|Home Recent Work Science Fair About Me Contact Me Software|
Sony BDP-S390 Firmware
Warning: if you build custom firmware using these instructions, make sure the SquashFS file is the same size so the offsets do not change. There is a detail I missed in the analysis of the format, that caused the bootloader to fail when this was not the case.
Recent updates: 11/03/2014: updated REsquash and REsquash2. Now the user can be prompted when a file has been modified from the original squashfs file. Now also allows files to be inserted and deleted. Normal unsquashfs and mksquashfs should be safe - this just helps to ensure that nothing got modified unintentionally.
Any patches described on this page are out of date and should not be used. This is now just an overview of the process to extract and regenerate firmware. For specific patches, please see here.
The original firmware files, can be downloaded from: http://www.mmnt.net/db/0/1/ftp.vaio-link.com/PUB/HAV/BDP/FW/. UPDATA_M11R0369 was used, but this code should also be compatible with other versions.
Extracting this downloaded file gives:
Usage to decode the input file is:
And to encode a file is:
It can now be seen that MSB11-FW.ID contains the initial part of, and checksum information for, MSB11-FW.BIN.
BINARY FILE HEADER
The intial header contains:
This is followed by 10 locations, beginning at 0xA0, containing a file offset (4B) and file length (4B). For this version, they are as follows:
The DECODED checksum is calculated as the XOR of each 8-byte word in the ENCODED MSB11-FW.BIN. The following C++ code will calculate the checksum:
The actual file data begins at 0xF0. For purposes of analysis, the data at 0xF0 will be referred to as FILE_0, and data at 0x2000F0 will be referred to as FILE_4.
The following C++ code extracts these files:
FILE_0 appears to contain bootloader(s) and FILE_4 contains the main file system
The data in FILE_4 contains a Binary Information Table (BIT) and Partition Information Table (PIT).
PARTITION INFORMATION TABLE
The PIT begins with a Magic Number of 0x50495469 repeated 2 times and ends with 0x69544950 repeated 4 times.
The next 8 bytes after the first Magic Number are unknown. These are followed by PIT entries, each 32B long as follows:
Each PIT entry contains Additional PIT Info (my term, not Sony's) at the specified file offset. This data begins with 0x8530EADC repeated 2 times. Then has the following header:
Each element then contains:
Each partition also has a corresponding BIT, described below.
BINARY INFORMATION TABLE
The BIT begins with a Magic Number of 0x8530ABCD repeated 5 times and ends with 0x8530EFEF repeated 5 times.
Each entry of the BIT is 20B long as follows:
By looking at the data at each offset, the file type may be identified. For example, 0x73717368 is the Magic Number for a Squash File System, 0x474E5089 for a PNG image, 0x56190527 for a uImage file.
If data starts with Magic Number 0x0x8530AFBE repeated 2 times, it is Additional BIT Info, and has a header as follows:
Each element then contains:
The Checksum field begins with 0x53526F58 ("XoRS") and ends with 0x586F5253 ("SRoX"). It should be 4-bytes long, and contains the XOR of each 4-byte word in the file, not including this checksum field.
The Version field begins with 0x56655253 ("SReV") and ends with 0x53526556 ("VeRS"). It should be 4-bytes long, and contains the version of this file type (=0x2313).
The following C++ code extracts the SquashFS subfile(s) named squash_[partition ID] which contain most of the file system. It can be easily modified for extracting other file types as well:
And this C++ code displays information about the Sony file format, and checks for obvious errors such as partitions being too small or files overlapping on a partition:
As noted above, the main firmware is located in a Squash File System file (squash_17). This can be extracted simply by using unsquashfs on a Linux computer. To ensure a modified duplicate can be made as closely as possible to the original, however, a modified version of unsquashfs and mksquashfs was created. This modified version stores all the file information to another temporary file while extracting, and uses this temporary file as an input while resquashing. Thus, all the file attributes and link information are ensured to be exactly the same as the original. It's unclear if this step is actually necessary, but it was taken as a precaution.
Whether you use unsquashfs or the custom REsquashfs, you should now obtain the extracted files in the firmware.
C++ code for REsquashfs is as follows:
Usage for normal unsquashfs to unsquash the file is:
And for normal mksquashfs to make a new squash file is:
Similarly for the modified REsquashfs to unsquash the file is:
And for modified REsquashfs2 to recreate the new squash file is:
Files can now be modified as desired. The main program which runs while the Blu-Ray player is operating is /usr/local/bin/bdpprog. (patch removed due to risk of brick)
Now you have hopefully modified your files and recreated the Squash File System described above.
The next step is to re-insert the Squash File System in the Sony file format (FILE_4). The file format has been described above. C++ code for inserting a subfile is as follows:
This is based on the parsesonyformat.cpp above. Usage is:
insertsubfile squash_17_mod 3079712 FILE_4 FILE_4_MOD
The modified FILE_4 can then be re-inserted into the binary file MSB11-FW.BIN.dec
The following C++ code will insert this file and modify any offsets as necessary:
insertfile MSB11-FW.BIN.dec 4 FILE_4_MOD MSB11-FW_MOD.BIN.dec
CHANGING DATE AND VERSION
An update cannot take place unless the date and version listed are newer than the current version in the Blu-Ray player. To modify these values in the .BIN file, they can be done by hand with a hex editor, or the following C++ code can be used:
Usage to change the subversion is:
modversion MSB11-FW_MOD.BIN.dec V M11.R.0370
And to change the date:
modversion MSB11-FW_MOD.BIN.dec D 2012051100
The above changes should allow an update to take place from M11.R.0369 to the modified version of itself. It will still, however, identify itself as 0369 since this is hardcoded in bdpprog.
The modified MSP11-FW_MOD.BIN.dec can be re-encoded by using:
The .ID file must now be re-created. This contains the first 0xA0 bytes of the .BIN file, and has the checksum filled in. The following C++ code will re-create the .ID.dec (DECODED ID) file:
Usage to create the .ID file is:
genid MSB11-FW.BIN MSB11-FW_MOD.BIN.dec MSB11-FW_MOD.ID.dec
The modified MSP11-FW_MOD.ID.dec can be re-encoded by using:
Now the firmware is ready to be updated into your Blu-Ray player (AT YOUR OWN RISK!!!)
BASH FILE PROCESS
These steps have been automated in bash files as follows:
Downgrading is disallowed by the Blu-Ray player, but should be possible as follows. This could possibly allow recovery from an unsuccessful upgrade:
Downgrading has been successfully tested. That's all I can confirm. Modifying firmware is risky, may violate EULA agreements, and can potentially brick your Blu-Ray player. Please try this at your own risk!
Copyright © 2013-2014 Malcolm Stagg