Switch branches/tags
Nothing to show
Find file History
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Failed to load latest commit information.
screens added two reverse tasks and one pwn Oct 12, 2017
README.md updated floppy wu Oct 14, 2017
floppy.img added two reverse tasks and one pwn Oct 12, 2017


Square CTF 2017



Category: Points: Writeup Author
Reverse 1000 merrychap


Our team of corn snakes formed an uneasy alliance with the office mice and slithered into the server room of Evil Robot Corp. They extracted an image of the VPN server before they had to retreat. Turns out sending a team of reptiles into a room whose main purpose is to keep its contents cold wasn’t the best idea. Can you figure out how this bootable floppy works and recover the secret data?


First of all, we should understand what this thing is. Using file, we see that this is DOS/MBR boot sector.

$ file floppy.img 
floppy.img: DOS/MBR boot sector

What should we do with it? If you try to run it, you fail, because of format error. Hence, we should find an emulator for this type of system. I'll use qemu.

In the first place, we have to see the code of this MBR. Using IDA Pro we can see the next code (some functions are already renamed):

This function does the next:

  • 16 line: Prints "Challenge" with some random number
  • 19 line: Prints "Code?"
  • 21 — 35: Inputs a string with 4 bytes length.
  • 37 line: Translates the string into hex format (I'm not sure about this function, it isn't necessary for the solution)
  • 38 — 42: Generates 8 bytes and stores them in byte_1DB8
  • 43 line: Compares processed hex and result of sub_BA0 function
    • If they are equal, then prints the "flag" and then execute sub_510 with byte_1DB8 as the first argument.
    • Else prints "Nope".

There are two ways to solve this challenge:

  1. Understand how sub_BA0 works and find appropriate input that will satisfy to the comparison
  2. Execute all instructions until comparison. After this, set eip to call sub_510. Input in this case is useless because doesn't take part in calculating the flag. So it will give us the flag without any effort.

I chose the second variant because it's faster. This is where that comparison located in disassembly:

But to do this trick with eip we have to be in debugging mode. This is where problems come.

First of all, we should run qemu with the possibility of attaching the debugger (gdb, in our case) to the binary. After hours of reading different web pages about it, I found the brilliant tutorial. As we can see, to run qemu in this mode we should do the next:

qemu-system-x86_64 -s -S -m 512 -fda winxp.img

And now we can see, that qemu is running:

Alright, we know from this article, that the address when MBR is loaded is 0x7c00. Let's attach to this process in the gdb and set breakpoint at this address.

Continue execution until the 0x7c00 address:

When everything is done, we have to find the address of the start function. This functions is shown below:

After some debugging steps, we find that the desired function is placed under 0x1000 address:

Okay, we are almost done! Now, we have to calculate the offset of that last comparison from 0x200 (it's the address of start function in disassembly). Offset is 0x217, so let's set breakpoint at the 0x1217 and continue execution. Program waits for an input. We input random 4 bytes.

When we are at that cmp instruction we have to just change eip register to 0x121f and continue execution.

And this is what the binary gives us after comparison:

So, the flag is: