PhotoRec module missing files in corrupt image

[kefir-]

I just tested the photorec module with a real life disk image, and lots of files weren't recovered.

A short "case description": A professional photographer took photos in my kid's kindergarten. I received the photos on an obviously really cheap USB drive, and the contents were corrupted when I received it, and none of the photos could be opened (or perhaps one or two could).

I manually imaged the USB drive with dd and ran photorec on the disk image, and that recovered all the photos plus a lot of additional files that had resided on the USB drive before this current use (the output folder contains 130 carved files, and 110 of these are jpg files - discounting all files beginning with "t"). The additional files appear to be pictures and files from some sort of business brochure, but all text is in Chinese so I can't tell for sure. In any case, these files aren't interesting to me, but they're there.

However, when I open the same image in autopsy and run the photorec module, I only get a fraction of the files, and none of them are the photos in question ($CarvedFiles contains 17 files, and 6 of these are jpg files). Presumably, this happens because photorec only gets to work with the unallocated segments of the file system, whereas I ran it on the entire disk in my manual session. The disk areas that are allocated (and corrupted) appear to cover the areas where the photos are located, so I guess they aren't given to photorec in the first place?

Perhaps there should be a second module option to pass the entire disk image to photorec? It'd be slower, and will result in duplicates, but these could be filtered by byte-runs or checksums.

I also tried adding the image file as a Logical File, and then I ran the photorec module on LogicalFileSet1, but that seemed to return immediately without doing any carving.

I'd be willing to share the disk image with developers for internal testing. I'd rather not distribute it freely.

[bcarrier]

It makes sense that there would be fewer because, as you point out, Autopsy only sends unallocated space to PhotoRec. There are a few scenarios that could be going on:

1) All of the files not recovered by PhotoRec in Autopsy are also available in the file system structure in Autopsy and therefore you still have access to the same files as before. You mentioned $OrphanFiles before. Is that the only file/folder that you see?

2) The file system is corrupted and there are far more blocks that are marked as "allocated" even if thre is no file name pointing to them. Therefore, because they are considered allocated, then we neither carve them or make them available via the file system directory structure. Note that we have had many discussions on this in the past about the best way to define "unallocated space" and different tools define it differently.

3) PhotoRec is recovering all of the files and we simply have a bug and are not adding all of them back into the case.

To help narrow these down, the image would be useful. You could also help with these questions:

• Are there files/directories in the image?
• If you look at the size of the unallocated space files in Autopsy, what do they add up to?

[kefir-]

Thanks for looking into this. I think photorec is recovering everything in the unallocated fragments it gets. I exported the unallocated ranges manualy and ran photorec on those, and I got 16 files (not 17 like in the image, I'm missing a .fat entry).

The entire image file is 1007681536 bytes, and the two unallocated runs are 546553856 and 416301056 bytes, so that's a total of 962854912 bytes. That leaves about 44.8 million bytes of allocated data. The pictures in question (as carved manually with photorec) add up to about 38 million bytes.

Here's a screenshot of the disk image in autopsy, and as you can see from the hex view, the JPGs in $OrphanFiles are not valid JPG files. Each file name has several entries, they have different meta_addr, but always appear to have the same size and content.

If I mount a copy of the same disk image under Ubuntu, here's what it looks like:

So this USB drive was clearly severely corrupted. But the pictures are in the image, and they are carveable with photorec.