Flash Drive Research project

[fzabkar]

Wondering if there could be a way of masking the main on board controller (presumably one that has failed) with one that is connected to it from a outer socket. ... Specifically, targeting SSDs, since many times there is no feasible solution due to encryption and much desoldering work.

Yes, that sounds like an easier approach for SSDs. Depending on the nature of the failure, you may be able to disable the controller via its reset pin. This usually places all the I/O pins in a high impedance state. Alternatively, you could remove or short (?) the crystal oscillator, unless of course it is embedded within the controller.

[HaQue]

I don't know if I would want to do that, it is possible the controller could write to the NANDs without user interaction. If the donor controller decided it needed to "fix" anything apon boot, there could be data loss. Also when each flash device is initialised, from what Ive seen, the controller and NANDs marry to each other pretty closely.
It can be quite difficult to know if a controller contains the same firmware, and if it does, same settings for the NANDs.

That said, this exact principle has worked on some sandisk flash drives(ive seen anecdotal evidence), the ones that are encrypted.

It is almost like flash drive and SSDdrive vendors are oblivious to the fact that DR is performed on the drives, or purposely designed to make it hard. Is encryption really necessary between a controller chip and a set of NANDs?

There is a massive research hole in this area.

[fzabkar]

The controller can't do anything if it is being held in the reset state. When its I/O pins are in high-Z mode, they are effectively disconnected from the circuit. It would be just like having two devices on the same bus, with one device disabled. That's how buses are designed.

[hhddrec]

A Lesson on Over-Engineering

Hi HaQue!
Very interesting project.

[HaQue]

Thanks
I have been able to take a data image, data dump, pattern dump and sector dump on 7 drives so far, and ready to solder some connectors on 8 more, so this is definitely helping me get through the mountain of data I want to take on each drive. It has saved me 14 solders and un solders of NAND Chips! so pretty significant boost for such a simple idea.
TBH, I was not looking forward to all the soldering, but now the process is simplified, I should have results a lot quicker.

[TerraNova]

Great work. Mate! Thats what i call creative thinking.

[Sasha Sheremetov]

Hi HaQue,

This is simply amazing what you're doing.
We're about to complete new chip-off Data Recovery and Digital Forensics tool manufacturing for NAND devices with open block management algorithms, scrambler analysis and extraction tool (XOR extraction), and many other nice and unique options. I think we can supply you tool on some conditions. If you're intrested, let's find a way for communication (my email in profile).

Besides the method HaQue described there's another one, for reverse engineering of controller algorithm on working devices(works in ~80% of cases).

0. Kill MBR otherwise Windows doesn't allow to write pattern
1. Write pattern 0x77 across entire LBA space of flash device (for XOR analysis and extraction)
2. Write pattern with 16-byte running number in every sector like "0000000000000001". (for Spare area analysis, Virtual block allocation)
3. Write some known text like "I'm a new page" to some sector at beginning and remember sector number, use sector 2048 to make it easy to remember (for Replacement/Log block analysis, obsolete block analysis [forensics], and block header analysis).

[Sasha Sheremetov]

My mistake in secont item:

2. Write pattern with 16-byte running number in every sector like "0000000000000001" on HALF of capacity, to leave space with XOR (for Spare area analysis, Virtual block allocation)