How to disable tystream encryption to enable extraction

[tivosohn]

Has anyone figured out the problem Miles posted a couple of months back of the ciphercheck doesn't show any listing even there are movies recording and listed in the "Now Showing" screen? I am seeing this problem as well. Here's the output.


tivo:/var/hack$ ./ciphercheck.tcl

TyStream encryption is currently disabled.

Here is the status of your current recordings:

Encrypted CSO Set Stream Name
--------- ------- -----------------------------------------------------------

tivo:/var/hack$ exit


Thanks.

[AlphaWolf]

Originally Posted by tivosohn

Has anyone figured out the problem Miles posted a couple of months back of the ciphercheck doesn't show any listing even there are movies recording and listed in the "Now Showing" screen?

My guess is that the reason it is doing this is due to differences in the MFS directory tree structure. Unfortunately, I don't run 4.0, so I don't know exactly what to look for and what changes to make for compatibility. Somebody else will have to document this to me so I can make the necessary changes.

BTW mods, what happened to the adhesive tape on this thread?

[BTUx9]

Originally Posted by AlphaWolf

My guess is that the reason it is doing this is due to differences in the MFS directory tree structure.

Absolutely correct. Changing "/Recording/NowShowingByTitle" to "/Recording/NowShowingByClassic" fixes the problem. Here's a modified version that runs on v4.x

[Deven]

Disclaimer: I'm new to this forum (though I've been on tivocommunity.com for years), and I haven't hacked the software on my TiVo units yet (SAT-T60 and DSR6000), though I've added extra disk space to both. So, in one sense, I'm a newbie, but I'm also a very experienced computer programmer and Linux user. Once I find the time to backup my systems and install the CacheCards I bought at Christmas, I look forward to hacking the software on my TiVo's.

A couple thoughts after reading this thread:

There's no need for the ".tmp" dance to avoid the "Text file busy" error. Instead, simply rename the original (running) copy instead, then copy back. Include the -p flag to copy the modes and save the need for the chmod. It's a good idea to include the -i flag to help prevent anyone from accidently overwriting their backup with a hacked copy. Finally, use the exit status from the rename to determine whether to copy back, and the whole backup operation becomes a one-liner:

mv -i /tvbin/tivoapp /tvbin/tivoapp.orig && cp -pi /tvbin/tivoapp.orig /tvbin/tivoapp

Also, while the "echo ... | dd ..." solution can perform the patch, it's very fragile, since it just blindly writes the bytes at a particular offset. It would be much more reliable to perform a search-and-replace operation looking for the original bytes and replacing them. However, this would require a signature long enough to be unique in the entire tivoapp to match, not just the bytes that need to be changed. There's a good chance that a good signature would be able to cleanly patch many different versions, since the surrounding code is likely identical in multiple versions.

There's a bit of a balancing act here -- the longer the signature is, the less chance there is of finding the signature twice, but longer signatures will be more likely to overlap unrelated code that might vary from version to version. The longer signature will work fine on the version it was made for, but a shorter signature might do the job equally well and work on more versions.

Ideally, someone who has disassembled the code and understands what it's doing could tell us (for both Series 1 and Series 2) all the bytes in that section of code, without including unrelated code, and which of those bytes need to be changed. Once the signature is known, implementing the search and replace operation is a simple matter of programming. I'd be happy to implement the operation if someone gives me the signature information, but I'll need to know what tools are available to do the job. Ideally, I'd like to use Perl, but it seems unlikely to be installed. I'm certain I can find a way to implement it, but it may have to wait until I have a bash prompt on my TiVo, so I can see what tools are available...

[tivomaster]

I have an HDVR2 that throws crc mismatch errors when mfs_export does it's thing. I never have had it cause any problems but I could not get ciphercheck to run. It errored out like so:

exporting fsid 971124 of size 268435456 to /tmp/scrambletest
starting at 0 for 4 bytes
100%
crc mismatch len=4608 0xfb5610f8 0x20b95196
crc mismatch len=17408 0x44d3ed3c 0x3dee7d81
while executing
"exec mfs_export -c 4 $part /tmp/scrambletest"
(procedure "crypcheck" line 2)
invoked from within
"crypcheck $fsid"
("uplevel" body line 8)
invoked from within
"uplevel $body"
invoked from within
"transaction {uplevel $body}"
(procedure "RetryTransaction" line 5)
invoked from within
"RetryTransaction {
set objindex [strim [mfs scan /Recording/LiveCache -start "" -count 1]]
set fsid [lindex $objindex 0]
set obj [db $db o..."
(file "/var/hack/bin/ciphercheck.tcl" line 44)

I found if I change the line
exec mfs_export -c 4 $part /tmp/scrambletest
to read
catch {exec mfs_export -c 4 $part /tmp/scrambletest}

It would execute just fine..
Encrypted CSO Set Stream Name
--------- ------- -----------------------
No Yes 3rd Rock From the Sun
No Yes Back to School

This change forces it to ignore the crc "errors"...

I have one question.
Right now I am running a bash env HDVR2 with 3.1.0 OS and the KMEM hack. I am going to convert to a montied 3.1.1c OS with tivoapp hack (same box). Are the recordings I archived going to have to be ran though csoscout before they are viewable on the new OS?

[BTUx9]

Originally Posted by tivomaster

I have one question.
Right now I am running a bash env HDVR2 with 3.1.0 OS and the KMEM hack. I am going to convert to a montied 3.1.1c OS with tivoapp hack (same box). Are the recordings I archived going to have to be ran though csoscout before they are viewable on the new OS?

Yes, you have to run csoscout. The kmem hack results in invalid CSO keys that have to be nuked to run on a tivo that's not running kmem, even if the box and DC key are the same.

[AlphaWolf]

mfs_export returns the crc mismatch error on occasion for some reason, and I haven't been able to reproduce the problem. I am thinking that it may be due to the fact that the mfs_export that people use have been altered from tridges original, and there could have been a bug introduced (notice the "Priority set..." message that it displays, tridges originals didn't do this)

[BTUx9]

Originally Posted by AlphaWolf

mfs_export returns the crc mismatch error on occasion for some reason, and I haven't been able to reproduce the problem. I am thinking that it may be due to the fact that the mfs_export that people use have been altered from tridges original, and there could have been a bug introduced (notice the "Priority set..." message that it displays, tridges originals didn't do this)

I doubt it's a problem with a modified binary. It seems to be tivo SW version related. I've seen it quite often on my HDVR2s running 3.x, but it goes away after a reboot. Since it's just a warning, and doesn't seem to affect the export, I think the catch is a good solution.

[AlphaWolf]

Ok, fixed both csoscout.tcl and ciphercheck.tcl to work in more situations.

[MuscleNerd]

Originally Posted by Deven

Also, while the "echo ... | dd ..." solution can perform the patch, it's very fragile, since it just blindly writes the bytes at a particular offset. It would be much more reliable to perform a search-and-replace operation looking for the original bytes and replacing them

Yeah but that wouldn't have nearly the "impact" that these one-liners do. As long as people know what version they're running, they should be set. If they don't even know their version, they probably will mess up other things soon too.

(Also..I'm fairly certain that every unique tivoapp version on every platform happens to have a unique file length -- that's an easy enough footprint).

But I hear you. The tivoapp patch programs I release have generally done some simple sanity checking before patching. But one-liners are fun, too!

[AlphaWolf]

I personally prefer the one line approach whenever I make random patches to binaries. It's very quick, and it allows you to get things done in the least number of steps.

[scr33n]

Hi there, this is my first time posting and I hope this is the right place.

I'm running a monte'd HDVR2 with the tivoapp hex edit for 3.1.1b and I'm trying to play an pre monte scrambled recording. I extracted the recording from my original tivo disk using mfs_tmfstream and restored it to the tivo using mfs_ftp. The stream will not play on the tivo. It's my understanding with this hack that I should be able to play shows that were scrambled on this tivo prior to the monte as long as my DiskConfiguration key is the same,the CSO Key is present (which it should be thanks to tmf), and the crypto chip is the same. I've verified the diskconfiguration key and the CSO key to the best of my ability and all looks in order. I've run the csosout.tcl script and verified with ciphercheck.tcl. Am I missing something here?

[BTUx9]

Originally Posted by scr33n

I've verified the diskconfiguration key and the CSO key to the best of my ability and all looks in order. I've run the csosout.tcl script and verified with ciphercheck.tcl. Am I missing something here?

Have you verified that the kmem line has been removed from your rc.sysinit.author (if it was placed there by sleeper's script). That would lead to the problem you've been describing.

[scr33n]

Originally Posted by BTUx9

Have you verified that the kmem line has been removed from your rc.sysinit.author (if it was placed there by sleeper's script). That would lead to the problem you've been describing.

Thanks for the quick reply. I commented it out myself (as I inserted in myself when I built the rc.sysinit.author file) and have since rebooted. I'm pretty positive it's not running as I log each entry in this file.

/etc/rc.d/rc.sysinit.author

date>>/var/hack/hackinit.log
echo starting tserver_mfs7. >> /var/hack/hackinit.log
tserver_mfs7 &
#echo starting kmem. >> /var/hack/hackinit.log
#kmem 800b23b4 00001021
# Call the Tivo Package Manager Startup Scripts
echo starting rcS.d packages. >> /var/hack/hackinit.log
/etc/rc.d/rc.sysinit.tpm

/var/hackinit.log

Tue Apr 20 08:53:09 UTC 2004
starting tserver_mfs7.
starting rcS.d packages.

I'm assuming then my assumptions are correct then and there's something awry. Any other ideas?

[Sleeper]

Originally Posted by scr33n

I'm assuming then my assumptions are correct then and there's something awry. Any other ideas?

I would verify with a Hex editor that tivoapp is patched in the correct location with the correct value. I have not heard of any problems but there could be a problem with one of the noscramble2 tpm's.

S.