Description: find the key, and they gave us the following file which revealed to be a gzipped raw disk image.
After extracting, use the file command to recognize a raw disk image:
$ file f100_6db079ca91c4860f.bin f100_6db079ca91c4860f.bin: x86 boot sector; partition 1: ID=0x7, starthead 0, startsector 31, 31558 sectors
fdisk shows one valid partition:
$ fdisk -lu f100_6db079ca91c4860f.bin You must set cylinders. You can do this from the extra functions menu. Disk f100_6db079ca91c4860f.bin: 0 MB, 0 bytes 1 heads, 31 sectors/track, 0 cylinders, total 0 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x00000000 Device Boot Start End Blocks Id System f100_6db079ca91c4860f.bin1 31 31588 15779 7 HPFS/NTFS
But thanks to mmls - part of The Sleuth Kit - we can see the full partition table, with the unallocated space not to forget in our analysis:
$ mmls f100_6db079ca91c4860f.bin DOS Partition Table Offset Sector: 0 Units are in 512-byte sectors Slot Start End Length Description 00: Meta 0000000000 0000000000 0000000001 Primary Table (#0) 01: ----- 0000000000 0000000030 0000000031 Unallocated 02: 00:00 0000000031 0000031588 0000031558 NTFS (0x07) 03: ----- 0000031589 0000031615 0000000027 Unallocated
From now on, here is what I usually do (my methodology):
- Extract the partitions simply with dd
- Quick look with strings or even raw hex: not at the main partition (15 MB is too big), but at the unallocated space
- Run foremost or scalpel to quickly extract any interesting files, and have a look at them
- Run The Sleuth Kit with Autopsy browser for more in-depth analysis of the filesystem of main partition
According to the values given by mmls, we can extract partitions with dd.
$ dd if=f100_6db079ca91c4860f.bin of=f100_6db079ca91c4860f_p0.bin bs=512 skip=0 count=1 $ dd if=f100_6db079ca91c4860f.bin of=f100_6db079ca91c4860f_p1.bin bs=512 skip=0 count=31 $ dd if=f100_6db079ca91c4860f.bin of=f100_6db079ca91c4860f_p2.bin bs=512 skip=31 count=31558 $ dd if=f100_6db079ca91c4860f.bin of=f100_6db079ca91c4860f_p3.bin bs=512 skip=31589 count=27 $ file 100_6db079ca91c4860f_p*.bin f100_6db079ca91c4860f_p0.bin: x86 boot sector; partition 1: ID=0x7, starthead 0, startsector 31, 31558 sectors f100_6db079ca91c4860f_p1.bin: x86 boot sector; partition 1: ID=0x7, starthead 0, startsector 31, 31558 sectors f100_6db079ca91c4860f_p2.bin: x86 boot sector f100_6db079ca91c4860f_p3.bin: data
Quick look at unallocated space
Running strings on partition #3:
$ strings f100_6db079ca91c4860f_p3.bin Mustapha Laden 972-3-5197575 Hank Huessein 00-1-703-343-7604 Samir Nagheenanajar 9661-4883800 Pete Mitchell 843-234-2342 Tom Kazanski 343-343-2343 Pete Gibbons 234-324-2342 Hans Gruber 49-89-2888-0 Wah Sing Ku 011-81-3-3224-5000 sf8D aN3jl: ajid sometimesisitreal 24jssj. sometimes it is not real strings suck where0where15thek3y? keyfile.dat
And with a hex dump:
$ hexdump -C f100_6db079ca91c4860f_p3.bin [...] 00000470 0000000000e00000 7768657265307768 |........where0wh| 00000480 6572653135746865 6b33793f00000000 |ere15thek3y?....| 00000490 0000000000000000 0000000000000000 |................| 000004a0 0069007400690073 006e006f00740068 |.i.t.i.s.n.o.t.h| 000004b0 0065007200650000 0000000000000000 |.e.r.e..........| [...]
Ok, it is clear: it is not here.
Foremost, scalpel or even mounting partition #2 give the same files:
$ ls -l -rwxrwxrwx 2 root root 33383 May 19 02:32 2009040811380736734_115018_0.jpg -rwxrwxrwx 2 root root 9970 May 19 02:31 carpenter.png -rwxrwxrwx 1 root root 11765 May 19 02:31 caught.jpg -rwxrwxrwx 1 root root 13862 May 19 02:31 evidence.jpg -rwxrwxrwx 1 root root 36947 May 19 02:32 furries.jpg -rwxrwxrwx 1 root root 4378 May 19 02:33 images.jpg -rwxrwxrwx 2 root root 1929 May 19 02:32 whiteflag.jpgAll extracted files available here.
carpenter.png seems an interesting picture of base64 text: we took some time to extract it with my teammate milo, played with it a bit, but found nothing.
The panda images.jpg has some JPEG EXIF data:
$ jhead extracted_files/images.jpg File name : extracted_files/images.jpg File size : 4378 bytes File date : 2010:05:22 01:57:57 Resolution : 116 x 102 GPS Latitude : N 36d 8m 8.5s GPS Longitude: E 115d 9m 29s Comment : Who is the author?ASCII
We find the ASCII comment Who is the author? and GPS coordinates leading us in China. We even spent some to find the same picture in Google Images to see if we can find some useful information, but nothing interesting.
In-depth analysis of the main partition
For that, I use my favourite tools: The Sleuth Kit with Autopsy browser, which I have already introduced in a previous posting about Codegate challenge #19. Same thing: we create a new case, a new host, add partition #2 and ready to start file analysis.
File analysis view is very useful as always, we can see deleted file C:\key, sadly with no content in it:
However NTFS has an interesting component: the Master File Table (MFT), shown in the NTFS filesystem as $MFT. Let's have a look at it because it may still contain portions of our deleted file.
We could scroll the whole MFT in hex, but is rather big. A better thing to do is to see its metadata 0-128-1 (last column) and view the information from there.
Interesting report. Let's have a look at all the MFT data clusters:
1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 ....
For instance with cluster 1323:
Finally we stumble upon the MFT entry for key file, and find something interesting:
n.o.t.d.e.l.e.t.e.d.,.n.e.v.e.r.existedwhere the dots are null bytes (they may come from Unicode). Seems interesting, try it as a flag, first by adding spaces to make it correct: not deleted, never existed but it does not work, so try without spaces: notdeleted,neverexisted and CORRECT!
You can find another good write-up of this challenge from Scott Wolchok, among others.