Sponsored Links

Sponsored Links

Page 1 of 2 12 LastLast
Results 1 to 10 of 11



Thread: PS3 Firmware

  1. #1
    Contributor naturesbane's Avatar
    Join Date
    Jul 2006
    Posts
    26
    Sponsored Links

    PS3 Firmware

    Sponsored Links
    The PS3 system uses multiple flash memories, including flash devices on the system board (Samsung), BR disc drive (Spansion) and WiFi module on the 60GB version (Spansion). For pictures, I recommend searching for a PS3 game console basic tear down report.

    The PS3 system board includes two Samsung K9F1G08U0A 1Gbit SLC NAND Flash chips with one on the top of the board (Firmware A) and one on the bottom of the board (Firmware B).

    Theoretically, suppose a nice messenger delivered a raw dump of these two PS3 system firmwares to you.

    Clearly, one would notice that the firmware is encrypted. The almost uniform distribution of byte hex codes, except for "FF", is an indicator.

    What is a viable first step?

    First, you have two firmware devices. The first step would be too unify the firmware into a single image (file). But, how do you merge? Do all of the contents from one flash device follow the contents of the other flash device? Or, do the devices hold interleaved/multiplexed information? Which information goes first, start reading with A or B?

    This thread states my hypothesis for merging the firmware contents.

    My first assumption is that the contents are interleaved. Flash memory has a strong benefit of being non-volatile; however, the architecture also is relatively slow on reads and, especially, writes (& erases.) The information is often stored in sectors for easier erases. From a performance perspective, using the two x8 devices at the same time and reading/storing multiplexed data on the devices makes sense from a performance perspective.

    However, how are the devices interleaved? Do you read 1 bit A then 1 bit B? or a byte then a byte? or a word then word? or multiple words in a row?

    My second assumption is that you would either read a byte, word or multiple words in a row. Flash often writes in bytes, such as this software function: write(byte[] data, int startindex, int length, int sector). In fact, if one did a File->Unify->Bytewise in WinHex, it may appear to work well...the information aligns at each sector. However, their is one issue. At the end of some of the segments of information, about 960 bytes of information will be oddly multiplexed with blank "FF" byte hex codes. However, this misstep highlights important clues that may result in a properly unified image. In particular, a clue as to what file starts with information first and a clue to the files structure.

    My last assumption is based on the fact that these Samsung devices are page mode flash, which benefit on read/write operation speed by acting on multiple bytes of information in the same "memory page" during the same series of read/write operations. In particular, according to the Samsung datasheets, working with 2 to 2112 bytes at a time. My assumption is that the high-performance system wants data fast and that it is streaming more than a byte or word from/to each flash at a time.

    I believe that the 960 byte mismatch provides the clue to the stream length, which is 960 bytes. Secondly, the pattern one views indicates that the bottom flash B may be the first one in the series.

    To illustrate,
    AA = a byte hex code from firmware A other than FF
    BB = a byte hex code from firmware B other than FF
    FF = byte hex code FF from either firmware

    Bytewise Unified (simplified example using optimal stream size of a 4 byte word length)

    AABBAABBAABBAABBFFBBFFBBFFFFFFFF  why did FFs occur before more valid data?

    BBAABBAABBAABBAABBFFBBFFFFFFFFFF <- this at least has a more reasonable BBFF pattern

    Wordwise Unified (simplified example using optimal stream size of a 4 byte word length)

    BBBBAAAABBBBAAAABBBBFFFFFFFFFFFF - this seems most logical as you receive a single stream of data

    Extract that concept to a pattern of 960 bytes of B, then 960 bytes of A, then 960 bytes of B, then 960 bytes of Athen these two firmware images multiplex together nicely.

    While I may be incorrect, my theory is that a 960 byte interleaved structure is how information is read/written for the vast majority of the memory space of the flash memory chips. The firmware on the bottom of the system board is the first in the series.

  2. #2
    Junior Member hacked2123's Avatar
    Join Date
    Nov 2006
    Posts
    665
    Sponsored Links
    Sponsored Links
    Beautifully put. I am sure these files can be found for those who might also offer some insight for the topic. I just hope multiple raw dumps can be obtained from the multitude of firmwares for cross comparisons and the relativism's to the PUP file and it's contents, particularly the 200MB 1.02 pup. (All updates proceeding this update are about 98MB, the size you would expect for 1 of the NAND dumps)

  3. #3
    Contributor courier's Avatar
    Join Date
    May 2005
    Posts
    14
    Sponsored Links

    PS3 Square Button few images of pal mobo

    Sponsored Links
    this is the mobo of ps3 pal :??
    Attached Thumbnails<br><br> Attached Thumbnails

    1.JPG   2.JPG   3.JPG   4.JPG   5.JPG  


  4. #4
    Toucan Sam CJPC's Avatar
    Join Date
    Apr 2005
    Posts
    2,174
    Quote Originally Posted by hacked2123 View Post
    Beautifully put. I am sure these files can be found for those who might also offer some insight for the topic. I just hope multiple raw dumps can be obtained from the multitude of firmwares for cross comparisons and the relativism's to the PUP file and it's contents, particularly the 200MB 1.02 pup. (All updates proceeding this update are about 98MB, the size you would expect for 1 of the NAND dumps)
    If I recall, the 200mb 1.02 pup was the ~90mb update, + another 100mb or so of blank space!

  5. #5
    Contributor courier's Avatar
    Join Date
    May 2005
    Posts
    14
    I have removed the bios chips from my PS3, and will post more information on them soon

    Dump Sizes:

    PS3 BiOS Flash1 Bottom (138,412,032 bytes)
    PS3 BiOS Flash2 Top (138,412,032 bytes)
    PS3 Blu-ray DVD MX25L1005 Chip1 (131,072 bytes)
    Attached Thumbnails<br><br> Attached Thumbnails

    Hpim0368.jpg   Hpim0374.jpg   Hpim0375.jpg   Hpim0376.jpg   Hpim0377.jpg  

    Hpim0378.jpg   Hpim0383.jpg   Hpim0385.jpg   Hpim0387.jpg   Hpim0389.jpg  


  6. #6
    Contributor courier's Avatar
    Join Date
    May 2005
    Posts
    14
    other hig res bd
    Attached Thumbnails<br><br> Attached Thumbnails

    PICT0001.JPG   PICT0003.JPG   PICT0004.JPG   PICT0005.JPG  

  7. #7
    Contributor naturesbane's Avatar
    Join Date
    Jul 2006
    Posts
    26

    FIU v0.1.1

    The attached Firmware Interleave Utility (FIU) is a DOS console application intended to unify or disect certain page mode firmware files.

    V0.1.1 functionality is limited to unifying equal size page mode flash firmware files with an assumed maximum byte interleave count of 2112 bytes. For example, K9F1G08X0A or similar flash devices.

    The readme has more detail. I recommend trying an interleave_byte_count of 512. For example:

    FIU -unify down_fw.bin up_fw.bin merged_fw.bin 512

    This example assumes that the files are in the same directory as the EXE file.
    Attached Files Attached Files

  8. #8
    Contributor StrontiumDog's Avatar
    Join Date
    Apr 2007
    Posts
    6
    I have managed to decode part of the firmware flash (the linux Other OS portion, so it isn't too exciting).

    For the interested, in my flash B I see:
    0x15e0000:

    015E0000 65 63 6C 6C 65 5F 74 78 6F 5F 5F 73 72 61 61 65 eclle_txo__sraae
    015E0010 00 00 01 00 00 00 02 00 00 00 04 00 FF FF FF FF ................
    015E0020 00 00 01 00 00 00 00 00 FF FF FF FF FF FF FF FF ................

    = cell_ext_os_area

    and 0x15e0400:
    015E0400 8B 1F 08 08 42 2F 45 E2 03 00 69 6C 75 6E 00 78 ....B/E...ilun.x
    015E0410 5C EC 54 0D E7 54 7E 99 B9 BF 0C FC 26 31 C2 63 \.T..T~.....&1.c

    =

    0x1F 0x8B 0x08 0x08 0x2F 0x42 0xE2 0x45 0x00 0x03 "linux" 0x00
    This would indicate the bytes are reversed in the dump and need also to be swapped as well as interleaved.

    Strontium Dog

  9. #9
    Banned User r3pek's Avatar
    Join Date
    Feb 2007
    Posts
    54
    that proves that ps3 is a "mixed endian" architecture. if this is true, all the firmware is arranged like that. for example: the word "abcd" is stored like in memory like "badc".

    more info can be read in this article: http://en.wikipedia.org/wiki/Little_endian

  10. #10
    Contributor courier's Avatar
    Join Date
    May 2005
    Posts
    14
    well very very nice sound

 

Sponsored Links
Page 1 of 2 12 LastLast

Tags for this Thread

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