Thread: PS3 Firmware
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.
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 FF’s 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 A…then 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.
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)
few images of pal mobo
this is the mobo of ps3 pal :??
I have removed the bios chips from my PS3, and will post more information on them soon
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)
other hig res bd
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.
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:
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 ................
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
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
well very very nice sound