Don't like this style? Click here to change it! blue.css
For today's main problem we have 2 things going on to learn about:
What is shellcode?
It was the first major exploit to rock the world about 25 years ago and it works like this:
You write bytes into memory that are, themselves, instructions/opcodes that the computer could execute.
Then you jump the instruction pointer to those instructions and bam, you've written your own win condition.
If you see NX Disabled
or Has RWX Segments
during a checksec
I typically start a PWN with a call to checksec --file=yourpwnbin
and the output will tell me the protections in place.
For this case we're looking for NX disabled (non-executable stack disabled == stack is both writable AND executable)
There is a quick and easy answer: pwntools shellcraft
There are medium answers: googling shellcode databases
There are expert answers: writing your own
My original project 1 was intended to help you learn how to write your own, because now and again you need to.
The situations where you need to are a problem that is doing some sanity checking on your payload but can be made vulnerable to shellcode.
In those cases you'll need to be able to take something off the shelf and tweak it to fit your problem, but those problems are fairly rare and for those of you in the class that are going to be the world class pwners you can do that on your own time.
The Easy Way:
It's just 1-3 lines!!
Couple of notes:
The context matters. If you need a 64-bit shellcode you need the line context.arch="amd64"
otherwise you'll get 32-bit shellcode.
The output of the shellcraft module is actually assembly code that does something cool (run /bin/sh in our case here). But you can turn pretty ASM into op codes with
the line asm(b"pretty stuff here")
There is a lot of beauty in this particular shell code, like avoiding null bytes and new line characters and trying to fit into 48 bytes or so.
If you want a more foundational approach to shellcode take a look at my old notes: Spring class 8
So in this problem we are given an address leak. Why? What is that all about? How do we process it?
There is a lot of ways that leaks will happen to us this year and this one will be one of the most straight forward.
There are usually 3 segments we need to handle:
.data
segment which has the .main opcodes/instructions (randomization is turned OFF by NO PIE
)stack
segment which has our local variables, return address for smashing, etcglibc
segments which are the walmart segments that have every chunk of functionality we need to run the worldThese addresses are different every time the program executes (in order to stop us hackers). Throughout the course we will find various ways to get around these defenses.
OFFSETS are key (but not for this problem)
That is, given an address from one of these segments you'll need to deduce where in the segment is the leak, and how far from the leak is an address you need to know.
We will explore again soon which things are in each segment and jumping around from leak to target like gymnasts
If you are given a leak (or manufacture a leak) you'll have to parse the data.
In pwntools you'll want to get an example response from the process and parse it. Here are several methods: