4 ms·

Debugger can trap calls into that and return whatever it wants, also this API only returns true for user-mode debuggers. Point of most anti-debugging measures

by dfox 9y ago

Debugger can trap calls into that and return whatever it wants, also this API only returns true for user-mode debuggers. Point of most anti-debugging measures is to detect debuggers that are actively trying to hide their presence.

ravenstine 9y ago
Even with a user mode debugger, those APIs aren't hard to thwart in x86 Windows. I don't know if that's really still the case with newer architectures; the last version of Windows I used was Windows 7. https://stackoverflow.com/questions/10330147/how-do-i-bypass-isdebuggerpresent-with-ollydbg https://stackoverflow.com/questions/10330147/how-do-i-bypass... Even if that weren't the case, it's not a big feat to run a Windows program with a version of Kernel32.dll that has isdebuggerpresent as a no-op. If I recall correctly, you only needed to take those measures if you were trying to modify a program that extracted itself into memory where it would be particularly difficult to "debug". Otherwise you could create bypasses for those API calls using just a disassembler. My memory on this is pretty rusty, though. My guess is that API doesn't exist so much to discourage reverse engineering as it is to prevent certain code from executing if a debugger is being used legitimately, or to provide extra data to a debugger. It is(or at least was) used as a way to make reverse engineering difficult, but it's very ineffective.
- SteveJS 9y ago
  Yes, there are a bunch of legitimate use cases for large scale development where you want inline tools to assist QA and diagnostic issues. The Visual Studio codebase had (may have changed now) a dialog for debug asserts allowing you to suppress a single instance, suppress repeat instances of just that assert, or suppress all asserts, as well as a bunch of other features. I believe later versions of that macro made use of IsDebuggerPresent to change behavior when the process was being debugged or not. (I believe previous versions made use of a -different- hack to implement IsDebuggerPresent.)

by dfox 9y ago

ravenstine 9y ago

Even with a user mode debugger, those APIs aren't hard to thwart in x86 Windows. I don't know if that's really still the case with newer architectures; the last version of Windows I used was Windows 7. https://stackoverflow.com/questions/10330147/how-do-i-bypass-isdebuggerpresent-with-ollydbg https://stackoverflow.com/questions/10330147/how-do-i-bypass... Even if that weren't the case, it's not a big feat to run a Windows program with a version of Kernel32.dll that has isdebuggerpresent as a no-op. If I recall correctly, you only needed to take those measures if you were trying to modify a program that extracted itself into memory where it would be particularly difficult to "debug". Otherwise you could create bypasses for those API calls using just a disassembler. My memory on this is pretty rusty, though. My guess is that API doesn't exist so much to discourage reverse engineering as it is to prevent certain code from executing if a debugger is being used legitimately, or to provide extra data to a debugger. It is(or at least was) used as a way to make reverse engineering difficult, but it's very ineffective.

SteveJS 9y ago
Yes, there are a bunch of legitimate use cases for large scale development where you want inline tools to assist QA and diagnostic issues. The Visual Studio codebase had (may have changed now) a dialog for debug asserts allowing you to suppress a single instance, suppress repeat instances of just that assert, or suppress all asserts, as well as a bunch of other features. I believe later versions of that macro made use of IsDebuggerPresent to change behavior when the process was being debugged or not. (I believe previous versions made use of a -different- hack to implement IsDebuggerPresent.)