Which NAND flash reader ?

[arvika]

Not bad. 75% map is green

[nlc]

Ok !

I try to read this block multiple time to see if some bits are changing

[Gregory]

I have some bad bits in the dump :
But I think the dump quality is good, because the white column is 12 bits wide, and on a dump sample of 8192 pages, thus 98304 bits, I counted only 89 bad bits (0.00091%)
If I'm not mistaken, the 70 bytes ECC for 1024 data byte (total 8752 bits) can correct up to 40 bit errors, thus up to 40/8752 = 0.004%

But what if, let's say you have 1 bit error every 12 bits in page, then in theory you can have (1094*8)/12= 682 error bits per chunk (data+ecc).
ps. you not mistaken about how many bits you can correct, is 40.

[nlc]

But what if, let's say you have 1 bit error every 12 bits in page, then in theory you can have (1094*8)/12= 682 error bits per chunk (data+ecc).

Of course, but in this case statistically I should see more page with bad pixel in the 12 bits blank I think

Today I need to work on ecc to be able to check by myself the pages dump quality

[nlc]

ECC CALCULATION MAKES ME CRAZY !!!

[nlc]

This fuc***g chip is really complex !!
Will try to understand ECC later, today I tried to find how data are arranged in the nand, because from above screen capture it's clear the spare area is completely scrambled, pages are interleaved or something like that.

We know that generally all the Spare Area of a block have same values.
What I have done is to randomly take a 32 bytes spare area, and wrote a small utility to scan all the pages of the nand, and display all pages number which have at least 245 bits in common (to remove maching problem due to flipped bit). It worked very well, was able to understand how the data are arranged :

Code:

0032.001 = 256 common bits
0048.001 = 255 common bits
0064.001 = 256 common bits
0096.001 = 256 common bits
0112.001 = 256 common bits
0128.001 = 255 common bits
0144.001 = 255 common bits
0160.001 = 256 common bits
0192.001 = 256 common bits
0208.001 = 256 common bits
0224.001 = 255 common bits
0240.001 = 256 common bits
0256.001 = 256 common bits
0272.001 = 255 common bits
0288.001 = 255 common bits
0304.001 = 256 common bits
0320.001 = 256 common bits
0336.001 = 256 common bits
0352.001 = 255 common bits
0368.001 = 255 common bits
0384.001 = 256 common bits
0400.001 = 253 common bits
0416.001 = 256 common bits
0432.001 = 256 common bits
0448.001 = 255 common bits
0464.001 = 256 common bits
0480.001 = 255 common bits
0496.001 = 254 common bits
0512.001 = 255 common bits
0576.001 = 256 common bits
0592.001 = 255 common bits
0608.001 = 255 common bits
0624.001 = 255 common bits
0656.001 = 256 common bits
0704.001 = 256 common bits
0720.001 = 256 common bits
0736.001 = 254 common bits
0752.001 = 256 common bits
0768.001 = 255 common bits
0784.001 = 254 common bits
0816.001 = 256 common bits
0832.001 = 252 common bits
0848.001 = 256 common bits
0864.001 = 255 common bits
0880.001 = 255 common bits
0896.001 = 256 common bits
0912.001 = 254 common bits
0928.001 = 256 common bits
0960.001 = 254 common bits
0976.001 = 255 common bits
0992.001 = 255 common bits
1008.001 = 256 common bits
1024.001 = 255 common bits
1040.001 = 255 common bits
1056.001 = 256 common bits
1072.001 = 254 common bits
1088.001 = 255 common bits
1104.001 = 256 common bits
1120.001 = 256 common bits
1136.001 = 256 common bits
1152.001 = 255 common bits
1168.001 = 255 common bits
1184.001 = 254 common bits
1200.001 = 254 common bits
1216.001 = 256 common bits
1232.001 = 255 common bits
1248.001 = 256 common bits
1264.001 = 255 common bits
1280.001 = 255 common bits
1296.001 = 256 common bits
1328.001 = 256 common bits
1344.001 = 256 common bits
1360.001 = 256 common bits
1376.001 = 255 common bits
1392.001 = 256 common bits
1424.001 = 255 common bits
1440.001 = 256 common bits
1456.001 = 256 common bits
1472.001 = 256 common bits
1488.001 = 255 common bits
1504.001 = 256 common bits
1520.001 = 256 common bits
1536.001 = 256 common bits
1552.001 = 256 common bits
1568.001 = 255 common bits
1584.001 = 256 common bits
1600.001 = 256 common bits
1616.001 = 255 common bits
1632.001 = 256 common bits
1648.001 = 255 common bits
1664.001 = 256 common bits
1680.001 = 254 common bits
1696.001 = 256 common bits
1728.001 = 255 common bits
1744.001 = 254 common bits
1760.001 = 256 common bits
1776.001 = 255 common bits
1792.001 = 254 common bits
1808.001 = 255 common bits
1824.001 = 255 common bits
1840.001 = 255 common bits
1888.001 = 256 common bits
1904.001 = 255 common bits
1920.001 = 254 common bits
1936.001 = 256 common bits
1952.001 = 253 common bits
1968.001 = 256 common bits
1984.001 = 256 common bits
2000.001 = 256 common bits
2016.001 = 255 common bits
2048.001 = 256 common bits
2064.001 = 255 common bits
2080.001 = 256 common bits
535552 pages read analysed, 113 Spare Area are matching the pattern model !


XXXX.YYY is block_number.page_number

We can see all page containing the same spare area (and probably must be assembled together), are on the same page number, but every 16 block !

And my SA test pattern doesn't match at all on the dump of the second chip, it means data are not interleaved between nand chip I think.

Ok, now I write a small utility program to rearrange data, and see the result in Gimp

[Arch Stanton]

Ever come across this, very similar adventure: https://joshuawise.com/projects/ndfreco ... extraction

[nlc]

Yes thank you, already found this excellent article

[Gregory]

Screenshot_20200531-011656__01__01.jpg

I tested this emmc chip via NAND protocol on VNR and FE with and without VCC, VCCQ, VDDI capacitors, no visible differences in reading quality. You have big luck, you chip is in very good contition.

[nlc]

Received yesterday a working H26M42003GMRA. I filled it with 0x00 and can extract the Xor key now.

Will also be more easy to understand ECC

[nlc]

First file successfully recovered

[HaQue]

nice work! Was it from the other partition you couldn't access before?

[nlc]

Yes, the first file I recovered was in the logical partition which was all 0x00.
I also found other files, but they contain errors, I need to implement ECC, I spent hours an hours and I haven't found how the ECC is calculated for now

[nlc]

FINISHED ! I successfully recovered all files I was looking for

I spent a lot of hours and nights was short but it was a great experience, I learned a lot of things

[HaQue]

Great to hear. Very inspiring watching this unfold. Goes to show what hard work and learning can achieve.

[Arch Stanton]

Ow wow, that's awesome!

[nlc]

The adventure continues !!
The eMMC of my car died too

And the luck is not on my side this time, because the data quality on the 2 die are really really bad.
From the 2 dies dump I found 2 occurrences of one file I am looking for, and 5 occurrences of the second file I am looking for.

But data are so damaged that I am unable to reconstruct the 2 files

So I looked on Read Retry and implemented it in my home made nand reader, based on a customized nand_hynix.c from Linux kernel as base code.
I know my read retry implementation works well because :
- I can get the Read Retry OTP data. From the eight time repeated 64 byte + 64 inverted byte Read Retry data, I can successfully get the eight data byte configuration for the eight Retry Mode.
- I found a page filled with 0xFF with some bit flip errors (26 bits error) when reading without Read Retry, and by changing read retry mode I can lower the bit errors to 8 (%70 less errors)

BUT !

On the pages where my important files data are, changing read retry mode doesn't improve anything !!

Any idea why ? For people who do data recovery, how this behavior can happen?
Should I try to use another values in the eight read retry registers ?

I also found some filled 0xFF pages with a lot of bit flip, and also no RR mode from the eight available improved anything :/

[harry_harry]

oh wow i saw this thred and had to give a comment.

and the second reason reason is to gives a hats off )thumbs up) to NLC very good engineer. also help with the famous interface wont forget that.

[nlc]

Thank you

[XNoOp]

Hello,
@nlc, what is your adapter? USB, JTAF or SPI to BGA UFS or BGA EMMC? is there a clamp to fix the chip without soldering?
I guess there are some readily available drivers for the adapter? Otherwise you have to wrap UFS/eMMC controller commands/address/data into the higher protocol level packets, is that right?
I am have only developped a driver for ARM Static Memory Controller connected to 8-bit ONFI NAND... The philosophy shall be similar right?
Regards,
Florian