The Series4 (TiVo Premiere) Development Thread

[mike_s]

I think you can pass parameters, but they have to be in double quotes:

boot -3 "root=/dev/hda4 dsscon=true console=0,115200"

[jt1134]

also, original bootpage looks like the premiere uses sdaX instead of hdaX like it did on previous hardware

[Omikron]

I think you can pass parameters, but they have to be in double quotes:

boot -3 "root=/dev/hda4 dsscon=true console=0,115200"

That makes a great deal of sense. I'm not sure why I didn't think of that. :-P

[Omikron]

Eventually got the flags set correctly and got my terminal program to behave properly.

In case anyone is curious, I've attached the full console log from the complete bootup, with timestamps.

[tivo4mevo]

To verify that the PROM signature is checked via BSP, I could just change a single bit in the data and see what the console says.

Either way, once we start looking at the PROM disassembly we should get some insight into what options we have, if any.

bsptest doesn't check the Flash boot partition signature, bsptest checks that secure boot is enabled and the debug interface is locked (based upon bsptest errors and the rc.sysinit notes).

Errors:

bsptest: public key index is %d, expected 0.
bsptest: flash key authentication is not enabled.
bsptest: secure boot is not enabled.
bsptest: debug interface is not locked.
bsptest: EJTAG is disabled?

From rc.LoadEarlyCoreDrivers.sh:

# This complains if secure boot is disabled or the debug interface is not
# locked.  Dev systems will always complain. Release systems should *never*
# complain, if they do then the factory is broken.

Additionally, fswak:

fswak -- flash swiss army knife

usage:

  fswak [-c] [-i] [-I] [-lock_FOREVER] [-q] [-p] [-r[0]] [-s k=v] [-t k] [-u k] [-v] [-V] [-w n] [-x n] [<file]

where:

  -c              Clear environment.
  -i              Check that file on stdin is a valid boot image. Fail if not.
  -I              Same as above, but also check signature.
  -lock_FOREVER   Don't do this if you don't mean it... Fail if couldn't.
  -p              Print environment.
  -q              Query lock status. Fail if unlocked.
  -r[0]           Copy partition 0 to stdout.
  -s k=v          Set environment variable.
  -t k            Test that environment variable exists. Print if so, fail if not.
  -u k            Unset environment variable.
  -v              Check that boot partition contains valid boot image. Fail if not.
  -V              Same as above, but also check signature.
  -w n            Write file on stdin to partition n.
  -x n            Compare file on stdin to partition n. Fail if different.

Legal partitions are: 0 = config; 1 = boot; 2 = kernel. Multiple options can be specified, including options
that reference stdin. Options will be executed in the order specified. Note the environment is not actually
updated until successful termination or execution of -w0.

appears to be a utility to access to the Flash. Reordering the usage flags as follows helps elucidate how to use fswak to load a new image from stdin:
["-i"] Check that file on stdin is a valid boot image. Fail if not.
["-I"] Same as above, but also check signature.
["-w 1"] Write file on stdin to partition n (boot in my example).
["-x 1"] Compare file on stdin to partition n. Fail if different. (check for corruption),
["-v"] Check that boot partition contains valid boot image. Fail if not.

Finally, the "-v" option seems to result in these possible failures:

Image has invalid signature length.
Image has invalid signature CSD.
Image has invalid signature key.
Image has wrong SHA (%s).

Roll that all together and here's a guess of what might be happening:
1) the BCM7413's internal boot ROM, when set to "secure boot" mode (and an associated public key index), will search the Flash boot-partition for an expected public key and loads it in.
2) the CPU authenticates that public key (presumably by comparing it's checksum to an internal/hard-coded version).
3) Assuming that the public key is valid, the CPU then verifies the signature (using said authenticated flash key) of the Flash boot partition.
4) Assuming the signature is valid, the CPU hands off control to the Flash boot partition code.
5) Rest of boot is as it was before.

This would simplify things considerably for TiVo development. No more engineering keys needed. Development boxes run with secure boot off and debug enabled in hardware. Production units are secured during factory configuration (OTP bits or fuses). Additionally, as Jamie pointed out, this lowers the root of trust away from the Boot Flash (PROM) to the CPU--which is considerably more difficult to replace.

Finally, I would suggest that you try these steps to confirm the above.
1) change a bit of the public key
2) change a bit of the signature
3) change a bit of the boot image
I'm not sure whether the BCM7413 has any way to report errors?

[Omikron]

Finally, I would suggest that you try these steps to confirm the above.
1) change a bit of the public key
2) change a bit of the signature
3) change a bit of the boot image
I'm not sure whether the BCM7413 has any way to report errors?

Thanks for the great analysis. That sounds like a good plan to move forward with once the adapter arrives.

Even if secure boot and other checks are enabled, it's possible that there could be other exploit vectors.

In this case, TiVo doesn't really seem to have a whole lot to protect. Clearly they are obligated to make an effort secure their software and the content on the disk in order to placate copyright holders and Cable Labs, but beyond that they're not really protecting state secrets. I have a hard time believing TiVo spent as much time securing Gen07 as say, Apple did securing iPhone or Microsoft did securing Xbox.

The real question is how much effort is reasonable in this situation. When the Gen05 platform was released it was done so without TTG and MRV capabilities, which are pretty major features. The desire to enable similar functionality via the use of other hacks was a fairly strong one, and I feel it drove development. Meanwhile, Gen07 was released with all of the major features enabled, and a new (albeit buggy) HDUI to boot.

As far as new features go the stakes are markedly lower, but the hacker and TiVo-lover in me still wants to explore. This is a sentiment I'm sure others share.

So in that spirit...

Onward!

[tivo4mevo]

Good points, though regarding the point about tivo not having a lot to protect, I thought saw mention that the S4 was to be fielded by some cable manufacturers. Who presumably would want assurances about the box's resistance to tampering.

Additionally, tivo is just leveraging the security features Broadcom has already added (and Broadcom is building to a level of security demanded by their current and customers potential customers, which includes Dish, DirecTV, Sky, and others). So tivo can up their box's security significantly with minimal effort.

[Jamie]

I certainly don't want to discourage further exploration. It's just good to know what obstacles to expect.

[Omikron]

Good points, though regarding the point about tivo not having a lot to protect, I thought saw mention that the S4 was to be fielded by some cable manufacturers. Who presumably would want assurances about the box's resistance to tampering.

Interesting thought. This would certainly explain the progressive "downgrading" of the case observed from Gen05 to Gen07. The case styles seem to keep getting uglier, with the original Gen05 Series3 being the best looking TiVo ever (IMHO). However, the new case design has to be decidedly cheaper to manufacture since the front panel doesn't have any LED's directly on it but rather just uses some light pipes to go down to some SMD LED's on the motherboard. The new hardware is also considerably lighter and smaller in every dimension.

Just the other day I was musing to myself how much the new hardware looks and feels more like a cable box than a TiVo. :-)

[StanSimmons]

Thanks for the great analysis. That sounds like a good plan to move forward with once the adapter arrives.

Even if secure boot and other checks are enabled, it's possible that there could be other exploit vectors.

In this case, TiVo doesn't really seem to have a whole lot to protect. Clearly they are obligated to make an effort secure their software and the content on the disk in order to placate copyright holders and Cable Labs, but beyond that they're not really protecting state secrets. I have a hard time believing TiVo spent as much time securing Gen07 as say, Apple did securing iPhone or Microsoft did securing Xbox.

The real question is how much effort is reasonable in this situation. When the Gen05 platform was released it was done so without TTG and MRV capabilities, which are pretty major features. The desire to enable similar functionality via the use of other hacks was a fairly strong one, and I feel it drove development. Meanwhile, Gen07 was released with all of the major features enabled, and a new (albeit buggy) HDUI to boot.

As far as new features go the stakes are markedly lower, but the hacker and TiVo-lover in me still wants to explore. This is a sentiment I'm sure others share.

So in that spirit...

Onward!

The only thing keeping me from getting the Premier is the CCI byte issue. Since I HEAVILY use MRV/TTG, and TimeWarner Dallas sets the CCI byte on almost everything, until that can be bypassed I have zero interest in getting a Premier.

[Omikron]

Since I had the TSOP sockets already on hand, I figured I would try my hand at socketing my board in preparation for future work. Little did I know the frustration that would ensure. First of all, the entire board is RoHS compliant, which means they use 100% lead-free solder. For those who are "not in the know" lead-free solder melts at a higher temperature, and for that reason is a pain in the ass to work with. Apparently my existing rework equipment couldn't get to high enough temperatures to remove the TSOP. After spending more time than I felt comfortable with blasting the board with hot air, I resorted to Chip Quick.

If I haven't ranted about Chip Quick before, please allow me to do so now. I hate Chip Quick. It's expensive, it's messy, and it's a pain in the ass to clean up. The initial removal of the component is fairly straight forward, but if you plan on doing anything useful with the component you removed other than using it as a keychain, you have to clean it up. This means a great deal of time and effort spent cleaning the leads of the chip with lots of copper braid, flux, and more copper braid. Double that up for the actual pads on the PCB itself. You see, Chip Quick consists of an alloy that melts at a crazy-low temperature that mixes with the existing solder, allowing the huge blob of solder to stay molten for quite some time. Unfortunately every last bit of this stuff has to be removed from any component that needs to be re-soldered. If it's not properly cleaned, the joint is prone to poor connectivity and failure. This is the glorious bliss that awaits any Chip Quick user.

So after I removed the original TSOP from the board, I noticed something interesting. The PROM has a serial number underneath it. Not on the PCB, but rather laser-etched onto the underside of the chip. This is particularly interesting because TiVo has already laser-engraved the top of the chip with the CBOM revision number, and it takes an extra few steps to flip the chip over and serialize the bottom. Without being able to read the chip, it's hard to say yet exactly what this means for us. It's possible that each PROM has it's own unique crypto key, or stores some other pertinent and unique information. If this is the case, then it's going to mean that PROM dumps posted online will be useless to anyone but the original user, and it could also mean that even if a PROM exploit is found, I wouldn't be able to batch program chips. I would have to read, patch, and re-write the PROM for each TiVo separately.

Ultimately after meticulously cleaning both the TSOP and the pads on the motherboard I tried to mount the TSOP socket. Much to my frustration, it would seem that my current equipment is not suited for this task. I don't have to use lead-free solder so temperature isn't an issue, but the nozzle I have is way too big, and a smaller adapter isn't available. As near as I can tell there's no easy way to solder the socket on via a hand-held soldering iron with fine tip either. It would seem that I am now faced with buying either new hot air rework equipment, or an IR rework station.

Another option that I've been researching is the use of anisotropic conductive epoxy. Apparently it's expensive and a pain in the ass to find, but it might be the ticket to getting this thing done without having to buy a new set of equipment.

I'm still continuing to look for other options and if anyone has any suggestions I'd love to hear them.

[mike_s]

This means a great deal of time and effort spent cleaning the leads of the chip with lots of copper braid, flux, and more copper braid.

Dust-off (or a source of compressed air) is your friend.

[Omikron]

Dust-off (or a source of compressed air) is your friend.

Care to elaborate on this method?

Edit: I'm assuming you're talking about heating the Chip Quick that's on the component and then blasting the material off of the leads, but this still leaves a good layer of the alloy on the pins which must be removed manually for optimal connections, and doesn't address the residue left on the PCB, which also must be cleaned thoroughly and manually.

[mike_s]

I'm assuming you're talking about heating the Chip Quick that's on the component and then blasting the material off of the leads, but this still leaves a good layer of the alloy on the pins which must be removed manually for optimal connections,

No, it doesn't, in my experience. Very, very little is left on. It has worked well for me. In any case, if the removed component is going into a socket, then concerns about future solder adhesion are moot.

and doesn't address the residue left on the PCB, which also must be cleaned thoroughly and manually.

I get most of that with a q-tip, then solder braid. Finish by rewetting with real solder and braiding again. I find it easier than doing through hole with a vacuum extractor.

[Omikron]

No, it doesn't, in my experience. Very, very little is left on. It has worked well for me. In any case, if the removed component is going into a socket, then concerns about future solder adhesion are moot.

I honestly hadn't tried it yet, but I suppose it's true. I just dislike leaving any residue on there because it seems to have a tendency to hand-off to other connectors and pads on contact. I'm perhaps a bit too anal at times about my soldering, but it's saved me a few times. :-)

I get most of that with a q-tip, then solder braid. Finish by rewetting with real solder and braiding again. I find it easier than doing through hole with a vacuum extractor.

I use the same method. Again, cleanliness of the pads for me is important because in this specific case, I'm soldering a socket in it's place. While a normal component doesn't really have any stress put on it during use, a socket relies on it's cohesion to the PCB in order to stay put while the user fiddles with the socket during chip removal and insertion, and most socket designs put the pins under light tension at all times while the chip is inserted and locked in. My fear would be that a thermal cycling coupled with a low quality bond would break down over time and cause issues down the line.

If hacking Gen07 is indeed possible, the socket issue may be somewhat moot. Historically TiVo has never issued a PROM update and even though we've been using sockets for all previous platforms, it hasn't ever been needed. If this remains true, it would be significantly easier to simply write-protect the replacement PROM and solder it directly to the motherboard, instead of fiddling with a costly and error-prone socket.

Heck, just the "application notes" alone are 15 pages: http://meritec.thomasnet.com/Asset/A...tion_Notes.pdf