2.1 Getting Files
You can obtain your files from the Autolab site
https://ics.autolabproject.com
After logging in to Autolab, select Attacklab -> Download handout. The Autolab server will
build your files and return them to your browser in a tar file called targetk.tar, where k is the unique
number of your target programs.
Note: It takes about 15 seconds to build and download your target, so please be patient.
Save the targetk.tar file in a (protected) Andrew directory in which you plan to do your work. Then
login to a shark machine and give the command: tar -xvf targetk.tar. This will extract a directory
targetk containing the files described below.
You should only download one set of files. If for some reason you download multiple targets, choose one
target to work on and delete the rest.
Warning: If you expand your targetk.tar on a PC, by using a utility such as Winzip, or letting your
browser do the extraction, you’ll risk resetting permission bits on the executable files.
The files in targetk include:
README.txt: A file describing the contents of the directory
ctarget: An executable program vulnerable to code-injection attacks
rtarget: An executable program vulnerable to return-oriented-programming attacks
cookie.txt: An 8-digit hex code that you will use as a unique identifier in your attacks.
farm.c: The source code of your target’s “gadget farm,” which you will use in generating return-oriented
programming attacks.
hex2raw: A utility to generate attack strings.
In the following instructions, we will assume that you have already copied the files to a protected local
directory, and that you are executing the programs in that local directory.

2.2 Important Points
Here is a summary of some important rules regarding valid solutions for this lab. These points will not make
much sense when you read this document for the first time. They are presented here as a central reference
of rules once you get started.
• You must do the assignment on one of the class shark machines. There are ten machines available to
students to use, a full list of which can be found on the course Web site at:
http://www.cs.cmu.edu/˜18213/labmachines.html
• Your solutions may not use attacks to circumvent the validation code in the programs.
• You may only construct gadgets from file rtarget with addresses ranging between those for func
tions start_farm and end_farm.
• You can use any gadgets you discover in the farm, not just those for which we give the byte codes in
Figure 3.
• You are allowed to use the standard tools for this assignment: gdb (or lldb), objdump, and any tool
that you create (from scratch) on your own.
• You are not allowed to use tools or gdb plugins that are designed to assist in implementing buffer
overflow and ROP attacks.
• It is highly recommended that you gdb to confirm that your exploit is placed on the stack with the
correct byte ordering
• It is not uncommon for gdb to get lost while performing exploit code. You may be unable to step
through your exploit in gdb while seeing all of the usual diagnostic information.

3 Target Programs
Both CTARGET and RTARGET read strings from standard input. They do so with the function read and process line
defined below:
This function reads a byte sequence from standard input, terminated by either a newline (’\n’), or end of
file (EOF). Then it calls another function, process line, passing it the bytes that were read. (It does not
add a NUL terminator to the bytes it reads, so what it passes to process line is not a “string.” Instead,
it passes the number of bytes read as process line’s second argument.)
In the code sample, you can see that read and process line stores the byte sequence in a local vari
able buf, an array of BUFFER_SIZE bytes. (BUFFER_SIZE is a compile-time constant, specific to your
version of CTARGET and RTARGET.) Notice that the while loop does not stop when BUFFER_SIZE bytes
have been read. This is the same bug that’s found in the C library function gets: it keeps reading data until
end of line or file, possibly overrunning the bounds of the storage allocated for the data.

(Note that the value on the Cookie: line will differ from yours.)
Program RTARGET will have the same behavior. As the error
message indicates, overrunning the buffer typically causes the program state to be corrupted, leading to a
memory access error. Your task is to be more clever with the strings you feed CTARGET and RTARGET so
that they do more interesting things. These are called exploit strings.
Both CTARGET and RTARGET take several different command line arguments:
-h: Print list of possible command line arguments
-i FILE: Supply input from a file, rather than from standard input
Your exploit strings will typically contain byte values that do not correspond to the ASCII values for printing
characters. The program HEX2RAW will enable you to generate these raw strings. See Appendix A for more
information on how to use HEX2RAW.
Important points:
• Your exploit string must not contain byte value 0x0a at any intermediate position, since this is the
ASCII code for newline (‘\n’). When Gets encounters this byte, it will assume you intended to
terminate the string.
• HEX2RAW expects two-digit hex values separated by one or more white spaces. So if you want to
create a byte with a hex value of 0, you need to write it as 00. To create the word 0xdeadbeef
you should pass “ef be ad de” to HEX2RAW (note the reversal required for little-endian byte
ordering).
Unlike the Bomb Lab, there is no penalty for making mistakes in this lab. Feel free to fire away at CTARGET
and RTARGET with any strings you like.1
Figure 1 summarizes the five phases of the lab. As can be seen, the first three involve code-injection (CI)
attacks on CTARGET, while the last two involve return-oriented-programming (ROP) attacks on RTARGET.

4 Part I: Code Injection Attacks
For the first three phases, your exploit strings will attack CTARGET. This program is set up in a way that
the stack positions will be consistent from one run to the next and so that data on the stack can be treated as
executable code. These features make the program vulnerable to attacks where the exploit strings contain
the byte encodings of executable code.

4.1 Level 1
For Phase 1, you will not inject new code. Instead, your exploit string will redirect the program to execute
an existing procedure.
Function read and process line is called within CTARGET by a function test having the following
C code:
When read and process line executes its return statement (line 5 of read and process line),
the program ordinarily resumes execution within function test (at line 5 of this function). We want to
change this behavior. Within the file ctarget, there is code for a function touch1 having the following
C representation:
Your task is to get CTARGET to execute the code for touch1 when read and process line executes
its return statement, rather than returning to test. Note that your exploit string may also corrupt parts
of the stack not directly related to this stage, but this will not cause a problem, since touch1 causes the
program to exit directly.
Some Advice:
• All the information you need to devise your exploit string for this level can be determined by exam
ining a disassembled version of CTARGET. Use objdump -d to get this dissembled version.
• The idea is to position a byte representation of the starting address for touch1 so that the ret
instruction at the end of the code for read and process line will transfer control to touch1.
• Be careful about byte ordering. Remember, arrays (such as strings) are saved in index order, but
values like integers are evaluated in little-endian.
• You might want to use GDB to step the program through the last few instructions of read and process line
to make sure it is doing the right thing.
• The placement of buf within the stack frame for read and process line depends on the value
of compile-time constant BUFFER_SIZE, as well the allocation strategy used by GCC. You will need
to examine the disassembled code to determine its position.

4.2 Level 2
Phase 2 involves injecting a small amount of code as part of your exploit string.
Within the file ctarget there is code for a function touch2 having the following C representation:
Your task is to get CTARGET to execute the code for touch2 rather than returning to test. In this case,
however, you must make it appear to touch2 as if you have passed your cookie as its argument.
Some Advice:
• You will want to position a byte representation of the address of your injected code in such a way that
ret instruction at the end of the code for read and process line will transfer control to it.
• Recall that the first argument to a function is passed in register %rdi.
• Your injected code should set the register to your cookie, and then use a ret instruction to transfer
control to the first instruction in touch2.
• Do not attempt to use jmp or call instructions in your exploit code. The encodings of destination
addresses for these instructions are difficult to formulate. Use ret instructions for all transfers of
control, even when you are not returning from a call.
• See the discussion in Appendix B on how to use tools to generate the byte-level representations of
instruction sequences.

4.3 Level 3
Phase 3 also involves a code injection attack, but passing a string as argument.
Within the file ctarget there is code for functions hexmatch and touch3 having the following C
representations:
Your task is to get CTARGET to execute the code for touch3 rather than returning to test. You must
make it appear to touch3 as if you have passed a string representation of your cookie as its argument.
Some Advice:
• You will need to include a string representation of your cookie in your exploit string. The string should
consist of the eight hexadecimal digits (ordered from most to least significant) without a leading “0x.”
• Recall that a string is represented in C as a sequence of bytes followed by a byte with value 0. Type
“man ascii” on any Linux machine to see the byte representations of the characters you need.
• Your injected code should set register %rdi to the address of this string.
• When functions hexmatch and strncmp are called, they push data onto the stack, overwriting
portions of memory that held the buffer used by read and process line. As a result, you will
need to be careful where you place the string representation of your cookie.

5 Part II: Return-Oriented Programming
Performing code-injection attacks on program RTARGET is much more difficult than it is for CTARGET,
because it uses two techniques to thwart such attacks:
• It uses randomization so that the stack positions differ from one run to another. This makes it impos
sible to determine where your injected code will be located.
• It marks the section of memory holding the stack as nonexecutable, so even if you could set the
program counter to the start of your injected code, the program would fail with a segmentation fault.
Fortunately, clever people have devised strategies for getting useful things done in a program by executing
existing code, rather than injecting new code. The most general form of this is referred to as return-oriented
programming (ROP) [1, 2]. The strategy with ROP is to identify byte sequences within an existing program
that consist of one or more instructions followed by the instruction ret. Such a segment is referred to as a
gadget. Figure 2 illustrates how the stack can be set up to execute a sequence of n gadgets. In this figure, the
stack contains a sequence of gadget addresses. Each gadget consists of a series of instruction bytes, with the
final one being 0xc3, encoding the ret instruction. When the program executes a ret instruction starting
with this configuration, it will initiate a chain of gadget executions, with the ret instruction at the end of
each gadget causing the program to jump to the beginning of the next.
A gadget can make use of code corresponding to assembly-language statements generated by the compiler,
especially ones at the ends of functions. In practice, there may be some useful gadgets of this form, but not
enough to implement many important operations. For example, it is highly unlikely that a compiled function
would have popq %rdi as its last instruction before ret. Fortunately, with a byte-oriented instruction
set, such as x86-64, a gadget can often be found by extracting patterns from other parts of the instruction
byte sequence.
The chances of this function being useful for attacking a system seem pretty slim. But, the disassembled
machine code for this function shows an interesting byte sequence:
The byte sequence 48 89 c7 encodes the instruction movq %rax, %rdi. (See Figure 3A for the
encodings of useful movq instructions.) This sequence is followed by byte value c3, which encodes the
ret instruction. The function starts at address 0x400f15, and the sequence starts on the fourth byte of
the function. Thus, this code contains a gadget, having a starting address of 0x400f18, that will copy the
64-bit value in register %rax to register %rdi.
Your code for RTARGET contains a number of functions similar to the setval_210 function shown above
in a region we refer to as the gadget farm. Your job will be to identify useful gadgets in the gadget farm and
use these to perform attacks similar to those you did in Phases 2 and 3.
Important: The gadget farm is demarcated by functions start_farm and end_farm in your copy of
rtarget. Do not attempt to construct gadgets from other portions of the program code

5.1 Level 2
For Phase 4, you will repeat the attack of Phase 2, but do so on program RTARGET using gadgets from your
gadget farm. You can construct your solution using gadgets consisting of the following instruction types,
and using only the first eight x86-64 registers (%rax–%rdi).
movq : The codes for these are shown in Figure 3A.
popq : The codes for these are shown in Figure 3B.
ret : This instruction is encoded by the single byte 0xc3.
nop : This instruction (pronounced “no op,” which is short for “no operation”) is encoded by the single
byte 0x90. Its only effect is to cause the program counter to be incremented by 1.
Some Advice:
• All the gadgets you need can be found in the region of the code for rtarget demarcated by the
functions start_farm and mid_farm.
• You can do this attack with just two gadgets.
• When a gadget uses a popq instruction, it will pop data from the stack. As a result, your exploit
string will contain a combination of gadget addresses and data.

5.2 Level 3
Before you take on the Phase 5, pause to consider what you have accomplished so far. In Phases 2 and 3,
you caused a program to execute machine code of your own design. If CTARGET had been a network server,
you could have injected your own code into a distant machine. In Phase 4, you circumvented two of the
main devices modern systems use to thwart buffer overflow attacks. Although you did not inject your own
code, you were able inject a type of program that operates by stitching together sequences of existing code.
You have also gotten 95/100 points for the lab. That’s a good score. If you have other pressing obligations
consider stopping right now.
Phase 5 requires you to do an ROP attack on RTARGET to invoke function touch3 with a pointer to a string
representation of your cookie. That may not seem significantly more difficult than using an ROP attack to
invoke touch2, except that we have made it so. Moreover, Phase 5 counts for only 5 points, which is not a
true measure of the effort it will require. Think of it as more an extra credit problem for those who want to
go beyond the normal expectations for the course.
To solve Phase 5, you can use gadgets in the region of the code in rtarget demarcated by functions
start_farm and end_farm. In addition to the gadgets used in Phase 4, this expanded farm includes
the encodings of different movl instructions, as shown in Figure 3C. The byte sequences in this part of the
farm also contain 2-byte instructions that serve as functional nops, i.e., they do not change any register or
memory values. These include instructions, shown in Figure 3D, such as andb %al,%al, that operate on
the low-order bytes of some of the registers but do not change their values.
• You’ll want to review the effect a movl instruction has on the upper 4 bytes of a register, as is
described on page 183 of the text.
• The official solution requires a sequence of eight gadgets. Depending on the contents of your farm
(each target has a different one), you may be able find a shorter one.
• Remember: Your exploit string must not contain the newline character (byte value 0x0a) at any inter
mediate position

6 Logistical Notes
Whenever you correctly solve a phase, your target program will send a message to Autolab. The server
will test your exploit string to make sure it really works, (From Autolab, follow Attacklab -> View
scoreboard). This Web page is updated every minute or so to show the progress for each target. You
should be sure to check this page after your submission to make sure your string has been validated. (If
you really solved the phase, your string should be valid. But, an attack that works on your copy of one
of the targets may be rejected by the version on the server, if it does not correctly implement the specified
functionality.)
Each phase is graded individually. You do not need to do them in the specified order, but you will get credit
only for the phases for which the server receives a valid message.
Good luck and have fun!