Hey @hasherezade

I'm opening this as an Issue even if it's not a real one, but it's more to start a conversation :-).

First of all let me thank you for the great tools you are creating for all of us, they are awesome!

Then, coming to my "Issue". I used TinyTracer for a while and I found it very useful. I had a use case which was not entirely covered, which was the following: sometimes, in order to carry on dynamic analysis on malware samples, I'd like to identify where antidebug tricks are placed, so that I can patch them out and continue with my work.

So, I started to implement this kind of "flagging" by using TinyTracer as a starting point. Right now I'm just at the beginning of this, but I already have something functional. You can have a look to the fork if you want (https://github.com/cecio/tiny_tracer).

What I did so far is to start to implement various techniques (mainly from the well known https://anti-debug.checkpoint.com, but then also from few others) and add a line in the TinyTracer output when one if found ([ANTIDEBUG] is the tag I used for these messages).
I tried to keep my code as much as possible isolated from the main core (files AntiDebug.cpp and AntiDebug.h) and I put it under a specific option of the INI file (because is going for sure to impact performance)

I'm currently focused on two aspect:

• antidebug API usage
• memory access monitoring for antidebug tricks

Some sample output looks like this:

[ANTIDEBUG] --> PEB!BeingDebugged accessed at 0x135d
1038;ucrtbase.__acrt_iob_func
1057;ucrtbase.__stdio_common_vfprintf
[ANTIDEBUG] --> PEB!NtGlobalFlag  accessed at 0x1384
1038;ucrtbase.__acrt_iob_func
1057;ucrtbase.__stdio_common_vfprintf
13a8;kernel32.GetCurrentProcess
13b5;kernel32.IsWow64Process
2302;vcruntime140.memset
10c5;ntdll.VerSetConditionMask
10d4;ntdll.VerSetConditionMask
10e3;ntdll.VerSetConditionMask
1105;kernel32.VerifyVersionInfoW
2302;vcruntime140.memset
10c5;ntdll.VerSetConditionMask
10d4;ntdll.VerSetConditionMask
10e3;ntdll.VerSetConditionMask
1105;kernel32.VerifyVersionInfoW
[ANTIDEBUG] --> Heap Flags accessed at 0x13f3 https://anti-debug.checkpoint.com/techniques/debug-flags.html#manual-checks-heap-flags
[ANTIDEBUG] --> Heap Flags accessed at 0x13fc https://anti-debug.checkpoint.com/techniques/debug-flags.html#manual-checks-heap-flags
1038;ucrtbase.__acrt_iob_func
1496;kernel32.GetModuleFileNameA
14bc;kernel32.CreateFileA
[ANTIDEBUG] --> https://anti-debug.checkpoint.com/techniques/object-handles.html#createfile 
CreateFileA:
    Arg[0] = ptr 0x000000f9300ff9c0 -> "C:\Temp\Antidebug2.exe"
    Arg[1] = 0x0000000080000000 = 2147483648
    Arg[2] = 0
    Arg[3] = 0
    Arg[4] = 0x000000f900000003 = 1069446856707
    Arg[5] = 0x00007ff800000000 = 140703128616960
    Arg[6] = 0

1038;ucrtbase.__acrt_iob_func

For the time being, I fully implemented (for both 32 and 64 bit) the "Debug Flags" portion of the Checkpoint site and started to work on the "Object Handles". I'm at the beginning, but it's starting to take shape.

If you find this in some way usfeful, I'm more than happy to do a pull request. Obviously if you think it does not fit, or if you just don't want my crappy code in your repo, I totally understand you ;-) and I can keep this as a separated fork. And if you have any suggestion or advice on how to improve it, it's welcome!

Thanks a lot.