Direct extraction from a tivo drive in a pc (not networked)

[ronnythunder]

ok, sorry if this is a dumb question, but there's actually three parts to the scrambling keys, right? (1) cso keys (per part) (2) dc keys (per box) and (3) crypto chip key(s) (per box).

so, even with the cso and dc keys, we still can't move streams to another box, right? for example, i have a s1 dtivo that's dead (mobo probs of some kind) and i have scrambled shows on there that i'd like to liberate. i'm sol because of the crypto chip keys, aren't i?

ronny

[rc3105]

ok, sorry if this is a dumb question, but there's actually three parts to the scrambling keys, right? (1) cso keys (per part) (2) dc keys (per box) and (3) crypto chip key(s) (per box).

so, even with the cso and dc keys, we still can't move streams to another box, right? for example, i have a s1 dtivo that's dead (mobo probs of some kind) and i have scrambled shows on there that i'd like to liberate. i'm sol because of the crypto chip keys, aren't i?

ronny

theoretically no. practically, maybe. I've retrieved scrambled streams from a few fried boxes by moving the crypto to a working motherboard

anybody with the soldering skills & a guinea pig dtivo should be able to decrypt your recordings if you can get them your crypto (without destroying it during removal) & a dvd full of tmf scrambles along with the dc key from that drive

[ronnythunder]

if i had a huge pr0n stash on there or something, i might be willing to do that

most of the stuff on my dead machine is just old, forgotten hockey games, so no worries.

ronny

[StanSimmons]

if i had a huge pr0n stash on there or something, i might be willing to do that

most of the stuff on my dead machine is just old, forgotten hockey games, so no worries.

ronny

Maybe KRaveN could move the chip for you. If you can find a live donor box...

[kevinallein]

Hi Jonbig,
today my primary Tivo drive broke. The drive has developed a HW bug in the area of parition 9 (MFS applications). I have a dual drive SA1 Tivo (primary 120G, secondary 30G). Any chance your tool will allow me to save my recordings ? I have some stuff on the Tivo I really would like to have.

I was planing to save of the recordings through turbonet for a long while, now I am not able to boot anymore (any access to hda9 hangs up the Tivo with error messages. I tried to dd hda9 from a MFS backup image, but the HW errors appear hear as well).

Thanks
Kevin

[AlphaWolf]

that's great if you only have 1 scrambled stream, or all your scrambles have the same dc key. if the insert util restores a key from a scramble then anything else on that drive scrambled with a different key just quit working... (and did it backup the old key? did it know which streams were associated with the old key?)

Thats why you don't do that; you store the DC key outside of the normal XML tags as I described, since it is reserved for a special purpose. You only apply the DC key to the tivo if the user specifically requests it. You DO NOT apply it for a casual reinsertion under any circumstances.

The DC key is only a few hundred bytes and it is very relavent for scrambled streams. I don't see any reason to not include and handle it in the manner I described.

[jonbig]

Hi Jonbig,
today my primary Tivo drive broke. The drive has developed a HW bug in the area of parition 9 (MFS applications). I have a dual drive SA1 Tivo (primary 120G, secondary 30G). Any chance your tool will allow me to save my recordings ? I have some stuff on the Tivo I really would like to have.

It may work, but I have a couple of more things I need to clean up before I'm ready to release it. Perhaps by this weekend.

I had to hack my copy of the mfs library to extract stuff from my dead drive, because the MFS superblock got trashed. I'll be releasing it in source form, since the code I used is GPL'd, but you may have to add some code to work around the particular damage in your MFS filesystem. Luckily, the recordings aren't in the partition that you have damage on.

[kevinallein]

It may work, but I have a couple of more things I need to clean up before I'm ready to release it. Perhaps by this weekend.

I had to hack my copy of the mfs library to extract stuff from my dead drive, because the MFS superblock got trashed. I'll be releasing it in source form, since the code I used is GPL'd, but you may have to add some code to work around the particular damage in your MFS filesystem. Luckily, the recordings aren't in the partition that you have damage on.

Thanks, I will hang tight !
Kevin

[kevinallein]

One more question for my preparation: I am using RedHat 9.0 on my linux box. I asume I need a kernel with swapping turned on for your tool ?
So far I never modified the kernel on my main box for swapping, but just booted from a floppy for the Tivo modifications. Since I want to move 150G now I need to get connected to the net when the tivo drive is mounted and change my method here.

Thanks
Kevin

[jonbig]

[QUOTE=kevinallein]One more question for my preparation: I am using RedHat 9.0 on my linux box. I asume I need a kernel with swapping turned on for your tool ?
So far I never modified the kernel on my main box for swapping, but just booted from a floppy for the Tivo modifications. Since I want to move 150G now I need to get connected to the net when the tivo drive is mounted and change my method here./QUOTE]

I'm not particularly familiar with S1 boxes, but I don't think you need to do anything special. The mfs utility functions I am using can access the disk directly through the raw /dev/hd? devices, and appear to have detection and handling of byte-swapping built in.

But then again, since I don't have an S1 box to play with, you'll have to find out definitively for yourself.

[kevinallein]

quote:
I'm not particularly familiar with S1 boxes, but I don't think you need to do anything special. The mfs utility functions I am using can access the disk directly through the raw /dev/hd? devices, and appear to have detection and handling of byte-swapping built in.

But then again, since I don't have an S1 box to play with, you'll have to find out definitively for yourself.[/QUOTE]

Usually both Mips (S2) and PowerPC(S1) run in Big Endian mode (although both have little endian options for WindowsNT support. So if it works for a S2 it will also work for S1. Do you use a stock kernel from a distribution or are you using something done for Tivo (i.e. something based on Dylan's boot disk or so ?)

Kevin

[jonbig]

Do you use a stock kernel from a distribution or are you using something done for Tivo (i.e. something based on Dylan's boot disk or so ?)

I've been running my new tool on a stock RedHat 9 kernel with no problems.

[AlphaWolf]

Tridges mfs code automatically handles byteswapping on S1 drives. No special kernel is required.

BTW: I think the mfs_tmfexport thread was best left separated from this thread, not only because its a separate development effort, but because if vplay (which this is based off of) is any indication, this will probably be able to compile for the tivo architecture (be it S1 or S2,) and will be useful for live TMF extraction, hence reducing the need for buggy/bloatish/slow tivosh.

IMO, merging it with this thread just worsens the thread bloat that so many people complain about.

[rc3105]

BTW: I think the mfs_tmfexport thread was best left separated from this thread, not only because its a separate development effort, but because if vplay (which this is based off of) is any indication, this will probably be able to compile for the tivo architecture (be it S1 or S2,) and will be useful for live TMF extraction, hence reducing the need for buggy/bloatish/slow tivosh.

IMO, merging it with this thread just worsens the thread bloat that so many people complain about.

bloated threads, "censorship" from deleting junk, info spread too thin to be usefull... choose the least of the necesary evils

once mfs_tmfexport is more than vaporware it probably will rate it's own thread - still falls squarely in the direct extraction category

fwiw: olaf's tyserver allready retrieves title/episode/etc from mfs. can be tweaked to produce ty+ easily (hardly more than cut & paste) - tmf is a bit more involved but not much, just borrow a bit of tar code from mfs_tarstream. PII-400 running tyindex/tyserver indexes SO much faster than the tivo, edit/extract/convert on the fly across 100 or tcp/firewire is allso pretty groovy

[jonbig]

once mfs_tmfexport is more than vaporware it probably will rate it's own thread - still falls squarely in the direct extraction category

Yeah, yeah, yeah. I've got a life.

I'm almost done with the changes I wanted to make, so you'll all see it soon.