I came across a weird problem caused by Vista SP1 that prevents "unforwarding" some imports by ImpREC or similar programs.

I've seen it happen on user32.dll and did a bit of spelunking:
DefWindowProcA and DefWindowProcW's AddressOfFunctions entries usually lead to a string that forwards them to NTDLL.NtdllDefWindowProc_A and NTDLL.NtdllDefWindowProc_W on pretty much all versions of Windows.

After installing Vista SP1, the physical file doesn't seem to have changed.
The "paper trail" to the forwarding string can still be followed as usual.
During run-time, the AddressOfFunctions entries are not the same, they lead outside of the dll's ImageSize and are not constant (0x1793D42 or 0x1B83D42).

ImpREC cannot unforward those 2 APIs successfully so they are still identified as belonging to ntdll.dll, which is not a good thing, I presume.
If the loader can forward the API to ntdll, it must be able to find the forwarding string somehow.

Uninstalling the Service Pack has fixed the problem but I'm still looking for an explanation.
Why such a weird-ass hook?
Why such a weird-ass hook on only those 2 APIs?
How such a weird-ass hook is achieved?

I could be mistaken about this next part but the modified entries seem to lead to code (I need to reinstall the SP to verify this again).
If they effectively lead to code and not the forwarding string, how can the loader know to forward them to ntdll.dll anyway?

TiGa

Cool finding indeed. Have you verified it on some other (preferably as clean as possible) system, to make sure it is not cause by some third party hook by some other application on your system (even though it disappearing when uninstalling SP1 seems strange in that case)? Have you also tried it on multiple executables that are certain not to be purposely protected by something that might cause this behavior?

Anyone has any idea about what it might be?

I did more digging today and found more details.
The MS employee that did this should really be feeling some MS-Shame right now.
It is specific to the WoW64 of Vista x64 SP1 and to DefWindowProcA and DefWindowProcW but there could be more.

It is basically a way of forwarding an API without a forwarding string.
Probably some hotfix in wow64.dll that wasn't thought through.
I'll include more details in a blog entry and even more details with a workaround for my ReCon talk.

The weird RVA that leads outside of the dll in fact leads inside ntdll.dll.
ImageBase of user32.dll + weird RVA = OEP of new forwarded API = IAT entry that belongs to ntdll.dll

As a result, there is a wacky side-effect:
GetProcAddress(DefWindowProcA) == GetProcAddress(NtdllDefWindowProc_A)
GetProcAddress(DefWindowProcW) == GetProcAddress(NtdllDefWindowProc_W)

The resolved RVA is really code, a standard FF25 [address] call that leads back to user32.dll.
It could have always gone back to user32.dll, I never checked before on a "regular" system but it doesn't really matter anyway.

ImpREC only tries the traditional unforwarding method by bruteforcing all dlls until a good forwarding string is found so it fails to unforward those two specific APIs.
As seen here from an unprotected FireFox process, pre-SP1:
http://img510.imageshack.us/img510/4355/presp1zr0.th.png (http://img510.imageshack.us/my.php?image=presp1zr0.png)
http://img510.imageshack.us/my.php?image=presp1zr0.png

post-SP1:
http://img177.imageshack.us/img177/3155/postsp11vz2.th.png (http://img177.imageshack.us/my.php?image=postsp11vz2.png)
http://img177.imageshack.us/my.php?image=postsp11vz2.png

http://img177.imageshack.us/img177/3144/postsp12vf6.th.png (http://img177.imageshack.us/my.php?image=postsp12vf6.png)
http://img177.imageshack.us/my.php?image=postsp12vf6.png

I have found a work-around for this that still allows for unforwarding.
I guess that I'll have something interesting to say at ReCon after all.

I still don't understand the point of all this...
Why such an ugly fix?
The standard loader wouldn't go for this if the physical file was modified with such a weird RVA.

Big thanks to M. Pompeo of IITAC for the brainstorming session.

TiGa