CSAW Quals 2012 – exp400


challenge2 is an Linux x86 binary with a format string vulnerability. If our format string contains no common shells, it gets placed in bss so we can just jump directly to it.


We quickly find the interesting function and notice the obvious format string vulnerability (Some functions renamed for increased readability.)

Vulnerable function

There are a couple of things we need to observe for this exploit:

  • The snprintf fills a buffer on the stack (there is actually a buffer overflow here we didn’t use but could have), so we can use it to get arguments we want on the stack.
  • The program will exit if it detects /bin/sh, /bin/bash, etc. in our string, so we cannot use shellcode with those as constants. Luckily, my favorite shellcode doesn’t have this problem.
  • Immediately after the snprintf, the function countdown makes another call to snprintf.
  • Our format string is initially placed in bss, which is at a known location and is executable.

But now we have everything we need for our exploit: we make a format string that overwrites the GOT address of snprintf to point to the area in bss with payload. The format string will have the form: shellcode + padding + addr_of_snprintf_got_hi + addr_of_snprintf_got_lo + format_string. Here is an exploit.

Writeup by Alex Reece, see me on Google+.

  • Unamed

    Hi PPP,

    I test this challenge with your expoit code on Ubuntu 12.04 LTS 32-bit but not successful. Does I need to disable any protection ?


  • skdltmxn

    when i was struggling with that format string attack, i found that the binary just died whenever i send a format string as “%600c”. So i couldn’t overwrite GOT of snprintf… do u know why it happens, and how could your exploit work properly?

    p.s) when tested on my local machine, i got SIGSEGV when “%600c” was sent.

  • bbolmin


    In the above code “second_size = (target_val & 0xFFFF) – first_size – len(first_part)”

    why are there “len(first_part)” ?