[SOLVED] Cs6035 projects / binary exploitation

CS 6035

Projects / Binary Exploitation / Flag 03 – XORbius
Task 03_XORbius
Time to rev up those Reverse Engineering motors, because you need to unravel the logic that this program is checking against in order to get to the call_me() function!
No buffer overflow this time, you just ‘simply’ need to input the right values that will correctly decode the logic and pass the checks.
If you’re unfamiliar with C operators, this TUTORIAL has all the necessary operations detailed.
Suggest pen and paper for this one to work through the logic by hand, or do a ton of experimentation to get the right value!
XOR TRUTH TABLE

XOR Operations are REVERSIBLE, meaning that performing the same XOR operation on a number twice will end up with the original number!
Example:
0b11110000 ^ 0b00001111 = 0b11111111
=>
0b11111111 ^ 0b00001111 = 0b11110000
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/03_XORbius.html 1/2 Flag 03 – XORbius | CS 6035
in Hex notation
0xF0 ^ 0x0F = 0xFF
=>
0xFF ^ 0x0F = 0xF0
Some students have likewise found it helpful to try and break down some of the elements of the binary within their own toy code; below is an example of such an effort using Programmiz.com:

Disclaimer: You are responsible for the information on this website. The content is subject to change at any time.
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/03_XORbius.html 2/2 Flag 03 – Pointy | CS 6035
CS 6035

Projects / Binary Exploitation / Flag 03 – Pointy
Task 03_pointy_pointy_point
We see there is an unsafe() function which has some checks for different local variables. The positioning of these variables is important because they are declared before the input buffer which means that a buffer overflow will cause data to be overwritten.
This program is a Buffer Overflow, however you will not be changing the control flow to a specific binary address (i.e. overwriting ret), rather you will need to enter in the right values to trick the pointer arithmetic logic and get to the call_me() function.
Some students have likewise found it helpful to try and break down some of the elements of the binary within their own toy code; below is an example of such an effort using Programmiz.com:

Disclaimer: You are responsible for the information on this website. The content is subject to change at any time.
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/03_pointy_pointy_point.html 1/1 Flag 03 – Hunt/ROP | CS 6035
CS 6035

Projects / Binary Exploitation / Flag 03 – Hunt/ROP
Task 03_hunt_then_rop
You’ve made it! You are now on your final task. In this directory is the entire contents of /usr/bin, a collection of binary files that make up a lot of common linux uses. One of these files has been overwritten by our vulnerable flag program. It is your task to figure out which one.
NOTE: just to make it explicitly clear, you will not find a binary named “flag” in this directory. There IS a binary compiled from the flag.c source code present, but it is renamed to something else, overwriting/replacing that binary.
To help sort out what’s going on, we’ve supplied you with a checksums file. Inside the checksums file is – as you might guess – a list of known good checksums generated by the linux shasum command. You should leverage this checksums file to figure out which binary present is the vulnerable one; you are free to do this however you would like.
NOTE: we suggest skipping over the ‘checksums’ file itself (as well as any additional files you might introduce during your hunt).
Once you find the file it is time to begin our exploit. This is a bit more complex than the other flags and will require a full ROP (return oriented programming) exploit to chain calls together, and we will also need a new tool called Ropper to find a ‘gadget’ in order to supply a function argument and pass a specific check.
In 64-bit programs, the function gets arguments through registers, in the case of intel architecture the RDI register supplies the first function argument.
So we need to find a gadget (a piece of code that we can override the instruction pointer with, that will perform a certain action and then continue with the control flow hijack) that will pop a value from the stack into the RDI register.
Let’s use ropper like this
$ ropper –file flag | grep ‘pop’
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/03_hunt_then_rop.html 1/2 Flag 03 – Hunt/ROP | CS 6035
This will give you all gadgets within the binary that have a keyword ‘pop’ (spoiler, there’s a LOT of them). An objective for this task is to figure out what gadget will likely work best to get the required argument passed into the function you are trying to call. This Writeup is a helpful reference to understand how calling convention works for x86_64 cpu’s
Note the addresses that are output for each gadget. Once you find a gadget you think will work, we will need that as our first override value in pwntools
Pictorially, this is what our crafted exploit needs to look like (remember stack grows down)

Now we will need to supply the argument, which will be on the stack immediately after our pop gadget, figure out what that value needs to be, and add it as p64() after the pop gadget
Then we need to put the address of the function as the next call, use objdump or gdb to find the addresses (you should probably get the second function address while you’re at it). The call to our pop gadget will ‘ret’ and then hit this second function call to enter one of the unsafe functions
Finally, we need to finish our execution chain by calling the second function which will allow for exploitation. Append that address to your chain and see if you get a flag!
Disclaimer: You are responsible for the information on this website. The content is subject to change at any time.
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/03_hunt_then_rop.html 2/2 Flag 02 – Server/Client | CS 6035
CS 6035

Projects / Binary Exploitation / Flag 02 – Server/Client
Task 02_the_server_client_one
This flag shows a communication between a server and a client. The client binary (flag) will send data to the server, and the server appends some (very conveniently structured) data to that message and sends it back to the client. Your goal for this task is to have the server return the ideal data to overwrite the instruction pointer with the data that is returned from the server.
Follow the same steps in previous tasks (buffer_overflow_2, more specifically) to break the program in gdb, and then figure out your buffer size, and try to fill in the response to correctly hit this function call!
If you use the pwntools e.py file, it will start the server for you so there is no need to explicitly start the server.
If you are running the program on the command line to experiment, then you must start the server each time you run the binary. You can either open a new terminal, and run ./server Or in the same terminal, each time you run the binary, run
./server &
Your task is to figure out the breaking point, and heavily inspect the last bytes that are returned from the server in order to get the right return and get the flag!
Disclaimer: You are responsible for the information on this website. The content is subject to change at any time.
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/02_the_server_client_one.html 1/1

Flag 02 – Password | CS 6035
Flag 02 – Password
Task 02_p4s5w0rd
STRINGS!
Now it’s time to learn a really useful technique to find all the available strings in a program.
And by strings, we mean any collection of printable characters that exist in the binary. So things like variable names, hardcoded paths, debug messages, or eeeeevenn…. passwords? Hopefully not in a real program but you would be surprised.
This binary has zero debugging information and you do not have the source code available, but guess what? The program is written terribly and is very unsafe, with passwords stored in plain text that can easily be dumped/searched in the binary!
I would recommend running the program once or twice to see what it’s doing (checking a series of responses to questions) and if you get every question right, then you will get the flag!
To get the strings for the program, run the command:
$ strings flag
This will output it all to the terminal which isn’t super helpful, so would suggest redirecting output to a file like:
$ strings flag > flag_str
Now you will be able to grep/search/navigate the file in a new terminal and will (hopefully) be able to figure out what the correct responses would be for the given questions.
(hint, strings are stored in the binary in the order that they’re written in the C code, might be a good idea to search for the questions they’re asking and it should be pretty easy to determine the answer from there!) Good luck!
Disclaimer: You are responsible for the information on this website. The content is subject to change at any time.
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/02_p4s5w0rd.html
Flag 02 – Password | CS 6035
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/02_p4s5w0rd.html
Flag 02 – Bad Rando | CS 6035
Flag 02 – Bad Rando
Task 02_bad_rand0
This Program (very conveniently) leaks out part of the libc base address this address is randomized via ASLR so it will change a little bit every time the program is launched run the program a few times and notice what bytes are different and which ones aren’t
Next step will be analyzing the C file and see what we are comparing against in order to get to call_me – system() is a libc function, use GDB to get the address of system using command p system –
run ./flag multiple times, it will ask you for input and your goal is to guess an address. Put in any random guess and try it a few times to see if you can notice a pattern versus what is leaked and what is being expected.
Fortunately there’s only one byte that is missing from our formula, so we can do some scripting in python to try out the remaining values.
– pwntools has a function called recv<line|until|all>() that will let us do some manipulation with the str
– the recv functions will return a BYTES object, so you will need to do some clever manipulation of said s
– note that the C file is using scanf to read in a hexadecimal number, meaning you don’t need to use p64()

Your task is going to be: – get the value leaked from the program – modify it with the offset of the system() function – fill in the remaining byte with a random value – send to the process – (repeat until you get a flag) note: i recommend using recvall() after you send in each payload, and write your loop logic around the output (see other flags for what kind of string output you can expect) to see if you got the right value!
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/02_bad_rand0.html
Flag 02 – Bad Rando | CS 6035

Disclaimer: You are responsible for the information on this website. The content is subject to change at any time.
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/02_bad_rand0.html

Flag 02 – Assemble | CS 6035
Flag 02 – Assemble
Task 02_assemble_the_assembly
This task will get you to determine which series of assembly instructions will direct the code flow into constructing a call to call_me(). Analyze the different instructions and look up the usage/behavior of them to figure out which combination will get you there.
There is a small twist, however:
You can use objdump or gdb to find the address of call_me() and figure out how you calculate it.
For debugging, we highly recommend using gdb, setting a breakpoint on the gadget function, and stepping through the options once you think you know the correct path to get to the function call.
(FYI:: you don’t have to use pwntools for this one)
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/02_assemble_the_assembly.html
Flag 02 – Assemble | CS 6035

Disclaimer: You are responsible for the information on this website. The content is subject to change at any time. https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/02_assemble_the_assembly.html

Flag 01 – BO2
Task 01_basic_overflow_2
In this task you will learn details about binaries compiled from C code (with gcc) in a Linux environment, and how some basic things can be exploited such as process redirection or control flow hijacking. The steps in this flag are discussed in-depth in the intro video.
In this directory you have an executable binary named ‘flag’ which is vulnerable to a buffer overflow in one of its functions. We will be using an exploitation library called pwntools to automate some of the overflow techniques and get the binary to call a function it otherwise wouldn’t have. This function called ‘call_me’ generates a key using your Gradescope User ID to get a valid flag that will pass the autograder.
Now we will run the binary just to see what the program is doing by running the executable

We see the binary is asking for a string, input any text you want or just press enter, and you’ll see that the program does nothing and just exits. That’s just to simplify the code so we can focus on the exploit.
The binary is statically linked to a shared object which has a lot of methods that construct the key and has a simple function called ‘call_me()’ which will print out your key.
This is where we will start learning about binary file formats. Without going into a deep dive about program structure, operating systems, compilers, assembly language, machine code, etc. you will still be able to understand that there are two aspects that are key in binary exploitation
Data
• is simple enough, it is just any collection of bits that represent some kind of data element (like an ASCII character, integer value, pointer, etc)
Addresses
• At this scope we can just think of addresses as fully unique identifiers of specific data elements.
These are logical locations the computer understands.
A buffer overflow occurs when too much data is fed into an unprotected (or poorly protected) data buffer. The way that 64-bit C programs work is, a few bytes before the start of the stack frame (this is the function entry point), there is an address stored in memory called the Return Address. This Return Address is read into a register upon function return (when the function ends and intends to return to its caller), andthen process redirection to that address happens. If we override this location with another valid address, we can manipulate the control flow of the program and have it execute arbitrary (or otherwise unintended) code, with a well-formed attack. Starting off easy, we are going to modify e.py and learn a few basics of the pwntools library, which will build up into a successful attack at the end.
Open e.py with your favorite text editor and analyze the content and comments.
Once you understand what they do, proceed to fill in the cyclic size (this number is up to you, based on your understanding of the program and what would break it) to get a segmentation fault message by running
$ ./e.py dbg
This will open up a gdb terminal with a breakpoint set at main()
Type ‘c’ to continue from the breakpoint
• (sometimes you might need to press ‘c’ twice if you don’t see the error, this is an issue with how gdb attaches to processes)

We see the program received an interrupt signal for a SEGMENTATION FAULT (SIGSEV, or an invalid access to memory). This happens when the program tries to access memory at a certain location that it either isn’t allowed to access, or doesn’t exist. In this case the return address for the function was overwritten by cyclic()’s data in the form of long strings of characters. Pay attention to the bottom of the screenshot where the instruction pointer is currently trying to ‘ret’ (return) to 0x6561……616b which is just a string of ascii characters in hexadecimal form. Now we know how to break the binary, let’s figure out how to purposefully break it. Using a pwntools method called
‘cyclic_find()’ we enter in the bottom 32 bits (4 bytes) of the return string (in this example is 0x6561616b) which will give the number of characters before reaching that value. This is important because we are now going to reach our first step of control flow hijacking by overflowing enough data that we can place a value and change the course of the program’s normal path.
In e.py, on the commented line below your cyclic command, we are now going to use cyclic_find() which will automate our buffer length calculation, and feed that number into cyclic(). Place in your 4 character bytes (preceded by a 0x, like 0x6561616b). Uncomment either of the lines beneath our original cyclic() call (one uses hex value and the other uses the ASCII values), and fill in the hex or ascii value described above This will fill the buffer with our calculated buffer length, appended by the ASCII byte equivalent of the variable by using another pwntools method p64(number). After you have done that, rerun
./e.py dbg
And hit ‘c’

If done correctly, you should see something like this screenshot, where if you check the ‘ret’ instruction, we are now failing on an invalid access to our dummy address.
Stepping away from the pwntools library for a moment, we now need to find something usable within the binary that will allow us to actually call a function or do something other than just crashing the program.
Now we will use a linux command ‘objdump’ which takes a binary file and will output a dump of the binary which will give some key information about the binary. The -D flag will output binary addresses, machine code, and assembly code of the binary into a file. objdump -D flag > flag.asm
Then open flag.asm
You will see a bunch of (likely) confusing information that at a high level translates to the code that you can see in the ‘flag.c’ file. You aren’t going to have to go through this file in any extreme expanse (unless you want to?) we are just going to focus on finding an address within the binary file that holds the machine code responsible for making a function call to ‘call_me()’.
Search for the string ‘call_me’ in flag.asm and keep looking until you find the assembly instruction:
call <some address> <call_me>
Note down the highlighted address showing the call (it will be different in your binary):
With the hexadecimal value of the address above (prepend 0x to the value highlighted)
Now run ./e.py again from the command line (without dbg) and check the terminal output.
Did you get it? Awesome! Submit your first flag to gradescope (follow APPENDIX for more details) If not, retrace your steps in this task and also make sure you used the call call_me address in the earlier step and not the address of the actual function call_me()
Disclaimer: You are responsible for the information on this website. The content is subject to change at any time.

Flag 01 – BO1 | CS 6035
CS 6035

Projects / Binary Exploitation / Flag 01 – BO1
01_basic_overflow_1
(watch the intro video first please)
This task is a very simple buffer overflow that, upon inspection, will check if a variable is non-zero. Using the information you have gathered from reading and the videos, it is your task to get this program to get to the call_me() function, and get the flag printed.
Here are some steps I suggest you follow for the remainder of the project, that will set yourself up for success when debugging/analyzing/reverse engineering the binaries.
• Read the source code! You have the source code for each of these tasks saved in the same directory named flag.c which will help you understand what the program does
• Look for where the input is taken! All of these programs take input in a few different ways, but they all are similar in the fact that this is how you get your exploit/solution to work! Check for things like read() or scanf in the binaries.
• Once you have identified where the input is taken, look at what variables are also going to be on the stack, everything is fair game!
• Note that all of these binaries are pretty much specially written so that you will need to use the adjacent variables to pass certain checks by overflowing (not all of them though) so just try to focus on the bigger picture when you are analyzing the program
• In this instance you need to overflow the target buffer to change the initialized value of the variable make_me_not_zero. Although this is a trivial example, it is just designed to show you how unprotected buffers can result in changing other adjacent values in memory
Note: you are free to use GDB if you need to for this project but you need to run the program on the command line (i.e. ./e.py) in order to get the real flag for submission and submit it!
Disclaimer: You are responsible for the information on this website. The content is subject to change at any time.
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/01_buffer_overflow_1.html 1/1 Flag 01 – bb_steps | CS 6035
CS 6035

Projects / Binary Exploitation / Flag 01 – bb_steps
01_bb_steps
(watch the intro video first please)
This is a test on using GDB to read a few things that would be difficult to calculate (you can if you want to), but the main point of this task is to try running a few things in gdb and get comfortable with it first.
cd ~/binexp/01_bb_steps/ gdb flag
you will be met with a pwndbg prompt which waits for you to run the program (or set breakpoints, etc) which we’ll do now: b main
sets a breakpoint at the first executable statement of the main() function. r
runs the program and you will be met with some text/blocks showing various things like stack traces, register printouts, code prints, etc. Now next you will want to run the STEP command to go into the function
s
After that, you will notice we are now in the bb_steps() function and can traverse all the code with the NEXT command
n
Which will execute each following instruction. This is useful if you don’t want to go into every single function call, and rather want to just execute those calls/instructions. https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/01_bb_steps.html 1/2
Flag 01 – bb_steps | CS 6035
Pay attention to the register window which will show each register value as the instructions are executed.
At the end of the ASM instructions, you will be prompted to enter in the answers for the two registers RBX and R15. You can enter these into GDB if you want to, however to get the official/valid flag for submission you will have to save your answers for the two registers, and then enter them into the non-debug binary run, e.g.:
binexp@cs6035:~/binexp/01_bb_steps$ ./flag What value is currently in RBX?: 0xdeadbeef
Upon correctly answering the questions, you will see your flag printed out, which you can copy into the json file!
Disclaimer: You are responsible for the information on this website. The content is subject to change at any time.
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/01_bb_steps.html 2/2

CS 6035

Projects / Binary Exploitation / FAQ
Frequently Asked Question(s) (FAQ)
Make sure you have read:
• This Writeup explaining some rudimentary basics of Computer Architecture
• Please refer to: Required Reading > VM Troubleshooting, for VM related troubleshooting questions.
Make sure you have watched:
• This CS6035 Project 1 pwntools/pndbg Tutorial video
Submission and GradeScope
Please navigate to the Submission Details menu page, left.
Logistics & Setup
Q1) Can I SSH into the VM and perform the project?
When you run your e.py exploits with GDB, a separate terminal is opened with the process hooked to GDB. Some students have reported handling this by using tmux. Once you SSH into the VM, kill existing tmux sessions: tmux kill-session
And then start a new tmux session with:
tmux -CC
This will open up a new window with 2 separate scrollable sections for pwndbg and e.py.
Q2) Can I recompile the binaries?
If it helps your comprehension, you’re welcome to recompile the source code with whatever alterations you want; in fact, we suggest doing this in some of the binaries in section 04, for example.
However, we have fingerprinted the binaries that are shipped out to you all with the project; your final exploit(s) will need to utilize them as is. Gradescope will recognize if you attempt to submit a flag from a binary that wasn’t among the original set.
We strongly discourage this. The binaries rely on files residing in particular locations, such as
/home/binexp/user.txt, among others. However, you ARE welcome to make copies/backups as needed if it helps facilitate your testing.
Q4) Help, I’ve deleted/broken something! What do I do?
Backup any working e.py exploits you’ve already developed and your project_binexp.json file that contains your hashes. Then re-run the binexp.sh script to download the project files fresh again.
Note: you’ll need to double-check your GTID is properly set in /home/binexp/user.txt again.
General
Q1) “Any hints?”
Per CS6035 policy, we do not provide hints/guidance expressly for the purpose of simply solving the provided tasks. Instead, we are happy to address comprehension issues or matters concerning administration/logistics of the project. If there is something that is particularly confusing or unclear, please pose your question as a comment on the respective Ed Discussion megathread.
Most of the time, these kinds of questions can be answered by a combination of analyzing the source code and manually setting a breakpoint within GDB to take more granular steps (i.e. n or ni) so you can see what’s causing the trouble. Suggested breakpoints might include overwritten ret instructions or instructions within the destinations you’re jumping to, though this can vary from problem-to-problem. You might also invoke info local to observe details about localized variables.
Q2) How do I know if I got the flag for a given binary?
All of the flags in the project are read-in by the binaries through /proc/flag. For an example of what that might look like, see:

Q3) I got to the flag in GDB but I don’t see a message output with the flag; where is it?
We have configured our flag generation-mechanism (/proc/flag) to deny providing any flags to users who attempt to read from it via GDB. This is deliberate, because as a debugger GDB has a multitude of functionality that would undercut the learning objectives of the tasks. This includes but isn’t limited to – using the set and call commands, for example. You will need to naturally arrive at reading from /proc/flag either directly from directly interacting with the binary along the command line or through a non-GDB optioned invocation of your e.py file (e.g. python3 e.py).
Attempting to read from /proc/flag through GDB will yield something that looks like this:

Q4) How does cyclic() and cyclic_find() work?
We encourage you to read up on the tools you’re utilizing: https://docs.pwntools.com/en/stable/util/cyclic.html In brief:
cyclic() produces a bytestring of length “n”, where n is some integer value between 0 and the largest possible positive integer supported by the platform (e.g. sys.maxsize). Example usages might look like:
• cyclic(10)
• cyclic(25)
• cyclic(3000)
The output of cyclic() is a bytestring with a unique character sequence in chunks of 4 bytes at a time:

In the above screenshot, you can see the pattern as:
• aaaa
• baaa
• caaa
• etc.
This pattern is the same with every invocation of cyclic() and terminates at the nth character.
cyclic_find() reverse-engineers the above. It provides an integer corresponding to a particular segment in that aforementioned bytestring; you can supply it with a variety of inputs (e.g. a bytestring, a hex representation, etc.):

Q5) Do I have to use e.py?
Q6) What is “/proc/flag”?
The /proc/flag file is the target for all of the binary exploits in this project. Every time a user reads from it, it outputs a uniquely encoded result (which we erroneously refer to as a “hash”) that contains reversible information fingerprinted to it that the autograder uses to evaluate for correctness.
You can test if /proc/flag is running trivially by reading from it like so: cat /proc/flag
Note: while doing the above should yield a flag hash, it will not be accepted/validated by the autograder. Valid hashes will only be returned from exploiting the binaries.
Q7) I’m given a different result everytime I read the flag; is something wrong?
No. This is expected behavior and nothing to worry about.
Q8) I’m making the call to read from /proc/flag but my exploit keeps seg-faulting; what’s wrong?
In most cases of this happening, your exploit is catching on a movaps instruction somewhere within

If this is the case, the issue is related to a stack-misalignment problem. Because our exploits forcibly redirect the control flow in ways the process wasn’t expecting, there can be downstream consequences as the process executes along and refers back to our maliciously overwritten stack. By-and-large, you generally want to consider jumping to a different instruction within your targeted function.
Q9) My e.py file is throwing a “can only concatenate str (not bytes) to str” error; what gives?
The error is telling you that you’re mixing your data types in your payload within e.py:
## WRONG payload = “A” * 100 #type str payload += p64(0xwhatever) #type bytes
## RIGHT payload = b’A’ * 100 #type bytes payload += p64(0xwhatever)
Q10) My e.py file is throwing a “name ‘p’ is not defined” error; what gives?
You’re likely getting this error because you’re misspelling the optional argument for e.py.
Q11) When I’m stepping through instructions in GDB, I enter “n” and it skips over my desired target function call; what gives?
We speak to this in the 01 section, step 1.2: 01_bb_steps. Both the (n)ext and next instruction (ni) GDB commands step over function calls. To enter the function you need to (s)tep inside (or step inside, immediate instruction (si)).
Q12) Why are the tasks prefixed with numbers like 01, 02, 03_, etc.?
We’ve labeled the tasks with numbers to reflect their relative perceived difficulty. You do not need to complete the tasks in any particular order. If you get stuck working on a problem, try working through some of the other challenges and come back.
Disclaimer: You are responsible for the information on this website. The content is subject to change at any time.

1/27/25, 12:54 PM Flag 00 – Intro | CS 6035
CS 6035

Projects / Binary Exploitation / Flag 00 – Intro
Step 0:
Welcome to the Binary Exploitation (BinExp) project for CS6035! We’re excited to have you with us for this effort.
Binary exploitation is a really interesting and challenging domain within cybersecurity. It rests at the intersection of many sub-disciplines, including reverse engineering, low-level programming, operating systems, code review, etc. As such, you’ll be expected to draw upon a variety of subjects matter in approaching and working through the challenges of this project.
Step 1:
Before diving in, let’s ensure that our project work environment is appropriately configured.
1 This project utilizes the same virtual machine (VM) that is used for other projects within CS6035. If you’ve already got it configured, great! If not, see the respective “Course VM Download Thread” post in Ed Discussion for instructions.
2 Please follow the instructions in Canvas (navigate to “Assignments” > “Binary Exploitation”) for login credentials to the VM as well as the requisite commands for fetching the project files.
3 Navigate to /home/binexp/user.txt and set it to your nine-digit GTID. If you do not know your GTID, you should be able to discover this through https://gtid.gatech.edu. Note: if you fail to set this, no responses you submit to Gradescope will be accepted as correct.
Below is a brief summary of the project’s contents:
• project_binexp.json: This is the one (and only) file you will submit to Gradescope to have your work be evaluated. See the Submission tab along the left-hand side of this page for additional guidance concerning project submission guidelines.
• binexp*: This is the directory and subdirectories that make up the project. Each subdirectory reflects an individual challenge within the project and contains all of the files necessary for solving that particular challenge.
• binexp*lag: For most of the challenges, this is the compiled binary you’re attempting to exploit. If it isn’t, the student instructions for that particular challenge will say so.
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/00_intro.html 1/2 1/27/25, 12:54 PM Flag 00 – Intro | CS 6035
• binexp*lag.c: This is the source code for the flag binary, above. This is intended to be a useful reference to aid in identifying and crafting your exploits of flag.
• binexp*e.py: This is a python3 script with some templated skeleton exploit code.
In all of the projects’ binaries, your goal is to have the binary read from /proc/flag! Most of the time, this is via a system() call like: system(“cat /proc/flag”);
However, sometimes it’s not that simple – carefully analyze your source code within each challenge to figure out how the binary is meant to read from /proc/flag.
Step 2:
Enter into /home/binexp/binexp/00_intro and run the flag binary located there. Note the GTID it outputs to verify that the binary is reading the correct value from step 1, above. If so, copy the supplied hash and write it to the appropriate value in project_binexp.json.
Finally, try submitting the project_binexp.json file to Gradescope to verify that the hash is correct. Remember, you have unlimited submission attempts for this project, so be sure to submit early and often.
Disclaimer: You are responsible for the information on this website. The content is subject to change at any time.
https://github.gatech.edu/pages/cs6035-tools/cs6035-tools.github.io/Projects/BinExp/00_intro.html 2/2