Can anyone shed any light on "API hooking" for me. That is what is it, how is it done, how can my application prevent this from occurring while it is running. Any reference to literature or other information on the subject would be appreciated.
Printable View
Can anyone shed any light on "API hooking" for me. That is what is it, how is it done, how can my application prevent this from occurring while it is running. Any reference to literature or other information on the subject would be appreciated.
I'm taking a wild guess. Is this got anything to do with screen capture?
Are you referring to the ability to view API fn calls made by your program? You can't disable that, since it's system-wide info. Matt Pietrek, of "Bounds-Checker" fame is one such guru you might look up the works of. The thing is, many of these guys are dyed-in-the-wool assembly experts, and they are quite adept at intercepting this sort of data, with or without system approval. Thus any attempt to obfuscate the mechanisms of your program are all but futile. But good luck trying, anyway. :D
I think he is refering to the ability to hook out Win API functions, and replace them dynamically with functions which do something else. I think he wants to know how you can prevent another application doing this to your program.
The only instance I know of where this is used is the prevention screen capture.
I'm not exactly sure what API hooking is. My assumption is though it either prevents the API function from working or replaces it with another function. If it can't be prevented, then
how can it be detected?
After a quick google, found these:
http://www.delphifaq.com/fq/q2172.shtml
http://www.experts-exchange.com/Prog...0294215.html#1
In my previous, reply I said:
>The only instance I know of where this is used is the prevention screen capture.
From my quick google, there seems to be all sorts of arcane reasons why you may want hook the win api, including some good, bad and ugly reasons. However, I can't think of many reasons why you might want to override a hook.
Is it possible you could tell us what you are trying to do?
Have you looked at
InSendMessageEx()?
I don't understand, novacain. How is this used? In a loop? After you send a message? Could you please elaborate? I read MSDN's explanation, the part I don't understand though is how you would practically use it....
API hooking is a process of looking at/hooking up imported symbols in the imports table of an exe or dll. If an exe uses say MessageBoxA() or ExitProcess(), then you can edit the import table to jump to a callback (that you define) and then divert the call to the actual API one you have done what you want to do...
It's not a very nice thing to do, and its pretty complex as you need a good knowledge of executable format, a good knowledge of the process address space and how exes and dll work and a little 32bit assembler knowlege to boot!
Seb mentioned Matt Peitrek...his artcles are a good start.....if you want API hooking countermeasures, then you will probably find it on the FAQ of http://board.win32asmcommunity.net/index.php as it comes up there exery now and again...
API Hooking-- this is not new. It's actually called "Trap Patching". Whenever an API function is called, an exception is generated and sent to a trap table. The trap is determined and the processor jumps to the address defined in the trap table.
In Fordy's response, when he refers to symbols, he's actually referring to linker symbols- in other words, function addresses. The 'import table' he's referring to is a 'trap table'.
when you "patch" the trap, you replace the address in the table for a particular function with an address to your own function that takes the same exact args and returns the same exact results as the API would normally expect.
There are three ways this can be done--
1) Before an API call, to modify or view information before an API func gets to see it.
2) Replace the API trap with your won to modify behavior entirely (this is incredibly useful for modifying the behavior of the O/S or correcting bug fixes until a new release is made, and
3) After an API call-- this is called "tail patching" and takes the results from the API call and modifies it before anyone else gets to see it.
Numbers 1 and 3 can cause problems if for some reason, registers are left in an improper state and are relied upon by the O/S to determine other heuristics of operation.
Number 2 is generally the safest, but is normally only done for that which I stated, or specifically to prevent certain types of behaviours-- such as disallowing someone to press Ctrl-Alt-Del, or a screen capture, etc.
---
This is a _very useful_ thing to know how to do. If you always play be the rules, it won't bite you.
So the original question was how to prevent API hooking, or at least to detect whether a certain API call has been hooked.
Would it be possible to exam the trap table & how would you know something has been modified from the default?
InSendMessageEx()
As a msg is received by your callback, you can test to see if it was 'sent' (and so filter some of those from from outside your app) or generated in your app.
Ok, thanks. So basically, returning true would mean that the current message was SendMessage'd (as opposed to what tho? DispatchMessage'd?). Thanks for that insight. I hate functions with that sig, BTW...annoying!
If you check incoming mouse or virtual key msg's you would be able to tell if some other app was trying to manipulate yours with send message calls.
Precisely. OK, thank you for the clarification.
Sayeh...out of interest, is this technique actually used that much?Quote:
Originally posted by Sayeh
2) Replace the API trap with your won to modify behavior entirely (this is incredibly useful for modifying the behavior of the O/S or correcting bug fixes until a new release is made,
I've seen articles on its use, but I often wondered on how much its actually used in practice.....I wondered if some of the "Hot fixes" you download as bug fixes from Microsoft used this as an interim fix before a decent service pack was released.....