fyi -
I just wrote some code to hide a process from the OS. In essence this allows MQ (or any other process for that matter) to run completely undetectable by all Win32 API; e.g. PSApi and the ToolHelp API can't detect the process and even System Internals Process Explorer and the Windows Task Manager can't detect the cloaked process(es).
Since SoE doesn't check client side running processes this isn't a big deal right now. Just so the rest of you know, however, we do have this stealth ability if we ever need it.
FYI - Process cloaking...
Moderator: MacroQuest Developers
-
dont_know_at_all
- Developer
- Posts: 5450
- Joined: Sun Dec 01, 2002 4:15 am
- Location: Florida, USA
- Contact:
Shouldn't be a problem at all...
Compuboy - no known virus do this. This is a bit more complicated then what virus' usually do and requires more access then they can get.
dont_know_at_all - Yes. I can cloak a DLL from a process that has loaded it - including making calls to open handles to it fail; e.g. GetProcAddress( hDLL, "") - without unloading the DLL. Note, however, that this will cause the DLL to be unloadable until reboot.
We can also do the following:
* Freeze individual threads in a process.
* Completely freeze a process from running (this is done by freezing all its threads which I already made a UI for).
* Make a process forget about which Threads it has running without terminating them.
* Make a process forget about which Handles it has opened without closing them.
Not to toot my own horn.. but... it's pretty major; especially for worm authors and the current flurry of RPC exploits as delivery mechanisms.
dont_know_at_all - Yes. I can cloak a DLL from a process that has loaded it - including making calls to open handles to it fail; e.g. GetProcAddress( hDLL, "") - without unloading the DLL. Note, however, that this will cause the DLL to be unloadable until reboot.
We can also do the following:
* Freeze individual threads in a process.
* Completely freeze a process from running (this is done by freezing all its threads which I already made a UI for).
* Make a process forget about which Threads it has running without terminating them.
* Make a process forget about which Handles it has opened without closing them.
Not to toot my own horn.. but... it's pretty major; especially for worm authors and the current flurry of RPC exploits as delivery mechanisms.
I would think you could detour this api, just like any other and prevent it from reporting the names of dll's you dont want known, AMadMonk and I had talked about doing this before but never got around to trying it.dont_know_at_all wrote:Well, before they start checking processes, they are going to check the DLLs loaded into the eq client. Can you cloak that API?
A million ways...
Detour'ing GetProcAddress() is very easy. Unfortunately it's equally easy to tell if you have detoured it.
... but, why stop at GetProcAddress? You're going to have to hook all the API that PSAPI and Tool Help use because they can get module lists and find you that was as well. THEN you're going to have to hook the NtDll.dll calls that provide the same features - but I know that most of you can't write (or figure out) code at this level so you may as well not even try. Oh, did I mention that you may want to check the PEB?
So, it would seem that you're best bet is to forget about detouring GetProcAddress() - that's script kiddie talk. If SoE wanted to find you then they'd start with calling IsDebuggerPresent(). That'll probably weed out half of the attempts right there; or at least those that can't get/use SoftIce, write their own inter-process breakpoint/read/write memory app, kernel mode inspection API, or injection debugger.
... but, why stop at GetProcAddress? You're going to have to hook all the API that PSAPI and Tool Help use because they can get module lists and find you that was as well. THEN you're going to have to hook the NtDll.dll calls that provide the same features - but I know that most of you can't write (or figure out) code at this level so you may as well not even try. Oh, did I mention that you may want to check the PEB?
So, it would seem that you're best bet is to forget about detouring GetProcAddress() - that's script kiddie talk. If SoE wanted to find you then they'd start with calling IsDebuggerPresent(). That'll probably weed out half of the attempts right there; or at least those that can't get/use SoftIce, write their own inter-process breakpoint/read/write memory app, kernel mode inspection API, or injection debugger.