TM2X: Difference between revisions

From MultimediaWiki
Jump to navigation Jump to search
Line 162: Line 162:
   byte  7    --- list length - 1
   byte  7    --- list length - 1
   byte  8-... --- list data
   byte  8-... --- list data
 
 
=== 0xA0000119 ===
 
This chunk is obfuscated.
 
byte  0    --- number of parameter blocks
bytes 1-... --- parameter IDs (used in the same way as chunk ID in 0xA0000103)
 
=== Inverse Huffman list data format ===
=== Inverse Huffman list data format ===



Revision as of 04:37, 3 April 2016

Duck TrueMotion 2X is believed to be related to Duck TrueMotion 2.

Coding principles

Truemotion 2X is different from Duck Truemotion 2 in its coding principles. Instead of delta coding 4x4 blocks with Huffman coded streams for each block type, TM2X has chunked frame format, inverse Huffman coding (i.e. instead of codes using variable number bits representing one token TM2X employs list of tokens assigned to single byte value) and 8x8 blocks.

Each frame consists of chunks with the following structure:

 0-2 always 0xA0 0x00 0x01
 3      chunk identifier
 4-7 chunk size (big-endian)
 8-... chunk payload

Analyzed frames have chunks in the following order:

  • 0x06 (usually takes more than a half of coded frame)
  • 0x15- small, variable size
  • 0x09- 3 bytes long, seems to be some initialisation data
  • 0x02- two chunks of variable size
  • 0x0B- there are always 16 of them with size=4. Maybe for some Huffman tables?
  • 0x0A- variable size

In order to ease reverse-engineering Duck seemed to used pseudo-encryption on data. Pseudo-encryption means XORing some chunks with parts of LFSR which may be updated before some chunks. Register data is stored as big-endian number and looks like first 4 bytes of 0x06 chunk are used to initialize it (it also seems to be that chunk size minus four bytes).

LSFR update algorithm:

 calculate sum by modulo 2 of bits 31, 21, 3 and inverted bit 0
 shift register contents left by one bit and store new sum in LSB
 repeat 4 times

Known chunks

Each chunk starts with 32-bit identifier and 32-bit chunk size, both big-endian. Usually frame is composed of chunks for main data, configuration parameters and the last one is inverse Huffman list chunk.

0xA0000102

There should be up to two chunks.

First byte gives the chunk number (0 or 1).

Second byte tells how many 16-bit words of actual dat this chunk has (up to 128).

The rest of chunk is 16-bit words.

0xA0000103

First byte - ID?

Seems to be similar to 0xA000010B

0xA0000105

Inverse Huffman list data.

 bytes 0-1   --- list size
 bytes 2-3   --- list length (usually 256)
 byte  4     --- list depth (should be 8)
 byte  5-... --- list data

0xA0000106

First 32-bit word is used to initialise LSFR key.

0xA0000109

his chunk is obfuscated.

 byte  0     --- chunk ID 
 bytes 1-2   --- ???

Chunk ID is used instead of offset provided in 0xA000010B.

0xA000010A

Inverse Huffman list data.

 byte  0     --- escape value
 bytes 1-2   --- ???
 bytes 3-4   --- list size
 bytes 5-6   --- list length (usually 256)
 byte  7     --- list depth (should be 8)
 byte  8-... --- list data

0xA000010B

This chunk is obfuscated.

 byte  0     --- chunk ID 
 bytes 1-2   --- ???
 byte  3     --- some offset

The following codebook is used for nonzero chunk IDs, it seems to affect which block decoding functions are selected:

 0, 0, 0, 0,
 0, 1, 1, 1,
 0, 1, 1, 2,
 0, 1, 2, 4
 1, 1, 2, 4,
 0, 2, 2, 4,
 1, 2, 2, 4,
 2, 2, 2, 4
 1, 4, 2, 4,
 2, 4, 2, 4,
 2, 8, 3, 8,
 3, 4, 3, 8
 3, 8, 3, 8,
 0, 1, 1, 4,
 0, 1, 2, 2,
 0, 2, 1, 4
 1, 1, 2, 2,
 1, 4, 2, 8,
 2, 2, 3, 4,
 2, 4, 3, 8
 0, 1, 3, 8,
 1, 2, 3, 8,
 2, 4, 2, 4,
 2, 4, 3, 8
 3, 8, 3, 8

0xA000010E

This chunk is obfuscated.

byte  0     --- chunk ID 
bytes 1-2   --- ???
bytes 3-6   --- some parameters used instead of codebook in 0xA000010B (offset = chunk ID as for 0xA00000103)

0xA0000112

This represents some 2D array.

First byte is number of elements per line. Second byte seems to be padding. Following 16-bit word is number of lines.

The rest of chunk is 16-bit words forming some 2D array.

0xA0000117

Inverse Huffman list data.

 byte  0     --- escape value
 bytes 1-2   --- ???
 bytes 3-4   --- ???
 bytes 5-6   --- ???
 byte  7     --- ???
 byte  8     --- list length - 1
 byte  9-... --- list data

0xA0000118

Inverse Huffman list data.

 byte  0     --- escape value
 bytes 1-2   --- ???
 bytes 3-4   --- ???
 bytes 5-6   --- ???
 byte  7     --- list length - 1
 byte  8-... --- list data

0xA0000119

This chunk is obfuscated.

byte  0     --- number of parameter blocks
bytes 1-... --- parameter IDs (used in the same way as chunk ID in 0xA0000103)

Inverse Huffman list data format

The list is stored in sparse form --- first you have a byte for length of the entry and then the tokens themselves (each takes a byte too). For example 01 0A 02 2A 2A expands to { 0A }, { 2A, 2A } .