Sony BDP S1200 Blu-ray/DVD player firmware

I purchased the Sony BDP-S1200 blu-ray/DVD player on special.  I need a region free DVD player, and there are none available within New Zealand.  It's possible to buy a universal remote, and to enter some codes and it's been reported to work - but it's claimed to work for firmware only for other regions.  There are reports of other models allowing you to put a shared library and a script on a USB key and to have it start the telnet daemon, but I don't have a router to connect the player to, via ethernet cable.

Malcolm Stagg has managed to modify the firmware for his S390, and provided detailed instructions.  I've downloaded five versions of the firmware.  Unlike the S390, which Malcolm has decryption scripts for, this is not encrypted with a simple substitution cipher.  It looks more like it has been XOR'd.

I've written a simple Python script to take what I assume the initial bytes to be, and look for the XOR key that matches in the rest of the file, hoping to find them over a sequence of null bytes.  But the longest match was four contiguous bytes in an unlikely location.

The five different firmware versions are (version numers are in the light coloured bar for first four):

• UPDATE_M19R0071.ZIP
• UPDATE_M19R0112.ZIP
• UPDATE_M19R0116.ZIP
• UPDATE_M19R0156.ZIP
• UPDATE_M19R0164.ZIP (bottom right).

If the first 16 bytes are a general null-terminated text version ('MSB19\0\0\0...') then this implies at least 16 bytes that may be located elsewhere in the file, should there be a long enough sequence of null bytes.

I've already run a Python script over what I guessed the initial 16 bytes to be, and longest matched sequence is 4 contiguous bytes.  It's possible that the embedded files which follow the header are compressed, but I doubt it.  It's also possible they used a different firmware version string format.  But given the pattern of red differences in the screenshot above, it looks like the header is almost the same to what Malcolm found,

• The 0x00 line is obviously still the firmware version, so will be something like 'MSB19\0\0\0\0...'
• The 0x10 line is obviously still the text version of the release.  The only difference is the changed numbers, i.e. one difference between 116 and 156 on the two releases in the upper right.
• The 0x20 line is the text release date.  I don't know the release dates, and expect they differ from the publication dates when the releases were made available for download.
• The 0x50 line differs where the checksum is supposed to be.
• The 0xC0 line is where Malcolm documents the size of the second embedded file.

In theory this gives large blocks of XOR'd zeros, which give XOR key sequences.  It should be possible to take the longest sequences and brute force them over the file to try and hopefully detect some readable strings and from that how long the repeat period should be.

So there's at least two things I can try before giving up:

• Look for substrings of the known XOR patterns where they've been applied to null bytes, instead of matching on the start of the known XOR key.  It is possible that 0x00 doesn't start with 'MSB19'.
• Apply the longest believed correct XOR key segments to the rest of the file stepping the application index by one byte.  Output any readable strings of decent length to a log and go through it later.

Anyway, if you're looking to reverse engineer this firmware, maybe you'll find this even if I don't get further. And if you've reverse engineered it already, maybe you'll add a comment or send me an email.  I do not live in the United States, in case you are reading this and thinking that the DMCA is relevant in any way.