Help to unscramble my NAND flash

[rom1nux]

Hello,

I try to recover data from broken USB stick for a friend. It's the first time I try to do that.

The USB stick is build around PS2251-09-26 and a "noname" NAND.

Controller PS2251-09-26 seem completely broken so I unsold carrefully the NAND

stick3.png (71.16 KiB) Viewed 12295 times

And I build a "Poor Man NAND Reader" with a TSOP48 adapter, a NUCLEO board and some dupont wires...
(I add a FT232H breakout to increase serial output speed).

I write a peace of code to download data on PC from serial port.

I'm able to get "JEDEC" ID and the device ID from the NAND "0x983AA4937A51".
This seem to be a TOSHIBA like NAND
I don't find the datasheet for this NAND but I find some characteristics from the "TC58TEG6DDKTA00-Toshiba" datasheets.

Here is the supposed caraceristics of the NAND Flash

Code:

#define NAND_SIZE_KB        (16*1024*1024)                // 16777216 KB
#define BLOC_SIZE_KB        (4*1024)                      // 4096 KB
#define BLOC_SIZE_BYTE      (BLOC_SIZE_KB*1024)           // 4194304 B
#define PAGE_SIZE_KB        (16)                          // 16 KB
#define PAGE_SIZE_BYTE      (PAGE_SIZE_KB*1024)           // 16384 B
#define BLOC_COUNT          (NAND_SIZE_KB/BLOC_SIZE_KB)   // 4096 BLOCKS
#define PAGE_PER_BLOC       (BLOC_SIZE_KB/PAGE_SIZE_KB)   // 256 PAGES


[ddrecovery]

You will not be able to recover data from the NAND without professional data recovery software. The NAND uses ECC and XOR (which is basically encryption). However I do like the way you have read the chip, bou can get pretty much the same information by plugging the USB drive into a PC and using a free app called Chip Genius.

Did you check the PCB fully for shorts or failed components before removing the NAND?

[rom1nux]

Hello ddrecovery,
Thanks for reply, I'm not finish my post because of technical problem. Yes I understand it's pretty hard to recover data but I want to try because my friend don't have money and professional solution are out of bound here.
Yes I take a lot of time to check hardware problem and try to recover the PS2251-09-26 before removing NAND but USB controller it seem cooked.

[rom1nux]

I'm able to download all the blocks

I write a small code to concat some block and add BMP header (I concat only 8 block because of the limitation of the bmp size)

Now I can use the Windows image viewer to quickly navigate into NAND blocks or GIMP for pixel (offset) measurement

I'm able to find some header, LBN and LPN and some thing look like flags "0x01FF".

I can get the boundary of all area of the pages

Code:

...
      25 : H1=0x0038 LBN=0x7467 LPN=0x0019 ?=0x01FF H2=0x0038 H3=0x0038 H4=0x0038 H5=0x0038 H6=0x0038 H7=0x0038 H8=0x0038 H9=0x0038 H10=0x0038 H11=0x0038 H12=0x0038 H13=0x0038 H14=0x0038
      26 : H1=0x0038 LBN=0x746B LPN=0x001A ?=0x01FF H2=0x0038 H3=0x0038 H4=0x0038 H5=0x0038 H6=0x0038 H7=0x0038 H8=0x0038 H9=0x0038 H10=0x0038 H11=0x0038 H12=0x0038 H13=0x0038 H14=0x0038
      27 : H1=0x0038 LBN=0x746F LPN=0x001B ?=0x01FF H2=0x0038 H3=0x003C H4=0x0038 H5=0x0038 H6=0x8038 H7=0x0038 H8=0x0038 H9=0x0038 H10=0x0238 H11=0x0038 H12=0x0038 H13=0x0038 H14=0x0038
      28 : H1=0x0038 LBN=0x7473 LPN=0x001C ?=0x01FF H2=0x0038 H3=0x0038 H4=0x0038 H5=0x0038 H6=0x0038 H7=0x0038 H8=0x0038 H9=0x0038 H10=0x0038 H11=0x0038 H12=0x0038 H13=0x0038 H14=0x0038
      29 : H1=0x0038 LBN=0x7477 LPN=0x001D ?=0x01FF H2=0x0038 H3=0x0038 H4=0x0038 H5=0x0038 H6=0x0038 H7=0x0038 H8=0x0038 H9=0x0038 H10=0x0038 H11=0x0038 H12=0x0038 H13=0x0038 H14=0x0038
...


With the header Hx and LBN I'm able to get the full logical block number I think

[rom1nux]

When I take look on the bitmap representation I found different type of blocks
I'm not sure what kind of block/data it is.

Some scrambled/noisy block : XORED DATA ?

Some recurrent pattern block : 0 XOR KEY ?

Some unscrambled bloc : BLOCK TABLE ?

I really don't know what are thoses unscrambled information

[rom1nux]

I begin to document the format of page

I write a small code to extract and filter the 15 data areas of each page without the header and 78 bytes (ECC ?), I take look on a block with visible repetitive pattern

I can see the repetitive pattern (the key ?) is shifted left of 1024 bytes at every pages

For instance I'm not sure about key length... but I think it's page size (15336 Bytes) but visualy it seem to be 1024 Bytes...

[arvika]

XOR block usually start from 9A9EF0 at this model, but start from correct ECC. Wihtout it all data will be broken and all your work will be useless.

[rom1nux]

Hello Arvika,

Many many thanks for the key start, that what I found, I found the shifting rate too. Big THANKS thanks for confirmation this help me a lot.
I thought that ECC data was not scrambled by XOR key, so XOR key is "round robin" shifted applied on all datas parts (1024 bytes) of a page except on "headers/LBN/LPN" (8+(13x2)=34 bytes) and "ECC" (13x78=1014 bytes). Did you confirm that ?
In other words:
Did you confirm ECC (78 bytes) areas are not XORed ?
Does ECC (78 bytes) is applied on scrambled data or unscrambled data (1024 bytes) ?

Subsidiary question, I got 14 areas of 1024 bytes with "ECC like area" (78 bytes) + 1 area of 1000 bytes without "ECC like area" per pages. I don't know what is the purpose of this last 1000 bytes area ? I don't know if this area is XORed too...
Can you enlighten me about this area ?

My idea is to :

1. Extract the potential key on several "repetitive patterns" pages/blocks (taking account shifting, so I get all key starting with 0x9A9EF0)
2. Compute statistics for each (dirty) bytes of the keys
3. Create a temporary/partial key with the most probable bytes (higher occurence)
4. Do a first pass with the temporary/partial key to find a known pattern (like FAT32 header, filename or directory name in directory entry, etc...)
5. Try to manually correct the known pattern
6. Use this pattern to brut force the associated ECC algorithm parameters

Do you think it's a good way to find ECC parameters ?

Thanks in advance for your immeasurable help, i think I enter in the hardest part...

[arvika]

Probably it is your case: http://flash-extractor.com/library/PS/P ... a4_93__1x1
If yes, first sector should be 1110, rest 1104 bytes. Usually for this Phison controllers only data is XORed, SA and ECC not.
ECC for this controller use BCH algorithm and should work on source (unXORed) dump as I remeber.

[rom1nux]

Many thank for your help Arvika, I will try BCH ECC on unXORed data area.

[pepe]

there seem to be a couple of errors in the above.
page size is surely not 16384 bytes. The page should fit an integer power of 2 sectors (512 bytes), so 14*1024 + ECC is not enough.
Try setting the read page size to 20KB and check where the page actually ends. (usually FFs are read beyond the end of the page).
in your case it should accomodate like 16 1K sectors plus ECC plus SA.

pepe

[rom1nux]

It did not come to my mind I don't read the real size of page... I stuck on datasheet info I found from device ID....
Many big THANKS pepe to point this, I will try...

[rom1nux]

Ok pepe, you are right, i'm not read the entire pages...
I do a quick test and I receive that at end of pages.

Code:

Last sector of data         1024 B
The delimiter/header           2 B
The missing area (ECC?)       78 B
A full of 0xFF area           90 B
The rest of 20KB is 0x00


Code:

                       SIZE OF PAGE
Without 0xFF area   141360 px    17670 B
With 0xFF area      142080 px    17760 B


Pfff... I need to re-read all my NAND...
I will take this opportunity to optimize my power supply filtering and level...

Another big THANKS pepe, this help me a lot.

[rom1nux]

Ok, so this is the true page structure of my NAND for instance

[pepe]

looks better

but still a long way to go...

pepe

[rom1nux]

Yes, "I have my nose in the handlebars" to don't think about looking forward behind the limits.
I understand it still a long way to go especially since I only spend a few minutes a day ...
Another thank you for your help.

[pepe]

But congrats for your reader, nice one ...
I also built mine back in 2005 or so. ECC and XOR were not players those days, i was able to reconstruct pretty good images from SLC memories.
Later i realized i am better with a commercial tool which makes life much easier - when the thing is supported of course
Also, with MLC and TLC ecc is a must, so it is netto cheaper to own a tool than developing these things from scratch.

pepe

[rom1nux]

I know, I ask for a quote for recovery and for two different bundled solutions but prices are high in both case, my friend don't have budget. She is a modest person without a lot of money with health problems, that what I try with my hand...

My reader is not very good in that state, if I had time, I will probably make a small PC to connect properly the TSOP48 adapter and the NUCLEO board, integrate the FT232H and a small adjustable power supply (0 .. 3V3) with good filtering.

For example when I read 3 times a block, sometimes I got some different read byte (just 1 bit is different essentially)

First I use the 3V3 of the NUCLEO and dont have any decoupling capacitor near the TSOP adapter, and I read that, lowering the power supply voltage of a NAND improve readability, I don't know if it's true.... I will try with my lab power supply...

[pepe]

supply voltage may affect data integrity but you can't really decide what's good and what's wrong without calculating ecc.
Reading same value several times does not mean it is good.

pepe

[ddrecovery]

I read that, lowering the power supply voltage of a NAND improve readability, I don't know if it's true.... I will try with my lab power supply...

Heating or cooling the chip can also make a difference.