.tivo file format (split from: Decrypting TiVo ToGo)

[ezrec]

.tivo files are chunked according to the following structure:

/* All elements are in big-endian format */
typedef struct tivo_stream_header_s {
        char filetype[4];       /* the string 'TiVo' */
        uint16_t dummy_0004;
        uint16_t dummy_0006;
        uint16_t dummy_0008;
        uint32_t mpeg_offset;   /* 0-based offset of MPEG stream */
        uint16_t chunks;        /* Number of metadata chunks */
        struct tivo_stream_chunk_s *chunk;
} __attribute__((packed)) tivo_stream_header;

#define TIVO_CHUNK_XML  0
#define TIVO_CHUNK_BLOB 1

typedef struct tivo_stream_chunk_s {
        uint32_t chunk_size;    /* Size of chunk */
        uint32_t data_size;     /* Length of the payload */
        uint16_t id;            /* Chunk ID */
        uint16_t type;          /* Subtype */
        const uint8_t *data;
} __attribute__((packed)) tivo_stream_chunk;

The 'BLOB' types appear to be either (a) compressed or (b) encrypted, as they have very high entropy. (ie, can't be compressed). The 'BLOB' sizes seem to get longer for longer .tivo streams.

Chunk Type XML has the following text:

<?xml version="1.0" encoding="utf-8"?>
<license xmlns="http://www.tivo.com/developer/xml/license-1.0">
<notice>
TiVo takes copyright violations seriously.  This file may contain
content protected by copyright laws.  If you are not the owner or rights
holder of such content, you should be aware that if you distribute this
file or otherwise make it available to anyone else, you may be violating the
intellectual property rights of the owners of the content contained in this
file.  If you are not the owner or rights holder of such content, and if you
are a TiVo customer, and if you distribute this file or otherwise make it
available to anyone else, you may be violating the service agreement.
We may permanently discontinue your TiVo service as a result.
</notice>
<created>
01/12/2005 11:22:01
</created>
<fingerprint>
... hex string that is 224 hex digits long ....
</fingerprint>
<salt>
... hex string that is 32 hex digits long...
</salt>
</license>

For example, a stream off of my machine has:

TiVo Stream:
        filetype: TiVo
        dummy_0004:     0x0004              // Possibly format version?
        dummy_0006:     0x0001              // Possibly format minor version?
        dummy_0008:     0x0000
        mpeg_offset:    0x00003000
        chunks: 0x0003
Chunk 0:
        chunk_size:    0x00000474
        data_size:     0x00000463
        id:    0x0003
        type:  0x0000
Chunk 1:
        chunk_size:    0x00000f54
        data_size:     0x00000f44
        id:    0x0001
        type:  0x0001
Chunk 2:
        chunk_size:    0x00001434
        data_size:     0x00001422
        id:    0x0002
        type:  0x0001

I couldn't find any references to .ty stream format on the web, but for those that do know, does this look similar?

[alldeadhomiez]

Moved to Extraction Dev.

tystream info:

http://dvd-create.sourceforge.net/ty...tystream.shtml
http://alt.org/forum/index.php?t=msg...&start=0&rid=0
http://alt.org/forum/index.php?t=msg...&start=0&rid=0

tydemux/tystudio sources: http://dvd-create.sourceforge.net/ty...download.shtml

[linux_mofo]

I just got the TiVoToGo update and am poking around. I'd love to get VLC to work directly with .TiVo files. A couple notes:

Eventhough the files are encrypted, we should have the decryption key (the MAK?). I think it is 4 bytes long. The salt (file specific) is 16 bytes long. So that's a 20 byte decryption key. The files are easily parsed to find the encrypted chunks. Pull a chunk out, decrypt with different methods using the key (it might also take some experimentation to figure out if it is MAK padded with salt, the other way around, or something else?) using different cipher methods to see what works.(?)

It's difficult to find the current status on the effort to decrypt these things other than using round-about methods in a Windoze-only environment. Any pointers to current info, or is this it? :')


-Phil

[alldeadhomiez]

http://www.alt.org/wiki/index.php/TiVoToGo

[ezrec]

I have updated the link that Admin posted with my 'tivoinfo' program that dumps out the header info, and saves the encrypted mpeg stream from the TiVo file.

[ezrec]

Someone might want to try recoding a completely blank video stream (no video input, no audio input). That should result in a much easier to decode crypto stream, as the GOPs will be predictable.

[linux_mofo]

Humm, have you looked at the DirectShow dll? Some interesting pieces of text in there, and lots of debugging info!

A few choice/random things found in that file:

TivoMpegFileStream *
Mpeg2Lib::TivoMpegDecrypt *
Mpeg2Lib::TivoMediaFile
Mpeg2Lib::TivoMpegDecrypt
_STL::auto_ptr<Mpeg>
_STL::auto_ptr<MpegProgramStreamDecrypt>
MediaPasswordDialog
ResourceString *
MediaAccessKey *
MediaAccessKey
CryptoLib::Cypher
CryptoLib::Data
MpegProgramStreamDecrypt
Mpeg2Lib::PcMpeg
Mpeg
MpegTuring

ref<Turing> *
TuringFast *
TuringRef *
TuringTable *
Turing *
Turing
TuringTable
TuringRef
TuringFast
ref<TuringFast>
ref<TuringFast> *
Q@YY]
[YY]
ref<TuringTable>
ref<TuringTable> *
8luY
MpegData *
ref<MpegData> *
MpegData
MpegBlowfish *
MpegTuring::CipherStream *
Borland C++ - Copyright 2002 Borland Corporation
Incorrect media access key or data file is damaged.

Software\TiVo\DirectShow\Volume
TiVo PCM boost filter
Multiplier
TiVoToGo Metadata
TiVoToGo Media
TiVoToGo Transfer
tivo:TiVo DVR:
tivo:transfer:
basic_string
MediaPasswordDialog
Error
Password incorrect
Src\crypt\Turing.C
Turing::Create
hexkey should start with 0x or 0X
Key length exceeds 448 bits
Hexadecimal key contains non-hex digit %c
Hexadecimal key contains non-even number of digits
Residue error, out of zeros at offset %ld
MpegBlowfish::Initialize(%s)
BLOWFISH KEY=0x
%02X
MpegBlowfish::Seek(%lld)
TURING KEY=0x
%02X
PLAYBACK_STREAM_KEY[0x%02x]=0x
%02X
BLOCK_IV[0x%02x,%ld]=0x
invalid video offset, not a multiple of 1024 (%ld)
invalid video offset
invalid key %s
no key to 

*** TiVo File header, videoOffset=%ld, count=%d, flags=0x%x
*** 0x%04x: TiVo Public (%d bytes)
*** 0x%04x: TiVo Private (%d bytes)
*** 0x%04x: License Agreement (%d bytes)
*** 0x%04x: Unknown (%d bytes)decrypt meta data

%012lld: adler32 checksum mismatch 0x%lx != 0x%lx
%012lld: 0x%02x skip=%d
%012lld: no key was provided
%012lld: 0x%02x block=%ld/%ld/%d, flags=0x%02x, cs=0x%lx/0x%lx
%012lld: 0x%02x data=%d

Software\TiVo\SharingKeys

[ezrec]

For the Turing stream cypher, look no further than QualComm, who has kindly
placed on the web the EXACT SAME SOURCE CODE that TiVo used in their stream cypher.

http://www.qualcomm.com.au/Turing.html

Time for the fun to begin!

[linux_mofo]

Originally Posted by ezrec

For the Turing stream cypher, look no further than QualComm, who has kindly
placed on the web the EXACT SAME SOURCE CODE that TiVo used in their stream cypher.

http://www.qualcomm.com.au/Turing.html

Time for the fun to begin!

Yeah, I noticed that too. Although it's not obvious to me that it is the same exact source code. How did you determine that?

BTW- I needed to comment out the endian.h and byteorder.h includes and make dummy functions (which do nothing but pass values through) for __be32_to_cpu and __be16_to_cpu to make it work on MacOS-X. Namely, I put this

#ifdef __ppc__
int32_t __be32_to_cpu(int32_t data) { return data; }
int16_t __be16_to_cpu(int16_t data) { return data; }
#endif

in near the top of tivo.c.

It gives identical output as my x86 Linux box.

It shouldn't be too hard to determine if the decryption works. The first chunk is smallish and of a special type (0). Must be the meta info, which is probably largely text. Perhaps all XML.

Post any progress you make! :')

[linux_mofo]

The Turing key size is 16 bytes and the "playback stream key" is 20. At least according to the debugging routines in the dll.

[linux_mofo]

Turing keys differ completely between files and don't resemble anything contained in a TiVo file, text or binary (including salt, sorry). But, they do remain the same between plays of the same file, even from different players (which are obviously using the same tivo dll for decoding).

BTW- I suggest throwing REC and IDA at the dll. I downloaded the Windows debugger and am using it for the first time tonight and am pulling keys. I think it's the only reasonable way to make progress. Especially if the keys aren't becoming as obvious as hoped. :'(

[ezrec]

At the TiVoToGo Wiki , we have discovered quite a bit about the encrypted streams. Please go there and check it out! We'd love your contributions.

[linux_mofo]

Nice work ezrec and fdm!

Poking around with the dll some more, I noticed that stream keys are changing a lot (breakpoints hit several times when playing a file), but once the file begins to play, the keys don't seem to change.

I've spent some time today creating an initial draft of a function flow chart. I've tried to spend a lot of time eliminating things which aren't interesting (hard to do since we don't know really what's interesting yet). The file is a mere 80K, but there is a huge amount of detail and not a lot of helpful hints in it that show what the functions do.

I can give a brief walkthrough, though:

First of all, the very top (sub_4075F8) is Mpeg2Lib::TivoMpegDecrypt.

In rough quarters of the document from left to right, the left is final cleanup and setup code for the dll. Pretty uninteresting to us.

The second fourth which is a little below the first is the Turing code, playback stream decode, and block_IV decrypt. Probably the most interesting! In this quarter sub_42549C is the function which has the Turing key debug code. The cluster to the right of it (sub_4257F0) is where we find the Playback stream key debug code. Lastly, just to the right of it is sub_425A1C which has the reference to BLOCK_IV.

Third fourth of the document and a little in the middle is the file access and registry routines. Reference to Tivo meta-data is on the right side of this quarter.

The last quarter is the password dialog box. Also are the references to CryptUnprotectData and CryptProtectData. Ignore the widows on the very upper right. Those were supposed to be deleted.

- Something to note. The software tries to lay out all the functions in such a way as to keep functions that call each other close to each other. Notice how far away the CryptProtect functions are from the Turing fuctions, yet close to the registry, file access, and password dialog functions?

[linux_mofo]

OK, sorry for the delay. Here is a *much* easier to understand graph.

I spaced it out a bit vertically, removed a vast majority of the uninteresting functions, color-coded by memory location (similar colors mean similar location in the lib which I would infer to mean the same source file), and numbered the edges (connecting lines) in the order that they are referenced in the calling function. The first edge (the first call) is unnumbered to help unclutter things. Notice that this graph has no information on flow control on the edges (if's, loops, etc.). Lastly, I added some nodes with string references that use gray edges to show where interesting strings are found.

It still begs to be printed out on several pieces of paper and taped together to be understood, but at least now you should be able to understand and follow most things without being overwhelmed (as much ;') and can see where edges go without them being lost.

BTW-This was created from a 'dot' file which in turn was produced by a Perl script that parses the .gdl file from IDA. Post a reply if you'd like to see either of these.

[ezrec]

Very useful.

Over the weekend, I plan to use this to help decode the 'Tivo Sharing Keys' in the registry, and I'll describe my results (if any) on Monday.

Thanks for the research - we're getting one step closer every day.