A thought occurred to me

[AlphaWolf]

I heard of an xbox 360 exploit that emulates the DVD drive only just enough to feed the xbox the digital signature information so that arbitrary code could just be executed later. Perhaps we could do something similar for tivos?

Namely, we'd have a boot stage that works like so:

- CPU checks prom for authenticity
- prom reads from what it believes is the hard disk, and checks the kernel image it was given for authenticity
- Our fake hard disk device recognizes when the kernel has been fully scanned, and swaps to a passthrough mode
- execution then begins on the REAL kernel, which has of course been modified

Thoughts?

[Jamie]

This seems to assume that the kernel is read twice: once to check its signature, and again to actually run it. It seems much more likely to me that it is read just once: read into memory, checked for validity, then transfer control into the kernel in memory. It would seem to me that to perform this sort of hack, you'd need the switch to occur in the memory controller, not the disk controller.

[AlphaWolf]

I don't know about the newer tivos but I think I remembered that being how it worked on the S1 dtivos.

[Jamie]

Seems quite unlikely to me that you could fool the prom into transferring control into the wrong kernel this way. You might be able to swap the root file system after the initrd scan completed.

[Thinkdiff]

Interesting idea, but one small correction.

The Xbox 360 drive hacks do not allow arbitrary code execution. It only fakes the xbox into thinking the DVD is official. Once that check is passed, everything else on the disc (except a few special cases) needs to be signed with Microsoft's signing key because the Hypervisor is still in complete control.

With the TiVo, we have the advantage that the processor will execute unsigned code after the PROM approves the kernel. Assuming, as Jamie said, the kernel is read twice, it is possible but the required R&D/hardware is probably pretty extensive.

I think Jamie's idea of replacing the root file system is a better approach. Recognize that the kernel has checked the filesystem, then use some method to replace the active FS. Alternative approach would be providing the initrd checks with some stock responses that pass the challenges, then have it execute from the modified partition.

[AlphaWolf]

Seems quite unlikely to me that you could fool the prom into transferring control into the wrong kernel this way. You might be able to swap the root file system after the initrd scan completed.

That's a better idea. Or maybe even upon power up, look for the first binary/script that gets executed on a premier (whatever it is) and map its physical location. After its read in full for the first time, simply insert code to execute monte in its place, then monte gets executed as soon as the first init stage starts.

In fact I wonder if the hard disk firmware itself could be hacked to do something like this. From what I understand of a hard disk, they have their own mini operating system that already does remap data locations on the fly to correct for physical defects detected on the platter.

With the TiVo, we have the advantage that the processor will execute unsigned code after the PROM approves the kernel. Assuming, as Jamie said, the kernel is read twice, it is possible but the required R&D/hardware is probably pretty extensive.

I'm thinking there might already be some designs for that in place. I read about something called an xkey that has an embedded linux operating system which emulates the entire drive, so for all intents and purposes you don't even have to have the dvd or the drive to begin with, and they sell these for as low as $70 and some change.

But we don't need to get anywhere near that complex. I think simply spitting the right data in at the right time shouldn't be too complicated for anybody who has done any sort of hard hacking (not me, in fact I don't ever plan on owning a premier even if it was cracked, just throwing this out in the air is all.)

[pc-reviewer]

I seems like what is needed is a buffer over run flaw in the code that would allow us to inject the signature of a good kernel into memory regardless of what the real kernel looks like. I wish I was a true hacker and I could run the code through a code fuzzer. Who has mad skills?

http://en.wikipedia.org/wiki/Fuzz_testing

http://blog.emaze.net/2011/10/exploi...d-devices.html

[tivo4mevo]

The trouble is that the buffer over run flaw you seek would need to be in the Broadcom Security Processor (bsp) of the tivo's CPU, as a vulnerability in the tivo "boot sector" (code that prior to the s4, used to be house in a PROM) could be (in theory) closed by tivo releasing a new boot sector to be written to the mainboard Flash.

And finding such an vulnerability in the BSP code is difficult (it's inside the CPU, and I haven't seen a way to dump it other than lathing down the CPU to find the metal mask ROM).

I think that generally speaking, the "use an Audrino to emulate a SATA block device that gives a different file upon second access" style attack would be more fruitful, but it's beyond the mainstream.

[pc-reviewer]

I was thinking of an error in the program in the prom it self like on the S3, which cannot be changed by tivo. If that program had a flaw that could be exploited, like giving it more data than expected when it goes to read a hash from the hard drive. It is a very common attack on programs to give back unexpected data, when a request for data is made. The extra data includes a command, which is then written into memory which is then executed when the memory block is read. I know that these types of attacks are used, but I do not know how to create them. for instance extending a hash value to include instructions.

here is a better explanation.
http://en.wikipedia.org/wiki/Buffer_overflow

[tivo4mevo]

Thanks. I understood, but might not have provided enough background. This thread here (link) might be worth a re-read. But the short version is that the "PROM" code (i.e., the boot-loader code written by tivo) is no longer in PROM, but instead is in Flash, and that Flash is checked by the CPU itself, before the CPU turns over execution to the "PROM" code in Flash. So assuming that there were a buffer overflow vulnerability in tivo's "PROM" code, once exploited, tivo could (in theory) release an update to fielded units in order to have them rewrite their Flash boot partitions with a new "PROM" image, with the vulnerability patched.

This shouldn't dissuade one from investigating to confirm the veracity of what I write and to check for other vulnerabilities, but just wanted to point out that Series4 hardware pushed the "root of trust" down one level below the tivo-coded "PROM".

[Rakeesh]

The trouble is that the buffer over run flaw you seek would need to be in the Broadcom Security Processor (bsp) of the tivo's CPU, as a vulnerability in the tivo "boot sector" (code that prior to the s4, used to be house in a PROM) could be (in theory) closed by tivo releasing a new boot sector to be written to the mainboard Flash.

And finding such an vulnerability in the BSP code is difficult (it's inside the CPU, and I haven't seen a way to dump it other than lathing down the CPU to find the metal mask ROM).

I think that generally speaking, the "use an Audrino to emulate a SATA block device that gives a different file upon second access" style attack would be more fruitful, but it's beyond the mainstream.

I've been working with storage tech a bit recently, and I noticed an emerging standard called AoE, or ATA over Ethernet. When I was pulling apart a tivo a few days ago (hard disk clicking,) an idea came to me about having the tivo be diskless. That is, have a loopback device sitting on a NAS, and the SATA adapter configured with the address and CIFS/NFS credentials, and...you get the idea.

Now we have tivo RAID'ified (no more failed disks eating up your settings and shows) and we can inject code willy nilly.

Arduino boards can be had for cheap, I would imagine the hardware for doing this not being too expensive. We'd certainly be talking less effort and cost than it took to create the original tivonet adapter. The problem is, somebody needs to write the software. This would have applications beyond just tivo btw, you could effectively turn any computer of your choosing into a diskless one, regardless of firmware support.

[tivo4mevo]

This could work. I saw on slashdot some time ago, a conference presentation of an Arduino based device (I believe) to sit between a SATA device and the victim, and it would alter a file accessed when the victim accessed it a second time (first time is to measure/check the file, second time is to execute). This type of attack could probably work against a tivo, but unless there's a fair amount of reusable code, it might be a lot of work.

[unitron]

This could work. I saw on slashdot some time ago, a conference presentation of an Arduino based device (I believe) to sit between a SATA device and the victim, and it would alter a file accessed when the victim accessed it a second time (first time is to measure/check the file, second time is to execute). This type of attack could probably work against a tivo, but unless there's a fair amount of reusable code, it might be a lot of work.

Who are you on /.?

You can PM it to me if you're shy.

[tivo4mevo]

I'm not a member of slashdot. I tried to search for the article/presentation, but had no luck finding it again. I can't even remember the device they were attacking, unfortunately.