Windows Process Data Types

You can''t convert a HANDLE to a HMODULE (or vise versa). One (HANDLEs) are kernal objects representing processes, the other (HMODULEs) are handles used by processes to keep track of executable files mapped into their address space. To get a HMODULE you need to map the file to your first processes address space. Try LoadLibrary instead of GetModuleHandle. It returns an HINSTANCE but you can cast it to an HMODULE and use it as one. GetModuleHandle''s documentation sounds like it will only work if the module has already been mapped.

What do you need an HMODULE for? Typically they''re only used with DLLs, so you could probably accomplish what you''re trying to do a different way.

First off, the GetModuleHandle function retrieves a module handle for the specified module if the file has been mapped into the address space of the calling process. A child process does not run in the same address space as it''s parent - thus the NULL return value from GetModuleHandle. The child process has it''s own address space and it''s HMODULE value will also be 0x00400000 the same as it is for the parent process. Thus your approach will not work at all ever. You''ll have to figure out some other way to do whatever it is you''re trying to do.

Solo: I realize they are two different data types that represent different things. HMODULE is just a typedef that represents the HINSTANCE type, and every program has an HINSTANCE, so there has to be some way to get that if you have the handle to the process of that program and the name of the executable used to create it.

LessBread: I need to retrieve the HINSTANCE of the child process, and I believe there is a way because some code I got from planet-source-code.com has a function that takes the HINSTANCE of another program. Were it impossible to get the HINSTANCE (or HMODULE, as they are the same thing), it would make little sense for a programmer to create such a function.

mutex: I''m trying to do some IAT patching on a program to first find out how it works, and then modify and add some functionality. Its game related because the program is a map editor =-) The problem is that the only code I could find to implement IAT patching assumes you have the HINSTANCE(or HMODULE) of the program you need to patch.

A friend of mine reminded me that you can use GetWindowLong to get the HINSTANCE associated with a window, so I might have to do that, but it seems like an unnecessary hack.
After looking through the MSVC docs, it might be possible to use LoadLibraryEx and GetModuleHandle to get the HMODULE of the exe without running anything, and then use GetModuleInformation to get the entry point (but that might not work, it might only work for dllmain and not winmain) but that also seems like a needless hack.
There should be a cleaner way, I just need to find somebody that knows it =-)

"The Requested Information Is Unknown Or Classified" -Anonymous

One way to achieve this is DLL injection. You have three parts. The injector, which co-ordinates activities. The victim, which gets patched. And the DLL, which gets injected by the injector into the victim; it is then free to patch the victim, hook function calls, blah blah.

The injector does the following:
Spawn a process -- the victim -- in the suspended state
Allocate some memory in the victim''s address space
Copy a function body to the memory you allocated
Create a thread using that function body as its threadproc in the victim with CreateRemoteThread
Unsuspend the victim''s main thread

The purpose of the function for the created thread is to simply call LoadLibrary to load your custom DLL.

The DLL does the actual patching. Because it''s inside the victim process, it can get handles to all the modules inside the process with GetLoadedModules.

It enumerates each module in the process. If the module isn''t patched already, it patches its IAT.
It then patches the calls to LoadLibrary and LoadLibraryEx, so that whenever they are called, the call is intercepted. This is so that each newly loaded library can be patched before it gets a chance to run.

I wrote the actual patching routines myself (look at the PE''s headers, they''re not too fiddly), but then I found the BugSlayer hooking library, which did the job a bit better (it had the code to patch by ordinal as well as by name). That library should be available here.