Help needed - Serious challange with this one

[joanorsky]

Check page 5 to 10 on this document : http://pdf.datasheetarchive.com/indexer ... 390008.pdf

Is it possible that we have been reading the original dump in a wrong way?

BTW the nand chip was sent to Sean for further checkout on the dumping procedure....

[fzabkar]

The Intel document confirms that the FTL exists in system RAM, not on the DOC. I was led to believe that the FTL and wear levelling were functions that were handled by the DOC's microcontroller. In fact these are handled by TrueFFS drivers running under DOS. These drivers are loaded into RAM via the BIOS adapter window that loads the IPL ROM code.

In short, we were looking for a map that didn't exist. Had your tools, or their operator, not let you down, this would have been immediately evident in the NAND dump. I'm convinced that even a complete novice like myself would have been able to determine the logical-to-physical translation scheme, and we would have had your data by the following day.

[HaQue]

BTW the nand chip was sent to Sean for further checkout on the dumping procedure....

well fine then! [blows raspberry]


No, seriously

Except we aren't looking for the FTL, we are looking for the FTL Map - VPM, VBM & BAM. This may or may not be stored on the Flash, and if it is, may or may not be completely stored on the flash. (pg. 11).



Another thing to consider is this document is a version of an FTL scheme.

Many different variations are possible between vendors, and between devices, and even between versions of the same device.

I reckon wait 'til Sean dumps the chip and see what is different.

[joanorsky]

While the chip travels... here goes some more reading material on the MSystems FTL algorithm.. (Kinda interesting.. )

www.it.iitb.ac.in/frg/wiki/images/a/a7/ ... ort_01.pdf

Attachments

P12440_silpa_week_07_Report_01-1.pdf

(152.83 KiB) Downloaded 1001 times

[HaQue]

(Kinda interesting.. )

Kinda? Actually this whole thing is VERY interesting! one observation is that if this device/machine was one manufactured this year, and we had to perform similar analysis.. there would probably be not a single document apart from a marketing "datasheet" with max 5 40pt bullet points saying virtually nothing.

remember that documents relating to any system is a guide only, and even if regular programmers used these docs as a guide or manual, the actual produced system is however they decided to implement it. Customisations and errors also make it more interesting.

Thanks for the docs, and also to everyone else posting useful info.

[guru]

You're correct with the below. Many times I have seen specs that are not followed

(Kinda interesting.. )

remember that documents relating to any system is a guide only, and even if regular programmers used these docs as a guide or manual, the actual produced system is however they decided to implement it. Customisations and errors also make it more interesting

[DRUG]

joanorski, how is the process going?

[joanorsky]

It arrived at uk today. It should be delivered next monday...

[pcimage]

It arrived at uk today. It should be delivered next monday...

Tuesday at the earliest, national holiday here tomorrow

[pcimage]

Chip arrived.

Read with Soft Center tool (my PC3K won't read at all although the ID is in the supported list, just gives read errors but need to look into that) , but still weird...

https://www.hightail.com/download/bXBhZ ... MHVxV2NUQw

As you'll see, SA data still not being read correctly. The 16-byte SA data just contains the last byte of the 512-byte data area repeated.

[joanorsky]

The latest dumps have the same problem. Worse still, the firmware sections are missing.

On the plus side, your latest dumps are identical, so there is some hope that there are no bit errors in the user data area.

I notice that your chip has an /SE pin that more recent flash chips do not need. I suspect that you need to ground this pin in order to be able to read the spare bytes.

I have forgotten to mention but on the DOC's board the SE pin IS grounded as specified on the K9F2808's datasheet. I don't know if this is relevant to this situation or not...

[pcimage]

Have now read it with a real old version of the SC nand reader, and SA data now seems to have read....

https://www.hightail.com/download/bXBhZ ... QUpvZE1UQw

[pcimage]

Using block size of 0x4200 and markers at 521/520 I have rebuilt the dump...

Attachments

[pcimage]

Here's the image file dump...

https://www.hightail.com/download/bXBhZ ... SWZOTzhUQw

[pcimage]

And running GDB on the image produces this data (root folder names lost)...

https://www.hightail.com/download/bXBhZ ... MTQxWjhUQw

[joanorsky]

Ok.. Now i am getting nervous...

Have found the nk.bin file inside? (I am currently away from the computer)

[HaQue]

Nice work Sean!!

[HaQue]

yes NK.bin is there

[joanorsky]

My heart is running fast now. I will test this out on the device's board this afternoon/night and will get back to you guys after it has been "worked on"...

Sean... very nice job indeed!

[joanorsky]

At first analysis it seems ok.. but after some looking i have notice that some files are corrupted. Take a look at these two files ..

msgalarm_original.msg -> From original setup (that i had partially had over here)
msgalarm_dump.msg -> From Sean dump


Download at : http://www.joaocesarsilva.com/echo/damaged_data.rar