project bdp

Overview

The initrd partition is not easily extractable from the device firmware, possibly due to encryption. This makes running custom code at boot more of a challenge, but since we have access to all the contents of /bin, /sbin, /usr/local/bin, ... it's definitely not impossible. It does require a firmware modification though, so some risk is involved.

The "bdpprog" executable controls basically everything in the player. It runs shortly after the player boots, so this is a good target to modify. One simple way to get arbitrary code execution is to create a wrapper bash script for it, so that when the player executes bdpprog, it's really executing the bash script. The bash script can do anything you want it to, then execute the actual bdpprog (which has been renamed). In order to keep this change as small as possible, I'm causing it to execute a second bash script in nonvolatile memory. That script can be modified more easily without flashing the firmware.

Changes:

• Rename /usr/local/bin/bdpprog to /usr/local/bin/_bdpprog
• Create a bash script named /usr/local/bin/bdpprog containing:

/mnt/3rd_data/startup.sh
exec /usr/local/bin/_bdpprog "$@" > /tmp/bdpprog_output.txt
	

The > /tmp/bdpprog_output.txt is optional, but I found it handy to see the output of bdpprog for debugging other mods.

I created a bash script named /mnt/3rd_data/startup.sh using telnet to perform tasks at player boot. Although it's unlikely this script will execute multiple times in this case, it's good practice to make sure it only executes once. I did this by using a file named /tmp/pwned.txt as a lock. My contents of /mnt/3rd_data/startup.sh is as follows:

if [ ! -f /tmp/pwned.txt ]; then
    echo pwned > /tmp/pwned.txt

    #change the password
    echo root:admin | chpasswd
 
    #start telnet daemon
    telnetd &
 
    #start ftp daemon
    /mnt/3rd_data/busybox tcpsvd -vE 0.0.0.0 21 /mnt/3rd_data/busybox ftpd -w / &
 
    #anything else you want to do here....
    
fi
	

Note that to get the ftp daemon to work, I had to use a cross-compiler to compile busybox, since the version already on the player did not support ftp. I will detail this later.

Also, be very careful what you cause to execute in the bash script. At this point in the boot, USB drives, wifi, etc have not been loaded, so if something in your bash script hangs, it could brick the player. Checks such as "if [ -e ....filename.... ];" can help prevent bad things from happening in case a file it references inadvertantly gets deleted.

Conclusion

1. Extract the firmware files
2. Rename bdpprog, and create a script named bdpprog in the same location (or you can try using another executable)
3. Modify date & version to make the player think it is newer
4. Re-generate the firmware files
5. Burn to a CD and update your player
6. Use telnet to create a script named startup.sh in nonvolatile memory containing any commands you want to run at boot
7. Copy any other files your script needs to nonvolatile memory (e.g. ExecModify, busybox)

DISCLAIMER

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. Be careful what you run/change even when connecting to your player remotely. You can brick your player using Telnet. Please try this at your own risk!