±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 0 Overall: 35734
New Yesterday: 1 Visitors: 92

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Videos

±Latest Jobs

Logical evidence file size reduction

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Page 1, 2  Next 
  

xandstorm
Member
 

Logical evidence file size reduction

Post Posted: Apr 17, 19 18:30

Hi all,

Having a 3TB network disk that the suspect tempered with and deleted files from prior to the device being seized for examination.
Conducted a file carve operation on the disk and subsequently applied some regex search patterns to it.

Nothing complicated so far.

However, upon exporting the search results to a logical evidence file, the size of the LEF export exceeds 300TB.
This is an unworkable amount of data and just exporting it will require weeks of not longer to complete.

Challenge here is that the majority of all search pattern hits are related to the unallocated disk space of the disk.
The LEF export process copies big chunks of the same part of the unallocated disk space with it.
Leading to the 300TB+ in LEF size.

I was wondering if it would be possible to just have that same chunk of unallocated disk space exported just once instead of re-copying / re-exporting the same chunk over and over again.

Is there anyone on this list that has a solution for this LEF size problem in particular or the reduction of LEF size in general?

Thanks!

Rg,
Lex  
 
  

TinyBrain
Senior Member
 

Re: Logical evidence file size reduction

Post Posted: May 25, 19 11:01

Lex, look into AWS DynamoDB to solve the downsizeing  
 
  

xandstorm
Member
 

Re: Logical evidence file size reduction

Post Posted: May 25, 19 11:24

Hi TinyBrain,

Thank you for the reply, will look into this later, currently traveling.

Saludos,
Lex  
 
  

armresl
Senior Member
 

Re: Logical evidence file size reduction

Post Posted: May 26, 19 00:25

Did you mean 300TB or 3TB?
_________________
Why order a taco when you can ask it politely?

Alan B. "A man can live a good life, be honorable, give to charity, but in the end, the number of people who come to his funeral is generally dependent on the weather. " 
 
  

xandstorm
Member
 

Re: Logical evidence file size reduction

Post Posted: May 26, 19 13:19

Hi armresl,

The initial confiscated disk has a size of 3TB and the exported LEF dataset encompasses a theoretical 300TB and it was tried in different forensic suites.

Rg,
Lex  
 
  

watcher
Senior Member
 

Re: Logical evidence file size reduction

Post Posted: May 27, 19 17:29

- xandstorm
Hi armresl,

The initial confiscated disk has a size of 3TB and the exported LEF dataset encompasses a theoretical 300TB and it was tried in different forensic suites.

Rg,
Lex


While at first blush, this seems impossible, I have seen something similar on a smaller scale.

The variant I saw had to do with millions of tiny files, mostly gifs and thumbnails. Attempting to copy them to another media overflowed even though the target media was much bigger than the source media. The problem was that the source media used a very small block size, while the target media used a rather large block size. The net result was each tiny file took up a large block on the destination media.

Look at the media block sizes of both source and destination.

If you need to deal with a huge amount of tiny files, putting them into a database instead of separate files may work better.

Come to think of it, this would make an interesting anti-forensics method.  
 
  

xandstorm
Member
 

Re: Logical evidence file size reduction

Post Posted: May 28, 19 03:27

Hi watcher,


I think the whole problem here is the lack of adequate deduplication options when it comes to exporting to a LEF.

It is understandable that, from the perspective of maintaining forensic integrity, each search pattern hit is associated with the file it was found in and that the file in question is exported to the LEF as well.

The issue for me started when a large number of search pattern hits were related to a file carve operation or unallocated disk space search. The export to the LEF process copies large chunks of the unallocated disk space again and again.

I have seen the same with PST container files. When there is a search pattern hit in 1 e-mail, most forensic suites export the entire PST file to the LEF.

It just seems that with the ever growing size of seized evidence data, the LEF exporting processes are walking behind, particularly when it comes to deduplication options.

At the moment I am running some test exports and will definitely look into the block size advise.


Rg,
Lex  
 

Page 1 of 2
Page 1, 2  Next