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