There are a lot of sites about "hacking" the TiVo, to do this to it and that to it (and there's always the other thing too). After all, half the fun of owning something that runs Linux is to make it do something more (or different) than it was intended to do. But most of us only need so many Web servers (off the top of my head, I think I have 10 or 15 Web servers in my house already, including the embedded systems).

A couple of bits of advice about a planned TiVo hack attack. You should probably assume that you will void any warranty it ever had and that it won't work as a video recorder again. It's not that you're likely to botch things that badly, but rather that the aggravation you could face trying to get the machine fixed for any little change will be offset by the realization that you're the one who busted it.

If you're going to try to upgrade the hard drive, online instructions tell you to start by getting T10 and T15 Torx screwdriver bits from a hardware store. This is partially good advice: the TiVo does indeed use T10 and T15 Torx screws. However, if you are not the sort of person who already has a reasonable collection of Torx bits lying around, you may not want to mess with this. Thanks to the Kuro box and the Mac Mini, you have other options for reasonably affordable PowerPC® hardware.

My selection for this experiment was the 40-hour TiVo. It's a Series2 machine, which means it's much less flexible or open than the Series1 was. Unfortunately, that's all they sell now, but it is moderately inexpensive.

Making backups

As always, when about to do something that may alter the electronic landscape, start by making backups. Before even powering up my TiVo, I made a backup of its disk. This involves opening the machine (using the T10 Torx bit), removing the drive sled (T10 again), and removing the drive from the sled (T15). Now you have a 40-GB disk. Put this drive in any old x86 Linux box, and you'll find that it has an unknown partition table. So, there are no partitions on TiVo (such as /dev/hde1), just a whole disk. No problem.

On my system, I put the drive into a drive bay, making it /dev/hde. If you use an external drive bay, it might show up as /dev/sdX in which "X" is some letter; it might be "a" if you have no other SCSI or pseudo-SCSI devices, or possibly something from later on in the alphabet. Be sure you know which disk you're working on!

# bzip2 -1c < /dev/hde > tivo.img.bz2

Note that at first it may appear that something's gone horribly wrong. No output will appear for quite a while. This disk contains lots of empty sectors full of zeroes at the start, and bzip2 is dutifully doing a very good job of compressing them -- it was a minute or so before the file reached 4,096 bytes and a few minutes more before it reached 8,192. The final file size was around 560 MB, not bad for an image of a 40-GB disk. If you want to restore from that backup, just do it the other way:

# bzip2 -dc < tivo.img.bz2 > /dev/hde

The image will be a lot more than 560 MB once you've got some data on the drive. Assume you'll need to have about as much free space as the size of your TiVo drive.

Back to top

So, what's on the disk?

Since the disk doesn't show up as being partitioned, it's reasonable to suspect that it might be in some proprietary format. Time to figure out what that format is.

Of course, the first thing to do is look at the disk as raw bytes. It starts out with something that looks a little like configuration for a boot loader:

root=/dev/hda7
runfinaltest=2 contigmem8=16M brev=0x10

After that, however, is the explanation of all mysteries -- this disk contains an Apple partition map:

0x0200  50 4d 00 00  00 00 00 0d  00 00 00 01  00 00 00 3f  'PM.............?'
0x0210  41 70 70 6c  65 00 00 00  00 00 00 00  00 00 00 00  'Apple...........'
0x0220  00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  '................'
0x0230  41 70 70 6c  65 5f 70 61  72 74 69 74  69 6f 6e 5f  'Apple_partition_'
0x0240  6d 61 70 00  00 00 00 00  00 00 00 00  00 00 00 00  'map.............'
0x0250  00 00 00 00  00 00 00 3f  00 00 00 33  00 00 00 00  '.......?...3....'

Did you suspect this?

In retrospect, an Apple partition map is a very reasonable thing for a PowerPC Linux box to hold. Support for Apple partition maps isn't unusual, and they're reasonably well documented. It's a little less typical for a MIPS system, but they presumably opted for compatibility with the Series1 systems, which ran on PowerPC.

Strictly speaking, this is still a proprietary format; it's just a well-known one. Unfortunately, none of the partitions are in formats that are familiar to OS X, but my Mac Mini could read the partition table. Here's the partition map:

Partition map (with 512 byte blocks) on '/dev/rdisk1'
 #:                type name                       length   base     ( size )
 1: Apple_partition_map Apple                          63 @ 1
 2:               Image Bootstrap 1                     1 @ 44161324
 3:               Image Kernel 1                     8192 @ 44161325 (  4.0M)
 4:                Ext2 Root 1                     524288 @ 44169517 (256.0M)
 5:               Image Bootstrap 2                     1 @ 44693805
 6:               Image Kernel 2                     8192 @ 44693806 (  4.0M)
 7:                Ext2 Root 2                     524288 @ 44701998 (256.0M)
 8:                Swap Linux swap                 262144 @ 45226286 (128.0M)
 9:                Ext2 /var                       262144 @ 45488430 (128.0M)
10:                 MFS MFS application region     524288 @ 45750574 (256.0M)
11:                 MFS MFS media region         33494098 @ 46799150 ( 16.0G)
12:                 MFS MFS application region 2   524288 @ 46274862 (256.0M)
13:                 MFS MFS media region 2       44161260 @ 64       ( 21.1G)


Device block size=512, Number of Blocks=80293248 (38.3G)
DeviceType=0x0, DeviceId=0x0

This gives us a good idea of what to expect. For one thing, it looks like it is probably designed to update one file system while running from the other, to make updates safe. And, wonder of wonders: this gives exact block offsets and sizes for some file systems to look at. That means it's time to connect the drive back up to a Linux box and have a look at those file systems.

# dd if=/dev/hde bs=512 count=524288 skip=44169517 of=root1.img
# dd if=/dev/hde bs=512 count=524288 skip=44701998 of=root2.img
# dd if=/dev/hde bs=512 count=262144 skip=45488430 of=var.img

It turns out that the Root 1 file system isn't even formatted; it's just 256 MB of null bytes. But the Root 2 file system is golden:

# file root2.img
root2.img: Linux rev 0.0 ext2 filesystem data
# mount -o loop root2.img /mnt
# ls /mnt
.   bin  diag  etc       initrd   lib         mnt  proc  sbin  tvbin  var
..  dev  dist  etccombo  install  lost+found  opt  res   tmp   tvlib
# mount -o loop var.img /mnt/var
# ls /mnt/var
.   a    dev   etc  lost+found  mnt   packages  run    tmp
..  bin  dist  log  mess        mtab  persist   state  utils

Back to top

Security

One of the disadvantages of this being essentially a proprietary system is that the TiVo as shipped has some "security" features that are intended to prevent you from modifying it. This is a simple question of economics -- anyone selling general-purpose MIPS systems with hard drives and TV tuners in them for $100 would go broke quickly. So for now, I'm just going to look at how Linux runs on this system, not how to change it.

Note that the convenient compatibility of the ext2 file system from one system to another means that you have the option of playing around under a regular Linux box. You could even set up a cross-compiler and related tools and poke around in a little more detail. Don't expect to be able to change things easily, though; while it has been done, it is not intended to be easy or convenient. Remember, this is a proprietary piece of hardware that has the capability to record video. Needless to say, a large number of corporations want very badly for it to be hard to change it too much.

On this particular model of TiVo, there is a hardware security check before the kernel even gets loaded. Then, the kernel itself has a RAMdisk built into it that contains some of the security features; compare with the code found on the hard drive, such as the /var/utils/checkkernel.tcl script.

It is worth noting that in the initial install, there's a very large amount of extra space. The root file system has 54 MB in use and 182 MB free; /var has 3 MB in use and 116 MB free. Of course, the intention is to store a lot of data, such as the programs you like to watch.

Back to top

Looking at the software

One of the more interesting things about the TiVo is the variety of special-purpose applications it has. Although in theory it has a display available, in fact it can't just scroll text up the screen. There's an executable named /tvbin/text2osd, which sounds suspiciously like an application to write words on the output video as an on-screen display. There's also an interesting collection of PNG files, all in typical video sizes, containing messages that might need to be displayed. In a nod to Douglas Adams, my favorite says "Don't Panic."

The software is a little disorganized, but then again there's really no need to have things in "intuitive" locations -- only the development team needs to be able to find the bits. Some things make less sense than others -- all of the TiVo software is in /tvbin and /tvlib, but the configuration files for a lot of programs are in /opt/tivo. A more traditional Linux file system layout would have put the files in /opt/tivo/bin, /opt/tivo/lib, and /opt/tivo/etc.

Looking at a Tcl script, I noticed that it was interpreted by /tvbin/tivosh. This is probably a tcl interpreter. But wait, it's actually a symbolic link to a program called tivoapp. Many different programs are linked to tivoapp. It looks like a unified binary containing bits of a number of different programs. It is not immediately obvious why this application would be built this way -- it may reduce memory footprint or it may just make the system harder to crack.

Mix and match

One thing that's very noticeable is that the TiVo has a fairly loose combination of shell scripts, Tcl programs, and binaries. You can learn a lot about what a given program does by looking at it. For instance, the installNFS script, written in bash, calls text2osd to display messages. It even has an inlined Tcl script!

One of the big strengths of Linux for development is the freedom to mix and match development tools like this -- TiVo shows this off to good advantage.

System boot

Like any Linux system, the TiVo spawns /sbin/init, which in turn looks at /etc/inittab to decide what to do. The first thing it does is run /etc/rc.d/rc.sysinit, which in turn runs files from directories with names like StageA_PreKickstart and StageG_PostApplication. They are run in order.

Each of these directories contains a number of scripts with names like rc.Sequence_150.CheckForDebug.sh. These are analogous to files like /etc/rc.d/rc3.d/S12sshd on a more conventional Linux system. Note that the shell's habit of collating expansions (such as rc.Sequence_*.sh) is used to provide ordering. If a script's name has the string .Platform in it, it will be run only on matching hardware.

This is a good design for a commodity vendor -- they don't need to build the disk differently for each machine. The same goes for .Implementation and .Implementer flags, which identify scripts to run only on some systems. The Stage directories replace the rcN.d directories, which are absent.

This organization makes it comparatively easy to see what's going on at each stage of boot. It's interesting to note that the shell scripts are sourced into the parent shell so that early scripts can set environment variables for later ones to use.

Back to top

Summary

The TiVo is a fascinating example of a number of different Linux philosophies, in action and contrasted starkly with the philosophy of a company making money selling services and providing a simple, robust application for users. Many of the features that would-be hackers find most frustrating are probably there to keep people from calling customer support with an entirely customized box and wondering why it won't work.

On the other hand, it does appear that a real effort has gone into making the machine harder and harder to tweak. Early TiVo systems were often modified to be Web servers. The one I'm looking at, so far as anyone can tell, cannot be made to run a new kernel or otherwise be changed in any significant way without an actual hardware hack to the PROM that checks for unauthorized modifications to the software.

It's particularly interesting to note that the GPL, while it does compel TiVo to produce source code for their kernels, doesn't really keep them from building a box that runs Linux but won't let you change anything. The interesting aspects of this box are mostly in studying how it does what it does and how various open source tools and technologies are used to build an embedded application.

Resources

• Participate in the discussion forum.
  
  
• Read the other installments in Peter's Linux on board series.
  
  
• The Series2 TiVo is based on the Broadcom BCM7317 chip, a MIPS core with some handy support for set-top box features.
  
  
• The Atmel AT90SC6464C chip is a low-power, high-performance, 8-/16-bit secure microcontroller with 64KB/64KB ROM EEPROM and such security features as MMU, MED, OTP (One Time Programmable) EEPROM area, RNG (Random Number Generator), "out of bounds" detectors, and side channel attack countermeasures.
  
  
• If you want to make the TiVo into a slightly friendlier hard disk recorder, there are instructions for hacking the TiVo Series 2.
  
  
• You can find a whole lot of discussion on TiVo hacking at the DealDatabase Forum. And no, they won't help you get free DirectTV.
  
  
• Peter's TiVo is nicknamed a Series 2.5; it has a non-reflashable chip designed to provide extra security. Read about it in this thread.
  
  
• You can check out The Hitchhiker's Guide to the Galaxy (movie version) on this site. And remember, "Don't Panic!"
  
  
• The "Three reasons why Linux will trounce the embedded market" (developerWorks, May 2001) are royalty fees, device features, and the promise of a single platform (TiVo gets a mention here).
  
  
• "Software Development for Consumer Electronics: Bigger, Better, Faster, More -- Or Bust" (The Rational Edge, 2004) details Linux as a best choice for consumer electronics where the profit margin can be razor thin.
  
  
• "Emulation and cross-development for PowerPC" (developerWorks, January 2005) introduces PowerPC emulation and cross-compiling.
  
  
• "A developer's guide to the POWER architecture" (developerWorks, March 2004) introduces the PowerPC application-level programming model to provide an overview of the instruction set and important registers.
  
  
• Find more resources for Linux developers in the developerWorks Linux zone.
  
  
• Get involved in the developerWorks community by participating in developerWorks blogs.
  
  
• Order the SEK for Linux, a two-DVD set containing the latest IBM trial software for Linux from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  
• Build your next development project on Linux with IBM trial software, available for download directly from developerWorks.
  
  

About the author

Peter Seebach loves to take things apart and find out how they would have worked. He feels that the discovery that a device "runs Linux" can reasonably be considered a challenge to poke around in its root file system. You can contact Peter at dwlinux@plethora.net.

Rate this article

Comments

Back to top

Table of contents

• Making backups
• So, what's on the disk?
• Security
• Looking at the software
• Summary
• Resources
• About the author
• Comments

Dig deeper into Linux on developerWorks

IBM SmartCloud trial. No charge.

Unleash the power of hybrid cloud computing today!

---

Public and private solutions in one trial.

Special offers