$ cat writeup.md…
$ cat writeup.md…
HackTheBox
Task: PE32 Windows binary with anti-debug protections. Solution: Bypassed PEB and RDTSC anti-debug checks, analyzed XOR self-modifying code to statically extract the flag.
$ cat /etc/rate-limit
Rate limit reached (20 reads/hour per IP). Showing preview only — full content returns at the next hour roll-over.
A developer is experimenting with different ways to protect their software. They have sent in a windows binary that is supposed to be super secure and really hard to debug. Debug and see if you can find the flag.
Files:
debugme.exe - PE32 executable (console) Intel 80386, for MS Windows (MinGW compiled, 81377 bytes)file debugme.exe # PE32 executable (console) Intel 80386, for MS Windows strings debugme.exe | grep -i flag # "I heard you like bugs so I put bugs in your debugger so you can have bugs while you debug!!!" # "Seriously though try and find the flag, you will find it in your debugger!!!"
The binary contains DWARF debug sections (.debug_info, .debug_line, .debug_aranges, .debug_abbrev, .debug_frame, .debug_loc, .debug_ranges), compiled with GNU C 4.7.0 (MinGW).
Disassembly with objdump -d debugme.exe revealed a critical feature:
_main (0x401620) contains garbage/encoded data — many 0x5c (\) bytes, int3 instructions, unreadable code_mainCRTStartup (0x4010f9) starts with jmp 0x408904 — jump to __DTOR_LIST__+0x1c sectionThis means the real entry point is 0x408904, not the standard CRT startup.
The code in __DTOR_LIST__ performs three checks:
fs:[0x30]+0x02 (debugger flag)fs:[0x30]+0x68 (debug heap flags)rdtsc calls, if difference > 1000 cycles — debugger detectedIf all checks pass:
0x5C_main function from what appeared to be garbage0x5C (\) bytes in encoded data is the XOR key visible in encrypted form...
$ grep --similar