Hello,
I'm trying to read data from device that is using MNDSPEED PC3008 and S34ML02G1 NAND.
I read NAND using my TL866II reader, but I'm not able to figure ECC. algorithm.
I found that page size is 2048 bytes and 64bytes are used for ECC.
ECC is probably bch.
Does anybody have some information or documentation what exactly ECC is used in this controller? Like polynomial, sector size, sector size in ECC.
Is there any free tool that can determinate what ECC is used?

I uploaded NAND image here https://ufile.io/earrkl7z

Yes, page size is 2112. ECC is not BCH for 99%. Sector is 512/13_1. You meet also bad byte or it could be controller specific.
Such old chip even without ECC have quite good quality.

_________________
Flash Killer - everyday new resources (pinout, XOR, ECC,config) for flash devices

Hello ,
What do you mean by " Sector is 512/13_1 " ,Can You explain Please .

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

Thanks for response.
Unfortunately I'm not able to read data when I strip ECC.
It has squashfs file system, I can see squashfs header in data, but I'm not able to extract it because of errors.
Are you able to get corrected data from it?
Is there any other controller that is using the same ECC and has documentation for it?

Hi,
what is this device that you are having ,Some photos would be wonderful

_________________
Regards
Amarbir S Dhillon , Chandigarh Data Recovery Labs [India]
Logical,Semi Physical And Physical Data Recovery
Website-> http://www.chandigarhdatarecovery.com

AT&T Cisco Microcell DPH-154
ECC will be the same for all devices with MNDSPEED PC3008.

512 bytes of data followed by 13 bytes of ECC plus a 0x00 pad (?) byte, then repeat until end of page. The 4th sector is terminated with 6 bytes of 0xFF. There is something special about that last sector, but I haven't yet worked it out.

_________________
A backup a day keeps DR away.

I think I have worked out the layout of the 4th sector, but it seems very strange. I'll try to write a tool to strip out the data ... if anyone is interested.

_________________
A backup a day keeps DR away.

I used this tool https://github.com/Hitsxx/NandTool to strip ECC data, but data without ECC correction contains errors.
Do you found what ECC algorithm it is using?

Data is stored at blocks, but not at order, it is mixed - we can say digital puzzle.
This controller maybe use Reed-Solomon, Hamming, custom producent code or other ECC algorithm.

@fzabkar: there's no need to break open doors, just use VNR or other tool which can do it easly more or less.

_________________
Flash Killer - everyday new resources (pinout, XOR, ECC,config) for flash devices

Each page of 0x840 bytes contains data at the following ranges:

0x0 - 0x1ff
0x20e - 0x40d
0x41c - 0x61b
0x62a - 0x7ff
0x802 - 0x82b

_________________
A backup a day keeps DR away.

Yes, I'll just dig out my copy of VNR. LOL

_________________
A backup a day keeps DR away.

I used this tool to strip ECC github . com / Hitsxx / NandTool(I added spaces because I can't send post with link), but without correction I got a lot of errors in squshfs.
I think data in page is from 0x0 to 0x800 and ECC is from 0x800 to 0x840.
You can see it in my NAND image at 0x18C0 all data in this page is 0x00 and ECC is "FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF FF FF".

Definitely not. If you can't write your own tool (using my layout), I'll do it for you. Just let me know.

_________________
A backup a day keeps DR away.

I can, I will send it here when it is done.

BTW, I expect that the word at offset 0x800 is a bad block indicator. If the value is not 0xFFFF, I would ignore that particular block.

Actually, the file system may be aware of bad blocks, so you may want to write two versions of your tool, one including the bad blocks and the other without.

_________________
A backup a day keeps DR away.

Here is my program to strip ECC, unfortunately output still has errors.

Try discarding any bad blocks.

Could it be that the "ECC" bytes also contain LBNs? If so, then you would need to build a translator.

Perhaps you could extract the 14 bytes at the end of each sector and write them to a separate file? Then view this file in a hex editor set to display 14 bytes per line. In this way you could see any sequential pattern.

_________________
A backup a day keeps DR away.

I checked and there are no pages that have different value than 0xFFFF at 0x800.

Here is my reasoning:

Extract the two blocks in the range 0x152C40 - 0x153CBF and copy them to a test file. Then execute my algorithm (your program) against this test file.

You should see that the resulting output now has correctly aligned tabular data.

_________________
A backup a day keeps DR away.