478
edits
Changes
Jump to navigation
Jump to search
mLine 1:
Line 1: − + Line 5:
Line 5: − = ES blocks =+ − An ES block, for lack of a better name, is a commonly used data encryption method on DSi by Nintendo. − It uses AES CCM to encrypt a maximum of 0x20000 bytes of data per time, and extends it with a 32 byte trail block at the end.+ − A part of the last 16 bytes of trail block itself is encrypted with AES CTR, and contains the nonce for decryption and size of the ES block:+ − 0000000: qq qq qq qq qq qq qq qq qq qq qq qq qq qq qq qq+ − 0000010: xx nn nn nn nn nn nn nn nn nn nn nn nn yy yy yy+ − + − The counter used for decrypting the trail block is the last 16 bytes of the trailblock, with the first, 14th, 15th and 16th byte set to 0:+ − 00 nn nn nn nn nn nn nn nn nn nn nn nn 00 00 00+ + + + + + + + + + + + + + + + + − After decrypting the trailblock, xx is always 0x3A, and yy is the size of the ES block (excluding the trail block). The nonce after decryption is not used. It is assumed that qq is a MAC (Message Authentication Code), used to verify the contents of the ES block after decryption, but this has not been verified yet.+ − The same 12-byte nonce from the trailblock is again used to decrypt the whole ES block itself.+ − − Data larger than 0x20000 bytes is split into multiple ES blocks, each with their own trailblock. − − ES block encryption is used to encrypt the header block, footer block, and the 11 parts. − − − = header = Line 93:
Line 101: − + Line 172:
Line 180: − + − + + + + + + + + + + + + + − + − + − + − + − + + + + + + + + + − + − + − +
→Tad file structure overview
The System Settings application delivered with each DSi can be used to export applications from NAND to SD. The files created on SD are encrypted with AES CCM (CTR with CBC-MAC), using a combination of a shared key and a console specific key.
The System Settings application delivered with each DSi can be used to export applications from NAND to SD. The bin files created on SD are using the Tad file structure. Tad files are encrypted with AES CCM (CTR with CBC-MAC), using a combination of a shared key and a console specific key.
The application itself (APP), and the title metadata (TMD) is encrypted with a console specific key. This means that Nintendo intended that these files can only be imported back into the same DSi.
The application itself (APP), and the title metadata (TMD) is encrypted with a console specific key. This means that Nintendo intended that these files can only be imported back into the same DSi.
While the banner, the public savegame, and several other metablocks are encrypted with a shared key, which means any DSi can inspect these parts of the file.
While the banner, the public savegame, and several other metablocks are encrypted with a shared key, which means any DSi can inspect these parts of the file.
[[ES block encryption]] is used to encrypt the header block, footer block, and the 11 content parts. Each are their own seperate ES blocks.
= Tad file structure overview =
{| class="wikitable"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4020
| Banner/Icon
|-
| 0x4020
| 0xD4
| Header
|-
| 0x40F4
| 0x460
| Footer (certificates/hashes)
|-
| 0x4554
| -
| Content parts in sequence (TMD, SRL, savegame, custom banner).
|}
The banner, header, footer and savegame are encrypted with a shared key between each DSi. The other content parts are encrypted with a console specific key.
= Header block @ 0x4020 (size 0xB4) =
0000000: 34 41 4e 54 31 30 00 01 74 e9 2c 1e 24 00 00 00 4ANT10..t.,.$...
0000000: 34 41 4e 54 31 30 00 01 74 e9 2c 1e 24 00 00 00 4ANT10..t.,.$...
0000010: d6 e0 39 c3 98 3f 06 b6 9a b2 9d 14 e7 06 e9 00 ..9..?..........
0000010: d6 e0 39 c3 98 3f 06 b6 9a b2 9d 14 e7 06 e9 00 ..9..?..........
|}
|}
= footer block =
= footer block @ 0x40F4 (size 0x460) =
0000000: d6 f3 24 7c a1 0f 4a dc cd 07 34 d6 ce 62 32 93 ..$|..J...4..b2.
0000000: d6 f3 24 7c a1 0f 4a dc cd 07 34 d6 ce 62 32 93 ..$|..J...4..b2.
|-
|-
| 0x00
| 0x00
| 80
| 20
| Unknown
| SHA1 of banner
|-
| 0x14
| 20
| SHA1 of tna4
|-
| 0x28
| 20
| SHA1 of tmd
|-
| 0x3c
| 20*8
| SHA1 of up to 8 contents [if unused, can be whatever happened to be in memory before]
|-
|-
| 0x50
| 0xdc
| 150*2
| 20
| Producer Company (UCS-2)
| SHA1 of save data
|-
|-
| 0xDC
| 0xf0
| 20
| 20
| (?) SHA-1
| SHA1 of ?
|-
| 0x104
| 0x3c
| ECC signature of previous 0x104 bytes with AP cert
|-
| 0x140
| 0x180
| AP cert, signed by TW cert
|-
|-
|..
| 0x2c0
|..
| 0x180
|ECC certificates/signatures
| TW cert, specific to a console (see dev.kp)
|}
|}
It is assumed that this block contains an ECC signature, aswell as the console id and serial of the DSi that exported the file, as part of a Nintendo cert. Much like the Wii, the DSi carries with it a private ECC key that it can use to sign things, and a certificate signed by Nintendo that attests to the fact that the public ECC key belongs to a genuine DSi.
It is assumed that this block contains an ECC signature, aswell as the console id and serial of the DSi that exported the file, as part of a Nintendo cert. Much like the Wii, the DSi carries with it a private ECC key that it can use to sign things, and a certificate signed by Nintendo that attests to the fact that the public ECC key belongs to a genuine DSi.