Watching non-scrambled shows with noscramble disabled

[AlphaWolf]

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?)

[AlphaWolf]

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.

[Disconnect]

There is one problem with that though.

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

[AlphaWolf]

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*

[Disconnect]

Browsing the source today, it goes:

syscall sys_readsectors [fs/read_write.c] ->
f_llop->readsectors == idetivo_readsectors [drivers/block/ide-tivo.c] ->
idetivo_insert_request

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]);

..or, translated,
((*(volatile unsigned long *)(MS2_IDE_SCRAMBLER_0))=(scramble.config.wyrd[0]))
.. or translated again..
*(volatile unsigned long *)(0xFFD00000 + 0x0300)=scramble.config.wyrd[0];

So there is the mediachip encryption. What we do about it is a whole different question...

MsWrite(MS2_CONTROL_REGISTER,MsRead(MS2_CONTROL_REGISTER) | 0x00010000); looks like where its actually doing the encryption, although I'm just guessing.

[AlphaWolf]

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.

[Disconnect]

The problem is, the mediaswitch devices are handled by a module, with no sources:

ls -l /dev/mswitch0
crw-rw-rw- 1 0 0 90, 0 May 26 2002 /dev/mswitch0

cat /proc/devices | grep 90
90 fpga

cat /proc/modules
oslink 36972 11
fpgacombo 15568 6 [oslink]

..unless we can take those apart, we can't even begin to see what its doing. (And, come to think of it, if we -can- take those apart that is the best place to fix the encryption....)

Unless there is more info I'm missing I'm going to pursue this:
crw-rw-rw- 1 0 0 78, 4 May 26 2002 /dev/mpeg0a
crw-rw-rw- 1 0 0 78, 8 May 26 2002 /dev/mpeg0v

... if we redirect those we can get pure mpeg out from anything the tivo can play.

[AlphaWolf]

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.

[BoB-O TiVo]

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.

Opinions?

BoB

[Disconnect]

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.

Dec 4 17:11:01 (none) kernel: Noscramble inode atime: 1022396513 mtime: 1022396513 ctime: 1022396513

Thats on live tv and 2 different streams and works out (roughly) to Sun May 26 03:01:53 2002.

[Silverdude]

* the village ***** that was walking by, whom was being ignored, cause who ever pays attention, speaks up *

The now showing has the date and time the program was saved, couldnt the info be pulled from the same source that it gets it from....

* The village ***** wanders off, cause he is not smart enough to know where he is going, and doesnt have any hope of following this conversation.... *

SD

[Disconnect]

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.

[Disconnect]

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.

Can you plug noscramble_read into that script and give it a shot?

[Disconnect]

Untested (tivo is not with me at work) but this should do it.

- Load both modules at startup, just to be sure.
- If we get 31 and noscramble_loaded == 1, unload it (can we check the rmmod return code here..?)
- If loaded==0, load it

[BubbleLamp]

Originally posted by Disconnect
Untested (tivo is not with me at work) but this should do it.

- Load both modules at startup, just to be sure.
- If we get 31 and noscramble_loaded == 1, unload it (can we check the rmmod return code here..?)
- If loaded==0, load it

I'm no programmer, so excuse me if this is blatantly obvious, but you can grep /proc/modules and look for the presence, absense of noscramble module.