https://www.3dbrew.org/w/api.php?action=feedcontributions&user=Straybirdsnest&feedformat=atom3dbrew - User contributions [en]2024-03-28T09:04:19ZUser contributionsMediaWiki 1.35.8https://www.3dbrew.org/w/index.php?title=%E6%B8%B8%E6%88%8F%E5%AD%98%E6%A1%A3&diff=2667游戏存档2012-03-15T09:30:49Z<p>Straybirdsnest: /* Wear leveling */</p>
<hr />
<div>本页面描述了3DS游戏卡带(3DS game cartridges/gamecards)中以及别的地方发现的游戏存档格式,加密方法等等内容。你可以在[[Games|游戏]]页面找到多种游戏的存档。<br />
<br />
=== 加密手段 ===<br />
<br />
3DS上的游戏存档与DS的很像,都储存在游戏卡带的一块闪存芯片(FLASH chip)上。DS上这些游戏存档以明文的方式保存,但在3DS上则加了一层加密手段。正如对目录包含的游戏存档中的某些部分使用异或操作后显示出明文的奇怪行为所展示的那样,这很像是一种序列密码法( streamcipher)。<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 plain-text 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 behavior that xor-ing certain parts of the savegame together will result in the plain-text appearing.)<br />
<br />
这样猜测的理由在于序列密码法曾有一段时间使用512字节(作为单位来加密),即是说,在超过512字节之后,这种加密方法将重复某些关键字序列(keystream)。序列密码法加密的方法是,使用关键字序列对待加密数据进行异或操作,(得到的便是加密数据)。不幸的是,假如你使用重复的关键字序列加密某些已知的明文(在我们的场合里,是数据0),那么你基本上在泄漏你宝贵的关键字序列。(译者注:在位(Bit)级别上进行异或运算时,1^0=1,0^0=0,这里符号"^"表示异或,所以一个数据和0进行异或时会得到它本身。)<br />
<br />
(The reason this works is because the stream cipher 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 stream cipher is you XOR your data with the keystream as it is produced. Unfortunately, if your streamcipher repeats and you are encrypting a known plain-text (in our case, zeros) you are basically giving away your valuable keystream.)<br />
<br />
那么怎么在3DS上运用这种解密方法呢?首先,将游戏存档切成以512字节为单位长度的片段,然后将除了只包含FF以外的片段以二进制方式查看。现在寻找最常见的公共片段,那就是你的关键字序列。现在用你原始的游戏存档和这些关键字序列进行异或操作,你将得到一个完全解密的游戏存档。对关键字序列进行异或操作以产生加密的游戏存档。(译者注:异或运算的一个重要性质是,a^b^b=a;即使用同样的关键字b对a进行两次异或将得到a本身,所以使用关键字序列对加密的游戏存档异或会得到明文,再异或一次又得到加密的存档。)<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 />
更新:<br />
<br />
系统版本[[2.0.0-4]]中,使用了不同的CTR方式,修正了上述缺陷。异或操作似乎是在文件中重复进行,但不再以0x200字节为单位。目前还不知道如何解密这种新的存档文件。<br />
<br />
<br />
'''使用新加密方式的游戏:'''<br />
* Super Mario 3D Land 《超级马里奥3D大陆》<br />
* Mario Kart 7 《马里奥赛车7》<br />
* Need for Speed - The Run 《极品飞车-亡命狂飙》<br />
<br />
'''一些信息:'''<br />
* 旧游戏仍使用0x200字节的异或加密方式。<br />
* 新游戏存档可以被备份和再储存(同样的密钥将被一个个存档使用)。New games saves can be backed-up and restored (same key is used from one save to another). <br />
* (wearleveling) 没有变化。<br />
* 对两个文件使用异或将产生一些明文。<br />
* 0x1000字节后,异或操作将停止。(所以 0x1000 可能是最大长度,但还未证实)<br />
<br />
=== Wear leveling ===<br />
<br />
3DS在游戏存档闪存芯片上引入了wear leveling 方案。这是通过使用blockmap和journal来实现的。blockmap在闪存上偏移量为0,其后是journal。初始状态由blockmap指定,然后journal对其进行应用。<br />
<br />
The 3DS employs a wear leveling scheme on the savegame FLASH chips. This is done through the usage of blockmaps and a journal. The blockmap is located at offset 0 of the flash chip, and is immediately followed by the journal. The initial state is dictated by the blockmap, and the journal is then applied to that.<br />
<br />
首先,是8字节目前还不明白其确切意义的数据。然后是实际的blockmap。其结构很简单:<br />
<br />
<pre><br />
struct header_entry {<br />
uint8_t phys_sec; // when bit7 is set, block has checksums, otherwise checksums are all zero<br />
uint8_t alloc_cnt;<br />
uint8_t chksums[8];<br />
} __attribute__((__packed__));<br />
</pre><br />
<br />
每个sector有一个入口,从实际的sector1开始计数(sector 0 包含blockmap/journal)。<br />
<br />
blockmap后2字节为最开始的8个字节,以及blockmap的CRC16校验码(开始值为0xFFFF(像modbus))。<br />
The 2 bytes that follow the blockmap are the CRC16 (with starting value 0xFFFF (like modbus)) of the first 8 bytes and the blockmap.<br />
<br />
然后是journal。其结构如下:<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 physical sector has been remapped<br />
uint8_t virt_realloc_cnt; // Amount of times virtual 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 />
}__attribute__((__packed__));<br />
</pre><br />
<br />
With magic being a constant 0x080d6ce0.<br />
<br />
The checksums in the blockmap/journal entries work as follows:<br />
* each byte is the checksum of an encrypted 0x200 bytes large block<br />
* to calculate the checksum, a CRC16 of the block (with starting value 0xFFFF) is calculated, and the two bytes of the CRC16 are XORed together to produce the 8bit checksum<br />
<br />
=== Partitions ===<br />
<br />
There can be multiple partitions on the chip. <br />
The partitions are represented by tables of DIFI blobs inside a DISA structure.<br />
The order of the DIFI blobs is the order of the partitions in the chip.<br />
<br />
'''DISA'''<br />
<br />
* If the uint32 @ 0x168 into the image in the DISA(the low 8-bits) is non-zero, then first table is is hashed, otherwise the second DIFI table is hashed. <br />
* If the table has more then 1 DIFI then the uint32 @ 0x168 is the offset from the DATA partition to the file base (masked with 0xFFFFFFFE).<br />
* At offset 0x0 in the image is a 0x10-byte MAC over the 0x100-byte DISA/DIFF, it might be AES-CCM MAC but it's unknown for certain. The following 0xf0-bytes after the MAC normally must be zero, it's unknown whether this can ever be non-zero.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Start<br />
! Length<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Magic ("DISA")<br />
|-<br />
| 0x04<br />
| 4<br />
| Magic Number (0x40000)<br />
|-<br />
| 0x08<br />
| 8<br />
| Partition table size<br />
|-<br />
| 0x10<br />
| 8<br />
| Offset to primary partition table in DISA<br />
|-<br />
| 0x18<br />
| 8<br />
| Offset to secondary partition table in DISA<br />
|-<br />
| 0x20<br />
| 8<br />
| Partition table's length<br />
|-<br />
| 0x28<br />
| 8<br />
| SAVE Partition entry offset in the partition table<br />
|-<br />
| 0x30<br />
| 8<br />
| SAVE Partition entry length in the partition table<br />
|-<br />
| 0x38<br />
| 8<br />
| DATA Partition entry offset in the partition table<br />
|-<br />
| 0x40<br />
| 8<br />
| DATA Partition entry length in the partition table<br />
|-<br />
| 0x48<br />
| 8<br />
| SAVE Partition offset<br />
|-<br />
| 0x50<br />
| 8<br />
| SAVE Partition length<br />
|-<br />
| 0x58<br />
| 8<br />
| DATA Partition offset<br />
|-<br />
| 0x60<br />
| 8<br />
| DATA Partition length<br />
|-<br />
| 0x68<br />
| 4<br />
| Active table (and the offset to the filebase)<br />
|-<br />
| 0x6C<br />
| 0x20<br />
| Hash from active table<br />
|-<br />
| 0x8C<br />
| 4*29<br />
| Unknown<br />
|}<br />
<br />
* The hash in the DISA hashes the Active Table (starting from tables's offset to tables's offset + table length) with SHA256.<br />
<br />
* The partitions offsets points to a 0x1000 long block which isn't understood yet. The actual information starts after that block.<br />
<br />
The DIFIs table @ 0x200 (into the image) is written twice, (Meaning, if there's 4 DIFI blobs then the table is 2 DIFIs long).<br />
<br />
The second table is for backup. The active table is mentioned at 0x13C into the image (1=First table, other=Second Table)<br />
<br />
'''DIFF'''<br />
<br />
* This is the [[extdata]] equivalent of DISA, for extdata which use FS. DIFF is *only* used with extdata, not regular savegames.<br />
<br />
* When the active-table field low 8-bits is non-zero, the primary partition is used. Otherwise, the secondary partition is used.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Start<br />
! Length<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Magic ("DIFF")<br />
|-<br />
| 0x04<br />
| 4<br />
| Magic Number (0x30000)<br />
|-<br />
| 0x08<br />
| 8<br />
| Primary partition table offset<br />
|-<br />
| 0x10<br />
| 8<br />
| Secondary partition table offset<br />
|-<br />
| 0x18<br />
| 8<br />
| Partition table length<br />
|-<br />
| 0x20<br />
| 4<br />
| Active table (and the offset to the filebase)<br />
|-<br />
| 0x24<br />
| 0x20<br />
| Unknown<br />
|-<br />
| 0x34<br />
| 0x20<br />
| Hash of the active partition table<br />
|-<br />
| 0x54<br />
| 0x1ac<br />
| Unknown<br />
|}<br />
<br />
'''DIFI'''<br />
<br />
These 0x130 large blobs describe the partitions. Every DIFI blob describes a partition. Partitions are catted together, so after the end of one partition is the beginning of the next.<br />
<br />
Actually DIFI blobs are 0x12C large because the last 4 are not used and appear 0xFFFFFFFF at the encrypted image.<br />
<br />
For most games there's only 1 partition (The SAVE partition) and some (like Asphalt 3D, Steel Diver & Lego Star Wars III) has 2 partitions.<br />
<br />
* 2 Partitions means that the files inside the SAVE partition is on the other partition (we would call it DATA partition).<br />
<br />
* No more than 2 partitions have been seen yet (and can't be because of the DISA known structure).<br />
<br />
{| class="wikitable"<br />
|-<br />
! Start<br />
! Length<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Magic ("DIFI")<br />
|-<br />
| 0x04<br />
| 4<br />
| Magic Number (0x10000)<br />
|-<br />
| 0x08<br />
| 8<br />
| Offset to "IVFC" blob in DIFI (usually 0x44)<br />
|-<br />
| 0x10<br />
| 8<br />
| Size of "IVFC" blob<br />
|-<br />
| 0x18<br />
| 8<br />
| Offset to "DPFS" blob in DIFI (usually 0xBC)<br />
|-<br />
| 0x20<br />
| 8<br />
| Size of "DPFS" blob<br />
|-<br />
| 0x28<br />
| 8<br />
| Offset to the hash in DIFI (usually 0x010C)<br />
|-<br />
| 0x30<br />
| 8<br />
| Size of this hash<br />
|-<br />
| 0x38<br />
| 4<br />
| Flags (when this byte is non-zero, this is a DATA partition)<br />
|-<br />
| 0x3C<br />
| 8<br />
| File base offset (for DATA partitions)<br />
|}<br />
<br />
'''IVFC'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! Start<br />
! Length<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Magic ("IVFC")<br />
|-<br />
| 0x04<br />
| 4<br />
| Magic Number (0x20000)<br />
|-<br />
| 0x08<br />
| 8<br />
| Unknown (0x20?)<br />
|-<br />
| 0x10<br />
| 8<br />
| First Hash Offset<br />
|-<br />
| 0x18<br />
| 8<br />
| First Hash Length<br />
|-<br />
| 0x20<br />
| 8<br />
| First Hash Block Size (1<<value)<br />
|-<br />
| 0x28<br />
| 8<br />
| Second Hash Offset<br />
|-<br />
| 0x30<br />
| 8<br />
| Second Hash Length<br />
|-<br />
| 0x38<br />
| 8<br />
| Second Hash Block Size (1<<value)<br />
|-<br />
| 0x40<br />
| 8<br />
| HashTable Offset<br />
|-<br />
| 0x48<br />
| 8<br />
| HashTable Length<br />
|-<br />
| 0x50<br />
| 8<br />
| HashTable Block Size (1<<value)<br />
|-<br />
| 0x58<br />
| 8<br />
| FileSystem Offset<br />
|-<br />
| 0x60<br />
| 8<br />
| FileSystem Length<br />
|-<br />
| 0x68<br />
| 8<br />
| FileSystem Block Size (1<<value)<br />
|-<br />
| 0x70<br />
| 8<br />
| Unknown (usually 0x78=120)<br />
|-<br />
|}<br />
<br />
* First & Second hash are not understood yet.<br />
<br />
'''DPFS'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! Start<br />
! Length<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Magic ("DPFS")<br />
|-<br />
| 0x04<br />
| 4<br />
| Magic Number (0x10000)<br />
|-<br />
| 0x08<br />
| 8<br />
| Offset To First table<br />
|-<br />
| 0x10<br />
| 8<br />
| First table length<br />
|-<br />
| 0x18<br />
| 8<br />
| First table block size (1<<value)<br />
|-<br />
| 0x20<br />
| 8<br />
| Offset To Second table<br />
|-<br />
| 0x28<br />
| 8<br />
| Second table length<br />
|-<br />
| 0x30<br />
| 8<br />
| Second table block size (1<<value)<br />
|-<br />
| 0x38<br />
| 8<br />
| Offset to Data<br />
|-<br />
| 0x40<br />
| 8<br />
| Data Length<br />
|-<br />
| 0x48<br />
| 8<br />
| Data block size (1<<value)<br />
|-<br />
|}<br />
<br />
* Every block this table point to is written twice (concatenated). You can see that the offset to the next block is twice the length (except the data which always begin after 0x1000).<br />
<br />
The first partition's data starts at 0x2000. First comes the hashtable (usually start @ 0x40 into the partition) and then the filesystem.<br />
<br />
The hashtable entries' size is 2^x where x is the 'Hashed block size' from the IVFC block.<br />
<br />
'''Hash'''<br />
<br />
After the DIFI,IVFC & DPFS comes a 0x20 long hash, it is unknown what it's hashing.<br />
<br />
'''Summary Drawing'''<br />
<br />
[[File:Sfimg_drawing.png]]<br />
<br />
==== The SAVE partition ====<br />
<br />
* The SAVE filesystem works with a backup. There are two SAVE blocks inside the partition concatenated. Which SAVE block is the updated one is unknown yet.. (I'm guessing from experience that (image[0x100B] & 0x20) == 0x20 --> 1st SAVE --[[User:Elisherer|Elisherer]] 01:30, 18 October 2011 (CEST))<br />
<br />
'''Finding the folders table:'''<br />
* If DATA partition exists: At folder table exact offset from the SAVE struct (from the beginning of the struct).<br />
* Otherwise: The 'folder table offset' * 'folder table media' (=0x200) from the 'filestore offset'. (usually 0 from filebase)<br />
<br />
'''Finding the files table:'''<br />
* If DATA partition exists: At file table exact offset from the SAVE struct (from the beginning of the struct).<br />
* Otherwise: The 'file table offset' * 'file table media' (=0x200) from the 'filestore offset'.<br />
<br />
'''Detemining the filestore base:'''<br />
* If DATA partition exists: At file base from the DATA's DIFI struct into the DATA partition.<br />
* Otherwise: At the 'filestore offset' from the beginning of the SAVE struct.<br />
<br />
Folder's entry structure:<br />
<pre><br />
struct folder_entry {<br />
u32 parent_folder_index;<br />
u8 filename[0x10];<br />
u32 folder_index;<br />
u32 unk1; <br />
u32 last_file_index;<br />
u32 unk3; <br />
u32 unk4;<br />
}<br />
</pre><br />
<br />
File's entry structure:<br />
<pre><br />
struct file_entry {<br />
u32 parent_folder_index;<br />
u8 filename[0x10];<br />
u32 index;<br />
u32 unk1; // magic?<br />
u32 block_offset;<br />
u64 file_size;<br />
u32 unk2; // flags?<br />
u32 unk3;<br />
}<br />
</pre><br />
<br />
The first entry in both tables is the count of the table, the parent directory index will be the amount of table rows. The root includes itself, so there are the amount - 1 (minus one) folders in the root directory (or files). The entries that follow after the root are the actual folders/files.<br />
<br />
Reading the files out is as simple as taking the file base offset and adding (block_offset * 0x200) to it.<br />
<br />
Here's a follow-up example from the Legend of Zelda: Ocarina of Time 3D:<br />
<pre><br />
//FST entry = SAVE base + File base + (FST offset * 0x200) + (FST entry # * 0x30)<br />
//0x2600 = 0x2000 + 0x400 + (0x1 * 0x200) + (0x0 * 0x30)<br />
<br />
00002600: 03000000 09000000 00000000 00000000 ................<br />
00002610: 00000000 00000000 00000000 00000000 ................<br />
00002620: 00000000 00000000 00000000 00000000 ................<br />
00002630: 01000000 73797374 656D2E64 61740000 ....system.dat..<br />
00002640: 00000000 00000000 D57B1100 02000000 ........Õ{......<br />
00002650: 22000000 00000000 E8121500 00000000 ".......è.......<br />
00002660: 01000000 73617665 30302E62 696E0000 ....save00.bin..<br />
00002670: 00000000 01000000 69921100 03000000 ........i’......<br />
00002680: DC140000 00000000 04000000 00000000 Ü...............<br />
</pre><br />
<br />
{| class="wikitable"<br />
|-<br />
! Start<br />
! Length<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Magic ("SAVE")<br />
|-<br />
| 0x04<br />
| 4<br />
| Magic Number (0x40000)<br />
|-<br />
| 0x08<br />
| 8<br />
| Offset to data in this SAVE header(normally 0x20)<br />
|-<br />
| 0x10<br />
| 8<br />
| Partition Size [medias]<br />
|-<br />
| 0x18<br />
| 4<br />
| Partition Media Size<br />
|-<br />
| 0x1C<br />
| 8<br />
| Unknown<br />
|-<br />
| 0x24<br />
| 4<br />
| Unknown<br />
|-<br />
| 0x28<br />
| 8<br />
| FolderMap Offset<br />
|-<br />
| 0x30<br />
| 4<br />
| FolderMap Size<br />
|-<br />
| 0x34<br />
| 4<br />
| FolderMap Media Size<br />
|-<br />
| 0x38<br />
| 8<br />
| FileMap Offset<br />
|-<br />
| 0x40<br />
| 4<br />
| FileMap Size<br />
|-<br />
| 0x44<br />
| 4<br />
| FileMap Media Size<br />
|-<br />
| 0x48<br />
| 8<br />
| BlockMap Offset<br />
|-<br />
| 0x50<br />
| 4<br />
| BlockMap Size<br />
|-<br />
| 0x54<br />
| 4<br />
| BlockMap Media Size<br />
|-<br />
| 0x58<br />
| 8<br />
| File store offset (from SAVE)<br />
|-<br />
| 0x60<br />
| 4<br />
| File store length [medias]<br />
|-<br />
| 0x64<br />
| 4<br />
| File store media size<br />
|-<br />
| 0x68<br />
| 4/8<br />
| Folders Table offset (8 bytes in DATA)<br />
|-<br />
| 0x6C<br />
| 4<br />
| Folders Table Length (medias) (Only in no DATA)<br />
|-<br />
| 0x70<br />
| 4<br />
| Folders Table unknown<br />
|-<br />
| 0x74<br />
| 4<br />
| Folders Table Media size<br />
|-<br />
| 0x78<br />
| 4/8<br />
| Files Table offset (8 bytes in DATA)<br />
|-<br />
| 0x7C<br />
| 4<br />
| Files Table Length (medias) (Only in no DATA)<br />
|-<br />
| 0x80<br />
| 4<br />
| Files Table unknown<br />
|-<br />
| 0x84<br />
| 4<br />
| Files Table Media size<br />
|-<br />
|}<br />
<br />
* The FolderMap and FileMap still unknown. They are tables of uint32.<br />
* The BlockMap is a map of the blocks in the filestore. An entry in the BlockMap is 2 uint32: {uint32 start_block; uint32 end_block; }. This is still being researched. (You can use [[3DSExplorer]] to see those maps.<br />
<br />
'''Summary Drawing'''<br />
<br />
[[File:Sfsave_drawing.png]]<br />
<br />
=== Initialization ===<br />
<br />
When a save FLASH contains all xFFFF blocks it's assumed uninitialized by the game cartridges and it initializes default data in place, without prompting the user. <br />
<br />
I got a new game SplinterCell3D-Pal and I downloaded the save and it was 128KB of 0xFF, except the first 0x10 bytes which were the letter 'Z' (uppercase) --[[User:Elisherer|Elisherer]] 22:41, 15 October 2011 (CEST)<br />
<br />
=== Fun Facts ===<br />
<br />
If you have facts that you found out by looking at the binary files please share them here:<br />
<br />
* From one save to another the game backups the last files that were in the partition and the entire image header in "random" locations.. --[[User:Elisherer|Elisherer]] 22:41, 15 October 2011 (CEST)<br />
<br />
[[セーブデータ|Japanese]]</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=%E6%B8%B8%E6%88%8F%E5%AD%98%E6%A1%A3&diff=2666游戏存档2012-03-15T09:14:33Z<p>Straybirdsnest: Translation for Savegames, NOT completed.</p>
<hr />
<div>本页面描述了3DS游戏卡带(3DS game cartridges/gamecards)中以及别的地方发现的游戏存档格式,加密方法等等内容。你可以在[[Games|游戏]]页面找到多种游戏的存档。<br />
<br />
=== 加密手段 ===<br />
<br />
3DS上的游戏存档与DS的很像,都储存在游戏卡带的一块闪存芯片(FLASH chip)上。DS上这些游戏存档以明文的方式保存,但在3DS上则加了一层加密手段。正如对目录包含的游戏存档中的某些部分使用异或操作后显示出明文的奇怪行为所展示的那样,这很像是一种序列密码法( streamcipher)。<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 plain-text 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 behavior that xor-ing certain parts of the savegame together will result in the plain-text appearing.)<br />
<br />
这样猜测的理由在于序列密码法曾有一段时间使用512字节(作为单位来加密),即是说,在超过512字节之后,这种加密方法将重复某些关键字序列(keystream)。序列密码法加密的方法是,使用关键字序列对待加密数据进行异或操作,(得到的便是加密数据)。不幸的是,假如你使用重复的关键字序列加密某些已知的明文(在我们的场合里,是数据0),那么你基本上在泄漏你宝贵的关键字序列。(译者注:在位(Bit)级别上进行异或运算时,1^0=1,0^0=0,这里符号"^"表示异或,所以一个数据和0进行异或时会得到它本身。)<br />
<br />
(The reason this works is because the stream cipher 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 stream cipher is you XOR your data with the keystream as it is produced. Unfortunately, if your streamcipher repeats and you are encrypting a known plain-text (in our case, zeros) you are basically giving away your valuable keystream.)<br />
<br />
那么怎么在3DS上运用这种解密方法呢?首先,将游戏存档切成以512字节为单位长度的片段,然后将除了只包含FF以外的片段以二进制方式查看。现在寻找最常见的公共片段,那就是你的关键字序列。现在用你原始的游戏存档和这些关键字序列进行异或操作,你将得到一个完全解密的游戏存档。对关键字序列进行异或操作以产生加密的游戏存档。(译者注:异或运算的一个重要性质是,a^b^b=a;即使用同样的关键字b对a进行两次异或将得到a本身,所以使用关键字序列对加密的游戏存档异或会得到明文,再异或一次又得到加密的存档。)<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 />
更新:<br />
<br />
系统版本[[2.0.0-4]]中,使用了不同的CTR方式,修正了上述缺陷。异或操作似乎是在文件中重复进行,但不再以0x200字节为单位。目前还不知道如何解密这种新的存档文件。<br />
<br />
<br />
'''使用新加密方式的游戏:'''<br />
* Super Mario 3D Land 《超级马里奥3D大陆》<br />
* Mario Kart 7 《马里奥赛车7》<br />
* Need for Speed - The Run 《极品飞车-亡命狂飙》<br />
<br />
'''一些信息:'''<br />
* 旧游戏仍使用0x200字节的异或加密方式。<br />
* 新游戏存档可以被备份和再储存(同样的密钥将被一个个存档使用)。New games saves can be backed-up and restored (same key is used from one save to another). <br />
* (wearleveling) 没有变化。<br />
* 对两个文件使用异或将产生一些明文。<br />
* 0x1000字节后,异或操作将停止。(所以 0x1000 可能是最大长度,但还未证实)<br />
<br />
=== Wear leveling ===<br />
<br />
The 3DS employs a wear leveling scheme on the savegame FLASH chips. This is done through the usage of blockmaps and a journal. The blockmap is located at offset 0 of the flash chip, and is immediately followed by the journal. The initial state is dictated by the blockmap, and the journal is then applied to that.<br />
<br />
First, there are 8 bytes whose purposes are currently unknown. Then comes the actual blockmap.<br />
The blockmap structure is simple:<br />
<pre><br />
struct header_entry {<br />
uint8_t phys_sec; // when bit7 is set, block has checksums, otherwise checksums are all zero<br />
uint8_t alloc_cnt;<br />
uint8_t chksums[8];<br />
} __attribute__((__packed__));<br />
</pre><br />
<br />
There's one entry per sector, counting from physical sector 1 (sector 0 contains the blockmap/journal).<br />
<br />
The 2 bytes that follow the blockmap are the CRC16 (with starting value 0xFFFF (like modbus)) of the first 8 bytes and the blockmap.<br />
<br />
Then comes the journal.<br />
The journal structure is as follows:<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 physical sector has been remapped<br />
uint8_t virt_realloc_cnt; // Amount of times virtual 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 />
}__attribute__((__packed__));<br />
</pre><br />
<br />
With magic being a constant 0x080d6ce0.<br />
<br />
The checksums in the blockmap/journal entries work as follows:<br />
* each byte is the checksum of an encrypted 0x200 bytes large block<br />
* to calculate the checksum, a CRC16 of the block (with starting value 0xFFFF) is calculated, and the two bytes of the CRC16 are XORed together to produce the 8bit checksum<br />
<br />
=== Partitions ===<br />
<br />
There can be multiple partitions on the chip. <br />
The partitions are represented by tables of DIFI blobs inside a DISA structure.<br />
The order of the DIFI blobs is the order of the partitions in the chip.<br />
<br />
'''DISA'''<br />
<br />
* If the uint32 @ 0x168 into the image in the DISA(the low 8-bits) is non-zero, then first table is is hashed, otherwise the second DIFI table is hashed. <br />
* If the table has more then 1 DIFI then the uint32 @ 0x168 is the offset from the DATA partition to the file base (masked with 0xFFFFFFFE).<br />
* At offset 0x0 in the image is a 0x10-byte MAC over the 0x100-byte DISA/DIFF, it might be AES-CCM MAC but it's unknown for certain. The following 0xf0-bytes after the MAC normally must be zero, it's unknown whether this can ever be non-zero.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Start<br />
! Length<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Magic ("DISA")<br />
|-<br />
| 0x04<br />
| 4<br />
| Magic Number (0x40000)<br />
|-<br />
| 0x08<br />
| 8<br />
| Partition table size<br />
|-<br />
| 0x10<br />
| 8<br />
| Offset to primary partition table in DISA<br />
|-<br />
| 0x18<br />
| 8<br />
| Offset to secondary partition table in DISA<br />
|-<br />
| 0x20<br />
| 8<br />
| Partition table's length<br />
|-<br />
| 0x28<br />
| 8<br />
| SAVE Partition entry offset in the partition table<br />
|-<br />
| 0x30<br />
| 8<br />
| SAVE Partition entry length in the partition table<br />
|-<br />
| 0x38<br />
| 8<br />
| DATA Partition entry offset in the partition table<br />
|-<br />
| 0x40<br />
| 8<br />
| DATA Partition entry length in the partition table<br />
|-<br />
| 0x48<br />
| 8<br />
| SAVE Partition offset<br />
|-<br />
| 0x50<br />
| 8<br />
| SAVE Partition length<br />
|-<br />
| 0x58<br />
| 8<br />
| DATA Partition offset<br />
|-<br />
| 0x60<br />
| 8<br />
| DATA Partition length<br />
|-<br />
| 0x68<br />
| 4<br />
| Active table (and the offset to the filebase)<br />
|-<br />
| 0x6C<br />
| 0x20<br />
| Hash from active table<br />
|-<br />
| 0x8C<br />
| 4*29<br />
| Unknown<br />
|}<br />
<br />
* The hash in the DISA hashes the Active Table (starting from tables's offset to tables's offset + table length) with SHA256.<br />
<br />
* The partitions offsets points to a 0x1000 long block which isn't understood yet. The actual information starts after that block.<br />
<br />
The DIFIs table @ 0x200 (into the image) is written twice, (Meaning, if there's 4 DIFI blobs then the table is 2 DIFIs long).<br />
<br />
The second table is for backup. The active table is mentioned at 0x13C into the image (1=First table, other=Second Table)<br />
<br />
'''DIFF'''<br />
<br />
* This is the [[extdata]] equivalent of DISA, for extdata which use FS. DIFF is *only* used with extdata, not regular savegames.<br />
<br />
* When the active-table field low 8-bits is non-zero, the primary partition is used. Otherwise, the secondary partition is used.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Start<br />
! Length<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Magic ("DIFF")<br />
|-<br />
| 0x04<br />
| 4<br />
| Magic Number (0x30000)<br />
|-<br />
| 0x08<br />
| 8<br />
| Primary partition table offset<br />
|-<br />
| 0x10<br />
| 8<br />
| Secondary partition table offset<br />
|-<br />
| 0x18<br />
| 8<br />
| Partition table length<br />
|-<br />
| 0x20<br />
| 4<br />
| Active table (and the offset to the filebase)<br />
|-<br />
| 0x24<br />
| 0x20<br />
| Unknown<br />
|-<br />
| 0x34<br />
| 0x20<br />
| Hash of the active partition table<br />
|-<br />
| 0x54<br />
| 0x1ac<br />
| Unknown<br />
|}<br />
<br />
'''DIFI'''<br />
<br />
These 0x130 large blobs describe the partitions. Every DIFI blob describes a partition. Partitions are catted together, so after the end of one partition is the beginning of the next.<br />
<br />
Actually DIFI blobs are 0x12C large because the last 4 are not used and appear 0xFFFFFFFF at the encrypted image.<br />
<br />
For most games there's only 1 partition (The SAVE partition) and some (like Asphalt 3D, Steel Diver & Lego Star Wars III) has 2 partitions.<br />
<br />
* 2 Partitions means that the files inside the SAVE partition is on the other partition (we would call it DATA partition).<br />
<br />
* No more than 2 partitions have been seen yet (and can't be because of the DISA known structure).<br />
<br />
{| class="wikitable"<br />
|-<br />
! Start<br />
! Length<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Magic ("DIFI")<br />
|-<br />
| 0x04<br />
| 4<br />
| Magic Number (0x10000)<br />
|-<br />
| 0x08<br />
| 8<br />
| Offset to "IVFC" blob in DIFI (usually 0x44)<br />
|-<br />
| 0x10<br />
| 8<br />
| Size of "IVFC" blob<br />
|-<br />
| 0x18<br />
| 8<br />
| Offset to "DPFS" blob in DIFI (usually 0xBC)<br />
|-<br />
| 0x20<br />
| 8<br />
| Size of "DPFS" blob<br />
|-<br />
| 0x28<br />
| 8<br />
| Offset to the hash in DIFI (usually 0x010C)<br />
|-<br />
| 0x30<br />
| 8<br />
| Size of this hash<br />
|-<br />
| 0x38<br />
| 4<br />
| Flags (when this byte is non-zero, this is a DATA partition)<br />
|-<br />
| 0x3C<br />
| 8<br />
| File base offset (for DATA partitions)<br />
|}<br />
<br />
'''IVFC'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! Start<br />
! Length<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Magic ("IVFC")<br />
|-<br />
| 0x04<br />
| 4<br />
| Magic Number (0x20000)<br />
|-<br />
| 0x08<br />
| 8<br />
| Unknown (0x20?)<br />
|-<br />
| 0x10<br />
| 8<br />
| First Hash Offset<br />
|-<br />
| 0x18<br />
| 8<br />
| First Hash Length<br />
|-<br />
| 0x20<br />
| 8<br />
| First Hash Block Size (1<<value)<br />
|-<br />
| 0x28<br />
| 8<br />
| Second Hash Offset<br />
|-<br />
| 0x30<br />
| 8<br />
| Second Hash Length<br />
|-<br />
| 0x38<br />
| 8<br />
| Second Hash Block Size (1<<value)<br />
|-<br />
| 0x40<br />
| 8<br />
| HashTable Offset<br />
|-<br />
| 0x48<br />
| 8<br />
| HashTable Length<br />
|-<br />
| 0x50<br />
| 8<br />
| HashTable Block Size (1<<value)<br />
|-<br />
| 0x58<br />
| 8<br />
| FileSystem Offset<br />
|-<br />
| 0x60<br />
| 8<br />
| FileSystem Length<br />
|-<br />
| 0x68<br />
| 8<br />
| FileSystem Block Size (1<<value)<br />
|-<br />
| 0x70<br />
| 8<br />
| Unknown (usually 0x78=120)<br />
|-<br />
|}<br />
<br />
* First & Second hash are not understood yet.<br />
<br />
'''DPFS'''<br />
<br />
{| class="wikitable"<br />
|-<br />
! Start<br />
! Length<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Magic ("DPFS")<br />
|-<br />
| 0x04<br />
| 4<br />
| Magic Number (0x10000)<br />
|-<br />
| 0x08<br />
| 8<br />
| Offset To First table<br />
|-<br />
| 0x10<br />
| 8<br />
| First table length<br />
|-<br />
| 0x18<br />
| 8<br />
| First table block size (1<<value)<br />
|-<br />
| 0x20<br />
| 8<br />
| Offset To Second table<br />
|-<br />
| 0x28<br />
| 8<br />
| Second table length<br />
|-<br />
| 0x30<br />
| 8<br />
| Second table block size (1<<value)<br />
|-<br />
| 0x38<br />
| 8<br />
| Offset to Data<br />
|-<br />
| 0x40<br />
| 8<br />
| Data Length<br />
|-<br />
| 0x48<br />
| 8<br />
| Data block size (1<<value)<br />
|-<br />
|}<br />
<br />
* Every block this table point to is written twice (concatenated). You can see that the offset to the next block is twice the length (except the data which always begin after 0x1000).<br />
<br />
The first partition's data starts at 0x2000. First comes the hashtable (usually start @ 0x40 into the partition) and then the filesystem.<br />
<br />
The hashtable entries' size is 2^x where x is the 'Hashed block size' from the IVFC block.<br />
<br />
'''Hash'''<br />
<br />
After the DIFI,IVFC & DPFS comes a 0x20 long hash, it is unknown what it's hashing.<br />
<br />
'''Summary Drawing'''<br />
<br />
[[File:Sfimg_drawing.png]]<br />
<br />
==== The SAVE partition ====<br />
<br />
* The SAVE filesystem works with a backup. There are two SAVE blocks inside the partition concatenated. Which SAVE block is the updated one is unknown yet.. (I'm guessing from experience that (image[0x100B] & 0x20) == 0x20 --> 1st SAVE --[[User:Elisherer|Elisherer]] 01:30, 18 October 2011 (CEST))<br />
<br />
'''Finding the folders table:'''<br />
* If DATA partition exists: At folder table exact offset from the SAVE struct (from the beginning of the struct).<br />
* Otherwise: The 'folder table offset' * 'folder table media' (=0x200) from the 'filestore offset'. (usually 0 from filebase)<br />
<br />
'''Finding the files table:'''<br />
* If DATA partition exists: At file table exact offset from the SAVE struct (from the beginning of the struct).<br />
* Otherwise: The 'file table offset' * 'file table media' (=0x200) from the 'filestore offset'.<br />
<br />
'''Detemining the filestore base:'''<br />
* If DATA partition exists: At file base from the DATA's DIFI struct into the DATA partition.<br />
* Otherwise: At the 'filestore offset' from the beginning of the SAVE struct.<br />
<br />
Folder's entry structure:<br />
<pre><br />
struct folder_entry {<br />
u32 parent_folder_index;<br />
u8 filename[0x10];<br />
u32 folder_index;<br />
u32 unk1; <br />
u32 last_file_index;<br />
u32 unk3; <br />
u32 unk4;<br />
}<br />
</pre><br />
<br />
File's entry structure:<br />
<pre><br />
struct file_entry {<br />
u32 parent_folder_index;<br />
u8 filename[0x10];<br />
u32 index;<br />
u32 unk1; // magic?<br />
u32 block_offset;<br />
u64 file_size;<br />
u32 unk2; // flags?<br />
u32 unk3;<br />
}<br />
</pre><br />
<br />
The first entry in both tables is the count of the table, the parent directory index will be the amount of table rows. The root includes itself, so there are the amount - 1 (minus one) folders in the root directory (or files). The entries that follow after the root are the actual folders/files.<br />
<br />
Reading the files out is as simple as taking the file base offset and adding (block_offset * 0x200) to it.<br />
<br />
Here's a follow-up example from the Legend of Zelda: Ocarina of Time 3D:<br />
<pre><br />
//FST entry = SAVE base + File base + (FST offset * 0x200) + (FST entry # * 0x30)<br />
//0x2600 = 0x2000 + 0x400 + (0x1 * 0x200) + (0x0 * 0x30)<br />
<br />
00002600: 03000000 09000000 00000000 00000000 ................<br />
00002610: 00000000 00000000 00000000 00000000 ................<br />
00002620: 00000000 00000000 00000000 00000000 ................<br />
00002630: 01000000 73797374 656D2E64 61740000 ....system.dat..<br />
00002640: 00000000 00000000 D57B1100 02000000 ........Õ{......<br />
00002650: 22000000 00000000 E8121500 00000000 ".......è.......<br />
00002660: 01000000 73617665 30302E62 696E0000 ....save00.bin..<br />
00002670: 00000000 01000000 69921100 03000000 ........i’......<br />
00002680: DC140000 00000000 04000000 00000000 Ü...............<br />
</pre><br />
<br />
{| class="wikitable"<br />
|-<br />
! Start<br />
! Length<br />
! Description<br />
|-<br />
| 0x00<br />
| 4<br />
| Magic ("SAVE")<br />
|-<br />
| 0x04<br />
| 4<br />
| Magic Number (0x40000)<br />
|-<br />
| 0x08<br />
| 8<br />
| Offset to data in this SAVE header(normally 0x20)<br />
|-<br />
| 0x10<br />
| 8<br />
| Partition Size [medias]<br />
|-<br />
| 0x18<br />
| 4<br />
| Partition Media Size<br />
|-<br />
| 0x1C<br />
| 8<br />
| Unknown<br />
|-<br />
| 0x24<br />
| 4<br />
| Unknown<br />
|-<br />
| 0x28<br />
| 8<br />
| FolderMap Offset<br />
|-<br />
| 0x30<br />
| 4<br />
| FolderMap Size<br />
|-<br />
| 0x34<br />
| 4<br />
| FolderMap Media Size<br />
|-<br />
| 0x38<br />
| 8<br />
| FileMap Offset<br />
|-<br />
| 0x40<br />
| 4<br />
| FileMap Size<br />
|-<br />
| 0x44<br />
| 4<br />
| FileMap Media Size<br />
|-<br />
| 0x48<br />
| 8<br />
| BlockMap Offset<br />
|-<br />
| 0x50<br />
| 4<br />
| BlockMap Size<br />
|-<br />
| 0x54<br />
| 4<br />
| BlockMap Media Size<br />
|-<br />
| 0x58<br />
| 8<br />
| File store offset (from SAVE)<br />
|-<br />
| 0x60<br />
| 4<br />
| File store length [medias]<br />
|-<br />
| 0x64<br />
| 4<br />
| File store media size<br />
|-<br />
| 0x68<br />
| 4/8<br />
| Folders Table offset (8 bytes in DATA)<br />
|-<br />
| 0x6C<br />
| 4<br />
| Folders Table Length (medias) (Only in no DATA)<br />
|-<br />
| 0x70<br />
| 4<br />
| Folders Table unknown<br />
|-<br />
| 0x74<br />
| 4<br />
| Folders Table Media size<br />
|-<br />
| 0x78<br />
| 4/8<br />
| Files Table offset (8 bytes in DATA)<br />
|-<br />
| 0x7C<br />
| 4<br />
| Files Table Length (medias) (Only in no DATA)<br />
|-<br />
| 0x80<br />
| 4<br />
| Files Table unknown<br />
|-<br />
| 0x84<br />
| 4<br />
| Files Table Media size<br />
|-<br />
|}<br />
<br />
* The FolderMap and FileMap still unknown. They are tables of uint32.<br />
* The BlockMap is a map of the blocks in the filestore. An entry in the BlockMap is 2 uint32: {uint32 start_block; uint32 end_block; }. This is still being researched. (You can use [[3DSExplorer]] to see those maps.<br />
<br />
'''Summary Drawing'''<br />
<br />
[[File:Sfsave_drawing.png]]<br />
<br />
=== Initialization ===<br />
<br />
When a save FLASH contains all xFFFF blocks it's assumed uninitialized by the game cartridges and it initializes default data in place, without prompting the user. <br />
<br />
I got a new game SplinterCell3D-Pal and I downloaded the save and it was 128KB of 0xFF, except the first 0x10 bytes which were the letter 'Z' (uppercase) --[[User:Elisherer|Elisherer]] 22:41, 15 October 2011 (CEST)<br />
<br />
=== Fun Facts ===<br />
<br />
If you have facts that you found out by looking at the binary files please share them here:<br />
<br />
* From one save to another the game backups the last files that were in the partition and the entire image header in "random" locations.. --[[User:Elisherer|Elisherer]] 22:41, 15 October 2011 (CEST)<br />
<br />
[[セーブデータ|Japanese]]</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=SD%E5%8D%A1%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F&diff=2659SD卡文件系统2012-03-13T08:54:55Z<p>Straybirdsnest: /* title */</p>
<hr />
<div>3DS使用SD卡来储存附加的游戏数据、音乐以及用3DS拍摄的照片。<br />
<br />
/DCIM - 照片及因特网浏览器(Internet Browser)下载的图像。<br />
/Music - 音乐文件。<br />
/Nintendo 3DS - 游戏数据。<br />
<br />
/DCIM 在[[3.0.0-5]]版本中也存储.avi格式的3D视频,视频框架为MJPG。<br />
(with [[3.0.0-5]] also stores .avi 3D videos from the camera title, video frames use MJPG.)<br />
<br />
== Extdata ==<br />
附加的游戏数据储存在这里:<br />
: /Nintendo 3DS/<SomeID>/<SomeID>/extdata/00000000<br />
<br />
00000082 - eShop - JPN (Unconfirmed)<br />
0000008f - Some [[2.0.0-2]] data, unknown doesn't appear in extdata management.<br />
00000098 - eShop - EUR (Unconfirmed)<br />
00000207 - Mii Maker - JPN <br />
0000020d - Face Raiders - JPN<br />
00000210 - Some [[2.0.0-2]] data, unknown doesn't appear in extdata management.<br />
00000217 - Mii Maker - USA<br />
00000219 - eShop USA<br />
0000021d - Face Raiders - USA<br />
00000227 - Mii Maker - EUR<br />
0000022d - Face Raiders - EUR<br />
0000030c - Nintendogs + Cats - EUR<br />
00000326 - Pokédex 3D - EUR<br />
0000032d - Super Street Fighter IV 3D - USA<br />
0000033b - Ridge Racer 3D - EUR<br />
0000033c - Super Street Fighter IV 3D - EUR<br />
0000034d - Samurai Warriors Chronicles - USA<br />
00000358 - Ridge Racer 3D - USA<br />
0000038a - Dead or Alive Dimensions - EUR<br />
00000481 - Monster Hunter Tri G (Download-Quests) - JPN<br />
000004aa - Nintendo Video - USA<br />
000004ab - Nintendo Video - EUR<br />
<br />
所有[[extdata]]下的附加数据(extra data)都是加密的。尽管这些文件使用类似于闪存(FLASH)[[Savegames|存档]]的0xFF区块,附加数据却不能用对待闪存存档的异或操作来解密。所有附加数据文件都不能被拷贝到别的3DS的SD卡上,它们被锁在3DS本体上。(straybirdsnest注:保存了一台3DS附加数据的SD卡直接(或者拷贝到另外的SD卡后)插入到另外一台3DS上无法被识别,猜测原文是指这个。)<br />
<br />
(All "extra data" under [[extdata]] is encrypted. Although these files use 0xFF blocks similar to FLASH [[Savegames|saves]], extdata can't be decrypted with the xorpad fail like FLASH saves. All "extra data" files can't be copied to other 3DS SD cards, they are locked to the console.)<br />
<br />
== import.db 与 title.db ==<br />
6月更新后,文件夹结构有了细微变化。你会在 /Nintendo 3DS/<SomeID>/<SomeID>/ 的exetdata旁找到"dbs"和"title"文件夹。"dbs"文件夹包含两个文件:import.db和title.db——用途目前不明。import.db似乎包含来自DSiWare SRL的数据。<br />
<br />
文件数据的开头部分是加密的,但剩余部分是明文(cleartext)。这个文件总是3.1MB大小,因此它不包含大多数DSiWare的完整的SRL。里面的数据排列方式也与源SRL——ARM7代码,ARM9代码的排列顺序不同,它们混(mix)在一起。文件包含未安装的DSiWare数据,只在源DSi上被列出,用于DSiWare转移。(翻译待考证)<br />
<br />
(The data at the beginning of the file is encrypted, but the rest is cleartext. This file is always 3.1MB, thus this doesn't contain the whole SRL for most DSiWare. The data stored here is not ordered the same way as the src SRL: ARM7 code, ARM9 code, and data are mixed together. The file can contain data from DSiWare that wasn't installed, only listed on the src DSi for DSiWare transfer. (This file is likely some temporary data storage used for DSiWare install etc).)<br />
<br />
title.db似乎是加密的。<br />
<br />
* [https://gist.github.com/1113cbe10f124e5a2c72 新旧 import.db 与 title.db 异或后,泄露了某些明文(plaintext)].<br />
<br />
<br />
== title ==<br />
/title/00040000/ 包含 eshop 下载的数据 (有人能帮忙查证和加上地区吗?):<br />
00032600 - Pokedex 3D - EUR (verified)<br />
00042a00 - Legend of Zelda - Link's Awakening - EUR<br />
0004ab00 - Nintendo Video - EUR<br />
00052000 - Let's Golf 3D - EUR<br />
00054300 - 3D Classics Excitebike - USA<br />
00054e00 - 3D Classics Excitebike - EUR (verified)<br />
00054300 - 3D Classics Excitebike - USA<br />
00045C00 - 3D Classics Excitebike - JPN<br />
要查看更多的ID,请参阅[[Title_list]]上的00040000标题(title)。<br />
<br />
上面的游戏标题文件(title directories)包含两个目录: content 和 data 。content 包含 00000000.tmd、.app文件,某些cmd目录包含 00000001.cmd,所有这些文件都使用一个本体唯一的密钥(console-unique key)加密。data目录包含 00000001.sav,这是游戏标题(title)的加密游戏存档。尽管这些存档看起来很像闪存游戏存档,但是它们对文件内每个AES块使用了唯一的CTR,而CTR在每个游戏存档写入的时候又会改变。重命名这些游戏存档文件将引起主菜单在启动游戏(title)时挂起(hang),修改存档将像游戏卡带闪存存档一样抛出checksum/hash错误。<br />
<br />
(The above title directories contain two dirs: content and data. content contains 00000000.tmd, .app files, and some cmd dir containing 00000001.cmd, all of which are encrypted with a console-unique key. The data dir contains 00000001.sav, this is the title's encrypted savegame. Although these saves look similar to FLASH savegames, these savegames use proper unique CTR for each AES block in the file, and the CTR properly changes for each savegame write. Renaming these savegames causes home-menu to hang while launching titles, modifying saves throws the usual checksum/hash corruption like gamecard flash saves.)<br />
<br />
重命名content文件夹下任意文件或目录的时候,主菜单上的图标仍会被显示。修改这些文件与重命名有同样效果。重命名cmd文件夹下的cmd文件,或 00000000.app ,则3D标题会消失。重命名cmd目录或目录下的文件时,主菜单会拒绝运行游戏程序,说明书(译者注:即菜单里的软件说明书,3DSware和马里奥大陆3D这样的游戏会自带)将无法工作。(会显示“SD卡未插入”的黑屏)。重命名 00000001.app时,说明书将不会被载入,因此 .app 可能是说明书?主 00000000.app 二进制文件被重命名的时候,无法启动该游戏程序,并且显示说明书的地方将显示游戏程序的图标和标题。(译者注:这段按本人理解翻译,有兴趣的可以亲自试验一下,记得先备份SD卡内容)重命名tmp文件夹里面的文件将不会引起主菜单的任何改变。<br />
<br />
(When renaming ''any'' of these files/dir under content, the icon in home-menu is still displayed. Modifying any of these files has same result as renaming them. When renaming the cmd dir/cmd file, or 00000000.app, the 3D banner isn't displayed. When renaming the cmd dir or the file contained in that dir, home-menu will refuse to run the title, and the manual will not work.(will display the black screen saying sdcard isn't inserted) Manual won't load when 00000001.app is renamed, so that .app might be the manual? When the main 00000000.app binary is renamed, the title will not launch and in the manual placeholder text is used for the title name/icon. Home-menu doesn't care at all when tmd is renamed.)<br />
<br />
== Private ==<br />
"Private" 数据保存在这里:<br />
<br />
/Nintendo 3DS/Private/<Title ID Low>/<br />
<br />
00020400 - Nintendo 3DS Camera <br />
00020500 - Nintendo 3DS Sound<br />
<br />
<br />
3DS的Sound/Canera "Private"数据是明文(cleartext)。<br />
camera 私有目录下是 [[phtcache.bin]], 似乎是SD卡上图片的列表?<br />
当你想在3DS放入并能查看到新图片的时候,重命名为8位数字的.mpo并保存到/DCIM目录下。<br />
<br />
(When you want to install and see pictures with 3DS,rename to 8 numbers.mpo and save it on /DCIM .)<br />
<br />
Sound目录下是: voice/XX/*.m4a.XX为01-10,保存着名为 .m4a的声音文件。<br />
<br />
(Under the sound priv dir is: voice/XX/*.m4a. Where XX is 01-10, with sound saved as .m4a.)</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=User_talk:Straybirdsnest&diff=2658User talk:Straybirdsnest2012-03-13T08:40:26Z<p>Straybirdsnest: /* 欢迎,话说你是谁呢= = */</p>
<hr />
<div>== Welcome! ==<br />
<br />
Welcome to 3dbrew and thanks for your contributions a lot! And you also can use Wikilinks (like [[已知文件格式(CCI/CXI/CIA)]]) in summary box :-) --[[User:Wangxuan8331800|Wangxuan8331800]] 07:06, 12 March 2012 (CET)<br />
<br />
== 欢迎,话说你是谁呢= = ==<br />
哈哈,首先感谢了,我还以为就我和楼下这位在搞中文呢,不过你到底是谁呢?我没记得我把这个网址散布的多广啊= =麻烦能说一下是在哪里看到的吗?<br />
--[[User:黄金の轰龙|黄金の轰龙]] 13:38, 12 March 2012 (CET)<br />
<br />
: 表示在乃开始搞这个之前吾就知道这个地方了,在GBAtemp站得知的,至少是去年,偶尔看看这边的更新,木有想过搞中文化的动作。<br />
: 现在稍微做些东西,不过手头没有多余的资源,就顺便搞搞这个了。上次DOA相片导出的时候做过一些事,嘛……<br />
: 顺便请教下时间的设置方法,自动前面貌似木有效果呐……<br />
: --[[User:Straybirdsnest|Straybirdsnest]] 13:48, 12 March 2012 (CET)<br />
<br />
::嗯,您好→_→<br />
::我帮龙哥代答顺便排个版不介意吧……签名打时间的话用四个波浪线(<nowiki>~~~~</nowiki>) 就行了--[[User:Wangxuan8331800|Wangxuan8331800]] 14:47, 12 March 2012 (CET)<br />
<br />
:::高手啊,膜拜膜拜。<br />
:::签名的话维基编辑器上面是有的嘛~--[[User:黄金の轰龙|黄金の轰龙]] 05:51, 13 March 2012 (CET)<br />
::::表示这个编辑器用不大习惯,没用过,嘛……翻译得不是很好,不过老实说有技术的人都自己看的,翻译最多帮忙普及一下,呵呵呵。吾技术是渣渣就是了。--[[User:Straybirdsnest|Straybirdsnest]] 09:40, 13 March 2012 (CET)</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=User_talk:Straybirdsnest&diff=2646User talk:Straybirdsnest2012-03-12T12:48:04Z<p>Straybirdsnest: some talk about my translation, NOT important.</p>
<hr />
<div>== 欢迎,话说你是谁呢= = ==<br />
哈哈,首先感谢了,我还以为就我和楼下这位在搞中文呢,不过你到底是谁呢?我没记得我把这个网址散布的多广啊= =麻烦能说一下是在哪里看到的吗?<br />
--[[User:黄金の轰龙|黄金の轰龙]] 13:38, 12 March 2012 (CET)<br />
<br />
表示在乃开始搞这个之前吾就知道这个地方了,在GBAtemp站得知的,至少是去年,偶尔看看这边的更新,木有想过搞中文化的动作。<br />
现在稍微做些东西,不过手头没有多余的资源,就顺便搞搞这个了。上次DOA相片导出的时候做过一些事,嘛……<br />
顺便请教下时间的设置方法,自动前面貌似木有效果呐……<br />
--[[User:Straybirdsnest|Straybirdsnest]] 13:48, 12 March 2012 (CET)<br />
<br />
== Welcome! ==<br />
<br />
Welcome to 3dbrew and thanks for your contributions a lot! And you also can use Wikilinks (like [[已知文件格式(CCI/CXI/CIA)]]) in summary box :-) --[[User:Wangxuan8331800|Wangxuan8331800]] 07:06, 12 March 2012 (CET)</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=User_talk:Straybirdsnest&diff=2645User talk:Straybirdsnest2012-03-12T12:45:35Z<p>Straybirdsnest: /* 欢迎,话说你是谁呢= = */</p>
<hr />
<div>== 欢迎,话说你是谁呢= = ==<br />
哈哈,首先感谢了,我还以为就我和楼下这位在搞中文呢,不过你到底是谁呢?我没记得我把这个网址散布的多广啊= =麻烦能说一下是在哪里看到的吗?<br />
--[[User:黄金の轰龙|黄金の轰龙]] 13:38, 12 March 2012 (CET)<br />
<br />
表示在乃开始搞这个之前吾就知道这个地方了,在GBAtemp站得知的,至少是去年,偶尔看看这边的更新,木有想过搞中文化的动作。<br />
现在稍微做些东西,不过手头没有多余的资源,就顺便搞搞这个了。上次DOA相片导出的时候做过一些事,嘛……<br />
顺便请教下时间的设置方法,自动前面貌似木有效果呐……<br />
--[[User:Straybirdsnest|Straybirdsnest]]<br />
<br />
== Welcome! ==<br />
<br />
Welcome to 3dbrew and thanks for your contributions a lot! And you also can use Wikilinks (like [[已知文件格式(CCI/CXI/CIA)]]) in summary box :-) --[[User:Wangxuan8331800|Wangxuan8331800]] 07:06, 12 March 2012 (CET)</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=SD%E5%8D%A1%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F&diff=2643SD卡文件系统2012-03-12T12:14:14Z<p>Straybirdsnest: /* Private */</p>
<hr />
<div>3DS使用SD卡来储存附加的游戏数据、音乐以及用3DS拍摄的照片。<br />
<br />
/DCIM - 照片及因特网浏览器(Internet Browser)下载的图像。<br />
/Music - 音乐文件。<br />
/Nintendo 3DS - 游戏数据。<br />
<br />
/DCIM 在[[3.0.0-5]]版本中也存储.avi格式的3D视频,视频框架为MJPG。<br />
(with [[3.0.0-5]] also stores .avi 3D videos from the camera title, video frames use MJPG.)<br />
<br />
== Extdata ==<br />
附加的游戏数据储存在这里:<br />
: /Nintendo 3DS/<SomeID>/<SomeID>/extdata/00000000<br />
<br />
00000082 - eShop - JPN (Unconfirmed)<br />
0000008f - Some [[2.0.0-2]] data, unknown doesn't appear in extdata management.<br />
00000098 - eShop - EUR (Unconfirmed)<br />
00000207 - Mii Maker - JPN <br />
0000020d - Face Raiders - JPN<br />
00000210 - Some [[2.0.0-2]] data, unknown doesn't appear in extdata management.<br />
00000217 - Mii Maker - USA<br />
00000219 - eShop USA<br />
0000021d - Face Raiders - USA<br />
00000227 - Mii Maker - EUR<br />
0000022d - Face Raiders - EUR<br />
0000030c - Nintendogs + Cats - EUR<br />
00000326 - Pokédex 3D - EUR<br />
0000032d - Super Street Fighter IV 3D - USA<br />
0000033b - Ridge Racer 3D - EUR<br />
0000033c - Super Street Fighter IV 3D - EUR<br />
0000034d - Samurai Warriors Chronicles - USA<br />
00000358 - Ridge Racer 3D - USA<br />
0000038a - Dead or Alive Dimensions - EUR<br />
00000481 - Monster Hunter Tri G (Download-Quests) - JPN<br />
000004aa - Nintendo Video - USA<br />
000004ab - Nintendo Video - EUR<br />
<br />
所有[[extdata]]下的附加数据(extra data)都是加密的。尽管这些文件使用类似于闪存(FLASH)[[Savegames|存档]]的0xFF区块,附加数据却不能用对待闪存存档的异或操作来解密。所有附加数据文件都不能被拷贝到别的3DS的SD卡上,它们被锁在3DS本体上。(straybirdsnest注:保存了一台3DS附加数据的SD卡直接(或者拷贝到另外的SD卡后)插入到另外一台3DS上无法被识别,猜测原文是指这个。)<br />
<br />
(All "extra data" under [[extdata]] is encrypted. Although these files use 0xFF blocks similar to FLASH [[Savegames|saves]], extdata can't be decrypted with the xorpad fail like FLASH saves. All "extra data" files can't be copied to other 3DS SD cards, they are locked to the console.)<br />
<br />
== import.db 与 title.db ==<br />
6月更新后,文件夹结构有了细微变化。你会在 /Nintendo 3DS/<SomeID>/<SomeID>/ 的exetdata旁找到"dbs"和"title"文件夹。"dbs"文件夹包含两个文件:import.db和title.db——用途目前不明。import.db似乎包含来自DSiWare SRL的数据。<br />
<br />
文件数据的开头部分是加密的,但剩余部分是明文(cleartext)。这个文件总是3.1MB大小,因此它不包含大多数DSiWare的完整的SRL。里面的数据排列方式也与源SRL——ARM7代码,ARM9代码的排列顺序不同,它们混(mix)在一起。文件包含未安装的DSiWare数据,只在源DSi上被列出,用于DSiWare转移。(翻译待考证)<br />
<br />
(The data at the beginning of the file is encrypted, but the rest is cleartext. This file is always 3.1MB, thus this doesn't contain the whole SRL for most DSiWare. The data stored here is not ordered the same way as the src SRL: ARM7 code, ARM9 code, and data are mixed together. The file can contain data from DSiWare that wasn't installed, only listed on the src DSi for DSiWare transfer. (This file is likely some temporary data storage used for DSiWare install etc).)<br />
<br />
title.db似乎是加密的。<br />
<br />
* [https://gist.github.com/1113cbe10f124e5a2c72 新旧 import.db 与 title.db 异或后,泄露了某些明文(plaintext)].<br />
<br />
<br />
== title ==<br />
/title/00040000/ 包含 eshop 下载的数据 (有人能帮忙查证和加上地区吗?):<br />
00032600 - Pokedex 3D - EUR (verified)<br />
00042a00 - Legend of Zelda - Link's Awakening - EUR<br />
0004ab00 - Nintendo Video - EUR<br />
00052000 - Let's Golf 3D - EUR<br />
00054300 - 3D Classics Excitebike - USA<br />
00054e00 - 3D Classics Excitebike - EUR (verified)<br />
00054300 - 3D Classics Excitebike - USA<br />
00045C00 - 3D Classics Excitebike - JPN<br />
要查看更多的ID,请参阅[[Title_list]]上的00040000标题(title)。<br />
<br />
上面的游戏标题文件(title directories)包含两个目录: content 和 data 。content 包含 00000000.tmd、.app文件,某些cmd目录包含 00000001.cmd,所有这些文件都使用一个本体唯一的密钥(console-unique key)加密。data目录包含 00000001.sav,这是游戏标题(title)的加密游戏存档。尽管这些存档看起来很像闪存游戏存档,但是它们对文件内每个AES块使用了唯一的CTR,而CTR在每个游戏存档写入的时候又会改变。重命名这些游戏存档文件将引起主菜单在启动游戏(title)时挂起(hang),修改存档将像游戏卡带闪存存档一样抛出checksum/hash错误。<br />
<br />
(The above title directories contain two dirs: content and data. content contains 00000000.tmd, .app files, and some cmd dir containing 00000001.cmd, all of which are encrypted with a console-unique key. The data dir contains 00000001.sav, this is the title's encrypted savegame. Although these saves look similar to FLASH savegames, these savegames use proper unique CTR for each AES block in the file, and the CTR properly changes for each savegame write. Renaming these savegames causes home-menu to hang while launching titles, modifying saves throws the usual checksum/hash corruption like gamecard flash saves.)<br />
<br />
When renaming ''any'' of these files/dir under content, the icon in home-menu is still displayed. Modifying any of these files has same result as renaming them. When renaming the cmd dir/cmd file, or 00000000.app, the 3D banner isn't displayed. When renaming the cmd dir or the file contained in that dir, home-menu will refuse to run the title, and the manual will not work.(will display the black screen saying sdcard isn't inserted) Manual won't load when 00000001.app is renamed, so that .app might be the manual? When the main 00000000.app binary is renamed, the title will not launch and in the manual placeholder text is used for the title name/icon. Home-menu doesn't care at all when tmd is renamed.<br />
<br />
== Private ==<br />
"Private" 数据保存在这里:<br />
<br />
/Nintendo 3DS/Private/<Title ID Low>/<br />
<br />
00020400 - Nintendo 3DS Camera <br />
00020500 - Nintendo 3DS Sound<br />
<br />
<br />
3DS的Sound/Canera "Private"数据是明文(cleartext)。<br />
camera 私有目录下是 [[phtcache.bin]], 似乎是SD卡上图片的列表?<br />
当你想在3DS放入并能查看到新图片的时候,重命名为8位数字的.mpo并保存到/DCIM目录下。<br />
<br />
(When you want to install and see pictures with 3DS,rename to 8 numbers.mpo and save it on /DCIM .)<br />
<br />
Sound目录下是: voice/XX/*.m4a.XX为01-10,保存着名为 .m4a的声音文件。<br />
<br />
(Under the sound priv dir is: voice/XX/*.m4a. Where XX is 01-10, with sound saved as .m4a.)</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=SD%E5%8D%A1%E6%96%87%E4%BB%B6%E7%B3%BB%E7%BB%9F&diff=2642SD卡文件系统2012-03-12T12:06:49Z<p>Straybirdsnest: Translation for SD_Filesystem, NOT Complated.</p>
<hr />
<div>3DS使用SD卡来储存附加的游戏数据、音乐以及用3DS拍摄的照片。<br />
<br />
/DCIM - 照片及因特网浏览器(Internet Browser)下载的图像。<br />
/Music - 音乐文件。<br />
/Nintendo 3DS - 游戏数据。<br />
<br />
/DCIM 在[[3.0.0-5]]版本中也存储.avi格式的3D视频,视频框架为MJPG。<br />
(with [[3.0.0-5]] also stores .avi 3D videos from the camera title, video frames use MJPG.)<br />
<br />
== Extdata ==<br />
附加的游戏数据储存在这里:<br />
: /Nintendo 3DS/<SomeID>/<SomeID>/extdata/00000000<br />
<br />
00000082 - eShop - JPN (Unconfirmed)<br />
0000008f - Some [[2.0.0-2]] data, unknown doesn't appear in extdata management.<br />
00000098 - eShop - EUR (Unconfirmed)<br />
00000207 - Mii Maker - JPN <br />
0000020d - Face Raiders - JPN<br />
00000210 - Some [[2.0.0-2]] data, unknown doesn't appear in extdata management.<br />
00000217 - Mii Maker - USA<br />
00000219 - eShop USA<br />
0000021d - Face Raiders - USA<br />
00000227 - Mii Maker - EUR<br />
0000022d - Face Raiders - EUR<br />
0000030c - Nintendogs + Cats - EUR<br />
00000326 - Pokédex 3D - EUR<br />
0000032d - Super Street Fighter IV 3D - USA<br />
0000033b - Ridge Racer 3D - EUR<br />
0000033c - Super Street Fighter IV 3D - EUR<br />
0000034d - Samurai Warriors Chronicles - USA<br />
00000358 - Ridge Racer 3D - USA<br />
0000038a - Dead or Alive Dimensions - EUR<br />
00000481 - Monster Hunter Tri G (Download-Quests) - JPN<br />
000004aa - Nintendo Video - USA<br />
000004ab - Nintendo Video - EUR<br />
<br />
所有[[extdata]]下的附加数据(extra data)都是加密的。尽管这些文件使用类似于闪存(FLASH)[[Savegames|存档]]的0xFF区块,附加数据却不能用对待闪存存档的异或操作来解密。所有附加数据文件都不能被拷贝到别的3DS的SD卡上,它们被锁在3DS本体上。(straybirdsnest注:保存了一台3DS附加数据的SD卡直接(或者拷贝到另外的SD卡后)插入到另外一台3DS上无法被识别,猜测原文是指这个。)<br />
<br />
(All "extra data" under [[extdata]] is encrypted. Although these files use 0xFF blocks similar to FLASH [[Savegames|saves]], extdata can't be decrypted with the xorpad fail like FLASH saves. All "extra data" files can't be copied to other 3DS SD cards, they are locked to the console.)<br />
<br />
== import.db 与 title.db ==<br />
6月更新后,文件夹结构有了细微变化。你会在 /Nintendo 3DS/<SomeID>/<SomeID>/ 的exetdata旁找到"dbs"和"title"文件夹。"dbs"文件夹包含两个文件:import.db和title.db——用途目前不明。import.db似乎包含来自DSiWare SRL的数据。<br />
<br />
文件数据的开头部分是加密的,但剩余部分是明文(cleartext)。这个文件总是3.1MB大小,因此它不包含大多数DSiWare的完整的SRL。里面的数据排列方式也与源SRL——ARM7代码,ARM9代码的排列顺序不同,它们混(mix)在一起。文件包含未安装的DSiWare数据,只在源DSi上被列出,用于DSiWare转移。(翻译待考证)<br />
<br />
(The data at the beginning of the file is encrypted, but the rest is cleartext. This file is always 3.1MB, thus this doesn't contain the whole SRL for most DSiWare. The data stored here is not ordered the same way as the src SRL: ARM7 code, ARM9 code, and data are mixed together. The file can contain data from DSiWare that wasn't installed, only listed on the src DSi for DSiWare transfer. (This file is likely some temporary data storage used for DSiWare install etc).)<br />
<br />
title.db似乎是加密的。<br />
<br />
* [https://gist.github.com/1113cbe10f124e5a2c72 新旧 import.db 与 title.db 异或后,泄露了某些明文(plaintext)].<br />
<br />
<br />
== title ==<br />
/title/00040000/ 包含 eshop 下载的数据 (有人能帮忙查证和加上地区吗?):<br />
00032600 - Pokedex 3D - EUR (verified)<br />
00042a00 - Legend of Zelda - Link's Awakening - EUR<br />
0004ab00 - Nintendo Video - EUR<br />
00052000 - Let's Golf 3D - EUR<br />
00054300 - 3D Classics Excitebike - USA<br />
00054e00 - 3D Classics Excitebike - EUR (verified)<br />
00054300 - 3D Classics Excitebike - USA<br />
00045C00 - 3D Classics Excitebike - JPN<br />
要查看更多的ID,请参阅[[Title_list]]上的00040000标题(title)。<br />
<br />
上面的游戏标题文件(title directories)包含两个目录: content 和 data 。content 包含 00000000.tmd、.app文件,某些cmd目录包含 00000001.cmd,所有这些文件都使用一个本体唯一的密钥(console-unique key)加密。data目录包含 00000001.sav,这是游戏标题(title)的加密游戏存档。尽管这些存档看起来很像闪存游戏存档,但是它们对文件内每个AES块使用了唯一的CTR,而CTR在每个游戏存档写入的时候又会改变。重命名这些游戏存档文件将引起主菜单在启动游戏(title)时挂起(hang),修改存档将像游戏卡带闪存存档一样抛出checksum/hash错误。<br />
<br />
(The above title directories contain two dirs: content and data. content contains 00000000.tmd, .app files, and some cmd dir containing 00000001.cmd, all of which are encrypted with a console-unique key. The data dir contains 00000001.sav, this is the title's encrypted savegame. Although these saves look similar to FLASH savegames, these savegames use proper unique CTR for each AES block in the file, and the CTR properly changes for each savegame write. Renaming these savegames causes home-menu to hang while launching titles, modifying saves throws the usual checksum/hash corruption like gamecard flash saves.)<br />
<br />
When renaming ''any'' of these files/dir under content, the icon in home-menu is still displayed. Modifying any of these files has same result as renaming them. When renaming the cmd dir/cmd file, or 00000000.app, the 3D banner isn't displayed. When renaming the cmd dir or the file contained in that dir, home-menu will refuse to run the title, and the manual will not work.(will display the black screen saying sdcard isn't inserted) Manual won't load when 00000001.app is renamed, so that .app might be the manual? When the main 00000000.app binary is renamed, the title will not launch and in the manual placeholder text is used for the title name/icon. Home-menu doesn't care at all when tmd is renamed.<br />
<br />
== Private ==<br />
"Private" data is stored here:<br />
<br />
/Nintendo 3DS/Private/<Title ID Low>/<br />
<br />
00020400 - Nintendo 3DS Camera <br />
00020500 - Nintendo 3DS Sound<br />
<br />
<br />
"Private" data for 3DS Sound/Camera are cleartext.<br />
Under the camera priv dir is [[phtcache.bin]], this seems to list the pictures on SD card?<br />
When you want to install and see pictures with 3DS,rename to 8 numbers.mpo and save it on /DCIM .<br />
Under the sound priv dir is: voice/XX/*.m4a. Where XX is 01-10, with sound saved as .m4a.</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=User:Straybirdsnest&diff=2629User:Straybirdsnest2012-03-11T20:55:21Z<p>Straybirdsnest: </p>
<hr />
<div>== About Me ==<br />
<br />
I just come here to do some translations, if you want to connect me, please send an e-mail to straybirdsnest@gmail.com, thank you!<br />
<br />
{| class="wikitable" border="0" align="right"<br />
|-<br />
! zh-N<br />
| 此用户的母语是中文。<br />
|-<br />
! en-2 <br />
| This user has intermediate knowledge of English. <br />
|}<br />
<br />
== 关于本人 ==<br />
<br />
一名无聊的来自天朝的还能写点代码的不成熟3ds玩家,以上。</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=%E9%A6%96%E9%A1%B5/Navigation&diff=2628首页/Navigation2012-03-11T20:35:57Z<p>Straybirdsnest: Fix some links.</p>
<hr />
<div>{{Main page box|导航|首页/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%" | '''常规'''<br />
! width="34%" | '''N3DS硬件'''<br />
! width="33%" | '''N3DS软件'''<br />
|- valign="top" style="background: #F5FAFF;"<br />
| <br />
*[[3DS exploits|N3DS漏洞]]<br />
*[[术语表]]<br />
*[[FAQ/zh|FAQ]]<br />
*[[Friend code]]<br />
*[[游戏|游戏]]<br />
*[[Serials|序列号]]<br />
*[[:Category:PC utilities|PC工具]]<br />
|<br />
*[[Hardware|N3DS硬件配置]]<br />
*[[扩展右摇杆]]<br />
*[[游戏卡带]]<br />
|<br />
*[[Nintendo Software|自带任天堂软件]]<br />
*[[3DS Development Unit Software|N3DS开发机软体]]<br />
*[[已知文件格式]]([[CCI]]/[[CXI]]/[[CIA]])<br />
*[[Title list|已发售游戏列表]]<br />
*[[Title metadata|游戏元数据]]<br />
*[[SD Filesystem|SD卡文件系统]]<br />
*[[Flash Filesystem|闪存文件系统]]<br />
*[[引导程序]]<br />
*[[Savegames|游戏存档]]<br />
|}<br />
</div><br />
{{box-footer-empty}}</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=%E5%BC%95%E5%AF%BC%E7%A8%8B%E5%BA%8F&diff=2627引导程序2012-03-11T20:35:02Z<p>Straybirdsnest: Translation for Bootloader.</p>
<hr />
<div>当3DS找不到NAND芯片时,显示如下错误信息:<br />
<br />
[[Image:CTR_Bootrom_Error.jpg|500px]]<br />
<br />
3DS启动过程:<br />
<br />
* 0 Seconds - 部件上电,引导程序启动。<br />
<br />
* 2 Seconds - 引导程序尝试初始化NAND。如果NAND成功被初始化,它接管并引导3DS。如果NAND不能被初始化(例如NAND芯片未连接/已损坏,等等)。会出现像上面一样的蓝屏。<br />
<br />
* 3 Seconds - 全部必要硬件被激活——检测所有被连接上的硬件,如果solt1中是一张自动引导的卡带(比如kiosk demos),那么引导slot1硬件。在这个时间点,由于自动引导游戏像父级控制(parental control)和强制更新(forced updates)那样短路(by-pass)了 [[Home Menu|主菜单]] 安全措施,所以主菜单还没被初始化。同时,自动引导卡带也不会被记录为从 [[Home Menu|主菜单]]运行。如果未发现自动引导的slot1硬件,开始初始化 [[Home Menu|主菜单]]。自动引导卡带似乎不能短路区域锁(the region lock)。(如果不是demo区域,就产生"An Error has Occurred"信息。)<br />
(yields "An Error has Occurred" if out-of-region demo)<br />
<br />
* 4 Seconds - 初始化LCD屏幕。<br />
<br />
* 7 Seconds - [[Home Menu|主菜单]]被完全初始化/载入。</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=%E5%B7%B2%E7%9F%A5%E6%96%87%E4%BB%B6%E6%A0%BC%E5%BC%8F&diff=2626已知文件格式2012-03-11T20:05:02Z<p>Straybirdsnest: fix</p>
<hr />
<div>下面是已知的3DS所使用的文件格式列表。<br />
<br />
== 应用程序(任何可运行代码) ==<br />
<br />
.[[CCI]] - Cart image. 被烧入ROM(或被官方debug硬件载入)。包含实际的ROM dump格式,及对3DS与卡带之间读请求的响应。<br />
<br />
.[[CXI]] -可执行镜像。与上面相似,不同之处在于CXI程序被安装在NAND中,因此它们也从NAND中执行。<br />
<br />
.[[CIA]] - (CTR Importable Archive) 被编译进档案的应用程序,准备安装到设计好的位置。.CIA文件可被解压安装应用程序到CTR NAND,TWL NAND(部分被DSi应用程序使用的NAND)以及SD卡上。<br />
<br />
.[[CCI|CSU]] - 系统更新. 格式随(系统)版本呈多样化。<br />
<br />
.CFA - CTR File Archive - Externalized ROM-FS.CXI数据与ROMFS数据被分散到一个外部文件列表而不是被编译进单一的CXI镜像(通常不使用)。Lib表明这与CIA类似,有点像一个CIA档案。幸运的是,Lib含有这种格式的某些信息。CFA文件基本上被打包进CIA中。当CCI文件包含分布下载游戏(download play)子设备时,CFA才被使用。<br />
(CFAs are used when the CCI file includes the child device distributed with download play.)<br />
<br />
.NSA - 被3DS内多种通信协议使用的文档。<br />
<br />
.RSF - 输出CCI/CXI文件时的描述性数据。特定选项如:标题,存档格式,等等。<br />
<br />
.AXF - 汇编前的ARM代码(Pre-assembled ARM code). 链接成CCI/CXI前的格式。<br />
<br />
.CDI - CTR开发镜像(CTR Development Image).Lib不包含该格式的格式、用途等等的文档,我不得不挖穿编译器来找到这种格式。希望我很快能找到更多信息。*可能*与CTR调试器有关,不过这只是一个猜想。<br />
<br />
.CIP - CTR初始化进程(CTR Initial Process).不幸的是,情形很像CDI格式,不过因为它在Lib编译器当中,所以它是3DS使用的某种格式类型。<br />
<br />
.[[BCWAV]] - CTR音频文件格式(CTR waveform file format)。<br />
<br />
.[[CBMD]] - CTR二进制标题模型(CTR binary banner model).被做成CTR游戏标题(banner,或者乃给吾一个更好的翻译)或其他应用程序前的档案文件。<br />
<br />
=== 文件系统 ===<br />
<br />
3DS文件系统需要绝对路径。它能处理短(8.3)和长(255个字符)的文件名。<br />
<br />
== MPO格式(Multi-Picture Object Format) ==<br />
描述MPO文件格式的文档:<br />
http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-007_E.pdf<br />
<br />
[[MPO|任天堂的MPO标准]]</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=%E9%A6%96%E9%A1%B5/Navigation&diff=2625首页/Navigation2012-03-11T20:01:00Z<p>Straybirdsnest: </p>
<hr />
<div>{{Main page box|导航|首页/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%" | '''常规'''<br />
! width="34%" | '''N3DS硬件'''<br />
! width="33%" | '''N3DS软件'''<br />
|- valign="top" style="background: #F5FAFF;"<br />
| <br />
*[[3DS exploits|N3DS漏洞]]<br />
*[[术语表]]<br />
*[[FAQ/zh|FAQ]]<br />
*[[Friend code]]<br />
*[[游戏|游戏]]<br />
*[[Serials|序列号]]<br />
*[[:Category:PC utilities|PC工具]]<br />
|<br />
*[[Hardware|N3DS硬件配置]]<br />
*[[扩展右摇杆]]<br />
*[[游戏卡带]]<br />
|<br />
*[[Nintendo Software|自带任天堂软件]]<br />
*[[3DS Development Unit Software|N3DS开发机软体]]<br />
*[[已知文件格式]]([[CCI]]/[[CXI]]/[[CIA]])<br />
*[[Title list|已发售游戏列表]]<br />
*[[Title metadata|游戏元数据]]<br />
*[[SD Filesystem|SD卡文件系统]]<br />
*[[Flash Filesystem|闪存文件系统]]<br />
*[[Bootloader|引导程序]]<br />
*[[Savegames|游戏存档]]<br />
|}<br />
</div><br />
{{box-footer-empty}}</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=%E5%B7%B2%E7%9F%A5%E6%96%87%E4%BB%B6%E6%A0%BC%E5%BC%8F&diff=2624已知文件格式2012-03-11T20:00:41Z<p>Straybirdsnest: I’m sorry,please delete the other page - "http://www.3dbrew.org/w/index.php?title=已知文件格式(CCI/CXI/CIA)".</p>
<hr />
<div>下面是已知的3DS所使用的文件格式列表。<br />
<br />
== 应用程序(任何可运行代码) ==<br />
<br />
.[[CCI]] - Cart image. 被烧入ROM(或被官方debug硬件载入)。包含实际的ROM dump格式,及对3DS与卡带之间读请求的响应。<br />
<br />
.[[CXI]] -可执行镜像。与上面相似,不同之处在于CXI程序被安装在NAND中,因此它们也从NAND中执行。<br />
<br />
.[[CIA]] - (CTR Importable Archive) 被编译进档案的应用程序,准备安装到设计好的位置。.CIA文件可被解压安装应用程序到CTR NAND,TWL NAND(部分被DSi应用程序使用的NAND)以及SD卡上。<br />
<br />
.[[CCI|CSU]] - 系统更新. 格式随(系统)版本呈多样化。<br />
<br />
.CFA - CTR File Archive - Externalized ROM-FS.CXI数据与ROMFS数据被分散到一个外部文件列表而不是被编译进单一的CXI镜像(通常不使用)。Lib表明这与CIA类似,有点像一个CIA档案。幸运的是,Lib含有这种格式的某些信息。CFA文件基本上被打包进CIA中。当CCI文件包含分布下载游戏(download play)子设备时,CFA才被使用。<br />
(CFAs are used when the CCI file includes the child device distributed with download play.)<br />
<br />
.NSA - 被3DS内多种通信协议使用的文档。<br />
<br />
.RSF - 输出CCI/CXI文件时的描述性数据。特定选项如:标题,存档格式,等等。<br />
<br />
.AXF - 汇编前的ARM代码(Pre-assembled ARM code). 链接成CCI/CXI前的格式。<br />
<br />
.CDI - CTR开发镜像(CTR Development Image).Lib不包含该格式的格式、用途等等的文档,我不得不挖穿编译器来找到这种格式。希望我很快能找到更多信息。*可能*与CTR调试器有关,不过这只是一个猜想。<br />
<br />
.CIP - CTR初始化进程(CTR Initial Process).不幸的是,情形很像CDI格式,不过因为它在Lib编译器当中,所以它是3DS使用的某种格式类型。<br />
<br />
.[[BCWAV]] - CTR音频文件格式(CTR waveform file format)。<br />
<br />
.[[CBMD]] - CTR二进制标题模型(CTR binary banner model).被做成CTR游戏标题(banner,或者乃给吾一个更好的翻译)或其他应用程序前的档案文件。<br />
<br />
=== 文件系统 ===<br />
<br />
3DS文件系统需要绝对路径。它能处理短(8.3)和长(最长255字符)的文件名。<br />
<br />
== MPO格式(Multi-Picture Object Format) ==<br />
描述MPO文件格式的文档:<br />
http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-007_E.pdf<br />
<br />
[[MPO|任天堂的MPO标准]]</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=%E5%B7%B2%E7%9F%A5%E6%96%87%E4%BB%B6%E6%A0%BC%E5%BC%8F(CCI/CXI/CIA)&diff=2623已知文件格式(CCI/CXI/CIA)2012-03-11T19:56:41Z<p>Straybirdsnest: /* 应用程序 (任何可运行代码 ) */</p>
<hr />
<div>下面是已知的3DS所使用的文件格式列表。<br />
<br />
== 应用程序(任何可运行代码) ==<br />
<br />
.[[CCI]] - Cart image. 被烧入ROM(或被官方debug硬件载入)。包含实际的ROM dump格式,及对3DS与卡带之间读请求的响应。<br />
<br />
.[[CXI]] -可执行镜像。与上面相似,不同之处在于CXI程序被安装在NAND中,因此它们也从NAND中执行。<br />
<br />
.[[CIA]] - (CTR Importable Archive) 被编译进档案的应用程序,准备安装到设计好的位置。.CIA文件可被解压安装应用程序到CTR NAND,TWL NAND(部分被DSi应用程序使用的NAND)以及SD卡上。<br />
<br />
.[[CCI|CSU]] - 系统更新. 格式随(系统)版本呈多样化。<br />
<br />
.CFA - CTR File Archive - Externalized ROM-FS.CXI数据与ROMFS数据被分散到一个外部文件列表而不是被编译进单一的CXI镜像(通常不使用)。Lib表明这与CIA类似,有点像一个CIA档案。幸运的是,Lib含有这种格式的某些信息。CFA文件基本上被打包进CIA中。当CCI文件包含分布下载游戏(download play)子设备时,CFA才被使用。<br />
(CFAs are used when the CCI file includes the child device distributed with download play.)<br />
<br />
.NSA - 被3DS内多种通信协议使用的文档。<br />
<br />
.RSF - 输出CCI/CXI文件时的描述性数据。特定选项如:标题,存档格式,等等。<br />
<br />
.AXF - 汇编前的ARM代码(Pre-assembled ARM code). 链接成CCI/CXI前的格式。<br />
<br />
.CDI - CTR开发镜像(CTR Development Image).Lib不包含该格式的格式、用途等等的文档,我不得不挖穿编译器来找到这种格式。希望我很快能找到更多信息。*可能*与CTR调试器有关,不过这只是一个猜想。<br />
<br />
.CIP - CTR初始化进程(CTR Initial Process).不幸的是,情形很像CDI格式,不过因为它在Lib编译器当中,所以它是3DS使用的某种格式类型。<br />
<br />
.[[BCWAV]] - CTR音频文件格式(CTR waveform file format)。<br />
<br />
.[[CBMD]] - CTR二进制标题模型(CTR binary banner model).被做成CTR游戏标题(banner,或者乃给吾一个更好的翻译)或其他应用程序前的档案文件。<br />
<br />
=== 文件系统 ===<br />
<br />
3DS文件系统需要绝对路径。它能处理短(8.3)和长(最长255字符)的文件名。<br />
<br />
== MPO格式(Multi-Picture Object Format) ==<br />
描述MPO文件格式的文档:<br />
http://www.cipa.jp/english/hyoujunka/kikaku/pdf/DC-007_E.pdf<br />
<br />
[[MPO|任天堂的MPO标准]]</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=User:Straybirdsnest&diff=2622User:Straybirdsnest2012-03-11T19:32:38Z<p>Straybirdsnest: Created page with "== About Me == I just come here to do some translations, if you want to connect me, please send an e-mail to straybirdsnest@gmail.com, thank you! == 关于本人 == 一名无..."</p>
<hr />
<div>== About Me ==<br />
<br />
I just come here to do some translations, if you want to connect me, please send an e-mail to straybirdsnest@gmail.com, thank you!<br />
<br />
<br />
== 关于本人 ==<br />
<br />
一名无聊的来自天朝的还能写点代码的不成熟3ds玩家,以上。</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=%E5%B7%B2%E7%9F%A5%E6%96%87%E4%BB%B6%E6%A0%BC%E5%BC%8F(CCI/CXI/CIA)&diff=2621已知文件格式(CCI/CXI/CIA)2012-03-11T19:25:38Z<p>Straybirdsnest: Translated from Category:File formats, NOT complated.</p>
<hr />
<div>下面是已知的3DS所使用的文件格式列表。<br />
<br />
== 应用程序 (任何可运行代码 ) ==<br />
<br />
.[[CCI]] - Cart image. 被烧入ROM(或被官方debug硬件载入)。包含实际的ROM dump格式,及对3DS与卡带之间读请求的响应。<br />
<br />
.[[CXI]] -可执行镜像。与上面相似,不同之处在于CXI程序被安装在NAND中,因此它们也从NAND中执行。<br />
<br />
.[[CIA]] - (CTR Importable Archive) 被编译进档案的应用程序,准备安装到设计好的位置。.CIA文件可被解压安装应用程序到CTR NAND,TWL NAND(部分被DSi应用程序使用的NAND)以及SD卡上。<br />
<br />
.[[CCI|CSU]] - 系统更新. 格式随(系统)版本呈多样化。<br />
<br />
.CFA - CTR File Archive - Externalized ROM-FS.CXI数据与ROMFS数据被分散到一个外部文件列表而不是被编译进单一的CXI镜像(通常不使用)。Lib表明这与CIA类似,有点像一个CIA档案。幸运的是,Lib含有这种格式的某些信息。CFA文件基本上被打包进CIA中。当CCI文件包含分布下载游戏(download play)子设备时,CFA才被使用。<br />
(CFAs are used when the CCI file includes the child device distributed with download play.)</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=%E9%A6%96%E9%A1%B5/Navigation&diff=2620首页/Navigation2012-03-11T18:48:16Z<p>Straybirdsnest: edit some links.</p>
<hr />
<div>{{Main page box|导航|首页/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%" | '''常规'''<br />
! width="34%" | '''N3DS硬件'''<br />
! width="33%" | '''N3DS软件'''<br />
|- valign="top" style="background: #F5FAFF;"<br />
| <br />
*[[3DS exploits|N3DS漏洞]]<br />
*[[术语表]]<br />
*[[FAQ/zh|FAQ]]<br />
*[[Friend code]]<br />
*[[游戏|游戏]]<br />
*[[Serials|序列号]]<br />
*[[:Category:PC utilities|PC工具]]<br />
|<br />
*[[Hardware|N3DS硬件配置]]<br />
*[[扩展右摇杆]]<br />
*[[游戏卡带]]<br />
|<br />
*[[Nintendo Software|自带任天堂软件]]<br />
*[[3DS Development Unit Software|N3DS开发机软体]]<br />
*[[:Category:File_formats|已知文件格式]] ([[CCI]]/[[CXI]]/[[CIA]])<br />
*[[Title list|已发售游戏列表]]<br />
*[[Title metadata|游戏元数据]]<br />
*[[SD Filesystem|SD卡文件系统]]<br />
*[[Flash Filesystem|闪存文件系统]]<br />
*[[Bootloader|引导程序]]<br />
*[[Savegames|游戏存档]]<br />
|}<br />
</div><br />
{{box-footer-empty}}</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=%E6%B8%B8%E6%88%8F%E5%8D%A1%E5%B8%A6&diff=2619游戏卡带2012-03-11T18:37:40Z<p>Straybirdsnest: continue to translate.</p>
<hr />
<div>[[File:Gamecard.jpg|thumb|right|A 3DS gamecard]] <br />
[[File:GamecardPhy.jpg|thumb|right|Close-up of PCB]] <br />
<br />
== 物理接口 ==<br />
3ds游戏卡带拥有与通常DS或DSi一样的物理接口。它们的区别只有塑料卡壳右上角的一个装饰槽,它能阻止卡带插入到旧的Nintendo DS或DSi系统中。<br />
<br />
当去除装饰槽以使卡带适于插入DS或DSi系统中时,它们拒绝检测卡带,并无法显示标题图标。<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! 引脚<br />
! 名称<br />
! 描述<br />
|-<br />
| 1<br />
| GND<br />
| 接地。<br />
|-<br />
| 2<br />
| CLK<br />
| 时钟信号。DS/DSi游戏卡带频率分别为6.7MHz和4.2MHz,3DS游戏卡带上升到16.6MHz(用于SPI和ROM传输)。<br />
|-<br />
| 3<br />
| NC<br />
| 未连接。可能用于编程卡(program card?翻译待查证)。<br />
|-<br />
| 4<br />
| RCS<br />
| ROM选择,低电平有效。送低电平开始传输ROM。<br />
|-<br />
| 5<br />
| RST<br />
| 重置信号。低电平有效。 <br />
|-<br />
| 6<br />
| ECS<br />
| 存游戏芯片(Savegame chip)选择,低电平有效。送低电平开始存游戏SPI传输(savegame SPI transfer)。<br />
|-<br />
| 7<br />
| IRQ<br />
| 移除检测。<br />
|-<br />
| 8<br />
| VCC<br />
| 提供3.3V电压。<br />
|-<br />
| 9<br />
| DAT0<br />
| 双向数据总线。<br />
|-<br />
| 10<br />
| DAT1<br />
| 双向数据总线。<br />
|-<br />
| 11<br />
| DAT2<br />
| 双向数据总线。<br />
|-<br />
| 12<br />
| DAT3<br />
| 双向数据总线。<br />
|-<br />
| 13<br />
| DAT4<br />
| 双向数据总线 /存游戏芯片上的NC/SIO3引脚。<br />
|-<br />
| 14<br />
| DAT5<br />
| 双向数据总线 /存游戏芯片上的WP#/SIO2引脚。<br />
|-<br />
| 15<br />
| DAT6<br />
| 双向数据总线 /存游戏芯片上的SO/SIO1引脚。<br />
|-<br />
| 16<br />
| DAT7<br />
| 双向数据总线 /存游戏芯片上的SI/SIO0引脚。<br />
|-<br />
| 17<br />
| GND<br />
| 接地。<br />
|}<br />
<br />
<br />
== SPI闪存 ==<br />
目前为止,只有存游戏闪存芯片(savegame FLASH chip)被识别了。这块芯片被识别为0xC22211。JEDEC制造ID为Macronix,此外芯片标签为25L1001,与 MX25L1021E相符。<br />
数据表位于:http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/3F21BAC2E121E17848257639003A3146/$File/MX25L1021E,%203V,%201Mb,%20v0.01.pdf 。不论如何,MX25L1021E不支持3DS用于与SPI闪存(SPI flash)交换数据的4位宽传输。因此,这可能是一块定制闪存芯片。<br />
<br />
== 格式 ==<br />
Cartridge及系统更新存放在为此预留的区块内。<br />
在ROM里,能找到小于1GB的CART_SIZE_MAX-( 0x280000*(CART_SIZE_MAX/CART_SIZE_128MB) )-0x2000000的更新区块。该区块为0x2000000字节。<br />
<br />
== 通信协议 ==<br />
与DS和DSi游戏卡带相比,3DS系统与3DS游戏卡带的通信协议几乎完全改变了。<br />
<br />
在第6个传输以后,命令从8字节变为16字节。可能使用了新的加密手段,比如AES CTR。<br />
使用16字节命令后,数据总线维护0x00直到卡带返回表示准备好的单字节数据0x01,接着是实际数据。每0x200字节块实际数据后,是4字节的(未加密的)该字节块的标准CRC32码。<br />
<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 />
When 16-byte commands are used, the data bus maintains the value 0x00 until the card signals it is ready by clocking a single byte 0x01, followed by the actual data. After each 0x200-byte block of actual data, a 4-byte standard CRC32 of the block data (before encryption) follows.<br />
)<br />
<br />
下面是3DS发送给3DS游戏卡带的一组游戏卡带命令样本:<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 />
! 大小<br />
! 命令<br />
! 解码命令<br />
! 描述<br />
|-<br />
|<tt>2000</tt><br />
|<tt>9F00000000000000</tt><br />
|<br />
|Reset<br />
|-<br />
|<tt>0000</tt><br />
|<tt>71C93FE9BB0A3B18</tt><br />
|<br />
|Unknown<br />
|-<br />
|<tt>0004</tt><br />
|<tt>9000000000000000</tt><br />
|<br />
|Get gamecard ID, response=9000FEC2<br />
|-<br />
|<tt>0004</tt><br />
|<tt>9000000000000000</tt><br />
|<br />
| Get gamecard ID, response=9000FEC2<br />
|-<br />
|<tt>0004</tt><br />
|<tt>A000000000000000</tt><br />
|<br />
| Unknown, response=00000000<br />
|-<br />
|<tt>0000</tt><br />
|<tt>3E00000000000000</tt><br />
| <br />
| Enter 16-byte command mode.<br />
|-<br />
|<tt>0200</tt><br />
|<tt>82000000000000000000000000000000</tt><br />
| <br />
| Get header<br />
|-<br />
|<tt>0000</tt><br />
|<tt>F32C92D85C9D44DED3E0E41DBE7C90D9</tt><br />
|<tt>8300000000000000708DF1A731717D0B</tt> <br />
| Seed<br />
|-<br />
|<tt>0004</tt><br />
|<tt>696B9D8582FB55D31B68CAFE70C74A95</tt><br />
|<tt>A200000000000000708DF1A731717D0B</tt><br />
| Get secured gamecard ID, response=9000FEC2<br />
|-<br />
|<tt>0004</tt><br />
|<tt>BAA4812CA0AC9C5D19399530E3ACCCAB</tt><br />
|<tt>A300000000000000708DF1A731717D0B</tt><br />
| Unknown<br />
|-<br />
|<tt>0000</tt><br />
|<tt>178E427C22D87ADB86387249A97D321A</tt><br />
|<tt>C500000000000000708DF1A731717D0B</tt><br />
| Unknown<br />
|-<br />
|<tt>0004</tt><br />
|<tt>E06019B1BD5C9130ED6A4D9F4A9E7193</tt><br />
|<tt>A200000000000000708DF1A731717D0B</tt><br />
| Get secured gamecard ID, response=9000FEC2<br />
|-<br />
|<tt>0004</tt><br />
|<tt>4E0D224862523BBFE2E6255F80E15F37</tt><br />
|<tt>A200000000000000708DF1A731717D0B</tt><br />
| Get secured gamecard ID, response=9000FEC2<br />
|-<br />
|<tt>0004</tt><br />
|<tt>4CDF93D319FB62D0DB632A45E3E8D84C</tt><br />
|<tt>A200000000000000708DF1A731717D0B</tt><br />
| Get secured gamecard ID, response=9000FEC2<br />
|-<br />
|<tt>0004</tt><br />
|<tt>9AA5D80551002F955546D296A57F0FEF</tt><br />
|<tt>A200000000000000708DF1A731717D0B</tt><br />
| Get secured gamecard ID, response=9000FEC2<br />
|-<br />
|<tt>0004</tt><br />
|<tt>C12BA81AEF30DDDBD93FAD5D544C6334</tt><br />
|<tt>A200000000000000708DF1A731717D0B</tt><br />
| Get secured gamecard ID, response=9000FEC2<br />
|-<br />
|<tt>0200</tt><br />
|<tt>62EC5FB7F420AE1DC6253AE18AFA5BB3</tt><br />
|<tt>BF000000000000000000000000000000</tt><br />
| Read address 0<br />
|-<br />
|<tt>0200</tt><br />
|<tt>E3FA23AA016BE0C93430D1F42FF41324</tt><br />
|<tt>BF000000000040000000000000000000</tt><br />
| Read address 0x4000<br />
|}<br />
<br />
头部命令有一些无用的初始字节,最后返回一个0x200字节的头部。下面是乐高星球大战3( Lego Starwars 3)的样本:<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>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=%E6%B8%B8%E6%88%8F%E5%8D%A1%E5%B8%A6&diff=2618游戏卡带2012-03-11T17:50:25Z<p>Straybirdsnest: Translated from Gamecards,Not NOT complated.</p>
<hr />
<div>[[File:Gamecard.jpg|thumb|right|A 3DS gamecard]] <br />
[[File:GamecardPhy.jpg|thumb|right|Close-up of PCB]] <br />
<br />
== 物理接口 ==<br />
3ds游戏卡带拥有与通常DS或DSi一样的物理接口。它们的区别只有塑料卡壳右上角的一个装饰槽,它能阻止卡带插入到旧的Nintendo DS或DSi系统中。<br />
<br />
当去除装饰槽以使卡带适于插入DS或DSi系统中时,它们拒绝检测卡带,并无法显示标题图标。<br />
<br />
{| class="wikitable" border="1"<br />
|-<br />
! 引脚<br />
! 名称<br />
! 描述<br />
|-<br />
| 1<br />
| GND<br />
| 接地。<br />
|-<br />
| 2<br />
| CLK<br />
| 时钟信号。DS/DSi游戏卡带频率分别为6.7MHz和4.2MHz,3DS游戏卡带上升到16.6MHz(用于SPI和ROM传输)。<br />
|-<br />
| 3<br />
| NC<br />
| 未连接。可能用于编程卡(program card?翻译待查证)。<br />
|-<br />
| 4<br />
| RCS<br />
| ROM选择,低电平有效。送低电平开始传输ROM。<br />
|-<br />
| 5<br />
| RST<br />
| 重置信号。低电平有效。 <br />
|-<br />
| 6<br />
| ECS<br />
| 存游戏芯片(Savegame chip)选择,低电平有效。送低电平开始存游戏SPI传输(savegame SPI transfer)。<br />
|-<br />
| 7<br />
| IRQ<br />
| 移除检测。<br />
|-<br />
| 8<br />
| VCC<br />
| 提供3.3V电压。<br />
|-<br />
| 9<br />
| DAT0<br />
| 双向数据总线。<br />
|-<br />
| 10<br />
| DAT1<br />
| 双向数据总线。<br />
|-<br />
| 11<br />
| DAT2<br />
| 双向数据总线。<br />
|-<br />
| 12<br />
| DAT3<br />
| 双向数据总线。<br />
|-<br />
| 13<br />
| DAT4<br />
| 双向数据总线 /存游戏芯片未上的NC/SIO3引脚。<br />
|-<br />
| 14<br />
| DAT5<br />
| 双向数据总线 /存游戏芯片未上的WP#/SIO2引脚。<br />
|-<br />
| 15<br />
| DAT6<br />
| 双向数据总线 /存游戏芯片未上的SO/SIO1引脚。<br />
|-<br />
| 16<br />
| DAT7<br />
| 双向数据总线 /存游戏芯片未上的SI/SIO0引脚。<br />
|-<br />
| 17<br />
| GND<br />
| 接地。<br />
|}</div>Straybirdsnesthttps://www.3dbrew.org/w/index.php?title=%E6%89%A9%E5%B1%95%E5%8F%B3%E6%91%87%E6%9D%86&diff=2617扩展右摇杆2012-03-11T17:14:00Z<p>Straybirdsnest: Translated from Circle Pad Pro, I'm learning using wiki editing tools.</p>
<hr />
<div>也作为CTR-009为人所知,它通过背部的IR接口向本体发送命令。<br />
<br />
[http://what-games.golog.jp/archives/1350330.html 内部结构图片].<br />
<br />
<br />
== 使用说明 ==<br />
<br />
<br />
[[File:Circle pad pro instructions.jpg]]</div>Straybirdsnest