Help with MNDSPEED PC3008 NAND ECC

[matostr]

File with 14Byte ECC only. ufile.io / ij8dspdp

[matostr]

File with 14Byte ECC only ufile . io / ij8dspdp(I added spaces because I cant post links).
I see there are ECC that are all 0x00 or all 0xFF so LBNs shouldn't be here.

[fzabkar]

I can't see any pattern. The "ECC" field seems random to me.

[matostr]

They are not exactly random ECC at first pages repeats exactly the same at 0xe00 and 0x1c00 in ECC file. This is because this devices has few copies of bootloader.

[fzabkar]

They are not exactly random ECC at first pages repeats exactly the same at 0xe00 and 0x1c00 in ECC file. This is because this devices has few copies of bootloader.

That proves that there is no LBN information, so the sectors must be sequential. :-?

[matostr]

Yes, I think they are sequential.

[fzabkar]

So why does the squashfs image not mount? Could the image contain a RAID mirror???

[matostr]

This is simple device, it doesn't have any RAID.
I think it may need to correct ECC.
When I try to extract it I got this message:

Code:

read_id_table: failed to read id table block
File system corruption detected
FATAL ERROR:failed to read file system tables


[fzabkar]

Can you extract the "id table block"? Are you able to confirm that it is located at the correct sector?

This "how-to" states that squashfs is a read-only file system, which would confirm that the sectors are sequential.

https://tldp.org/HOWTO/html_single/SquashFS-HOWTO/

[matostr]

I will look at this next day.

[fzabkar]

If you dump the flash IC two or more times, are the dumps identical? If not, I would perform a bitwise AND on all the copies. This is because flash cells decay over time and flip from 0 to 1. If a particular bit is mostly 1, but sometimes 0, then it is most likely a 0 that is slowly erasing itself.

FWIW, I have written a tool for this purpose:

http://users.on.net/~fzabkar/FreeBasic_W32/Utils/bitwand.exe
http://users.on.net/~fzabkar/FreeBasic_W32/Utils/bitwand.bas

[Amarbir[CDR-Labs]]

If you dump the flash IC two or more times, are the dumps identical? If not, I would perform a bitwise AND on all the copies. This is because flash cells decay over time and flip from 0 to 1. If a particular bit is mostly 1, but sometimes 0, then it is most likely a 0 that is slowly erasing itself.

FWIW, I have written a tool for this purpose:

http://users.on.net/~fzabkar/FreeBasic_W32/Utils/bitwand.exe
http://users.on.net/~fzabkar/FreeBasic_W32/Utils/bitwand.bas

Hi,
If he can dump the nand min three times and provide me a copy i can do this and upload back , I would be interested to get this chip for R&D Too .

[fzabkar]

I would be interested to get this chip for R&D Too .

There are 4 identical regions at the start of the dump.

0x - 0x20fff
0x21000 - 0x41fff
0x42000 - 0x62fff
0x63000 - 0x83fff

There are no bit differences between these regions, ie no errors in the first 528KiB.

What more do you need for research? :-?

[matostr]

I read it using TL866 and TL866 app is verifying after reading, so I'm sure it doesn't have any errors because of reading.
After reading it I soldered it back to pcb, so I can't easily read it again.

I would be interested to get this chip for R&D Too .

You can buy on ebay "AT&T DPH-154", operator stopped using this so they are cheap.

[fzabkar]

Interesting thread and resources:

https://osmocom.org/issues/4574

https://github.com/neggles/dph154-gpl

[fzabkar]

There is a cramfs superblock and file system at 0x600000 - 0x61ffff plus 3 copies. There are 13 files.

The 3rd and 4th copies are identical (I haven't tested the others).

There are additional cramfs file systems at 0x163B830, 0x68da830, 0x68db830, 0xb8eb830.

https://github.com/spotify/linux/blob/master/include/linux/cramfs_fs.h

Code:

Offset(h) 00       04       08       0C

00640000  453DCD28 00200000 03000000 00000000  E=Í(. ..........
00640010  436F6D70 72657373 65642052 4F4D4653  Compressed ROMFS
00640020  3336AFBA 00000000 06000000 0D000000  36¯º............
00640030  436F6D70 72657373 65640000 00000000  Compressed......
00640040  ED410000 6C000000 C0040000 ED410000  íA..l...À...íA..
00640050  14000000 820B0000 63657274 73000000  ....‚...certs...
00640060  A4810000 C6040000 45D30000 68775F64  ¤...Æ...EÓ..hw_d
00640070  65736372 69707469 6F6E2E64 61740000  escription.dat..
00640080  ED410000 10000000 01100000 6D697363  íA..........misc
00640090  ED410000 10000000 81120000 70707900  íA..........ppy.
006400A0  A4810000 520A0000 03280100 72616469  ¤...R....(..radi
006400B0  6F63616C 2E646174 ED410000 34000000  ocal.datíA..4...
006400C0  C20C0000 63657274 31000000 A4810000  Â...cert1...¤...
006400D0  8B050000 04150000 33676170 2D636572  ‹.......3gap-cer
006400E0  742E7065 6D000000 ED810000 4C0B0000  t.pem...í...L...
006400F0  83560000 63686169 6E2E7065 6D000000  ƒV..chain.pem...
00640100  ED410000 18000000 01110000 68680000  íA..........hh..
00640110  A4810000 23000000 83F50000 61647665  ¤...#...ƒõ..adve
00640120  72742E64 61740000 ED410000 18000000  rt.dat..íA......
00640130  81130000 70707931 A4810000 C2030000  ....ppy1¤...Â...
00640140  83F80000 33676170 2D6B6579 2E70656D  ƒø..3gap-key.pem
00640150  68050000 78DA6594 4BAFA24A 1485E7FC  h...xÚe”K¯¢J.…çü

Code:

Offset(h) 00       04       08       0C

00660000  453DCD28 00200000 03000000 00000000  E=Í(. ..........
00660010  436F6D70 72657373 65642052 4F4D4653  Compressed ROMFS
00660020  3336AFBA 00000000 06000000 0D000000  36¯º............
00660030  436F6D70 72657373 65640000 00000000  Compressed......

There is a squashfs signature ("hsqs") at 0x68000. If you carve out the data that follows, you may be able to mount the file system.

Code:

Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

00680000  68 73 71 73 BE 10 00 00 5A BF 01 52 00 00 02 00  hsqs¾...Z¿.R....
00680010  47 00 00 00 04 00 11 00 C0 00 01 00 04 00 00 00  G.......À.......
00680020  AE 04 4A 6C 00 00 00 00 9A 0A A4 00 00 00 00 00  ®.Jl....š.¤.....
00680030  92 0A A4 00 00 00 00 00 FF FF FF FF FF FF FF FF  ’.¤.....ÿÿÿÿÿÿÿÿ
00680040  1C F2 A2 00 00 00 00 00 E4 5F A3 00 00 00 00 00  .ò¢.....ä_£.....
00680050  C2 E8 A3 00 00 00 00 00 64 0A A4 00 00 00 00 00  Âè£.....d.¤.....
00680060  FD 37 7A 58 5A 00 00 01 69 22 DE 36 03 C0 F2 B9  ý7zXZ...i"Þ6.Àò¹
........
00C7FFE0  F2 80 7D D0 20 3A B1 2F C3 A3 6B C5 5F F3 6C 90  ò€}Ð :±/ãkÅ_ól.
00C7FFF0  BC 49 AE 51 C2 79 E1 87 70 6F 54 DE CA F6 5B 3B  ¼I®QÂyá‡poTÞÊö[;

[fzabkar]

Some info on "unsquashing" the file system...

https://poppopret.org/2012/04/18/netgear-unsquashfs-c-version-1-3/
https://reverseengineering.stackexchange.com/questions/2196/extract-squashfs-filesystem-with-shsq-magic-number#2199

[fzabkar]

I decompressed the section between 0x680000 and 0xc7ffff using 7Zip. I got a truncated Linux ELF executable. :-?

[fzabkar]

I decompressed the cramfs images with 7Zip, and extracted the files..

[matostr]

Interesting thread and resources:

https://osmocom.org/issues/4574

https://github.com/neggles/dph154-gpl

I know, I read it.
I know about cramfs, I extracted it.
I only have problem with squashfs.
There is also ubifs and it also makes errors when extracting.