Issues with: Forens...
 
Notifications
Clear all

Issues with: Forensic Acquisition Of Solid State Drives

52 Posts
6 Users
0 Reactions
4,922 Views
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

…but a write-blocker should always be used when performing forensic Acquisition of any drive.

Why? 😯
If the tool/distro is read-only, it is read-only.
If it writes, it is not read-only. roll

Now, that a given LiveCD/imaging distro/tool needs to be validated to be read-only, that is another thing.

Using a write blocker is ONLY a way to delegate to the write-blocker manufacturers the responsibility if the source is written (and to make them a tad bit richer).

Other reasons (convenience, compelling procedures, whatever) can be cited as to the "reason why" but the "should" is only an apodictical statement.

Only for the record some previous discussion on the matter
https://www.forensicfocus.com/Forums/viewtopic/t=8679/postdays=0/postorder=asc/start=42/

jaclaz

 
Posted : 28/03/2018 3:04 pm
(@thefuf)
Posts: 262
Reputable Member
 

I used Deft zero 2017.1 mostly and Caine and parrotsecand these have the automount disabled and write protection enabled by default. These were all good to image SSDs.

If you don't see a file system mounted after the boot, it doesn't mean that this file system wasn't mounted and unmounted during the boot. Many live forensic distributions can (and sometimes will) mount and unmount file systems on fixed media during the boot. And again, mounting a file system doesn't have a direct connection with the Trim command and garbage collection.

Parrot 3.11 in the forensic mode

 
Posted : 28/03/2018 3:09 pm
(@thefuf)
Posts: 262
Reputable Member
 

but a write-blocker should always be used when performing forensic Acquisition of any drive.

A write blocker can write to an evidence drive (even without a command from the host). Also, a write blocker can block access to some sectors.

 
Posted : 28/03/2018 3:14 pm
(@jefferreira)
Posts: 19
Active Member
 

Thefuf,

Thank you again for your input.

We are back at the beginning of this post.

You are right, and I am not going to disagree with you ) , but the truth is that unmounted SSDs can be imaged repeatedly without any changes.

 
Posted : 28/03/2018 3:16 pm
(@thefuf)
Posts: 262
Reputable Member
 

You are right, and I am not going to disagree with you ) , but the truth is that unmounted SSDs can be imaged repeatedly without any changes.

As expected. Please, read my previous posts in this thread about deterministic read after Trim and filesystem-aware garbage collection.

 
Posted : 28/03/2018 3:21 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

A write blocker can write to an evidence drive (even without a command from the host). Also, a write blocker can block access to some sectors.

Yep, and BTW this last possibility (blocking access to some sectors) might be - at least partially - the cause of the hash mismatches occurring and reported, in the absence of a proper investigation on the causes, as per your previous post

https://www.forensicfocus.com/Forums/viewtopic/p=6593191/#6593191

jaclaz

 
Posted : 28/03/2018 3:26 pm
(@aquachimere)
Posts: 32
Eminent Member
 

A write blocker can write to an evidence drive (even without a command from the host). Also, a write blocker can block access to some sectors.

Thefuf,

could you explain that?

if you calculate the hash of a hard drive before making the image of it and then you calculate the hash of the binaries from the image made, there is no difference. i did the test with td3

what sectors are you talking about?

 
Posted : 29/03/2018 6:36 am
(@thefuf)
Posts: 262
Reputable Member
 

A write blocker can write to an evidence drive (even without a command from the host). Also, a write blocker can block access to some sectors.

Thefuf,

could you explain that?

if you calculate the hash of a hard drive before making the image of it and then you calculate the hash of the binaries from the image made, there is no difference. i did the test with td3

what sectors are you talking about?

https://github.com/msuhanov/Linux-write-blocker/blob/master/research/2017-01_Write_blockers.pdf (pages 5-6).

 
Posted : 29/03/2018 10:35 am
(@aquachimere)
Posts: 32
Eminent Member
 

Thanks thefuf!!

it means that it is possible to corrupt data on the evidence, but that when it happens it is random?

it is better to use only the tools of live boot or software behind write blocker and avoid tools TD3 type?

 
Posted : 29/03/2018 3:21 pm
jaclaz
(@jaclaz)
Posts: 5133
Illustrious Member
 

If I may

it means that it is possible to corrupt data on the evidence, but that when it happens it is random?

it means that there are a number of "edge" but still possible in practice (and actually happened) cases where the "normal" provisions (be it in either software or in hardware - which BTW actually is as well software, as the modern hardware writeblockers have a firmware that is what may contain bugs) are not adequate to fully preserve the original evidence.

You have to take also into account that some of these issues - since they happen at the sheer moment that either the device is connected/powered up or that the (live/foerensic) OS boots won't even result in a hash mismatch, since they happen BEFORE the acquisition is performed and the hash is calculated.

it is better to use only the tools of live boot or software behind write blocker and avoid tools TD3 type?

It depends on the scope.
1) do you want someone to blame IF (the extremely rare cases) something goes wrong AND you have money to "waste" (but thus saving a lot of explanations)? Go for a hardware writeblocker
2) do you want to be (relatively) sure that nothing is changed, ever? Use either a surely non-writing OS (as hinted by thefuf, where applicable simpler, older OS can be more easily verified) or an OS that has been verified to never write (such as - if Linux - a forensic distro with the patch by thefuf) or use a WinFE or IMHO even better, use a WinFE with my personal[1] approach (mind you I don't do forensics, only some data recovery, and only as a hobby) of modifying the source in order to be sure it won't be modified 😯 .

It has somehow to be highlighted that most of the possible "bad behaviours" of "forensic" distros/OSes only happen when the system is booted with the evidence disk drive connected, so an additional little caution (that costs nothing BTW) is to use - whenever possible - a hot-pluggable interface such as SATA/eSATA or USB.

jaclaz
[1]Hinted here

http//reboot.pro/topic/19730-dmde-basic-disk-imaging-test-and-results/

http//reboot.pro/topic/18953-is-winfe-forensically-sound/

 
Posted : 29/03/2018 4:14 pm
Page 5 / 6
Share: