views:

122

answers:

3

I am running Windows XP on an Intel x86 machine and I got an error in the instruction at memory location 0x00000001.

I am not worried about debugging the error, but I was interested to know what instructions would generally be located at the very begging of memory.

The only processors I have written low-level code for are PIC microcontrollers, and I know that the first memory location would be a GOTO and then the interrupt vectors.

+2  A: 

That is not the actual physical address space 000001. XP is a modern virtual paged memory OS so each application gets its own address space.

rerun
+2  A: 

I believe that the zero page of a process's address space is deliberately inaccessible on Windows to help detect null pointer errors, in which case there's nothing there.

Stephen Canon
+5  A: 

Windows guarantees that the first 64k and the last 64k of memory will always cause an access violation to read or write. This makes detecting null pointer dereferences easier.

See the graphic in this page below the heading

Free, Reserved, and Committed Virtual Memory

http://msdn.microsoft.com/en-us/library/ms810627.aspx

John Knoeller
To be clear: The guarantee is a weak guarantee. It's possible to map valid memory to virtual location 0, there have been a couple of elevation of privilege vulnerabilities that were exploited by doing that. But by default the first 64K of virtual memory are always 0.
Larry Osterman
@Larry: I'm sure there's a story behind that. It seems to me that if you can map memory into a privileged process you would have full control. There would be no need to try and exploit a null pointer reference.
John Knoeller
@John: Think EoP, not RCE. A great example of this is Mark Dowd's Flash attack: http://chargen.matasano.com/chargen/2007/7/3/this-new-vulnerability-dowds-inhuman-flash-exploit.html. All you need is a vulnerability in the kernel that writes into an allocated structure where the kernel doesn't check that the allocation succeeded. If you can get the allocation to fail (by passing in a big buffer), you can sometimes get the kernel to write to arbitrary locations in memory.
Larry Osterman
@Larry: I remember reading about that exploit when it happened. That was a very impressive attack.
Brightside