4 ms·

How I fixed the infamous Basilisk II Windows “Black Screen” bug in 2013

79 points by zdw 1y ago

cardanome 1y ago
I remember running Basilisk 2 on a PlayStation Portable. Not sure what the point was but I was happy I could.
MBCook 1y ago
Allocations moving around sounds a lot like the Address Space Layout Randomization (ASLR) that was added to Vista as part of the large increase in security hardening MS went through during development. Great article. I’d love to know why the memory was allocated that way initially.
- fredoralive 1y ago
  The two memory allocations makes sense, ROM and RAM are separate chunks of memory, and in the Mac memory map(s) they're non-contiguous, so why not two allocations? It's only once the C classic of optimising through FUN™ with pointers, and then weird issues with bits of the Mac ROM not liking being mapped into random high memory addresses that we end up with lockups.
rcarmo 1y ago
This reminds me that I cannot run BasiliskII at a decent resolution under GNOME at 125% - the thing apparently tries to set the window size several times, then goes into a black-bordered resolution mode that is _not_ what I asked for (and I'm used to setting the prefs directly, so I have mag_rate, scale_nearest, etc. all set "correctly"
- rcarmo 1y ago
  If anyone lands here from Google, I got it to work by setting scale_nearest and scale_integer to false since GNOME at 125% scaling seems to throw it off.
RJIb8RBYxzAMX9u 1y ago
Very interesting article, but this stood out to me: > To re-familiarize myself with this bug [...] I downloaded the broken version [...] and tried it out in some virtual machines. Windows 2000 and XP ran it without any trouble on the first try, but Vista and 7 didn’t [...] Amazing. Emulating an older system in order to debug emulating an even older system. The amount of compute / memory / storage readily available at our fingertips today is astounding. My first computer was a 68k Mac, and back then, I would never imagine such scenarios would be possible!
- electroly 1y ago
  The Windows virtual machines aren't emulated; there's still only the one expensive emulation layer going on here.
- bluedino 1y ago
  First web job I had, there were a pair of barely working Dell computers in a dark corner. They were there to test Windows XP and IE6 I virtualized that crap a couple weeks later.
canucker2016 1y ago
Windows Vista Heap changes: https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Marinescu.pdf https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Ma... https://moflow.org/Presentations/200703%20EuSecWest%20-%20Windows%20Vista%20Exploitation%20Countermeasures/rjohnson%20-%20Windows%20Vista%20Exploitation%20Countermeasures.pdf https://moflow.org/Presentations/200703%20EuSecWest%20-%20Wi...
- canucker2016 1y ago
  Analysis of 32-bit Windows Vista ASLR - https://www.blackhat.com/presentations/bh-dc-07/Whitehouse/Paper/bh-dc-07-Whitehouse-WP.pdf https://www.blackhat.com/presentations/bh-dc-07/Whitehouse/P... After the stack address has been selected, the process heaps are selected. Each heap is allocated from a range of 32 different locations, each separated by 64kB. The location of the first heap must be chosen to avoid the previously placed stack, and each of the following heaps must be allocated to avoid those allocated before it. An important result of Vista’s ASLR design is that some address space layout parameters such as PEB, stack and heap locations are selected once per program execution. Other parameters, such as the location of the program code, data segment, BSS segment and libraries, change only between reboots. This paper shows that the stack, heap, image and PEB protected by ASLR on Microsoft Windows Vista 32bit RTM have different frequency distributions. While the stack has near uniform distribution over a very wide range, the heap and PEB, and to a lesser degree the image base have much smaller ranges and because of biases in their distributions do not efficiently use this range. As a result, the protection offered by ASLR under Windows Vista may not be as robust as expected.

79 points by zdw 1y ago

I remember running Basilisk 2 on a PlayStation Portable. Not sure what the point was but I was happy I could.

Allocations moving around sounds a lot like the Address Space Layout Randomization (ASLR) that was added to Vista as part of the large increase in security hardening MS went through during development. Great article. I’d love to know why the memory was allocated that way initially.

fredoralive 1y ago
The two memory allocations makes sense, ROM and RAM are separate chunks of memory, and in the Mac memory map(s) they're non-contiguous, so why not two allocations? It's only once the C classic of optimising through FUN™ with pointers, and then weird issues with bits of the Mac ROM not liking being mapped into random high memory addresses that we end up with lockups.

rcarmo 1y ago

This reminds me that I cannot run BasiliskII at a decent resolution under GNOME at 125% - the thing apparently tries to set the window size several times, then goes into a black-bordered resolution mode that is _not_ what I asked for (and I'm used to setting the prefs directly, so I have mag_rate, scale_nearest, etc. all set "correctly"

rcarmo 1y ago
If anyone lands here from Google, I got it to work by setting scale_nearest and scale_integer to false since GNOME at 125% scaling seems to throw it off.

RJIb8RBYxzAMX9u 1y ago

Very interesting article, but this stood out to me: > To re-familiarize myself with this bug [...] I downloaded the broken version [...] and tried it out in some virtual machines. Windows 2000 and XP ran it without any trouble on the first try, but Vista and 7 didn’t [...] Amazing. Emulating an older system in order to debug emulating an even older system. The amount of compute / memory / storage readily available at our fingertips today is astounding. My first computer was a 68k Mac, and back then, I would never imagine such scenarios would be possible!

electroly 1y ago
The Windows virtual machines aren't emulated; there's still only the one expensive emulation layer going on here.
bluedino 1y ago
First web job I had, there were a pair of barely working Dell computers in a dark corner. They were there to test Windows XP and IE6 I virtualized that crap a couple weeks later.

canucker2016 1y ago

Windows Vista Heap changes: https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Marinescu.pdf https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Ma... https://moflow.org/Presentations/200703%20EuSecWest%20-%20Windows%20Vista%20Exploitation%20Countermeasures/rjohnson%20-%20Windows%20Vista%20Exploitation%20Countermeasures.pdf https://moflow.org/Presentations/200703%20EuSecWest%20-%20Wi...

canucker2016 1y ago
Analysis of 32-bit Windows Vista ASLR - https://www.blackhat.com/presentations/bh-dc-07/Whitehouse/Paper/bh-dc-07-Whitehouse-WP.pdf https://www.blackhat.com/presentations/bh-dc-07/Whitehouse/P... After the stack address has been selected, the process heaps are selected. Each heap is allocated from a range of 32 different locations, each separated by 64kB. The location of the first heap must be chosen to avoid the previously placed stack, and each of the following heaps must be allocated to avoid those allocated before it. An important result of Vista’s ASLR design is that some address space layout parameters such as PEB, stack and heap locations are selected once per program execution. Other parameters, such as the location of the program code, data segment, BSS segment and libraries, change only between reboots. This paper shows that the stack, heap, image and PEB protected by ASLR on Microsoft Windows Vista 32bit RTM have different frequency distributions. While the stack has near uniform distribution over a very wide range, the heap and PEB, and to a lesser degree the image base have much smaller ranges and because of biases in their distributions do not efficiently use this range. As a result, the protection offered by ASLR under Windows Vista may not be as robust as expected.