DSi软件

From 3dbrew
Jump to navigation Jump to search

第一次使用3DS时会在SD卡上生成一些管理数据的数据。3DS使用一个单独的目录,比如DSi: /Nintendo 3DS/<SomeID>/<SomeID>/Nintendo DSiWare。文件名的格式为<titleidlow>.bin。这些文件的keys/format域DSi是完全不同的。某个从3DS的SD卡导出的DSiWare ~0x3bc bytes ,这要比从 DSi 中导出的小。


3DS的DSiWare存储在"sdmc:/Nintendo 3DS/<ID0>/<ID1>/Nintendo DSiWare". 文件名的格式和DSi: "<TitleID-Low>.bin"相同. The below sizes include the 0x20-byte block metadata.

DSiWare exported from 3DS use console-unique keyslots initialized by movable.sed. Each section is encrypted with AES-CBC.

The content sections are ordered the same way as DSi: TMD, SRL from content0, <content1-7 for format v2>, public.sav, and banner.sav when banner.sav exists. When the DSiWare export type is 7-11, the 12th content section is the private.sav, if it exists.(ContentX here is the .app data from TWL-NAND /title)

DSiWare Export Types[edit]

Value Format version Description
0-6 Same as value 14.
7-11 v2 12 content sections
12 v2 4 content sections
13 v1 4 content sections
14 v2 11 content sections

For NATIVE_FIRM versions where this DSiWare export type field is unused, format version v1 is used with 4 content sections. Otherwise when this field is used, see the above table. System Settings uses type 1 for exporting DSiWare, regardless of the System Settings title-version.

Block Metadata[edit]

Offset Size Description
0x0 0x10 AES MAC over a SHA-256 hash
0x10 0x10 IV, generated by the RNG.

Each section begins with the payload encrypted data, followed by this block metadata. The SHA-256 hash used for the MAC is calculated over the cleartext payload. This hash used for generating the MAC is also stored in the footer.

Footer[edit]

Offset Size Description
0x0 X SHA-256 hashes over the banner, header, and content sections. When a content section doesn't exist, the corresponding hash here is uninitialized.
0x0 + X 0x3C ECDSA signature using SHA-256 over the previous hashes, signed by the APCert.
0x3C + X 0x180 ECDSA "APXXXXXXXXXXXXXXXX" cert signed by the below CTCert, where X is random lowercase ASCII hex data.
0x1BC + X 0x180 ECDSA CTCert
0x33C + X 0x4 Uninitialized padding.

These hashes are the same hashes used for generating each section's MAC stored in the metadata block. X = 0x40 + totalcontentsections*0x20.

File Structure v1[edit]

Offset Size Description
0x0 0x4020 Banner section
0x4020 0xC0 Header section
0x40E0 0x340 + 0x20 + X, where X is the total size of the hashes stored in the footer. Footer section
0x40E0 + footer_size Content sections

Header[edit]

Offset Size Description
0x0 0x4 Magic number 0x54444633, "3FDT".
0x4 0x2 Byte-swapped groupID from the TWL TMD.
0x6 0x2 Byte-swapped title version from the TWL TMD.
0x8 0x20 SHA-256 hash calculated over the encrypted movable.sed.
0x28 0x10 Encrypted AES block from encrypting an all-zero 0x10-byte block with AES-CBC, where the IV is all-zero.
0x38 0x8 Byte-swapped titleID from the TWL TMD.
0x40 0x8 ?
0x48 0x10 u32 payload sizes for the 4 content sections.
0x58 0x4 ?
0x5C 0x3E Data from the TWL TMD reserved section. Only the first 0x20-bytes from the TWL TMD is written here, the rest is uninitialized.
0x9A 0x6 Padding?

File Structure v2[edit]

Offset Size Description
0x0 0x4020 Banner section
0x4020 0x110 Header section
0x4130 0x340 + 0x20 + X, where X is the total size of the hashes stored in the footer. Footer section
0x4130 + footer_size Content sections

Header[edit]

Offset Size Description
0x0 0x4 Magic number 0x54444633, "3FDT".
0x4 0x2 Byte-swapped groupID from the TWL TMD.
0x6 0x2 Byte-swapped title version from the TWL TMD.
0x8 0x20 SHA-256 hash calculated over the encrypted movable.sed.
0x28 0x10 Encrypted AES block from encrypting an all-zero 0x10-byte block with AES-CBC, where the IV is all-zero.
0x38 0x8 Byte-swapped titleID from the TWL TMD.
0x40 0x8 ?
0x48 0x2C u32 payload sizes for the 11 content sections.
0x74 0x30 ?
0xA4 0x3E Data from the TWL TMD reserved section. Only the first 0x20-bytes from the TWL TMD is written here, the rest is uninitialized.
0xE2 0x0E Padding?