hckrnws

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.

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.

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...

  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.

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"

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.

I remember running Basilisk 2 on a PlayStation Portable.

Not sure what the point was but I was happy I could.