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!
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.
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.
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.
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"
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!
The Windows virtual machines aren't emulated; there's still only the one expensive emulation layer going on here.
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.
Windows Vista Heap changes:
https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Ma...
https://moflow.org/Presentations/200703%20EuSecWest%20-%20Wi...
Analysis of 32-bit Windows Vista ASLR - https://www.blackhat.com/presentations/bh-dc-07/Whitehouse/P...
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.
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.
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"
I remember running Basilisk 2 on a PlayStation Portable.
Not sure what the point was but I was happy I could.