Hi there

I've been looking at an off chip read of a Winbond W25N01GV SPI NAND 128Mb chip for a few days. (yes my life is that exciting).

It's from an IP Camera, and I'm looking to extract an lzma file from the first partition around 0x9300 of the dump. This contains the proper bootloader I need to further research.

I've removed the OOB (the layout of which is weird below), but when trying to decompress the lzma file it is clearly corrupted, and fails after producing only a little valid data.

Comparison with a dump from the same camera with the same bootloader version shows 420 bit errors between them for the data area I am interested in.

I do not have access to either device - just the dumps.

I did write a program to navigate these 420 bits errors that allowed me to interactively try both options for each of the 420 bits the 2 dumps disagreed on, previewing the decompression results, and backtracking to earlier choices as needed. That's allowed me to get about 200 bits in with valid results but now I'm struggling to make further progress.

I did look at using the ECC data in the dump to correct the bits, but short of spending $1000s for VNR there don't seem to be many tools that understand either the OOB layout or the ECC scheme used.

Page: 2048 + 64 OOB

OOB layout:

0x00 - 0x40F user data
0x410 - 0x40D 14 bytes (assumed ECC1)
0x40E - 0x7FF user data
0x800 - 0x801 Bad block marker (0xFF 0xFF)
0x802 - 0x80F user data
0x810 - 0x81D 14 bytes (assumed ECC2)
0x81E - 0x83F 0xFFs (except 0x83A there are always 2 0x00s)

So 0x800 user data in all and 0x40 OOB

On a blank page
ECC1 is always 0A 3A E9 39 43 DE 09 AC 83 22 D0 E1 7F F3
ECC2 is always A5 BB 1D F0 B8 A2 03 70 69 78 36 69 84 B1

So I'm thinking BCH-8 with a sector size of 1024 each having it's own 14 byte ECC code. 2 sectors in each 2048 + 64 page.

Despite this, the bootlog shows:

From bootlog of the kernel:
[ 1.602149] SPI Nand(cs 0) ID: 0xef 0xaa 0x21
[ 1.606622] nand: device found, Manufacturer ID: 0xef, Chip ID: 0xaa
[ 1.612980] nand: Winbond W25N01GV
[ 1.616460] nand: 128MiB, SLC, page size: 2048
[ 1.620901] Nand(Auto): OOB:64B ECC:4bit/512

The last line of this seems to disagree with my guess above, but it that because I'm looking at a physical off chip dump rather than the logical OOB view the OS gets? Data sheets on manufacturer web just talk about the logical layout view not what a chip reader sees.

Can anyone recommend a sensible way forward? Especially tools where I just press a button and magic happens lol :p

I know going too deep into BCH will get very mathematically complex likely beyond my ability for what is just a fun project for me. I can try different schemes, rearrange the OOB areas of the dump in to 1 64 byte area, try different polys for example, but if I need to work at a university and smoke a pipe with a whiteboard in the background I might give up

Any help appreciated.

Despite this being a fetish of you imagination, you could try reading:

https://www.blackhat.com/docs/us-14/mat ... fit-WP.pdf
https://www.blackhat.com/docs/us-14/mat ... enefit.pdf
http://recon.cx/2014/slides/Reverse%20E ... enefit.pdf

This is a begining, where you can make and adapter for you case, and then you just have to mod the OOB page in the python software.

I've been there, i've done that, it will make you wish to bang your head against a wall many times, but good luck.

p.s: Look at me being retarded trying to read nand with that homemade programmer 5 years ago: https://forum.hddguru.com/viewtopic.php?t=31253

_________________
BTC Wallet - 3AoQPTBsz9PbfoanCx44Lw76Y2TwtKa1x5
Instagram https://www.instagram.com/datarecovery_morde.pt/

Thanks for the reply and the links

I do know the position and length of the 2nd stage u-boot by looking at the 1st stage in IDA, and don't care about the filesystems later on in the dump so that simplifies thing a bit at least.

I have found nand-dump-tools which implements a BCH decoder which I'm looking at with interest even though it will need some changes to the nand structures it knows about (or simply programmatically change of the dump I feed it which is somewhat easier now I've written a program to do that already).

I do know there are proprietary tools that already seem to have understanding of the underlying OOB/ECC scheme of this chip, and thought I'd check here in case I'm missing more effective ways of proceeding, or someone with experience of this specific chip which seems to be used with increasing frequency.

Thanks again.

Have you looked at FlashcatUSB? I am not sure if it needs to do the ECC when dumping, or you can just open the dump in the software.
https://www.embeddedcomputers.net/products/FlashcatUSB_Mach1/

I have no real experience in this area, but my reading of the datasheet suggests that the chip defaults to using its own, internal, transparent ECC algorithm, with a standard spare area. Your application, however, appears to override this default configuration and instead implements its own "soft" algorithm. If I've understood this correctly, then I can't imagine that any tool would understand this strange, proprietary (application specific?) structure.

_________________
A backup a day keeps DR away.

Funnily enough I posted on their forum yesterday - I wondered the same thing.

But, in the last few hours I think I may have it. I think I've figured out enough to write a program that will use the ECC to correct the dump. But it's late here and time for bed

Hi,

I'm struggling with the same ecc on micron nand chip. Our ECC are the same for the blank pages. Can you share the ecc algo?

depending on your situation, $250 Commercial Licence appears to enable integrateded ECC for the Flashcat software
https://www.embeddedcomputers.net/software/