Is there any way to get hInstance of the application that is NOT in the address space of the calling process? I mean something GetModuleHandle but for any process in the memory?
If there are could anyone suggest the solution or give me a tip?
Thanks
Posted on 2002-11-15 06:21:00 by Spot
hInstance is just virtual memory address where program is mapped so it is basicly same for every program on win9x
I think that on nt platform there is no fixed location at which program will be loaded

so basicly you can have all programs hInstances but they are useless to your program is in different memory space (different or should I say parralel world :D)
Posted on 2002-11-15 17:15:41 by Mikky
Most hInstance's for PE executables would be 00400000h. You can retrieve them with toolhelp32 API. But as Mikky said, they would be useless to you as they are in different address space. Although you can use ReadProcessMemory/WriteProcessMemory API on them.
Posted on 2002-11-17 11:39:04 by comrade
And you have to remember that an "app" will have several hInstances, one for each module that is loaded. An exe and a dll are both counted as modules.
Posted on 2002-11-18 03:53:24 by sluggy
Thanks all. You're all right I've checked GetModuleHandle.
But say if I hook the process and make a thread of the process of myself. Then I'm going to be in the same address space? I mean my callback function should be in the same address space before the call and the thread is created. That means that my thread will be in the same address space of the original process who called the callback function?
What happens then if I exit from the original process that set hook? Will my thread still exist?
Posted on 2002-11-18 05:05:41 by Spot
But say if I hook the process and make a thread of the process of myself. Then I'm going to be in the same address space? That means that my thread will be in the same address space of the original process who called the callback function?
If you install thread-specific hook, specifying dwThreadId in last param of SetWindowsHookEx,
then your callback function resides id dll mapped in process that owns that thread.
And your callback function is called in that process context. And your newly created thread will live in the same process.

If you install global hook, specifying 0 in last param of SetWindowsHookEx,
then your dll will be mapped in all processes. And in every process it creates new thread.
Each thread corresponds to the process in which it was created.

What happens then if I exit from the original process that set hook?
Nothing except for your process will die.

Will my thread still exist?
Yes. Your thread is a part of remote process and has no relationship with your process.
Moreover:
You can release a global hook procedure by using UnhookWindowsHookEx, but this function does not free the DLL containing the hook procedure. This is because global hook procedures are called in the process context of every application in the system, causing an implicit call to the LoadLibrary function for all of those processes. Because a call to the FreeLibrary function cannot be made for another process, there is then no way to free the DLL. Windows eventually frees the DLL after all processes explicitly linked to the DLL have either terminated or called FreeLibrary and all processes that called the hook procedure have resumed processing outside the DLL.
Posted on 2002-11-18 05:44:52 by Four-F

If you install thread-specific hook, specifying dwThreadId in last param of SetWindowsHookEx,
then your callback function resides id dll mapped in process that owns that thread.
And your callback function is called in that process context. And your newly created thread will live in the same process.


I thought as well! it is great then the next question is: When I'm in the address space of the process can I reroute SOCKET functions of the process I'm now the part of? Actually I'm thinking of writing a proxy server that can set proxy server settings to any of ALREADY running processes. I'm just thinking of the possiblity of the deed. It is very useful to set proxy servers to any of the processes... and I think that an implanted thread that reroutes SOCKET functions to an address specified. There are a number of possiblities that can be made with so implanted thread.

Thanks!!
Posted on 2002-11-18 07:19:32 by Spot

Actually I'm thinking of writing a proxy server that can set proxy server settings to any of ALREADY running processes.



Symantec's Norton Virus Scanner does something like this. It hooks the winsock dll globally to filter SMTP and POP3 communication of every running mail programm, communicating over port 110 or 25 (maybe other ports too). That way it also filters outoging mails you send via telnet ;)
In fact you might just use that way (hooking winsock) instead of trying to hook a single process.
Posted on 2002-11-18 07:46:10 by bazik
bazik, do you know what method NAV use to globally hook winsock APIs?
Posted on 2002-11-19 16:11:56 by Mikky
mikky,

you should check CreateRemoteThread(), for nt, and elicz simulation of this api, for w9x

this way you can get control in other process addresspace and hook things from there(import table), or its context(windows hooks)

ancev
Posted on 2002-11-19 16:27:53 by ancev

mikky,

you should check CreateRemoteThread(), for nt, and elicz simulation of this api, for w9x

this way you can get control in other process addresspace and hook things from there(import table), or its context(windows hooks)

ancev


Yes it looks like a much simplier solution. One just have to get PID of the program then one would have to run OpenProcess to get process handle and then one can use CreateRemoteThread to create the thread that will run in the process address space he got handle to earlier.
But I can all so see some weak sides about this method to compare with thread hooking.
Say if I'm a process that was created with HIGH security level CreateRemoteThread should fail to accomodate itself in the address space of such a process.

And that makes this method useless when firewalls are concerned so I doubt that NAV uses this method. Let me know if I'm not correct.

BTW threading is perfectly suited for trojans that want to pass through firewalls undetected. The trojan should only have to attach itself to a process like IE. Who knows anyway how much threads are there on his computer at the moment, nobody would have ever notice a new thread.
Posted on 2002-11-20 09:17:06 by Spot
AFAIK, CreateRemoteThread exists only under ME, 2K and XP.
Posted on 2002-11-21 04:12:50 by Four-F

AFAIK, CreateRemoteThread exists only under ME, 2K and XP.


and NT

I'm not sure about ME but since it does support transparency while 9X does not....
Posted on 2002-11-21 05:30:45 by Spot