When my driver loads (before DriverEntry is invoked), RtlImageNtHeader
is called. Among others, it verifies that my PE driver has a valid "MZ"
signature. It is failing this check and subsequentially crashing.
The compare operation is pretty straightforward:
cmp word ptr[eax], 5a4d
While standing on this command, WinDbg's Disassembler suggested that
word ptr[eax] indeed contained 5a4d. However, the result of the
comparison was: unequal (ZF = 0).
Looking at @eax in the Memory pane showed a beatiful header starting
MZ.. 0x4d 0x5a 0x90 0x00
However, when I tried reading this DWORD from the context of the code
(by manipulating some 'mov' I found in the code to do this -- a dirty
trick), I've got:
0xcc 0x5a 0x90 0x00
0xcc? Weird! How could it be that WinDbg's Memory pane shows something
different than what the code sees?
Next thing, I tried overwriting the header with 0x01 0x02 0x03 0x04 and
then reading it back from the code. Guess what I've got?
0xcc 0x02 0x03 0x04
How could this be possible? Are WinDbg's memory reads performed
P.S. I had additional two pairs of eyes seeing this, suggesting that
I'm not hallucinating.
 MiEnablePagingForDriver never checks RtlImageNtHeader's return
value but that's a different issue altogether (and a corrupted driver
will cause a bugcheck one way or another, so this is not significant).
"Ilya Konstantinov" <ilya.kon...@gmail.com> wrote in message