CSAW CTF 2017 - Write-up

Challenge: Misc, Serial

This challenge had to do with Serial, just like it’s name.

This is what we get when we connect to the server:

You can already guess that it has to do with parity checking. When you research 8N1 Parity, you’ll learn that the format is:

START_BIT, DATA(byte), PARITY_BIT, STOP_BIT

We’re asked to evaluate the data and respond with 1 or 0.

Even parity is explained pretty well here http://www.globalspec.com/ImageRepository/LearnMore/20157/parityc189996e759b44a7ae14aa7d36630839.png:

Basically, you want to end up with even amount of 1’s. If your data contains three 1 bits then you need 1 as your parity bit. If your data contains eight 1 bits then you need 0 as your parity bit.

We’re asked to respond with 1 if parity bit is correct and respond with 0 if parity bit is incorrect.

I used pwntools and binascii to implement my solution.

It looks something like this:

First my checkparity function is defined, which will tell me what I need to transmit back to csaw server (either 1 or 0).

I make a connection to the server then read the data (All 11 bits). I send the data to my checkparity function.

Checkparity will look at only the byte value (actualdata) and parity bit. I also count the number of 1 bits I’ve received.

If I have even number of 1 bits then parity bit should be 0, if I have odd number of 1 bits then parity should be 1. If that isn’t the case then I have bad data and I retransmit 0.

The good bytes can be converted to ascii and that’s our flag!

This is what it looks like when ran:

Solution file is here: https://cdn.discordapp.com/attachments/299010542977417216/358793197243072524/ser.py

Challenge: Pwn, Pilot

This was an exploitation challenge and the goal was to get a shell.

In this case, the tools I’ve used were gdb with peda and pwntools and struct libraries.

This was a 64-bit binary. I don’t I’ve done overflow on 64-bit before in any CTF so it was kinda new to me. The concept is still the same as 32-bit though.

I use ‘pattern create 50 out’ to generate a file named out with 50 bytes. ‘run < out’ takes bytes from the out file and inputs them after running the program. As you can see in the image above, there is a crash.

I can run pattern search to look at offsets. I also look at backtrace and look at the offset for the pattern find there. It is 40. This means that we need 40 bytes + address and whatever the address is should land in RIP and the application will jump to that address.

I test this out below:

In the screenshot above, you can see that BBBBAAAA is where the application jumps to.

When we connect to the server, this is the output:

Notice the location address it returns. This is where our code will be placed. The downloaded application also does this, obviously. Our goal is have some code at that address to obtain shell.

This is what my code ends up looking like:

First I make a connection then read the input. I extract the address that I need to jump to then pack it. I found shellcode that executes /bin/sh and I’ve added that as well.

\x90 is a nop, however, when testing, I was using \xcc (int3) which makes the debugger break (as in breakpoint) and lets me do step by step execution.

My data I will be inputting will be SHELLCODE (execute /bin/sh) + nop * (40-lenth of SHELLCODE)

I then send the data and interact with the socket connection.

Below is how I got the flag.