This challenge came only with a .bin-file, and a quick ‘file’ told me this was going to be fun:

doogie.bin: DOS/MBR boot sector

Awesome! I’ll have to debug PC boot code! For this challenge I used IDA as disassembler (remember to select 16-bit mode!), qemu as emulator to run the binary and radare2 to attach as a debugger to qemu to debug the binary.

Booting it up shows some nice ASCII-art and asks for a password:

The date in this screen appears to be the first clue. Entering any random password yields crap to be shown on the screen.

First stage bootloader

The bootloader code in the MBR is limited to 446 bytes, so most OSes first load a ‘second stage’ bootloader from disk to RAM and execute this; as does this binary:

Second stage

The second stage prints some ASCII-art and text to the console, then reads the time/date value from the RTC. The function I labeled decrypt_stuff runs over an array in RAM and does a simple XOR decryption:

The first decryption pass is done with the date from the RTC. Didn’t we see a date on the boot screen? That means we’ll probably have to change the date! This can be done with the -rtc base="1990-02-06",clock=vm parameter for qemu.

After setting the correct date, I looked at the ciphertext with the debugger in memory:

See those phrases that appear? ‘IOPERATEONMALWARE’? That’s probably a clue for our password.. But how come it appears in the ciphertext? As you may know, 0x20 can be used with XOR to convert uppercase to lowercase and vice-versa, so maybe there are lots of spaces in the ciphertext? Let’s try ‘ioperateonmalware’ as password:

There’s our flag! :)