Printable View
Good afternoon =]
Does anyone know a good way to prevent another program from suspending my program? Programs like OllyDbg and IDA can 'pause' the process and dissassemble it with no problem and therefor my program stops working in their tracks. Any way to prevent these types of programs accessing my program? I thought maybe setting ResumeThread on a timer would be of help, but maybe not so much.
I'm using MSVC++ 6 with a Win32 console app.
I'm pretty sure that ResumeThread won't help you, becuase the debugger is highly likely to use the debug interface, and ResumeThread only resumes threads that have been suspended with the corresponding SuspendThread function.
You may be able to detect that there is a debugger running in the system, but realisticly, that would just be an "arms-war", meaning that whatever you prevent, someone will find a way past it.
--
Mats
Your program seems pretty important to need to do that, you could always hook the debug functions. :D
I wrote this up real fast, but didn't test it yet. Would this be a proper way of hooking and checking if something is debugging your process? Don't pound on me too hard =p
Code:#include <windows.h>
#include <iostream>
typedef BOOL (WINAPI* _IsDebuggerPresent)(VOID);
HINSTANCE hKernal32Lib;
BOOL idb = FALSE;
_IsDebuggerPresent t_IsDebuggerPresent;
void main(void){
hKernal32Lib = LoadLibrary("Kernal32");
t_IsDebuggerPresent = (_IsDebuggerPresent )GetProcAddress(hKernal32Lib, "IsDebuggerPresent");
while(1)
{
idb = t_IsDebuggerPresent();
if(idb)
{
std::cout << "Present" << std::endl;
}
else
{
std::cout << "Not Present" << std::endl;
}
}
}
It definitely won't detect a debugger working down on Ring 0 such as Soft Ice
I know someone who "hacked" the kernel's "IsDebuggerPresent()" to always return false to avoid that sort of thing - this was for a commercial project were we needed to debug another component that got used BY this application, and of course, the application would just bail out when you started it with the debugger.
As I said, it becomes an arms race. You invent something, the other guys do something "better", and you have to come up with something even better. And the guys that try to break applications usually have much more time than the commercial developers care to throw at it.
--
Mats
Thanks for the infos...just wondering..to detect debuggers running in ring 0, does my application have to also be running in ring 0? I know it gets complicated from there...but I just need a simple way to catch programs like OllyDbg, IDA, ProcessExplorer, etc. My app isn't going to be that important to the world but I just wanted to make some extra precautions and learn from it and hopefully use this info/method/coding in the future.
Edit: Did I hook correctly in my code above?
The above is not a "hook", it's just a API call via GetProcAddress().
I don't think you can detect debuggers running in Ring 0 [unless you want to check for DLL's loaded in kernel-space].
--
Mats
Even ring3 debuggers bypass IsDebuggerPresent() usually.
Silentkarma, making your app run in ring0 is a BAD idea, trust me. ;) Plus it will take you alot of time to get used to low-level interface and driver structure. It's certainly an overkill.
I have tried to do a sytem-wide hook for OpenProcess and CreateProcess once (so other applications wouldn't be able to open my process). It was for an anticheat system. But I never included it in the final product since I thought this behaviour is not acceptable even for an anticheat system. At least I had fun building it. :)
It is no longer an application if it runs in ring 0. It is a kernel driver or some such.Quote:
Originally Posted by maxorator
--
Mats
Details, details, details. :DQuote:
Originally Posted by matsp
Generally kernel mode drivers are a mess. Inexperienced use of ring0 will likely end up with BSODs (I only did it once though :D ).
Even with experience, you do occassionally hit a BSOD if you spend enough time in driver code... Guess how I know that... ;-)Quote:
Originally Posted by maxorator
--
Mats
There are plenty of available debugger obfuscation techniques. Have you ever tried running a buggy program in a debugger, only for the bug to go away? You can take advantage of that sort of thing to cause things to go haywire if someone tried to debug your program.
It does make it an order of magnitude more difficult, though, which reduces the pool of people in the world who could potentially do it. You can delay the breaking of the dam but you can't stop it.Quote:
Originally Posted by matsp
Many debuggers have built-in antiantidebuggers, so it doesn't usually need experienced people to get bypassed...Quote:
Originally Posted by brewbuck
Well that would just be a lack of cleverness.Quote:
Originally Posted by maxorator
Here is a link to a botnet tracking white paper. About halfway down the paper is a link to some source code examples illustrating how botnets detect the presence of a debugger.