Tuesday, January 12, 2010

Forensic Practical Exercise #3 - SOLVED

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!!!!

Monday, January 11, 2010

Forensic Review of Windows 7 - Part V - Bitlocker

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:


When you look at the BitLocker options from the control panel you may notice some new options:

Removable devices are now treated differently than internel hard disks and are listed below under the heading "BitLocker to go". When you encrypt a removable device, you are presented with a screen that lets you set your own password as well as other authentication methods. This is a change fromt he way Vista handles removable devices and the fact that the user can set the pasword.




Once you enter a password the drive is encrypted, but in a different way than using Bitlocker on removables in Windows Vista. With Windows 7, BitLocker to Go is used and the contents of the flash drive are encrypted into a file container, then an application is placed on the removable device, letting you access the entrypted container from other computers, including non-Windows 7 computers. If you look at the removable device in WIndows explorer or via forensic software, you will see several files:



Normally, I get nervous when I see "autorun.inf" on any removable drive. But in this case if you don't have the autorun feature disabled in the registry (your should!), then the "BitLockerToGo.exe" application is started. Once the application starts, it will then ask for the password that was set.





Once the password is entered, the contents of the encrypted container is displayed and you can copy files from the device:



The BitLockerToGo Reader only allows a non-Windows 7 computer from *viewing* and copying files from the flash device. You cannot add files onto the device using the BitLocker Reader program. However, if you insert the removable device into a different Windows 7 computer with BitLocker enabled, you can access and add files as long as you present the correct password or smartcard.

From a forensic tool, the removable device will look like this:



The COV file is the container file that actually contains the encrypted data. The example above was created on a 4GB flash device.


For internal hard drives, the process is very similar to Windows Vista. You can enable BitLocker and it will create a second small partition that is used for the initial boot process. The main partition is then completely encrypted (not a container like BitLocker To Go). From a forensic tool, an encrypted volume will look like this:


The "C" volume is the boot partition and is not encrypted and the "D" volume is the actual encrypted volume. It is important to note that the above drive letters are assigned by EnCase and are not the same as what would be seen on a live Windows machine with BitLocker enabled. In Windows Vista, the second partition was usually labelled "S". In Windows 7, it does not have a drive label by default. The boot sector of the encrypted volume looks like this:



Gpedit.msc can be used to configure several new options with BitLocker:











This last screen shows how to use BitLocker without a TPM chip. Just enable the "Require additional authentication methods at startup" and check the "Allow BitLocker without a compatible TPM" checkbox.

 The current version of EnCase (6.15.0.82) does not support decryption of a BitLocker volume created with Windows 7 with the EDS module as it does with Microsoft Vista.

Sunday, January 10, 2010

Windows 7 Forensics - Part IV - Thumbcache_*.db

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%\AppData\Local\Microsoft\Windows\Explorer

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.

Sunday, January 3, 2010

Forensic Practical Exercise #3

So I figured many of you may be on vacation and would like a little puzzle to work on during your free time ;)

Scenario:
Your company has been contacted by a very wealthy and prominent business. They have one simple request. They would like you to do some data recovery and recover one simple file. The President of the company explains that he has a USB flash device that contained one simple file and that when he gave it to the company accountant (who uses a MAC), the drive suddenly became unreadable. The President advises you that the file contains the account number of a very important bank account and that he needs that 18 digit account number. Nothing else matters to him.

The file is *very* important and he is willing to pay you whatever fee you demand if you are able to recover the file exactly as it was.

Your mission, if you choose to accept it, is to recover the file and be able to tell the President (me) the account number (via email, please don't spoil it and post it in the comments, send to lance(at)forensickb.com).

Extra Credit:
Can you hypothesize as to what happened to make the file "disappear"?
Can you articulate the status of the drive and what, if anything is different that a typical flash disk?
Provide the MD5 of the recovered file.

I will provide an exact explanation of what was done to the device and file to those who submit answers so you can compare it with what you see. 

There is no encryption or hidden elements to this problem. This is a classic puzzle. For this scenario, I will be the "President" who lost the data and has contacted you. Feel free to "interview me" and ask any further information that you feel necessary, via the comment section (so everyone can benefit).

Good Luck!

Download Here (7.5MB)

Saturday, January 2, 2010

Forensic Review of Windows 7 - Part III

This post is a New Year's present from Troy Larson. Troy emailed me a presentation a few days ago that he and Harlan Carvey did a few months back that outlines many of the changes with Vista and Windows 7. With his permission, I am posting the PPT, converted to PDF for everyone to benefit.

Thanks Troy and Happy New Year to everyone!

Download Here

Computer Forensics, Malware Analysis & Digital Investigations

Random Articles