I've dumped the same (pre-programmed) NAND 4GB chip from different embedded devices (after removing them with a hot air gun) several times to obtain the firmware and filesystem. I looked up the chip specs (Toshiba/Kioxia TC58NVG2S0H BAI6), grabbed strings from the raw dump to discover how the chip is being used/drivers/mounted/MTD subsystem params/kernel params, etc after dumping the raw NAND. Binwalk discovers a number of signatures, but the files end up mostly corrupted.

The socket and programmer seem to work just fine. I also built a programmer from an FTDI2232 breakout board to try another method of reading them

Every time I dump the chip, it says there are 496 bad blocks. I used a hot air gun to remove it, removed it as fast as possible (45-60 seconds), evened out the solder so it would sit flush in the socket, all pins are detected, Binwalk is able to identify signatures from the raw dump, but the data is corrupt as all get out....and I cannot figure out why. I've tried DD slicing it in a ton of different ways to recover the bootloader/kernel/file system, but it is always corrupt. I checked to see if an overlay FS was used, and it is disabled in the kernel startup params. I've stared at hexdumps for hours, trying to see if there's something I'm missing.

I know a BCH ECC method is being used (correcting 48 bits per sector (2048 bytes), with 4096 page size and 256 OOB). I have tried just chopping off the OOB area and the data is mangled.

I cannot figure out if there is heat damage, some other ECC algo getting layered over it, or if I'm missing something entirely?

I have been unsuccessful in reversing the ECC algo, even though I located the driver source, as most of the logic is being performed on a hardware-based controller.

Any advice would be GREATLY appreciated, as I've been spinning my mental gears on this for several weeks now (and several hundred dollars worth of additional equipment).

Hello,

there are multiple ways content of flash chips are shuffled usually. First, there are 2 banks usually which are merged in a RAID0 like manner, and the blocks are usually shuffled due to wear leveling. You need to take care of these at least. These, especially the 2nd one depends on the NAND controller, as well as the ECC params.
What kind of embedded devices do these come from?

pepe

_________________
Adatmentés - Data recovery

These come from Google Nest Minis, 2nd gen. I am reversing the firmware to find bugs for their bug bounty program.

The controller is a Cadence NAND controller. Have looked up the specs, source, etc. I can't determine what kind of wear leveling is being used, but per the logs/their code, BCH is the ECC algo used.

It's a 4GB chip being used as a 512MB chip....so perhaps their is 4x redundancy/wear leveling capacity?



How would I go about determing this/reconstructing the data segments? It looks like the partitions on the raw NAND are likely contiguous, per their MTD partition table.

would it not be better/easier to download a firmware update and reverse that? That's how I do it.
I will PM you

can you show a photo of the cadence controller or is it part of a MCP or built into Main CPU chip? or even just the chip numbers if it is a separate chip

BTW looks like Nest is online update, so maybe you can sniff the firmware update with wireshark (follow tcp stream type thing)

I did not think of reversing the OTA firmware bits itself....that's pretty brilliant. They have cert-pinning enabled on the device, so I can't just MitM the traffic out of the box. I'd have to get a root CA cert on the device to be able to read the traffic. Also, I still want to get into the (proprietary) bootloader, kernel and file system itself to see what kind of goodies they are hiding on there . Also, I want to reverse some hardware and learn about Android and embedded devices in general.

The Cadence controller is built into the SoC, AFAIK.

Machine model: Synaptics AS370 Valens. Perused their site and couldn't locate the the actual controller logic. Schematics, yes....but no bit-level info.