±Forensic Focus Partners

Become an advertising partner

±Your Account


Username
Password

Forgotten password/username?

Site Members:

New Today: 3 Overall: 35628
New Yesterday: 2 Visitors: 121

±Follow Forensic Focus

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

RSS feeds: News Forums Articles

±Latest Articles

±Latest Webinars

Issues with: Forensic Acquisition Of Solid State Drives

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, 3, 4, 5, 6, 7, 8  Next 
  

AmNe5iA
Senior Member
 

Issues with: Forensic Acquisition Of Solid State Drives

Post Posted: Mar 14, 18 18:54

Recently Forensic Focus published the following article.

Forensic Acquisition of Solid State Drives with Open Source Tools/

Much of this article flew in the face of what I understood as the issues regarding the TRIM command and garbage collection on SSD.

I understand the main issue as being that if files are deleted, the OS send the TRIM command to the SSD which can start the whole garbage collection mechanism. In the same way you can avoid files being actively deleted by pulling power to the drive, you can do the same with an SSD that has received the TRIM command but as soon as you power the SSD on again the garbage collection resumes, regardless of whether or not it is connected to a write blocker. You effectively get stuck in a situation where you believe the contents of the deleted files still remain on the SSD but the very process of plugging it in to image it, results in the contents of those files being purged. I assumed, when I opened this article that this would be the issue being dealt with. It is not.

The author seems to believe that the TRIM command will be sent/resent only when mounted. As far as i am aware simply mounting a filesystem on an SSD would not start the process of sending TRIM commands. In addition I was also under the impression that TRIM command,s could only be sent over certain connections. For example TRIM command can be sent via SATA connection but not by a USB connection.

As far as I am aware to resend TRIM commands you'd have to mount the filesystem (whilst enabling the 'discard' option) AND THEN also run a command like: fstrim
Is that right?
And, if you had mounted the filesystem over a USB connection, the TRIM command wouldn't even reach the SSD.
Is that right?

In addition, it is my understanding that any ongoing garbage collection would not be prevented by not mounting the filesystem.

I'm not really sure what he has proved or achieved in this paper if my assumptions/beliefs are correct.

Also, in this paper he states that certain cables prevent reliably hashing the same SSDs (Section 7.3.1). They all prove reliable when they are used to hash a partition but not when hashing a volume. How do you hash a volume? You can hash a patrtion easily enough, 'md5sum /dev/sda1' but how has he hashed the volume? ' md5sum /mnt/sda1'???? I suspect that is the real reason the results are not reliable, not because of any specific cables.

Can someone please explain this all to me?  
 
  

thefuf
Senior Member
 

Re: Issues with: Forensic Acquisition Of Solid State Drives

Post Posted: Mar 14, 18 23:12

I understand the main issue as being that if files are deleted, the OS send the TRIM command to the SSD which can start the whole garbage collection mechanism.


First of all, the term garbage collection can have two different meanings:
1. an act of changing the data in a discarded logical block when this block, which was previously reported by the operating system, is processed by the drive;
2. an act of walking through file system structures in order to locate and (later) discard unused logical blocks performed by the firmware of the drive.

In the same way you can avoid files being actively deleted by pulling power to the drive, you can do the same with an SSD that has received the TRIM command but as soon as you power the SSD on again the garbage collection resumes, regardless of whether or not it is connected to a write blocker. You effectively get stuck in a situation where you believe the contents of the deleted files still remain on the SSD but the very process of plugging it in to image it, results in the contents of those files being purged.


In general, yes. However, a forensic examiner can try to put a drive to the techno mode to prevent discarded blocks from being erased (Techno Mode – The Fastest Way To Access Digital Evidence On Damaged SSDs).

As far as i am aware simply mounting a filesystem on an SSD would not start the process of sending TRIM commands.


There are two ways to issue discard commands in Linux:
1. as soon as data is marked as unallocated ("Continuous TRIM");
2. in a batch ("Periodic TRIM").

So, yes, mounting a file system (by itself) doesn't result in discard commands being sent to the drive.

In addition I was also under the impression that TRIM command,s could only be sent over certain connections. For example TRIM command can be sent via SATA connection but not by a USB connection.


In theory, it could be possible to issue the SCSI UNMAP over a USB connection. But this will likely fail.

A random report:
It confirmed that "deletenotify" worked on my JMicron JMS567 SATA/USB bridge, which supports UASP and UNMAP->TRIM translation. Since LBPME bit on the bridge is set to 0, so apparently Windows does not check the bit before issue UNMAP commands. Not sure about the requirement on the two VPDs though.
(source)

As far as I am aware to resend TRIM commands you'd have to mount the filesystem (whilst enabling the 'discard' option) AND THEN also run a command like: fstrim
Is that right?


Yes (if we speak about resending the commands). However, the fstrim command may be executed from an anacron job. Some live forensic distributions had this anacron job enabled (thus, leaving a file system mounted for a long time may result in the free space being discarded).

And, if you had mounted the filesystem over a USB connection, the TRIM command wouldn't even reach the SSD.
Is that right?


In most cases, yes.

In addition, it is my understanding that any ongoing garbage collection would not be prevented by not mounting the filesystem.


Yes.

I'm not really sure what he has proved or achieved in this paper if my assumptions/beliefs are correct.


Well, the author isn't aware of many things. For example, the Tableau TD3 device is mounting file systems present on source drives, so, according to the author, this should result in data being changed on a source drive.  
 
  

jaclaz
Senior Member
 

Re: Issues with: Forensic Acquisition Of Solid State Drives

Post Posted: Mar 15, 18 10:27

There are a few things I am not sure/convinced about.

TRIM is an OS feature.
If the issue is that a trim command may be issued accidentally, wouldn't make it sense to use an old, non-trim enabled OS (like - say - a BartPE/PE1.0, or a Linux with kernel before 2.6.33) ?

But I believe it is possible even with later Linux to build a non-trim enabled kernel (or *whatever* sub-system trim belongs to).

Since once the data has been copied in an image it is "safe" form the effects of trim commands, this could be a very minimal OS, only needed in the acquisition phase to perform a dd (or similar), much like the OFSClone by Passmark:
www.osforensics.com/to...mages.html

Besides, I could find no trace in the paper of the usage of a writeblocker (in the sense of make/model).

As AmNe5iA noted this:

It is important to note that despite the change in the hash values generated from the disk’s volume, the hash value generated from the disk’s partition will always match regardless of the adapter used.

needs some clarifications, I cannot understand what the Author meant, and - AFAICU - "standard practice" is to image the whole PhysicalDrive and never "partitions" or "volumes" so I wonder what is the relevance of this - if confirmed/replicable.

As well, using a forensic live CD and/or having automount disabled is already (again AFAIK) "standard practice", so I am failing to see in what the "proposed method" represents an innovation. Confused

The point #3 maybe?

Decide on what adapter and/or cable to use and take note of brand and model. The same and only adapter should be used to verify and image an SSD.

But the recommendation in itself doesn't seem adequate to solve the (reported but as said non entirely clear) issue about the adapter/converter (not cable) altering the hash.
I mean, say (hypotherically) that you have Adapter #1 and Adapter#2.
You either verify that Adapter #1 always makes a correct hash and that Adapter #2 always alters it.
Then the remedy is "only use Adapter #1 and throw the Adapter #2 in the garbage".

What am I missing? Question

jaclaz

P.S.: And we are again on the apodictic:
† Forensic Live CDs have write-protection rules [13] to prevent changes from occurring to connected devices, but a hardware write-blocker must be used when performing data acquisition.

_________________
- In theory there is no difference between theory and practice, but in practice there is. - 


Last edited by jaclaz on Mar 15, 18 11:22; edited 1 time in total
 
  

thefuf
Senior Member
 

Re: Issues with: Forensic Acquisition Of Solid State Drives

Post Posted: Mar 15, 18 10:56

Besides, I could find no trace in the paper of the usage of a writeblocker (in the sense of make/model).


Table 4. Also, a previous version of this table included the "Tableau TD3 forensic imager" (it's gone now, but there is a cached page in Google).  
 
  

jaclaz
Senior Member
 

Re: Issues with: Forensic Acquisition Of Solid State Drives

Post Posted: Mar 15, 18 11:05

- thefuf
Besides, I could find no trace in the paper of the usage of a writeblocker (in the sense of make/model).


Table 4. Also, a previous version of this table included the "Tableau TD3 forensic imager" (it's gone now, but there is a cached page in Google).


Ahh, thanks, I found it now, it is a .png:


T35es

The image in the cache is still available:

TD3
T35es

Question

jaclaz
_________________
- In theory there is no difference between theory and practice, but in practice there is. - 
 
  

Jefferreira
Member
 

Re: Issues with: Forensic Acquisition Of Solid State Drives

Post Posted: Mar 15, 18 13:30

As the author of the article I am glad that this is happening.

The only thing I can say and will say is that you should do the experiments, prove me wrong. I am okay with it. Smile

If you have a spare pc or laptop, plug an SSD inside, boot a live cd such as Ubuntu from a usb, format the ssd, create a partition, populate the partition with data, delete some data, unmounted the ssd, Hash it, take note of the hash, turn computer, plug a forensic live cd, turn pc/laptop on, boot from live cd, wait has long as much as you like and then hash the ssd and check if the hashes match.????

I could sit here all day debating garbage collection and trim, but enough papers and articles have been written on those issues over the last decade and the only thing I want to add is that Bell and Boddington wrote in their paper that we should give up trying to find a solution to the problem and that is not very optimistic, is it? ????

The TD3 should not have been in the post and that is why I asked scar to remove it. The TD3 was a failed experiment.

The article was written because the results from the experiments showed that it's indeed possible to image SSDs without losing any traces of potential digital evidence, otherwise I would not have spent months confirming the results, repeating the same experiments and taken the time to write the paper... The article is a paper.

PS: the issue with the adapters is not an SSD problem, it aldo happens with HDDs. I thought about sharing it with everyone so that the paper wouldn't be just about the auto mount.

Thank you  

Last edited by Jefferreira on Mar 15, 18 13:52; edited 1 time in total
 
  

AmNe5iA
Senior Member
 

Re: Issues with: Forensic Acquisition Of Solid State Drives

Post Posted: Mar 15, 18 13:51

Yes but all you have really proved is that storing an SSD in a cupboard for 30 days has no effect on the data.  
 

Page 1 of 8
Page 1, 2, 3, 4, 5, 6, 7, 8  Next