Hi folks,

Not sure where to start this topic, at FUN or R&D section, but there's more R&D than FUN in here, I believe.
Just want to shed a light here on some of the latest Flash technologies in pictures, from DR point of view.
This is Scrambler (so-called "XOR key") of the latest Phison controller PS2251-68-5 on the picture.



Beginning from PS2251-65-x series Phison has changed Scrambler scheme, now period of key is not equal to page like it was before.
In this particular example the period of key is 7680b when data area of page is 8192b (period is floating).
It brings more mess into user's data and suppose to PROTECT it better in TLC memory cells.
Ohh really? Why then we see high number of bit errors??? (small contaminations in structure, dots).



The chip was unsoldered without overheating. Most of errors could be fixed with ECC.
If your extracted XOR key contains bit errors its usage is useless because it corrupts all blocks with data.

_________________
VISUAL NAND RECONSTRUCTOR. A big revolution in chip-off data recovery

Have to disagree, the FUN factor is just as high!!

This is very interesting work.

I am also looking at Phisons controllers. last night I was looking at some information of the Phison PS2303 (PS2251-03-Q) memory map:



I was wondering if the actual XOR block was stored in one of the unknown memory location. Not real sure how it all works yet. Was hoping to do some more research tonight but got a 1500KM drive to do taking next 2 days up.

job was rescheduled so back to some playing around with Phison controllers.

Here is the contents of RAM 0x0 - 0x10000 (64K) from 3 of my research drives.

- R223 - Phison PS2251-03-V Kingston DataTraveler DT111 8GB


- R237 - Phison PS2251-03-Q Kingston DataTraveler DT100 G3 8GB


- R237 - Phison PS2251-03-Q TDK 8GB

It turns to be interesting research.
I found out that PS2251-03-V you're analyzing has same key period as PS2251-68-5 and pretty similar XOR pattern generation scheme, look at the picture. I'm sure PS2251-03-Q is similar.

This is scrambling pattern (XOR key) of PS2251-03-V


From this we can assume that the scrambler (polynom generation scheme) could be same or very similar, just different settings or initial values. So there must be place in code which is same in both PS2251-03-Q and little bit different in PS2251-03-V.

XOR key of PS2251-03-V is attached.

_________________
VISUAL NAND RECONSTRUCTOR. A big revolution in chip-off data recovery

I bet people are finding this look into the previously mysterious world of flash drives quite interesting. It is so refreshing and exciting to see the work Sasha and his company is doing!

I just heard of a talk at Black Hat where Karsten Knoll will present some work on modifying flash drive firmware. If it is anywhere near as cool as the smartcard research then definately one to watch out for

Probably some people are wondering why vendors go to the trouble of applying XOR to DATA... Is it to obfuscate their Intellectual Property? No not usually.

Joshua explains it way better than I can, so go to his site and read the whole thing
http://joshuawise.com/projects/ndfslave


This page is a fantastic write up of finding a XOR key and ales about ECC.

I hope more people can start to get involved in discovering new secrets of these little bundles of joy

Great article of Joshua, especially explanation of ECC is good for people who not involved.
Error correction algorithms (nowadays is BCH) have one of a key roles in Flash recovery, because TLC chips are to weak to store data patterns (user's data has looot of patterns).
Even scrambling/randomization doesn't help much as you can see from the first picture in this topic. But ECC does.
On the newest devices 1024b sector protected by 120b (and more) of ECC code, which means >10% of entire capacity.

Here samples of data block (xor block) before ECC correction and after ECC correction.
Every dot-comtamination means 1 bit corruption, that leads to 1 byte corruption. Sometimes 1 byte corruption leads to 1 file corruption.
If this bit is corrupted in Boot/Root sector...well you can imagine what happens...

Before correction (ECC OFF)


After correction (ECC ON)


There's one cool experiment about consequences of bit errors.
Get any JPEG file.
Open in hex.
Change any 3 bytes this way:
4B --> 4C; 13-->14; FF-->EF (use any bytes, just add +1)
Save , then open file in photo viewer.

_________________
VISUAL NAND RECONSTRUCTOR. A big revolution in chip-off data recovery

New portion of NAND stuff in pictures

As many of us know, in NAND chips the smallest data unit is PAGE (similar to hdd's sector).
The page stores sectors of data (Data area) and additional service info (Spare area).
Long time ago there was one standard and simple page size = 528 bytes.
It wasn't big deal to figure out page structure 528b = 512b + 16b (D512/S16), one page stores one 512b Data sector and 16b Spare area.
But time has changed and now page size and structure can be very different, from 2112b to 27648b (TLC-WL Sandisk and others).
So how did they (vendors) use page space? How many sectors there? Where's Data area? Where's Spare, ECC, Block number areas? What's size of Spare area? How many bytes ECC code has, etc, etc...
How to extract data if we dont even know where data is?
Page structure analysis is one of the biggest and most important questions, because until you understand page structure there's just nothing to do with NAND physical image (dump).
Data visualization does a great job when it comes to analysis, especially binary look of data - BITMAP VIEWER. Especially when you can set different colours to different areas.
Here's a look of some random blocks from one old memory chip with page size 2112b (there's no scrambling (XOR)).
Not scrambled/crypted data has lot of patterns.



Here data is shown like you look through microscope on NAND memory cells: horizontal line is page, vertically - blocks (normally one block = 64/128/256/512 pages/lines).
One pixel = one bit (0/1).
Coloured pixel = 1, white pixel = 0.
1 byte = 8 bits = 8 pixels. (horizontally)

Look at horizontal lines. There are lot of patterns.
There's one continious, horizontal pattern, that's interrupted for some bytes then starts again. It is data pattern. These are Data areas. There's vertical pattern between them - Spare area.



The whole page structure is shown on the picture above (right side - page structure) - blue areas are Data areas, red areas are Spare areas.
Data areas always have horizontal patterns within pages (if not scrambled/crypted). Spare area always has vertical patterns within blocks.

Spare area also has vertical patterns inside, that help to understand function of every byte that controller assigned.



The biggest part of Spare area used to store ECC code. ECC code always looks like garbage. Look at yellow area. There's no any visual patterns.
The red area belongs to logical block number (LBN). Every block has unique number. Every page of one block has same number. So we can see that vertical pattern is changed from block to block.
The blue area here belongs to Block header. It's not obvious here, however it 's not changed so often like LBN. Every type of block has own header (main blocks, replacemrnt blocks, log blocks, FW blocks, translation table blocks, bad blocks, etc).

All these measurments and structure determinations done using "selection markers" of Bitmap mode - vertical and horizontal tapes.
Block size = 256 vertical lines (= 256 pages);
Spare area = 128 horizontal pixels (= 128 bits = 16 bytes).



Next time will show here Scrambler (XOR) patterns and how to detect Data area and Spare area when data is not data but scrambled garbage (garbage also can look different! ).

_________________
VISUAL NAND RECONSTRUCTOR. A big revolution in chip-off data recovery

Thank you for explaining the diagrams. I just read over them a few times (once is not enough!!) and it strikes me how powerful visual analysis is. You can stare at HEX for hours and it can all start to play havoc with your mind. It wouldn't be long before you could just say, this looks like a PS2251-60-5, or SM3254.. and it would be correct.. it LOOKS like it.

I have one little thing I am not clear on, (and it could be because I spent half the night soldering monoliths, and got up after 3 hours sleep) bit this bit here:


Should it say "Block size = 256 vertical pixels(= 256 pages); " where each pixel is the start of a horizontal line that is a page?


I saw some research and demos by Greg Hoglund that used to run rootkit.com. It was looking at malware in a different way.. visualising the whole system, actions, interactions and stripping out or grouping known actions such as mouse clicks, uninteresting routines etc. simply incredible to see what can be achieved. really beats days in IDA and immunity debugger.. People should at least watch the talk.. actually a few other talks are good such as hacking WoW game.

Looking forward to the XOR posts

Great work Sasha and team, really fantastic stuff!!

HaQue, sometimes Bitmap also playing with your mind and eyes so you feel sick after 2-3 hrs analysis

Yes, you may say "Block size = 256 vertical pixels(= 256 pages); ", but you have to change formula then this way:
Block size = 256 v.pixels x Page size; where page size = one horizontal line (height = 1 pix)
In this particular case with old chip:

Block size = 256 x 16896bits = 256 x 2112bytes = 540672 bytes (0x84000 bytes).

_________________
VISUAL NAND RECONSTRUCTOR. A big revolution in chip-off data recovery