3 ms·

This is really cool. You can also detect a debugger on windows by using one of the apis provided, such as IsDebuggerAttached, or is debuggerpresent. https://ms

This is really cool. You can also detect a debugger on windows by using one of the apis provided, such as IsDebuggerAttached, or is debuggerpresent. https://msdn.microsoft.com/en-us/library/windows/desktop/ms680345(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

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.)
badrabbit 9y ago
You can use those APIs but AV and dynamic sandbox analysis solutions look for samples that make decisions based on the return value of those functions.
- hypervis0r 9y ago
  Not really. The amount of samples that check for debuggers is surprisingly high, and thus makes such red flag unusable. It'd just spam false positives.

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.)

badrabbit 9y ago

You can use those APIs but AV and dynamic sandbox analysis solutions look for samples that make decisions based on the return value of those functions.

hypervis0r 9y ago
Not really. The amount of samples that check for debuggers is surprisingly high, and thus makes such red flag unusable. It'd just spam false positives.