Switch to full style
In-depth technology research: finding new ways to recover data, accessing firmware, writing programs, reading bits off the platter, recovering data from dust.

Forum rules

Please do not post questions about data recovery cases here (use this forum instead). This forum is for topics on finding new ways to recover data. Accessing firmware, writing programs, reading bits off the platter, recovering data from dust...
Post a reply

Firmware security and using SSDs for (anti)forensics

November 6th, 2018, 7:34

I'm currently looking for ways to write protect SSDs. Maybe also other storage devices like HDDs or USB sticks, but I'd like to focus on SSDs mostly due to speed.
When you approach systems with some virus you usually don't want to spread it to your SSD or whatever you use to save data. On the other hand it would be also nice to write protect SSDs and then use them for browsing or online banking without needing to fear some drive by download or ransomware encrypting your files.
What I could gather up to now is that there are more or less two approaches.
One is to use the WP pin on the NAND flash directly and connect it to GND. However, this requires some tedious soldering or is impossible in case of BGA. Also in case of multiple flash chips you need to do the soldering on all chips. I think some SATA DOMs or USB drives with write protect switch make use of this but I am not entirely sure. Also they are either only rarely commercialy available or rather expensive.
The other method is to use write blockers based on USB SATA adapters. I guess these block all the commands used for writing and have a whitelist of allowed commands. I think also the commercial forensic write blockers work this way. These adapters usually have an external eeprom which is used to store the whitelist or boots into a different minimal OS depending on the position of the switch.

One thing missing is how to secure the firmware of the SSD drives or these adapters. Most SSDs seem to store their firmware on parts of the nand flash, so the WP pin should be sufficient to also protect this part.
The eeprom in the USB SATA adapters is usually some SOIC8 chip which you also could write protect.
However, for practical use I'd like to omit these adapters since I don't want some USB cable/adapter/SSD assembly dangling on the site of my notebook.

I also came across a possible third method using the TCG Opal features which maybe could ease my pain.
While mostly used for encryption there also seems to be an option to prevent writing to the device. The question is how this works internally (like method 1 or 2 ?) and if enabling it would also protect the firmware itself.
There is the sedutil utility available but I could not find anything related to write protection.

So my questions would be:
Is anyone aware of ways to protect SSDs against writing without some intermediate adapter? Either some specific models with a WP switch / pins to solder a jumper or via TCG Opal.
Are there maybe some models for USB-SATA adapters available where you can upload a modified firmware with a custom whitelist?
Which SSD models use an external EEPROM to store their firmware?

Re: Firmware security and using SSDs for (anti)forensics

November 6th, 2018, 15:39

IIUC, there are firmware modules which are transparently updated by the SSD on a regular basis. For example, the Power-On Hours SMART attribute is just one of these. Therefore, ISTM that one would need to block writing at the host interface, not at NAND level.

Re: Firmware security and using SSDs for (anti)forensics

November 6th, 2018, 17:15

What would be the implications when blocking this or other commands? Any risk of increased failure? Why should it be blocked at the host(=controller?) interface? Wouldn't blocking at the NAND level lead to a complete blocking? Afaik this is also one of the reasons why SSDs are somewhat harder to approach from a forensic side since they always do some stuff internally on the NAND as soon as you power them on. Wouldn't matter too much for applications, though.

Re: Firmware security and using SSDs for (anti)forensics

November 6th, 2018, 17:21

SSD do background wear leveling, so writing to NANDs is a crucial part of SSD's internal work. I very much doubt firmware would even boot up if you WP all the NANDs

Re: Firmware security and using SSDs for (anti)forensics

November 6th, 2018, 17:31

It's an exceptional case, but Samsung's 840 Evo is affected by a serious hardware flaw which results in data loss (due to charge decay) over a relatively short period of time. Samsung's "fix" was a firmware update which regularly refreshed (rewrote) each cell.

As for your question, I don't know what the firmware would do if it were not able to update SMART. Perhaps the firmware would deem any unwritable sector to be faulty? After all, it would not be aware that you have enabled Write Protect. If it then continued to search for a good spare sector to replace the "faulty" one, eventually it would find that all the spares are unwritable.

Re: Firmware security and using SSDs for (anti)forensics

November 7th, 2018, 8:22

The Samsung EVO 840 have tied the WP (Write Protect) pins of the NAND flashes directly to ground on the PCB, so you would need a different PCB to make use of the WP feature.
Another thing you could try to use is the ERASE function, which needs the VPP voltage line, which provides a much higher voltage that is dedicated to erasing the flash. Since erasing is necessary before writing, if you don't supply the voltage for erasing, it also can't write. Theoretically. The VPP should be reachable somewhere on the PCB surface or on one of the smaller parts that are surfaces mounted on the SSD surface, where you might be able to easily break a pin or trace and thereby remove the VPP supply from the SSD.
Whether SSDs are still bootable without erase or with write-protect being used is a good question, I guess someone would need to try that.
The Alcor based NAND Flash adapters I bought some time ago do not supply the VPP at all, so erasing is not possible with them. That might be a start for experimenting.
If you are looking for write-once media, I heard that EMC is offering solutions for that commercially called Centera. How secure that is in practice would need to be audited.
Write-Blockers as adapaters that you plug in between are most likely the best solution available.

Re: Firmware security and using SSDs for (anti)forensics

November 7th, 2018, 14:29

I don't need to erase the drives. I just should not be possible to write data but I still want to read it.
I did some more research and found some SSDs with more pins. Some are advertised as having write protection and hardware purge features. Though it looks like in some cases also a custom firmware would be necessary.
Hardware purge: https://us.transcend-info.com/Embedded/Essay-19
These Transcend SSDs have JTAG, Serial and 3 other pins which are probably used with a jumper to either write protect or erase the device. Anyone came across those or knows more about these pins?
https://ozon-st.cdn.ngenix.net/multimed ... 299165.jpg
https://www.transcend-info.com/Files/ED ... N_1710.pdf

I also came across these similar SSDs from different manufacturers:
https://ae01.alicdn.com/kf/HTB1sIuNArSY ... esktop.jpg
http://www.zheinossd.com/photo/ps193925 ... active.jpg

They don't seem to have a serial connection but JTAG and three jumpers. One being labeled ROM but no information about the other ones.

These ones have a ROM jumper and one labeled QE.
http://www.zheinossd.com/photo/ps183760 ... _flash.jpg

These are mostly msata SSDs, I could also find some real SSDs with enclosure which have additional pins for different erase functions (some including firmware) and write protection. But I guess they are going to be pricey.
https://www.apro-tw.com/Databank/2017%2 ... MSTCMB.pdf

Re: Firmware security and using SSDs for (anti)forensics

November 7th, 2018, 15:23

For the 840 Evo, Vpp is "Vboost" in the attached image. If you wish to disable it, then make a vertical cut through the PCB trace to the right of the diode.

Re: Firmware security and using SSDs for (anti)forensics

November 7th, 2018, 16:34

Is the flash controller really "physically destroyed"?

Re: Firmware security and using SSDs for (anti)forensics

November 7th, 2018, 19:40

fzabkar wrote:Is the flash controller really "physically destroyed"?

probably it burns a fuse inside ASIC

Re: Firmware security and using SSDs for (anti)forensics

November 8th, 2018, 2:31

With NAND Flash you actually have to erase a whole block before you can write anything to the pages of the block. You can't actually write without erasing it before. With some NAND Flash chips you even have to write the pages in the block in a specific order. The SSD controller handles all this complexity for you, so you normally dont notice this, and you just have to send read and write requests.

Re: Firmware security and using SSDs for (anti)forensics

November 8th, 2018, 4:50

A live CD of Linux with all the tools/files (pre installed) you need and a few GB of memory could save you all the hassle of worrying about WP storage devices and Virus infestation.

As Doomer said, better to hack the Interface. Most WP dongles filter out write commands with a flick of a switch.

Post a reply