PDA

View Full Version : Ideals for getting past v2.5 lockout



surgeon
09-24-2001, 11:32 PM
I'm going to throw out a suggestion as something to try to get around the v2.5 lockout problem. I've got another DTivo on order and will attempt this myself when it arrives, but I wanted to throw the ideal out for debate on if it might work or not...

To recap via paraphrasing KRavEN, this is the v2.5 boot sequence:

1) prom checksums itself
2) prom checksums kernel partition
3) prom loads kernel into memory & transfers control to it
4) kernel loads initrd into memory & execs linuxrc
5) linuxrc checksums all files on root partition and deletes/replaces all file alterations & reboots if changes were made
6) root switching occurs & /sbin/init is executed, runs rc.sysinit, ect...

It seems to me that until we find someone that can disassemble PPC code and find us a patch for the prom/kernel we need to try something a little more drastic. So my ideal/question is:

"Will the v2.5 software ("myworld" et all) run under a v2.0 kernel?"

What seems to me to be worth a try is the following:

1) upgrade totally to v2.5
2) pull drive & place in p.c.
3) replace v2.5 kernel+initrd with v2.0 versions via dd
4) mark *ALL* files on root partition as "imutable"
5) replace drive & see if "hybrid" system works

Unless there are new exports from the v2.5 kernel then using the v2.0 kernel *should* work... And since the v2.0 initrd will continue to boot even when it sees altered files that are marked "imutable", this *MIGHT* possibly work???

Anyone care to test, comment, or offer additional ideals???

-surgeon-

pasha
09-25-2001, 11:00 AM
Sorry dude,

2.5 kernel and prom have new drivers to support 2 tuners and switch between 2 of them
kernel from 2.0 doesn't work
this is one of the fisrt things I have tried.
only one way is to patch 2.5 PROM to skip checks on itself and kernel partition
new ram disk image have to be created in order to boot it right level.

if you have any debug tools and disassm for PPC this could be done...

KRavEN
09-25-2001, 04:54 PM
Like Eel-sushi, I also tired this right away. To get very far at all you have to edit the rc.sysinit and force the loading of the modules because they won't load by default due to kernel mismatch. Once this is done you can get all the way up with handcraft=true, but if you start myworld, it will always crash due to the kernel not supporting all of the module functions.

Juppers
09-26-2001, 11:33 AM
So as soon as they post their kernel mods, then we may get around that obstacle. Why haven't they released them yet? It is GPL.

BubbaJ
09-26-2001, 02:58 PM
Replace the initrd
Replace the initrd
Replace the initrd

hmm wouldn't it be fun to
Replace the initrd

I'm a lazy bastard.. someone want to .tar.gz /dev/hdX where X is the partition with kernel2.5 and initrd2.5, and send it to me or post it somewhere, so that I can practice mangling it??

Thanx
Bubba

KRavEN
09-27-2001, 03:17 PM
Bubbaj,

Not trying to piss on your wheaties, but like we said before, the prom checksums that kernel partition and the initrd is contained in the kernel partition. So if you change it, then it fails checksum and won't boot.....

There are going to be 3 ways to bypass this as far as I can see:

1. Build a new tivonet adapter that will emulate the tivo debug board exactly and use the built in kernel drivers. This way we would ge a bash prompt no problem.

2. Hack the prom and remove the prom check and the kernel check, then edit and replace the linuxrc in the initrd with the linuxrc used in the 2.0.1 kernel

3. Find a way to generate your own checksum and replace the checksum at the end of the kernel file with one you generated.

surgeon
09-27-2001, 06:35 PM
Originally posted by KRavEN
There are going to be 3 ways to bypass this as far as I can see:

1. Build a new tivonet adapter that will emulate the tivo debug board exactly and use the built in kernel drivers. This way we would ge a bash prompt no problem.

2. Hack the prom and remove the prom check and the kernel check, then edit and replace the linuxrc in the initrd with the linuxrc used in the 2.0.1 kernel

3. Find a way to generate your own checksum and replace the checksum at the end of the kernel file with one you generated.

KRavEN,

One other possibility exists that gets *REALLY* strange but may work via a hardware approach is:

Create 2 separate "A:" drives that are 100% clones of one another.

Make only a simple edit to the rc.sysinit on the 2nd one to provide a bash or other simple instructions. (Probably best done with a hex-editor by over-writing comments in the rc.sysinit file without altering it's location or size on the 2nd disk).

Boot with both drives connected to power & the 1st drive's data-lines connected; let the file-check run against 1st drive's contents and finish; at a moment when drive activity is at a minimum (during "acquirring satellite information"?) *quickly* swap the data-line connection to the 2nd drive & let it now continue the run with the modified rc.sysinit...

While this may seem rather crude and take a lot of trial-and-error to do manually, I'm sure a microcontroller circuit could easily be designed & programed to locate the proper point to do the switchover automatically... Just look at the lengths DTV goes through to produce "hack-proof" access cards only to have someone come along with $25 worth of electronics and "glitch" right through their toughest attempts at security...

And at least this approach doesn't require anyone to learn to disassemble PPC instructions...

-surgeon-

Electron
09-27-2001, 06:49 PM
Question

Is the checksum that is being checked the same for all Dtivos?
Or is it calculated the first time 2.5 is booted ?

Do we know exactly what file is checking the checksum and preventing boot up if it is incorrect?

Is it the kernal itself?

Electron

BubbaJ
09-28-2001, 01:48 PM
KRaVEn: Number 3 is exactly what I'm suggesting, generating a checksum is really not difficult, and as the checksum is in the same partition as the initrd, it REALLY shouldn't be that hard to come up with a little program to rebuild it.

KRavEN
09-28-2001, 02:31 PM
Well, I don;t really code, I can script and edit code, but not come up with anything from scratch, so have at it, please, I would be quite happy to test anything you can come up with.

pasha
10-01-2001, 12:07 PM
FOLKS!!!!

it's not a checksum it's digital signature...
you MUST have PRIVATE key in order to create one...
this signature is checked in PROM
if you can't create correct one your box not gonna boot...

if you can fake this one rest of it would be easy...
other posibility is to get same process and replace public key in PROM....

surgeon
10-01-2001, 03:58 PM
Originally posted by eel-sushi
it's not a checksum it's digital signature...
you MUST have PRIVATE key in order to create one...
this signature is checked in PROM
if you can't create correct one your box not gonna boot...

if you can fake this one rest of it would be easy...
other posibility is to get same process and replace public key in PROM....

OK. So does this mean that the checking program run by the initrd is just looking at a signature appended to the end of the files or is the signature itself a "hash" of the file's contents? And does anyone know anything about the "fastboot" option found in the rom code?

Also does *ANYONE* have a copy of the "IDA Pro Advanced" disassembler as found via this link?

http://www.datarescue.com/idabase/ida.htm

It appears to be what we need to reverse-engineer the PPC code found in the prom and initrd checking modules but at $495 is beyond my reach... Would there be any interest in a "group" purchase via donations made by PayPal?

-surgeon-

pasha
10-01-2001, 06:30 PM
surgeon

PROM hash own image and verify signature against one adden by the end of code...
then it hash kernel partition which include kernel itself and compressed image of romfs and signature....
if both signatures correct and valid for release ( I don't know how it check this part) it will load kernel into the memory...
next kernel will load romfs image into the ramdisk....
( this image has linuxrc executable, signature, and copy of valid rc.sysinit and couple other files )
mount to the /
linuxrc will do next couple steps...
i.e. it will mount actual root to /mnt or something like this...
and scan every file found in this filesystem against some kind of signature on stored in /signature in ramdisk
if it finds any broken file (or moded file) it will delete it and if it has a backup it will replace it with it... and then it will reboot ( in order to check that broken and/or moded files gone i.e. chattr +i no logner works)
or if check is successfull it will change / to actual filesystem umount /initrd clean ramdisk and continue with rc.sysinit





So in order to change anything in kernel partition (even 1 byte) you must know tivo private key and way they signing it... or modify prom to skip this or put your private key into to the PROM so you will be able to sign it...
or get some kind of emulator of tivo debug board
ttyS2 and ether.... ( but this is temporary since in next release they will fix it like they fixed immune bit)

Juppers
10-05-2001, 03:51 PM
What about attacking this from the other side? Forget the prom hacks, digital signatures and such. TiVo has had to leave a way for them to get in and modify things incase of something unexpected that doesn't require a full software upgrade. What we need to look at is the .runme files occasionally downloaded during a daily call. I know that all gets cleared out during a reboot, but if you added a something.runme to /var/packages, and did a chattr +i to it, it should execute during the next daily call, and not get caught by the initrd file checking. While I do think it is checking out the var parition for too many extra files, you could always mount your utils from your unused software partition and just have that mount from the runme. So the real question is what format we need to make the .runme to be able to load modules, start shells, mount drives, and generally let us back in as soon as we do a daily call after a reboot. Then again, those could always just be mfs updates, I don't know, I've never thought to look at them. It just seems a much simplier approach to gaining access back into 2.5. What do you think?

tangee
10-06-2001, 11:57 AM
I had this flash of inspiration too. Looking at the var directory, there are a number of links/files there that are executable. Presumably the Tivo will be executing them at some point during its operations. Seemingly all it would take is a renamed file that spawns a shell then runs the original application.