The challenge deadline has arrived and a lot of writeups are coming out from various blog pages. The solutions of the first two parts are similar, but the last part has been solved approaching the problem in many ways. As far as I’ve seen the most common approach is guided by the Linux mount command, but I’ve seen the use of Autopsy, Foremost, X-Ways Forensics and The Sleuth Kit just to mention some tools. I don’t know many of them, and I don’t even know that my FileHunter program is quite similar to Foremost.
Here is the first thing to do, call the program passing the file to analyze as parameter. FH tries to understand all the possible file types contained inside the input file. With this simple invocation FH doesn’t check if one file is inside another one or not, it simply shows everything it’s able to recognize; the check is done over specific file signatures only. The offset is in decimal value.
When I saw the output I felt quite happy because the tool can extract all the displayed types except the DOC (I’m still working it).
12 files revealed but just 7 saved as correct files (except the DOC file of course). Why? Two options: some files are included in the previous saved file(s) or there is one or more false positive. The answer is a combination of both options.
So, seems like I have the necessary files except one. How can I extract the DOC?
The DOC class is incomplete because the extraction feature is not yet implemented but, like all the other types, it’s possible to see some details about the header.
“-d” option is used to get details about a specific file type at a certain location. Type and location are both passed via command line. These are the info I have added for a DOC type, nothing special I know but this type is still under development. I can’t say too much from the output, but I’m almost sure it’s a real DOC file: sector and mini stream sector have standard values, Word.Document exists and Root Entry is where it should be:
Ok, I have the starting point but not the end of the file. Can I guess it? Looking at the DOC details I know that the Word.Document keyword is at offset 2581068, it’s after some revealed file signatures (look at the first picture) and it’s higher than the other interesting values (like Directory or Mini FAT starting location). Taking a look at the bytes after 2581068 offset you’ll see a lot of 0x00 bytes followed by a JPEG file signature. Could it be a good end point for the DOC file? I think I can try to extract the DOC file stopping some bytes after offset 2581068 (it doesn’t matter if you don’t get the right end point of the original file):
File has been saved and I can view it with Word or OpenOffice or any other .doc viewer.
With all the necessary files I was able to locate every single secret message.
In the end, this is just an excerpt of FH. It’s based on Foremost principle but it has more features and I think it can be handy from time to time.
If you want to read some Sans Holiday Challenge 2014 complete solutions take a look at: