Thread: PS3 NAND Analysis
PS3 NAND Analysis
Instead of cluttering the existing Firmware analysis thread, I decided to open a new one; sepcifically focusing on the NAND chip contents.
This one is more related to how the data is stored (Data vs Spare bytes) and bad block information.
According to the Samsung specs:
- The chips are "guaranteed" to be defect free in Block:0x00. That means that you can trust to have that area of the chip be reliable for the life of the device.
- If a block is defective, it will be marked with a non-0xFF value at Page:0x00, Column:0x400 OR Page:0x01, Column:0x400.
- To READ and WRITE data from/to the device, you need to send 4 bytes (A0, A1, A2, A3) containing 10 bits of BlockNo, 6 bits of PageNo and 10 bits of ColumnNo (see the attached Samsung NAND Access.png).
- Removes the Out-of-Band data (or Spare bytes) from an input file, and writes the remaining data (Data bytes) to an output file
- Re-arranges the A0, A1, A2, A3 address bytes used to construct a NAND offset so that it is interpreted as A2, A3, A0, A1
- Identifies blocks that begin with 16 "0xFF"s (which can be considered as _unused_ NAND area), and looks at the 1st spare byte of PageNo: 0x00 and PageNo: 0x01 to see if these blocks are BAD BLOCKS. Results are written to a file in the form of a report (see the attached sample report).
- There are 64 bad blocks in one of the NAND chip images I have. That is _a lot_ for a device with 1024 blocks.
- The above wouldn't be as bad, if it weren't the fact that Block:0x00 is _also BAD_. The very block that Samsung says is guaranteed to be defect free.
- Why would a sane developer have the defect free block un-used (block0 is all FFs) AND mark it as DEFECTIVE?
- You would think, that the boot loader of a system would go to the one place on the NAND device that is guaranteed to be defect-free. But, then again, it would have made our life _too_ easy.
- Maybe $ony wants to fool the casual NAND analyst (is that even a position/job? ).
- Maybe the real defective map of the NAND chip is in some other place.
May the Force be with You...
Allright, minutes after my post, I found a silly bug that I had to correct. With that, I am attaching the updated package and the dumps from _both_ NAND images.
Few observations have to be changed in light of the updated program:
- In the 1st NAND image we have 512 bad blocks identified. That is _HALF_ the number of blocks in the device.
- In the 2nd NAND image we have 517 bad blocks identified. That is _MORE THAN HALF_ the number of blocks in the device.
However, other things have materialized before my eyes in the last few minutes between this post and the earlier:
- Whever a block is _not_ used; as in, it is filled with all 0xFFs, then this entire block is marked defective (Samsung terminology) or sce_nand_UnUsed ($ony terminology; I have just invented this one)
- Better yet, all the other blocks that have some sort of data in them _also_ seem to have this byte set to mark the block defective.
- Even though blocks with legitimate data also seem to have been marked as defective, there is an undeniable pattern that exists in the Spare Bytes area of each Page. Namesly Page Offsets 0x812, 0x820, 0x82E, and 0x83C are _always_ 0x00. I have no idea what this means, but it surely is a pattern.
- My theory at this point is that the NAND blocks are marked defective at Page Offset: 0x800 to signify that they do not contain any data. Maybe this is a method by which $ony keeps track of used vs. unused blocks.
Also - are there any other data present in spare bytes area apart of those for 0x00 ones??
Sorry for "repeating" some of your finding just in another words - it helps me to make more clear picture of the whole situation.
I understand why GranpaHomer got a little confused, as I read through the post with fresh eyes today. So, to illustrate what I saw as the pattern in both UNUSED and USED blocks, i drew some pictures:
- The first one is the UNUSED blocks' identifying picture. This is the 1st page (PageNo: 0x00) in the block. You will see that the first 2 bytes are 0x00 and 0xFF, followed up by all 0xFFs.
- The second one is the USED blocks' identifying picture. Again, this is the 1st page (PageNo: 0x00) in the block. You will see that, again, the first 2 bytes are 0x00 and 0xFF, followed up by some data (probably related to checksums). BUT, there are 0x00 bytes located at offsets 0x12, 0x20, 0x2E and 0x3C.