Finding crashes -- 2
Budget: $30 – $250 USD
Finding Crashes
Purpose
The purpose of this project is to test your understanding of memory corruption vulnerabilities and familiarize you with bug hunting in both C source code and binary code. You will learn how to find memory corruption vulnerabilities in C source code and binary code, and derive input that is required to trigger the vulnerability and crash the program.
Objectives
Students will be able to:
● Read the source code of programs when their source code is available.
● Comprehend the decompiled code of binary programs when their source code is not available.
● Determine which input that can be used to trigger the vulnerability and lead the program to crash.
● Reverse engineer simple binary programs.
Technology Requirements
All provided source code files are intended to be compiled under Linux (tested under Ubuntu 20.04 LTS). You are strongly encouraged to have the exact same environment as the test environment. If you are using Windows or MacOS, please follow the instructor's instructions (from the live event or in the course announcements section) and install a virtual machine on your system. You can get VMware for free as an ASU student (strongly recommended).
Project Description
For this project, you will get a tarball called `collection.tar.gz`. Inside the tarball, you will find multiple programs, each in its own directory named after the name of the program (`p_N` where N is an integer). Some programs are shipped with source code, while other programs are binary-only (without any source code). Each program takes input from stdin, operates on the input, and either exits gracefully or prints out some output before exiting.
Your goal is to do "bug hunting" on each program, find vulnerabilities that can lead to crashes, reason about the input that will trigger the vulnerabilities you found, and then submit your input.
For each program, if source code is available, you are supposed to read its source code and find vulnerabilities. If only binary code is available, you are supposed to use a decompiler (such as Ghidra) to derive the pseudo code, read the pseudo code, and find vulnerabilities. While reading disassembly is not necessary, you may find disassembly to be more useful than decompiled code at times.
Your submission should include exactly *one* file for each program, named after the program name (`p_N` where N is an integer), that will act as input through stdin for each program. You will score as long as your input crashes the program.
Bonus: Control-flow hijacking is possible in some of these programs. If you can achieve control-flow hijacking and make the program print out "Great Job" before _exiting gracefully_ (i.e., exiting with return code 0), your score of that program will double.
Directions
For programs with source code available, you may use any text editor to read the source code, find the bugs, and trigger crashes. Visual Studio Code is strongly recommended, although other text editors work as well.
For programs without source code provided, please use a binary analysis tool, such as Ghidra, to analyze and decompile the binaries directly.
Evaluation
Your submissions will be graded automatically. You will earn 10 points for each crash, and another 10 points if your submission manages to hijack the control flow, make the program print out “Great job” to stdout, and exit with an exit code 0. You will get 0 points otherwise.
Submission Directions for Project Deliverables
Your should submit a zip file called submission.zip, which includes exactly *one* file for each program. Each of the files in the zip file should be named after the program name (`p_N` where N is an integer). File `p_N` will be the input for program p_N.
2
Purpose
The purpose of this project is to test your understanding of memory corruption vulnerabilities and familiarize you with bug hunting in both C source code and binary code. You will learn how to find memory corruption vulnerabilities in C source code and binary code, and derive input that is required to trigger the vulnerability and crash the program.
Objectives
Students will be able to:
● Read the source code of programs when their source code is available.
● Comprehend the decompiled code of binary programs when their source code is not available.
● Determine which input that can be used to trigger the vulnerability and lead the program to crash.
● Reverse engineer simple binary programs.
Technology Requirements
All provided source code files are intended to be compiled under Linux (tested under Ubuntu 20.04 LTS). You are strongly encouraged to have the exact same environment as the test environment. If you are using Windows or MacOS, please follow the instructor's instructions (from the live event or in the course announcements section) and install a virtual machine on your system. You can get VMware for free as an ASU student (strongly recommended).
Project Description
For this project, you will get a tarball called `collection.tar.gz`. Inside the tarball, you will find multiple programs, each in its own directory named after the name of the program (`p_N` where N is an integer). Some programs are shipped with source code, while other programs are binary-only (without any source code). Each program takes input from stdin, operates on the input, and either exits gracefully or prints out some output before exiting.
Your goal is to do "bug hunting" on each program, find vulnerabilities that can lead to crashes, reason about the input that will trigger the vulnerabilities you found, and then submit your input.
For each program, if source code is available, you are supposed to read its source code and find vulnerabilities. If only binary code is available, you are supposed to use a decompiler (such as Ghidra) to derive the pseudo code, read the pseudo code, and find vulnerabilities. While reading disassembly is not necessary, you may find disassembly to be more useful than decompiled code at times.
Your submission should include exactly *one* file for each program, named after the program name (`p_N` where N is an integer), that will act as input through stdin for each program. You will score as long as your input crashes the program.
Bonus: Control-flow hijacking is possible in some of these programs. If you can achieve control-flow hijacking and make the program print out "Great Job" before _exiting gracefully_ (i.e., exiting with return code 0), your score of that program will double.
Directions
For programs with source code available, you may use any text editor to read the source code, find the bugs, and trigger crashes. Visual Studio Code is strongly recommended, although other text editors work as well.
For programs without source code provided, please use a binary analysis tool, such as Ghidra, to analyze and decompile the binaries directly.
Evaluation
Your submissions will be graded automatically. You will earn 10 points for each crash, and another 10 points if your submission manages to hijack the control flow, make the program print out “Great job” to stdout, and exit with an exit code 0. You will get 0 points otherwise.
Submission Directions for Project Deliverables
Your should submit a zip file called submission.zip, which includes exactly *one* file for each program. Each of the files in the zip file should be named after the program name (`p_N` where N is an integer). File `p_N` will be the input for program p_N.
2