Page 11 of 44 FirstFirst ... 91011121321 ... LastLast
Results 151 to 165 of 647

Thread: How to disable tystream encryption to enable extraction

  1. #151
    Join Date
    May 2003
    Posts
    129

    4.0.1b listing?

    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.

  2. #152
    Join Date
    Jan 2002
    Location
    Sonoran Desert
    Posts
    2,831
    Quote 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?
    Before PMing me: Iím not your personal tech support. If you have a question, ask in public so I don't have to repeat if somebody else asks. If you want images or slices, use emule. I will ignore all support PMs.

    Sponsor a vegetarian! I have taken the pledge, how about you?

  3. #153
    Join Date
    Nov 2003
    Posts
    291
    Quote 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

  4. #154
    Join Date
    Apr 2004
    Posts
    36
    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:

    Code:
    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...

  5. #155
    Join Date
    Jul 2003
    Posts
    669

    Fix for crc mismatch errors while running ciphercheck.tcl

    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?
    Four Hacked HDVR2's,
    One Still slightly confused Hacker,
    4 dogs, 8 cats, and 1 wife that is happy as long as I don't screw up her TiVo ...... Oh yeah two grandchildren that are the light of my life!

  6. #156
    Join Date
    Nov 2003
    Posts
    291
    Quote 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.

  7. #157
    Join Date
    Jan 2002
    Location
    Sonoran Desert
    Posts
    2,831
    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)
    Before PMing me: Iím not your personal tech support. If you have a question, ask in public so I don't have to repeat if somebody else asks. If you want images or slices, use emule. I will ignore all support PMs.

    Sponsor a vegetarian! I have taken the pledge, how about you?

  8. #158
    Join Date
    Nov 2003
    Posts
    291
    Quote 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.

  9. #159
    Join Date
    Jan 2002
    Location
    Sonoran Desert
    Posts
    2,831
    Ok, fixed both csoscout.tcl and ciphercheck.tcl to work in more situations.
    Before PMing me: Iím not your personal tech support. If you have a question, ask in public so I don't have to repeat if somebody else asks. If you want images or slices, use emule. I will ignore all support PMs.

    Sponsor a vegetarian! I have taken the pledge, how about you?

  10. #160
    Join Date
    May 2002
    Posts
    314
    Quote 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!
    Last edited by MuscleNerd; 04-18-2004 at 01:33 PM.

  11. #161
    Join Date
    Jan 2002
    Location
    Sonoran Desert
    Posts
    2,831
    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.
    Before PMing me: Iím not your personal tech support. If you have a question, ask in public so I don't have to repeat if somebody else asks. If you want images or slices, use emule. I will ignore all support PMs.

    Sponsor a vegetarian! I have taken the pledge, how about you?

  12. #162
    Join Date
    Feb 2004
    Posts
    2

    play encrypted stream with s2 hdvr2 running tivoapp edit'

    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?

  13. #163
    Join Date
    Nov 2003
    Posts
    291
    Quote 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.

  14. #164
    Join Date
    Feb 2004
    Posts
    2
    Quote 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
    Code:
    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
    Code:
    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?

  15. #165
    Join Date
    Aug 2003
    Posts
    1,285
    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •