A forum for reverse engineering, OS internals and malware analysis 

Discussion on reverse-engineering and debugging.
 #9118  by newgre
 Thu Oct 13, 2011 8:38 am
Hey,

I came across a kernelmode driver (actually starting at boot time) which takes a snapshot of all modules in the system and walks each modules' import directory.
First it checks whether each entry in the array pointed at by OriginalFirstThunk is signed, i.e. if this is an import by ordinal. But then, there is an additional check which determines whether an entry in this array has a value above 0x80010000, and if it is, the driver does some special processing with this address (it seems to mask everything above the first 12 bits and in some circumstances increments the address page-boundary-wise (0x1000); finally ends up with a name string of the import; it is weird).
From my understanding, this check must always evaluate to "false" since ordinals for imports can only ever be in the range of 0x0-0xFFFF, right? And since the OriginalFirstThunk is never touched by the OS loader, it cannot contain any virtual addresses, right? So how come, the code checks for a value above 0x80010000? In what situations can such a value end up in that array anyway? Any ideas welcome :)
 #9176  by newgre
 Sat Oct 15, 2011 9:15 pm
After looking at the driver routine once more and analyzing the way in which the windows loader processes imports by ordinal, I came to the following conclusions:
a) the OS loader requires that entries in the array pointed at by OriginalFirstThunk are either relative virtual addresses (to the hint name array) or values of the form 0x8000????. The ordinal corresponds to the lower 16bit of the value.
b) the driver contains a bug, i.e. the logic actually needs to be reversed in that it needs to test whether the values are below 0x8010000 and not above in order to continue with processing the array entry.