View topic - Help needed - Serious challange with this one

Main » Forums home » Flash storage, SSD

All times are UTC - 5 hours [ DST ]

Help needed - Serious challange with this one

Page 2 of 7

[ 137 posts ]

Go to page Previous 1, 2, 3, 4, 5 ... 7 Next

Print view

Previous topic | Next topic

Author

Message

joanorsky

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 17:06

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal

HaQue wrote:

wish I had time to look more tonight, but got actual paying (I Know! where is the fun in that??) jobs to do...

I will try and pick it up tommorrow

Yeah... i know... no fun in that.. eheh..

Thank you HaQue.. i really appreciate your efforts and your time in explaining this..

I have some files that i do believe were inside the dump... would these help in mapping the files for correct block translation? My guess is yes.. but then again...

This is not 100% sure.. but i found a floppy disk that was damaged and i was able to recover it's data. I think belongs to the initial machine setup as i can see this data is inside the dump as well (fragmented but it seems to be there).

The files are here : http://www.joaocesarsilva.com/echo/EchoV104.zip

I wasn't able to compile a full WinCE image with this on Platform Builder because they seem to be incomplete.. it's only a partial or so it seems.. :\ .. nevertheless i leave them here as they might help.

Top

fzabkar

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 17:20

Joined: September 8th, 2009, 18:21
Posts: 16955
Location: Australia

Clearly there is a flaw in the way that the OP is reading the NAND flash.

AISI, the OP's NAND dump looks like this:

Code:

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

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

_________________
A backup a day keeps DR away.

Top

fzabkar

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 17:25

Joined: September 8th, 2009, 18:21
Posts: 16955
Location: Australia

I've found a few resources that may help to get an insight into how the DiskOnChip works.

Here is the original M-Systems patent for a "Flash File System" (1993):

http://www.google.com/patents/US5404485
http://patentimages.storage.googleapis. ... 404485.pdf

The "DiskOnChip Software Utilities User Manual" gives some insight into the structure of the TrueFFS file system:

http://sewoon.com/icmaster/Semi/amd/pdf ... .01_UM.pdf
http://www.tri-m.com/products/trim/file ... lities.pdf

The DiskOnChip contains a "Binary Partition", "BDTL Partition" (Block Device Translation Layer), "Secondary Program Loader" (SPL), and "NAND Flash Translation Layer" (NFTL). An "Initial Program Loader" (IPL) resides in a separate IPL ROM and this is accessed via an 8KB BIOS window.

AFAICT, the SPL occupies a fixed location at the beginning of the NAND and is not subject to wear levelling.

Code:

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

00000000  EB 2D 55 AA 60 B6 42 00 14 84 04 02 53 50 4C 5F  ë-Uª`¶B..„..SPL_
00000010  44 69 73 6B 4F 6E 43 68 69 70 20 28 63 29 20 4D  DiskOnChip (c) M
00000020  2D 53 79 73 74 65 6D 73 00 00 00 00 40 00 00 55  -Systems....@..U

The following archive contains a "DOC105.EXB - V3.3.5(V1.05) - DiskOnChip 2000 bootimage file":

http://web.archive.org/web/199711131045 ... doc105.exe

Code:

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

00000000  EB 2D 55 AA 10 00 00 00 00 00 01 05 53 50 4C 5F  ë-Uª........SPL_
00000010  66 6F 72 5F 44 4F 43 5F 32 30 30 30 20 28 63 29  for_DOC_2000 (c)
00000020  31 39 39 36 20 4D 2D 73 79 73 74 65 6D 73 00 55  1996 M-systems.U

The file has a size of 0xA800, so I'm guessing that this comprises the SPL.

Elsewhere in the OP's NAND dump I see ...

TrueFFS-BIOS -- Version 3.3.9 for DiskOnChip 2000 (V4.2) Copyright (C) M-Systems, 1992-2000

_________________
A backup a day keeps DR away.

Top

joanorsky

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 17:54

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal

There is a picture missing that shows this as DOC 4.2 (2000 variant)

As the machine works on x86 based platform the real boot image should be the doc42.086 or doc42p.086 (for plug and play OS)

I believe that 3.3.9 is the TFFS version for this 4.2 Boot version..

These are located at :

Full 4.2 Pack : ftp://ftp.emacinc.com/Archive/PCSBC/DOC_Drivers/
Boot images for 4.2 on x86 platforms : ftp://ftp.emacinc.com/Archive/PCSBC/DOC_Drivers/8086/

Top

DRUG

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 19:35

Joined: April 22nd, 2015, 20:32
Posts: 413
Location: Portugal

Is this the machine you own ?

This request may sound silly, but once the company that is in the building next to ours once had a issue with a corrupted firmware of a machine that wasn't supported anymore (no web presence, company bankrupt...) After googling a bit they ended up finding a ex-worker on LinkedIn of the manufacturer of those machines and he was able to retrive the latest firmware and get it back to work again.

Google for Omega Echo webtex.ag and try sending those guys an inquiry!

or FTL time.

Good luck!

P.S: Excuse this english, been all day trying to correct the pads of a tsop48, I can't even...

Attachments:

2289_2_big.jpg [ 105.33 KiB | Viewed 18842 times ]

2289_1_big.jpg [ 106.23 KiB | Viewed 18842 times ]

2289_big.jpg [ 92.4 KiB | Viewed 18842 times ]

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

Top

joanorsky

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 19:58

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal

This machine has only one cart... The one we are refering to has 2 carts so the hardware is not the same. That means that the software and firmware are expected to be different as well. Since the manufacturer is the same, the story must be very similar.

There are several omega models.. Such as nikita, echo and zip. I dont know if there is any chance of compability... But hey... Making a contact doesnt hurt..

Thanks for your help.. I appreciate it..

Top

fzabkar

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 20:05

Joined: September 8th, 2009, 18:21
Posts: 16955
Location: Australia

The DOC PCB has a 3.3V LDO regulator IC at the bottom left corner. Therefore I suspect that the DOC is a 5V part. Measuring the Vcc and Gnd pins at the IC socket on the main board should confirm this.

LM3480IM3-3.3, Texas Instruments, 3.3V, 100mA, LDO regulator, marking L0A, SOT-23
http://www.ti.com/lit/ds/symlink/lm3480.pdf

I would first check whether the regulator is working.

The NFDC-2148 flash controller appears to contain the IPL boot code in its internal memory. Therefore ISTM that one way to test whether the controller is alive would be to read the DOC as a standard 32-pin JEDEC flash EEPROM in a regular chip reader. You could select any device with the same voltage and pinout, eg SST28SF040A.

http://www.metatech.com.hk/datasheet/ss ... -10-DS.pdf

Of course you will only retrieve 8KB of data (the rest of the address space would be aliased).

Attachments:

MD2200_pinout.jpg [ 134.88 KiB | Viewed 18827 times ]

_________________
A backup a day keeps DR away.

Top

HaQue

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 20:14

Joined: December 4th, 2012, 1:35
Posts: 3903
Location: Adelaide, Australia

Hi OP:
I will put this question alone, as I think you have previously missed it:

can you say what process and hardware you used to dump the chip?

Top

DRUG

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 20:25

Joined: April 22nd, 2015, 20:32
Posts: 413
Location: Portugal

HaQue wrote:

Hi OP:
I will put this question alone, as I think you have previously missed it:

can you say what process and hardware you used to dump the chip?

I've already asked him, he was going to ask that to the guy who did it.

Two questions for you master HaQue:

a)Doesn't VNR has a bitmap viewer that can help on this ?

b)Can the voltage used to do the dump have any influence on the errors found?

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

Top

jermy

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 20:49

Joined: March 19th, 2015, 15:01
Posts: 1388
Location: isreal

DRUG wrote:

a)Doesn't VNR has a bitmap viewer that can help on this ?

it does, that's why he asked the question

DRUG wrote:

b)Can the voltage used to do the dump have any influence on the errors found?

yes, http://rusolut.com/analysis-of-bit-errors-in-nand/

Top

joanorsky

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 21:09

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal

fzabkar wrote:

The LM is OK.. it was burned... so we have replaced it and tested it. Since this was done, and we didnt knew the extend of the damage we managed to get a new board from another equal DOC bought from germany. The new DOC board was equal to the original (all references equal.. same controller, resistors, etc).. so.. 100% sure the LM is ok.

fzabkar wrote:

The NFDC-2148 flash controller appears to contain the IPL boot code in its internal memory. Therefore ISTM that one way to test whether the controller is alive would be to read the DOC as a standard 32-pin JEDEC flash EEPROM in a regular chip reader. You could select any device with the same voltage and pinout, eg SST28SF040A.

Of course you will only retrieve 8KB of data (the rest of the address space would be aliased).

We have replaced this controler by another one from a new board (as mentioned above) as we have suspected it had totally burned because the LM was initially faulty. Is it possible that the failure from this DOC was because this controller became also damaged and that the new controller's IPL was blank or based on a non x86 platform?!? Are you sure that the IPL is on the NFDC-2148? The donor controller (2148) as mentioned above was from another equal DOC that we managed to get.. (but i cant make sure what it had inside.. so i dont quite know if the donor controller had a x86 platform originally.. to be quite honest... we didnt even knew this had a ROM within.. i know... what a dumb thing to find out now.. :\ )

HaQue wrote:

can you say what process and hardware you used to dump the chip?

I wasnt able to get in touch with the guy who did the nand backup (was done in a offchip procedure though).. tomorrow i think i can get that info and will post it here ASAP.

Top

HaQue

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 21:25

Joined: December 4th, 2012, 1:35
Posts: 3903
Location: Adelaide, Australia

DRUG wrote:

HaQue wrote:

Hi OP:
I will put this question alone, as I think you have previously missed it:

can you say what process and hardware you used to dump the chip?

a) Yes, as jermy say, it is why I asked. I already loaded Francs edited version, and the original in VNR and both just don't look right.

b) The link jermy posted is the best resource for this. though this dump looks very sound with possibly no bit errors at all, just the config used to dump appears to be wrong.

Top

fzabkar

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 22:27

Joined: September 8th, 2009, 18:21
Posts: 16955
Location: Australia

I'm not sure of anything, but AIUI the DOC hooks into BIOS during its search for adapters. BIOS finds an 8KB window, loads the IPL (Initial Program Loader) boot code, and this code then loads the SPL code (Secondary Program Loader). The SPL code appears to be located at address 0 in the NAND, so this would suggest that the IPL must be outside the NAND, in which case the only other place is the controller.

_________________
A backup a day keeps DR away.

Top

joanorsky

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 23:05

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal

Just for curiosity... i made a test run on photorec tool with the following geometry :

Sectors : 2
Heads : 16
Cylinders : 996

Photorec - www.cgsecurity.org

in a command line (windows) :
photorec_win dump.dmp (no ecc) ->advanced options : brute force : change geometry

It managed to get me all the files inside the dump. The size and time stamp seem to be ok.. but the internals seem to be corrupted.

This is one printscreen from one of the grabbed inodes :

Top

fzabkar

Post subject: Re: Help needed - Serious challange with this one

Posted: May 11th, 2015, 23:26

Joined: September 8th, 2009, 18:21
Posts: 16955
Location: Australia

I had a look at the following firmware file:

ftp://ftp.emacinc.com/Archive/PCSBC/DOC ... /doc42.086

ISTM that it is structured as follows:

Code:

0x0000 - 0x01FF   IPL code
0x0200 - 0x03FF   copy of IPL code
0x0400 - 0x1FFF   SPL code
0x2000 - 0x27FF   TFFS code
0x2800 - 0x8FFF   more TFFS code
0x9000 - 0xAFFF   block of repeating 0x90 with 0x55AA signature at start

Here is the IPL code:

Code:

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

00000000  55 AA 10 EB 3C 00 00 28 43 29 4D 2D 53 79 73 74  Uª.ë<..(C)M-Syst
00000010  65 6D 73 31 39 39 38 00 00 00 21 00 00 04 00 1C  ems1998...!.....
00000020  55 24 50 6E 50 01 02 00 00 00 1E 6D 1A 01 10 00  U$PnP......m....
00000030  00 00 00 00 80 01 94 00 00 00 00 00 00 00 00 00
00000040  00 9C 50 53 51 52 56 57 55 1E 06 BA C0 1F 33 C0
00000050  8E C0 33 FF 83 C2 40 8E DA 81 FA 00 A0 74 1A 33
00000060  F6 B9 00 02 FC AD 0B C0 75 E8 E2 F9 83 FF 00 75
00000070  02 1E 07 47 83 FF 30 72 DB 83 FF 30 73 05 BA 00
00000080  58 8E C2 0E 1F 8B EC 83 EC 04 8C C0 8C 46 FE C7
00000090  46 FC AB 00 0E E8 13 00 8B 46 FE 8E C0 33 FF B9
000000A0  00 60 33 C0 FC F3 AB 8B E5 EB 74 55 8B EC 8B 46
000000B0  04 8E D8 BB 00 00 C6 87 03 10 00 C6 87 02 10 85
000000C0  C6 87 02 10 85 BE 00 08 B1 FF E8 5D 00 FC 32 E4
000000D0  B1 00 E8 55 00 2E 8B 0E 1E 00 33 FF F7 C1 FF 01
000000E0  75 23 C6 87 04 10 0D 2E 8B 16 1C 00 03 D7 D0 EE
000000F0  88 14 88 34 33 D2 88 14 C6 87 1E 10 00 C6 87 04
00000100  10 09 E8 36 00 84 87 0D 10 AC 02 E0 AA 4E E2 CC
00000110  2E 3A 26 20 00 75 06 5D 06 33 C0 50 CB 5D CB 07
00000120  1F 5D 5F 5E 5A 59 5B 58 9D CB C6 87 04 10 0B 88
00000130  0C C6 87 1E 10 00 C6 87 04 10 09 F6 87 20 10 80
00000140  F6 87 20 10 80 F6 87 20 10 80 F6 87 20 10 80 F6
00000150  87 04 10 80 74 F9 F6 87 20 10 80 F6 87 20 10 80
00000160  C3 1C 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000170  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
........
000001F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The "55AA" signature at the start appears to be consistent with other BIOS adapter code.

For example, here is the BIOS entry for my graphics card at address C000:0:

Code:

-d c000:0 1ff

C000:0000  55 AA 60 E9 53 02 32 2E-30 30 2E 35 30 20 2D 30   U.`.S.2.00.50 -0
C000:0010  98 01 AC 01 DE 01 F2 01-8F 55 8F 04 8F 04 49 42   .........U....IB
C000:0020  4D 20 43 4F 4D 50 41 54-49 42 4C 45 31 32 2F 32   M COMPATIBLE12/2
C000:0030  38 2F 32 30 30 30 2D 31-36 3A 34 34 3A 33 31 20   8/2000-16:44:31
C000:0040  3F 01 02 01 3E 01 40 01-65 01 39 10 00 73 57 01   ?...>.@.e.9..sW.
C000:0050  97 01 30 00 5A 64 80 42-00 B3 45 80 53 00 37 61   ..0.Zd.B..E.S.7a
C000:0060  80 64 00 37 22 80 85 00-37 61 80 64 00 37 61 80   .d.7"...7a.d.7a.
C000:0070  64 00 37 61 80 64 00 37-61 80 64 00 54 43 80 64   d.7a.d.7a.d.TC.d
C000:0080  00 53 43 80 64 00 55 43-80 64 00 52 43 80 64 00   .SC.d.UC.d.RC.d.
C000:0090  3F 42 80 64 00 54 43 80-64 00 54 43 80 64 00 54   ?B.d.TC.d.TC.d.T
C000:00A0  43 80 64 00 10 01 09 A3-00 00 00 00 00 43 43 43   C.d..........CCC
C000:00B0  00 00 00 00 00 1E 1E 1E-00 00 00 00 00 2A 2A 2A   .............***
C000:00C0  00 00 00 00 00 06 06 06-00 00 00 00 00 00 00 00   ................
C000:00D0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
C000:00E0  00 00 00 00 00 00 16 B2-F6 0D 00 11 40 21 ED BA   ............@!..
C000:00F0  08 2A 05 E3 00 00 00 80-D1 00 B9 00 B3 00 00 00   .*..............
C000:0100  00 00 53 69 53 20 37 33-30 20 41 47 50 20 54 72   ..SiS 730 AGP Tr
C000:0110  75 65 20 43 6F 6C 6F 72-20 47 72 61 70 68 69 63   ue Color Graphic
C000:0120  73 20 61 6E 64 20 56 69-64 65 6F 20 41 63 63 65   s and Video Acce
C000:0130  6C 65 72 61 74 6F 72 00-00 00 00 00 00 00 0E 00   lerator.........
C000:0140  0F 20 42 79 74 65 73 20-56 69 64 65 6F 20 4D 65   . Bytes Video Me
C000:0150  6D 6F 72 79 2C 14 00 07-42 49 4F 53 20 56 65 72   mory,...BIOS Ver
C000:0160  73 69 6F 6E 20 32 2E 30-30 2E 35 30 20 20 16 00   sion 2.00.50  ..
C000:0170  53 75 70 70 6F 72 74 20-56 45 53 41 20 42 49 4F   Support VESA BIO
C000:0180  53 20 45 78 74 65 6E 73-69 6F 6E 20 56 65 72 20   S Extension Ver
C000:0190  33 2E 30 0D 0A 25 00 07-53 69 53 00 00 00 00 00   3.0..%..SiS.....
C000:01A0  00 00 00 00 00 00 00 00-00 00 00 00 53 69 6C 69   ............Sili
C000:01B0  63 6F 6E 20 49 6E 74 65-67 72 61 74 65 64 20 53   con Integrated S
C000:01C0  79 73 74 65 6D 73 20 43-6F 72 70 2E 00 00 00 00   ystems Corp.....
C000:01D0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 37 33   ..............73
C000:01E0  30 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   0...............
C000:01F0  00 00 32 2E 30 30 2E 35-30 00 00 00 64 00 00 00   ..2.00.50...d...

I couldn't find anything that looks like IPL code in your NAND dump. That said, something doesn't look right with the start of the dump. Every second 0x100 sized block is zero filled. I would have expected a contiguous block of code. In fact if I reassemble the SPL section by removing the empty 0x100-byte blocks from your NAND dump, the result is almost identical to the SPL code in the doc42.086 file.

Attachments:

SPL.rar [3.64 KiB]
Downloaded 1046 times

_________________
A backup a day keeps DR away.

Top

fzabkar

Post subject: Re: Help needed - Serious challange with this one

Posted: May 12th, 2015, 1:29

Joined: September 8th, 2009, 18:21
Posts: 16955
Location: Australia

Could you dump an image of a new, working DiskOnChip via DOS using the GETMIMG utility? Hopefully the only content of the image file will be the firmware, an empty formatted FAT16 volume, and maybe the FTL.

_________________
A backup a day keeps DR away.

Top

fzabkar

Post subject: Re: Help needed - Serious challange with this one

Posted: May 12th, 2015, 3:34

Joined: September 8th, 2009, 18:21
Posts: 16955
Location: Australia

I've examined the doc42.086 file again. This time I looked for 8-bit checksums.

Code:

address range     checksum  function
-------------------------------------------------------------------------
0x0000 - 0x01FF   0x00      IPL code
0x0200 - 0x03FF   0x00      copy of IPL code
0x0400 - 0x042F   0x22      header of SPL code
0x0430 - 0x1FFF   0x33      SPL code
0x2000 - 0x27FF   0x00      TFFS code
0x2800 - 0x8FFF   0x00      more TFFS code
0x9000 - 0xAFFF   0x00      block of repeating 0x90 with 0x55AA signature

Comparing against your own NAND dump ...

Code:

address in SPL.DMP

0x0400 - 0x042F   0x22      header of SPL code
0x0430 - 0x1FFF   0xF2    * SPL code

Code:

address in NOECC.DMP

0x4000 - 0x47FF   0x00      TFFS code
0x4800 - 0xA7FF   0xB2    * more TFFS code
0xA800 - 0xBFFF   0x00      block of repeating 0xFF

ISTM that the 0x22 and 0x33 numbers look too "neat" to be coincidental, especially since the two SPL headers contain significantly different data.

I'd say that your NAND dumps have several bit errors in the "SPL code" and "more TFFS code" sections. However, I would be surprised if these were not correctable by ECC.

Here is a comparison of the SPL code sections. The differences occur randomly in single bits.

Code:

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

00000560  0D A1 BC 16 8B 4E FA 8B 16 24 17 FF 5E FC 8B 46
00000160  0D A1 BC 56 8B 4E FA 8B 16 24 17 FF 5E FC 8B 46
                   ^

000007F0  C7 06 D2 16 00 00 B8 04 00 50 16 8D 46 FC 50 33
000003F0  C7 06 D2 16 00 00 B8 04 00 50 16 8D 46 FC D0 33
                                                    ^

00000860  C2 B8 1F 00 8B E5 5D C3 55 8B EC 8B 56 04 EB 04
00000460  C2 B8 1F 00 8B E5 5D C3 55 8B EC 8B 56 04 E9 04
                                                     ^

00000B00  FC 16 A1 FA 16 E8 82 0F 89 16 FC 16 A3 FA 16 33
00000700  FC 16 A1 FA 16 E9 82 0F 89 16 FC 16 A3 FA 16 33
                          ^

_________________
A backup a day keeps DR away.

Top

joanorsky

Post subject: Re: Help needed - Serious challange with this one

Posted: May 12th, 2015, 7:44

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal

Here is a dump we have made a few days ago.. in order to check the structure ourselfs. The dump was made using the DOC tool "getmimg". We had the doc42.086 or doc42p.086 firmware within .. with the 3.3.9 TFFS version as well.

We had only 2 text files within this dump. Both were clear text.. repeated in order to make a few MB. One of the files just had a "t" repeated inside and the other text file had something like (wich has a typo) "eu sei que vais ler isto o codigo e disk-on-CHIP" (translates to : "I know that you are going to see this in the disk-on-CHIP")

Clean dump using DOC tools : http://www.joaocesarsilva.com/echo/clean_dump.rar

Top

joanorsky

Post subject: Re: Help needed - Serious challange with this one

Posted: May 12th, 2015, 12:50

Joined: May 8th, 2015, 19:08
Posts: 40
Location: Portugal

HaQue wrote:

Hi OP:
I will put this question alone, as I think you have previously missed it:

can you say what process and hardware you used to dump the chip?

I was just informed that the hardware used for this dump was the PC3000 (offchip procedure on the samsung nand). They said that they checked for bit errors and that the dump was ok. No further details were given to me...

Top

fzabkar

Post subject: Re: Help needed - Serious challange with this one

Posted: May 12th, 2015, 15:00

Joined: September 8th, 2009, 18:21
Posts: 16955
Location: Australia

joanorsky wrote:

HaQue wrote:

Hi OP:
I will put this question alone, as I think you have previously missed it:

can you say what process and hardware you used to dump the chip?

LOL. Obviously there are bit errors and obviously the dump is flawed. Either this person doesn't understand how to use his expensive tool, or the tool is junkware. Ask him how he managed to determine that there are no bit errors when there are no ECC bytes in the dump.

Adding to my previous post ...

The first TFFS code sections are identical. The second TFFS sections differ in length and content, so a bit-for-bit comparison is not possible.

Previously I compared two copies of the FAT in the data area. These were identical. ISTM that the bit errors may be confined to the static area of the NAND, ie the firmware area. IMO this seems reasonable since NAND flash has finite data retention (10 years according to the datasheet). The user area would be subject to wear levelling and would be refreshed from time to time. Perhaps it would be advisable to refresh the NAND's firmware partition using the appropriate DOC utility.

FWIW, the number of used clusters is 5863. This means that the used space amounts to approximately 12MB.

5863 clusters x 4 sectors per cluster x 512 bytes per sector = 12 007 424 bytes

_________________
A backup a day keeps DR away.

Top

Page 2 of 7

[ 137 posts ]

Go to page Previous 1, 2, 3, 4, 5 ... 7 Next

Main » Forums home » Flash storage, SSD

All times are UTC - 5 hours [ DST ]

Who is online

Users browsing this forum: jcan and 13 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum