{"id":228082,"date":"2016-04-03T20:44:42","date_gmt":"2016-04-03T18:44:42","guid":{"rendered":"http:\/\/securite.intrinsec.com\/?p=1972"},"modified":"2016-04-03T20:44:42","modified_gmt":"2016-04-03T18:44:42","slug":"write-up-nuit-du-hack-2016-ctf-quals-matriochka-step-4","status":"publish","type":"post","link":"https:\/\/www.intrinsec.com\/en\/write-up-nuit-du-hack-2016-ctf-quals-matriochka-step-4\/","title":{"rendered":"Write-up \u2013 Nuit du Hack 2016 CTF Quals \u2013 Matryoshka step 4"},"content":{"rendered":"

Introduction<\/b><\/h1>\n

Some of Intrinsec's consultants participated, as independent individuals, to the Nuit du Hack CTF Quals \u2013 2016. We are satisfied with our ranking (#52 over 447 teams who solved at least one challenge) and we were one of the few teams to solve the Matryochka step 4 challenge (500 points) so here is our writeup.<\/p>\n

This could also be useful to malware analysts who want to reverse-engineer an infected MBR (like in a recent ransomware).<\/p>\n

Identification<\/b><\/h1>\n

The previous step, Matryoshka step 3<\/i>, gives us a binary file (download<\/a>), weighing 5,120 bytes.<\/p>\n

Tea file<\/i> command recognizes a \u00abDOS\/MBR boot sector\u00bb. HAS fdisk -l<\/i> on it identifies four 1 Tb partitions with the same start and end offsets (we ignored this fact). Running strings<\/i> returns an interesting one: \u00abWhat's the magic word? ".<\/p>\n

VM setup<\/b><\/h1>\n

Set up a minimal VM (1x vCPU and a few megabytes of RAM and hard-disk space) to execute this MBR code, using VMWare Workstation. The VM is booted on a GParted CD ISO to access the raw disk and copy the MBR on it:<\/p>\n

\"image23\"Then disconnect the ISO and reboot the VM to find the expected prompt:<\/p>\n

\"image17\"Try to type something and see it fail:<\/p>\n

\"image20\"interestingly, the \u00abbadboy\u00bb message was not found by strings<\/i> so it must be decoded during the execution.<\/p>\n

Debugging setup<\/b><\/h1>\n

VMWare VMs can be remotely debugged, using the GDB protocol, even during the initial BIOS and MBR steps. You have to add the following lines to the .vmx file (source<\/a>):
\n
\ndebugStub.listen.guest32 = "TRUE" # enables debugging
\ndebugStub.listen.guest32.remote = "TRUE" # Allows debugging from a different computer \/ VM instead of localhost. The IP for remote debugging will be that of the host.
\ndebugStub.hideBreakpoints = "TRUE" # Enables the use of hardware breakpoints instead of software (INT3) breakpoints
\nmonitor.debugOnStartGuest32 = "TRUE" # Breaks into debug stub on first instruction (warning: in BIOS!) # This will halt the VM at the very first instruction at 0xFFFF0, you could set the next breakpoint to break *0x7c00 to break when the bootloader is loaded by the BIOS
\n<\/code>
\nWhen you start the VM, it hangs on a black screen, it is normal. Then you can start your preferred GDB-compatible debugger, I chose IDA. In the Debugger <\/i>menu, choose Attach -> Remote GDB debugger<\/i>. Input the listening IP and the default TCP port 8832, click OK then select attach to the process started on target<\/i>, and type F9 to continue execution.<\/p>\n

Analysis<\/b><\/h1>\n

The VM should now show you the prompt, type something, but don't hit ENTER, then suspend the execution in IDA. Inspect the memory in the Hex view<\/i> to find familiar strings:<\/p>\n

\"image25\"Our input is stored at 0x1003 so let's place a hardware RW breakpoint. I didn't find an easier way than right-clicking in the IDA view<\/i>, selecting Synchronize with->Hex view<\/i> to be able to right-click on the data and select Add breakpoint<\/i>:<\/p>\n

\"image31\"<\/p>\n

Don't forget to synchronize back the IDA view <\/i>with EIP. Hit F9 to resume execution, and hit ENTER in the VM to submit this password. The VM pauses because the breakpoint is triggered.<\/p>\n

Follow the execution step-by-step or hit F9 until it triggers again to see interesting comparisons:<\/p>\n

\"image21\"<\/p>\n

It looks like the beginning of a string \u00abGoo\u00bb, so edit the password in the Hex view <\/i>to make it match (or set EIP at 0x14C0 to skip the checks), then continue following the execution thanks to the breakpoint.<\/p>\n

If you go too far and miss something, disable the breakpoint, restart from the beginning, type the password, suspend the execution to enable the breakpoint, resume with F9, hit ENTER.<\/p>\n

We gradually find the remaining chars of the string:<\/p>\n

\"image16\"<\/p>\n

\"image24\"<\/p>\n

\"image29\"<\/p>\n

So we have \u00abGood_Game_!\u00bb \u00bb which really looks like a flag, let's try:<\/p>\n

\"image26\"<\/p>\n

I submitted this flag and unfortunately it did not work. An organizer kindly answered us on IRC: it was a nice side effect but not the expected flag (very frustrating!) so I continued the analysis relying on the breakpoints to see if something else happened to the password after this.<\/p>\n

It found the following routine which modifies the password in-place with a promising XOR:<\/p>\n

\"image27\"<\/p>\n

I replaced the password with null bytes, to get the key after execution, we can even see that it is repeated:<\/p>\n

\"image22\"<\/p>\n

We extend the length of the breakpoint to 0x18 to catch every operation on this whole area. And we find more interesting comparisons:<\/p>\n

\"image18\"<\/p>\n

Caution: it begins with EBX=0x1004, the second letter of the password, and it adds to EBX at first 2, then 1, then 6. It means that the comparison is not done sequentially char by char. The next routines work the same way:<\/p>\n

\"image30\"<\/p>\n

\"image19\"<\/p>\n

So we have everything, including the expected string after the XOR routine (length = 11), in the right order. We XOR lines 1 and 2 in the following table and obtain the expected input:<\/p>\n\n\n\n\n\n
Expected result<\/td>\n0x28<\/td>\n0x37<\/td>\n0x77<\/td>\n0x5b<\/td>\n0x31<\/td>\n0x90<\/td>\n0xd4<\/td>\n0x68<\/td>\n0xdf<\/td>\n0x2c<\/td>\n0xb9<\/td>\n<\/tr>\n
XOR key<\/td>\n0x6C<\/td>\n0x53<\/td>\n0x05<\/td>\n0x6a<\/td>\n0x5c<\/td>\n0xfc<\/td>\n0xfb<\/td>\n0x0e<\/td>\n0xad<\/td>\n0x4a<\/td>\n0xb9<\/td>\n<\/tr>\n
Expected input<\/td>\nD<\/td>\nd<\/td>\nr<\/td>\n1<\/td>\nm<\/td>\nl<\/td>\n\/<\/td>\nf<\/td>\nr<\/td>\nf<\/td>\n0x00<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

 <\/p>\n

It looks less like a flag than the previous one, but it works, and it is accepted by the submission webapp!<\/p>\n

\"image28\"<\/p>\n

Things that did not work<\/b><\/h1>\n

It is also interesting to know what I tried but that did not lead to anything interesting:<\/p>\n