Description
A binary license-key validator builds the correct key at runtime using MD5 hashes and string operations. Rather than reversing every step by hand, run the binary in GDB and read the fully assembled key directly from memory after the program has computed it.
Setup
Download the binary and make it executable.
Open in Ghidra to understand the structure, then run in GDB on the picoCTF web shell to extract the key dynamically.
wget https://artifacts.picoctf.net/c/244/keygenme && chmod +x keygenmegdb keygenmeSolution
Walk me through it- Step 1Find the key assembly point in GhidraOpen the binary in Ghidra, run auto-analysis, and browse to the license-check function. Look for the call to strlen (which fires once the key string is complete). That call site is a good breakpoint because the full key lives in memory at rbp-0x30 at that moment.
Learn more
Ghidra decompiles the key-check function and shows the sequence of MD5 calls and sprintf operations that assemble the expected license key. The decompiler output reveals that the assembled string is stored at a local variable corresponding to
rbp-0x30on the stack frame.You do not need to understand every MD5 computation. The goal is to find the address where the string is complete so you can break there in a debugger and read the value directly from memory.
- Step 2Break after key assembly in GDB and read the flagStart the binary under GDB. It loads into libc_start_main initially with no main symbol defined. Use
info address mainor step through entry to find main's address, then set a breakpoint just after the strlen call where the key is complete. Examine the string at $rbp-0x30 to read the flag.bashgdb keygenmebash# GDB session:bashrunbash# After it prints the prompt and pauses, break on the check function:bashinfo functionsbash# Set breakpoint at the strlen call site (address from Ghidra):bashbreak *0x<ADDRESS_FROM_GHIDRA>bashcontinuebash# Enter any license key when prompted (it will not matter)bashx/s $rbp-0x30Learn more
The binary calculates the correct license key at runtime and stores it in a stack buffer. GDB's
x/s $rbp-0x30command dereferences the address and prints it as a null-terminated string. Because the key is built before any comparison with user input, you can provide a dummy key to get past the prompt, hit the breakpoint, and read the real key.This dynamic approach works for any validator that builds the expected value at runtime - even if the algorithm is a one-way hash chain that cannot be inverted analytically. As long as the program computes the answer to compare against, a debugger can intercept it.
On the picoCTF web shell, GDB is pre-installed. Run
gdb ./keygenme, then userunto start. If the binary has nomainsymbol, break on__libc_start_mainfirst, step through to find main, then set your real breakpoint. - Step 3Submit the keyRun the binary normally and paste the key read from GDB. The validator accepts it and prints the flag.bash
./keygenmebash# Enter the key from GDB output: picoCTF{br1ng_y0ur_0wn_k3y_...}Learn more
The key is the flag itself formatted as
picoCTF{bring_your_own_key_...}. After entering it, the binary prints a success message confirming the flag.The key insight from this challenge: dynamic analysis with GDB often bypasses the need to fully reverse-engineer a complex algorithm. If the program needs to know the right answer to compare against, the right answer is somewhere in memory right before the comparison happens.
Flag
picoCTF{br1ng_y0ur_0wn_k3y_...}
Use GDB to break after the key-assembly code and read the expected key directly from the stack at rbp-0x30. No MD5 reversal needed.