Creating my own binary :)

What a wealth of information I came across today. I have to give credit to klootje for steering me in that direction.

http://rtd1261.wikidot.com/start

Apparently there are already devices out there that are very similar to this one, and hacks that support those devices.

First, I wanted to find out if some of the binaries on that site would work at all. So from the tweaks page, I copied the FTP binaries out there and set it up. It worked like a charm.

So I continued to explore through the page when I came across a link that was no longer valid on the site but it put me in the right location. This was on the linux page. But here is the critical link:

http://www.uclibc.org/downloads/binaries/

In there are the precompiled toolchains necessary for developing DIRECTLY ON THE DEVICE. The best way to do this:

Download the one called system-image-mipsel.tar.bz2 and extract the image-mipsel.ext2 file. I used WinRar. Put the .ext2 file on the root of the NTFS drive. Now telnet into the drive.

cd /tmp
mkdir root_fs
mount -o loop /usr/local/etc/hdd/volumes/HDD1/image-mipsel.ext2 root_fs

What that does is mount the image from your hard drive.

chroot /tmp/root_fs

Presto. Now you can write C programs, compile them and run them. They didn't have any success doing this with the other multimedia players, but this worked beautifully on the Iomega drive. I wrote the basic "hello world" program in C, compiled it, made it executable, exited the chroot, and ran it. It displayed exactly what I wanted.

Cntrl-d to exit the chroot, by the way. gcc is the C compiler in that environment.

A whole new world to explore now. I believe many of the things found on that wiki site are going to be almost immediately usable on this drive. I have blogged all I'm going to blog on this device for the time being, as it will be much more beneficial to log this information into the wiki.

An easier way

This didn't seem like a productive time while working on my ScreenPlay Pro.

I have found several other methods for modifying the contents of the first partition. But I'll spare you the story and give the simplest and easiest way, which is going to make it much easier for others to do.

TELNET into the drive using root as the username (no password)
mount -o remount /dev/root /

that's all. That remounts the root as a readable / writable drive.

So I created a couple of CGI scripts to make it easy to transfer stuff onto the drive. First, I created a www directory and a www\cgi-bin directory on the NTFS drive. Then I navigated to /tmp_orig/www/cgi-bin and using vi created a file called copyhere
Here's the contents:

#!/bin/sh

cp /usr/local/etc/dvdplayer/hdd/volumes/HDD1/www/* /tmp/www
cp /usr/local/etc/dvdplayer/hdd/volumes/HDD1/www/cgi-bin/* /tmp/www/cgi-bin
chmod 775 /tmp/www/cgi-bin/*


then I remounted the drive read-only using:

mount -o remount -o ro /dev/root /

and exited out of telnet.

What that enabled me to do is to place anything I want copied into the www and www/cgi-bin directories on the drive by simply putting them onto the NTFS partition from windows, then bringing up the browser and going to:
http://x.x.x.x/cgi-bin/copyhere
(replacing x.x.x.x with the IP address of the drive, of course) it automatically copies the contents to the www and cgi-bin directories and makes the cgi-bin stuff executable.

Now as I compile, I can add stuff to the drive easily. I also created another CGI script to allow me to execute a series of commands on the drive. That script is a little more complicated, because I made a full HTML form output with an input box to enter the commands in. The whole purpose of this is when my two computers are occupied, I can still hack into my screenplay pro using my Wii. It runs everything I enter as root.

Anyway, even though this is an easier way to do this, if you are just getting started I still heavily recommend making an image of the ext3 partitions before starting.

ScreenPlay Pro, more hacking

Explored around with the telnet a little bit. I have found it to be a very useful feature, since there are so many programs already on the drive for OS support.

MemTotal: 57664 KB
VmallocTotal: 1048560 KB

I found out that while the drive is playing files from another computer, it mounts the directory as a CIFS mount. Did not have any problems at all with it streaming a 2.5 GB over the Trendnet wireless adapter. So that eliminates CIFS from the picture (CIFS has already fixed the 2 GB bug anyway, so I'd have been surprised if that weren't the case).

The 2 GB file limit I'm running into appears to be related to Samba, specifically the SMBD program automatically launched from inetd.conf file. I found that if I try to browse to a directory on my drive using Windows XP, it cannot see any files > 2 GB. Supposedly the 2 GB problem was fixed in SMB a long time ago. So I'm wondering if the port they used hasn't been done right, or just never had the patch applied.

I ran into a problem with the DVR. It kept stopping with Bad Disc error, even though I know this drive doesn't have any bad sectors on it. This is speculation at this point, but it appears that when it is writing the info to the NTFS drive and it cannot do it contiguously (it has to create a fragment) then it bombs out. Once I got past all the "holes", it didn't stop while recording. I created some open holes in the sector map by deleting some files and immediately the problem came back. Just something else for me to watch for. I'm tempted to mount the drive as EXT3 so I won't have those kind of problems, but I'm not sure if SMB can expose an EXT3 drive.

Ive had something funny happen two times now while recording DVR. The screen suddenly goes blank and the player is unresponsive. The second time this happened, I had already telnet into the system. So what I found out is that it wasn't locked up. But apparently the DvdPlayer process terminated. I wasn't able to get the process restarted though.

Oh, something really fun I found. There's an objdump program on the drive. Using that, I was able to quickly determine that the embedded language used is MIPS 3000. So now I need to setup a linux box with a toolchain and mips cross compiler so I can do some C programming for it.

More nice info. From cat /proc/version
Linux version 2.6.12.6-VENUS (root@local) (gcc version 3.4.4 mipssde-6.03.01-200
51114) #29 Wed Sep 10 22:00:48 CST 2008

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.