The winter break is a strange stretch of time. Long enough to start something, short enough that any project bigger than a weekend stalls somewhere around day four. So here is a format that fits: twelve small reverse engineering puzzles, one per day, each solvable in twenty to forty minutes with tools you already have. No scoreboard, no flags, no write-ups to compare against. Just a binary, one question, and a notebook.
Each day has exactly one goal: read a byte you could not read yesterday, change a byte on purpose, or watch a byte change under a debugger.
Before Day One: Build a Small Toolkit
You do not need much, and you should resist installing everything. Six utilities cover all twelve days.
- xxd or hexdump -C for raw byte views, plus od when you need a specific width.
- file for the first thirty seconds of every day: format, architecture, stripped or not, statically or dynamically linked.
- strings, ideally with -t x so every string arrives with a file offset attached. That offset is the thread you pull on.
- objdump for disassembly, plus readelf on Linux or otool on macOS for section headers and symbol tables.
- gdb or lldb for breakpoints, single-stepping, and reading registers at the exact moment a decision is made.
- A hex editor you can type into — ImHex, HxD, or a terminal-based one — because viewing bytes and editing bytes are different skills.
Add one item that is not a utility at all: a plain text notebook. Every day, write down the file's hash, the command that worked, the offset you found, and the single sentence that explains why it worked. Twelve days is a few dozen lines of notes, and by the end those notes are worth more than the binaries.
Set up one directory per day before you start, and keep the original binary untouched while you work on a copy. You will break things on purpose, and you want to be able to start over without downloading anything again.
How the Twelve Days Are Shaped
The sequence matters more than the individual puzzles. It moves from looking, to touching, to watching, and each phase hands you the vocabulary for the next one.
Days 1–4: Reading
Nothing is modified. You are learning to answer questions with static tools alone: what is this file, what does it say, where does execution begin, which bytes are code and which are data. The goal is to make objdump output boring — to look at twenty lines of assembly and see a shape instead of noise.
Days 5–8: Changing
This is where the challenge earns its name. You flip a conditional jump, rewrite a string, replace a call with a no-op, and edit a hardcoded constant. The lesson is not just that patching works, but how fragile it is: change one byte and a checksum fails, a length field disagrees with its payload, or the program walks off the end of a buffer.
Days 9–12: Watching
The last four days move into the debugger. A breakpoint at main, then one on the instruction that actually makes the decision, then a watchpoint on a value you want to see change. You already know what the bytes say. Now you watch them execute, and the two views finally line up.
Static analysis tells you what could happen. Dynamic analysis tells you what did. Neither one is complete alone, and the gap between them is where the interesting bugs live.
The Twelve Days, In Outline
- Identify. Run file and strings -t x, then write one paragraph guessing what the program does without running it.
- Find the message. Locate a string's offset, then find the instruction that loads its address.
- Map a struct. Dump 256 bytes and annotate them by hand, marking every field you can guess or confirm.
- Walk to main. Start at the entry point and follow the call chain until you land in user code.
- Flip a jump. Patch one conditional branch so the program takes the path it was designed to avoid.
- Rewrite a string. Change a message without changing its length, then change the length and watch the rules break.
- NOP a call. Replace a call instruction with no-ops and observe what falls apart downstream.
- Hunt a constant. Find a hardcoded comparison value, change it, and explain why the change worked.
- Break at main. Attach a debugger, set a breakpoint, and read the arguments and registers.
- Break at the branch. Set a breakpoint on the exact instruction that decides your fate, then step through it.
- Watch a byte. Put a watchpoint on a variable and log every write along with its backtrace.
- Explain from memory. Close everything and write a one-page map of an unfamiliar binary, then compare it to day one's guess.
One Worked Day: Patching a Single Jump
Here is what day five looks like in practice, so you know roughly how much time to budget. Run strings -t x and find the failure message — say, access denied. Note its offset. Now open the binary with objdump -d and search the disassembly for that offset appearing as an address being loaded, usually through lea or a mov of a computed address into a register.
A few lines above, you will typically find the pattern: a cmp, then a conditional jump that skips the success path. In a common x86 build that jump might be 0x74 (jump if equal) where you want 0x75 (jump if not equal), or the reverse. One byte, patched in a hex editor.
Do not patch and run blindly. Write the predicted result in your notebook first: the offset, the old byte, the new byte, and what you expect to see. A prediction you can be wrong about is the whole point of the exercise.
Then run it. If you were right, write one sentence about why. If you were wrong, that reason is your lesson for the day, and it is worth more than the correct patch would have been.
Rules That Keep It Sustainable
- Forty minutes, hard stop. A timer turns a puzzle into a daily habit. Without one, day nine quietly becomes days nine through fifteen.
- One question per day. If you stumble onto something else interesting, write it down and save it for tomorrow.
- Notes before tools. Predict first, then run. The notebook catches the assumptions that static analysis quietly encourages.
- No write-ups. You are not publishing, ranking, or comparing. The notes are for the version of you who starts day ten having forgotten day three.
- Binary stays in the sandbox. Only run what you built or deliberately downloaded, and only in a directory you do not mind breaking.
Why Twelve Small Days Beat One Big Project
A large reversing project has a long middle: hours where you understand less than you did at the start, before anything clicks. Twelve small puzzles invert that ratio. Each day ends with a complete, verified answer, which is the thing that actually keeps a habit alive during a break full of other obligations.
And the tools compound. By day twelve you have read a struct, walked from the entry point to main, patched a branch, watched a variable change, and explained a binary from memory. That is the same loop professionals run, just scaled down to a length that fits between lunch and a walk outside.
Keep the binaries. Keep the notebook. In twelve months you will have a small archive of puzzles you half-remember, which is a far better position than having nothing at all.
Photo: NHP&Co / Pexels
