Pre-prologue: Computer surgery
Long story short: the battery on my old Mac gave up the ghost in a relatively ugly way and I had to put a bit of effort for that ghost not to become a fire spirit. In one picture worth a thousand words, this is what happened:
Which meant that the only computer with a DVD drive was severely crippled, and I was getting fed up with hooking a computer to the TV whenever there was a "please Daddy may we watch..." So I decided to buy a simple standalone
DVD/Blu-ray player.
Prologue: DVD players and world travellers
The trouble was, I have lived on 2 continents in 5 different countries (at one time, simultaneously), and while doing so, a hodge-podge mini collection of DVDs from at least 3 different regions materialized on my living room shelf. While I fully understand the region mechanism so that a new blockbuster may hit the box offices at different times in different parts of the world, this protection kind of makes zero sense for titles (or worse, indies) released around the world long ago. Of course there's
VLC and
dvdlibcss but hey, this whole thing was done to spare the hassle of having to connect a computer to the TV to play a disc.
In other words, I needed a region freeing or region switching mechanism for my player. I researched some forums before buying, and it seemed that at least *some* players of this kind could play discs from around the world; also there were already "multi-region" players of this kind freely available for sale
on Amazon and
third-party websites (presumably with modified firmware), so I thought that it might be worth to try my luck as well.
Expectedly but disappointingly, the unit was not multi-region out of the box. None of the methods "off the internet" worked either. None of the
"magic" remote control codes. Some more in-depth sites suggested
burning a special CD-R to enter the "advanced settings mode", but this did not work for me at all (and people were writing in the forum that this CD-R method was good for any player except North American, which was my case). The forums even
mentioned that the only way was to physically get into the player by soldering some wires to its serial interface
(yikes: I am not that big a fan of soldering and my few circuits even tend to work better on a breadboard than in soldered form), so it seemed that I had to use the computer route for anything outside North America...
Entry route and initial troubleshooting
...or not? Further search got me to
a page mentioning what is called "the Pandora exploit". Here's the essence of it:
$ cat /mnt/rootfs_normal/usr/local/bin/pandora/pandora.sh
#!/bin/sh
#
(...)
if [ -e /mnt/sda1/PandoraApp ]; then
(...)
/mnt/sda1/PandoraApp -qws -display directfb
elif [ -e /mnt/sdb1/PandoraApp ]; then
(...)
/mnt/sdb1/PandoraApp -qws -display directfb
else
(...)
/usr/local/bin/pandora/PandoraApp -qws -display directfb
fi
What this means is that when the player is asked to launch the Pandora app (I had no idea what this was, at the time), the player looks for
PandoraApp executable in the following directories,
in that order:
/mnt/sda1/,
/mnt/sdb1/, and finally
/usr/local/bin/. Which is to say that if you put a shell script called
PandoraApp in the root folder of a USB stick, plug it into your player, and launch Pandora, it will execute that script instead of the app.
This was worth trying out. Pandora isn't available in Canada so there was no menu item to call it, but as soon as I changed the player's country to US, that menu item happily appeared in the Premium menu of the player (which holds all the "streaming app" capabilities). Provided the player was connected to the Internet (i.e. had wi-fi set up and running), I was able to get to a nice splash screen where I was
happily informed that, well, "Pandora isn't available in your country".
The exploit page mentioned setting up a reverse shell, but this seemed to me too complicated in a home network situation full of dynamic IPs and firewalls. Instead, what I put on the SD card was
ls > /mnt/sda1/check_a.txt; ls > /mnt/sdb1/check_b.txt;
This time, running Pandora resulted in the USB stick LED blinking once and then the player froze with a black screen, forcing me to do a hard reboot. The USB stick nicely contained the file
check_a.txt, holding root directory listing, and confirming that the drive was indeed mounting under
/mnt/sda1.
Next time, what I put on the drive was:
ls -alR > /mnt/sda1/dirlist ;
/usr/local/bin/pandora/PandoraApp -qws -display directfb;
The last line ensured that the Pandora app was launched after what I instructed the player to do, allowing me to return to the main menu and avoiding the need for a hard reset. After a few unsuccessful tries, I got a nice full listing of the player's file system.
The reason for "a few tries" turned out to be that I was accidentally using a defective USB drive which, due to its old age or/and compatibility issues, had a corrupted file system that took the player forever to list. So, kind of "bad luck". However, I had a compensating "good luck" that the first stick I tried ended up working - the newer ones did not, even the first script wasn't being executed at all, presumably because newer drives were mounted under some different path. Had I started with a non-working stick, I might well have thought that the exploit didn't work anymore, most likely got patched in the newer firmware, and would have given up any further tries... the lesson of this was not to give up and "throw it until it sticks" a few more times.
Analysis and solution
Okay, I have the full listing of the player's system, now what?
I spent some time carefully studying the listing, and after a few red herrings stumbled onto this:
./mnt/ubi_boot/var/local/acfg:
total 108
drwxr-xr-x 2 root root 232 Jun 1 2014 .
drwxr-xr-x 6 root root 424 Jan 1 1970 ..
-rw-r----- 1 root root 107677 Jun 1 2014 config_file.txt
So copying the file to the USB stick for investigation by doing
cp -f -v /mnt/ubi_boot/var/local/acfg/config_file.txt /mnt/sda1/ ;
/usr/local/bin/pandora/PandoraApp -qws -display directfb;
and opening the copied file in a hex viewer such as
hiew immediately gave me this;
Promising. Let us zoom in for a closer look:
Looking at the byte signature after each option, it seemed like the first non-zero byte marked something like the beginning of the data section (always
01); the second marked the length of the data (
01 for one byte,
02 for two bytes etc.), and finally the last byte stored the relevant information (e.g.
FF at
0x50C stands for 255 years Blu-ray age restriction).
At this point many would say "Got it!" and rush to change the bytes at
0x3E3 and maybe
0x408 from
01 to
00... well,
not so fast. Remember the exploit only works when you have a bootable player! The file is not encrypted, that much we
can see, but what if there is a checksum somewhere that needs to match with any edit of the file? A mismatch may, at best, trigger a factory reset, and at worst, brick the player. So I changed an option from the Settings screen, for example the above mentioned age restriction to, like, 128 years. Re-dump the file, and...
>fc /b config_file.txt config_file1.txt
Comparing files config_file1.txt and config_file.txt
0000050C: 80 FF
OK, we are safe at least on this front.
The modification of ..._BDAGE is needed for us to be able to visually confirm that the new file has taken effect; the modification of ..._REGIONFREE is just for good measure, I have no idea what it does. Store it as config_file_fix.txt, and do the following...
cp -f -v /mnt/ubi_boot/var/local/acfg/config_file.txt /mnt/sda1/config_file_pre.txt >/mnt/sda1/report.txt ;
cp -f -v /mnt/sda1/config_file_fix.txt /mnt/ubi_boot/var/local/acfg/config_file.txt >>/mnt/sda1/report.txt ;
cp -f -v /mnt/ubi_boot/var/local/acfg/config_file.txt /mnt/sda1/config_file_post.txt >>/mnt/sda1/report.txt ;
/usr/local/bin/pandora/PandoraApp -qws -display directfb;
... to find that it does not work, and the edits revert back upon player restart.
Well, after some more probing, reading, dumping, and more reading up on
UBI,
MTD and
NAND flash, it occurred to me that write-behind cache might have been playing tricks on me; after all, the system totally doesn't expect a file modification at this point. So I tried adding
/bin/sync after copying the file, hard-reset the player some time after the script executed, and it worked; looking at settings confirmed that the BD age restriction went down from 255 to 254 years.
I have to give you a "proceed at your own risk" warning here, for two unrelated reasons. First off, I have no idea how robust the player software is against false moves such as accidentally erasing yor config file entirely or messing up in any other way; having actually done sudo chmod -r / on my first Mac (followed by sudo chmod +r / ... what does it mean "sudo not found"?!?) I can say that it is entirely possible to brick your player this way, and there will be no way back unless you really want to (and can) do the soldering thing. The other reason is that media industry does not pat us on the back for reverse engineering their code because 9 times out of 10 people try this with some form of piracy in mind. Well that wasn't my motive whatsoever (since I already had quite a few ways to play all of my entirely legal discs), and it should not be your motive either. So, don't try this at home unless you really know what you are doing, and if you do, proceed at your own risk and treat it like I treated it -- as a troubleshooting challenge (which I love) along with a comfort improving thing (which I value).
