While this challenge was under the "Baby's First" section, I think it's a great teaching example of a basic heap exploitation technique. File

 

$ file beatmeonthedl
beatmeonthedl: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, not stripped

This years DEFCON CTF qualifiers featured a section called crackme. The idea behind the questions in this section was to find correct input to a prompted executable. The added challenge was that each challenge was actually a series of ~200 binaries. Your goal was to automate the cracking of one and be able to extend it to all the rest.

 

Magic was one of the easy ones, but it shows off the power of angr in finding good code paths.

 

$ file 4245f48054debd4d1a4cc0e5bd704705bff1440607443b8c6fc5c342d067e93e
4245f48054debd4d1a4cc0e5bd704705bff1440607443b8c6fc5c342d067e93e: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, stripped

Category: Pwn Points: 300 Solves: 53 Description:

h3y... can you leave me a note?

For this challenge we were given a binary and the libc used on the server. Up front I should say, I didn't solve this challenge the way it was intended. Other writeups out there will go over the proper way. This writeup goes over my way.

For this challenge, we were given a binary named "mute". The reason for this name becomes apparent in a minute.

 

$ file mute
mute: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=3c37c5241fad4af47c79288b1f0aea4b63418e86, not stripped

 

I find this challenge to be good for two reasons. First, the premise is interesting/novel. And second, this is an example of a challenge that can be simply stated and does not attempt to make itself harder through obfuscation of the vulnerability. I came up with my solution right as the contest was ending, so I do not have the flag nor did I run it against the server. However, this solution worked well for me and is interesting.

This was an exploit challenge that serves as a nice introduction to the concept of Stack Smashing Protector leaking.

$ file checker 
checker: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=93df47896b068ea44ddcd0b97780375cd589987e, not stripped