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)

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..

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

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

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:


Here are the firmware block headers:


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


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.


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

_________________
A backup a day keeps DR away.

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?

_________________
A backup a day keeps DR away.

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

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.

_________________
A backup a day keeps DR away.

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

_________________
A backup a day keeps DR away.

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

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.

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

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'm not familiar with this programmer, but it says here that your chip is supported

I would start by checking the volts here:

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

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 ?

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

by analyzing the dump in bitmap mode

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


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

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))

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?)