I've seen a number of requests for a writeups on the forensics 200 challenge from Defcon Quals, so I figured I would write one up. Its a relatively simply challenge, but it takes a certain mindset to solve these forensics challenges, so I'll be focusing on that instead of the technical aspects as much. I will, however, try and go step by step so the process can be reproduced.
First off, we'll grab a copy of the file. If you weren't aware, Shell Storm keeps a Repo of the previous CTFs and their challenges, you can download F200 there. Once we've got the file, the first thing to do with most forensics files is to run... file. It will tell us (most of the time) what type of a file we're looking at, so we'll be able to make some sense of it. In this case, we should have output like:
f200_a3c6a7f6a4b4f9511ee83.out: x86 boot sector, code offset 0x52, OEM-ID "NTFS ", reserved sectors 0, Media descriptor 0xf8, heads 255, hidden sectors 2048, dos < 4.0 BootSector (0x80)
Fairly straightforward, we've got what appears to be a NTFS volume, so we'll need to get some tools to work with that. In the past (see Codegate f400), I've used AnalyzeMFT, but its a little more complicated to use than the method we'll use here. I'll go over how to use it to get the data we want, however, at the end.
Instead, I used what might be a lesser known feature of Windows 7 (and Server 2008r2): you can mount VHD files natively. In order to do so, however, we'll need to modify our raw output and turn it into a VHD, but there are tons of conversion tools. I chose VHD Tools, but for no other reason than its on MSDN. Once we have a VHD, load up Disk Management (diskmgmt.msc), and we'll use that to mount the VHD. We'll just go to Action->Attach VHD, and select our VHD file.
Once its mounted, we can start browsing through it. The first thing you should notice is that there are a lot of little "key" files, scatter throughout 100 directories. It would seem like they're mostly random, useless data, so we need to find a way to figure out which one is actually the key. A number of methods are used for this: Are there an duplicates, either in data or name? Are the all the same size? The answer to all of those questions, and similar ones is that for most purposes, all of the files are the same, just with a different key inside of them.
In that case, the next thing to check is to see if there is any inconsistency with the file structure. While we could do something like use AnalyzeMFT, or another tool, and parse all that data output, we can go one step easier: we can simply run CHKDSK on the volume. CHKDSK, while doing all sorts of wonderful magic, will verify that all the metadata for the files are at least somewhat accurate. Now there's something interesting:
CHKDSK is verifying files (stage 1 of 3)...
6 percent complete. (13286 of 22142 file records processed)
Attribute record (272, "") from file record segment 13446
is corrupt.
Interesting. It would appear that file 13446 has some sort of a bad attribute in it, which we'll need to investigate. While there are many ways to do that, we'll use AnalyzeMFT for it. just toss the $MFT file at it, and it will spit out all sorts of fun information (to a CSV). Load that up, find segment 13446, and we've got a file for us to work with. Unfortunately, we just deleted the interesting information, so we're going to have to go grab another copy of the file to look at (unless you mounted the VHD read-only).
With a new copy in hand, lets take a look at that actual record. If we run through AnalyzeMFT with the /d option, it will print out debugging information. That's quite a lot of data, so make sure to dump it to a file, so that we can open it later. If we open the output, we should see that the file, key50883, that is segment 13446, has an "unknown attribute". Now, we could have skipped the whole process, but its a little more difficult to parse this record, and CHKDSK could find additional information. In any case, looking at this attribute, we notice a first thing. Notably, it seems to be almost identical to the data attribute, with only a few bytes different. At this point, we have a few options. In effect, this is an unnammed alternate data stream, so we could go out and find a tool to extract the data. We could also read through the NTFS specification, figure out what those bytes actually do, and figure out where the data is stored. Or, we could do the easy bit, open the NTFS VHD in a hex editor, and changing the data segment to match that of our invalid attribute. Once they've been modified, we can re-mount it, open the file and... POOF a valid key.