Recently, my friend brought to my attention a Blu-ray disc player, product name BX59 (a.k.a BDP-S590).

Let’s take a look at some of its features.

  1. It is a media player that supports various formats: Blu-ray, DVD, USB, you name it. It also supports one format I have never heard before: Super Audio CD.
  2. It can connect to Internet, with built-in wireless adapter and certainly browser. You should be surprised by now, because this device was released in 2012, around the time where Internet <insert applicant name here> is new on the market. If you know web, you must have known browser has tons of vulnerabilities. But that is the story for another time.
  3. Finally, it can detect DLNA media server. This BDP can look up any server in your LAN and connect to your collection of movies, music, etc.

My first instinct was to find open ports. Through Fing, I found port 50002, but my friend later did a nmap scan and also found 50001-50003. These ports might be for the media server feature. When I tried to curl, something interesting happens.

*   Trying 192.168.1.223:50002...
* Connected to 192.168.1.223 (192.168.1.223) port 50002
* using HTTP/1.x
> GET / HTTP/1.1
> Host: 192.168.1.223:50002
> User-Agent: curl/8.10.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< Connection: close
< Date: Mon, 18 Nov 2024 17:56:56 GMT
< Server: Linux/2.6 Sony-BDP/2.0
<
* abort upload
* shutting down connection #0

It responses back with HTTP response format. What’s more, it even identifies itself in the header. Linux 2.6 was first introduced in December 17, 2003 (21 years ago), and the very last Linux 2.6 release is 2.6.32.71 in March 2016 (that is still 8 years ago).

Instead of going blindly, how about we look at the firmware and search for openings? I noticed that Sony still have the update server online (+1 for long-term support). After downloading the latest firmware, we can extract the content (MSB12-FW.BIN and MSB12-FW.ID) and try binwalk on the biggest file:

Analyzed 1 file for 85 file signatures (187 magic patterns) in 727.0 milliseconds

Wait, the result is empty? If we plot the entropy:

With such low entropy, this does not look like encrypted at all, meaning they must have used some simple cipher. And my guess was right when I found Project BDP.

Turns out, this series of Blu-ray disc player likely shares source tree. Despite the blog post author, Malcolm Stagg, focuses on S390, the rest of the materials look the same. The firmware update we have contains both .BIN and .ID file. The file names are only different in number (11 vs. 12). And it is likely the file we saw above uses substitution cipher. Let’s try following the post and extracting the firmware.

.
├───bin
├───lib
├───res
├───sbin
└───usr
    ├───bin
    ├───browser
    ├───etc
    ├───include
    ├───lib
    ├───local
    │   ├───bin
    │   └───lib
    ├───sbin
    └───share
...

To my surprise, it works flawlessly. Let’s do readelf -A on binaries and see what they are compiled for:

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6Z"
  Tag_CPU_arch: v6KZ
  Tag_ARM_ISA_use: Yes
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6Z"
  Tag_CPU_arch: v6KZ
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_FP_arch: VFPv2
  Tag_ABI_PCS_GOT_use: direct
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: Deprecated
  Tag_Virtualization_use: TrustZone

The CPU speaks ARMv6KZ! Z here might stand for TrustZone. If you are a computer historian, I would love to hear the story of this whole name. Other than that, the CPU also supports Thumb ISA (Thumb-1) and hard-float (VFPv2). That seems solid for a processor from a long time ago.

Now, the blog posts from earlier also highlight a different special “feature”. When the browser is opened on S390, a script called browser.sh is executed. This script contains a line that the developer(!?) forgot to delete; that is, to load library at a specific location: /mnt/sda1/bbb/libSegFault.so. Here, because the player did not come with any disk, /mnt/sda1 is equivalent to the first plugged-in USB drive. Since there are no checks, we can put in place a dynamic library that will excute telnetd on load and open us a remote terminal.

I compared with the latest firmware for BX59, and realized it has the same “feature”. In other word, all we have to do is to compile binary for this platform, right? We will take a look at that next time.