Defuse the Bomb

Whatever you type into the answer box is written straight into the machine's memory at the label answer, before the first instruction runs. Nothing else is done to it: it is not checked, cleaned up or converted. mov rax, [answer] then reads it back out, exactly like any other value sitting in memory.

That is what makes the whole thing readable. Your number is not tucked away somewhere private; it sits in a known place with a name on it, and every stage has to fetch it from there before it can test it. If you want to see that for yourself, open the debugger and type x/1 answer, which prints what is in that slot right now. x is the debugger's examine command. It reads memory rather than registers. The number after the slash is how many values you want and the name after it is where to start. So x/1 answer asks for one value at answer, and x/16 table asks for sixteen in a row starting at table.

Working out what a program does without its source is called reverse engineering, and people do it for a living: to find out what malware is doing, to check whether a device is spying on its owner, to make an old file format readable again, to find security holes before someone else does.

The exercise here is a version of a famous university assignment that has been set for over twenty years, because it teaches the one habit that matters: read what the machine will actually do, rather than what you assume it does.

The lines starting with a dot are not instructions. They are directions to the assembler, the program that turns this text into the numbers a machine can run. .data means "what follows is values, not instructions", and .text means "back to instructions again". The machine never executes either line; by the time it starts running, both have already done their work and disappeared.

answer: .quad 0 sets aside one slot of memory, puts the name answer on it, and starts it holding zero. Quad is short for quad word, which is four 16-bit words, which is 64 bits, which is eight bytes, which is exactly the size of a register like rax. table: .quad 2, 10, 6 would set aside three such slots in a row. Anywhere you see a name with a colon after it in the .data part, that is a place in memory with a label on it, and the instructions below reach it by that name.

Every bomb in this course is built from a small set, so here they all are in one place to come back to. mov a, b puts b into a. add and sub add to and take away from the first thing named. inc adds one and dec takes one away. and is a bit operation, explained in Step 6 where it is used. push puts a value on the stack, an area of memory kept for values a program wants back shortly, and pop takes the top one back off. Values come back in the opposite order to the one they went on in. call runs the code at a label and comes back afterwards, and ret is the coming back.

The jumps all read the notes a cmp left behind about how its two values differed. jmp goes without asking. jne jumps when the two were not equal. jl, jle, jg and jge jump when the first was less than, less than or equal to, greater than, or greater than or equal to the second. jnz jumps when the last result was not zero, which after a comparison is the same test as jne. Every one of them either jumps or does nothing at all, and which of those two happens is the whole of what a stage decides.

The numbers down the left of the code are line numbers, and that is what break takes. break 9 stops the machine just before line 9 runs, without running it. Then run starts the stage and stops at your breakpoint, print rax shows what is in a register at that exact moment, step runs one single instruction, and continue carries on to the next breakpoint or to the end. One more is worth having. x examines memory rather than registers, so x/4 answer prints four values in a row starting at answer. That is how you read a table the code is using.

Type a command into the box and press Enter, or press one of the buttons under it, which type the command for you. help lists everything it takes and reset puts the stage back to the start. While it is stopped somewhere, the line it is stopped on and any breakpoints you set are marked in the code above, so you can always see where the machine is.

A comparison can take its second value from a register, from memory, or from the instruction itself. When the number is written into the instruction, as in cmp rax, 1729, it is called an immediate: it travels with the instruction and is not stored anywhere else. That is why nothing needs to fetch it first, and why it is sitting there in plain text for you to read.

It also changes what the debugger can do for you here. On this stage there is no register holding the wanted number, so printing registers only ever shows you your own guess coming back. Later stages work the number out into a register before comparing, and those are the ones where a breakpoint hands you the answer.

dec rcx is decrement. It takes one away from rcx, exactly as sub rcx, 1 would, and like every other piece of arithmetic it writes down facts about the answer in the flags. The flag that matters here is the zero flag, which is set when the answer came out exactly zero and clear otherwise.

jnz is jump if not zero, and it jumps when that flag is clear. So dec rcx followed by jnz top reads as: take one off the counter, and go round again unless the counter has just hit zero. That pair is the standard countdown loop. You will meet it constantly, because it does the counting and the testing in two instructions instead of three. It is the same jump as jne under a second name: both mean "the zero flag is clear" and an assembler accepts either spelling.

You do not have to be cleverer than the loop. The value it builds sits in a register just before the comparison, so a breakpoint on the comparison and one print hands you the answer without you working anything out.

This is not cheating, it is the technique. A real program's check might involve thousands of instructions, and nobody traces those by hand. You find the moment of decision, look at what is in front of it, and read the value off.

Real checks are rarely one comparison. They are a run of them, each jumping to failure, with the success case simply being what happens if you fall off the end without jumping.

So read them as a list of conditions that all have to hold at once. Write each one down as you find it, in ordinary arithmetic, and only then start solving. For this stage that comes out as: the two numbers add up to 20, and the first minus the second is 6. Two conditions on two numbers can always be cracked by trying, and here there are only ten pairs that add to 20, so start at 19 and 1 and walk down until the difference is right. There is a faster way that does not need any trying and the question below shows it, but the trying works and it never lets you down on a stage this size. Extracting the two conditions from the instructions is the part that is actually hard. You have already done it.

Look for a call whose target is the label the function itself starts at. Above it there will be a comparison and a jump: that is the case where it stops rather than calling again, and without one the program would never finish.

When a function calls itself twice with two different arguments and adds the two answers together, it is almost always building the Fibonacci numbers: 0, 1, 1, 2, 3, 5, 8, 13, 21, and so on, where each number is the two before it added up. That is exactly what the instructions say here, once you read them: the value it stops at is the argument itself, and everything above is two smaller calls with their results added. Spotting the shape is quicker than tracing it and a breakpoint will confirm your guess in one step, so guess first and check second.

The stack is an area of memory set aside for values a program wants back shortly, with one register, rsp, holding the address of its top. push rdi writes a copy of rdi there and moves that top mark on by one slot of eight bytes. pop rdi takes the top value off again and puts it back into rdi. Values come off in the opposite order to the one they went on in, which is the whole idea of it.

This stage needs it because there is only one rdi, and the function is about to call itself with a smaller number in it. So the outer call pushes its own copy of rdi, makes the inner call, and pops the copy back afterwards to carry on where it was. call uses the stack for the same reason: it pushes the address of the instruction to return to, and ret pops that address and goes there.

and is a bit operation. Every number in the machine is really a row of 64 bits, each one a 0 or a 1, and and lines two rows up and compares them place by place: the answer has a 1 only where both rows had a 1, and a 0 everywhere else. The number 15 written out as bits is a row of zeros with 1111 on the end, four ones in the bottom four places. Anding your number with 15 therefore keeps its bottom four bits exactly as they were and wipes everything above them to zero.

Keeping the bottom four bits is the same thing as taking the remainder after dividing by 16, so whatever you type, the index that actually reaches the table is a number from 0 to 15. Type 100 and it looks up index 4, because 100 divided by 16 leaves 4. That instruction is not decoration: it is the program making certain that a number you chose can never send it reading memory past the end of a sixteen-entry table. Programs mask like this constantly, and now you can read it when they do.

A label in the .data section is a name for a place in memory. Written on its own, as in mov rsi, table, it means the address of that place, so rsi ends up holding where the table begins and nothing that is inside it. Written inside square brackets, as in mov rax, [answer], it means the contents of that place, so rax ends up holding the value that is stored there. Same name, two entirely different things, and the brackets are the only signal.

This stage needs both. It wants the table's starting address in a register so it can do the index arithmetic [rsi+rax*8], which reads as "begin at rsi, go rax items along, each item eight bytes wide". And it wants the contents of your answer slots, so those are fetched with brackets. Mixing the two up is the most common mistake there is in reading assembly. It is also, one layer up, exactly what a pointer is: a number that says where something lives rather than what it is.

Forwards is easy: take the input, use it as an index, read the table, add it up. Backwards means finding which indexes produce the total that is wanted, and there may be several answers or none.

The way through is to write the table out as a plain list of index to value, then look for the combination you need. Sixteen entries is small enough to inspect by eye, which is why the stage uses sixteen. A real one might use two hundred and fifty-six, and the method would be identical.

jle is jump if less than or equal. This stage does cmp rdx, rbx and then jle boom, where rdx is the weight it has just looked up and rbx is the weight from the number before it. So it goes off if the new weight is smaller than the previous one, and it also goes off if the two are exactly the same. Surviving means every weight is greater than the one before it, with no ties allowed.

That is what strictly increasing means: each value larger than the last, and equal does not count. Had the author written jl instead of jle, equal values would have been fine and the rule would have been the looser "never goes down". One letter, two different puzzles, and no comment in the code to tell you which you are looking at. This is why the instruction has to be read rather than skimmed, and it is the kind of one-letter difference that real security holes are made of.

Everything so far has been answerable from the instructions. This one is not: the rule is in the instructions, and what satisfies the rule depends on a table of values sitting in the program's data. Change the data and the answer changes while the code stays identical.

This is worth meeting, because it is the normal case. Programs are code plus data, and a great deal of real reverse engineering is reading data structures rather than instructions. The debugger's x command is how you look at them.

Bigger, mostly. A real program is hundreds of thousands of instructions and the interesting check is four of them. Finding those four is the work, and it is done with searches, breakpoints on library functions, and watching which code runs when you change your input.

Some programs also fight back: they detect a debugger, scramble their own code until it runs, or check a secret on a server where you cannot reach it. That last one is the only defence in the list that actually works, and the reason is Step 3: if the check happens on your machine, the thing being checked against is on your machine.

A file offset counts bytes from the start of the file. A virtual address names where the loader intends a byte to appear in a process. Alignment, unmapped gaps and zero-filled regions mean the two numbers need not match. Tools normally show both. Use the address column when following a running process and the offset column when inspecting or patching bytes on disk.

PIE and ASLR add a load base at runtime, so an instruction's absolute address can change between runs. Its offset within the module stays useful. The linking and loader stages are introduced in Assembly & Debugging, Step 14.

An import says this file expects another module to provide a symbol. An export offers one. Relocation records identify instruction or data fields that need an address fixed later. Even when function names are stripped, an imported strcmp, malloc or connect still tells you what kind of work happens nearby.

Indirect calls need more care. The target may come from a virtual-method table, callback field, dynamic import table or computed jump table. List the values that can reach the target register rather than assigning one guessed destination.

A computed jump or return does not spell its target in the instruction. Static analysis estimates possible targets from tables and data flow. Dynamic tracing shows the edge taken in one run, not every edge that could be taken. Mark an unresolved indirect edge explicitly instead of silently deleting it.

Exceptions, signals and long jumps add non-local edges that ordinary source-shaped graphs can omit. The smallest graph that answers your question is usually better than a large graph pretending to be complete.

A slice for “why did this comparison fail?” can omit code responsible for allocation, timing or thread ordering even when that code explains why the compared value became corrupt. Start narrow, then expand through memory writers, callers and concurrent events when the first slice reaches an unknown input.

SSA and compiler data-flow analysis continue in Language Engineering. Invalid memory and aliasing failures continue in Memory Exploits.

Analyse software you own, are authorised to test, or are studying in a legal challenge environment. Reverse engineering rules vary by licence and jurisdiction, and bypassing access controls can carry additional restrictions. Keep written scope, protect captured data and report defects through the agreed channel.

This course uses deliberately small local programs. The method transfers; permission does not.

Changing a branch byte can demonstrate that you found a decision. It does not prove you understand all callers, error paths or integrity checks. Signed binaries may refuse modified files, and an update will replace the patch. In maintained software, fix the source, rebuild with matching symbols and test both the original failure and nearby behaviour.

Use Assembly & Debugging, Step 18 for the full reproduce-reduce-observe-test loop, and Systems That Fail Well for production evidence and recovery.