Help needed - Serious challange with this one

[jermy]

first of all we need to know if the right configuration was done before reading i.e. page and block size Etc. (Because, it seems from the current dump, that the settings wasn't set properly before reading)
only then we gonna deal with bit error (if there is at all)

[HaQue]

Would it be possible to get the chip to me?
I think it is quite important to not wreck chances of success by playing with the chip too much and damaging it.
I get quite a few chips from other DR companies in AU and overseas that the PC3k doesn't like

[joanorsky]

Would it be possible to get the chip to me?
I think it is quite important to not wreck chances of success by playing with the chip too much and damaging it.
I get quite a few chips from other DR companies in AU and overseas that the PC3k doesn't like

I don't know if that is possible.. but i do thank you a lot for making yourself available for this. I will have to check that will my colleagues.. it doesn't depend solely on me..

[pcimage]

I'll take a look if you wanna send to UK, a little nearer.

[fzabkar]

I can't see any FTL in the "clean" dump, but I suppose that's to be expected.

The structure appears to be as follows:

16-byte header for entire image
16-byte header for 1st 0x4000 byte block
1st 0x4000 byte block
16-byte header for 2nd 0x4000 byte block
2nd 0x4000 byte block
16-byte header for 3rd 0x4000 byte block
etc

The first 3 blocks are assigned to the SPL and TFFS firmware. The user area begins at the 4th block.

This is the image header:

Code:

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

00000000  56 10 E6 03 03 00 00 04 0E 0E FF FF FF FF FF FF

Here are the firmware block headers:

Code:

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

00000010  0F CB 19 A3 85 14 55 55 84 A8 AC A0 FF FF FF FF
00004020  16 50 13 28 53 FF 55 55 84 A8 AC A0 FF FF FF FF
00008030  DA F1 18 6F 01 72 55 55 84 A8 AC A0 FF FF FF FF

Here are the first 3 user block headers, and the last 2:

Code:

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

0000C040  00 00 FF FF 00 00 FF FF 00 00 FF FF 00 00 FF FF
00010050  01 00 FF FF 01 00 FF FF 01 00 FF FF 01 00 FF FF
00014060  02 00 FF FF 02 00 FF FF 02 00 FF FF 02 00 FF FF
........
007C9F30  EF 01 FF FF EF 01 FF FF EF 01 FF FF EF 01 FF FF
007CDF40  E7 02 FF FF E7 02 FF FF E7 02 FF FF E7 02 FF FF

Clearly the user block headers reflect the block number. In this "clean" dump the block headers are sequential until the very last one. ISTM that only the in-use blocks are imaged.

I have reassembled the firmware blocks by removing the headers and 0xFF pad bytes.

Code:

address range     checksum  function
----------------------------------------------
0x0000 - 0x002F   0x22      header of SPL code
0x0030 - 0x1BFF   0x33      SPL code
0x1C00 - 0x23FF   0x00      TFFS code
0x2400 - 0x8BFF   0x00      more TFFS code

Once again the checksums match the corresponding components in the doc42.086 file.

Attachments

SPL_v4_2.rar

(18.15 KiB) Downloaded 790 times

[fzabkar]

I'll take a look if you wanna send to UK, a little nearer. :-)

I don't understand why the OP's NAND dump isn't enough. Sure, it doesn't have the ECC bytes, so it has bit errors, but if your tool can't reassemble the FAT file system from the dump, then what difference will it make to have the physical chip in your hands?

[joanorsky]

This might sound stupid.. but.. cant it be that the block mapping is inside the TFFS block (ence there are two identical blocks such as the 2 identical FAT16??)



Source : http://wenku.baidu.com/view/9cfc7d88d0d ... e696c.html

[fzabkar]

The TFFS sections are targeted by firmware updates, so I can't see how they could have any mapping info. In any case the FTL is subject to wear levelling (according to the M-Systems patent). If you could dump the raw NAND data of your "clean" DOC, rather than a GETMIMG dump, then perhaps the FTL location would become apparent. The GETMIMG dump appears to be a logical image rather than a physical one.

[fzabkar]

Is it possible that the mapping for each block/page is stored within its own ECC bytes?

[HaQue]

The ecc bytes only store the error correcting bytes, such as for the BCH algorithm
The service area or spare area should hold the info you are talking about but if the ecc was part of the SA then it should be more bytes

[pcimage]

There's no SA data at all as I can see, no block numbers etc..

Appears only to be the 512 user sectors, plus a repeat of the 16 bytes of the following sector and no 16-byte SA data.

Hence the reason for getting the chip read properly.

Happy to read the chip for free.

[joanorsky]

There's no SA data at all as I can see, no block numbers etc..

Appears only to be the 512 user sectors, plus a repeat of the 16 bytes of the following sector and no 16-byte SA data.

Hence the reason for getting the chip read properly.

Happy to read the chip for free.

I appreciate all your willingness to help. Nevertheless i would prefer to do the dump myself as i no longer want to be dependant of other's equipment and to avoid further delays as well as to avoid possible courrier loss. What do you guys think about the TNM5000? Do you think this programmer is able to read this nand as required? What are the configurations that i need to be aware of (page size, volts, spare size, etc...)?

[jermy]

i'm not familiar with this programmer, but it says here that your chip is supported

[DRUG]

There's no SA data at all as I can see, no block numbers etc..

Appears only to be the 512 user sectors, plus a repeat of the 16 bytes of the following sector and no 16-byte SA data.

Hence the reason for getting the chip read properly.

Happy to read the chip for free.

I appreciate all your willingness to help. Nevertheless i would prefer to do the dump myself as i no longer want to be dependant of other's equipment and to avoid further delays as well as to avoid possible courrier loss. What do you guys think about the TNM5000? Do you think this programmer is able to read this nand as required? What are the configurations that i need to be aware of (page size, volts, spare size, etc...)?

I would start by checking the volts here:

Attachments

K9F2808U0B.pdf

(306.56 KiB) Downloaded 848 times

[jermy]

I would start by checking the volts here:

as discussed before, probably there is no bit error, the issue is the right configurations, (page size block size Etc.)

that being said

even there is bit error we deal with that latter, first the right configurations has to be set, in order to get the proper dump

only then...

[DRUG]

I would start by checking the volts here:

as discussed before, probably there is no bit error, the issue is the right configurations, (page size block size Etc.)

that being said

even there is bit error we deal with that latter, first the right configurations has to be set, in order to get the proper dump

only then...

How do you find out the right configs for a proper dump ?

[jermy]

by analyzing the dump in bitmap mode

[jermy]

i really hope your chip is been supported
because i don't know how 1024 blocks (c the pic. attached with original configurations) end up with the size of 16MB, if page size supposed to be 528

as written above

Instead it should be ...

Code:

512-bytes from page #0
16 ECC bytes from page #0
512-bytes from page #1
16 ECC bytes from page #1
512-bytes from page #2
etc

& i can't find where it (page size) can be changed

[jermy]

EDIT: but i repeat i'm not familiar with this programmer
(i don't know y the message above can't be edited, (seems there is a very limited time to edit a message))

[joanorsky]

by analyzing the dump in bitmap mode

Just for my own curiosity ..what kind of pattern should we be looking for on the dump? (I ask this because i might have found someone near that has a compatible reader, that actually "might" be able to read this nand again)

I mean.. can you indicate an example like this one? (This is from Digital Forensics Framework on the dump without the ECC.. i think that this is what you were referring to.. right?)