Introduction

Most people are not aware of the changes they can make in everyday consumer electronics. I think I first became aware of the ability to hack electronics when I got my Apex 703 DVD player. I was really disliking some of the aspects of the Apex and was able to team up with Jockey. He did most of the hacking. I attempted to make it available to the larger public and added in my own tweaks, including changing the background color, the timeout before the screensaver came on, and even the screensaver logo itself.

I think the Furby was my second hack. I had found instructions online for taking it apart and my curiosity got the better of me. After a little bit of soldering, replaced the eeprom and confirmed my suspicions of what was stored there and how.

Next I hacked my Sony Clie PDA. I wanted to make the remote control better, so I figured out the format of the individual files. I made a program that would allow new skins and special codes. But as I was decoding the protocols, my Clie bit the dust. I was given another one a couple of years later, but I had lost interest mainly because of my next hacking adventure.

That was the JP1 remote. Although I did none of the research, I was able to benefit greatly from the work of other hackers. I now have a single remote that controls our 4 TVs, 2 DVD players, the 2 set top boxes, and the PS2. The All-In-Ones were great remotes and it was fun building my own interface cable. It made it possible to completely reconfigure the whole remote to control devices it was never programmed to do.

My next hacking attempt was on my Canon S30 camera. That was fun, although short lived. The Canon cameras had already been hacked and again I just piggybacked on already existing hacks. What worked for other cameras happened to work for mine, and in no time at all I was playing Tetris on my camera. But I couldn't get anybody excited about this breakthrough in the S30 forums. It held potential to improve the firmware, but I didn't really have any problems with the S30 and it was already customizable. So I discontinued working on it.

My latest attempt has been to hack my brand new ScreenPlay HD Pro 1 TB. It's a media player with LOTS of potential. So I thought I'd document the process this time in this blog.

First was finding out that it could be hacked. Just about any device can be hacked if you have the right tools. That is what made the ScreenPlay Pro so much funner to hack -- I didn't have to have any special tools. I haven't even had to take it apart.

I found my first entry into the system when I went to format the drive. Using XP, I found out there were some additional partitions. So I downloaded WinHex and tried to examine the "unknown" partitions. WinHex told me that the partitions were EXT3 partitions.

EXT3 partitions are used by Linux. So first I pulled down a product called Explore2FS for windows which let me view the contents of the two EXT3 partitions. It was plain to see the Linux operating system installed.

Traditionally, I don't use Linux. I'm familiar enough with it to be dangerous, but that's about it. So this is going to commit me to learning more Linux stuff (which is good, I've been wanting a reason to).

So each session, I did something different.

#1. When ScreenPlay Pro HD tried to navigate to another computer on the network, one that's protected with login passwords, it requests the login. By default, it gives Realtek_guest as the username and some obscured password. It would be really nice to setup a user account on the computer with the appropriate name/password so I don't have to enter those, because those are a real pain to enter with the remote. But what was the password? To find this out, I used WinHex and did a search through the partition for "Realtek_guest" figuring it would probably be in plain text. Sure enough, I found it and the accompanying password "Realtek_pw"

#2. What type of hard drive was in the device? I have to admit I don't recall where I got this from. I think I picked it up during a USB device scan in Linux. It's a Seagate Sata 3.0 gb/s ST 31000340AS Baracuda 7200.11 drive. Sweet! That'll make it easy to replace the internal hard drive if I need to after this thing goes out of warranty.

#3. The SPP uses httpd. That means it has a web server daemon in it. So what kind of web pages are there? Well, unfortunately there's only one web page: index.html which has a reference to cgi-bin/sum.cgi. However, there is another file in the cgi-bin directory: webtorrent.cgi. But I don't know how to use it just yet. This will be something to explore in the future. My suspicion is that it has something to do with the Divx support.

#4. How do I telnet into the system? What are the usernames and passwords? Since I had full access to view all files, I was able to look at the passwd file in the etc directory. After doing a google search, I found out that the encoded password would be inbetween the first and second colons just past the user name. You couldn't decode the password (one way encryption) but you could just blank it out. Well, turns out that the root, default, and nobody accounts were already blanked out, which means there isn't a password for those 3 accounts :)

#5. Once I telnet into the system, I quickly discovered I couldn't make any changes. The root is mounted Read Only, although the second partition is mounted as R/W and so is the main 920 GB partition. Telnet lets me copy some stuff from the NTFS drive to the second partition. But some of the things I wanted to change were in the RO first partition. So I downloaded the System Rescue CD (a bootable linux), mounted the partitions and was able to modify things from there. As this can be a very dangerous thing to do, the first thing I did was made image files of the two partitions using partimage (comes on the System Rescue CD). That will enable me to recover if I accidentally change something in the OS that breaks it. I stuck those files on my main computer.

#6. The smb.conf file defines how the SMB network filesystem operates. It includes everything necessary (and just commented out) to allow the attached USB device to be shared. So using vi, I modified the file to expose the attached USB device and confirmed that my changes worked. Look for [usbshare] near the bottom and it becomes obvious what you have to do.

#7. In the inetd.conf file, it identifies the configurations for the httpd and telnet. I wanted to make the web directory easily updatable so I could experiment around with the system and see what it could handle, without having to keep booting the System Rescue CD. Yes, I know, I could probably just set up a virtual machine and install Linux, and probably will someday. Anyway, I changed the web directory to point to the mounted NTFS drive, and copied the www stuff over to that drive. Now I can stay in windows, and modify the www stuff without having to worry about permissions (full permission are automatically granted) and without having to boot the system rescue cd.

#8. I found a firmware image file on the partition. This is dangerous territory. Screw that up and the drive won't even turn on. And depending on how they apply the firmware (it's probably stored in an eeprom), it could be permanently screwed up. So I'll play around with that later when I have a better understanding of what processor it's all compiled for (I'm guessing it's MIPS).

Well, it's now early in the morning, and I better get some sleep before my job starts. So I'll close off my posts for today. Hopefully I can get some more hacking time in later this week.