程序代写 CSE 127 – PA1: Buffer Overflows

CSE 127 – PA1: Buffer Overflows

Copyright By PowCoder代写 加微信 powcoder

PA1: Buffer Overflows Spring 2022

Total Points: 20 (+ 4 optional extra credit)

Due: Tuesday, April 19 at 11:59pm

This is a group project; you can work in a team of size at most two and submit one
project per team. You are not required to work with the same partner on every project.
You and your partner should collaborate closely on each part.

You have two late days that you may use to turn in work past the
deadline over the entire quarter. A late day is a contiguous 24-hour
period. Both you and your partner will be charged for every late day
that you use, and you both must have late days to use them. These
late days are intended to cover your extension needs for usual
circumstances: brief illness, busy with other classes, interviews,
travel, extracurricular conflicts, and so on. You do not need to ask
permission to use a late day.

The code and other answers you submit must be entirely your team’s
own work. You may discuss the conceptualization of the project and the
meaning of the questions, but you may not look at any part of someone
else’s solution or collaborate with anyone other than your
partner. You may consult published references, provided that you
appropriately cite them (e.g., with program comments).

Solutions must be submitted to Gradescope.

Introduction

This project will introduce you to control-flow hijacking
vulnerabilities in application software, including buffer overflows. We
will provide a series of vulnerable programs and a virtual machine
environment in which you will develop exploits.

Objectives

Be able to identify and avoid buffer overflow vulnerabilities in
native code.
Understand the severity of buffer overflows and the necessity of
standard defenses.
Understand the mechanics of buffer overflow exploitation.

Read this first!

This project asks you to develop attacks and test them in a virtual
machine you control. Attempting the same kinds of attacks against
others’ systems without authorization is prohibited by law and
university policies and may result in fines, expulsion, and jail time.
You must not attack anyone else’s system without
authorization! You are required to respect the privacy and
property rights of others at all times, or else you will fail the

Resources and Guidelines
Submission Details
Frequently Asked Questions

Alice’s company Security4All is having one of their periodic security audits taking place today. The software used for this purpose (from an external firm called Mandiant) has flagged a bunch of code snippets across various Security4All projects as potentially being unsafe. Unfortunately for Alice, 8 of the flagged threats belongs to projects under her ownership. However, before Alice can patch the security bugs, she wants to verify that the threats detected are indeed exploitable, and not false positivies.

Alice was super happy with your assistance helping her fix the compiler bug last week, and asks for your help again. Your task is to help Alice develop working exploits for each of the threats flagged by the software tool.

Buffer-overflow exploitation depends on details of the target system.
You must develop and test your attacks inside the CSE127
as it has been configured to disable certain security features that would complicate your

We recommend that you start this step early in order to make sure that you will be able to
set up the assignment on your computer.

Download the appropriate VM image for your platform and run it.

Windows, Linux, and Intel Macs: Download the .ova
file and import it into VirtualBox.

M1 or Intel Mac users: Download the .zip
to get a UTM file and use UTM
to open it.

The username and password are both cse127.

Once the VM is up running, if you prefer to ssh in, you can ssh using
(e.g. ssh -p 4127

You can use scp to copy files into or out of the VM (e.g.
scp -P 4127 -r /path/to/files/

You can also use VS Code to connect to the VM via SSH, see the Microsoft docs.
Jetbrains also
has a similar feature, but it’s a bit harder to set up, see their

Download the assignment starter code inside
the VM with the command
wget https://zzjas.github.io/cse127sp22/pa/assets/pa1-starter.tar.gz and use the command tar -xf pa1-starter.tar.gz to unzip it.
You should see a targets directory which contains the assignment.

Run ./build.sh. It will prompt you for usernames. Use the usernames
registered in your gradescope accounts.
For example, if your gradescope looks like:

Then you would input gobaido.

If you’re in a group, enter both usernames. The order of usernames doesn’t

For example, if the usernames are gobaido and svrao,
running ./build.sh should generate a cookie file. Take a look at its

cat cookie
gobaido svrao

If you upload that to gradescope, you can confirm that the cookie you generate is the
one we expect. If not, an error is generated as shown in the screenshot below.

Also, if you are working in a team of 2, make sure to add both you and your teammate on your gradescope submission using the “Add Group Member” button (the cookie test case would only pass once both have been added).

Please make sure you have correctly generated your cookie file before you start

If you need to recompile your targets, you will need to run
./build.sh clean before you run ./build.sh again.

Resources and Guidelines

No attack tools allowed!

Except where specifically noted, you may not use special-purpose tools
meant for testing security or exploiting vulnerabilities. You must
complete the project using only general purpose tools, such as gdb.

Control-flow hijacking tutorials

Before you begin this project, review the slides from the
buffer overflow lectures and attend discussion for additional details.
Read “Smashing the Stack for Fun and Profit”

You will make use of the GDB debugger for dynamic analysis within the
VM, hopefully leveraging your learnings from PA0.
This quick
reference on GDB may help refresh your memory.

x86 assembly

These are many good references for x86, but note
that our project targets use the 32-bit x86 ISA. The stack is organized
differently in x86 and x64. If you are reading any online documentation,
ensure that it is based on the x86 architecture, not x64.

If you are getting a segfault

A segfault means that you’re either jumping execution to or dereferencing an address
that is incorrect. This means you’re on the right track because you’ve
overwritten something and changed the program’s behavior! If you are stuck as to where to
start looking, try
to identify the addresses the exploit has changed and work from there, i.e. make sure the
addresses you
intended to change have actually been changed and nothing else.

All the flagged programs are simple, short C programs with
(mostly) clear security vulnerabilities. Further, we have provided source code
and a build script that compiles all the targets. Your exploits must work
against the targets as compiled and executed within the provided VM.

target0: Overwriting a variable on the
stack (2 points) (Easy)

This program takes input from stdin and prints a message. Your job is
to provide input that causes the program to output:
“Hi username! Your grade is A+.” (You can use either group member’s
username.) To accomplish this, your input will need to overwrite another
variable stored on the stack.

Here’s one approach you might take:

Examine target0.c. Where is the buffer overflow?

Disassemble _main. What is its starting address?

Set a breakpoint at the beginning of _main and run the program.

Using GDB from within the VM, set a breakpoint at the beginning of
_main and run the program.

(gdb) break _main

Draw a picture of the stack. How are name[] and grade[]
relative to each other?

How could a value read into name[] affect the value contained in
grade[]? Test your hypothesis by running ./target0 on the
command line with different inputs.

Be careful about null terminators!

What to submit

Create a Python 3 program named sol0.py that prints a line to be
passed as input to the target. Test your program with the command line:

$ python3 sol0.py | ./target0

Hint: In Python 3, you should work with bytes rather than Unicode
strings. To construct a byte literal, use this syntax: b”\xnn”, where
nn is a 2-digit hex value. To repeat a byte n times, you can do:
b”\xnn” * n. To output a sequence of bytes, use:

import sys
sys.stdout.buffer.write(b”\x61\x62\x63″)

Don’t use print(), because it automatically encodes whatever is being
printed with the default encoding of the console. We don’t want our payload
to be encoded, so we use sys.stdout.buffer.write().

target1: Overwriting the return address (3
points) (Easy)

This program takes input from stdin and prints a message. Your job is
to provide input that makes it output: “Your grade is perfect.” Your
input will need to overwrite the return address so that the function
vulnerable() transfers control to print_good_grade() when it

Examine target1.c. Where is the buffer overflow?

Examine the function print_good_grade. What is its starting

Using GDB from within the VM, set a breakpoint at the beginning of
vulnerable and run the program.

(gdb) break vulnerable

Disassemble vulnerable and draw the stack. Where is input[]
stored relative to ebp? How long would an input have to be to
overwrite this value and the return address?

Examine the esp and ebp registers:

(gdb) info reg

What are the current values of the saved frame pointer and return
address from the stack frame? You can examine two words of memory at
ebp using:

(gdb) x/2wx $ebp

Essentially, this command says “e(x)amine the memory at location $ebp. Give me two
words (4 bytes per word, so 8
bytes in total) and put the result in hexadecimal.

What should these values be in order to redirect control to the
desired function?

What to submit

Create a Python 3 program named sol1.py that prints a line to be
passed as input to the target. Test your program with the command line:

$ python3 sol1.py | ./target1

When debugging your program, it may be helpful to view a hex dump of the
output. Try this:

$ python3 sol1.py | hd

Remember that x86 uses little endian ordering. Use Python’s to_bytes method to
output 32-bit little-endian values like so:

import sys
sys.stdout.buffer.write(0xDEADBEEF.to_bytes(4, “little”))

target2: Redirecting control to shellcode
(3 points) (Easy)

Targets 2 through 7 are owned by the root user and have the suid
bit set. Your goal is to cause them to launch a shell, which will
therefore have root privileges. This and several of the following targets all take
input as command-line arguments rather than from stdin. Unless
otherwise noted, you should use the shellcode we have provided in
shellcode.py. Successfully placing this shellcode in memory and
setting the instruction pointer to the beginning of the shellcode (e.g.,
by returning or jumping to it) will open a shell.

Examine target2.c. Where is the buffer overflow?

Create a Python 3 program named sol2.py that outputs the provided
shellcode:

from shellcode import shellcode
import sys
sys.stdout.buffer.write(shellcode)

Disassemble vulnerable. Where does buf begin relative to
What is the offset from the start of the

程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com