If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Ok another idea popped in my head earlier today, and RC3105 just helped me confirm that its possible. We can make non-scrambled tystreams playable while the noscramble modules/kernel patches are disabled. Yeah this isn't all that useful to all of us who don't keep scrambled recordings (I myself don't), and I know its a bit late in the game, but here it is.

When we export non-scrambled tystreams, then reinsert them, you can disable your noscramble mod, and they play back fine. The reason you can do this is because 2.0 streams still held over passed the upgrades are not scrambled. My theory on this is that since tivo doesn't see any descrambling keys present, it assumes its a 2.0 stream, and plays it back without the error. No I don't have any easy ways for you to do this as it serves no useful purpose to me as none of my shows are scrambled anyways, but I am sure if somebody is dead set, they can come up with a method to easily remove the keys that aren't transfered during the extraction/reinsertion process. Note that doing this on a scrambled stream however will render it useless; meaning it won't unscramble it.

So theres your info, have at it

If anybody finds out what other info is present, so far as where/how the encryption keys are stored, etc, this could lead up to the knowledge necessary for our ability to extract scrambled streams, descramble them, then re-insert them unscrambled...(then again?)

Last edited by AlphaWolf; 12-01-2002 at 02:10 AM.

Before PMing me: I知 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.

I know how you can fix that, slice off the keys or whatever flags are present that indicate the new recording is not a version 2.0 recording a la what happens when we extract and reinsert video, that way the tivo knows its not scrambled and plays it back fine.

Last edited by AlphaWolf; 12-01-2002 at 11:18 AM.

Before PMing me: I知 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.

Noscramble (for those that haven't poked it) just sends NULL instead of the scramble structure on both read and write. (Which is why you can't play scrambled streams with it installed.)

I made some mild progress, as indicated above. The problem is, there seems to be no way to detect whether a stream is scrambled or not; unencrypted/reinserted streams don't hit that code -at all- because of the valid security info. Encrypted and noscramble-unencrypted streams both have valid security information in MFS, regardless of the content of the stream itself. (Farther down the call chain, when the data is actually written to disk, things like the crypt version and keys are put back and streamed to disk.)

Summary:

- Reinserted or old unencrypted stream: Valid security info, some marker (no keys? version?) indicating no encryption.
- New stream: Regardless of stream encryption, encryption data is written to disk. Things like blanking just the keys results in Bad Things (crashes) and the version tag is updated elsewhere in ide-tivo.c so any changes are thrown out.

Code available for anyone who is interested.

Update: It looks like a simple fix in ide-tivo.c (ide-tivodma.c? not sure..). If we can write old security info (version != IO_SCRAMBLE_TIVO_VERSION1) then we can leave the read path alone. But I don't know enough about kernel coding to get hooks into the other funcs

During the tystream encryption, does it encrypt based only on the keys stored to the disk, or does it also encrypt based on physical hardware (mediaswitch?) in your tivo? If it doesn't do the latter, then I imagine unscrambling the streams, which would fix the problem entirely, wouldn't be difficult at all. I imagine that looking at the kernel sources would help somebody determine this.

But, even if you don't go that route, somebody could probably write a simple TCL script that allows you to remove the encryption flags from non encrypted streams by duplicating the stream and deleting the origional. Probably take a minute or so per stream *shrug*

Last edited by AlphaWolf; 12-02-2002 at 06:29 PM.

Before PMing me: I知 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.

And the scramble struct is passed to/from userspace basically unchanged (there are some checks in ide-tivo.c and a bunch of math in ide-tivodma.c)

Passing it around as NULL (what the current noscramble does - f_llop->readsectors and writesectors is repointed) works but somewhere a valid scramble struct is still being generated and written out. (If it was not doing that, all that would need to happen is to change the [edit] writesectors [/edit] to blank that struct and the tivo would play both scrambled and unscrambled with no problems.)

Another interesting thing: In drivers/block/ide-tivodma.c, there is a lot of MsWrite that seems to be deailing with scrambling. And what that seems to do is things like:
#define MsWrite(addr,d) ((*(volatile unsigned long *)(addr))=(d))
MsWrite(MS2_IDE_SCRAMBLER_0,scramble.config.wyrd[0]);

My guess is the Ms in MsWrite is mediaswitch. Just call me captain obvious :P

Sooo...that means the best (and probably only) way of descrambling the video is sending it back through the mediaswitch in the same way that the kernel does when playing it back. A comparison of the 2.0 and 2.5 kernel sources might help with this? Not an easy task unless your pretty good with C, so unless somebody is pretty dead set to descramble the existing streams, it aint happening.

Before PMing me: I知 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.

You would need a PPC assembly guru like Ghost Coder to look at that. Haven't seen or heard from him in 8 months though.

Before PMing me: I知 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.

What if we took a different approach. Why not create a file called "scrambleend" somewhere on a non-mfs partition. Then, the first time noscramble is loaded, it writes the time that it was loaded to scrambleend. Now, whenever we need to do a read, we decide if, based on the time of the recording, we should pass NULL or the actual key data.

OK .. so I read that and went "well thats crap" . Its difficult to get info out of a file from the kernel (not impossible, and if done at module load time it wouldn't be too bad performance-wise) and so forth.

Then I started poking code, just in case.. The problem is that I can't find anything that even hints at times in MFS, at least in the read/write opers (which is all that its easy to steal.)

Basically Tivo said "lets make a userspace fs" .. and they did. Userspace says "get these sectors" .. "write this data to those sectors".. etc.

But IANAKG so maybe I'm missing something.

<Edit>
OK I was missing something. filp->f_inode->i_ctime (in theory) contains the seconds-since-epoch that the inode was created. Unfortunately, it never changes.

Thats all handled by myworld, in userspace. If we could alter myworld we'd be able to do a lot more than this - like decrypting on-disk streams.

In the kernel all we get is a struct file (from include/linux/fs.h) containing "stuff" and a struct inode (same file). And a scramble struct (include/linux/tivo-scramble.h), which has nothing particularly useful.

Attached are the modules I'm currently playing with. They should work (at least, my tivo hasn't exploded yet) as follows:

- noscramble_write.o: load it always on boot. This makes sure all new recordings are unscrambled, but does not affect the read path.
- noscramble_read.o: Load it to play an UNENCRYPTED stream, unload it to play an encrypted one.