Reputation: 7168
Can you detect whether or not a debugger is attached to your native Windows process by using a high precision timer to time how long it takes to divide an integer by zero?
The rationale is that if no debugger is attached, you get a hard fault, which is handled by hardware and is very fast. If a debugger is attached, you instead get a soft fault, which is percolated up to the OS and eventually the debugger. This is relatively slow.
Upvotes: 9
Views: 1034
Reputation: 26171
most debuggers used by reverse engineers come with methods to affect (remove) 99% of the marks left by debuggers, most of these debuggers provided exception filtering, meaning the speed difference would be undetectable.
its more productive to prevent the debugger attaching in the first place, but in the long run you'll never come out ahead unless you make the required effort investment unfeasable.
Upvotes: 2
Reputation: 54624
No. A sufficiently determined attacker would simply host your process in a VM and break in that way.
Besides, you don't need to attach a debugger to attack a program: grabbing a minidump will let an adversary inspect the memory state offline, or using process explorer you can inspect open handles to determine what files are vulnerable.
If you were going to use an exception to determine whether a naive debugger were attached, I'd personally use INT_MIN/-1
to trigger an integer overflow exception. Most don't know about that one.
Upvotes: 3
Reputation: 34587
Since there is absolutely nothing you can do to prevent a determined person from reverse engineering your code, no clever approach you find will be significantly better than calling IsDebuggerPresent()
Upvotes: 4