Reliability of an e...
 
Notifications
Clear all

Reliability of an external enclosure hardware write blocker  

  RSS
fraudit
(@fraudit)
Member

I have an urgent case to investigate that involves M.2 SSD M-key connector drive. I don't have the M.2->SATA adapter for M-key, so I could safely connect it to my blocker. I can obviously buy one but since this standard is less common than the B-key, delivery will take a few days which I cannot allow.

I can get directly an external enclosure (Icy Box brand) that's equipped with the write blocker. I've never used this type of blocking before and would like to know your opinions on its reliability. Do you find it safe to use?

Quote
Posted : 28/08/2019 4:08 pm
Rich2005
(@rich2005)
Senior Member

I've not tried it yet personally (as I've got hardware write-blockers) but Caine ( https://www.caine-live.net/ ) lists having drivers for the latest SSDs (NVME) so in theory you could image it using that without the need for additional hardware.

ReplyQuote
Posted : 28/08/2019 4:41 pm
minime2k9
(@minime2k9)
Active Member

I'd use a Linux distro and either connect it via USB or put it into a machine and boot the machine to the Linux distro.
Think we use an m2 adapter and then just connect it to a DEFT X machine.

ReplyQuote
Posted : 28/08/2019 8:46 pm
D1m4g3r
(@d1m4g3r)
Junior Member

Just as suggested in previous replies, I recommend getting a Linux Distro. Deft and Paladin are exceptional when it comes to handling SSD media. Give them a try and I wish you all the best.

ReplyQuote
Posted : 29/08/2019 7:08 am
fraudit
(@fraudit)
Member

Thank you all for your tips!

I eventualy went for CAINE (as I used it already before) and did the job.

ReplyQuote
Posted : 29/08/2019 3:47 pm
Suai
 Suai
(@suai)
New Member

Going back to the subject of write bloc using software solutions.

Is there any difference connecting a disk via SATA or M.2 for example, and booting directly into a live system with them already connected, from starting a live OS and then connecting the devices, either through the motherboard or via USB port adapters?

ReplyQuote
Posted : 11/02/2020 9:02 am
jaclaz
(@jaclaz)
Community Legend

Going back to the subject of write bloc using software solutions.

Is there any difference connecting a disk via SATA or M.2 for example, and booting directly into a live system with them already connected, from starting a live OS and then connecting the devices, either through the motherboard or via USB port adapters?

It ALL depends on the specific "live OS", no simple answer to that possible.
Some "live OS" may have some form of auto-mount (which is a no-no) only when booting, some may have that both when booting and at connection time, a "right" one won't have either.

jaclaz

ReplyQuote
Posted : 11/02/2020 11:54 am
Suai
 Suai
(@suai)
New Member

Thanks again jaclaz, always quick on the responses.

I was refering to most known live forensic OS (eg. DEFT, CAINE), as I understand they don't mount any drive by default or at least mount them RO. Just curious as to wheather it makes a difference if they are connected to the machine through SATA or external USB ports both when booting and at connection time.

ReplyQuote
Posted : 13/02/2020 11:18 am
jaclaz
(@jaclaz)
Community Legend

Thanks again jaclaz, always quick on the responses.

I was refering to most known live forensic OS (eg. DEFT, CAINE), as I understand they don't mount any drive by default or at least mount them RO. Just curious as to wheather it makes a difference if they are connected to the machine through SATA or external USB ports both when booting and at connection time.

I wouldn't be so sure about "most known" being "the same" (let alone being actually validated).

Connecting a drive to a computer before booting is not a good idea, you would be dealing with whatever firmware the computer has (BIOS or UEFI) way before the "most known live forensics distro" of choice comes into action, the firmware (because you set it "incorrectly" or "by itself") may decide to attempt booting from the evidence disk instead.

Personally I wouldn't even trust any of the "most known" distros and use either a very minimal (and built/validated by myself) PE booting with disks offline or the Passmark's OSFclone to ONLY make an image out of the evidence disk.

And even OSFclone has some possible quirks (in really edge and not at all common cases, still …).

Once you have a clone or an image, the worst that it can happen is that the tool you are using alters it, and you can always make a new clone or image, if this happens on the original evidence file you'll have a looong day finding out what happened and providing justifications for it or proving that the changes had no practical consequences (and it will probably also be a loong day in court).

I mean, should the tool accidentally (to remain in the cited OSFclone example) alter last mount time, last write time, mount count and a byte at location 0x0178 within the superblock of some ext2/3/4 volumes, the hash won't match anymore, but no real harm is done according to how I (and jhup) see the matter, see
https://www.forensicfocus.com/Forums/viewtopic/p=6573207/
but that doesn't mean that the counterpart in a trial won't use this hash mismatch to grill you on the stand and attempt to invalidate each and every one of your (BTW perfectly valid) findings.

jaclaz

ReplyQuote
Posted : 13/02/2020 7:28 pm
thefuf
(@thefuf)
Active Member

alter last mount time, last write time, mount count and a byte at location 0x0178 within the superblock of some ext2/3/4 volumes

Don't forget that the words quoted are true for a simplified case only. The vendor won't tell you that "any metadata block could be altered on a real-world system and if data journaling is enabled, data of any file can be replaced too, all of this just depends on data logged in the journal". So, the problem is that a journal is replayed, not just several bytes getting modified (this is only true for a simple case, as stated before).

ReplyQuote
Posted : 13/02/2020 8:40 pm
thefuf
(@thefuf)
Active Member

but that doesn't mean that the counterpart in a trial won't use this hash mismatch to grill you on the stand and attempt to invalidate each and every one of your (BTW perfectly valid) findings

I remember a similar discussion here, it happened five or six years ago. A person suggested a simple solution the use of a hardware write blocker. And now it was demonstrated that even a hardware-based solution can write through a write-blocked port on its own (issue a write command without a corresponding command from a host).

ReplyQuote
Posted : 13/02/2020 8:51 pm
jaclaz
(@jaclaz)
Community Legend

Don't forget that the words quoted are true for a simplified case only.

Yep, and I am still wondering how/why in the meantime you and the Author of the OSFClone didn't manage to come out (together) with an agreed upon/tested/validated solution to that issue.

ONLY to give some background to Suai about the specific matter
https://www.forensicfocus.com/Forums/viewtopic/t=12056/

https://www.forensicfocus.com/Forums/viewtopic/t=16195/

jaclaz

ReplyQuote
Posted : 14/02/2020 10:17 am
Share: