A Futile Attempt At Bending a DVR To My Will

One of my favorite places in the world is Gateway Electronics in St. Louis. They're an electronic part and surplus store that never fails to delight with their collection of old electronics. The last time I went, however, I found something newish. It was a DirecTV HR23-700 HD DVR box. I looked at the back and it had several really interesting ports: HDMI, eSATA, and two ethernet ports just to name a few. At $10, it was too good to pass up, so I bought it to see what I could do with it. I don't have any immediate plans for this right now mainly because I don't know what's inside. But we're about to find out.

I plugged it in and it works. Okay fine, let's take it apart. I'm super ready for this if you can't tell.

The screws keeping the back on are Torx Security T10 screws. Once those came off and and the warranty sticker was sliced, the top came off almost too easily.

Whoops

The first thing to look at is the SATA Hard Drive.

The HD is a Western Digital 500GB GreenPower hard drive. Not bad, but what will the box do when we try to power it up without the hard drive?

So it wouldn't start. I don't know if this is the BIOS doing the check or the firmware, but the hope is that the real OS is on the hard drive. That way we can, you know, boot whatever the hell we want. But, before we continue, let's take a look at what's actually on the Hard Drive.

The hard drive was actually a relatively tough nut to crack. I'm no data forensic expert, so this took a lot of knowledge I hadn't yet used.

When I plugged the hard drive into the dock I have, it showed up in Ubuntu as a 16GB partition that it couldn't mount because of an "unknown filesystem type 'xfs'". This struck me as odd, because XFS should be compiled right into the kernel. I checked 'lsmod' and the XFS module was loaded. Weird. So I tried to run binwalk on the entire drive. Binwalk found linux-like files on the drive, but was unable to identify the filesystem. So I hit it with xfs_db (what I should have done first) and here's what it said:

Well, that's nice. I tried using DiskInternals and it couldn't read it either. So I guess I'd try to use an older version of Ubuntu. It's very possible this is an outdated version of XFS. It's also possible that this isn't really an XFS filesystem but we'll just have to see.

xfs_repair couldn't repair it. But binwalk could still find unix paths. So I tried to make binwalk extract everything. It didn't do a good job. The files are probably encrypted. Darn.

So, now that we've failed to see what's on the drive, let's study the board a bit.

The first easy chip to identify was the BCM5325FKQMG, a 5 port 10/100 Ethernet Switch Controller. This appeared to run the two ethernet ports on the back of the device. The other easily identifiable chip was the BCM4506 Dual Advanced Modulation Satellite Receiver. The next chips I looked at were the HY5DU121622 memory chips. They look to be 512MB DDR RAM, and there are four of them, so unless there are some on the other side, we're dealing with 2GB of DDR RAM. Not the worst in the world. Then there was the chip I was afraid to find: the HY27UF082G2B which provides 2GB of NAND Flash.

There were two other interesting chips. Over by the DirecTV card reader, there was a CX24123-11ZT which is a Demodulator and FEC Decoder. Finally, there's a ATmega88PV 8-bit micro controller, probably to deal with the buttons and lights on the front of the box (as the connector to the front of the box is really close to it).

"But what about the processor?" you may ask. Excellent question. I've been avoiding removing the heatsink until now, mainly because I can't find my thermal paste. But, I suppose I'll have to find it eventually. I removed the heatsink and was not shocked when I found a Broadcom Chip.

Okay, so now what? Do we go about compiling a kernel for this, or do we try to break the one that's already there?

After hours of research and learning about kernel cross compilation I've decided to try and hack the existing software first. This may prove to be slightly harder than originally thought because during my investigation of the hard drive, it occurred to me that the paths reported by binwalk were not a full linux installation, leading me to believe that the hard drive acts as just the /var partition (where most of the GUI software and the actual recordings get placed, but this may not be true either, I'm really only guessing at this point).

So how do I even begin to get into this?

There's an HTTP Server listening on port 8080 for controlling the box over HTTP, but through the vague documentation I found on it, there's nothing useful from that interface. I even tried bruteforcing the undocumented /processCommand path to no avail. Then I tried to get into some sort of maintenance mode. The best I could do was diagnostic mode (pressing Select during the self check) but that did nothing useful. I then tested several unpopulated connectors on the board for a serial connection and didn't find one (that was readily apparent.) I found this wave form on one of them but I wasn't able to decode it into anything meaningful. Because of the relatively consistent clock on the top signal, I've decoded it as I2C for now. But, even if that's what it is, that's fairly useless to me.

I even checked the bottom of the board for more possible serial connections.

Nothing. And this is as far as I dared venture. I couldn't figure out where to go from here. I may pick this up later, but these devices are engineered to be hard to hack. Like, really hard. They really didn't want people modding their DVR to pull recorded shows off of the system. So, if there comes a time where I give up on this, at least I will have scored a decent hard drive for $10 along with a fan, a power supply, and some common ports and a small USB board. Not bad, but certainly not what I wanted, either. At least an attempt was made.