Forensic Imaging of...
 
Notifications
Clear all

Forensic Imaging of USB Drive with Corrupt File System

8 Posts
5 Users
0 Likes
2,507 Views
(@mkel2000)
Posts: 24
Eminent Member
Topic starter
 

I'm looking for some suggestions for imaging a USB thumb drive with a corrupt file system (FAT 32). I'm trying to do this with no change to the drive (or as little as possible.)

The USB drive is attached to the forensic computer with either a software write block or a Tableau hardware write block. Windows 7 sees the device and wants to "scan and fix" it upon insertion. I've used Encase, both version 6 and 7, to try to forensically image the entire disk. I can see the file structure as well as data while it is added to Encase.

Encase 7 will get to the corrupt part of the file system and then stops imaging; the imaging timer then begins to increment until I stop the process and generates no error messages. Encase 6 will err out after attempting to image the disk for about 10 minutes.

I have not yet tried to do a logical image of the allocated files but this is my next step. I'm looking for any other suggestions for methods to get a disk image without going through a "scan and fix" by Windows, if at all possible.

Mark

 
Posted : 07/07/2014 8:39 pm
(@francesco)
Posts: 79
Trusted Member
 

Try with FTK Imager
1. click on the first button in the toolbar ("Add evidence item"), select the USB stick from the list (you'll find its device descriptor and size in the list) then click Finish.
2. In the evidence tree right click on the root entry that you just added and select "Export disk image". Add a destination and click start.

It should work even when the stick has damaged flash sectors. If it still doesn't work try with GuyMager on DEFT Linux or ddrescue as a last resource.

 
Posted : 07/07/2014 8:48 pm
(@mscotgrove)
Posts: 938
Prominent Member
 

Once you have your forensically secure image, I suggest you try data recovery software on the image.

Data carving might be a start, but this might fail if the files are fragmented, and the carving cannot handle fragmentation for the file type being investigated.

What file type(s) are you looking for?

A lot depends on how the file system has been damaged.

Forensically, you must not make ANY changes to the drive, but work on ways of discovering data.

 
Posted : 07/07/2014 8:50 pm
(@athulin)
Posts: 1156
Noble Member
 

Windows 7 sees the device and wants to "scan and fix" it upon insertion.

Do you know what the problem is? Try 'chkdsk' without '/f' through a write blocker to just scan it, and get a report of what kind of problems are discovered.

Encase 7 will get to the corrupt part of the file system and then stops imaging; the imaging timer then begins to increment until I stop the process and generates no error messages. Encase 6 will err out after attempting to image the disk for about 10 minutes.

Sounds like the error is deeper than just a bad file system. EnCase should not be referring to the file system, only to sectors. What is it configured to do on read error? Default action is to skip 64 sectors, and try to continue. Have you changed that? Do you plan to?

Do you have any error messages in the system log from which you can identify faulty sectors?

I have not yet tried to do a logical image of the allocated files but this is my next step.

Why? Do you have a plan, or are you just trying random things?

I'd try to get an idea of exactly where the damage starts, and its extent, and then image the remaining parts of the drive. You should have a log message from EnCase or Windows that says where the damage starts. Then, try imaging the sectors at some suitable distance from there – I don't know flash memory architecture well enough, but it's almost certainly an even power of 2. I'd start at 1Mb or 512 kb further into the memory, and if that works, decrease the skip, or if that also fails, increase it. That is, try to be intelligent about finding the end of the damage.

However, there's a point when there's no point in going on. If you reach a point where you've spent the planned budget for analyzing this drive just on imaging it and failing, you're not exactly ahead of the game.

 
Posted : 07/07/2014 9:42 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

If I may, let's try NOT mixing things all together. (physical vs. logical).

If the flash drive is fully functional you do a dd-like or "forensic sound" PHYSICAL image (that is completely "agnostic" to the filesystem(s) used and to whether the filesystem(s) is/are valid or corrupted).
Then you make a copy (still "physical") of the image and either carve it for the files or attempt rewriting/fixing/repairing the filesystem structures.

Be warned that a chkdsk (even without "f" option) SHOULD (if it is the case) NEVER be run on the actual flash device directly if NOT through a writeblocker (only to underline the need of what athulin posted).

BUT, *any* disk imaging tool will work fine with a fully functional device, so, as already said before, it is very likely that you have a much "deeper" problem, including unreadable (faulty) areas of the device.

Your best option, if this latter is the case, is actually ddrescue (or a similar "recovery oriented" tool) that will automate (given the correct options) the skipping of the sectors and also further attmpts to read.

jaclaz

 
Posted : 08/07/2014 2:08 am
(@mkel2000)
Posts: 24
Eminent Member
Topic starter
 

Thanks for the replies and suggestions. I was able to forensically image the thumb drive using a Tableau write block and FTK Imager to create a dd image. I moved the dd image into Encase 7 and then re-acquired it into the Encase format without issue.

I believe that there are some issues with Encase 7 and imaging of hardware that may have issues. I had this issue on three different thumb drives trying to image with Encase 7. It doesn't appear that the error checking process for Encase 7's imager works well (or at all) if presented with hardware that has any kind of "issues."

Mark

 
Posted : 09/07/2014 3:20 am
(@mscotgrove)
Posts: 938
Prominent Member
 

I think one small comment is that Encase is a forensic investigation program, and not a data recovery program. There can be a very large overlap between these applications, but one size may not always fit all.

 
Posted : 09/07/2014 4:34 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

Since now you have the image, you should IMHO "delay" the "forensic part" and then "fork" it. 😯

Make a copy of the image.
Make a second copy of the image.

Repair the filesystem on the first copy of the image (i.e. attempt doing a filesystem based recovery).
Once you have this (hopefully) fixed filesystem/volume do a "diff" of these repaired image against the second copy.
Check which/what/how the repairing altered the first copy (i.e. what specifically were the changes made by the repair process).
Document them.
Verify the exact nature of these changes (as an example - for simplicity - let say that a single word, the "Magic bytes" 55AA were missing in the "corrupted" filesystem/volume VBR and that it was all that the recovery process changed), of course resetting those two bytes to the "standard" (and needed) value are NOT altering the evidence in any way (i.e. the consequence of that change will not create from thin air a compromising file), see
http//www.forensicfocus.com/Forums/viewtopic/t=11739/

Then run Encase (or whatever) on the repaired first copy, get all the reports you need, etc.

Then run Encase (or whatever) on the "untouched" second copy, carving the "raw" data, if the *whatever* you need finding (and is useful for the case) can be found on this untouched copy, you are fine and will never need to produce the "repaired" copy or the reports created from analyzing it.

jaclaz

 
Posted : 09/07/2014 5:37 pm
Share: