Computing 101

The CPU thinks in very simple terms. It moves data around, changes data, makes decisions based on data, and takes action based on data. Most of the time, this data is stored in registers.

Simply put, registers are containers for data. The CPU can put data into registers, move data between registers, and so on. These registers, at a hardware level, are implemented using very expensive chips, crammed into shockingly microscopic spaces, and accessed at a frequency where even physical concepts such as the speed of light impact their performance. Hence, the number of registers that a CPU can have is extremely constrained. Different CPU architectures have different amounts of registers, different names for these registers, and so on, but typically, there are between 10 and 20 "general purpose" registers that program code can use for any reason, and up to a few dozen other ones that are used for special purposes.

In x86's modern incarnation, x86_64, programs have access to 16 general purpose registers. In this challenge, we will learn about our first one: rax. Hi, Rax!

rax, a single x86 register, is a tiny piece of the massively complex design of the x86 CPU, but this is where we'll start. Like the other registers, rax is a container for a small amount of data. You move data into rax with the mov instruction. Instructions are specified as an operator (in this case, mov), and operands, which represent additional data (in this case, it will be the specification of rax as a destination, and the value we will want to store there).

For example, if you wanted to store the value 1337 into rax, the x86 Assembly would look like:

mov rax, 1337

You can see a few things:

1. The destination (rax) is specified before the source (the value 1337).
2. The operands are separated by a comma.
3. It is really simple!

In this challenge, you will write your first assembly. You must move the value 60 into rax. Write your program in a file with a .s extension, such as rax-challenge.s (while not mandatory, .s is the typical extension for assembly files). Pass that .s file to the checker as an argument:

hacker@dojo:~$ /challenge/check rax-challenge.s

The .s file is input to the checker; do not try to run it directly. You can use either your favorite text editor or the text editor in pwn.college's VSCode Workspace to implement your .s file!

ERRATA: If you've seen x86 assembly before, there is a chance that you've seen a slightly different dialect of it. The dialect used in pwn.college is "Intel Syntax", which is the correct way to write x86 assembly (as a reminder, Intel created x86). Some courses incorrectly teach the use of "AT&T Syntax", causing enormous amounts of confusion. We'll touch on this slightly in the next module and then, hopefully, never have to think about AT&T Syntax again.

So, your first program crashed... Don't worry, it happens! In this challenge, you'll learn how to make your program cleanly exit instead of crashing.

Starting your program and cleanly stopping it are actions handled by your computer's Operating System. The operating system manages the existence of programs and interactions between the programs, your hardware, the network environment, and so on.

Your programs "interact" with the CPU using assembly instructions such as the mov instruction you wrote earlier. Similarly, your programs interact with the operating system (via the CPU, of course) using the syscall, or System Call instruction.

Like how you might use a phone call to interact with a local restaurant to order food, programs use system calls to request the operating system to carry out actions on the program's behalf. As a bit of an overgeneralization, anything your program does that doesn't involve performing computation on data is done with a system call.

There are a lot of different system calls your program can invoke. For example, Linux has around 330 different ones, though this number changes over time as syscalls are added and deprecated. Each system call is indicated by a syscall number, counting upwards from 0, and your program invokes a specific syscall by moving its syscall number into the rax register and invoking the syscall instruction. For example, if we wanted to invoke syscall 42 (a syscall that you'll learn about sometime later!), we would write two instructions:

mov rax, 42
syscall

Very cool, and super easy!

In this challenge, we'll learn our first syscall: exit. The exit syscall causes a program to exit. By explicitly exiting, we can avoid the crash we ran into with our previous program!

Now, the syscall number of exit is 60. Go and write your first program: it should move 60 into rax, then invoke syscall to cleanly exit!

As you might know, every program exits with an exit code as it terminates. This is done by passing a parameter to the exit system call.

Similarly to how a system call number (e.g., 60 for exit) is specified in the rax variable, parameters are also passed to the syscall through registers. System calls can take multiple parameters, though exit takes only one: the exit code. The first parameter to a system call is passed via another register: rdi. rdi is what we will focus on in this challenge.

In this challenge, you must make your program exit with the exit code of 42. Thus, your program will need three instructions:

1. Set your program's exit code (move it into rdi).
2. Set the system call number of the exit syscall (mov rax, 60).
3. syscall!

Now, go and do it!

So you've written your first program? But until now, we've handled the actual building of it into an executable that your CPU can actually run. In this challenge, you will build it!

To build an executable binary, you need to:

1. Write your assembly in a file (often with a .S or .s syntax. We'll use program.s in this example).
2. Assemble your assembly file into an object file (using the as command).
3. Link one or more executable object files into a final executable binary (using the ld command)!

Let's take this step by step:

Writing assembly.
The assembly file contains, well, your assembly code. For the previous level, this might be:

hacker@dojo:~$ cat program.s
mov rdi, 42
mov rax, 60
syscall
hacker@dojo:~$

But it needs to contain just a tad more info. We mentioned that we're using the Intel assembly syntax in this course, and we'll need to let the assembler know that. You do this by prepending a directive to the beginning of your assembly code, as such:

hacker@dojo:~$ cat program.s
.intel_syntax noprefix
mov rdi, 42
mov rax, 60
syscall
hacker@dojo:~$

.intel_syntax noprefix tells the assembler that you will be using Intel assembly syntax, and specifically the variant of it where you don't have to add extra prefixes to every instruction. It isn't actually an x86 instruction (like mov and syscall), and so it doesn't end up in our final executable binary or runs on the CPU. We'll talk about other directives later, but for now, we'll let the assembler figure it out!

Assembling Assembly Code into Object Files.
Next, we'll assemble the code. This is done using the assembler, as, as so:

hacker@dojo:~$ ls
program.s
hacker@dojo:~$ cat program.s
.intel_syntax noprefix
mov rdi, 42
mov rax, 60
syscall
hacker@dojo:~$ as -o program.o program.s
hacker@dojo:~$ ls
program.o   program.s
hacker@dojo:~$

Here, the as tool reads in program.s, assembles it into binary code, and outputs an object file called program.o. This object file has actual assembled binary code, but it is not yet ready to be run. First, we need to link it.

Linking Object Files into an Executable.
In a typical development workflow, source code is compiled and assembly is assembled to object files, and there are typically many of these (generally, each source code file in a program compiles into its own object file). These are then linked together into a single executable. Even if there is only one file, we still need to link it, to prepare the final executable. This is done with the ld (stemming from the term "link editor") command, as so:

hacker@dojo:~$ ls
program.o   program.s
hacker@dojo:~$ ld -o program program.o
ld: warning: cannot find entry symbol _start; defaulting to 0000000000401000
hacker@dojo:~$ ls
program.o   program.s   program
hacker@dojo:~$

This creates an program file that we can then run! Here it is:

hacker@dojo:~$ ./program
hacker@dojo:~$ echo $?
42
hacker@dojo:~$

In the shell, $? holds the exit code of the last executed command.

Neat! Now you can build programs. In this challenge, go ahead and run through these steps yourself. Build your executable, and pass it to /challenge/check for the flag!

_start?
The attentive learner might have noticed that ld prints a warning about entry symbol _start. The _start symbol is, essentially, a note to ld about where in your program execution should begin when the ELF is executed. The warning states that, absent a specified _start, execution will start right at the beginning of the code. This is just fine for us!

If you want to silence the error, you can specify the _start symbol, in your code, as so:

hacker@dojo:~$ cat program.s
.intel_syntax noprefix
.global _start
_start:
mov rdi, 42
mov rax, 60
syscall
hacker@dojo:~$ as -o program.o program.s
hacker@dojo:~$ ld -o program program.o
hacker@dojo:~$ ./program
hacker@dojo:~$ echo $?
42
hacker@dojo:~$

There are two extra lines here. The second, _start:, adds a label called start, pointing to the beginning of your code. The first, .global _start, directs as to make the _start label globally visible at the linker level, instead of just locally visible at the object file level. As ld is the linker, this directive is necessary for the _start label to be seen.

For all the challenges in this dojo, starting execution at the beginning of the file is just fine, but if you don't want to see those warnings pop up, now you know how to prevent them!

Okay, let's learn about one more register: rsi! Like rdi, rsi is a place you can park some data. For example:

mov rsi, 42

Of course, you can also move data around between registers! Watch:

mov rsi, 42
mov rdi, rsi

Just like the first line there moves 42 into rsi, the second line moves the value in rsi to rdi. Here, we have to mention one complication: by move, we really mean set. After the snippet above, rsi and rdi will be 42. It's a mystery as to why the mov was chosen rather than something reasonable like set (even very knowledgeable people resort to wild speculation when asked), but it was, and here we are.

Anyways, on to the challenge! In this challenge, we will store a secret value in the rsi register, and your program must exit with that value as the return code. Since exit uses the value stored in rdi as the return code, you'll need to move the secret value in rsi into rdi. Run /challenge/check and pass it your code for the flag! /challenge/check will set the secret value in rsi before running your code. Good luck!

As seen by your program, computer memory is a huge place where data is housed. Like houses on a street, every part of memory has a numeric address, and like houses on a street, these numbers are (mostly) sequential. Modern computers have enormous amounts of memory, and the view of memory of a typical modern program actually has large gaps (think: a portion of the street that hasn't had houses built on it, and so those addresses are skipped). But these are all details: the point is, computers store data, mostly sequentially, in memory.

In this level, we will practice accessing data stored in memory. How might we do this? Recall that to move a value into a register, we did something like:

mov rdi, 31337

After this, the value of rdi is 31337. Cool. Well, we can use the same instruction to access memory! There is another format of the command that, instead, uses the second parameter as an address to access memory! Consider that our memory looks like this:

  Address │ Contents
+────────────────────+
│ 31337   │ 42       │
+────────────────────+

To access the memory contents at memory address 31337, you can do:

mov rdi, [31337]

When the CPU executes this instruction, it of course understands that 31337 is an address, not a raw value. If you think of the instruction as a person telling the CPU what to do, and we stick with our "houses on a street" analogy, then instead of just handing the CPU data, the instruction/person points at a house on the street. The CPU will then go to that address, ring its doorbell, open its front door, drag the data that's in there out, and put it into rdi. Thus, the 31337 in this context is the memory address and serves to point to the data stored at that memory address. After this instruction executes, the value stored in rdi will be 42!

Let's put this into practice! I've stored a secret number at memory address 133700, as so:

  Address │ Contents
+────────────────────+
│ 133700  │ ???      │
+────────────────────+

You must retrieve this secret number and use it as the exit code for your program. To do this, you must read it into rdi, whose value, if you recall, is the first parameter to exit and is used as the exit code. Good luck!

NOTE: To solve this challenge, assemble and link your code, then pass the executable binary to /challenge/check.

You look like you need just a tiny bit more practice. In this level, we put the secret value at 123400 instead of 133700, as so:

  Address │ Contents
+────────────────────+
│ 123400  │ ???      │
+────────────────────+

Go load it into rdi and exit with that as the exit code!

Did you prefer to access memory at 133700 or at 123400? Your answer might say something about your personality, but it's not super relevant from a technical perspective. In fact, in most cases, you don't deal with actual memory addresses when writing programs at all!

How is this possible? Well, typically, memory addresses are stored in registers, and we use the values in the registers to point to data in memory! Let's start with this memory configuration:

  Address │ Contents
+────────────────────+
│ 133700  │ 42       │
+────────────────────+

And consider this assembly snippet:

mov rax, 133700

Now, what you have is the following situation:

    Address │ Contents
  +────────────────────+
┌▸│ 133700  │ 42       │
│ +────────────────────+
│
└────────────────────────┐
                         │
   Register │ Contents   │
  +────────────────────+ │
  │ rax     │ 133700   │─┘
  +────────────────────+

rax now holds a value that corresponds with the address of the data that we want to load! Let's load it:

mov rdi, [rax]

Here, we are accessing memory, but instead of specifying a fixed address like 133700 for the memory read, we're using the value stored in rax as the memory address. By containing the memory address, rax is a pointer that points to the data we want to access! When we use rax in lieu of directly specifying the address that it stores to access the memory address that it references, we call this dereferencing the pointer. In the above example, we dereference rax to load the data it points to (the value 42 at address 133700) into rdi. Neat!

This also drives home another point: these registers are general purpose! Just because we've been using rax as the syscall index in our challenges so far doesn't mean that it can't have other uses as well. Here, it's used as a pointer to our secret data in memory.

Similarly, the data in the registers doesn't have an implicit purpose. If rax contains the value 133700 and we write mov rdi, [rax], the CPU uses the value as a memory address to dereference. But if we write mov rdi, rax in the same conditions, the CPU just happily puts 133700 into rdi. To the CPU, data is data; it only becomes differentiated when it's used in different ways.

In this challenge, we've initialized rax to contain the address of the secret data we've stored in memory. Dereference rax to load the secret data into rdi and use it as the exit code of the program to get the flag!

In the previous level, you dereferenced rax to read data into rdi. The interesting thing here is that our choice of rax was pretty arbitrary. We could have used any other pointer, even rdi itself! Nothing stops you from dereferencing a register to overwrite its own content with the dereferenced value!

For example, here is us doing this exact thing with rax. I've annotated each line with comments:

mov [133700], 42
mov rax, 133700  # after this, rax will be 133700
mov rax, [rax]   # after this, rax will be 42

Throughout this snippet, rax goes from being used as a pointer to being used to hold the data that's been read from memory. The CPU makes this all work!

In this challenge, you'll explore this concept. Rather than initializing rax, as before, we've made rdi the pointer to the secret value! You'll need to dereference it to load that value into rdi, then exit with that value as the exit code. Good luck!

So now you can dereference pointers in memory like a pro! But pointers don't always point directly at the data you need. Sometimes, for example, a pointer might point to a collection of data (say, an entire book), and you'll need to reference partway into this collection for the specific data you need.

For example, if your pointer (say, rdi) points to a sequence of numbers in memory, as so:

    Address │ Contents
  +────────────────────+
┌▸│ 133700  │ 50       │
│ │ 133701  │ 42       │
│ │ 133702  │ 99       │
│ │ 133703  │ 14       │
│ +────────────────────+
│
└────────────────────────┐
                         │
   Register │ Contents   │
  +────────────────────+ │
  │ rdi     │ 133700   │─┘
  +────────────────────+

If you want the second number of that sequence, you could do:

mov rax, [rdi+1]

Wow, super simple! In memory terms, we call these number slots bytes: each memory address represents a specific byte of memory. The above example is accessing memory 1 byte after the memory address pointed to by rdi. In memory terms, we call this 1 byte difference an offset, so in this example, there is an offset of 1 from the address pointed to by rdi.

Let's practice this concept. As before, we will initialize rdi to point at the secret value, but not directly at it. This time, the secret value will have an offset of 8 bytes from where rdi points, something analogous to this:

    Address │ Contents
  +────────────────────+
┌▸│ 31337   │ 0        │
│ │ 31337+1 │ 0        │
│ │ 31337+2 │ 0        │
│ │ 31337+3 │ 0        │
│ │ 31337+4 │ 0        │
│ │ 31337+5 │ 0        │
│ │ 31337+6 │ 0        │
│ │ 31337+7 │ 0        │
│ │ 31337+8 │ ???      │
│ +────────────────────+
│
└────────────────────────┐
                         │
   Register │ Contents   │
  +────────────────────+ │
  │ rdi     │ 31337    │─┘
  +────────────────────+

Of course, the actual memory address is not 31337. We'll choose it randomly, and store it in rdi. Go dereference rdi with offset 8 and get the flag!

Pointers can get even more interesting! Imagine that your friend lives in a different house on your street. Rather than remembering their address, you might write it down, and store the paper with their house address in your house. Then, to get data from your friend, you'd need to point the CPU at your house, have it go in there and find the friend's address, and use that address as a pointer to their house.

Similarly, since memory addresses are really just values, they can be stored in memory, and retrieved later! Let's explore a scenario where we store the value 133700 at the address 123400, and store the value 42 at the address 133700. Consider the following instructions:

mov rdi, 123400    # after this, rdi becomes 123400
mov rdi, [rdi]     # after this, rdi becomes the value stored at 123400 (which is 133700)
mov rax, [rdi]     # here we dereference rdi, reading 42 into rax!

Wow! This storing of addresses is extremely common in programs. Addresses and data are stored, loaded, moved around, and, sometimes, mixed up with each other! When that happens, security issues can arise, and you'll romp through many such issues during your pwn.college journey.

For now, let's practice dereferencing an address stored in memory. I'll store a secret value at a secret address, then store that secret address at the address 567800. You must read the address, dereference it, get the secret value, and then exit with it as the exit code. You got this!

In the last few levels, you have:

• Used an address that we told you (in one level, 133700, and in another, 123400) to load a secret value from memory.
• Used an address that we put into rax for you to load a secret value from memory.
• Used an address that we told you (in the last level, 567800) to load the address of a secret value from memory into a register, then used that register as a pointer to retrieve the secret value from memory!

Let's put those last two together. In this challenge, we stored our SECRET_VALUE in memory at the address SECRET_LOCATION_1, then stored SECRET_LOCATION_1 in memory at the address SECRET_LOCATION_2. Then, we put SECRET_LOCATION_2 into rax! The result looks something like this, using 123400 for SECRET_LOCATION_1 and 133700 for SECRET_LOCATION_2 (not, in the real challenge, these values will be different and hidden from you!):

      Address │ Contents
    +────────────────────+
┌──▸│ 133700  │ 123400   │─┐
│   +────────────────────+ │
│ ┌▸│ 123400  │ 42       │ │
│ │ +────────────────────+ │
│ └────────────────────────┘
└──────────────────────────┐
                           │
     Register │ Contents   │
    +────────────────────+ │
    │ rax     │ 133700   │─┘
    +────────────────────+

Here, you will need to perform two memory reads: one dereferencing rax to read SECRET_LOCATION_1 from the location that rax is pointing to (which is SECRET_LOCATION_2), and the second one dereferencing whatever register now holds SECRET_LOCATION_1 to read SECRET_VALUE into rdi, so you can use it as the exit code!

That sounds like a lot, but you've done basically all of this already. Go put it together!

So far, we've been loading data from memory at addresses that we gave you: either hardcoded (like 133700) or stored in a register (like rax). But there's one region of memory that your program already has access to without any setup from us: the stack.

The stack is a region of allocated memory used as scratch space for your program, and the register rsp (the Stack Pointer) points to the top of it. We'll explore the stack further later, but for now, the relevant detail is this: when a program starts, rsp points to data that represents the number of command-line arguments passed to the program (including the program name itself).

So if you run:

hacker@dojo:~$ /tmp/your-program hello world

Then the situation looks like this (the actual addresses are an example):

    Address    │ Contents
  +───────────────────────+
  │ ...        │ ...      │
  +───────────────────────+
┌▸│ 1337000    │ 3        │  ◀── the argument count
| +───────────────────────+
| | 1337008    | ???      |
| +───────────────────────+
| | 1337016    | ???      |
│ +───────────────────────+
│
└────────────────────────────┐
                             │
   Register │ Contents       │
  +────────────────────────+ │
  │ rsp     │ 1337000      │─┘
  +────────────────────────+

rsp points to the stack, and the value there is 3: one for the program name, one for hello, and one for world. The stack also has other data, as shown, but we won't worry about that for now!

In this challenge, read the argument count from [rsp] and use it as the exit code of your program. We'll run your program a few times with different arguments to make sure you're reading it correctly!

In the previous challenge, you read the value at [rsp]: the very top of the stack. But the stack has lots of data on it, and you can access any of it by adding an offset to rsp.

For example, [rsp+8] reads the 8-byte value right after [rsp], [rsp+16] reads the next one after that, and so on. In general, [rsp+N] reads memory at the address rsp+N:

    Address    | Contents
  +---------------------------+
  | rsp        | value 0      |  <-- [rsp]
  +---------------------------+
  | rsp+8      | value 1      |  <-- [rsp+8]
  +---------------------------+
  | rsp+16     | value 2      |  <-- [rsp+16]
  +---------------------------+
  | ...        | ...          |
  +---------------------------+

You'll notice these offsets go in multiples of 8. That's because many values on the stack, such as numbers or memory addresses, tend to be 8 bytes (64 bits) wide, so consecutive values are 8 bytes apart. But this is mostly convention: in reality, the stack, like any other region of memory, is a contiguous region of individual bytes, though for now we'll treat the stack as a bunch of 8-byte/64-bit values.

In this challenge, we've stashed a secret value on the stack at an offset of 128 bytes from rsp. Read the value at [rsp+128] and use it as the exit code!

You've now read [rsp] to get the argument count, and [rsp+128] to get data at an offset. Let's look at what else is on the stack!

Right after the argument count, the stack stores pointers to each program argument. These are addresses stored in memory: [rsp+16] doesn't contain the argument text directly --- it contains the address where that text lives.

For example, if your program is run as /tmp/your-program Hi:

     Register │ Contents
   +───────────────────────────+
   │ rsp      │ 1337000        │─┐
   +───────────────────────────+ │
                                 │
  ┌──────────────────────────────┘
  │
  │    Address    │ Contents
  │  +────────────────────────+
  │  │ ...        │ ...       │
  │  +────────────────────────+
  └▸ │ 1337000    │ 2         │  ◀── the ARGument Count (termed "argc")
     +────────────────────────+
     │ 1337008    │ 1234000   │──────┐
     +────────────────────────+      │
     │ 1337016    │ 1234560   │────┐ │
     +────────────────────────+    │ │
     │ 1337024    │ 0         │    │ │
     +────────────────────────+    │ │
                                   │ │
   ┌───────────────────────────────┘ │
   │                                 │
   │   Address   │ Contents          │
   │ +──────────────────────────+    │
   │ │ 1234000   │ "/tmp/..."   │◀───┘ the program name
   │ +──────────────────────────+
   │ │ ...       │ ...          │
   │ +──────────────────────────+
   └▸│ 1234560   │ "Hi"         │ the first argument!
     +──────────────────────────+

To get the actual argument data, you need to dereference twice: once to get the pointer from the stack, and once to follow it to the data.

mov rdi, [rsp+16]   # load the first argument pointer (e.g., 1234560) from the stack
mov rdi, [rdi]      # follow the pointer to read the actual data (e.g., "Hi")

In this challenge, your program will be invoked with an argument. Read the value of the first argument and exit with it!

Why is the stack called a stack? So far, we've just used it as a region of memory that we read from with mov, like any other memory dereference. But the stack is meant to be used as, well, a stack of data: you pop values off the top!

The pop instruction is purpose-built for this. pop rdi does two things:

1. Reads the value at [rsp] into rdi (just like mov rdi, [rsp]).
2. Adds 8 to rsp, advancing the stack pointer to the next value.

Using the same example as before:

hacker@dojo:~$ /tmp/your-program hello world

Before the pop rdi:

    Address    │ Contents
  +───────────────────────+
  │ ...        │ ...      │
  +───────────────────────+
┌▸│ 1337000    │ 3        │  ◀── the argument count
│ +───────────────────────+
│ | 1337008    | ???      |
│ +───────────────────────+
│
└────────────────────────────┐
                             │
   Register │ Contents       │
  +────────────────────────+ │
  │ rsp     │ 1337000      │─┘
  +────────────────────────+
  │ rdi     │ 0            │
  +────────────────────────+

After the pop rdi:

    Address    │ Contents
  +───────────────────────+
  │ ...        │ ...      │
  +───────────────────────+
  │ 1337000    │ 3        │
  +───────────────────────+
┌▸| 1337008    | ???      |
│ +───────────────────────+
│
└────────────────────────────┐
                             │
   Register │ Contents       │
  +────────────────────────+ │
  │ rsp     │ 1337008      │─┘
  +────────────────────────+
  │ rdi     │ 3            │
  +────────────────────────+

The value 3 was popped off the top of the stack into rdi, and rsp advanced by 8 bytes to point to the next value. The data at 1337000 is still there in memory, but as far as the stack is concerned, it's been removed: rsp has moved past it.

In this challenge, use pop to read the argument count and exit with it!

Computers store data as bytes, which are made of bits. The registers you're used to so far, such as rax, are 64 bits wide, meaning that they can hold values from 0 (all 0 bits) to 2^64-1 (all 1 bits). But what if you wanted to store negative numbers?

Early approaches to storing negative numbers included the use of a sign bit: a positive decimal 5 might be stored as the byte 00000101, while a negative 5 would be 10000101. This makes sense, but it has a very important problem: math.

Deep inside your computer's CPU is a subcomponent called an Arithmetic Logical Unit (ALU), which is responsible for arithmetic. This critical component needs to be very optimized, so the less complexity is needed to, say, add units, the better. At the same time, the math needs to check out. This leads to two issues:

1. A signed bit system has two different values for zero: 00000000 (positive zero) and 10000000 (negative zero). This is terrible for many reasons, including having to complicate the ALU.
2. In a signed bit system, different arithmetic algorithms need to be used for signed versus unsigned numbers. You can add 00000010 (decimal 2) and 00000001 (decimal 1) easily with normal binary math, but 10000010 (decimal -2) and 00000001 (decimal 1) need to instead be modeled partially as subtractive.

This is not great. Luckily, some smart minds came up with a brilliant scheme called Twos Complement. Twos complement solves both problems by modeling half of the bit space as negative in a way compatible with unsigned arithmetic. Consider this subtraction:

  00000001    a positive 1
- 00000010    a positive 2 (being subtracted)

There aren't enough bits to service this subtraction, so we introduce a borrow bit:

  1 00000001    a positive 1 (with a borrow bit)
- 0 00000010    a positive 2 (being subtracted)
  ----------
  0 11111111    the result of the normal *sign-agnostic* subtraction

So 11111111 is -1: add it to 1 and they cancel, with the leftover bit falling off the end of the byte and vanishing. This has a few advantages:

1. The top bit is still the sign bit: if it's set, the value is negative! Very easy to test.
2. There is only one zero: 00000000.
3. Arithmetic works exactly normally for both signed and unsigned numbers.

The downside is the slight human complexity: the actual magnitude (e.g., value after the sign) of a negative number is the unsigned byte value minus 256. In the above 11111111, it's 255 - 256 = -1. A bit complex, but you'll get the idea eventually. Interestingly, if you treat the value as unsigned, you can happily use it as 255 in the arithmetic you want, and everything will still work out!

Now, put this to use. This challenge will force you to understand twos-complement on bytes. Run /challenge/decode and get the flag!

You've done two's complement one byte at a time, but nothing about it is special to 8 bits. It works at any bit-width!

In this level, we'll practice twos complement on 16-bit values. Remember, rax and its friends are 64 bits wide, and they're also twos-complement, so you have a ways to scale up!

A 16-bit value can be as big as 2^16-1 when unsigned (65535), but if you interpret that binary value (1111111111111111) as a signed integer, you will get -1! To interpret 1000000000000000 (unsigned 32768) as signed, you must subtract 65536 from it, resulting in -32768, which is the smallest signed value that can be expressed in 16 bits (with the largest signed value, 0111111111111111 being 32767).

This might be starting to get slightly confusing and, indeed, the different maximum values of signed versus unsigned numbers lead to all sorts of bugs and security vulnerabilities!

The size of these numbers makes manual math difficult, and we don't expect you to do these conversions in your head. Our advice: do the unsigned conversion using a tool, then do the twos complement subtraction if it's signed. One tool you can use is the Python programming language. You don't have to program anything in it yet (though we'll get there), just use its interactive mode as a calculator. For example, to convert the binary 1001111101011100, you can do:

hacker@dojo$ ipython
In [1]: 0b1001111101011100
Out[1]: 40796

In [2]: 40796 - 65536
Out[2]: -24740

In [3]: exit
hacker@dojo$

A few notes:

• In [1] is the input prompt for the ipython interactive python interpreter, and Out [1] is the result of the expression entered into In [1].
• 0b is Python's prefix to differentiate numbers written in binary from decimal (e.g., 0b101 is 5 and 101 is 101).

Run /challenge/decode and get the flag!

Let's go wider! We'll try 4 bytes, 32 bits. Use the same ipython calculator workflow from the 16-bit level: convert the binary as unsigned first, then subtract 2**32 if the top bit is set. The maximum unsigned value of this, 11111111 11111111 11111111 11111111, is 2**32-1, or 4,294,967,295. The maximum signed value, 01111111 11111111 11111111 11111111, is 2**31-1, which is 2,147,483,647, and the minimum signed value, 10000000 00000000 00000000 00000000, is -2**31, which is -2,147,483,648.

Run /challenge/decode and get the flag!

The first three levels had you read bits as a signed number. Now let's go the other way: given a number, write its two's-complement bits.

For a zero-or-positive number, that's just its plain binary, padded with leading zeros to fill the byte. For a negative number, recall the rule from the very first level --- the n-bit two's-complement pattern of a negative value is the same bits as the unsigned number (value + 2ⁿ). In a byte (8 bits), that means adding 256:

  -5   ->   -5 + 256 = 251   ->   11111011
  42   ->                         00101010

(Equivalently: flip the bits of +5 and add one, which gives you the same answer, 11111011. Either way of thinking about it works.)

Run /challenge/encode and get the flag!

Time to put the reading above into practice.

The key fact: a single hex digit is exactly 4 bits, so a byte --- 8 bits --- is just two hex digits. To turn a byte from binary into hex, split its 8 bits into two groups of 4 and look each group up:

11100011     the byte, in binary
1110 0011    the byte, in binary, split into two groups of 4 bits
 e    3      each group of 4 bits -> one hex digit
->  0xe3     the hex!

Run /challenge/convert and get the flag!

Like decimal numbers, you can add arbitrary amounts of them to represent more and more bytes. Every two hex digits are one additional byte. One hex digit, for those curious, is called a nibble (har har!), but this is not used when specifying data. We almost always work with data on the byte level, not less.

We'll practice this in this challenge. Split each byte's 8 bits into two groups of 4, turn each group into its hex digit, and write the bytes left to right. For example:

1110 0011   0101 1010   1001 0000
 e    3      5    a      9    0
-> 0xe35a90

Now it's your turn: run /challenge/convert and go earn that flag!

So far you've encoded binary data into hex. Now let's go the other way and decode it: that is, turn hex back into the bits it stands for.

It's the same mapping, just run in reverse. Each hex digit becomes its 4 bits, written out in order. Since a byte is two hex digits, decoding one byte means expanding two hex digits into 8 bits:

0x   0      a
     0000   1010
->   00001010

This is exactly what a program does when it receives hex-encoded data: it turns each pair of hex digits back into the byte it represents before working with it. Write out the full 8 bits, leading zeros and all --- each hex digit is always exactly 4 of them.

Run /challenge/convert and get the flag!

Of course, the same value can be interpreted/reasoned about in multiple ways. We'll explore that here across the four interpretations we've studied (unsigned decimal, signed decimal, hex, and twos-complement binary). Work through every conversion to earn the flag.

In the previous module, you wrote assembly programs and built them into executables. But what if someone gives you a program and you want to understand what it does? This is where disassembly comes in: the process of converting the binary machine code in an executable back into human-readable assembly instructions.

Though you will learn to use vastly more powerful tooling later in your journey, we will start with one of the most common tools for disassembly: objdump. Given a binary, objdump -d will disassemble the executable sections and show you the assembly instructions:

hacker@dojo:~$ objdump -d -M intel /tmp/your-program

/tmp/your-program:     file format elf64-x86-64


Disassembly of section .text:

0000000000401000 <_start>:
  401000:	48 c7 c7 39 05 00 00 	mov    rdi,0x539
  401007:	48 c7 c7 00 00 00 00 	mov    rdi,0
  40100e:	48 c7 c0 3c 00 00 00 	mov    rax,0x3c
  401015:	0f 05                	syscall

There are a few things to note here. First, by default, objdump uses the wrong assembly syntax, which is why we pass the -M intel option. Don't forget this option! Viewing assembly in non-Intel syntax can be confusing and harmful for your health.

Second, objdump displays the raw bytes of each instruction (e.g., the hexadecimal values 0f 05 is the syscall instruction) alongside the human-readable assembly. These are the actual values that are stored in computer memory to represent the instructions. For mathematical reasons, these are represented in "base 16" (hexadecimal) rather than the "base 10" (decimal) that we are used to counting with. If that does not make sense, please run through the first half or so of the Dealing with Data module and then come back here!

Third, the values that are being moved into registers are also represented as hexadecimal. This can make it slightly tricky to understand what the program is doing. Above, we can see that it is setting rax to the hexadecimal value 0x3c, which is 60 in decimal and, thus, is our familiar syscall number of exit! Right before that, it sets rdi to 0, which will be the exit code of the program.

But interestingly, right before that, it sets rdi to 0x539, which we can't really observe from the outside because it's overwritten to 0 immediately. While this "secret" is benign, by reading the code of software, we can extract many different such secrets, some of which are security relevant!

We'll practice this secret extraction in this challenge, using a binary at /challenge/disassemble-me. Use objdump to disassemble it and find the number being loaded into rdi before it's wiped out. Then, submit that number using /challenge/submit-number. The number will be displayed in hexadecimal in the disassembly, but /challenge/submit-number accepts both hexadecimal (e.g., 0x539) and decimal (e.g., 1337) values. Good luck!

The first one is pretty simple: the syscall tracer, strace.

Given a program to run, strace will use functionality of the Linux operating system to introspect and record every system call that the program invokes, and its result. For example, let's look at our program from the previous challenge:

hacker@dojo:~$ strace /tmp/your-program
execve("/tmp/your-program", ["/tmp/your-program"], 0x7ffd48ae28b0 /* 53 vars */) = 0
exit(42)                                 = ?
+++ exited with 42 +++
hacker@dojo:~$

As you can see, strace reports what system calls are triggered, what parameters were passed to them, and what data they returned. The syntax used here for output is system_call(parameter, parameter, parameter, ...). This syntax is borrowed from a programming language called C, but we don't have to worry about that yet. Just keep in mind how to read this specific syntax.

In this example, strace reports two system calls: the second is the exit system call that your program uses to request its own termination, and you can see the parameter you passed to it (42). The first is an execve system call. We'll learn about this system call later, but it's somewhat of a yin to exit's yang: it starts a new program (in this case, your-program). It's not actually invoked by your-program in this case: its detection by strace is a weird artifact of how strace works, that we'll investigate later.

In the final line, you can see the result of exit(42), which is that the program exits with an exit code of 42!

Now, the exit syscall is easy to introspect without using strace --- after all, part of the point of exit is to give you an exit code that you can access. But other system calls are less visible. For example, the alarm system call (syscall number 37!) will set a timer in the operating system, and when that many seconds pass, Linux will terminate the program. The point of alarm is to, e.g., kill the program when it's frozen, but in this case, we'll use alarm to practice our strace snooping!

In this challenge, you must strace the /challenge/trace-me program to figure out what value it passes as a parameter to the alarm system call, then call /challenge/submit-number with the number you've retrieved as the argument. Good luck!

Next, let's move on to GDB. GDB stands for the GNU Debugger, and it is typically used to hunt down and understand bugs. More specifically, a debugger is a tool that enables the close monitoring and introspection of another process. There are many famous debuggers, and in the Linux space, gdb is by far the most common.

We'll learn gdb step by step through a series of challenges. In this one, we'll focus on simply launching it. That's done as so:

hacker@dojo:~$ gdb /path/to/binary/file

In this challenge, the binary that holds the secret is /challenge/debug-me. Once you load it in gdb, the rest will happen magically: we'll handle the analysis and give you the secret number. In later levels, you'll learn how to get that number on your own!

Again, once you have the number, exchange it for the flag with /challenge/submit-number.

In the previous level, GDB automatically quit for you. Now it's your turn!

When you're done working in GDB, you exit it with the quit command (or just q):

(gdb) quit

In this level, we'll still handle the analysis for you. All you need to do is launch GDB, let the magic happen, and then type quit to exit.

Debuggers, including gdb, observe the debugged program as it runs to expose information about its runtime behavior. In the previous level, we automatically launched the program for you. Here, we will tone down the magic somewhat: you must start the execution of the program, and we'll do the rest (e.g., recover the secret value from it).

When you launch gdb now, it will eventually bring up a command prompt, that looks like this:

(gdb) 

You start a program with the starti command:

(gdb) starti

starti starts the program at the very first instruction. Once the program is running, you can use other gdb commands to inspect its actual runtime state. We'll start with the code that's running, which you can disassemble using the disassemble command! For example:

(gdb) disassemble
Dump of assembler code for function main:
=> 0x0000000000401000 <+0>:     mov    rdi,0x539
   0x0000000000401007 <+7>:     mov    rdi,0x0
   0x000000000040100e <+14>:    mov    rax,0x3c
   0x0000000000401015 <+21>:    syscall
End of assembler dump.

This is the same program from the objdump challenge, now running in gdb. Like before, you can gleam its secrets by reading the disassembly, though later we'll dig even deeper! For now, run starti after loading the binary in gdb, and we'll take care of the rest.

In the previous level, we ran the disassemble command for you after you started the program. Now it's your turn!

After starting the program with starti, you will need to run the disassemble command yourself:

(gdb) starti
...
(gdb) disassemble
Dump of assembler code for function main:
=> 0x0000000000401000 <+0>:     mov    rdi,0x539
   0x0000000000401007 <+7>:     mov    rdi,0x0
   0x000000000040100e <+14>:    mov    rax,0x3c
   0x0000000000401015 <+21>:    syscall
End of assembler dump.

Read the output to find the secret number, then submit it with /challenge/submit-number.

So far, you've been reading the secret from the program's disassembly. But what if the secret is hidden?

In this level, the disassembly is censored: the secret value is replaced with CENSORED. However, even though you can't read the value from the code, you can still execute the code! When the CPU executes mov rdi, CENSORED, it loads the actual secret value into the rdi register.

To execute a single instruction in GDB, use the stepi command (step one instruction, also abbreviated si):

(gdb) stepi

Once you step past the mov instruction, we'll read the rdi register for you and show the secret value. Submit it with /challenge/submit-number!

In the previous level, we automatically read the register value for you after you stepped. Now it's your turn!

The disassembly is still censored, so you'll need to:

1. Start the program with starti
2. Step one instruction with stepi (or si)
3. Read the register yourself with print $rdi

The print command displays the value of an expression. Register names in GDB are prefixed with $, so you can read rdi like this:

(gdb) print $rdi
$1 = 1337

Then submit the value with /challenge/submit-number.

In the previous level, you used print to read a register's value. GDB can also change a register while the program is stopped.

The set command assigns a new value to a register:

(gdb) set $rax = 42

As with print, prefix the register name with $.

In this level, you will need to:

1. Start the program with starti and step past its first instruction.
2. Set rdi to 1337 and step once more.
3. Print the resulting secret number, then submit it with /challenge/submit-number.

Run gdb /challenge/debug-me and change that register!

In previous levels, the secret was hidden in the program's code (a hardcoded mov instruction). This time, the secret comes from the program's runtime state: it's the argument count (argc), which lives on the stack.

The program pops this value off the stack with pop rdi, but then immediately overwrites rdi with 0 before exiting:

pop    rdi          <- reads argc from the stack into rdi
mov    rdi,0x0      <- overwrites rdi with 0!
mov    rax,0x3c
syscall             <- exit(0) --- the secret is gone!

The code is fully visible, and nothing is censored, but you can't determine the secret just by reading the disassembly because argc depends on how many arguments the program was launched with. In this level, GDB handles that for you, but in the future, we'll show you how to set the program's arguments in gdb as well!

For now, you'll need to:

1. Start the program.
2. Step one instruction to execute just pop rdi
3. print the resulting value in rdi before it gets overwritten
4. Quit gdb and then submit the value with /challenge/submit-number.

In the last level, you could stepi to execute pop rdi and then print $rdi to read the secret. This time, there's no pop at all --- the program just exits immediately:

mov    rdi,0x0
mov    rax,0x3c
syscall             <- exit(0) --- the secret was never read!

The secret is still argc, and it's sitting right on top of the stack, but the program never loads it into a register. You'll need to examine memory directly!

GDB's x (examine) command lets you look at the contents of memory. As you learned earlier, the stack pointer ($rsp) starts out pointing right at argc, so you can read it with:

x $rsp

Go and do that!

1. Start the program
2. Examine the top of the stack
3. Quit gdb and submit the value with /challenge/submit-number

NOTE: x displays values in hexadecimal by default. You can change the display format by appending / to the command. For example, if you'd rather see decimal, use x/d $rsp. Either way, /challenge/submit-number accepts both hex (e.g., 0x2a) and decimal (e.g., 42).

In the last level, you used x to read argc from the top of the stack. But the stack holds more than just argc!

Right after the argument count, the stack stores pointers to each program argument. These are addresses stored in memory: $rsp+16 doesn't contain the argument text directly --- it contains the address where that text lives.

For example, if your program is run as /challenge/debug-me Hi:

     Address    │ Contents
   +────────────────────────────+
   │  rsp + 0   │ 2             │◀── argc
   +────────────────────────────+
   │  rsp + 8   │ 0x1234000     │──────┐
   +────────────────────────────+      │
   │  rsp + 16  │ 0x1234560     │────┐ │
   +────────────────────────────+    │ │
                                     │ │
                                     │ │
     Address    │ Contents           │ │
   +──────────────────────────────+  │ │
   │ 0x1234000  │ "/challenge/..."│◀─│─┘ the program name
   +──────────────────────────────+  │
   │ ...        │ ...                │
   +──────────────────────────────+  │
   │ 0x1234560  │ "Hi"            │◀─┘   the first argument
   +──────────────────────────────+

To get the actual argument data, you need two dereferences: one to get the pointer from the stack, and one to follow it to the string.

In this level, THE FLAG ITSELF is passed as the first argument! The program doesn't use it --- it just exits --- but the flag is right there in memory.

To find it, you'll need two x commands, with two different display modes:

First: You'll need the pointer the first argument. You've done this before, but now you're doing it in gdb.

x/a $rsp+16

/a tells x to display the value as a memory address. You'll see a very large hexadecimal number, something like 0x7ffc001c4750.

Second: Read the text of the first argument at that address:

x/s 0x7ffc001c4750

/s tells x to display the value as a string. Replace the address with whatever you got from step 1. This will show you the flag!

Go and do that!

1. Start the program
2. x/a $rsp+16 to get the address of the first argument
3. x/s <address> to read the flag string

So far, the debugging you've done has been preemptive: you (the debugger) started the program with stepi, which immediately forces it to stop and let you debug it, without the program necessarily being aware of it. In this challenge, we'll learn another model for this, where the program decides when the debugger stop happens. We'll call this cooperative debugging.

On our now-familiar x86 architecture, the program can signal a desire to be debugged by using the int3 instruction. If a debugger is attached when int3 is executed, it stops the program. This is called a program breakpoint.

Later, we'll learn how to set breakpoints from the debugger itself, going back to the preemptive model. But in this challenge, the checker will run your program under gdb and expect your program to trigger its own breakpoint. To do this, rather than using starti to start your program and immediately stop it, we'll use gdb's run command, which will simply run it until a breakpoint is hit!

When your program executes int3, gdb will break and the checker script will inspect $rdi. If $rdi is 1337 at that point, you get the flag!

Go and write a program that:

1. Moves 1337 into rdi
2. Executes int3 to cooperatively hand control to the debugger

Assemble and link your code into an ELF executable, then submit that executable:

hacker@dojo:~$ /challenge/check /tmp/your-program

NOTE: When an int3 is executed by a program not running under a debugger, you will see:

hacker@dojo:~$ /tmp/your-program
Trace/breakpoint trap
hacker@dojo:~$

And the program will terminate... If you want the program to run outside a debugger, take out that int3!

In the previous level, you used gdb's run command for the first time: run starts the program and lets it execute freely. But what if the program needs command-line arguments to work?

Outside gdb, you've been passing arguments by just typing them after the program name:

hacker@dojo:~$ /challenge/debug-me hello

Inside gdb, the analog is to pass them to run:

(gdb) run hello

Whatever you put after run becomes the inferior's argv[1], argv[2], and so on --- exactly as if you'd typed those arguments on the shell command line. GDB also accepts the short form r:

(gdb) r hello

(Anywhere you see run in gdb's docs, r works too.)

In this challenge, /challenge/debug-me only prints your flag when you give it the string pwn as argv[1]. Do it!

In the previous level, you passed command-line arguments through gdb's run. Programs can also read from stdin, and gdb lets you redirect stdin when you run the inferior. The syntax is the same redirection you've seen in the shell, but it goes after run inside gdb:

(gdb) run < /path/to/input

In this challenge, /challenge/debug-me reads its required input from /challenge/secret. Run it under gdb with /challenge/secret redirected into stdin, read the secret number it prints, and submit that number with /challenge/submit-number.

Let's learn to write text!

Unsurprisingly, your program writes text to the screen by invoking a system call. Specifically, this is the write system call, and its syscall number is 1. However, the write system call also needs to specify, via its parameters, what data to write and where to write it to.

You may remember, from the Practicing Piping module of the Linux Luminarium dojo, the concept of File Descriptors (FDs). As a reminder, each process starts out with three FDs:

• FD 0: Standard Input is the channel through which the process takes input. For example, your shell uses Standard Input to read the commands that you input.
• FD 1: Standard Output is the channel through which processes output normal data, such as the flag when it is printed to you in previous challenges or the output of utilities such as ls.
• FD 2: Standard Error is the channel through which processes output error details. For example, if you mistype a command, the shell will output, over standard error, that this command does not exist.

It turns out that, in your write system call, this is how you specify where to write the data to! The first (and only) parameter to your exit system call was your exit code (mov rdi, 42), and the first (but, in this case, not only!) parameter to write is the file descriptor. If you want to write to standard output, you would set rdi to 1. If you want to write to standard error, you would set rdi to 2. Super simple!

This leaves us with what to write. Now, you could imagine a world where we specify what to write through yet another register parameter to the write system call. But these registers don't fit a ton of data, and to write out a long story like this challenge description, you'd need to invoke the write system call multiple times. Relatively speaking, this has a lot of performance cost --- the CPU needs to switch from executing the instructions of your program to executing the instructions of Linux itself, do a bunch of housekeeping computation, interact with your hardware to get the actual pixels to show up on your screen, and then switch back. This is slow, and so we try to minimize the number of times we invoke system calls.

Of course, the solution to this is to write multiple characters at the same time. The write system call does this by taking two parameters for the "what": a where (in memory) to start writing from and a how many characters to write. These parameters are passed as the second and third parameters to write. In the kinda-C syntax that we learned from strace, this would be:

write(file_descriptor, memory_address, number_of_characters_to_write)

For a more concrete example, if you wanted to write 10 characters starting from some memory address to standard output (file descriptor 1), this would be:

write(1, memory_address, 10);

Wow, that's simple! Now, how do we actually specify these parameters?

1. We'll pass the first parameter of a system call, as we reviewed above, in the rdi register.
2. We'll pass the second parameter via the rsi register. The agreed-upon convention in Linux is that rsi is used as the second parameter to system calls.
3. We'll pass the third parameter via the rdx register. This is the most confusing part of this entire module: rdi (the register holding the first parameter) has such a similar name to rdx that it's really easy to mix up and, unfortunately, the naming is this way for historic reasons and is here to stay. Oh well... It's just something we have to be careful about. Maybe a mnemonic like "rdi is the initial parameter while rdx is the xtra parameter"? Or just think of it as having to keep track of different friends with similar names, and you'll be fine.

And, of course, the write syscall index into rax itself: 1. Other than the rdi vs rdx confusion, this is really easy!

Now, you know how to set the system call number and how to set the rest of the registers. But where in memory is the data you need to write?

In this challenge, your program is invoked with a command-line argument, something like:

/tmp/your-program H

Recall that when a program is run with arguments, the stack stores pointers to each argument. These are addresses stored in memory: [rsp+16] doesn't contain the argument text directly --- it contains the address where that text lives.

So, to get the memory address of the first argument, you simply load the pointer from the stack, as you've done before!

mov rsi, [rsp+16]

This puts the memory address of the first argument's text into rsi --- exactly what write needs as its second parameter!

Your program will be invoked with a single character as its first argument. Call write to write that single character (for now! We'll do multiple-character writes later) to standard output, and we'll give you the flag!

Okay, our previous solution wrote output but then crashed. In this level, you will write output, and then not crash!

We'll do this by invoking the write system call, and then invoking the exit system call to cleanly exit the program. How do we invoke two system calls? Just like you invoke two instructions! First, you set up the necessary registers and invoke write, then you set up the necessary registers and invoke exit!

Your previous solution had 5 instructions (loading the first argument's address from the stack, setting rdi, setting rdx, setting rax, and syscall). This one should have those 5, plus three more for exit (setting rdi to the exit code, setting rax to syscall index 60, and syscall). For this level, let's exit with exit code 42!

Okay, we have one thing left for this run of challenges. You've written out a single byte, and now we'll practice writing out multiple bytes. In this level, the flag itself is passed as the first argument to your program! Can you write all 64 characters of it to stdout?

Hint: The only thing you should have to change compared to your previous solution is the value in rdx!

You now know how to output data to stdout using write. But how does your program receive input data? It reads it from stdin!

Like write, read is a system call that shunts data around between file descriptors and memory, and its syscall number is 0. In read's case, it reads some amount of bytes from the provided file descriptor and stores them in memory. The C-style syntax is the same as write:

read(0, some_address, 5);

This will read 5 bytes from file descriptor 0 (stdin) into memory starting from some_address. So, if you type in (or pipe in) HELLO HACKERS into stdin, the above read call would result in the following memory configuration:

     Address     │ Contents
+───────────────────────────+
│ some_address   │ 48       │
│ some_address+1 │ 45       │
│ some_address+2 │ 4c       │
│ some_address+3 │ 4c       │
│ some_address+4 │ 4f       │
+───────────────────────────+

What are those numbers?? They are hexadecimal representations of ASCII-encoded letters. If those words don't make sense, please run through the first half or so of the Dealing with Data module and then come back here!

In this level, we will combine read with our previous write abilities. The flag will be piped into your program's stdin --- 128 bytes of it. Your program should:

1. first read 128 bytes from stdin to your program's memory
2. write those 128 bytes from that memory location to stdout
3. finally, exit with the exit code 42.

But what address should you use? You need somewhere that's valid and writable, and you already know about one such place: the stack! The rsp register points to the top of the stack, and there's plenty of writable space there. So you can just use rsp as your memory address: mov rsi, rsp.

DEBUGGING: Having trouble? Recall the Introspection module! Build your program and run it with strace to see what's happening at the system call level, or run it in gdb to inspect the values of registers and memory to see what's unexpected.

REMEMBER: You've basically already written steps 2 and 3 (though in the previous challenges, you loaded rsi from [rsp+16] --- here, you'll set it to rsp directly with mov rsi, rsp!). All you have to do is add step 1!

In the previous level, you knew the input was exactly 128 bytes, so you could read 128 and write 128. Real input is rarely so tidy: often, you don't know up front how many bytes are coming.

Luckily, read tells you. When a system call returns, Linux places its result in rax. For read, that result is the number of bytes it actually read. Ask it to read 128 bytes but only 50 are available, and it reads those 50 and leaves 50 in rax.

So the idiom is: read into your buffer using a count comfortably larger than you expect, then write back exactly the number of bytes read returned. The only missing piece is that you need to move read's return value (rax) into write's size argument (rdx):

mov rdx, rax

Make sure to do this before clobbering rax with the syscall number of write!

This time the flag is piped in without padding. read it, write back exactly what you read, and exit with code 42 to get the flag!

So far, your program has only interacted with stdin and stdout, but what about files on disk? To access a file, you first need to open it using the open system call.

The open system call (syscall number 2) takes a pointer to a filename string and returns a brand-new file descriptor referring to that file:

open("/flag", 0);

The second argument specifies additional modes and permissions for the file, but 0 requests the default: read-only.

The registers for open follow the same convention:

When open returns, rax contains the new file descriptor (fd) number. Recall that file descriptor 0 is stdin, file descriptor 1 is stdout, and file descriptor 2 is stderr. Other files that are open are just represented by other file descriptors, incrementing from 3 onwards! You'll use this fd as the first argument to read, just like you did for stdin earlier, but this time read will read from your file.

How to load the filename into memory? In this level, the path to the flag (/flag) will be passed as the first argument to your program. You already know how to load that: mov rdi, [rsp+16].

Your program should:

1. Load a pointer to the filename (stored at [rsp+16], the first argument) into rdi
2. Specify the default of read access for the second argument (set rsi to 0).
3. open it (syscall 2)
4. read from the returned fd into memory. The fd open returned is in rax; move it to rdi for read's first argument (do this before you set the syscall number for write!). Read a comfortably large count --- the flag is shorter.
5. write to stdout exactly the number of bytes read returned (mov rdx, rax, just like in read-exact)
6. exit with code 42 (syscall 60)

DEBUGGING: Having trouble? Use strace to see your system calls in action --- it will show you exactly what arguments each syscall receives and what it returns. If open is returning -1, double-check your filename pointer. If read returns 0, the file descriptor from open might be wrong.

In the previous level, the filename was passed as an argument to your program. But what if you need to open a file whose path you already know? There are many ways to hardcode strings in your code, but for the purposes of the type of code you'll be writing in pwn.college, we are going to go with a "hacker" way designed more for use during software exploitation than real software development. We will hardcode the filename string directly into your program by writing it onto the stack, byte by byte!

The open syscall needs a pointer to the filename, so you need the bytes / f l a g stored somewhere in memory. You already know a writable memory address: rsp (the stack). You can write each character one byte at a time:

mov BYTE PTR [rsp], '/'
mov BYTE PTR [rsp+1], 'f'
mov BYTE PTR [rsp+2], 'l'
mov BYTE PTR [rsp+3], 'a'
mov BYTE PTR [rsp+4], 'g'
mov BYTE PTR [rsp+5], 0

A few things to note here:

• BYTE PTR: When you write to a memory address like [rsp] using an immediate value (a number or character), the CPU doesn't know how many bytes you intend to write --- one? two? eight? BYTE PTR is a size directive that tells the assembler "I mean exactly one byte." Without it, the assembler won't know what you want and will refuse to assemble the instruction.

• Single quotes: In assembly, a single-quoted character like 'f' represents that character's one-byte ASCII value. So 'f' is just a convenient way of writing 0x66, and '/' is 0x2f.

• The null byte: The last byte we write is 0 --- a special null byte. This is how Linux knows where a string ends: it reads bytes starting from the pointer you give it and stops when it hits a 0 byte. Without it, open would keep reading past "flag" into whatever else is on the stack, and you'd be trying to open a file with a nonsense name!

After writing these bytes, rsp points to the null-terminated string "/flag", ready to pass to open.

Your turn! This time, no arguments are passed to your program. You must construct the filename yourself.

Your program should:

1. Write "/flag\0" onto the stack byte by byte using mov BYTE PTR [rsp+N], ...
2. open it (syscall 2): rdi = rsp (the string you just wrote), rsi = 0
3. read from the returned fd into memory (syscall 0), using a comfortably large count
4. write to stdout exactly the number of bytes read returned (syscall 1)
5. exit with code 42 (syscall 60)

DEBUGGING: Having trouble? Use strace to trace your syscalls. If open returns -1, your string pointer or encoding might be off. Try x/s $rsp in gdb to see what string is actually on the stack.

In the previous level, you created the "/flag" filename by writing each byte onto the stack. That is a useful technique, but it is frustrating to write and hard to reason about (imagine trying to spot a typo in a long sentence written this way!). This challenge will show you a better way.

Luckily, your assembly can also contain bytes that are not meant to execute. For example, if you put those bytes after your final exit syscall, the CPU will stop before it reaches them. The bytes will still live in your program's memory, but will not crash your program by being interpreted as instructions.

For strings, the assembler gives you a convenient directive to specify these bytes:

_start:
    ...
    mov rax, 60
    syscall           // exit!
path:
    .asciz "/flag"    // never executed, but still there!

The .asciz directive emits the bytes of the string along with the terminating zero byte that Linux expects at the end of a filename. The path: label marks where those bytes start. In later challenges, when you see a compiled binary load a pointer to a stored string, you are seeing the same idea from the other side: the bytes are stored in the program, and an instruction computes their address at runtime.

That leaves one problem: to pass this path into the open syscall, you need to set its address in rdi. In the old days, programs would always be loaded to the same address in memory, and so you could hardcode this, as so:

_start:
    ...
    mov rdi, path    // this would tell the assembler to store the address of `path` in rdi
    ...
path:
    .asciz "/flag"

Unfortunately, THIS DOES NOT WORK in cybersecurity contexts! Modern software is compiled, for security reasons that we will cover in the Yellow belt, to be able to be loaded anywhere in memory. This means that, at the time of assembly of the software, the assembler doesn't know the right address. While this can be solved at start time for normal applications, modern CPUs have solved this problem in a different way: Instruction Pointer Relative Addressing.

On 64-bit x86, the instruction pointer (rip) is a register that always contains the address of the next instruction your CPU will execute. However, it is not a normal register, in the sense that its usage is more limited than something like rdi (note that this is a quirk of x86; many other architectures let you directly access their instruction pointer). That being said, 64-bit x86 does allow you to use addresses relative to rip for memory reads and writes. For example:

_start:
    ...
    mov rdi, [rip+path]
    ...
path:
    .asciz "/flag"

THIS IS STILL NOT WHAT WE WANT! Why? Because it reads the 8 bytes at [rip+path] into rdi rather than put the address of those bytes into rdi. rdi would end up holding the values 'f', and 'l', and so on, but the open syscall needs the address and not the values.

Luckily, there is an instruction that is almost a read, but instead does put the address that would have been read into rdi (or whatever other register). That instruction is load effective address (the word effective here refers to the CPU figuring out all the calculations it needs to do, such as adding an offset to the instruction pointer in this case):

_start:
    ...
    lea rdi, [rip+path]
    ...
path:
    .asciz "/flag"

This puts the address of the "/flag" string into rdi, rather than loading the contents of the string into rdi. Think of path as the address where the first byte of "/flag\0" lives: mov copies bytes from there, while lea copies the address so the kernel can walk those bytes until the null byte.

Now, a quick note about the math here: though we write [rip+path] above, what actually gets added to rip is the delta in addresses between rip (which, again, is pointing to the instruction after lea) and the "/flag" string. It's a weird syntax, and yet another little quirk of x86.

Use this in this challenge to set the path passed to open. Your program should open the stored filename, read from the returned fd into memory, write back exactly the number of bytes read returned (mov rdx, rax, as in read-exact), and exit with code 42. The new parts are:

1. Store the filename with .asciz after your code.
2. Load the filename address for open with lea rdi, [rip + path].

Run /challenge/check with your program, read the flag, and write it to stdout!

So far, your programs have been fairly straightforward: move some values around, read from memory, and invoke a system call. But real programs need to make decisions: "if this condition is true, do one thing; otherwise, do something else." This is the foundation of control flow, and it starts with being able to compare values.

In x86 assembly, comparisons are done with the cmp instruction. cmp compares two values by subtracting the second operand from the first. Crucially, cmp doesn't store the result of the subtraction anywhere you can see directly. Instead, it updates the CPU's internal flags based on what the result looked like.

For example:

cmp rdi, 42

This internally computes rdi - 42, but rdi is not modified. Instead, the CPU sets a special bit called the Zero Flag (ZF): if the result of the subtraction was zero (meaning the two values were equal), ZF is set to 1. If rdi contains 42, then 42 - 42 = 0, and ZF becomes 1. If rdi contains anything else, the result is non-zero, and ZF becomes 0.

Great, so after cmp, the CPU knows whether the values were equal. But how do we actually use that information?

We can't directly mov the flags into a register. Instead, x86 provides a family of "set on condition" instructions that write a 0 or 1 to a byte-sized destination based on the current flags.

The one we'll use here is setz ("Set if Zero"):

setz dil

This checks the Zero Flag and:

• If ZF = 1 (the values were equal, i.e., the subtraction result was zero), it writes 1 to dil.
• If ZF = 0 (the values were not equal), it writes 0 to dil.

Simple: 1 means "yes, they matched!" and 0 means "no, they didn't." There's also a complementary instruction, setnz ("Set if Not Zero"), which does the opposite, but we won't need it here.

But what is dil? So far, you've worked with 64-bit registers like rdi, rax, and rsp. The setz instruction, however, only writes a single byte (8 bits). Luckily, you can access smaller portions of the full 64-bit registers. For rdi:

• rdi is the full 64 bits
• dil is just the lowest 8 bits --- the low byte of rdi

When you write setz dil, you're putting a 0 or 1 into just the lowest byte of rdi, leaving the upper bytes unchanged. rdi is the value passed to the exit system call, but Linux reports only that value's low 8 bits as the process's exit status. That is why changing only dil is enough here: the visible status becomes 1 (equal!) or 0 (not equal!), regardless of the upper bytes of rdi.

One more thing about cmp: it can compare a register with an immediate (cmp rdi, 42) or even a memory location with an immediate (cmp QWORD PTR [rsp], 42). But it cannot compare two memory locations at once --- at most one operand can be a memory dereference.

Now, your challenge: recall from the Stack module that [rsp] contains argc --- the number of command-line arguments passed to your program, including the program name. Write a program that:

1. Compares argc with 42 (whether by first moving argc into a register or comparing against the memory directly).
2. Uses setz dil to set the exit code: 1 if argc equals 42, 0 otherwise.
3. Exits.

Now let's apply what you've learned to check a specific character in a command-line argument.

Recall from the Stack module that [rsp+16] holds a pointer to argv[1] --- the first command-line argument. To actually look at the argument text, you first need to load that pointer into a register:

mov rax, [rsp+16]

Now rax holds the address of the argument string. The first character of that string lives at [rax], the second at [rax+1], and so on.

To check whether the first character is, say, 'p':

cmp BYTE PTR [rax], 'p'

This reads one byte from the address in rax and compares it against the ASCII value of 'p'. Remember: BYTE PTR tells the CPU you're working with a single byte, not a full 64-bit value. You learned this back in the Output and Input module when you built strings on the stack byte by byte.

After the cmp, the Zero Flag reflects whether they matched, and you can capture that result with setz dil, just like before.

Your challenge: write a program that checks whether the first character of argv[1] is 'p'. Exit with 1 if it is, 0 if it isn't.

Your program should use 5 instructions:

1. Load the argv[1] pointer from [rsp+16] into a register.
2. Compare BYTE PTR at that address against 'p'.
3. Use setz dil to capture the result.
4. Set up the exit syscall number.
5. syscall.

In the previous challenges, you used setz to capture a comparison result as a 0 or 1 in dil, then passed that directly as your exit code. That was a neat trick --- but it has limitations. What if you want your program to take entirely different actions depending on whether the values were equal?

This is where conditional jumps come in. Instead of recording the comparison result into a register, you can tell the CPU to jump to a different part of your code based on the outcome of the cmp. The most useful conditional jump for our purposes is jne (Jump if Not Equal):

cmp BYTE PTR [rax], 'p'
jne fail

After the cmp, if the values were not equal, the CPU jumps to the location labeled fail. The terminology used for this is that it "takes the branch" (in the road/code). If the values were equal, the CPU simply continues to the next instruction. The terminology used for this is behavior of not taking the branch that it "falls through" to the next instruction.

Under the hood, jne checks the Zero Flag (ZF) that cmp set: jne jumps when ZF = 0 (meaning the subtraction result was non-zero, i.e., the values differed). There's also je (Jump if Equal), which does the opposite: it jumps when the values are equal.

But what is fail? It's a label --- a name you give to a location in your code. Labels don't generate any machine instructions; they just mark a spot that jump instructions can refer to. You define a label by writing its name followed by a colon:

fail:
  mov rdi, 1
  mov rax, 60
  syscall

The assembler resolves the label to an address, so jne fail becomes something like jne <address> in the actual machine code. You can name labels almost anything (fail, error, done, loop, etc.), but the name should describe what happens at that location.

With conditional jumps, your programs can now have two different paths of execution:

main:
  [load and compare]
  jne fail          ← jump to fail if NOT equal

success:
  mov rdi, 0
  mov rax, 60
  syscall

fail:
  mov rdi, 1
  mov rax, 60
  syscall

If the comparison succeeds (the values are equal), execution falls through to the success path and exits with 0 --- the standard "success" exit code for Linux programs. If the comparison fails (the values are not equal), execution jumps to the fail label and exits with 1 --- indicating program failure.

Of course, this is a simple example, but we'll start simple! The challenge: write a program that checks whether the first character of argv[1] is 'p', using conditional jumps instead of setz:

1. Load the argv[1] pointer from [rsp+16] into a register.
2. Compare BYTE PTR at that address against 'p'.
3. jne fail --- jump to the failure case if the characters aren't equal.
4. Write the "fall-through" success case (exit(0)).
5. Define the fail: label and write the fail case (exit(1)).

The tricky thing is that your success case (jump not taken) is between your jne instruction and the fail case that the jne instruction refers to. This can take a bit to wrap your head around, but you'll get used to it!

In the previous challenge, you used cmp and jne to check a single character and branch to a failure path. But checking one character is rarely sufficient: passwords, commands, and filenames are all strings of multiple characters.

The good news: you already know everything you need to check a whole string! You simply chain multiple cmp / jne pairs, one for each character, all jumping to the same fail label:

mov rax, [rsp+16]       ; load argv[1] pointer

cmp BYTE PTR [rax], 'Y'
jne fail

cmp BYTE PTR [rax+1], 'E'
jne fail

cmp BYTE PTR [rax+2], 'S'
jne fail

Each comparison checks one character of the string. Remember from the Computer Memory module that [rax+1] accesses the byte one past the address in rax, [rax+2] is two past, and so on. Since strings are stored as contiguous bytes in memory, [rax] is the first character, [rax+1] is the second, [rax+2] is the third, etc.

If any character doesn't match, jne immediately jumps to fail --- the program doesn't bother checking the rest. Only if all comparisons pass (all characters match) does execution fall through to the success path.

This is how many string comparisons work at the lowest level: compare byte by byte, bail out on the first mismatch.

Now, you will practice this. Write a program that checks whether the first argument starts with the string "pwn":

1. Load the pointer for the first argument from [rsp+16].
2. Compare byte at offset 0 against 'p' --- jne fail if it doesn't match.
3. Compare byte at offset 1 against 'w' --- jne fail if it doesn't match.
4. Compare byte at offset 2 against 'n' --- jne fail if it doesn't match.
5. Implement the success path: exit(0).
6. Implement the fail: label with exit(1).

In the previous challenge, you wrote assembly that compared strings character by character. Well, the tables have turned! We wrote a program, and you need to figure out what it does!

At /challenge/reverse-me, there's a SUID binary. It takes a command-line argument, compares it against a hidden password one byte at a time (sound familiar?) and, if the password is correct, reads and prints the flag. If any character is wrong, it silently exits.

How do you solve this? You must read the disassembly of the program, analyze the cmp instructions, understand the password that the program needs, then run it with the correct argument.

You already have the tools for this! From the Software Introspection module, remember: objdump -d -M intel /challenge/reverse-me disassembles the binary and shows its assembly instructions. You'll see familiar cmp instructions similar to those you wrote in the last challenge, but instead of the familiar ''-quoted characters, the compared-against values will be written as hex. The immediate values in those comparisons are the password characters, encoded as hexadecimal ASCII values.

For example, imagine that the disassembly shows:

cmp    BYTE PTR [rax],0x70

Here, 0x70 is the ASCII code for 'p'. You can get the full list of ASCII values by referencing the man ascii command.

Once you've recovered all the password characters, run the program directly:

hacker@dojo:~$ /challenge/reverse-me YOUR_PASSWORD_HERE

WARNING: /challenge/reverse-me is a SUID binary --- it runs with elevated privileges so it can read /flag. However, debugging a program will drop its SUID privileges, which means the open("/flag") syscall inside will silently fail if you run it under gdb. You can use gdb or objdump to understand the binary and figure out the password, but make sure to run it directly (outside of gdb) to get the flag.

In the previous challenge, you reverse-engineered cmp/jne pairs to recover a password. That technique checks each possibility one by one: compare, branch, compare, branch... But what if a program needs to branch to one of many different destinations based on a single value?

There's a more efficient approach: a jump table. A jump table is an array of addresses stored in memory, one for each possible destination (called a case). Instead of comparing the input against every possibility, the program uses the input value as an index into the table, loads the address stored at that position, and jumps to it. This pattern is called a switch, and it's a fundamental building block in programs.

In the disassembly, you'll see something like:

mov    rax, 0                    ; zero out rax
mov    al, BYTE PTR [rcx]        ; load the character into the low byte of rax
mov    rax, [rax*8+0x1234000]    ; load a stored address from the jump table at 0x1234000
jmp    rax                       ; jump to it

You've seen dil (the low byte of rdi) before, and al is the same idea for rax. Writing to al only changes the lowest 8 bits, leaving the rest of rax intact. That's why the code first zeros rax: it ensures the upper bytes are 0, so after mov al, [rcx], rax holds just the character's value (0--255).

The character's value directly indexes a table of 256 entries (one per possible byte value). Each entry is an 8 byte address pointing to code for that case. In this way, the program implements conditional logic without any conditional control flow!

This challenge (at /challenge/reverse-me) has 256 possible cases, with only one of them (corresponding to an alphanumeric character) being different than the others. Look at the jump table (you'll have to look at a lot of entries...), look at the program to understand how to influence the index, and get the flag!

When using gdb, give starti or run a one-byte placeholder argument (for example, starti A) so the program has an argv[1] to read.

NOTE: Though you should look at the disassembly using objdump -d -M intel /challenge/reverse-me, objdump will try to interpret the jump table data as assembly instructions, which will result in garbage. Ignore that section of the disassembly; you'll need to look at that data in gdb, instead.

HINT: You'll likely want to use gdb extensively in this challenge, and x/a will be your friend. For example, if you are in gdb at the instruction mov rax, [rax*8+0x1337000] (note, your address will differ), you can examine the jump table entries:

(gdb) print $rax
1
(gdb) x/a $rax*8+0x1337000
0x1337008:  0x400100
(gdb) x/a 2*8+0x1337000
0x1337010:  0x400100
(gdb) x/a 98*8+0x1337000
0x1337310:  0x400200
(gdb)

Once you find the table entry that points somewhere different, convert its table position back into the input byte. Use the address of that table slot (the address on the left side of the x/a output), not the address stored inside it. Subtract the table base from that slot address to get its offset into the table. Then divide by 8, because each table entry is an 8-byte address. In the example above, the unusual entry is at 0x1337310, so 0x1337310 - 0x1337000 = 0x310, and 0x310 / 8 = 98. That means the input byte has value 98, which ASCII represents as 'b'.

HINT: You can also print the whole jump table at the same time. The output will be long, but it starts like this:

(gdb) x/256a 0x1337000
0x1337000:  0x400100  0x400100
0x1337010:  0x400100  0x400100
...
(gdb)

The number after x/ is how many entries gdb should print. Since the input byte chooses one of 256 entries, and each entry is one 8-byte code address, this lets you scan the table for the one address that differs. If gdb prints multiple entries on one line, the address on the left is the first entry on that line; the next entry is 8 bytes later. As in the previous challenge, use gdb to understand the binary, then run /challenge/reverse-me directly with the recovered byte to get the flag.

So far, every control flow pattern you've seen executes in a straight line: compare, branch, done. But what if you need to repeat the same operation many times? That's what a loop is: a sequence of instructions that jumps backward to repeat itself.

In this challenge, /challenge/reverse-me compares argv[1] against the password using a loop:

loop:
  mov    al, BYTE PTR [rsi]       ; load next password character
  cmp    al, BYTE PTR [rdi]       ; compare against next argv[1] character
  jne    fail                     ; mismatch → jump to fail
  cmp    al, 0x0                  ; reached the null terminator?
  je     success                  ; yes → all characters matched!
  inc    rdi                      ; **inc**rement rdi to advance to next argv[1] character
  inc    rsi                      ; **inc**rement rsi to advance to next password character
  jmp    loop                     ; jump back to the top — repeat!

The key instruction is jmp loop at the bottom. Unlike jne (which only jumps when a condition is met), jmp unconditionally always jumps. By jumping backward to the loop label, the program re-executes the same comparison logic on the next pair of characters. The loop terminates when either a mismatch is found (jne fail) or the null terminator is reached at the end of the string after the other characters are successfully matched to the password (je success).

This is the fundamental pattern behind every for loop, while loop, and string operation you'll ever encounter in compiled code.

Analyze the binary, figure out the password, and get the flag!

In the previous challenge, you recognized a loop in a program someone else wrote. Now you will write one yourself.

A loop needs three pieces of state: where the current work is, how much progress has been made, and a test that decides when the loop is finished. For a string, the natural finish line is the null terminator: the 0 byte after the last character. Each trip through the loop checks the current byte, advances to the next byte, updates the count, and jumps back to repeat.

Write a program that computes the length of argv[1] and exits with that length as its exit code. Your program must inspect the string one byte at a time and use a backward jump to repeat the loop.

For example, if the argument is pwn, your program should exit with code 3. If the argument is empty, it should exit with code 0.

Submit it to /challenge/check, and get the flag!

So far, every program you've written has been a complete executable: it starts at _start, runs from there, and exits with a syscall. In this challenge, your code will be a single function inside a shared library, not a standalone executable.

A shared library (called a .so file on Linux) is a chunk of compiled code that some other program loads at runtime and calls into. Typically, such libraries perform utility functions, such as parsing image files (e.g., libpng parses PNG files) or handling general system-facing tasks (libc provides a lot of memory management, file management, and system interaction code). Deep inside, the actual interaction with the operating system takes place using system calls, but libraries provide a better interface to interact with than raw system calls.

This challenge plays the role of a program that loads your library (using libc's dlopen functionality), looks up your function by name, and calls it with arguments. In Computer Science nomenclature, your code is the callee and the challenge is the caller.

The call instruction.
How does the grader get into your code in the first place? It executes a new instruction you haven't met yet: call.

call <target> is x86's function-call instruction. It does two things:

1. Pushes the address of the next instruction after the call instruction (the return address) onto the stack.
2. Jumps to <target>.

In our case, the grader runs the equivalent of call solve, and execution lands at the top of your solve function. You don't have to do anything special to "receive" the call --- you just start running.

For this first challenge, you also don't have to do anything special to finish the call. We'll deal with the saved return address in the next challenge; for now, just end your code with the exit syscall you already know. This is the same shape as every program you've written so far --- the only thing that has changed is who started executing you.

Writing the function.
Your assembly should look like this:

.intel_syntax noprefix
.global solve
solve:
    <your code, ending in an exit syscall>

The .global solve line tells the assembler "expose this code so other code can find it" --- just like .global _start did for executables back in the building level. The solve: label actually specifies where the code is.

Building a shared library.
You already know how to assemble a program with as and link it with ld. To produce a shared library instead of an executable, pass -shared to ld:

hacker@dojo:~$ as -o your-solve.o your-solve.s
hacker@dojo:~$ ld -shared -o your-solve.so your-solve.o

Then submit the .so to the grader:

hacker@dojo:~$ /challenge/check your-solve.so

The calling convention.
When the grader calls solve, it passes arguments in registers. In the case of this challenge, your solve function takes two arguments:

You've already seen rdi used to hold the first argument of a syscall (the exit code, a file descriptor, etc.). That's because Linux syscalls and Linux functions use the same convention for the first few argument registers.

For this challenge, the challenge will pass you your flag as the buffer, with the flag's length in rsi. Write the rsi bytes starting at rdi to file descriptor 1 (stdout) using the write syscall (just like before!), and then exit the process cleanly with code 0. Get it right, and your solve will print your flag for you!

Hint: Keep in mind that write() takes arguments in the order of: file descriptor (1 in rdi for stdout), buffer (pointer to memory, in rsi), and size (in rdx). This is different from the arguments your function will be called with, so you'll need to move some stuff around!

Debugging your solution. Since your code is a function inside a shared library, there's no entry point to launch under gdb directly --- but you can give it one. Add a tiny _start to your code that fakes the grader's call: point rdi at a stand-in buffer, set rsi to its length, and call solve. Now you can step through your logic in plain gdb, with no flag and no privileges needed:

.global _start
_start:
    push 0x41414141   // put four 'A' bytes (0x41) on the stack to stand in for the flag
    mov rdi, rsp      // first argument: a pointer to those bytes
    mov rsi, 4        // second argument: how many bytes to print
    int3              // optional: gdb breaks here without setting a breakpoint
    call solve        // your solve runs, prints the bytes, and exits on its own

Assemble and link it as a normal executable (no -shared --- this version has an entry point), then load it in gdb:

hacker@dojo:~$ as -o debug.o debug.s
hacker@dojo:~$ ld -o debug debug.o
hacker@dojo:~$ gdb ./debug
(gdb) run

Execution stops at your int3; step through with the techniques from Software Introspection, watching the registers and the buffer. If your solve is correct, this prints AAAA --- and the same logic will print your real flag when you submit the .so to the grader.

You can also debug the native harness directly with stand-in bytes instead of the flag. /challenge/check is the Python checker script, so do not load it as the executable in gdb. The native program that loads your .so is /challenge/harness:

hacker@dojo:~$ gdb --args /challenge/harness your-solve.so
(gdb) run

The checker will run that same harness shape with the real flag when you submit your .so.

In the previous challenge, your solve function ended with an exit syscall. That worked, but it also meant the caller never got control back --- once you exited, the whole process was gone. In a real program, of course, this is not ideal.

A real callee is supposed to hand control back to whoever called it, so the caller can continue doing its own work. That's what the ret (return) instruction is for.

Recall the call instruction from the previous challenge: it pushed a return address onto the stack before jumping into your code. ret is the matching half: it pops that saved return address off the stack and jumps to it. Together, call and ret form the basic function-call/function-return pair in x86 --- one to get into a function, one to get back out.

In this challenge, your solve function has to return a value back to the challenge. In the Linux x86-64 calling convention, the return value of a function goes in rax. You've already seen rax used in syscalls --- it holds the syscall number on entry and the syscall's result on exit. The same register also holds the return value of a regular function.

The mechanics:

1. The challenge executes call solve, passing one argument in rdi. When it does this, the next instruction in the challenge after call solve gets pushed onto the stack as the "saved return address".
2. Your function does some work.
3. Your function puts its result in rax.
4. Your function executes ret, which pops the saved return address off the stack and jumps back to the challenge.
5. The challenge reads rax as your function's result ("return value").

For this challenge:

• rdi will contain a secret 64-bit value chosen at random by the challenge.
• Your function must return that same value back, in rax.

Once the challenge receives the correct value, it will give you the flag!

So far you've been on the callee side of a function call: the challenge called your solve, and you did the work. Now we flip it: your solve will receive a function pointer as an argument, and you have to call that function from your code.

A function pointer is just an address: a 64-bit value that names the location of some code in memory. The challenge passes the pointer in rdi (the first argument to your function), so to call it you can use the register form of call:

call rdi

This pushes the address of the instruction after the call (the return address) onto the stack, then jumps to the address held in rdi. When that callback eventually rets, your function's execution will continue right after your call rdi --- the same call/ret pair you learned in the previous two levels.

The callback prints the flag for you. Go for it!

In the previous level, you called the callback with call rdi --- easy, since the pointer was already in rdi. This time, you have to call it with 1337 as its first argument.

The calling convention says the first argument goes in rdi --- the same register the function pointer is in (because it's passed in as the first argument to your solve function). This means trouble:

• If you set rdi to 1337, you'll clobber the pointer (and then call rdi will try to call a function at address 1337 and crash)
• If you call rdi with rdi intact, you'll pass the function pointer as the first argument instead of 1337, and you won't get the flag.

This is an instance of a fundamental reality when dealing with assembly: your program has to share the same set of registers, and one function might want rdi for some different purpose than another. To resolve this contention, caller functions typically will push important registers to their local stack frame before invoking callees.

Anyways, here, the fix is simple: you have to use another register for the call, for example, by moving the callback function address into rax and then invoking call rax. That will free rdi for your argument!

In the last level you saw two functions fight over rdi. That's a glimpse of a bigger problem: there are only sixteen general-purpose registers, and every function in the program shares them. When you call a function, it's going to use registers for its own work, so what happens to the values you had in them?

The answer is determined by the Calling Convention of your architecture (in our case, 64-bit x86), which defines how functions pass arguments and share registers across function calls. Generally, a calling convention splits registers into two groups so that separately-written functions can cooperate:

• caller-saved registers may be freely overwritten by any function you call. If you have a value in one of these that you need after a call, it's your job (the caller's) to save it first and restore it afterward. Typically, this is done by pushing them to the stack before calling the callee and poping them off the stack later. On x86-64, these registers are rax (which callees will clobber by moving the return value to), rcx, rdx, rsi, rdi, r8, r9, r10, r11.
• callee-saved registers must be left untouched by the functions you call. Rather, callees can touch them, but they must restore them back to their original state. On x86-64, these are rbx, rbp, r12, r13, r14, r15.

Note that this convention is just that, a convention. Code can misbehave and violate this, though this doesn't really happen in practice with reasonable code.

This level forces you to explore caller-saved registers. Your solve function is given two arguments:

1. rdi: a pointer to a clobber_function that will clobber all caller-saved registers
2. rsi: a pointer to a flag_function that will give you the flag if you call it with your registers un-clobbered

You must call clobber_function before flag_function. But you must preserve your caller-saved registers before calling clobber_function and restore them afterwards.

Build your shared library and hand it to the grader:

hacker@dojo:~$ as -o your-solve.o your-solve.s
hacker@dojo:~$ ld -shared -o your-solve.so your-solve.o
hacker@dojo:~$ /challenge/check your-solve.so

Do it right, and the flag is yours!

You've practiced caller-saved registers, and now we'll cover callee-saved ones. The callee-saved registers (rbx, rbp, r12, r13, r14, r15) must come back unclobbered when the callee returns. When a function uses one of them, it is borrowing it from whoever called it, and it must return it in exactly the condition it was found. This is what lets a caller keep long-lived values in rbx, rbp, and r12-r15 across a call and trust they'll still be there afterward.

The rule is, when your function wants to use these registers, save (push) them on entry to your function, restore (pop) them before you ret.

This level puts you on the callee side. Your solve is called as solve(check_callee_clobbered) (the pointer is in rdi), and your caller has live values sitting in rbx, rbp, r12, r13, r14, r15 that it expects back untouched.

Your job:

1. Save off all the callee-saved registers.
2. Clobber them all by setting them to 0x1337.
3. Call check_callee_clobbered, which confirms you clobbered them.
4. Restore the callee-saved registers.
5. ret.

The challenge then checks that rbx, rbp, and r12-r15 came back exactly as the caller left them.

Build your shared library and hand it to the grader:

hacker@dojo:~$ as -o your-solve.o your-solve.s
hacker@dojo:~$ ld -shared -o your-solve.so your-solve.o
hacker@dojo:~$ /challenge/check your-solve.so

Borrow them, give them back, and claim the flag.

You have seen that byte, word, dword, and qword describe how many bytes an instruction reads or writes. Now add one more wrinkle: a smaller value can be copied into a larger register as either unsigned or signed.

If the byte is unsigned, filling the high bytes with zero is fine: 0x7f becomes 0x000000000000007f. But a signed byte uses two's complement. The byte 0xff is -1, so extending it to 64 bits must fill the new high bits with 1s: 0xffffffffffffffff.

That is sign extension. It copies the sign bit, not zeroes, into the new high bits. On x86-64, the form you need here is:

movsx rax, BYTE PTR [rdi]

This reads one byte from the address in rdi, treats that byte as signed, and returns the 64-bit signed value in rax.

Write a function called solve that takes a pointer to one byte in rdi. Load that byte as a signed 8-bit value, sign-extend it to 64 bits, return it in rax, and export it with .global solve.

Build it into a shared library and hand it to the grader:

hacker@dojo:~$ as -o solve.o solve.s
hacker@dojo:~$ ld -shared -o solve.so solve.o
hacker@dojo:~$ /challenge/check solve.so

You just read how x86 stores multi-byte values little-endian --- low byte first. Time to use it: /challenge/reverse-me hides an 8-character password in a single qword, deep in its own code.

It loads your input and compares all 8 bytes at once against a hard-coded value:

movabs rbx, 0x4847464544434241
mov    rax, [rdi]
cmp    rax, rbx
jne    fail

(movabs is new, but it's just a mov: a normal mov's immediate maxes out at 32 bits, so the assembler uses this wider form --- "move absolute" --- when the constant fills all 64. Read it as a mov.)

That immediate is the password as the CPU read it from memory --- little-endian, so its bytes are the characters in reverse:

0x4847464544434241  ->  bytes 48 47 46 45 44 43 42 41  (high to low, as printed)
                    ->  low byte first: 41 42 43 44 45 46 47 48  ->  "ABCDEFGH"

Disassemble it, read that one movabs immediate, reverse its eight bytes into the password, and run it:

hacker@dojo:~$ objdump -d -M intel /challenge/reverse-me
hacker@dojo:~$ /challenge/reverse-me YOUR_PASSWORD_HERE

WARNING: /challenge/reverse-me is a SUID binary, so debugging it drops its privileges and the open("/flag") inside will silently fail under gdb. Use objdump to read it, but run it directly to get the flag.

You've seen that a multi-byte value sits in memory low byte first, so reading one back into a register reverses its bytes. A single register tops out at eight bytes, but plenty of values are wider than that (and wider than the CPU can easily access at one time).

Depending on the program, such values might be accessed sequentially, register-width by register-width. For example, consider a 16-byte password, as you will experience in this challenge. The sixteen ASCII bytes, read as two 8-byte qwords, might be accessed like this:

As a string value stored in memory byte by byte, that ordering is not affected by endianness. What endianness flips is the bytes as they end up in a register after the mov: each one, being a multi-byte value, still reads back low byte first. So if rdi is pointing to this buffer, a mov rsi, [rdi] would end up with the value 0x4847464544434241, and the next mov rsi, [rdi+8] would have the value 0x504f4e4d4c4b4a49.

So to rebuild a longer value: keep the qwords in the order you get them, but reverse the bytes inside each one.

Disassemble /challenge/reverse-me, read the two qword values it checks your input against, endian-correct each one, concatenate them in order, and run it with the result:

hacker@dojo:~$ objdump -d -M intel /challenge/reverse-me
hacker@dojo:~$ /challenge/reverse-me YOUR_PASSWORD_HERE

WARNING: /challenge/reverse-me is a SUID binary, so debugging it drops its privileges and the open("/flag") inside will silently fail under gdb. Use objdump to read it, but run it directly to get the flag.

Endianness isn't special to 64-bit values. Every integer read from memory comes back little-endian, and the bytes that get reversed are exactly the ones covered by that read. For example, consider the following bytes, contiguously chilling in memory pointed to by rdi:

rdi -> 11 22 33 44 55 66 77 88

If you read all 8 bytes into, say, rsi with mov rsi, [rdi], rsi will have the value of 0x8877665544332211. You could also read it as two 32-bit (4 byte) values (into, say, the 4-byte partial registers esi and edx, which are 32 bits of rsi and rdx, respectively):

mov esi, [rdi]      // results in 0x44332211 in esi
mov edx, [rdi+4]    // results in 0x88776655 in edx

This makes sense written out, but it can confuse some people. Specifically, what does not happen is the reversal of the whole 8-byte value (in which case, esi above would have the 0x88).

You'll practice this in this challenge. /challenge/reverse-me checks the same kind of password four bytes at a time, as 32-bit values (termed "dwords"), so you get four integers instead of two. Each dword still reverses its own four bytes; the dwords themselves stay in address order, just like the qwords did. Because a dword fits the normal immediate size, each check is a direct cmp eax, 0x........ --- the value to recover is right there in the instruction:

mov eax, [rdi+0]
cmp eax, 0x44434241
jne fail

Disassemble /challenge/reverse-me, read the four cmp eax immediates, endian-correct each dword, concatenate them in address order, and run it with the result:

hacker@dojo:~$ objdump -d -M intel /challenge/reverse-me
hacker@dojo:~$ /challenge/reverse-me YOUR_PASSWORD_HERE

WARNING: /challenge/reverse-me is a SUID binary, so debugging it drops its privileges and the open("/flag") inside will silently fail under gdb. Use objdump to read it, but run it directly to get the flag.

Smaller still: /challenge/reverse-me now checks two bytes at a time, as words.

The rule never changes --- the bytes that reverse are exactly the ones in the read. A word read swaps its two bytes; the words stay in address order. (And a one-byte read has nothing to swap, which is why single bytes never need endian-correcting.)

Disassemble /challenge/reverse-me, read the eight cmp ax, 0x.... immediates, swap each pair, keep the words in address order, and run it:

hacker@dojo:~$ objdump -d -M intel /challenge/reverse-me
hacker@dojo:~$ /challenge/reverse-me YOUR_PASSWORD_HERE

WARNING: /challenge/reverse-me is a SUID binary, so debugging it drops its privileges and the open("/flag") inside will silently fail under gdb. Use objdump to read it, but run it directly to get the flag.

One byte at a time, in the 8-bit register al:

mov al, [rdi+0]
cmp al, 0x41
jne fail

And here's the payoff. A single byte has no order to reverse, so the immediates are the characters, already in order --- 0x41 is just 'A'. Sixteen byte-compares, and no endian-correcting at all.

This is the far end of the rule you've been applying: the reversal unit is the read size, so a one-byte read reverses nothing. Read the immediates straight down the disassembly and run it.

hacker@dojo:~$ objdump -d -M intel /challenge/reverse-me
hacker@dojo:~$ /challenge/reverse-me YOUR_PASSWORD_HERE

WARNING: /challenge/reverse-me is a SUID binary, so debugging it drops its privileges and the open("/flag") inside will silently fail under gdb. Use objdump to read it, but run it directly to get the flag.

Real programs rarely read a buffer at one uniform size. They read structs: a handful of fields of different sizes, laid out one after another in memory (in fact, struct is structure for short).

This /challenge/reverse-me treats your password as a struct. You might not know the C programming language, but if you did, this is what the structure would be defined as:

struct { uint64_t a; uint32_t b; uint16_t c; uint8_t d; uint8_t e; };

The disassembly loads each field at its own width and offset:

movabs rbx, 0x................   ; a: 8-byte field at +0
mov    rax, [rdi+0]
cmp    rax, rbx
mov    eax, [rdi+8]               ; b: 4-byte field at +8
cmp    eax, 0x........
mov    ax,  [rdi+12]              ; c: 2-byte field at +12
cmp    ax,  0x....
mov    al,  [rdi+14]              ; d: 1-byte field at +14
cmp    al,  0x..
mov    al,  [rdi+15]              ; e: 1-byte field at +15
cmp    al,  0x..

This is the whole module in one challenge. For each field, read three things off the access: its width (from rax/eax/ax/al), its offset ([rdi+X]), and its value (endian-correct the immediate according to the field's width). Reassemble the fields in offset order and you have the password.

hacker@dojo:~$ objdump -d -M intel /challenge/reverse-me
hacker@dojo:~$ /challenge/reverse-me YOUR_PASSWORD_HERE

WARNING: /challenge/reverse-me is a SUID binary, so debugging it drops its privileges and the open("/flag") inside will silently fail under gdb. Use objdump to read it, but run it directly to get the flag.

The last struct read its fields top to bottom, in memory order, so reading the disassembly straight down handed you the password already in order. Nothing guarantees that. A program can check a struct's fields in any order it likes --- the order the compares appear in the code has nothing to do with where those bytes live in memory.

This /challenge/reverse-me checks the same five fields, but scrambled:

mov    ax,  [rdi+12]              ; the +12 word might be checked first...
cmp    ax,  0x....
mov    al,  [rdi+15]              ; ...then a byte from the very end...
cmp    al,  0x..
movabs rbx, 0x................    ; ...then the +0 qword, and so on.
mov    rax, [rdi+0]
cmp    rax, rbx

So you can no longer read the password straight down the disassembly. Recover each field's value exactly as before, but now also read its offset from the [rdi+X] load --- that offset is where the bytes belong. Place each field at its offset, concatenate in offset order, and you have the password.

hacker@dojo:~$ objdump -d -M intel /challenge/reverse-me
hacker@dojo:~$ /challenge/reverse-me YOUR_PASSWORD_HERE

WARNING: /challenge/reverse-me is a SUID binary, so debugging it drops its privileges and the open("/flag") inside will silently fail under gdb. Use objdump to read it, but run it directly to get the flag.

In the previous challenge, you reversed a program by finding password characters directly in the cmp instructions. This time, the program transforms your input before comparing it. You'll need to understand and mentally invert this operation to successfully pass the check!

At /challenge/reverse-me, there's a new SUID binary. It will do some math on the first byte of the first program argument, and compare it against a hardcoded value. If the comparison passes, it reads and prints the flag. Otherwise, it silently exits.

The new instruction here is add, as so:

add rax, 42

This adds 42 to the rax register and updates rax with the result. The following would result in rax having the value 99:

mov rax, 57
add rax, 42

Like many other instructions, add can handle memory, registers, or immediates, when you disassemble this binary with objdump -d -M intel /challenge/reverse-me, you might see something like:

add    BYTE PTR [rax],0x2a
cmp    BYTE PTR [rax],0x96

This adds 0x2a (42) to the first byte of your input (in memory), then checks if the result equals 0x96 (150). To figure out what character you need, just reverse the math: 150 - 42 = 108 (6c). Looking at man ascii, 0x6c is the character 'l'. So the required input character in this case is l (remember, man ascii is your friend for converting between hex values and characters)!

Once you've figured out the character, run the program:

hacker@dojo:~$ /challenge/reverse-me YOUR_CHARACTER_HERE

Now it's your turn! Go and get the flag.

WARNING: /challenge/reverse-me is a SUID binary --- it runs with elevated privileges so it can read /flag. However, debugging a program will drop its SUID privileges, which means the open("/flag") syscall inside will silently fail if you run it under gdb. You can use gdb or objdump to understand the binary, but make sure to run it directly (outside of gdb) to get the flag.

In the previous challenge, the program used add to transform your input before checking it. This time, it uses sub (as in, subtract) instead. Analogous to add, sub rax, 42 will subtract 42 from rax and store the result in rax.

Otherwise, this challenge is the same as the previous one. Go get it!

This challenge introduces a new type of operation: bitwise XOR. Unlike add and sub, which do arithmetic, xor operates on individual bits.

The xor instruction computes the exclusive or of two values: for each bit position, the result is 1 if exactly one of the two input bits is 1, and 0 otherwise. For example:

  01100001  (0x61, 'a')
^ 00101010  (0x2a, 42)
---------
  01001011  (0x4b, 75)

In diagrams and expressions such as 0x4b ^ 0x2a, ^ means XOR; in assembly, the instruction is xor. The syntax is the same as add and sub: xor rax, 42.

A key property of XOR is that it's its own inverse: xoring a value with the same value twice gives back the original value. So if you see:

xor    BYTE PTR [rax],0x2a
cmp    BYTE PTR [rax],0x4b

The program XORs your input byte with 0x2a and checks if the result is 0x4b. To reverse this, XOR the target with the key: 0x4b ^ 0x2a = 0x61, which is 'a'.

Now: disassemble the binary, reverse the XOR, and get the flag!