How to disable tystream encryption to enable extraction

[AlphaWolf]

NOTICE: I am no longer updating this post as its original purpose has been served quite well, which was to transition people from the older more convoluted method to the new and simpler™ method. This kind of thing should now be delegated to the patch threads that show up every time a new version comes around for its respective tivo platform.

Warning: The below instructions should be fairly straightforward, but if you don't have much experience with computers beyond the simple usage of everyday microsoft windows applications, then please do not read any further and leave your tivo in its stock configuration. Thank you.

I was having an IRC discussion, and a leprechaun gave me a special patch for tivoapp that is the end all to be all solution to scrambling on a Tivo (which means that this ISN'T all my work, so do not pass any credits to me)

This patch forces tivoapp to not encrypt recordings by setting a static boolean expression from true to false (its only a two byte patch for all currently existing tivo software versions.)

If you are using an older noscramble method (e.g. kernel patches, modules, kmem, etc) be sure to remove it first. If you are hacking your tivo for the first time, proceed to the first step and ignore the rest of this paragraph. In contrast with the older "noscramble" methods that involved removing the kernel wrapper entirely, encrypted recordings made prior to applying this patch will play back fine. Older noscramble methods may interfere with the tivos ability to play back encrypted streams if you do not want to decrypt them (see below for instructions on decrypting them.)

Note: Legacy Tivo SW versions below 3.1.X will NOT be supported. Also, for StandAlone tivo users, this only applies for 4.x and greater. This does not apply at all to UK tivos.

Do the following for this patch: (FOLLOW THESE INSTRUCTIONS VERY CAREFULLY)

Make sure your root partition is writable. e.g.

mount -o remount,rw /

Make a backup copy of /tvbin/tivoapp e.g.

cp /tvbin/tivoapp /tvbin/tivoapp.orig

Do this number:

cd /tvbin
mv tivoapp tivoapp.tmp
cp tivoapp.tmp tivoapp
chmod 755 tivoapp

If you are an S1 user with Software Version 3.1.0c2, type this command:

echo -ne "\x48\x00\x00\x38" | dd conv=notrunc of=tivoapp bs=1 seek=4678532

If you are an S2 or HDTIVO user with Software Version 3.1.5f, type this command:

echo -ne "\x3C\x02\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=6984684

If you are an S2 user with Software Version 5.1.1b, type this command:

echo -ne "\x24\x02\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=10001408

If you are an S2 user with Software Version 5.2, type this command:

echo -ne "\x24\x02\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=11437232

If you are an S2 user with Software Version 5.3, type this command:

echo -ne "\x24\x02\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=10028224

If you are an S2 user with Software Version 6.2, type this command:

echo -ne "\x3C\x02\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=10705308

If you are an S2 user with Software Version 7.1b, type this command:

echo -ne "\x3C\x02\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=2691728

If you use MFS_FTP, clear out your XML cache, e.g. (assuming mfs_ftp is in /var/mfs_ftp)

rm /var/mfs_ftp/cache/*.xml

For you readonly root types:

mount -o remount,ro /

Then:

reboot

After (not before) the reboot, you can delete the /tvbin/tivoapp.tmp file to free up space on your rootfs.

Continued in the following post.

[AlphaWolf]

If you have not used any noscramble modules/patches/hacks/kmem before, then you are now finished with this part. If you are an S1 user, your next stop is here. If you are an S2 user, your next stop is here.

For the rest of you, theres a catch; nonencrypted recordings that you recorded with a kernel patch or module/kmem will no longer play back. In order to get them to play, you have to nuke their CSO keys so that tivoapp doesn't try to use them unnecessarily. Never fear though; attached is CSOScout.tcl, which is a script that takes care of that process automatically without nuking the CSO keys on scrambled recordings. Note, that you MUST have a working copy of mfs_export on your tivo for this script to work.

Warning: DO NOT USE CSOCSCOUT.TCL WITH UNSCRAMBLE.O

_______________________________

For the sake of reducing support requests, heres a diagnostic tool I whipped up that should help with problems that many people run into.

This script instantly detects whether or not you have TyStream encryption currently enabled, displays the crypto status of all of the recordings that are currently on your tivo, and tells you if each recordings' CSO is set. For the most accurate results, run this script after a fresh reboot when the boot process is entirely completed (after the "acquiring satellite data" step.)

For you newbies: if the "Encrypted" and "CSO Set" values disagree, then the stream in question will not play back properly, and you'll need to run CSOScout.tcl to correct this. If you are trying to copy a non encrypted tream from one tivo to another with mfs_ftp, and it doesn't play back on the other tivo, then you probably need to clear out the XML cache, and extract the stream again. Either that or run CSOScout.tcl on the other tivo after the stream has been inserted.

If the stream is encrypted, then you CANNOT transfer it to another tivo or convert it to mpeg without first decrypting it.

This script requires a binary copy of mfs_export and cat to be present in one of the $PATH directories in order to function.

I have only tested this script on my own tivo, but I don't see any reason why it wont work on any other tivo with SW version 3.X and up.

note to self: ciphercheck.tcl count 358+below, csoscout.tcl count 580+below

[wkearney99]

Originally Posted by AlphaWolf

If you are an S1 user with Software Version 3.1.0b ONLY (not 3.1.0)
If you are an S2 user with Software Version 4.0 ONLY (not 4.0.1)
If you are an S2 user with Software Version 4.0.1 ONLY (not 4.0)

Nice work! Now, what if you're on a 3.1.1b S2 DirecTivo (RCA DVR39)?

What sort of steps did you have to use to find the bytes to patch? I'd be willing to help do the work to dig 'em up on my 3.1.1b unit.

[BubbleLamp]

Heh Alpha, do you know the original values that are being overwritten? I'm still on 2.5.2, and thought maybe if I look for the pattern I can use Hexpad to try and find them. I know the new values might be wrong, but what's a toasted Tivo among friends<g>

[borghe]

It is taking a while running this through all of the tests.. Running it on T60 3.1.0b. Notes:

Works as described. HOWEVER, to extract existing scrambled recordings on a S1 you still need to insmod unscramble.o and play a few seconds of the show. Now the caveat to this is that unscramble would NOT unload from my system after loaded... it kept giving me "Device or resource busy" error. The only way I could get unscramble unloaded was a reboot.. While it was still loaded there were no ill effects, I have just never been a fan of leaving a module loaded when not needed. Also now I would be even more concerned being that unscramble refuses to let itself be unloaded.

Hopefully I will get all of my scrambled recordings off my Tivo one of these days.

edit - unscramble will unload, it just takes a while apparently. I tried it out.. loaded it, once with unscrambling a show right after it loaded and once with loading it and doing nothing, just letting it sit there.. both times it took somewhere bettwen a half hour and an hour for unscramble to free up and finally be able to be unloaded... I copied back my original tivoapp to double check and there were no problems instantly loading and unloading unscramble as desired.. it only happens with this patch.

also since this patch I have been having infrequent but major problems with mfs_ftp in conjunction with unscramble.o. it will load but every once in a while an instance of it will become corrupted and completely unusable. It will constantly terminate connections on any transfer (directory change/list, file transfer, etc) and will need to be unloaded... however most of the time I can reload it then and it will behave just fine. Again, I tried out the same thing with switching to the original tivoapp and it didn't happen. Haven't tried anything with non-scrambled shows (as I didn't have any on my Tivo until after I installed the app).

oh, tytool has no problems.. I did try that. tserver_mfs7 starts up fine and everything transfers fine. I am only having problems with mfs_ftp.

[tytyty]

Originally Posted by wkearney99

Nice work! Now, what if you're on a 3.1.1b S2 DirecTivo (RCA DVR39)?

What sort of steps did you have to use to find the bytes to patch? I'd be willing to help do the work to dig 'em up on my 3.1.1b unit.

A quick check of my original tivoapp on an S2 4.0 at 8593192 shows 03 20 f8 09


YMMV

[RUBiK]

Originally Posted by tytyty

A quick check of my original tivoapp on an S2 4.0 at 8593192 shows 03 20 f8 09

A search for '03 20 F8 09' in a HDVR2 3.1.1.b tivoapp returns 184387 occurances found. DOH! Hrmmmm..

[David Bought]

Originally Posted by tytyty

A quick check of my original tivoapp on an S2 4.0 at 8593192 shows 03 20 f8 09

Nice work, genius. You've discovered the opcode for "jalr $t9", which calls a function in relocatable MIPS code. It can't possibly be used more than, say, 185,000 times in tivoapp... right?

Originally Posted by wkearney99

Nice work! Now, what if you're on a 3.1.1b S2 DirecTivo (RCA DVR39)?

File offset 0x63139c.

P.S. You're still a <flame removed>

[tytyty]

YMMV = Your Mileage May Vary

Try quoting all of post to keep response in perspective.

A disassembly of the app will always yield more information.

[RUBiK]

Originally Posted by David Bought

File offset 0x63139c.

Thanks...

To confirm, on a S2 3.1.1b tivoapp, one would replace the "03 20 F8 09" (jalr $t9) at 0x63139C with "3C 02 00 00" (lui $v0,0 -- not 100% sure here, so don't lynch me, please) with something like:

echo -ne "\x3C\x02\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=6493084

?

Disclaimer: I haven't tried the above myself yet and am not responsible if it doesn't work for anyone who tries it, etc.

EDIT: Had the wrong (S1) 4 bytes for the changes. Changed to what I assume should be correct, analogous AlphaWolf's post above?

[AlphaWolf]

Hmm...I am not sure if I made it clear enough that I am too dumb to find the patch offsets on my own. The csoscout script is the only thing I should really be credited for. Sorry guys but I can't help with any patch related questions for patching any sw versions other than the ones I mentioned (Not only due to the first reason, but I also only have one version of tivoapp in my hands. If you have questions about that one...well, I'll try to help)

I can answer this one:

Originally Posted by Bubblelamp

Heh Alpha, do you know the original values that are being overwritten? I'm still on 2.5.2, and thought maybe if I look for the pattern I can use Hexpad to try and find them. I know the new values might be wrong, but what's a toasted Tivo among friends<g>

Bubblelamp: the original value should be 0x41860038. I can see doing this for 3.1.0, however, 2.5.2 is a very different revision of tivoapp. It's probable that doing a simple byte compare is going to be a needle in a haystack.

Originally Posted by borghe

edit - unscramble will unload, it just takes a while apparently. I tried it out.. loaded it, once with unscrambling a show right after it loaded and once with loading it and doing nothing, just letting it sit there.. both times it took somewhere bettwen a half hour and an hour for unscramble to free up and finally be able to be loaded... I copied back my original tivoapp to double check and there were no problems instantly loading and unloading unscramble as desired.. it only happens with this patch.

I knew I was forgetting to mention something...Thanks for the reminder.

Originally Posted by borghe

also since this patch I have been having infrequent but major problems with mfs_ftp in conjunction with unscramble.o. it will load but every once in a while an instance of it will become corrupted and completely unusable. It will constantly terminate connections on any transfer (directory change/list, file transfer, etc) and will need to be unloaded... however most of the time I can reload it then and it will behave just fine. Again, I tried out the same thing with switching to the original tivoapp and it didn't happen. Haven't tried anything with non-scrambled shows (as I didn't have any on my Tivo until after I installed the app).

oh, tytool has no problems.. I did try that. tserver_mfs7 starts up fine and everything transfers fine. I am only having problems with mfs_ftp.

Well, in terms of the actual tystream itself, this patch has the exact same effect as any of the previous noscramble mods that you are used to. Also, make sure that you are using the latest version of mfs_ftp...this sounds like things that the older versions used to do. If you are, try undoing the tivoapp patch, and see if mfs_ftp still has the same problems. Other than that, ask riley.

[David Bought]

Originally Posted by AlphaWolf

Bubblelamp: the original value should be 0x41860038. I can see doing this for 3.1.0, however, 2.5.2 is a very different revision of tivoapp.

3.1.0 S1 is file offset 0x476248. If you are running 2.5.2 you need to upgrade.

Everything I posted in this thread is untested and may be wrong. If it doesn't work post the exact steps you took.

Originally Posted by tytyty

YMMV = Your Mileage May Vary

Try quoting all of post to keep response in perspective.

Right, it would have taken you at least 5 seconds, easily 10, to figure out that searching and replacing 0320f809 is unworkable.

Think before you post. This is a good thread so don't ruin it by injecting stupidity.

[AlphaWolf]

Originally Posted by David Bought

3.1.0 S1 is file offset 0x476248. If you are running 2.5.2 you need to upgrade.

Everything I posted in this thread is untested and may be wrong. If it doesn't work post the exact steps you took.

Originally Posted by RUBiK

Thanks...

To confirm, on a S2 3.1.1b tivoapp, one would replace the "03 20 F8 09" (jalr $t9) at 0x63139C with "3C 02 00 00" (lui $v0,0 -- not 100% sure here, so don't lynch me, please) with something like:

echo -ne "\x3C\x02\x00\x00" | dd conv=notrunc of=tivoapp bs=1 seek=6493084

?

Disclaimer: I haven't tried the above myself yet and am not responsible if it doesn't work for anyone who tries it, etc.

Once you guys test these and verify that they work, post your results here and I will go ahead and add them to the first post.

[ronnythunder]

Originally Posted by borghe

unscramble will unload, it just takes a while apparently.

i've had this experience with noscramble.o. here's what i did: try the rmmod, if it fails, do a up arrow to recall the command. hit enter to run again. repeat this quickly, over and over, until you start seeing "rmmod: module unscramble not loaded". the trick is that you have to catch it at an instant that it's not in use. it's taken me dozens of tries on occasion.

ronny

[AlphaWolf]

Originally Posted by ronnythunder

i've had this experience with noscramble.o. here's what i did: try the rmmod, if it fails, do a up arrow to recall the command. hit enter to run again. repeat this quickly, over and over, until you start seeing "rmmod: module unscramble not loaded". the trick is that you have to catch it at an instant that it's not in use. it's taken me dozens of tries on occasion.

ronny

#!/bin/bash

while true
do
    echo -n .
    rmmod unscramble > /dev/null 2>&1
    if [ $? == 0 ]; then exit; fi
done