ThinkTank Forensics

Awhile back I posted an EnScript to create thumbnail photos from video file(s) inside of EnCase. You can read the original post here. There may be many different reasons you want to create thumbnails from video files inside EnCase, one of the most common being to quickly review the video in thumbnail format for relevance.

I was recently contacted via email from a reader who also created an EnScript to create thumbnails from video files inside EnCase using Mplayer and VLC.

Here is a description from Oliver Höpli:

The EnPack uses the Mplayer and the VLC- Player to create the thumbnails. It also adds this thumbnails to a LEF that can be processed in EnCase.

You can download the EnScript here.

Humpty Dumpty sat on a wall,
Humpty Dumpty had a great fall.
All the king's horses and all the king's men
Couldn't put Humpty together again.

This practical exercise is very much like Humpty Dumpty. It's a simple scenario, a simple JPG file fragmented in unallocated space. The complex part is that its in 35 pieces (fragmented) and they are not necessarily in order, and the FAT table is completely gone :(.

Well, all the kings men couldn't put Humpty Dumpty back together again, but Daniel Walton from e.law Asia Pacific Pty Ltd (elaw.com.au) in Australia was able to put this highly fragmented, unusual JPG image back together and solve the puzzle. If this had been a real case, he would have been paid a large amount of money for doing almost the impossible. Great job Daniel!!

Here are his notes:

-----------------------------------------------------------------------------------------------------------------
I have recovered  your number on the jpg.

983456 294001 991201

Have attached the recovered .JPG

##Extra Credit:
##Can you hypothesize as to what happened to make the file "disappear"?

It seems that the file was formatted by the mac pc.

###Can you articulate the status of the drive and what, if anything is different that a typical flash disk?
[a]  media descriptor byte
Now the media descriptor byte at the beginning of the FAT on the image signifies a floppy disk.( 0xf0)
re http://support.microsoft.com/kb/140418
Byte   Capacity   Media Size and Type
F0     2.88 MB    3.5-inch, 2-sided, 36-sector
F0     1.44 MB    3.5-inch, 2-sided, 18-sector
F8     -----      Fixed disk

on my usb drives it's 0xf8
now that is true for both partitions.

[b] two partitions.
Most usb drives only have 1 partition as windows will not display both partitions on a USB drive.
The file was on the second partition , which wouldn't be visible on the pc if the first partition was formatted to a FAT or NTFS filesystem.

So the first partition must of not had a  FAT or NTFS filesystem or the partition was  been deleted.

The evidence had the following two partitions.
The first partition was formatted by macos.  ("BSD  4.4" , FAT16)
The second partition had been formatted by windows. ("MSWIN4.1" , FAT32)

With this setup the second partition will not be accessible under windows.

For windows to mount the second partition the first partition must (a) not have a  FAT or NTFS filesystem or (b) the partition must been deleted.
I would assume the first partition originally was created but wasn't formatted when it was put in the MAC.

Not having a MAC I couldn't test it's behavour with partitions and USB sticks.
I know Linux will happily see all partitions on a USB stick.

Unless the first partition wasn't originally formatted , in which case that could be why the file wasn't immediately viewable on the mac and was viewable on the pc.

The partition table is EFI , which is the default format mac's make.

[c] File fragmentation.
The file was extremely fragmented.
the end of the file (footer) was stored before the beginning of the file. (header)
Not a normal situation , shows extreme fragmentation or unusual circumstances.

###  Provide the MD5 of the recovered file.
Can't do that as I have removed all of the section which has a header of 0xFFE2.
I couldn't find any info regarding that part of a jpg which would help me to find the missing parts.

After finding the header and footer if  searched for 0xff00 to find the image data.

My method was to use a hex editor and combine the parts manually.

I used encase to find the pictures header.
Then tried data carving it with "revit" which didn't find anything.

So researched the JFIF file format and found out what I could about the format and the headers in the file.
Searched for the most important headers and found the following.
FFD8 , FFE0 , FFE1 , FFE2 , FFDB , FFC0 , FFDA & FFD9
Exported all chunks with the above headers.

Found that JFIF files use byte stuffing and 0xFF00 is used to represent 0xFF , so searched for all blocks containing 0xFF00.

The size of the FFE2 section was fairly large and I couldn't easily find any details about it's format , so removed it.
(used the following two bytes after the header as the section size. (big endian))

Removed any sectors which contained 0xFF followed by a byte which's value is under C0 but still keeping all sectors which contain 0xFF00. (so keeping 0xFF00 and 0xFFC0 and above)

Connected sections FFD8 , FFE0 , FFE1 , FFDB , FFC0 , FFDA together.

Then appended first 4 found sectors containing 0xFF00 . ( Hadn't found the rest of them at that stage)
The resulting JPG wasn't quite correct , so changed the order until it displayed correctly.
This gave me the first two rows of numbers and half the HDD picture.

I search further and found all the other sectors with 0xFF00 .
Luckily I had started from the beginning as they were all in order and then appended them one by one until I ended up with the correct image.
Appended the footer when I had run out of data.

I had been hoping that I might of been able to find part of the original FAT table so then I could figure out the order of the sectors, but didn't

It was not an easy puzzle.
Was a good challenge !!
---------------------------------------------------------------------------------------------------------------------------

Here is the recovered JPG:


The file was fragmented severely across the second partition. Here is the order of the pieces notated in physical sector numbers :

427586, 427587, 427588, 427589, 427590, 427591, 427592, 427593, 427594, 427330, 426497, 428505, 428434, 428433, 427750, 427749, 427751, 427712, 427713, 428685, 428686,  426442, 426443, 426718, 428457, 426858, 426859, 426878, 426879, 426172, 426188, 426208, 426228, 426246, 427202.

Here is the true scenario:
This flash drive was partitioned and formatted using a MAC. The default was to use a GUID partition table. This caused two partitions to be created. The first partition is used as the GUID partitioning config and the second is actually the usable one.  When used on a MAC, there is no problem and just one partition is seen (the second one). When inserted into a Windows XP machine, the OS says the flash disk needs to be formatted and when you choose "yes" to format, it only formats the first partition (The one containing the GUID partition information) which is only 200MB in size. So in this case, I had a flash device that was 4gb, but the actual reported size in Windows was 200MB. I then deleted the second partition after "laying" down the fragmented JPG.  I manually assigned each piece to each sector using the diskmap tool by Tim Coakley (http://www.simplecarver.com/software.php?cat=All).  This tool allowed me to created the highly unusual, but not impossible, fragmentation and disorder among all the JPG pieces. I then reformatted the second partition using the MAC.

I admit that it is not often that you see the beginning of a file *after* middle parts or even the end piece of a file, especially in a FAT file system, but I have to honestly say that I have seen this situation on real evidence before.

To summarize, it's a simple JPG image with a text layer containing the 18 digit account number. I broke the account number into three parts, six digits each and placed the first part at the top, the second in the middle and the last part at the bottom, so if you started to recover the JPG you could start to see the account number, but not all of it until you got all the pieces (yes, it was evil). If you put the first 23 pieces together, you will get a partial image with the first portion of the account number, then you have to put the remaining pieces in order to get the rest.

I was very surprised and pleased at the amount of emails and responses I received asking questions and providing comments about the practical. It indicated to me that there are a lot of people that enjoy doing these puzzles/practical, so I intend on creating some more and posting them shortly.

Thanks to all that participated and congratulations to DANIEL WALTON!!!!

BitLocker Full Volume Encryption (FVE) is included in some versions of Windows 7 and it has changed a little compared to the version included with Windows Vista. There are (6) six versions of Windows 7 available:

• Starter
• Home Basic
• Home Premium
• Professional
• Enterprise (volume licensing)
• Ultimate

The Starter version provides the minimal amount of features and each version above that adds additional features. Like in Windows Vista, BitLocker is only available in the Enterprise and Ultimate versions of Windows 7. It seems at first glance, Microsoft has enhanced the Bitlocker capability with "BitLocker to go", an extention of BitLocker designed for removable drives. Here are the BitLocker hardware requirements directly from the built in help:

Windows 7 creates small thumbnail images of graphic files the same way previous version of Windows does, nothing new here. It stores the thumbnails in the same location as in Windows Vista:

C:Users%username%AppDataLocalMicrosoftWindowsExplorer

There are files named Thumbcache_32.db, Thumbcache_96.db, Thumbcache_256.db & Thumbcache_1024.db which correspond to the thumbnails stored for that specific user account and size.

Currently, the latest release of EnCase (6.15.0.82) does *not* parse these files correctly. The structure has slightly changed and therefore if you try and view the contents of any of the "thumbcache" files, EnCase will mount them without error, but they will appear empty. You can however, use the File Finder module to carve JPG images out of the *.db files.

If anyone is using any other tools and can confirm they handle these new Windows 7 thumbcache files correctly, please post the name in the comments so everyone can benefit and have a tool until EnCase incorporates this support.