Step B.1
Why are we interested in Assembly at all?
When you compile a source code file (such as flag. c ), the compiler (like gcc ) translates the high-level human-readable code into machine code that the computer’s processor can execute. A number of operations are performed at compile time (such as optimizing and linking), which obfuscates the binary’s original source code. However, we can still use a disassembler (like objdump) to translate machine code back into lower-level assembly instructions.
In practice, exploit developers generally do not possess the original source code of the binaries they research. But they can utilize tools to pour over and examine the assembly instructions – which can be just as good (provided you know how to read/contextualize assembly). Understanding what these assembly instructions are doing – both individually and collectively – is a fundamental baseline for reverse engineering (and by extension, exploit development).
NOTE: there are also tools that can “de-compile” binaries; these take the translation a step further by attempting to recreate the source code from the disassembled instructions. However, this is often incomplete and – in some cases – inaccurate. We do not supply you with a decompiler tool in this project because we provide you with the original source code. We’ve also compiled all our binaries in gcc with the -g flag, which produces debugging info in the OS’ native format that GDB can use to rebuild the source.
Being able to read and comprehend assembly is often a labor-intensive process, especially if you’ve primarily been exposed to only higher-level languages before. We encourage you to lean into this challenge, however. Without fostering this aptitude, you’ll often be left in a position of bruteforcing/guesswork (being unsure what a process is doing or why your exploit is behaving a certain way).
If this is your first time seeing/engaging x86 Assembly be forewarned that you’ll need to be a quick study for this project. This section’s exercises are meant to help orient you more generally, but the sections to follow will require a firm understanding if you want to avoid getting lost.
In the table below, we’ve listed some of the common instructions you’ll encounter in the course of this project. At a high-level, assembly operations (e.g. mov, , xor, , ret , etc.) may have 0, 1, or 2 “arguments” to them depending on the particular operation – these arguments are referred to as “operands”. Depending on the instruction, the operand may be a value, something referential to the stack/heap, or a register. We encourage you to consult other reference material as needed to foster your comprehension.
2/9/26, 12:08 AM Stage B – Intro to Assembly — (2 flags) I CS 6035
Instruction Description
mov Moves the contents of one memory location into another (as specified by operands).
XORs the values of 2 locations in memory against one another, storing the result in the xor primary operand.
“Load effective address”: computes an address of the source operand and stores it in the
lea
general register specified by the second.
Saves procedure linking information on the stack and branches to the called procedure; in
call
layman’s terms: it initiates a function call.
This is an unconditional jump, redirecting the control flow to elsewhere in the binary’s jmp instruction set. Examples of conditional jumps may apppear as jne, jnz, etc., which make
the jump only if particular conditions are met (common at branches, such as if-else blocks).
Returns transfer of the program control to a return address on the top of the stack;
ret
commonly the last instruction performed by most disassembled functions.
Why are we interested in CPU registers?
Registers are part of a CPU’s architecture and are used to store data and perform operations. Assembly instructions make use of registers all the time (and by extension, the stack and heap -topics for another section). In the setup exercise (
basic_overflow_l ), you may have observed some of
the registers and their contents at runtime within the GDB debugger like so:
| [ ILL.!.
“RAY, Ox60983alfcif5 r,. 4— endbr64 ‘RBX Ox7ffc0bd365f8 Ox7ffc0b089f,1 4— 1home/binexp/project binexp/experiment/projv2/01 basic overflow 1/flag’ *RCX Ox60983a1fedb0 ( do_global_dtors_aux_tini_array_entry) ■- endbr64 *ROX Ox7ffc0bd36608 Ox7ffc0bd3813b A- ‘SHELL=/bin/bash’ “ROI Oxl ‘RSI Ox7ffc0bd365f8 Ox7ffc0b6380f4 A- 1home/binexp/project_binexp/experiment/projv2/01_basic_overflow_1/flag’ R8 Ox0 *R9 ■— endbr64 *R10 Ox7tfc0bd361f0 ■— Ox600000 ‘R11 Ox203 ‘912 Oxl Ri3 Ox0 ‘“14 Ox60983alfedb0 ( do_global_dtors_aux_fini_array_entry) 4— endbr64 115 0x7d1t59cde000 c_rtld_gLobal) 0.x7dir39cdt2eu 0x60983a1fb000 ■— 0x10102464c457f ‘RBI) Ox7ffc0bd364d0 Ox7ffc0bd36570 -* Ox7ffcObd365d 4- Ox0 *RSP Ox7ffc0bd364d0 Ox7ffc0bd36570 Ox7ffc0bd365d0 A- Ox0 *RIP Ox60983alfcifd (mair-:c.. A— mov eax, 0 |
In the above screenshot, the various R* values (RAX, RBX, RCX, etc.) in red along the left-hand side denote the CPU registers. The values immediately adjacent to them reflect what is presently stored in them. You’ll see that sometimes the register can hold referential addresses which point to other locations in memory (see RAX, RBX, RDX, RSI, etc.) whereas others contain the value itself (e.g. RDI, R8, R11, etc.).
2/9/26, 12:08 AM Stage B – Intro to Assembly — (2 flags) I CS 6035
You can always query the current value of a register in GDB. For example, let’s say we wanted to view the contents of RDI:
pwndbg> x $rdi
Throughout this course, you’re going to be working with 64-bit registers. Besides being different in size from 32-bit registers, there’s actually some important architectural differences that you’ll need to know as they relate to binary exploitation. More to-the-point, not all registers are used in the same way by the CPU. Function calls – for example – look at specific registers for things like function arguments. For now, we encourage you to perform independent research into RBP, RSP, and RIP as these will be very important in the sections/exercises to follow.
