also, original bootpage looks like the premiere uses sdaX instead of hdaX like it did on previous hardware
I think you can pass parameters, but they have to be in double quotes:Code:boot -3 "root=/dev/hda4 dsscon=true console=0,115200"
Last edited by mike_s; 04-04-2010 at 02:00 PM.
also, original bootpage looks like the premiere uses sdaX instead of hdaX like it did on previous hardware
Last edited by jt1134; 04-04-2010 at 02:28 PM.
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.
From rc.LoadEarlyCoreDrivers.sh:Code: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?
Additionally, fswak:Code:# 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.
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:Code:fswak -- flash swiss army knife usage: fswak [-c] [-i] [-I] [-lock_FOREVER] [-q] [-p] [-r] [-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 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.
["-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:
Roll that all together and here's a guess of what might be happening:Code:Image has invalid signature length. Image has invalid signature CSD. Image has invalid signature key. Image has wrong SHA (%s).
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?
Last edited by tivo4mevo; 04-04-2010 at 03:35 PM.
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...
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.
Last edited by tivo4mevo; 04-04-2010 at 04:19 PM.
I certainly don't want to discourage further exploration. It's just good to know what obstacles to expect.
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. :-)
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.
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.
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.and doesn't address the residue left on the PCB, which also must be cleaned thoroughly and manually.
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