Speeding up file ca...
 
Notifications
Clear all

Speeding up file carving

7 Posts
6 Users
0 Likes
314 Views
(@billa316)
Posts: 5
Active Member
Topic starter
 

Hi All,

So far I tried using PhotoRec for carving out files from unallocated space. But one drawback is the time taken and it varies from disk to disk.

A 500GB could take > 16 hours sometimes. And I have noticed that in some scenarios it goes in a loop before moving on to the next sector etc.

There are also other tools like Foremost (I have not tried yet) available.

Anyone have experience on the optimal linux tool that can be used for speedier file carving?

Thanks and Regards

 
Posted : 08/12/2015 8:51 am
(@sam305754)
Posts: 44
Eminent Member
 

Hi,

There is Scalpel that you can try.

Regards

 
Posted : 08/12/2015 1:52 pm
joakims
(@joakims)
Posts: 224
Estimable Member
 

Depending on the level of detail you want to dig into, importance of the data and time spent, there may be additional options if
- Filesystem is NTFS
- OS accessing the volume was Windows

Then it could be worth, as a last effort, to try https://github.com/jschicht/LogFileParser

It can sometimes recover the cluster mapping of fragmented files that is deleted and have their MFT record overwritten. Recovery of such fragmented files is not possible by standard carving technique.

 
Posted : 08/12/2015 4:01 pm
Passmark
(@passmark)
Posts: 376
Reputable Member
 

Time is going to depend an enormous amount on the hardware used.

For example a traditional spinning 500GB external drive on USB2.0 will be about 50x slower than an internal SSD.

A straight linear read of a 500GB HDD on USB2.0 would be about 7 hours.
A straight linear read of a 500GB HDD on USB3.0 would be about 1.6 hours.
A straight linear read of a 500GB HDD on SATA3 would be about 1.3 hours.
A straight linear read of a 500GB SSD on SATA3 would be about 0.3 hours.
A straight linear read of a 500GB SSD on M.2 PCIe would be about 0.1 hours.

But these kind of tools will also be doing a bit of disk seeking, which is even slower on HDD.

So in some cases it might make sense to image a USB2.0 HDD onto a internal SSD (which would be a linear read). Then do the recovery on the SSD.

If it is taking 16 hours for 500GB and you aren't on USB2.0 then I think there is something wrong with the tool, or the drive (e.g. lots of bad sectors).

 
Posted : 09/12/2015 3:37 am
MDCR
 MDCR
(@mdcr)
Posts: 376
Reputable Member
 

SSD is one option that speeds up things in general, requires a SATA3 interface to be fast.

Same drive image on multiple boxes, carving different file formats = splits up the workload.

 
Posted : 09/12/2015 5:06 am
PaulSanderson
(@paulsanderson)
Posts: 651
Honorable Member
 

If it is taking 16 hours for 500GB and you aren't on USB2.0 then I think there is something wrong with the tool, or the drive (e.g. lots of bad sectors).

It also depends on what is being carved and more importantly how.

If the tool is just looking for jpeg headers and footers then it shold be very quick. If as is more likeley it is looking for internal file markers and validating the recovered data then this will be slower. Likewise if the sofwtare is searching for images at sector boundaries this will vastly speed up the search, searching for a header at any offset in a sector will slow it down. Add in multiple graphics formats and things get slower still.

16 hours seems excessive but as you say we don't know the hardware he is recovering from, the hardware he is using for the recovery, and how they are connected.

He mentions just unallocated so I would think it possible that this is a file copied to a local disk.Conversely it could be a forensically mounted disk/image in whcih case it would be hideously slow.

And I have noticed that in some scenarios it goes in a loop before moving on to the next sector etc.

If it is so slow that you can see it in a loop at a sector level - then it really is slow )

 
Posted : 09/12/2015 2:29 pm
(@billa316)
Posts: 5
Active Member
Topic starter
 

Hi All,

I imaged into NAS and was doing the carving from the image which is residing on the NAS.

One of the reason could be the bad sectors. This particular harddisk had lots of bad sectors.

Think read/write limitations on the NAS plus the bad sectors could have contributed to the longer carving time.

Regards

 
Posted : 10/12/2015 8:02 am
Share: