Results 1 to 3 of 3

Thread: Weird dll hook thanks to Vista SP1

  1. #1
    Registered User
    Join Date
    Jul 2007
    Posts
    107
    Blog Entries
    6

    Weird dll hook thanks to Vista SP1

    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
    Programming today is a race between software engineers to build bigger and better idiot-proof programs and the Universe trying to produce bigger and better idiots.
    So far, the Universe is winning.

  2. #2
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    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?
    "Give a man a quote from the FAQ, and he'll ignore it. Print the FAQ, shove it up his ass, kick him in the balls, DDoS his ass and kick/ban him, and the point usually gets through eventually."

  3. #3
    Registered User
    Join Date
    Jul 2007
    Posts
    107
    Blog Entries
    6
    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/my.php?image=presp1zr0.png

    post-SP1:

    http://img177.imageshack.us/my.php?image=postsp11vz2.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
    Programming today is a race between software engineers to build bigger and better idiot-proof programs and the Universe trying to produce bigger and better idiots.
    So far, the Universe is winning.

Similar Threads

  1. Replies: 3
    Last Post: April 1st, 2008, 04:01
  2. Weird...
    By ancev in forum Off Topic
    Replies: 1
    Last Post: March 17th, 2007, 20:05
  3. Ask a question about hook again
    By dcskm4200 in forum The Newbie Forum
    Replies: 2
    Last Post: August 6th, 2006, 11:10
  4. this is a question about hook
    By dcskm4200 in forum The Newbie Forum
    Replies: 18
    Last Post: July 31st, 2006, 13:12
  5. ? hook to a dll export?
    By _Servil_ in forum OllyDbg Support Forums
    Replies: 2
    Last Post: November 17th, 2002, 11:36

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •