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
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?
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.
(
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.
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
https://
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. ?
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? ?
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.
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).
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
?
jaclaz
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. )
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
Yes but all you have really proved is that storing an SSD in a cupboard for 30 days has no effect on the data.
Yes but all you have really proved is that storing an SSD in a cupboard for 30 days has no effect on the data.
Isn't that what ww are trying to do? Treat SSDs in a similar way we do with HDDs? Trying to preserve its integrity? The method is not full proof as stated in the conclusion, but it offers a solution to the problem the volatile data stays static and you can recover it.
Unless I am missing something here, the purpose is to preserve integrity to ensure that we can recover as much potential digital evidence aa possible, right?
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.????
If an SSD implements the deterministic read after Trim feature, then the hash will likely be the same. An SSD with the non-deterministic Trim or with the filesystem-aware firmware is a different issue.
The only thing I can say is that I am just sharing the findings of my experiments, the results show that it works.
You have a list of the equipment I used in one of the tables.
I tried mounted v unmounted and the truth is that it worked when unmounted. The SSDs were hashed then imaged 3 times with each one of the adapters, we are talking about hours, (thanks to the write-blocker with a usb 2.0 connector.) waiting to confirm the results. Repeated repeatedly and the results were consistent.
This post, these comments and observations were expected and obvious and, besides asking that you try the method, there is nothing else I can do. Is it possible that I may be missing something? Possibly. Is it possible that it does not work with all SSDs? Possibly, but I tried to get different types of SSDs and with the SSDs that I used, it worked.