Home    Recent Work    Science Fair    About Me    Contact Me    Software

project bdp

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: UPDATA_M11R0369 was used, but this code should also be compatible with other versions.

Extracting this downloaded file gives:

  • MSB11-FW.ID
  • MSB11-FW.BIN
These files are not human-readable, but a little research shows that Sony uses a simple ASCII substitution. The following C++ code performs the decoding/encoding:

Usage to decode the input file is:
lut D MSB11-FW.ID hex_substitution_01 MSB11-FW.ID.dec

And to encode a file is:
lut E MSB11-FW.ID.dec hex_substitution_01 MSB11-FW.ID.enc

It can now be seen that MSB11-FW.ID contains the initial part of, and checksum information for, MSB11-FW.BIN.


The intial header contains:
0x000x10Main Version ("MSB11")
0x100x10Subversion ("M11.R.0369") R appears to mean "release"
0x200x10Date ("2012051000") = 2012/05/10 00:??:??
0x300x08Unknown - Bootloader? ("JN1700")
0x380x08Unknown - Bootloader? ("JP1700")
0x400x10Unknown - zeros
0x500x04Unknown (04 00 00 00)
0x540x08Placeholder for Checksum - zeros in .BIN, checksum in .ID
0x5C0x04Binary File Size (0x0630E560)
0x600x10Unknown - zeros
0x700x10IFCON Version (0b0215)
0x800x10Unknown (00 00 1A 00 00 00 00 00 00 00 1A 00 00 00 00 00)
0x900x10Microbe Version ("0002")

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:
AddressOffset (4B)Length (4B)
0xA00xF00x200000 (FILE_0)
0xC00x2000F00x0610E470 (FILE_4)

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:

Usage is:
chksum MSB11-FW.BIN 8 0

Where 8 is the size of a word, and 0 is the file offset


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:

Usage is:
extractfiles MSB11-FW.BIN.dec

In this case FILE_0 and FILE_4 will be created.

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).


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:
0x04NAND Location
0x04Binary File Offset for Additional PIT Info
0x04Binary File Size for Additional PIT Info
0x04Binary File Offset for BIT Table
0x04Binary File Size for BIT Table
0x04Unknown (zero)
0x04Unknown (zero)

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:
0x04Element SIZE
0x04Number of Elements
SIZE-0x10Unknown (zero)

Each element then contains:
0x10Partition Name (string)
0x04Partition ID
0x04NAND Location
0x04NAND Size
0x04Protection Information
SIZE-0x28Unknown (if present)

Each partition also has a corresponding BIT, described below.


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:
0x04Partition ID
0x04Binary File Offset
0x04Binary File Size
0x04Partition Offset
0x04Partition Type

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:
0x04Element SIZE
0x04Number of Elements
SIZE-0x18Unknown (zero)

Each element then contains:
0x10File Name (string)
0x04Partition ID
0x04Partition Offset
0x04Binary File Size
0x10Encryption Information
SIZE-0x30Unknown (if present)


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:

extractsubfiles FILE_4

In this case squash_17 and squash_20 will be created. squash_17 is larger and contains the main firmware. squash_20 is smaller, and appears to be used during firmware upgrades only.

parsesonyformat FILE_4

An output and error check will be displayed.


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:
unsquashfs -d extract squash_17

where extract is the extraction directory.

And for normal mksquashfs to make a new squash file is:
mksquashfs extract squash_17_mod

Similarly for the modified REsquashfs to unsquash the file is:
REsquashfs -d extract squash_17

And for modified REsquashfs2 to recreate the new squash file is:
REsquashfs2 extract squash_17_mod

refile.bin will be created by REsquashfs and used by REsquashfs2 containing file and link information. Note that files can only be modified with this method, not created or deleted. Creating and deleting is in theory possible, but will require some modifications.


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

Where 3079712 is the BINARY FILE OFFSET obtained of the Squash File System (squash_17), determined by running parsesonyformat. FILE_4_MOD will be created with the new squash_17_mod replacing the original squash_17, and other file offsets adjusted based on the size difference.


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:

Usage is:

insertfile MSB11-FW.BIN.dec 4 FILE_4_MOD MSB11-FW_MOD.BIN.dec

Where 4 is the file to modify (corresponding to FILE_4_MOD) and MSB11-FW_MOD.BIN.dec is the new modified decoded binary file.


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:
lut E MSB11-FW_MOD.BIN.dec hex_substitution_01 MSB11-FW.BIN

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 inputs are the encoded BIN file, decoded BIN file, and output is the new decoded ID file (MSB11-FW_MOD.ID.dec)

The modified MSP11-FW_MOD.ID.dec can be re-encoded by using:
lut E MSB11-FW_MOD.ID.dec hex_substitution_01 MSB11-FW.ID

Now the firmware is ready to be updated into your Blu-Ray player (AT YOUR OWN RISK!!!)


These steps have been automated in bash files as follows:

  • use g++ to compile each source file (lazy version of a makefile).
    Note that the modified mksquashfs has its own makefile which is needed to build REsquashfs independently. Executables must then be copied to the main directory.
    • decode the files in "input" directory
    • extract files from binary file
    • extract squash subfiles from FILE_4
    • unsquash squash_17
    • Apply changes to bdpprog
    • resquash squash_17_mod
    • use unsquash to view original and modified contents to compare
    • reinsert squash_17_mod into FILE_4_MOD (user must ensure location is correct with parsesonyformat)
    • reinsert FILE_4_MOD into MSB11-FW_MOD.BIN.dec
    • modify date and version of MSB11-FW_MOD.BIN.dec (user must set as needed based on current firmware)
    • reencode binary file and generate ID file in the "output" directory
  • (error checking):
    • reverse the steps of (ensure location and original version/date are again correct)
    • verify extracted squash_17 file is the same as the file which was inserted
    • verify extracted FILE_4 Sony format is valid
    • re-insert the original unmodified squash_17 in the output binary file to generate a temporary binary file
    • verify this temporary binary file is identical to the original input binary file


Downgrading is disallowed by the Blu-Ray player, but should be possible as follows. This could possibly allow recovery from an unsuccessful upgrade:

  • lut D MSB11-FW.ID hex_substitution_01 MSB11-FW.ID.dec
  • lut D MSB11-FW.BIN hex_substitution_01 MSB11-FW.BIN.dec
  • use modversion to change version AND date to trick it into thinking this is a newer version
  • lut E MSB11-FW.BIN.dec hex_substitution_01 MSB11-FW.BIN
  • genid MSB11-FW.BIN MSB11-FW.BIN.dec MSB11-FW.ID.dec
  • lut E MSB11-FW.ID.dec hex_substitution_01 MSB11-FW.ID

Detailed Downgrade Instructions


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