VC, TMD and CETK stuff

Analysing this TMD file : http://ccs.shop.wii.com/ccs/download/0001000848414B45/tmd

Gives the result (stripped):

 +- File 00000000 size : 64 (file #0) - HASH: cd7b3fc43bcc19366d6dcf57891da6c01b256ca1

This potentially means that http://ccs.shop.wii.com/ccs/download/0001000848414B45/00000000 has a decrypted/uncompressed checksum of "cd7b3fc43bcc19366d6dcf57891da6c01b256ca1". Many checksums were collected over the Nintendo servers, then parsed with the TMD tool. It is believed that these files are encrypted with AES-128-CBC/nosalt.

The VC bundle "0000000100000002" contains 3 64-bytes files (00000011 / 00000016 / 00000019), which share the first 16 bytes of encrypted data. 

00000011:

    00000000  c3 0c 36 8a da f3 bd 55  60 63 62 da 63 64 7f 34  |..6....U`cb.cd.4
    00000010  4b 0a 10 c7 f2 3e 2b 1c  ba 9b 0f c2 42 ca b7 b2  |K....>+.....B...| 

    00000020  c4 29 7b 86 1d 40 fa 83  37 6a dd 99 12 16 1f f7  |.){..@..7j......|  

    00000030  49 d7 5b 7d 3a a5 22 fd  23 be 10 44 42 8c 85 cf  |I.[}:.".#..DB...|

00000016:

    00000000  c3 0c 36 8a da f3 bd 55  60 63 62 da 63 64 7f 34  |..6....U`cb.cd.4|
    00000010  c3 35 f4 4e 4f 73 7f 43  3f a7 8b 6b af d9 ca ae  |.5.NOs.C?..k....|
    00000020  78 fc 90 e9 c7 53 52 32  2c 41 a2 ae 28 9c 62 82  |x....SR2,A..(.b.|
    00000030  05 b2 9f 3e 17 aa f9 19  16 3c c6 d4 62 b0 75 f1  |...>.....<..b.u.| 

00000019: 

    00000000  c3 0c 36 8a da f3 bd 55  60 63 62 da 63 64 7f 34  |..6....U`cb.cd.4|
    00000010  96 1a 1e 49 cd 06 e8 36  84 98 c8 aa a8 e7 cc b5  |...I...6........|
    00000020  a0 87 8f d2 5d f8 76 2f  6a 37 dc 53 58 b3 57 5d  |....].v/j7.SX.W]|
    00000030  d9 51 5f 3d bc e5 1c 33  07 54 0d ce c8 f2 9e 94  |.Q_=...3.T......| 

What could that mean to the cipher leve ? AES uses an initialization vector :

This is an interesting statement, as this exact case shows up with this 3 files.

To illustrate the previous quote and prove it works with AES, the following commands were executed:

    $ perl -e 'print "A"x48' > a.txt
    $ perl -e 'print "A"x16 . "B"x32' > b.txt
    $ cat a.txt ; echo
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    $ cat b.txt ; echo
    AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
    $ openssl enc -aes-128-cbc -nosalt -in a.txt -out a.enc -k MyKey
    $ openssl enc -aes-128-cbc -nosalt -in b.txt -out b.enc -k MyKey
    $ ls -l
    total 32
    -rw-r--r--   1 user  wheel  64 Feb 10 00:43 a.enc
    -rw-r--r--   1 user  wheel  48 Feb 10 00:42 a.txt
    -rw-r--r--   1 user  wheel  64 Feb 10 00:44 b.enc
    -rw-r--r--   1 user  wheel  48 Feb 10 00:43 b.txt
    $ hexdump -C a.enc       
    00000000  a1 f2 3a 91 72 d9 8b 58  47 3c 57 80 89 75 cb 3f  |..:.r..XG<W..u.?|
    00000010  1b dd d9 ee 92 e7 a9 bf  8c 8b 7d 37 33 61 e2 ba  |..........}73a..|
    00000020  2d 47 ed 3b b3 c9 d0 19  34 05 ad ff ac 30 25 b5  |-G.;....4....0%.|
    00000030  ec 41 ca 09 e5 d6 7d 39  c8 01 13 bc 0d 27 17 fe  |.A....}9.....'..|
    00000040
    $ hexdump -C b.enc       
    00000000  a1 f2 3a 91 72 d9 8b 58  47 3c 57 80 89 75 cb 3f  |..:.r..XG<W..u.?|
    00000010  20 9e c3 c4 d0 d7 8c bb  9d a6 e7 21 75 fc 98 62  | ..........!u..b|
    00000020  cd cc b4 ab 31 a4 51 37  cc 8e 8c 88 45 91 21 45  |....1.Q7....E.!E|
    00000030  42 cc e3 00 68 ff 27 d1  ab 3b 0f ee 02 18 ea 67  |B...h.'..;.....g|
    00000040

For the non-UNIX reader:
        - 1 cleartext file "a.txt" was generated with 48 bytes ("A")
        - 1 cleartext file "b.txt" was generated with 16 "A" and 32 "B", resulting 48 bytes
        - The 2 cleartext files were encrypted ("a.enc", "b.enc") with the same key : "MyKey"
        => "a.enc" and "b.enc" share the first 16 bytes, as in their cleartext version. 

Different "flavors" on the 2 cleartext files were tested :

File A        File B                                    Result

48 x "A"      48 x "B"                                  Nothing common

48 x "A"      16 x "A" + 32 x "B"                    First 16 bytes common

48 x "A"      8 x "A" + 40 x "B"                     Nothing common

48 x "A"      16 x "A" + 16 x "B" + 16 x "A"      First 16 bytes common

48 x "A"      32 x "A" + 16 x "B"                    First 32 bytes common

48 x "A"      40 x "A" + 8 x "B"                      First 32 bytes common

48 x "A"      10 x "A" + 38 x "B"                    Nothing common

We can be pretty sure the cipher opers with a 128-bits key (16 bytes working blocks). 

Now, to prove the same AES key is used to encrypt each file (within the same VC bundle) :

    $ openssl enc -aes-128-cbc -nosalt -in b.txt -out b.enc -k MyOtherKey
    $ hexdump -C b.enc
    00000000  de aa 91 71 0a cf 56 a1  e9 82 21 cc 2c 93 2f a9  |...q..V...!.,./.|
    00000010  87 4b 1d e6 64 88 dd 46  b1 af f4 7a 99 f6 d6 78  |.K..d..F...z...x|
    00000020  cf 8c d2 82 9a 6e 06 80  19 5a 2c 6b eb f3 87 1f  |.....n...Z,k....|
    00000030  e6 56 f5 d4 a9 46 88 32  25 03 8a 7e 1d e4 4f d4  |.V...F.2%..~..O.|
    00000040

We see that the first 16 bytes aren't shared anymore when using a different key. 

So, to sum up :   

• We know that each of these file share the first 16 bytes while decrypted  
• We know that the same AES key is used to encrypt every files inside one VC bundle
• We know the cipher operates with 128-bits key