https://www.3dbrew.org/w/api.php?action=feedcontributions&user=Bushing&feedformat=atom
3dbrew - User contributions [en]
2024-03-29T15:14:14Z
User contributions
MediaWiki 1.35.8
https://www.3dbrew.org/w/index.php?title=CXI&diff=602
CXI
2011-05-29T04:56:06Z
<p>Bushing: /* Plain region example for Lego Starwars III */</p>
<hr />
<div>The following text tries to document the structure of the CTR Executable Image (CXI) format.<br />
<br />
=== Overview ===<br />
A CXI file contains the 'application' program code, which runs on a single ARM11 core. It can communicate through SVC calls with the other ARM11 core running the 'system' program code. For reasons of clarity, the ARM11 cores will sometimes be called the 'appcore' and 'syscore' respectively.<br />
<br />
The CXI file format contains application ARM11 code, the menu icon, the menu 3D model, and an embedded read-only (ROM) filesystem for external filestorage. In fact, the application ARM11 code, menu icon, and menu 3D model are embedded into its own filesystem too, called the ExeFS.<br />
<br />
More specifically, the CXI file format is structured in the following order:<br />
* first an NCCH header,<br />
* followed by an extended header, <br />
* followed by a plain binary region,<br />
* followed by an embedded executable filesystem (ExeFS),<br />
* and finally followed by a read-only filesystem (RomFS).<br />
<br />
The extended header contains additional information regarding access control.<br />
The plain binary region is an area specifically stored in plaintext, mostly containing SDK library strings for identification.<br />
<br />
The extended header, the ExeFS and the RomFS are encrypted using AES CTR.<br />
<br />
<br />
=== NCCH Header ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x000<br />
| 0x100<br />
| RSA-2048 signature of the NCCH header, using SHA-256.<br />
|-<br />
| 0x100<br />
| 4<br />
| Magic ID, always 'NCCH'<br />
|-<br />
| 0x104<br />
| 4<br />
| Content size, in media units (1 media unit = 0x200 bytes)<br />
|-<br />
| 0x108<br />
| 8<br />
| Partition ID<br />
|-<br />
| 0x110<br />
| 2<br />
| Maker code<br />
|-<br />
| 0x112<br />
| 2<br />
| Version<br />
|-<br />
| 0x114<br />
| 4<br />
| Reserved<br />
|-<br />
| 0x118<br />
| 8<br />
| Program ID<br />
|-<br />
| 0x120<br />
| 1<br />
| Temp flag<br />
|-<br />
| 0x121<br />
| 0x2F<br />
| Reserved<br />
|-<br />
| 0x150<br />
| 0x10<br />
| Product code<br />
|-<br />
| 0x160<br />
| 0x20<br />
| Extended header hash<br />
|-<br />
| 0x180<br />
| 4<br />
| Extended header size<br />
|-<br />
| 0x184<br />
| 4<br />
| Reserved<br />
|-<br />
| 0x188<br />
| 8<br />
| Flags<br />
|-<br />
| 0x190<br />
| 4<br />
| Plain region offset, in media units<br />
|-<br />
| 0x194<br />
| 4<br />
| Plain region size, in media units<br />
|-<br />
| 0x198<br />
| 8<br />
| Reserved<br />
|-<br />
| 0x1A0<br />
| 4<br />
| ExeFS offset, in media units<br />
|-<br />
| 0x1A4<br />
| 4<br />
| ExeFS size, in media units<br />
|-<br />
| 0x1A8<br />
| 4<br />
| ExeFS hash region size, in media units<br />
|-<br />
| 0x1AC<br />
| 4<br />
| Reserved<br />
|-<br />
| 0x1B0<br />
| 4<br />
| RomFS offset, in media units<br />
|-<br />
| 0x1B4<br />
| 4<br />
| RomFS size, in media units<br />
|-<br />
| 0x1B8<br />
| 4<br />
| RomFS hash region size, in media units<br />
|-<br />
| 0x1BC<br />
| 4<br />
| Reserved<br />
|-<br />
| 0x1C0<br />
| 0x20<br />
| ExeFS superblock hash<br />
|-<br />
| 0x1E0<br />
| 0x20<br />
| RomFS superblock hash<br />
|}<br />
<br />
==== NCCH header example for Lego Starwars III ====<br />
Signature: 720FF8F83F2A1E998322A026D1434165<br />
ED19642ABC1CB2722135AA202BEAD60A<br />
80BCD21C768C597B8268FEF2C64EA710<br />
4C9BA5E12CFFBD1D0C619F4EF7B42CA7<br />
DD8482CB4EB26720AD66CDA57ABCBCFB<br />
D63268A6E2896A59B3B744E39E45B88A<br />
ABB4C0980ACC6210818DCE6DAC838A10<br />
95D0F66B352474D4B3DA4B333F49912D<br />
29AF7EA58BC8C890B18C70B7D540A9FB<br />
EBE24A5312055617D3353B28C3EB1D17<br />
61021BEFF6AD22C384835B40BD44DFAD<br />
981F6350F9458B17BCB5F768C92ABC93<br />
2BCE9888855A8998F4CDE40C9543514A<br />
C57B84EB75A680E7C742632614620D1D<br />
A253284DF3DC01091EB3800C36FD62EE<br />
BA15340F1FD498FAB67C0302E9CDA397<br />
Magic: NCCH<br />
Content size: 0x1cfef400<br />
Partition id: 0004000000038c00<br />
Maker code: 3436 ("46")<br />
Version: 0002<br />
Program id: 0004000000038c00<br />
Temp flag: 00<br />
Product code: CTR-P-ALGP<br />
Extended header hash: 0C27E3C1DE7B2AE2D3114F32A4EEBF46<br />
9AFD0CF352C11D4984C2A9F1D2144C63<br />
Extended header size: 00000400<br />
Flags: 0000030100000000<br />
Plain region offset: 0x00004a00<br />
Plain region size: 0x00000200<br />
ExeFS offset: 0x00004c00<br />
ExeFS size: 0x00143800<br />
ExeFS hash region size: 0x00000200<br />
RomFS offset: 0x00148400<br />
RomFS size: 0x1ceab000<br />
RomFS hash region size: 0x00000200<br />
ExeFS Superblock Hash: 130C042615F647C4C63225EA9E67F8A2<br />
7B15246B88FBC7A927257B84977B787B<br />
RomFS Superblock Hash: A65BEE1060BB6A6821BBCEC600035B7E<br />
64FB6EACA7F0960CFB1F5A37087728F7<br />
Note: Offsets and sizes in media units have been converted to byte sizes.<br />
<br />
==== Plain region example for Lego Starwars III ====<br />
0004a00: 5b 53 44 4b 2b 4e 49 4e 54 45 4e 44 4f 3a 43 54 [SDK+NINTENDO:CT [SDK+NINTENDO:CTR_SDK-0_14_23_200_none]<br />
0004a10: 52 5f 53 44 4b 2d 30 5f 31 34 5f 32 33 5f 32 30 R_SDK-0_14_23_20<br />
0004a20: 30 5f 6e 6f 6e 65 5d 00 5b 53 44 4b 2b 4e 49 4e 0_none].[SDK+NIN [SDK+NINTENDO:Firmware-02_27]<br />
0004a30: 54 45 4e 44 4f 3a 46 69 72 6d 77 61 72 65 2d 30 TENDO:Firmware-0<br />
0004a40: 32 5f 32 37 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 2_27].[SDK+Mobic [SDK+Mobiclip:Deblocker_1_0_2]<br />
0004a50: 6c 69 70 3a 44 65 62 6c 6f 63 6b 65 72 5f 31 5f lip:Deblocker_1_<br />
0004a60: 30 5f 32 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 6c 0_2].[SDK+Mobicl [SDK+Mobiclip:ImaAdpcmDec_1_0_0]<br />
0004a70: 69 70 3a 49 6d 61 41 64 70 63 6d 44 65 63 5f 31 ip:ImaAdpcmDec_1<br />
0004a80: 5f 30 5f 30 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 _0_0].[SDK+Mobic [SDK+Mobiclip:MobiclipDec_1_0_1]<br />
0004a90: 6c 69 70 3a 4d 6f 62 69 63 6c 69 70 44 65 63 5f lip:MobiclipDec_<br />
0004aa0: 31 5f 30 5f 31 5d 00 5b 53 44 4b 2b 4d 6f 62 69 1_0_1].[SDK+Mobi [SDK+Mobiclip:MoflexDemuxer_1_0_2]<br />
0004ab0: 63 6c 69 70 3a 4d 6f 66 6c 65 78 44 65 6d 75 78 clip:MoflexDemux<br />
0004ac0: 65 72 5f 31 5f 30 5f 32 5d 00 00 00 00 00 00 00 er_1_0_2].......<br />
0004ad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0004ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................</div>
Bushing
https://www.3dbrew.org/w/index.php?title=CXI&diff=601
CXI
2011-05-29T04:53:31Z
<p>Bushing: /* NCCH header example for Lego Starwars III */</p>
<hr />
<div>The following text tries to document the structure of the CTR Executable Image (CXI) format.<br />
<br />
=== Overview ===<br />
A CXI file contains the 'application' program code, which runs on a single ARM11 core. It can communicate through SVC calls with the other ARM11 core running the 'system' program code. For reasons of clarity, the ARM11 cores will sometimes be called the 'appcore' and 'syscore' respectively.<br />
<br />
The CXI file format contains application ARM11 code, the menu icon, the menu 3D model, and an embedded read-only (ROM) filesystem for external filestorage. In fact, the application ARM11 code, menu icon, and menu 3D model are embedded into its own filesystem too, called the ExeFS.<br />
<br />
More specifically, the CXI file format is structured in the following order:<br />
* first an NCCH header,<br />
* followed by an extended header, <br />
* followed by a plain binary region,<br />
* followed by an embedded executable filesystem (ExeFS),<br />
* and finally followed by a read-only filesystem (RomFS).<br />
<br />
The extended header contains additional information regarding access control.<br />
The plain binary region is an area specifically stored in plaintext, mostly containing SDK library strings for identification.<br />
<br />
The extended header, the ExeFS and the RomFS are encrypted using AES CTR.<br />
<br />
<br />
=== NCCH Header ===<br />
{| class="wikitable" border="1"<br />
|-<br />
! OFFSET<br />
! SIZE<br />
! DESCRIPTION<br />
|-<br />
| 0x000<br />
| 0x100<br />
| RSA-2048 signature of the NCCH header, using SHA-256.<br />
|-<br />
| 0x100<br />
| 4<br />
| Magic ID, always 'NCCH'<br />
|-<br />
| 0x104<br />
| 4<br />
| Content size, in media units (1 media unit = 0x200 bytes)<br />
|-<br />
| 0x108<br />
| 8<br />
| Partition ID<br />
|-<br />
| 0x110<br />
| 2<br />
| Maker code<br />
|-<br />
| 0x112<br />
| 2<br />
| Version<br />
|-<br />
| 0x114<br />
| 4<br />
| Reserved<br />
|-<br />
| 0x118<br />
| 8<br />
| Program ID<br />
|-<br />
| 0x120<br />
| 1<br />
| Temp flag<br />
|-<br />
| 0x121<br />
| 0x2F<br />
| Reserved<br />
|-<br />
| 0x150<br />
| 0x10<br />
| Product code<br />
|-<br />
| 0x160<br />
| 0x20<br />
| Extended header hash<br />
|-<br />
| 0x180<br />
| 4<br />
| Extended header size<br />
|-<br />
| 0x184<br />
| 4<br />
| Reserved<br />
|-<br />
| 0x188<br />
| 8<br />
| Flags<br />
|-<br />
| 0x190<br />
| 4<br />
| Plain region offset, in media units<br />
|-<br />
| 0x194<br />
| 4<br />
| Plain region size, in media units<br />
|-<br />
| 0x198<br />
| 8<br />
| Reserved<br />
|-<br />
| 0x1A0<br />
| 4<br />
| ExeFS offset, in media units<br />
|-<br />
| 0x1A4<br />
| 4<br />
| ExeFS size, in media units<br />
|-<br />
| 0x1A8<br />
| 4<br />
| ExeFS hash region size, in media units<br />
|-<br />
| 0x1AC<br />
| 4<br />
| Reserved<br />
|-<br />
| 0x1B0<br />
| 4<br />
| RomFS offset, in media units<br />
|-<br />
| 0x1B4<br />
| 4<br />
| RomFS size, in media units<br />
|-<br />
| 0x1B8<br />
| 4<br />
| RomFS hash region size, in media units<br />
|-<br />
| 0x1BC<br />
| 4<br />
| Reserved<br />
|-<br />
| 0x1C0<br />
| 0x20<br />
| ExeFS superblock hash<br />
|-<br />
| 0x1E0<br />
| 0x20<br />
| RomFS superblock hash<br />
|}<br />
<br />
==== NCCH header example for Lego Starwars III ====<br />
Signature: 720FF8F83F2A1E998322A026D1434165<br />
ED19642ABC1CB2722135AA202BEAD60A<br />
80BCD21C768C597B8268FEF2C64EA710<br />
4C9BA5E12CFFBD1D0C619F4EF7B42CA7<br />
DD8482CB4EB26720AD66CDA57ABCBCFB<br />
D63268A6E2896A59B3B744E39E45B88A<br />
ABB4C0980ACC6210818DCE6DAC838A10<br />
95D0F66B352474D4B3DA4B333F49912D<br />
29AF7EA58BC8C890B18C70B7D540A9FB<br />
EBE24A5312055617D3353B28C3EB1D17<br />
61021BEFF6AD22C384835B40BD44DFAD<br />
981F6350F9458B17BCB5F768C92ABC93<br />
2BCE9888855A8998F4CDE40C9543514A<br />
C57B84EB75A680E7C742632614620D1D<br />
A253284DF3DC01091EB3800C36FD62EE<br />
BA15340F1FD498FAB67C0302E9CDA397<br />
Magic: NCCH<br />
Content size: 0x1cfef400<br />
Partition id: 0004000000038c00<br />
Maker code: 3436 ("46")<br />
Version: 0002<br />
Program id: 0004000000038c00<br />
Temp flag: 00<br />
Product code: CTR-P-ALGP<br />
Extended header hash: 0C27E3C1DE7B2AE2D3114F32A4EEBF46<br />
9AFD0CF352C11D4984C2A9F1D2144C63<br />
Extended header size: 00000400<br />
Flags: 0000030100000000<br />
Plain region offset: 0x00004a00<br />
Plain region size: 0x00000200<br />
ExeFS offset: 0x00004c00<br />
ExeFS size: 0x00143800<br />
ExeFS hash region size: 0x00000200<br />
RomFS offset: 0x00148400<br />
RomFS size: 0x1ceab000<br />
RomFS hash region size: 0x00000200<br />
ExeFS Superblock Hash: 130C042615F647C4C63225EA9E67F8A2<br />
7B15246B88FBC7A927257B84977B787B<br />
RomFS Superblock Hash: A65BEE1060BB6A6821BBCEC600035B7E<br />
64FB6EACA7F0960CFB1F5A37087728F7<br />
Note: Offsets and sizes in media units have been converted to byte sizes.<br />
<br />
==== Plain region example for Lego Starwars III ====<br />
0004a00: 5b 53 44 4b 2b 4e 49 4e 54 45 4e 44 4f 3a 43 54 [SDK+NINTENDO:CT<br />
0004a10: 52 5f 53 44 4b 2d 30 5f 31 34 5f 32 33 5f 32 30 R_SDK-0_14_23_20<br />
0004a20: 30 5f 6e 6f 6e 65 5d 00 5b 53 44 4b 2b 4e 49 4e 0_none].[SDK+NIN<br />
0004a30: 54 45 4e 44 4f 3a 46 69 72 6d 77 61 72 65 2d 30 TENDO:Firmware-0<br />
0004a40: 32 5f 32 37 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 2_27].[SDK+Mobic<br />
0004a50: 6c 69 70 3a 44 65 62 6c 6f 63 6b 65 72 5f 31 5f lip:Deblocker_1_<br />
0004a60: 30 5f 32 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 6c 0_2].[SDK+Mobicl<br />
0004a70: 69 70 3a 49 6d 61 41 64 70 63 6d 44 65 63 5f 31 ip:ImaAdpcmDec_1<br />
0004a80: 5f 30 5f 30 5d 00 5b 53 44 4b 2b 4d 6f 62 69 63 _0_0].[SDK+Mobic<br />
0004a90: 6c 69 70 3a 4d 6f 62 69 63 6c 69 70 44 65 63 5f lip:MobiclipDec_<br />
0004aa0: 31 5f 30 5f 31 5d 00 5b 53 44 4b 2b 4d 6f 62 69 1_0_1].[SDK+Mobi<br />
0004ab0: 63 6c 69 70 3a 4d 6f 66 6c 65 78 44 65 6d 75 78 clip:MoflexDemux<br />
0004ac0: 65 72 5f 31 5f 30 5f 32 5d 00 00 00 00 00 00 00 er_1_0_2].......<br />
0004ad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0004ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................</div>
Bushing
https://www.3dbrew.org/w/index.php?title=Savegames&diff=288
Savegames
2011-04-10T20:09:18Z
<p>Bushing: </p>
<hr />
<div>=== Encryption ===<br />
<br />
On the 3DS savegames are stored much like on the DS, that is on a FLASH chip in the gamecart. On the DS these savegames were stored in plaintext but on the 3DS a layer of encryption was added. This is highly likely a streamcipher, as the contents of several savegames exhibit the odd behaviour that xor-ing certain parts of the savegame together will result in the plaintext appearing.<br />
<br />
The reason this works is because the streamcipher used has a period of 512 bytes. That is to say, it will repeat the same keystream after 512 bytes. The way you encrypt with a streamcipher is you XOR your data with the keystream as it is produced. Unfortunately, if your streamcipher repeats and you are encrypting a known plaintext (in our case, zeroes) you are basically giving away your valuable keystream.<br />
<br />
So how do you use this to decrypt a savegame on a 3DS? First off, you chunk up the savegame into 512 byte chunks. Then, you bin these chunks by their contents, discarding any that contain only FF. Now look for the most common chunk. This is your keystream. Now XOR the keystream with your original savegame and you should have a fully decrypted savegame. XOR with the keystream again to produce an encrypted savegame.<br />
<br />
=== Wearleveling ===<br />
<br />
The 3DS employs a wearleveling scheme on the savegame FLASH chips. This is done trough blockmaps. Depending on the size of the flashchip, these are located somewhere at the beginning of the flashchip, in the first sector. The structure is as follows:<br />
<br />
<pre><br />
struct sector_entry {<br />
uint8_t virt_sec; // Mapped to sector<br />
uint8_t prev_virt_sec; // Physical sector previously mapped to<br />
uint8_t phys_sec; // Mapped from sector<br />
uint8_t prev_phys_sec; // Virtual sector previously mapped to<br />
uint8_t phys_realloc_cnt;// Amount of times virtual sector has been remapped<br />
uint8_t virt_realloc_cnt;// Amount of times physical sector has been remapped<br />
uint8_t chksums[8];<br />
} __attribute__((packed));<br />
<br />
struct long_sector_entry {<br />
struct sector_entry sector;<br />
struct sector_entry dupe;<br />
uint32_t magic;<br />
};<br />
</pre><br />
<br />
With magic being a constant 0x080d6ce0.<br />
<br />
=== Filesystem ===<br />
<br />
Savefiles stored on the FLASH are using a custom FS.<br />
<br />
It seems the file entries are stored somewhere in the third block. <br />
<br />
The first entry is the root directory, stored with a filename of '!'.<br />
<br />
<pre><br />
struct fs_entry {<br />
u32 nodes;<br />
u8 filename[0x10];<br />
u32 index;<br />
u32 unk1; // magic?<br />
u32 block_offset;<br />
u32 file_size;<br />
u32 unk2;<br />
u32 unk3; // flags and/or date?<br />
u32 unk4;<br />
}<br />
</pre><br />
<br />
Example from Super MonkeyBall 3D:<br />
<pre><br />
0003800: 04000000 21000000 00000000 00000000 ....!...........<br />
0003810: 00000000 00000000 00000000 00000000 ................<br />
0003820: 00000000 00000000 00000000 00000000 ................<br />
0003830: 01000000 736d6233 64732e64 61740000 ....smb3ds.dat..<br />
0003840: 00000000 00000000 d57b1100 05000000 .........{......<br />
0003850: e4060000 00000000 c8cf0008 00000000 ................<br />
0003860: 01000000 6d677265 706c6179 30302e64 ....mgreplay00.d<br />
0003870: 61740000 01000000 d57b1100 09000000 at.......{......<br />
0003880: 1c210000 00000000 cd331000 00000000 .!.......3......<br />
0003890: 01000000 6d677265 706c6179 30312e64 ....mgreplay01.d<br />
00038a0: 61740000 02000000 d57b1100 1a000000 at.......{......<br />
00038b0: 1c210000 00000000 00000000 00000000 .!..............<br />
</pre><br />
[[セーブデータ|Japanese]]</div>
Bushing
https://www.3dbrew.org/w/index.php?title=Savegames&diff=287
Savegames
2011-04-10T20:05:47Z
<p>Bushing: add example</p>
<hr />
<div>=== Encryption ===<br />
<br />
On the 3DS savegames are stored much like on the DS, that is on a FLASH chip in the gamecart. On the DS these savegames were stored in plaintext but on the 3DS a layer of encryption was added. This is highly likely a streamcipher, as the contents of several savegames exhibit the odd behaviour that xor-ing certain parts of the savegame together will result in the plaintext appearing.<br />
<br />
The reason this works is because the streamcipher used has a period of 512 bytes. That is to say, it will repeat the same keystream after 512 bytes. The way you encrypt with a streamcipher is you XOR your data with the keystream as it is produced. Unfortunately, if your streamcipher repeats and you are encrypting a known plaintext (in our case, zeroes) you are basically giving away your valuable keystream.<br />
<br />
So how do you use this to decrypt a savegame on a 3DS? First off, you chunk up the savegame into 512 byte chunks. Then, you bin these chunks by their contents, discarding any that contain only FF. Now look for the most common chunk. This is your keystream. Now XOR the keystream with your original savegame and you should have a fully decrypted savegame. XOR with the keystream again to produce an encrypted savegame.<br />
<br />
=== Wearleveling ===<br />
<br />
The 3DS employs a wearleveling scheme on the savegame FLASH chips. This is done trough blockmaps. Depending on the size of the flashchip, these are located somewhere at the beginning of the flashchip, in the first sector. The structure is as follows:<br />
<br />
<pre><br />
struct sector_entry {<br />
uint8_t virt_sec; // Mapped to sector<br />
uint8_t prev_virt_sec; // Physical sector previously mapped to<br />
uint8_t phys_sec; // Mapped from sector<br />
uint8_t prev_phys_sec; // Virtual sector previously mapped to<br />
uint8_t phys_realloc_cnt;// Amount of times virtual sector has been remapped<br />
uint8_t virt_realloc_cnt;// Amount of times physical sector has been remapped<br />
uint8_t chksums[8];<br />
} __attribute__((packed));<br />
<br />
struct long_sector_entry {<br />
struct sector_entry sector;<br />
struct sector_entry dupe;<br />
uint32_t magic;<br />
};<br />
</pre><br />
<br />
With magic being a constant 0x080d6ce0.<br />
<br />
=== Filesystem ===<br />
<br />
Savefiles stored on the FLASH are using a custom FS.<br />
<br />
It seems the file entries are stored somewhere in the third block. <br />
<br />
An fs_entry that has nodes > 1, is probably a directory.<br />
<br />
<pre><br />
struct fs_entry {<br />
u32 nodes;<br />
u8 filename[0x10];<br />
u32 file_id;<br />
u32 unk1;<br />
u32 block_offset;<br />
u32 file_size;<br />
u32 unk2;<br />
u32 unk3;<br />
u32 unk4;<br />
}<br />
</pre><br />
<br />
Example from Super MonkeyBall 3D:<br />
<pre><br />
0003800: 04000000 21000000 00000000 00000000 ....!...........<br />
0003810: 00000000 00000000 00000000 00000000 ................<br />
0003820: 00000000 00000000 00000000 00000000 ................<br />
0003830: 01000000 736d6233 64732e64 61740000 ....smb3ds.dat..<br />
0003840: 00000000 00000000 d57b1100 05000000 .........{......<br />
0003850: e4060000 00000000 c8cf0008 00000000 ................<br />
0003860: 01000000 6d677265 706c6179 30302e64 ....mgreplay00.d<br />
0003870: 61740000 01000000 d57b1100 09000000 at.......{......<br />
0003880: 1c210000 00000000 cd331000 00000000 .!.......3......<br />
0003890: 01000000 6d677265 706c6179 30312e64 ....mgreplay01.d<br />
00038a0: 61740000 02000000 d57b1100 1a000000 at.......{......<br />
00038b0: 1c210000 00000000 00000000 00000000 .!..............<br />
</pre><br />
[[セーブデータ|Japanese]]</div>
Bushing
https://www.3dbrew.org/w/index.php?title=Talk:SD_Filesystem&diff=191
Talk:SD Filesystem
2011-04-08T21:39:35Z
<p>Bushing: </p>
<hr />
<div>Are you sure that those offsets aren't exclusive to your SD card? Also, if an offset is hexadecimal, then you should put "0x" before the offset.--[[User:T3a|T3a]] 18:04, 8 April 2011 (CEST)<br />
:They're not offsets, they're filenames. [[User:Bushing|Bushing]] 23:39, 8 April 2011 (CEST)</div>
Bushing
https://www.3dbrew.org/w/index.php?title=Gamecards&diff=190
Gamecards
2011-04-08T20:52:19Z
<p>Bushing: </p>
<hr />
<div>[[File:Gamecard.jpg|thumb|right|A 3DS gamecard]] <br />
[[File:GamecardPhy.jpg|thumb|right|Close-up of PCB]] <br />
<br />
===Physical interface===<br />
The 3DS gamecards have the same physical interface as regular DS and DSi gamecards. There is only a minor cosmetic difference in the plastic case, which has a small extruding notch on the top-right side. As such, it prevents insertion of the gamecard into old Nintendo DS or DSi systems. <br />
<br />
When modifying the case so that the 3DS gamecard fits in a DS or DSi system, those systems will refuse to detect the gamecard and show no banner icon.<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Pin<br />
! Name<br />
! Description<br />
|-<br />
| 1<br />
| GND<br />
| Ground<br />
|-<br />
| 2<br />
| CLK<br />
| Clock. Frequencies 6.7MHz and 4.2MHz)<br />
|-<br />
| 3<br />
| NC<br />
| Not connected. Possibly used to program cards.<br />
|-<br />
| 4<br />
| RCS<br />
| ROM select, active low. Pulled low to start a ROM transfer.<br />
|-<br />
| 5<br />
| RST<br />
| Reset, active low. <br />
|-<br />
| 6<br />
| ECS<br />
| Savegame chip select, active low. Pulled low to start a savegame SPI transfer.<br />
|-<br />
| 7<br />
| IRQ<br />
| Removal detection.<br />
|-<br />
| 8<br />
| VCC<br />
| Powersupply 3.3V.<br />
|-<br />
| 9<br />
| DAT0<br />
| Bidirectional data bus.<br />
|-<br />
| 10<br />
| DAT1<br />
| Bidirectional data bus.<br />
|-<br />
| 11<br />
| DAT2<br />
| Bidirectional data bus.<br />
|-<br />
| 12<br />
| DAT3<br />
| Bidirectional data bus.<br />
|-<br />
| 13<br />
| DAT4<br />
| Bidirectional data bus / pin ? to savegame chip{{check}}<br />
|-<br />
| 14<br />
| DAT5<br />
| Bidirectional data bus / pin ? to savegame chip{{check}}<br />
|-<br />
| 15<br />
| DAT6<br />
| Bidirectional data bus / SPI data from savegame chip.<br />
|-<br />
| 16<br />
| DAT7<br />
| Bidirectional data bus / SPI data to savegame chip.<br />
|-<br />
| 17<br />
| GND<br />
| Ground<br />
|}<br />
<br />
===SPI flash===<br />
So far, only one savegame FLASH chip has been identified. The chip identifies as a 0xC22211. The JEDEC manufacturer ID is Macronix, and despite the chip label saying 25L1001 it is actually an MX25L1021E. Datasheet at: http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/3F21BAC2E121E17848257639003A3146/$File/MX25L1021E,%203V,%201Mb,%20v0.01.pdf.<br />
<br />
===Protocol===<br />
The communication protocol between the 3DS system and the 3DS gamecard has changed almost completely in comparison with the DS and DSi gamecard communication protocol.<br />
<br />
After the sixth transfer, commands change size from 8 bytes to 16 bytes. Possibly a new encryption is used, such as AES CTR.<br />
<br />
Here's a set of sample gamecard commands that a 3DS sends to a 3DS gamecard:<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! Size<br />
! Command<br />
! Description<br />
|-<br />
|2000<br />
|9F00000000000000<br />
| Reset<br />
|-<br />
|0000<br />
|71C93FE9BB0A3B18<br />
| Unknown<br />
|-<br />
|0004<br />
|9000000000000000<br />
| Get gamecard ID, response=9000FEC2<br />
|-<br />
|0004<br />
|9000000000000000<br />
| Get gamecard ID, response=9000FEC2<br />
|-<br />
|0004<br />
|A000000000000000<br />
| Unknown, response=00000000<br />
|-<br />
|0000<br />
|3E00000000000000<br />
| Enter 16-byte command mode.<br />
|-<br />
|07EC<br />
|82000000000000000000000000000000<br />
| Get header<br />
|-<br />
|05E3<br />
|F32C92D85C9D44DED3E0E41DBE7C90D9<br />
| Encrypted, unknown<br />
|-<br />
|0332<br />
|696B9D8582FB55D31B68CAFE70C74A95<br />
| Encrypted, unknown<br />
|-<br />
|0332<br />
|BAA4812CA0AC9C5D19399530E3ACCCAB<br />
| Encrypted, unknown<br />
|-<br />
|032E<br />
|178E427C22D87ADB86387249A97D321A<br />
| Encrypted, unknown<br />
|-<br />
|0332<br />
|E06019B1BD5C9130ED6A4D9F4A9E7193<br />
| Encrypted, unknown<br />
|-<br />
|0332<br />
|4E0D224862523BBFE2E6255F80E15F37<br />
| Encrypted, unknown<br />
|-<br />
|0332<br />
|4CDF93D319FB62D0DB632A45E3E8D84C<br />
| Encrypted, unknown<br />
|-<br />
|0332<br />
|9AA5D80551002F955546D296A57F0FEF<br />
| Encrypted, unknown<br />
|-<br />
|0332<br />
|C12BA81AEF30DDDBD93FAD5D544C6334<br />
| Encrypted, unknown<br />
|-<br />
|0532<br />
|62EC5FB7F420AE1DC6253AE18AFA5BB3<br />
| Encrypted, read address 0<br />
|-<br />
|0332<br />
|E3FA23AA016BE0C93430D1F42FF41324<br />
| Encrypted, read address 0x4000<br />
|}<br />
<br />
The header command has some initial dummy bytes, and eventually responds with a 0x200 byte header. Here's an example for Lego Starwars 3:<br />
0000000: 00 8c 03 00 00 00 04 00 00 00 00 00 00 00 00 00 ................<br />
0000010: b3 cf fb c6 6a b1 cb 20 32 af ce 35 d4 1c 74 c9 ....j.. 2..5..t.<br />
0000020: 8e 6b 27 2f 08 01 28 3b d4 30 de 44 37 f5 b0 46 .k'/..(;.0.D7..F<br />
0000030: 91 59 d7 38 33 48 df 83 fd 71 84 2c 00 00 00 00 .Y.83H...q.,....<br />
0000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
00000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
00000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
00000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
00000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
00000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
00000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0000100: 4e 43 43 48 7a 7f 0e 00 00 8c 03 00 00 00 04 00 NCCHz...........<br />
0000110: 36 34 02 00 00 00 00 00 00 8c 03 00 00 00 04 00 64..............<br />
0000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br />
0000150: 43 54 52 2d 50 2d 41 4c 47 50 00 00 00 00 00 00 CTR-P-ALGP......<br />
0000160: 0c 27 e3 c1 de 7b 2a e2 d3 11 4f 32 a4 ee bf 46 .'...{*...O2...F<br />
0000170: 9a fd 0c f3 52 c1 1d 49 84 c2 a9 f1 d2 14 4c 63 ....R..I......Lc<br />
0000180: 00 04 00 00 00 00 00 00 00 00 00 00 01 03 00 00 ................<br />
0000190: 05 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 ................<br />
00001a0: 06 00 00 00 1c 0a 00 00 01 00 00 00 00 00 00 00 ................<br />
00001b0: 22 0a 00 00 58 75 0e 00 01 00 00 00 00 00 00 00 "...Xu..........<br />
00001c0: 13 0c 04 26 15 f6 47 c4 c6 32 25 ea 9e 67 f8 a2 ...&..G..2%..g..<br />
00001d0: 7b 15 24 6b 88 fb c7 a9 27 25 7b 84 97 7b 78 7b {.$k....'%{..{x{<br />
00001e0: a6 5b ee 10 60 bb 6a 68 21 bb ce c6 00 03 5b 7e .[..`.jh!.....[~<br />
00001f0: 64 fb 6e ac a7 f0 96 0c fb 1f 5a 37 08 77 28 f7 d.n.......Z7.w(.</div>
Bushing
https://www.3dbrew.org/w/index.php?title=Template:Check/Doc&diff=189
Template:Check/Doc
2011-04-08T20:36:34Z
<p>Bushing: Created page with "{{Documentation subpage}} <!-- PLEASE ADD CATEGORIES AND INTERWIKIS AT THE BOTTOM OF THIS PAGE --> Sometimes some information comes from an unknown source, smells rotten, or is ..."</p>
<hr />
<div>{{Documentation subpage}}<br />
<!-- PLEASE ADD CATEGORIES AND INTERWIKIS AT THE BOTTOM OF THIS PAGE --><br />
<br />
Sometimes some information comes from an unknown source, smells rotten, or is just an educated guess. If you see this template, it means that you should double check the information before you use it. If you verify whether the information is correct or not, please update the page to remove this template and correct the information if necessary.<br />
<br />
=== Usage ===<br />
<tt><nowiki>{{check}}</nowiki></tt><br />
<br />
There are no parameters.<br />
<br />
=== See also ===<br />
<br />
<includeonly><br />
<!-- CATEGORIES AND INTERWIKIS HERE, THANKS --><br />
<br />
</includeonly></div>
Bushing
https://www.3dbrew.org/w/index.php?title=Template:Check&diff=188
Template:Check
2011-04-08T20:36:03Z
<p>Bushing: Created page with "<sup><span style="white-space: nowrap;" title="This might be wrong or incorrect, please check it">&#91;<i>check</i>&#93;</span></sup><noinclude> {{Documentatio..."</p>
<hr />
<div><sup><span style="white-space: nowrap;" title="This might be wrong or incorrect, please check it">&#91;<i>[[Template:Check|check]]</i>&#93;</span></sup><noinclude><br />
{{Documentation}}<br />
</noinclude><br />
<includeonly>[[Category:All pages with information that needs checking]]</includeonly></div>
Bushing
https://www.3dbrew.org/w/index.php?title=Hardware&diff=178
Hardware
2011-04-08T00:58:38Z
<p>Bushing: TI chip is a power manager (well, switch-mode supply controller)</p>
<hr />
<div>{{stub}}<br />
<br />
== Specifications ==<br />
According to iFixit.com ([http://www.ifixit.com/Teardown/Nintendo-3DS-Teardown/5029/1#s22696 source]):<br />
<br />
{| class="wikitable"<br />
! Type !! Name !! Datasheet !! Source<br />
|-<br />
| CPU || Nintendo 1048 0H 2x ARM11 266 @ 200Mhz || N/A || N/A<br />
|-<br />
| GPU || Digital Media Professionals Pica 200 @ 400Mhz || N/A || [http://en.wikipedia.org/wiki/PICA200]<br />
|-<br />
| RAM || Fujitsu MB82M8080-07L || N/A || [http://www.ifixit.com/blog/blog/2011/03/28/nintendo-3ds-has-128mb-ram/]<br />
|-<br />
| Storage || Toshiba THGBM2G3P1FBAI8 2 GB NAND Flash || N/A || N/A<br />
|-<br />
| Power Management || Texas Instruments PAIC3010B 0AA37DW || N/A || FCC filing<br />
|-<br />
| Gyroscope || Invensense ITG-3270 MEMS Gyroscope || [http://dl-web.dropbox.com/u/20520664/references/PS-ITG-3200-00-01.4.pdf] || --<br />
|-<br />
| Accelerometer || ST Micro 2048 33DH X1MAQ Accelerometer Model LIS331DH || [http://dl.dropbox.com/u/20520664/references/CD00213470.pdf] || --<br />
|}<br />
<br />
== Images ==<br />
<br />
=== Front ===<br />
<br />
[[Image:CTR_Front.jpg|600px]]<br />
<br />
=== NAND pinout ===<br />
[[Image:CTR_NAND_pinout.png]]</div>
Bushing
https://www.3dbrew.org/w/index.php?title=Main_Page/Navigation&diff=20
Main Page/Navigation
2010-06-30T08:29:08Z
<p>Bushing: add PXI</p>
<hr />
<div>{{Main page box|Navigation|Main Page/Navigation}}<br />
<div style="margin: -.3em -1em -1em -1em;"><br />
{| width="100%" bgcolor="#fff" border="0" cellpadding="2px" cellspacing="2px" style="margin:auto;"<br />
|- align="center" bgcolor="#e7eef6"<br />
! width="33%" | '''General'''<br />
! width="34%" | '''DSi hardware'''<br />
! width="33%" | '''DSi software'''<br />
|- valign="top" style="background: #F5FAFF;"<br />
| <br />
*[[DSiBrew:Contests|Contests]]<br />
*[[DSi exploits]]<br />
*[[Glossary]]<br />
*[[FAQ]]<br />
|<br />
*[[Hardware|DSi Hardware]]<br />
*[[Card hardware]]<br />
*[[Cameras]]<br />
| <br />
*[[Nintendo Software]]<br />
*[[NDS Format]]<br />
*[[Title list]]<br />
*[[Title metadata]]<br />
*[[SD Filesystem]]<br />
*[[Flash Filesystem]]<br />
*[[Bootloader]]<br />
*[[Exporting Apps]]<br />
*[[ES block encryption]]<br />
*[[PXI]]<br />
|}<br />
</div><br />
{{box-footer-empty}}</div>
Bushing