Click to See Complete Forum and Search --> : Process Hooks, how to?


MrDoomMaster
February 26th, 2006, 08:47 PM
There is a specific process on my system that is randomly scanning my system's running processes and retrieving information about them. Sounds like spyware, right? It's actually a game doing this, I won't mention any names but I intend to stop it.

I was wondering if it would be possible to "hook" into all win32 calls that involve getting process lists, or obtaining process memory data.

An example of a few calls I want to prevent the program from doing:

EnumProcesses()
ReadProcessMemory()
WriteProcessMemory()

I want to develop a small program that "intercepts" these calls and either prevents them or simply returns bogus data to the program (so that it doesn't feel it's being denied).

Any push in the right direction would be MOST helpful. Thank you!

Bornish
February 27th, 2006, 02:44 AM
Simplest way I know:
Patch the entry point of the executable that starts the "game", in order to load one DLL that you'll be writing and then call the original entry point. (I can patch it for you)
In the DllMain of your dll write stub functions with the same prototype as the ones for which you need to simulate behaviour.
Try to get "psapi.dll" module handle!
If successful, parse its IAT (import addres table) and replace the address of EnumProcesses() with your stub which does nothing... thus not enumerating any process. (I have also some code parsing IATs)
If "psapi.dll" is not loaded yet, you need to replace the pointer to LoadLibrary() in "kernel32.dll" 's IAT. Note that "kernel32.dll" should be already loaded since was used to load your dll, too! ;)
Replacing the implementation of LoadLibrary() with a stub that still calls the kernel's implementation will allow you to catch when the "game" is loading "psapi.dll", and then patch its IAT.
As for WriteProcessMemory() and ReadProcessMemory()... you can replace their calls with stubs (patching kernel's IAT)... but I don't see a reason, since no processes will be enumerated by a call to EnumProcesses().

PS: If you need to block only the memory access to other processes while allowing the processes enumeration, might be enough to ONLY patch OpenProcess() from kernel32.dll, since read / write ops need a handle with enough rights (PROCESS_VM_READ / PROCESS_VM_WRITE, PROCESS_VM_OPERATION). In case the "game" handles properly (without crashing or exiting) a NULL handle returned by OpenProcess, this simpler solution should suffice.

Best regards,

philkr
February 27th, 2006, 04:32 AM
Could it be that the game is a popular MMORPG by Blizzard?

JohnyDog
February 27th, 2006, 04:49 AM
There is a specific process on my system that is randomly scanning my system's running processes and retrieving information about them. Sounds like spyware, right? It's actually a game doing this, I won't mention any names but I intend to stop it.
Many online games scans processes or memory to determine if any hacks/cheats programs (eg. aimbots) are running. But if it is offline-only game, then yes, it is probably spyware.

MrDoomMaster
February 27th, 2006, 10:08 AM
Could it be that the game is a popular MMORPG by Blizzard?

Could be :)

MrDoomMaster
February 27th, 2006, 10:12 AM
Simplest way I know:
Patch the entry point of the executable that starts the "game", in order to load one DLL that you'll be writing and then call the original entry point. (I can patch it for you)
In the DllMain of your dll write stub functions with the same prototype as the ones for which you need to simulate behaviour.
Try to get "psapi.dll" module handle!
If successful, parse its IAT (import addres table) and replace the address of EnumProcesses() with your stub which does nothing... thus not enumerating any process. (I have also some code parsing IATs)
If "psapi.dll" is not loaded yet, you need to replace the pointer to LoadLibrary() in "kernel32.dll" 's IAT. Note that "kernel32.dll" should be already loaded since was used to load your dll, too! ;)
Replacing the implementation of LoadLibrary() with a stub that still calls the kernel's implementation will allow you to catch when the "game" is loading "psapi.dll", and then patch its IAT.
As for WriteProcessMemory() and ReadProcessMemory()... you can replace their calls with stubs (patching kernel's IAT)... but I don't see a reason, since no processes will be enumerated by a call to EnumProcesses().

PS: If you need to block only the memory access to other processes while allowing the processes enumeration, might be enough to ONLY patch OpenProcess() from kernel32.dll, since read / write ops need a handle with enough rights (PROCESS_VM_READ / PROCESS_VM_WRITE, PROCESS_VM_OPERATION). In case the "game" handles properly (without crashing or exiting) a NULL handle returned by OpenProcess, this simpler solution should suffice.

Best regards,

This is very awesome information. Unfortunately I do not know enough about parsing IAT's, I was hoping for a tutorial that would describe the concept in detail. Would you happen to know of any good tutorials? The only nice tutorial I could find is the following:

http://www.codeproject.com/dll/DLL_Injection_tutorial.asp

It lacks discussion on some very important terms and concepts that I was hoping I could get elsewhere.

Thanks again for your help!

MrDoomMaster
February 27th, 2006, 10:12 AM
Many online games scans processes or memory to determine if any hacks/cheats programs (eg. aimbots) are running. But if it is offline-only game, then yes, it is probably spyware.

Well this may or may not be true. In any case, I don't like it. If I have the power to stop it then I will :)

MrDoomMaster
February 28th, 2006, 01:27 PM
Bump? I would still like a good tutorial on DLL Injection / Function Interception along with good descriptions of terminology & concepts.

Thanks for any links. The tutorials I've found haven't really been as helpful as I've hoped.

Bob Davis
March 1st, 2006, 08:01 PM
Try this link (http://research.microsoft.com/sn/detours/). It's for a library called Detours. I bookmarked this a while back thinking that it looked neat, but I've never examined it thoroughly. It's a Microsoft Research project (open-source, I think) that allows you to instrument Win32 API calls. You should be able to inject code into a running process, IIRC.