Another useless Wii "hacking" site by noowii |
| Description | Link | Notes |
| Perl script to send SOAP request | here | Requieres perl, libwww perl module |
| Shell script to retrieve encrypted VC images | here | Requieres bash, wget |
| Diff between 2 tmd file (from 2 different games) | here | None |
| TMD file parser | here | Updated December, 23th 2006 |
| 64-bytes file AES/SHA1 analyser | here | Updated January, 14th 2007 |
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 :
"All these modes (except ECB) require an initialization vector, or IV -- a sort of 'dummy block' to kick off the process for the first real block, and also to provide some randomization for the process. There is no need for the IV to be secret, in most cases, but it is important that it is never reused with the same key. For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages. For OFB and CTR, reusing an IV completely destroys security. In CBC mode, the IV must, in addition, be randomly generated at encryption time." (From Wikipedia)
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 :
