GREGO GUARD / RESEARCH REPORT · NOVEMBER 2026
CrackMe 01 — Binary Reverse Engineering
Scope and objective
Research was performed on a purpose-built, locally owned Windows x64 CrackMe in an isolated virtual machine. The goal was to understand a client-side input check and perform a minimal binary patch without modifying the original sample.
Analysis and evidence
Ghidra identified the validator at FUN_140001220, which transformed an eight-character activation code using per-byte XOR and addition. The valid activation code recovered through algorithmic reversal was Q7M-42PX. The unmodified executable displayed RE-LAB{FIRST_BINARY_UNLOCK} upon successful activation.
In x64dbg, the relevant branch followed TEST EAX,EAX and JNE. On invalid input EAX=0, and the branch was not taken. A working copy changed the conditional-jump opcode from 75 to EB at file offset 0x585, leaving the length unchanged at 3,584 bytes.
Verification
The modified executable displayed the unlocked message on invalid input. Byte-by-byte comparison found exactly one modified byte.
| Binary | SHA-256 |
|---|---|
| Original | E88048B6B24D9D96E2B2119E0518D19DEB4F4F573C3A2B156DDE24085F2CF7EE |
| Modified | 68DBC6C3A4C7CD63E136FDDF4C1329CA819F7AF4E092A17E25D79879C38A9B04 |
Implication
A decision controlled exclusively by a locally patchable client binary is not a robust authorization boundary. This lab demonstrates conditional-branch analysis and patch verification; it is not a finding against a third-party product.