When I use the right-click context menu, I get "You'll need a new app to open this kind of file .exe", and when I run it from cmd I get:

PIN is trying to run the app:
"D:\ProjectsHell\IntelPIN\pin-3.20\pin.exe"
The system cannot execute the specified program.
Disable Kernel Mode Debugger before running the PIN tool!

I've checked that pin tool works (it can run say, icount) and that kernel mode debugger is disabled by bcdedit.

Test case

• b9ee0ab292030c1d31f57e551e73e23300b84e30a874ef97984563700c994e8c

Issue

When dumping of the parameters is selected, produced trace is incomplete.

Using the default params.txt:

kernel32;LoadLibraryW;1
kernel32;LoadLibraryA;1
kernel32;GetProcAddress;2
advapi32;RegQueryValueW;3
kernel32;CreateFileW;6

The end of the tracelog:

17710;msvcrt.__iob_func
17610;msvcrt.fflush
15492;kernel32.GetCurrentProcess
d479;kernel32.LoadLibraryA

When LoadLibraryA was removed from params.txt, the tracelog continues. Example:

175f0;msvcrt.fwrite
17710;msvcrt.__iob_func
17610;msvcrt.fflush
15492;kernel32.GetCurrentProcess
d479;kernel32.LoadLibraryA
d480;kernel32.GetProcAddress
13ad8;called: ?? [15440000+5c]
> 15440000+6e;SYSCALL:0x50(NtProtectVirtualMemory)
> 15440000+70;nim.[unnamedImageEntryPoint+125ee]*
13b09;called: ?? [15440000+2e]
[...]

Possible crash on dumping parameters of LoadLibraryA.

I found tiny_tracer not work on golang program:

pin.log

Pin: pin-3.28-98749-6643ecee5
Copyright 2002-2023 Intel Corporation.
E:  UPC Dispatcher: Unhandled internal exception in Pin or tool. ThreadId = 0 SysThreadId = 16336. Interruption context: IP: 0x05e8a9ef3 SP: 0x264f253c310. Exception Code: RECEIVED_ACCESS_FAULT. Exception Address = 0x05e8a9ef3. Access Type: READ. Access Address = 0x00005e2fc. ExceptionFlags: 0x000000000

Question

Hello!

Is there a way to get a track dump from just a DLL file specificly?

Also thanks for all the great tools, they really help me out!

Excluded 0 functions
Watch 0 functions
Watch 0 syscalls
SyscallTable size: 1589
===============================================
This application is instrumented by TinyTracer v.2.7.1
Tracing module: G:\PR\Compiled_IntelPt\gtnszz.exe
See file G:\PR\Compiled_IntelPt\gtnszz.exe.tag for analysis results
===============================================
E: G:\FL\TRACER\tiny_tracer-2.7.1\TinyTracer.cpp:750: Cannot use IARG_BRANCH_TARGET_ADDR with instruction at 0xb1fd7f: jmp far 0xb59fc7, 0x33
E:  check that INS_IsControlFlow is true

Windows ver ; Windows 10 1607
İntel Pin : 3.26

Tracer.ini

ENABLE_SHORT_LOGGING=True
USE_DEBUG_SYMBOLS=False
FOLLOW_SHELLCODES=1
;FOLLOW_SHELLCODES:
; 0 : trace only the main target module
; 1 : follow only the first shellcode called from the main module
; 2 : follow also the shellcodes called recursively from the the original shellcode
; 3 : follow any shellcodes
TRACE_RDTSC=False
TRACE_INT=False
TRACE_SYSCALL=True
LOG_SECTIONS_TRANSITIONS=True
LOG_SHELLCODES_TRANSITIONS=True
HEXDUMP_SIZE=8
HOOK_SLEEP=False
SLEEP_TIME=10
; ANTIDEBUG: (Windows only)
; 0 : Disabled
; 1 : Standard
; 2 : Deep (may lead to some false positives)
ANTIDEBUG=1
ANTIVM=0

I've followed the instructions, but whenever I try run an exe file with tiny_tracer i get prompted that i need a new app to open the result. I've tried selecting notepad.exe and instead of tracing the API calls it's dumping the exe
I've made sure my pin install dir is C:\pin, put the compiled dlls in the install32_64 dir, and all
Maybe I'm missing something, but i'm pretty sure i've followed all the steps carefuly.

Cheers!

I think it will be more friendly to other developers

Tracy kernel callstack is invalid.

i know this problem was discussed before , but i tried the solutions provided and it didn't fix the problem.
KDB check output is : KDB: Disabled
AV is disabled
running using run me bat gives
run_me.bat "C:\Users\ELJoOker\Downloads\you_bee_ex (1).exe" exe PIN is trying to run the app: "C:\Users\ELJoOker\Downloads\you_bee_ex (1).exe" The system cannot find the path specified. Target module: "C:\Users\ELJoOker\Downloads\you_bee_ex (1).exe" Tag file: "C:\Users\ELJoOker\Downloads\you_bee_ex (1).exe.tag" E: [tid:26508] Invalid tool DLL name : C:\pin\source\tools\tiny_tracer\install32_64\TinyTracer32.dll Press any key to continue . . .
pin file is in default location C:\\pin and compiled using VS 2022 using Pin 3.30

Pin v3.28, tiny_tracer v2.6
I don't know if this is new code of tiny_tracer or new feature of Pin v3.28.
When the environment variable _NT_SYMBOL_PATH is set, and I have long since set it, the tiny_tracer (or Pin v3.28) will path and display the function name according to the debug symbol files (.pdb/.xxx).
So the functions I define in params.txt don't match.
I was forced to delete (temporarily rename) this _NT_SYMBOL_PATH environment variable.
Previous versions of Pin and tiny_tracer do not have this problem.
Below is a screenshot of an example.

And after turn off _NT_SYMBOL_PATH, it run OK

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.

Hey, it would be really nice if you can implement faster tracing, of course it will use more system memory and stuff but its worth it lol because tracing does take some time. And maybe tracing only specific sections like .text .data so on.

Hi, I was trying to check the syscalls of a malware sample protected with vmprotect and noticed that the execution stops before reaching the payload. (the malware does not run and no error message is displayed)

Doing other tests (with the demo version of vmprotect and a test payload) I realized that the problem is only related to the vmprotect debugger flag, without the flag the test payload is executed and traced.

Do you know of a way around this problem?

Hi, i have a program which is using the INT2D for anti debug. And while running tiny_tracer under the application i confirmed its INT2D anti debug.... Is there any workaround to this? Thanks. EDITED (I saw the hide branch, but it seems so the INT2D flag is not cleared.)

The current toolchain is rather cumbersome and manual. Since tiny_tracer only targets Windows, the toolchain could be moved into a Visual Studio Solution outside of the Pin directory. I can make a pull request later as a proposal of how it might look like.

Doing this could also move the compilation of the helper binaries: dll_load32.exe, dll_load64.exe, kdb_check.exe, pe_check.exe, into the Visual Studio Solution.

Somewhat related, is there a reason for using pe_check instead of PINTOOL's -t and -t64 options?

Hey, i see you needed some help identifying them VMProtects Anti Debug in issue #26, so heres the resources i collected, hope it helps.
Blog 1 - https://www.researchgate.net/figure/A-program-that-has-applied-VMProtect-anti-VM-and-anti-debugging-options-is-terminated_fig12_348166976 - If you dont want to read all of it go to Page 9 that where he starts talking about VMProtect. Not so sure which version.
Blog 2 -https://cyber.wtf/ - VMP 3.6

In

Good day, I was using tiny racer v 1.4. I was getting results without any issues

I updated to version 2.0 today Can analyze unpackaged programs nicely but software packaged with vmp keeps working forever.
I waited for 20 minutes, the pin is working in the background. The program runs in the background, but it never completes. So it never reaches the oep point.

779a61;section: [.vmp1]
82404d;kernel32.LocalAlloc
7972b0;kernel32.GetModuleHandleA
7972b0;kernel32.GetModuleHandleA
8b56e0;kernel32.GetModuleFileNameW
7df6d1;kernel32.LocalAlloc

Windows 10 1607
pin-3.20
i7 6700K
Visual Studio 2019 (v142)

Hi, I tried to this project
and make exe file, Visual studio 2015 with .NET framework 4.5.2 Build Realese x64 and x86

allowedly, I set C:pin, source\tools\tiny-tracer and so on, using your youtube tutorial.

but my exe file result is empty. here is example

output,out file is empty.

and I tried other project exe file, Visual studio project 2015 build with C++ win32 project Relases x64 and x86
the Result is good. I get output.out with API Called.

is this any issue using .NET framework exe file or any Requirement using this project?

and Thank you for using your good project.

Hi,

   I wonder whether tiny_tracker could be run in a command line way. In this way, I could provide the other necessary parameters.
   Thanks

Good day ! this is a very cool tool, I like how it displays information on CPUID intrusion, can I somehow modify tiny_tracer to receive output on each instruction (example: 0x11111;mov eax edx;eax=0x1000000, ebx=0x10000, ..... )?

Currently Tiny Tracer don't allow to filter what function to log, how do you think about this function?

We may need a seperated config file or put them in params.txt , something like:

Kernel32;LoadLibraryW;1
kernel32;LoadLibraryA;1
# KERNEL32;GetProcAddress <- do not log GetProcAddress 
# CreateEvent* <- pattern match

Hey!

Sorry if it is stupid question but how to run an executable file with PIN as Administrator?

I found some wrong RVA origin of calls traced in .tag. I found out that many traced api saved in .tag file have RVA origin in many assembler instructions (not call).. Like mov, push... So I can't figure it out where is problem... The code is not self modyfing and also not packed...
I used pin version 3.15, tiny tracer 1.3.2 and compiled it in Visual studio 2019. Tested on win7 Pro 64bit.
Tested sample: RemcosRAT - pass:infected (https://www105.zippyshare.com/v/FGP4Yhw5/file.html) ; dd488af61f792c89265fd783f3ec4a18

My sample calls CreateProcessInternalW to create a new process, is there a way track it without attaching a debugger or hooking the function?

In case if a function has parameter tracking enabled, but it is called from a shellcode that is not traced, its parameters are reported, but not the name.

Example:

5ed0d;called: ?? [ca83000+fa8]
6a78;ntdll.NtdllDefWindowProc_A
1ee5b;user32.[CallNextHookEx+b1]*
	Arg[0] = ptr 0x0ca837c4 -> "lVali"
	Arg[1] = 0x00000004 = 4
	Arg[2] = 0

	Arg[0] = ptr 0x00cc0004 -> {\x00\x00\x00\x00\x00\x00\x00\x00}
	Arg[1] = ptr 0x0dcc2a3c -> "https://[removed]"
	Arg[2] = 0
	Arg[3] = 0

	Arg[0] = ptr 0x00cc000c -> {\x00\x00\x00\x00\x00\x00\x00\x00}
	Arg[1] = 0x00000013 = 19
	Arg[2] = ptr 0x0ca86a14 -> {\x00\x00\x00\x00\x00\x00\x00\x00}
	Arg[3] = ptr 0x0ca86c1c -> {\x01\x02\x00\x00\x00\x00\x00\x00}

	Arg[0] = ptr 0x0ca83b4c -> "aswe"
	Arg[1] = 0
	Arg[2] = 0

Used settings:
TinyTracer.ini

ENABLE_SHORT_LOGGING=True
FOLLOW_SHELLCODES=1
;FOLLOW_SHELLCODES:
; 0 : trace only the main target module
; 1 : follow only the first shellcode called from the main module
; 2 : follow also the shellcodes called recursively from the the original shellcode
; 3 : follow any shellcodes
TRACE_RDTSC=False
LOG_SECTIONS_TRANSITIONS=True
LOG_SHELLCODES_TRANSITIONS=False
HEXDUMP_SIZE=8
HOOK_SLEEP=False
SLEEP_TIME=10
LOG_INDIRECT_CALLS=False

params.txt

wininet;InternetOpenA;3
wininet;InternetOpenUrlA;4

Sample:

• d0b854dcea72fd8db68478961d30c52ce1f3aa56ecb5589e3cacb496edb147ab

My sample uses ntdll routines, hence most string arguments are passing as UNICODE_STRINGs, like always, which show up as pointers which is not helpful.

I can't attach a debugger and inspect memory unfortunately. Actually I can inspect memory but I can't pause the process at a function call.

Another solution that I'm working on rn is just to inject a dll at start and hook the functions. But if tiny tracer could detect UNICODE_STRING args, that would be awesome.

I decided I wanted to try out Tiny Tracer on Linux and it worked very well with some of the binaries I tested with.

However, I was just wondering if it is possible to run a target binary with target arguments?

I.e: ./tiny_runner.sh <target binary> <target binary args>

I'm trying to use tiny trace to trace Nanodump (https://github.com/fortra) syscalls but with no success.

For example, I'm trying to trace NtCreateFile, used to write the dump on disk, using the following in params.txt:

ntdll;NtCreateFile;11
<SYSCALL>;0x55;11

My TinyTracer.ini has TRACE_SYSCALL=True:

ENABLE_SHORT_LOGGING=True
FOLLOW_SHELLCODES=1
;FOLLOW_SHELLCODES:
; 0 : trace only the main target module
; 1 : follow only the first shellcode called from the main module
; 2 : follow also the shellcodes called recursively from the the original shellcode
; 3 : follow any shellcodes
TRACE_RDTSC=False
TRACE_SYSCALL=True
LOG_SECTIONS_TRANSITIONS=True
LOG_SHELLCODES_TRANSITIONS=True
HEXDUMP_SIZE=8
HOOK_SLEEP=False
SLEEP_TIME=10
LOG_INDIRECT_CALLS=False

When running nanodump, the nanodump.x64.exe.tag file does not seem to be tracing the syscall:

54be;kernel32.HeapFree
54a6;kernel32.GetProcessHeap
54be;kernel32.HeapFree
9722;ntdll.[ZwCreateFile+12]*
9779;ntdll.[NtWriteFile+12]*
94b8;ntdll.[NtClose+12]*
13800;msvcrt.strrchr
13a30;msvcrt.__iob_func
13878;msvcrt.fprintf

I'm probably doing something wrong. Could you give me some hints?

Thanks in advance!

Hi,

I would like to highlight a build issue with Intel Pin 3.19, Windows version. Though you have mentioned in the installation guide that it was tested against 3.16, I thought that it would be a good idea to let you know the build issue I faced for Intel Pin 3.19.

It seems that for Intel Pin 3.19, they have removed the pinvm.lib from %pin_root%\ia32\lib directory, resulting in a build error.

I have tested against version 3.16 to 3.18, and building is successful for all those versions in that range.

I am using tiny tracer when I encounter a problem where if the problem use seh exception for anti-debug but tiny tracer is also effect by it, the result in the end will look like this:

<random rva>;ntdll.KiUserExceptionDispatcher
<random rva>;ntdll.[RtlInterlockedCompareExhange64+1e2]*

The main reason I can think of is because tiny tracer doesn't run the exception part. The SEH exception look like this:

Is there anyway to keep tracing SEH exception?

VMPTest.vmp.zip - Test executable. With the AntiVM preset enabled. VMP Demo 3.7.3, you will need to compile the source on your PC since the demo has HWID-Lock.

VMPTest.vmp.exe.tag.zip - Trace of the protected test executable, with the AntiVM preset.

VMPTest.zip - Plain EXE (No Protection)

TinyTracer.ini ↓

ENABLE_SHORT_LOGGING=True
USE_DEBUG_SYMBOLS=False
FOLLOW_SHELLCODES=1
;FOLLOW_SHELLCODES:
; 0 : trace only the main target module
; 1 : follow only the first shellcode called from the main module
; 2 : follow also the shellcodes called recursively from the the original shellcode
; 3 : follow any shellcodes
TRACE_RDTSC=False
TRACE_INT=False
TRACE_SYSCALL=False
LOG_SECTIONS_TRANSITIONS=True
LOG_SHELLCODES_TRANSITIONS=True
HEXDUMP_SIZE=8
HOOK_SLEEP=False
SLEEP_TIME=10
; ANTIDEBUG: (Windows only)
; 0 : Disabled
; 1 : Standard
; 2 : Deep (may lead to some false positives)
ANTIDEBUG=1
ANTIVM=0

There is an issue with a tiny tracer currently related to VMProtect. The issue is that when AntiVM is enabled and under the tiny tracer, VMProtect throws an error that says "Sorry this application cannot run under a Virtual Machine.", I'm not on a VM. So I don't know why it's throwing that error while running under a tiny tracer. I suppose the newest tiny tracer update has something to do with this happening. Based on the "Trap Flag". But I'm not so sure.

Regards Dynamic.

can it be monitored, for x64 call under wow64?

maybe like this

...;called: C:\Windows\SysWOW64\ntdll.NtQueryInformationProcess
... // Wow64Transition
...;called: C:\Windows\System32\ntdll.NtQueryInformationProcess

for some use wow64ext, it may be better.