These programs are small inputs for the trace dump, trace Xref, and trace pattern-search features.
From this directory in Git Bash:
mkdir -p build
"/c/Program Files/LLVM/bin/clang.exe" -O0 -gcodeview -fuse-ld=lld -Xlinker -debug -Xlinker -dynamicbase:no -Xlinker -highentropyva:no -o build/trace_rc4.exe trace_rc4.c
"/c/Program Files/LLVM/bin/clang.exe" -O0 -gcodeview -fuse-ld=lld -Xlinker -debug -Xlinker -dynamicbase:no -Xlinker -highentropyva:no -o build/trace_overflow.exe trace_overflow.cThe linker flags -dynamicbase:no -highentropyva:no are the lld-link equivalents of /DYNAMICBASE:NO /HIGHENTROPYVA:NO. They keep module addresses stable across runs.
The examples export marker functions for convenient breakpoints. trace_rc4.exe uses trace_begin and trace_end. trace_overflow.exe uses only trace_begin; the access violation stops the trace.
Correct serial:
x64dbg{trace-memory}
Suggested run:
trace_rc4.exe wrongTrace workflow:
- Open
trace_rc4.exein x64dbg. - Set the command line to
trace_rc4.exe wrongif needed. - Open the Symbols view for the main module.
- Set breakpoints on the exported functions
trace_beginandtrace_end. - Run to
trace_begin. - Start
Trace intofromtrace_begin. - The trace stops when
trace_endis reached. - Open the Trace view, select the last traced instruction, and load the trace dump if x64dbg has not loaded it automatically.
Things to show:
- The console prints the stack addresses of
Sandexpected. - In the trace dump, go to the
expectedaddress and step through the trace rows aroundrc4_crypt; the buffer changes into the plaintext serial. - Search the trace dump for this ASCII pattern:
78 36 34 64 62 67 7B
That is the byte pattern for x64dbg{. It is not stored as plaintext in the program; it appears only after the RC4 decrypt loop writes it.
- Search for this RC4 initialization pattern:
00 01 02 03 04 05 06 07
The result points at the temporary S[256] table created during rc4_init.
- Select a byte in the
expectedbuffer and use the trace dumpXrefaction. The useful references are the RC4 write, the compare read, and the wipe write.
Trace workflow:
- Open
trace_overflow.exein x64dbg. - Set a breakpoint on the exported function
trace_begin. - Run to
trace_begin. - Start
Trace intofromtrace_begin. Set the max trace count to100000if x64dbg asks. - The trace stops on the access violation caused by
call_callback. - Open the Trace view, select the last trace row, and load the trace dump if needed.
Things to show:
- The console prints the addresses of
overflow,greeting, and thecallbackfield. - The crash happens because
g_arena.callbackwas overwritten with43 43 43 43 43 43 43 43, the ASCII bytes forCCCCCCCC. - In the trace dump, go to the printed
callbackfield address, select the first byte, and use the trace dumpXrefaction. - Jump to the last write before the crash. It lands inside
copy_unbounded(g_arena.overflow, ...), after the copy has crossed the end ofoverflow. - Repeat the same action on the printed
greetingaddress. Its bytes changed togreeting_is_gone, showing that the same overflow corrupted neighboring data before it corrupted the function pointer.
This is the cleanest motivating example for trace Xref: it answers "who last wrote the byte that caused this crash?" without needing a hardware breakpoint before the bug happens.