CSAW CTF Quals: Reversing 500 Noobs First Firmware Mod

Initially, we get a number of files, which appear to be an ARM program. Imp3rial figure out how to boot and run the program in qemu, allowing us to emulate the correct hardware.  How to Emulate.

 However, to get a good view of the program, I looked at it in IDA. Within IDA, I found two functions of relevance. First, there is the clearly named do_csaw method, shown below.

From this disassemlby, the function can be seen to read values between 0x80002013 to 0x8000203B, and then prints to the memory assigned by the malloc() call. However, when we look at the memory in qemu, there are no values ever loaded into those memory addresses. Since the emulator that we are using allows for command line read/write of memory, I looked at those addresses. While write attempts did not produce any error messages, it did not actually write the memory.

While I figured out how to deal with this, I found another function in IDA that seemed relevant, shown below.

While the rest of the method seems to do something in regards to networking, it also writes the string "SUPERSEXYHOTANDSPICY" to the address read by do_csaw. However, as said above, the write must have failed due to the restrictions on the memory. Although there probably is some way of increasing the size of memory, I found it easier to alter the locations of the read/write between the two methods. I changed it from 0x80002013 and 0x8000203B to 0x07002013 and 0x0700203B, which testing confirmed in qemu as writable. Also, since I believed smc_init to be extraneous to what I was actually trying to accomplish, I altered it to load "SUPERSEXYHOTANDSPICY" to memory, and then exit. Modified functions can be seen below, beginning with smc_init.

do_csaw

I also changed do_csaw to call smc_init to load the memory. Running the program using qemu shows that 0x07002013 is successfully loaded, but searching the memory turns up nothing. However, running the program using gdb multiarch allowed me to step through memory, and see what the program was trying to write. Using carefully selected breakpoints, I was able to see the program was writing output, but it seemed to be continually overwritten by the "2D" value loaded earlier into a register. Using GDB allowed me to read before the overwrite, and get the key.

key={SPREYOADPC}

-albinotomato

 Im