Two questions:
1) How can I make sure my api hook is system-wide
2) Is the way I get data out of that call by issuing an entire set of asm instructions to set up a console window (or log file) thereby instantiating (instancing) a whole 'nother set of of objects? In other words, I can't just simply patch the IAT and say WriteConsole (or WriteFile) right? Because as far as that patched address is concerned it's running outside of my program and doesn't have the necessary handles setup right? Any help would be GREATLY appreciated, thanks!

-- StakFallT

Edit 1: As far fas question 1 goes, let me know if this is right... I loaded up Olly and opened my asm program, scrolled through the code to find the line that retrieves the API call via GetProcAddress, I than open the "Exectuable Modules" window double click on the dll containing the function, and breakpoint on the eax register value I got earlier from GetProcAddress. Is that the correct way or checking a system-wide hook? (It never seems to get to the address though which makes me think I'm doing something wrong). I'm wondering if maybe I should ask FrozenKnight if I can PM him since the hooking code that he sent me was his.

A1: SetWindowsHookEx

A2: Correct, that is why each DLL must initialise itself for each process it is mapped into.

AE1: Not the correct way. Windows uses copy-on-write so you are only altering the API in your own process. See A1 above for the normal way to do it.

Extra: You can also use "DLL injection" to put your own DLL into every running process. Search for it on this board, it has been discussed before.

Gotcha, thanks! Definitely going to look into it.. Not really looking for DLL injection as I don't want to replace the dll, I just want to reroute the call out then back in again.. So if I use SetWindowsHookEx the code I patch in will automatically be duplicated to all other process' DLL-instances by Windows right?

You don't replace any DLLs with injection, you insert a new DLL into the process. Many programs that monitor for certain keystrokes use this method. Nope, windows will notify your process when certain things happen.

hmmm.. Could you define "notify"? Like let's say I wanted to record the parameters of an API call used by some other program/process would SetWindowsHookEx be what I'd be using? I'm looking to go beyond having it just notify me that a call occurred. I'm looking to have a system wide hook that says: should if at any point this API call be used by any program/process, log that it was used and record the parameters to a file. If SetWindowsHookEx is in fact what I'd be using, the examples I've seen of it being used refers to ThreadOwners typically the owner being the main thread of your program that's using the SetWindowsHookEx. Is there a System thread or would I really have to hook the main thread of every single process just to create a system-wide hook?

EDIT: I know alot of this could be answered just by searching on yahoo, but I always feel the explanations from the random sites for some reason seem...... It's kinda like buying a programming book. One book can make a language seem impossible to learn, another book can make sense. Most times a good book makes or breaks things. And so it's hard to find something that breaks something down into laymens terms that is technically accurate and sound.

Since you admit that you know how to use a search engine, then I think that the MSDN site will tell what you want to know about SetWindowsHookEx. Short answer: No. Slightly longer answer: That is not what it does. Long answer: Read about DLL injection and use your custom DLL to modify whatever API call you want to monitor. See my website if you are not sure where to find the info.

But why bother the typing such a long question when a 1 second search and a bit of reading can save you time.

[content deleted]

yeah, plus a big problem with IAT patching is:

Source: http://help.madshi.net/ApiHookingMethods.htm

In other words, any of the DLLs distributed (or installed by an application) would have to have their IATs patched as well, otherwise they'll jump to the correct address and avoid the hook.

I thought SetWindowsHookEx would've done what I needed it to do but really it doesn't. Nothing at all what I need.. It monitors events/messages. I then decided to revisit the Detours example, and it looked promising until I saw a line that said:

; our hook which gets called when <insert API> is called in this process

this process... as in not system-wide. So it's back to the code that Frozen sent me.. Just have to figure out how to ensure the global address space for that api was infact patched and not some sort of virtual address space (In which the dll was loaded into as a "copy". If my understanding of inline code is right: I guess it's sorta like a C++ class can be copied/pasted (on the asm level) directly, by the compiler during compiling, at the line the statement was at, or it can simply make a call out and return back.

Basically I guess I'm looking for the opposite direction.. A way to modify the export addresses of a system DLLs' functions because it seems the import side of things would seem to be more of working from the application (Whether it be the exe or application dll that was linking against the system dll) side of things. Definitely interesting stuff though..

I think what I really need is to get a little bit better of an understanding on the kernel level of how DLLs are used. For instance, when an application's import table uses an api call from a system dll, does Windows load that system DLL into a special address space along with the executable? It would almost seem so, given preemptive multitasking. So then if that's the case, the real question is, short of physically going into a hex editor and modifying a system dll, how does one modify a system dll virtually so that when the system dll gets duplicated into various address spaces, the patch gets duplicated as well..

It would seem to me that there exists a virtual hierarchy system (Or various layers) that pass information further down the chain and if you hook the topmost you get everything below it. So far everything I'm reading seem to work the issue on an individual process basis, and to me that seems pretty impractical (Having to enumerate all running processes (and watch for new processes) and patch each IAT)

Edit 1:
I think what I'm looking for is System Service Descriptor Table hooking.
Sample of the source I found this at:

By the sounds of it, I found my answer. YAY!

hmmm... interesting... It seems like it would do what I need it to, but the details on it's implementation and usage are sketchy at best based on the documents that come with it. It's like they give you some Delphi units, but one of the units looks like it refers to just passing command line parameters to a utility that comes in the zip file. Gonna look it over some more tomorrow when I'm not so tired to make heads or tails out of the C code .. Thanks for the link btw

I thought this may be a good place, when I load any program into Olly, it says that ... well... about a dozen different DLL's are loaded. I couldn't get the names right now, but I know some are Windows and some probably aren't. Could this be from that DLL injection you're talking about?

I thought this may be a good place, when I load any program into Olly, it says that ... well... about a dozen different DLL's are loaded. I couldn't get the names right now, but I know some are Windows and some probably aren't. Could this be from that DLL injection you're talking about?

Yes, of course. They must be initialised before the process, just like all the other DLLs.

Well, I had never seen them before in Olly. I used to see only the main Windows dll's being loaded, now I see things like 'USP10','RPCRT4','OLEAUT32','LPK',SHLWAPI', and even 'ADVAPI32' being loaded into every process!

Check the registry key HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\Appinit_Dlls to see what DLLs are being injected. Those DLLs may also load other DLL during initialisation. Is all depends on which programs you have installed and what settings you have enabled inside them.

Thanks Rev (I didn't see that until today).

EDIT: The AppInit_DLLs key has no value! I guess that's good, I'll keep looking.