Sponsored Links

Sponsored Links

Results 1 to 5 of 5



  1. #1
    Registered User HanSooloo's Avatar
    Join Date
    Mar 2007
    Posts
    33
    Sponsored Links

    Lightbulb PS3 NAND Analysis

    Sponsored Links
    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).
    To test these claims relative to the PS3 NAND contents; and see for myself, which blocks are marked as defective, I wrote a simple program that does a few things:
    • 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).
    Well, what do all of these tell us? Here is some editorial on it:
    • 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.
    Well, that's all for now. I will keep adding more as I come across more interesting news.

    May the Force be with You...
    Attached Images<br><br> Attached Images

    Attached Files Attached Files

  2. #2
    Registered User HanSooloo's Avatar
    Join Date
    Mar 2007
    Posts
    33
    Sponsored Links
    Sponsored Links
    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.
    Now, obviously, $ony did _not_ follow Samsung's advice on how to mark defective blocks. Otherwise, I would say they have been dumped a load of bad chips by Samsung .
    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.
    Keep checking back in for more interesting news as we discover them
    Attached Files Attached Files

  3. #3
    Registered User HanSooloo's Avatar
    Join Date
    Mar 2007
    Posts
    33
    Sponsored Links
    Sponsored Links
    Quote Originally Posted by NoxOm View Post
    Thank you Han..

    I was looking for the flashmgr.tar.gz.. And what do think about the block "non-0xFF value at Page:0x00, Column:0x400 OR Page:0x01, Column:0x400"?
    What about this location? Do you have something you want to add? Not to take it the wrong way, but please provide substantiating information when you post in the DEV forum.

    Thank you

  4. #4
    Senior Member GrandpaHomer's Avatar
    Join Date
    Apr 2005
    Posts
    1,316
    Quote Originally Posted by HanSooloo View Post
    Now, obviously, $ony did _not_ follow Samsung's advice on how to mark defective blocks.
    I was indeed thinking exactly the same but I would also expect that chips are "shipped" with all really faulty blocks already pre-marked by Samsung and then later on during the implementation by $ony (all??) other non-defective blocks are marked as defective too (to confuse / complicate the reverse engineering?).

    Quote Originally Posted by HanSooloo View Post
    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)
    OK - that's should be still within acceptable developer implementation. So - basically - there are no not used blocks not marked as defective present in the dumps, correct?

    Quote Originally Posted by HanSooloo View Post
    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.
    So in another words - all the blocks in both chips are ALWAYS marked as (Samsung)defective.

    Quote Originally Posted by HanSooloo View Post
    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.
    I suppose this patterns is NOT present in not used blocks? Then it would be simply $ony's proprietary implementation of used bocks.

    Also - are there any other data present in spare bytes area apart of those for 0x00 ones??
    Quote Originally Posted by HanSooloo View Post
    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.
    This contradicts a bit (unless I'm missing some aspect of your deductions) your other findings above. I would expect more that those spare bytes are marking for used blocks (indeed ONLY if you can confirm that that they're NOT present in unused / all 0xFF blocks).

    Sorry for "repeating" some of your finding just in another words - it helps me to make more clear picture of the whole situation.

  5. #5
    Registered User HanSooloo's Avatar
    Join Date
    Mar 2007
    Posts
    33
    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.
    I hope this helps.
    Attached Images<br><br> Attached Images


 

Sponsored Links

Tags for this Thread

Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News