Page 1 of 3 123 LastLast
Results 1 to 15 of 40

Thread: Not quite hooking...

  1. #1

    Not quite hooking...

    I'm messing around with the DebugAPI, and would like to be able to find where in a "slave" program it calls various windows APIs.

    I understand that I can do a GetProcAddress function to find the addresses of the functions that I want to find, but how do I locate them within the slave?

    At first I thought it might be through parsing the IAT, but that would just tell me that they DO in fact call them.

    Is there a way other than to brute force search the whole image for references?

  2. #2
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    The cross-reference feature of IDA Pro will do this for you, as long as the imported API is statically imported (i.e. is in the IAT).

    To complete it with also the dynamically imported APIs, you must dynamically hook all API functions in all loaded modules, and then take a look at the return address on the call stack for each call to these functions.

    There are many readily available API call loggers though, see the following CRCETL category for more info about these:

    http://www.woodmann.com/collaborative/tools/index.php/Category:API_Monitoring_Tools
    "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
    Doh! I left out that I want to do this at RUNTIME. Not from a static listing.

  4. #4
    well its fairly simpel..the only thing you really can do is search the .txt for FF15 calls ( Call DWORD PTR[IAT REFERENCE] ) ..thou the risk of false positives is present..thats the easiest way ...next you can improve the results by using a Dissassembler library..

    hope i understand your request correctly
    http://www.reversing.dk/

  5. #5
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    My tips above still apply, except the IDA Pro one then, and they are most likely the most reliable method to do it.

    1.
    Enumerate all loaded modules in the process space of the target process, and hook all the exports of these.

    2.
    Set a special hook on the LoadLibrary function. As soon as it is called on a new module, hook all the exports of this new module before you return control to the target program.

    3.
    In the hook function of each export, log the return address on the stack (together with the name of the export of course).

    You will then have a complete log list of all called imports of the program, and all the addresses at which they are called.

    And again, many readily available API loggers will do this, or similar things, for you.
    "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."

  6. #6
    OK, enough with me being generic. Let me explain what I'm trying to do.

    Primary note, this app is for personal use only, so I won't be releasing it.

    I do "requests" for friends from time to time, and 1 friend has me "fix" the same program for him over and over. (Everytime a new release comes out, he gets it, and sends it to me).

    Over the years, yes, I'm serious, there has been 1 constant in these programs. A call to WriteProcessMemory. There is only 1 of them, but they move around when the code is changed.

    This is a straight call from the code, not a GetProcAddress kind of situation. What I want to do, is to figure out how to, in my "fixer" program, find the call to WriteProcessMemory, and be able to modify some bytes around it in order to fix this app. I want to make an app for him that he can run on every release of this app from now until they change things too much for this to work.

    Does that make more sense? I was trying to be generic above, but I guess I was TOO generic.

  7. #7
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    I don't quite understand why you need to do it during runtime, since you seem to have the static application? If it is packed, you will of course need to dump it first to be able to patch it at all, and in that case you can as well perform static analysis on the unpacked executable.

    Are you trying to create a loader, or do you just want the info for a static patch?

    Anyway, given that you still want to do it during runtime, and that you can somehow get the program to break at OEP (or rather, any point in time where no code important to you has still executed, while the imported modules of the executable have still been loaded in memory and the IAT has been populated), do the following:

    1.
    Resolve the address to the WriteProcessMemory API inside the memory space of the application (either by injecting a GetProcAddress call, or by manually parsing the IAT of the process).

    2.
    Hook this function by patching/redirecting the first bytes of it in memory.

    3.
    Log the return address of the call(s) to it from your hook function, from the stack.

    4.
    For extra credit, let your hook function analyze the bytes around the call location on the fly, and output the information necessary to patch the static executable to work as you want.

    Done.
    "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."

  8. #8
    I've gotten A TON of stuff working now. Got the API Hooking working, got the "backtrace" from the stack working, and I even patch the bytes in memory, which lets it act as a loader for many different versions of his app.

    Thanks Guys!


    But, now that the API Hooking genie is out of the bottle, I've starting tinkering with using it for other things, which brings me to my question of the week:

    How does one go about API Hooking in a packed program with a mangled IAT?

    My first thought was that I might need to rebuild it in memory, and THEN hook what I want.

    Keep in mind that I want to do this at RUNTIME without deadlisting the code, and using a dumper, IAT fixer, etc.

    My first thought as to a way in, would be to monitor DLL loads, and the first load that happens after the code starts running, is from INSIDE, and that would be the time to launch the IAT fixer, and then the API Hooking.

    So, that being the case, how would YOU do it?

  9. #9
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    I still re-suggest my initial suggestion , namely:

    1.
    Enumerate all loaded modules in the process space of the target process, and hook all the exports of these.

    2.
    Set a special hook on the LoadLibrary function. As soon as it is called on a new module, hook all the exports of this new module before you return control to the target program.
    The IAT is irrelevant (or at least unrealiable, due to the numerous ways to mess up or hide and IAT), I would instead recommend hooking the code directly inside the exported function code inside each module (which is also why I say "hook all the exports of this new module" instead of "hook all imported functions from each module"), i.e. by patching in your hook over their first instruction. This will require some analysis of this first instruction/instructions though, although in most cases it will be one out of a very few alternatives, so no full disassembler should be needed to cover most of them.

    There are some packers (e.g. Asprotect) that even try to counter this kind of thing though (and the similar/related breakpointing of API calls), by emulating the first bunch of instructions of imported functions separately, and then skipping these instructions inside the imported module code, and jumping directly a bunch of bytes into it. Just keep this in mind if your hooks would seem to fail sometimes. To counter this, you could of course integrate a full disassembler inside your own code, which instead places your hook at the first conditional branch instruction inside the imported function. This in turn brings with it problems with exceptions and similar to solve though...
    "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."

  10. #10
    Hooking the exports becomes more of a "system-wide hook" since you're modifying the code inside the DLL, (in memory). Right?

  11. #11
    Wrong

    Each process loads a local copy of every DLL it uses. This has been the case since the Windows 95 kernel was ditched in favour of NT. I suggest you use an existing solution to this common problem. Microsoft Detours is a good option. My home-grown equivalent would also do the trick (http://www.ring3circus.com/downloads/dll-injection-framework/). These both hook the functions at their entry-points, rather than the caller at the reference-point as you initially asked, but I gather that this constraint has fallen by the wayside.

  12. #12
    I don't mind being wrong! That's the way I learn.

    I have "caller hooking" working as long as I can parse the IAT. Now that the IAT is destroyed in some packed programs, I'm looking for an alternate method. I worked out how to do it in my head today, and I'll give it a shot. If it should fail, I'll look at your framework, and Microsoft as a last resort, as I assume that their Detours is probably not the lightest weight solution available.

  13. #13
    This is my hooking library that performs a variety of different types of hooks:

    - IAT hooking
    - EAT hooking
    - Debug register hooking
    - Thread-safe jmp patch hooking using a length-disassembler engine and a code thunk that masks the problem of jumping back to the original function

    http://download.yousendit.com/9B7148B859485D9E

    Also, here's a library I wrote for dll injection by 'manually mapping' a PE file into the remote address space of a process. Instead of calling LoadLibrary or using SetWindowsHookEx (which also essentially calls LoadLibrary internally), this code parses the PE file itself, fixes up the relocs, maps the sections, and builds the import table. It also redirects APIs like GetModuleHandle and GetProcAddress so that manualmap'd modules are visible to each other, but are not visible to any other modules in the process:

    http://download.yousendit.com/2B06DBBE621E3DDC

    If you're not interested in using ManualMap for stability or other reasons, here's an article I wrote on the other three major methods of DLL injection, which incldues code examples of each:

    http://www.edgeofnowhere.cc/viewtopic.php?t=308049

    This is also a description of the impetus for writing the manualmap and CHook libraries and general musings on the problems of defeating game-hack detection systems:

    http://www.rootkit.com/newsread.php?newsid=360

    Another snippet of code you might be interested in is this KiFastSystemCall hook I wrote that hooks all user-mode APIs by replacing the SYSENTER MSR. This library isn't as flushed out, but it does work even on multi-processor systems and should be easy to extend into a fully functional library if you want to:

    http://download.yousendit.com/FD4D3FEE6C467564

    EDIT:

    Each process loads a local copy of every DLL it uses. This has been the case since the Windows 95 kernel was ditched in favour of NT.
    That's not *entirely* true. It is effectively true, but until a modification is made, most dll's that are mapped into more than one process actually do point to the same pages in physical memory. As soon as a page is modified in one process though, it's copied out and then that process will retain its own version of that specific page. This mechanism is referred to as 'copy-on-write', and is better explained here:

    http://en.wikipedia.org/wiki/Copy-on-write
    Last edited by darawk; June 27th, 2008 at 03:28.

  14. #14
    Administrator dELTA's Avatar
    Join Date
    Oct 2000
    Location
    Ring -1
    Posts
    4,206
    Blog Entries
    5
    "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."

  15. #15
    Quote Originally Posted by dELTA View Post
    There are some packers (e.g. Asprotect) that even try to counter this kind of thing though (and the similar/related breakpointing of API calls), by emulating the first bunch of instructions of imported functions separately, and then skipping these instructions inside the imported module code, and jumping directly a bunch of bytes into it.
    The app that I was playing with was ASPR protected, and I got around it's defenses by using EAT Hooking. (The packed app was loading a DLL that it was making calls to, I hooked the function in the EAT, and redirected them to me, and I was golden!)

    Also, FWIW, this DLL loaded itself into memory, and then the app checksummed it's "in memory image", and this checksum passes even with the EAT hook in place.

Similar Threads

  1. Api hooking
    By w_a_r_1 in forum The Newbie Forum
    Replies: 8
    Last Post: January 31st, 2011, 19:22
  2. .NET hooking
    By rendari in forum Advanced Reversing and Programming
    Replies: 10
    Last Post: January 30th, 2008, 15:59
  3. Preventing API hooking????
    By yaa in forum Advanced Reversing and Programming
    Replies: 17
    Last Post: September 23rd, 2002, 16:49
  4. api hooking via vxd...
    By hex0r in forum Advanced Reversing and Programming
    Replies: 7
    Last Post: January 23rd, 2002, 14:15
  5. api hooking
    By 4oh4 in forum Advanced Reversing and Programming
    Replies: 21
    Last Post: December 6th, 2001, 21:39

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
  •