Packet dump needed of MRV transfer

[Jamie]

Oh right, there would be the mpeg2 transport stream to program stream conversion as well. But that should be computationally fairly easy - more like reformatting the streams than re-muxing. The program stream is already muxed at the correct rate and with all the timestamps. For reference, notice how quickly videoredo can perform a ts->ps rewrite.

That's what I've always thought (that the DRM processing is the bottleneck), but the TCF crowd (supported by TiVoPony, I think) have always disputed that and insisted that the reformat/remuxing was the issue with slow TTG transfers.

[bcc]

That's what I've always thought (that the DRM processing is the bottleneck), but the TCF crowd (supported by TiVoPony, I think) have always disputed that and insisted that the reformat/remuxing was the issue with slow TTG transfers.

I guess I wouldn't put it past tivo to implement the conversion in such a way that it does cause a performance impact But I also wouldn't give TCF users so much credit. If someone over there mentions reformatting overheard they probably don't know whether they mean Qualcomm cipher and/or transport stream conversion.

Speaking of TCF, anyone notice that their forum says .tivo conversion discussion is not allowed, yet talk of programs performing such conversion is widespread?
Apparently it's ok to talk about videoredo, and tivodecode manager performing the very same conversion. It seems like tivo is happy to let these programs fill in the functionality gaps left by their own tivoserver. Sanctioned DRM violations?

[bcc]

So in the packet tracing of MRV, does MRV actually use the &Format=video%2Fx-tivo-raw-tts format spec? If so, this suggests that the two boxes are sharing scrambling information. That in turn would suggest that the scrambling keys/seed/whatever are transmitted between the MRV boxes, and it may be easy to sniff that information.

[Jamie]

So in the packet tracing of MRV, does MRV actually use the &Format=video%2Fx-tivo-raw-tts format spec? If so, this suggests that the two boxes are sharing scrambling information. That in turn would suggest that the scrambling keys/seed/whatever are transmitted between the MRV boxes, and it may be easy to sniff that information.

There was an fcc filling from tivo that goes over how the "old style" MRV key exchange works. They called it "TiVoGuard", at the time. I think it was this one. I don't think it was trivially snoopable. Could be different now though, as MRV has obviously been significantly changed.

[moyekj]

So in the packet tracing of MRV, does MRV actually use the &Format=video%2Fx-tivo-raw-tts format spec? If so, this suggests that the two boxes are sharing scrambling information. That in turn would suggest that the scrambling keys/seed/whatever are transmitted between the MRV boxes, and it may be easy to sniff that information.

Yes, this is how I found out about the that format spec - by putting my Tivos and PC on the same hub, starting packet sniffer, and then initiating an MRV transfer. I have the packet dump of that experiment saved. You can find it here:
http://replayguide.sourceforge.net/mrvTransfer.pcap

[AlphaWolf]

Of course, I assume the copy protection bits restrict what you can extract via http, while you have no so restrictions with mfs_ftp.

But what is stopping us from neutering such bits?

[Jamie]

But what is stopping us from neutering such bits?

Well, the context here was on an unhacked tivo, so I'd guess I'd say the tivo PROM. On a hacked tivo, of course, you can zap that stuff, at least on unencrypted recordings. If I remember right, you can't play back encrypted recordings at all if you modify the Drm data structures. They are "signed" and you'd probably have to find a way to bypass the signature checks to get encrypted recordings to play.

[AlphaWolf]

Well, the context here was on an unhacked tivo, so I'd guess I'd say the tivo PROM. On a hacked tivo, of course, you can zap that stuff.

Ah, I misinterpreted that.

[bcc]

Yes, this is how I found out about the that format spec - by putting my Tivos and PC on the same hub, starting packet sniffer, and then initiating an MRV transfer. I have the packet dump of that experiment saved. You can find it here:
http://replayguide.sourceforge.net/mrvTransfer.pcap

So then the scrambling algorithm is two-way and can be descrambled on a box other than the one that did the scrambling.

So have you found the scrambling info being negotated between the tivos (and what the scrambling algorithm is)? If tivo was careful, it'd be encrypted with the MRV certificate's key, but who knows, perhaps the algorithm only requires the box's service number.

[moyekj]

So then the scrambling algorithm is two-way and can be descrambled on a box other than the one that did the scrambling.

So have you found the scrambling info being negotated between the tivos (and what the scrambling algorithm is)? If tivo was careful, it'd be encrypted with the MRV certificate's key, but who knows, perhaps the algorithm only requires the box's service number.

If you look at the Wireshark (ethereal) dump I gave in above post there is some authentication information being exchanged between boxes prior to the actual transfer taking place. If it's any help interpreting the dump:
PC = 192.168.1.100
Bedroom S3 = 192.168.1.107
LivingRoom S3 = 192.168.1.101
Sequence followed once packet sniffing enabled:
1. Start packet sniffer on PC (with Wireshark)
2. From Bedroom S3 browse Now Playing List of LivingRoom S3
3. Scroll down and select Grey's Anatomy and push into it's description
4. Initiate a transfer
5. Turn off packet sniffing after about 1 minute into the transfer

[bcc]

If you look at the Wireshark (ethereal) dump I gave in above post there is some authentication information being exchanged between boxes prior to the actual transfer taking place. If it's any help interpreting the above dump:
PC = 192.168.1.100
Bedroom S3 = 192.168.1.107
LivingRoom S3 = 192.168.1.101
Sequence followed once packet sniffing enabled:
1. Start packet sniffer on PC (with Wireshark)
2. From Bedroom S3 browse Now Playing List of LivingRoom S3
3. Scroll down and select Grey's Anatomy and push into it's description
4. Initiate a transfer
5. Turn off packet sniffing after about 1 minute into the transfer

Thanks, yes, I can see those 2 boxes communicating, the request for Grey's Anatomy, etc.. The session would involve authenticating using the MAK. But my questions were lower level than that. Personally I don't plan on figuring out their scrambling algorithm. But you might, if you're serious about extracting your streams without DRM and without a prom mod.

[moyekj]

Thanks, yes, I can see those 2 boxes communicating, the request for Grey's Anatomy, etc.. The session would involve authenticating using the MAK. But my questions were lower level than that. Personally I don't plan on figuring out their scrambling algorithm. But you might, if you're serious about extracting your streams without DRM and without a prom mod.

I don't have a heck of a lot of motivation to do it either, but perhaps the OP does (if he ever shows up in this thread). After all we are only talking about a ~2x speedup over regular TTG transfers - if it was 5-10x I would be more motivated.

Do you know the actual mechanics taking place for MRV? Is the originating S3 unencrypting and then re-encrypting the stream prior to transfer? You mentioned about a 35Mbps ceiling on transfers with the video format flag but did you determine what is limiting the speed? Is CPU still the bottleneck? It would be good (if you haven't already) to closely monitor resources on the Tivo ("top" or similar util) during a transfer to see if CPU is maxing out.

[bcc]

I don't have a heck of a lot of motivation to do it either, but perhaps the OP does (if he ever shows up in this thread). After all we are only talking about a ~2x speedup over regular TTG transfers - if it was 5-10x I would be more motivated.

Well it was just over 3X in my test without any performance tuning.

Do you know the actual mechanics taking place for MRV? Is the originating S3 unencrypting and then re-encrypting the stream prior to transfer? You mentioned about a 35Mbps ceiling on transfers with the video format flag but did you determine what is limiting the speed? Is CPU still the bottleneck? It would be good (if you haven't already) to closely monitor resources on the Tivo ("top" or similar util) during a transfer to see if CPU is maxing out.

The stream transmitted on the wire for s3<->s3 is apparently the same as what is on disk. When the file on disk is unscrambled, the transmitted copy is unscrambled as well. When the original is scrambled (as is on an unmoded system) the version on the wire is scrambled exactly like it was on the source machine's disk.

When I mentioned 35Mbps that was an average, sustained rate, not a peak rate.
I didn't check if it was CPU, disk, bus or what that was the bottleneck. Someone would have to start paying me before I'd do a thorough performance analysis.
However, folks especially jamie have looked into that more closely in the performance derby thread.

[mikesown]

I don't have a heck of a lot of motivation to do it either, but perhaps the OP does (if he ever shows up in this thread). After all we are only talking about a ~2x speedup over regular TTG transfers - if it was 5-10x I would be more motivated.

Do you know the actual mechanics taking place for MRV? Is the originating S3 unencrypting and then re-encrypting the stream prior to transfer? You mentioned about a 35Mbps ceiling on transfers with the video format flag but did you determine what is limiting the speed? Is CPU still the bottleneck? It would be good (if you haven't already) to closely monitor resources on the Tivo ("top" or similar util) during a transfer to see if CPU is maxing out.

I'm around here... lurking . My main motivation is indeed the transfer time. Another motivation is being able to transfer HD in realtime on a THD unit(TTG is too slow with the THD). Due to this transfer increase, I think it would be possible(and cool) to have a player like VLC support streaming directly, so we could watch the file as it downloads(without stopping and starting it).

For the MRV mechanism, I'll be honest in saying that this information is just what I've heard lurking around here and TCF, but my impression is that the THD has a hardware encryption/decryption mechanism which the file is fed through to decrypt it. I would speculate that the file is transfered natively, and the same hardware is used to perform the decryption on the second box. I would also speculate that the main limiting factor now(when using the new native stream method) is the kernel's drivers for the ethernet controller. I remember someone posting benchmarks of .ty transfers using mfs_ftp where using the native kernel was about 30mbit, whereas using a modified kernel, with external adapter supporting jumbo frames, the transfer went up to 75mbit. There's not much we can do about this, but if Tivo opts to upgrade the drivers, the speed would likely see a big increase.

[lrhorer]

I aim to develop an MRV emulator for the PC so that transfers will go much faster than TTG.

Are you still planning to move ahead with this? I am certainly interested. I don't really care that the content can't be played on a PC. I just want to be able to move it off the TiVo and on to the server to free up space, and then to watch it real-time on the TiVo when I want. TTCB is not fast enough to handle real-time transfers if the bit rate is greater than roughly 15 or 16 Mbps. Even with 12 Mbps video, I find one needs to buffer at least 30 seconds or so or risk a pause during the show.