3dbrew

游戏存档: Difference between revisions

← Older editNewer edit →
T (talk | contribs)
155 edits
No edit summary
Line 1: Line 1:
本页面描述了3DS游戏卡带（3DS game cartridges/gamecards）中以及别的地方发现的游戏存档格式，加密方法等等内容。你可以在[[Games|游戏]]页面找到多种游戏的存档。
本页面描述了 3DS游戏卡, SD/NAND,SD/NAND [[extdata]] 中以及别的地方发现的游戏存档格式，加密方法等等内容。你可以在[[Games|游戏]]页面找到多种游戏的存档。


=== 加密手段 ===
=== 加密手段 ===


3DS上的游戏存档与DS的很像，都储存在游戏卡带的一块闪存芯片(FLASH chip)上。DS上这些游戏存档以明文的方式保存，但在3DS上则加了一层加密手段。正如对目录包含的游戏存档中的某些部分使用异或操作后显示出明文的奇怪行为所展示的那样，这很像是一种序列密码法( streamcipher)。
3DS上的游戏存档与DS的很像，都储存在游戏卡带的一块闪存芯片(FLASH chip)上。DS上这些游戏存档以明文的方式保存，3DS加了一层加密。通过对一些游戏存档的内容进行异或操作,显示出一些明文,看起来存档的加密方式应该是AES-CTR.
 
(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.）


这样猜测的理由在于序列密码法曾有一段时间使用512字节（作为单位来加密），即是说，在超过512字节之后，这种加密方法将重复某些关键字序列(keystream)。序列密码法加密的方法是，使用关键字序列对待加密数据进行异或操作，（得到的便是加密数据）。不幸的是，假如你使用重复的关键字序列加密某些已知的明文（在我们的场合里，是数据0），那么你基本上在泄漏你宝贵的关键字序列。（译者注:在位(Bit)级别上进行异或运算时，1^0=1,0^0=0，这里符号"^"表示异或，所以一个数据和0进行异或时会得到它本身。）
这样猜测的理由在于序列密码法曾有一段时间使用512字节（作为单位来加密），即是说，在超过512字节之后，这种加密方法将重复某些关键字序列(keystream)。序列密码法加密的方法是，使用关键字序列对待加密数据进行异或操作，（得到的便是加密数据）。不幸的是，假如你使用重复的关键字序列加密某些已知的明文（在我们的场合里，是数据0），那么你基本上在泄漏你宝贵的关键字序列。（译者注:在位(Bit)级别上进行异或运算时，1^0=1,0^0=0，这里符号"^"表示异或，所以一个数据和0进行异或时会得到它本身。）
(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.)


那么怎么在3DS上运用这种解密方法呢？首先，将游戏存档切成以512字节为单位长度的片段，然后将除了只包含FF以外的片段以二进制方式查看。现在寻找最常见的公共片段，那就是你的关键字序列。现在用你原始的游戏存档和这些关键字序列进行异或操作，你将得到一个完全解密的游戏存档。对关键字序列进行异或操作以产生加密的游戏存档。（译者注:异或运算的一个重要性质是,a^b^b=a;即使用同样的关键字b对a进行两次异或将得到a本身，所以使用关键字序列对加密的游戏存档异或会得到明文，再异或一次又得到加密的存档。）
那么怎么在3DS上运用这种解密方法呢？首先，将游戏存档切成以512字节为单位长度的片段，然后将除了只包含FF以外的片段以二进制方式查看。现在寻找最常见的公共片段，那就是你的关键字序列。现在用你原始的游戏存档和这些关键字序列进行异或操作，你将得到一个完全解密的游戏存档。对关键字序列进行异或操作以产生加密的游戏存档。（译者注:异或运算的一个重要性质是,a^b^b=a;即使用同样的关键字b对a进行两次异或将得到a本身，所以使用关键字序列对加密的游戏存档异或会得到明文，再异或一次又得到加密的存档。）


(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.)
所有的游戏卡和SD卡存储的游戏都是用AES-CTR加密的. The gamecard savegame [[AES|keyslot]] keyY is unique for every region of each game. A flag stored in the [[NCSD]] determines the method used to generate this keyY. This same flag is also used for determining which CTR method is used as well. The keyY when the flag is clear is generated from data stored in the main [[NCCH#CXI|CXI]], and data retrieved from gamecard commands. When the flag is set, a hash is generated for the keyY over the data from the CXI, and an ID retrieved from a gamecard command. The base CTR for gamecard savegames is all-zero. SD savegames use a CTR where the base CTR is fixed per savegame, however the CTR doesn't repeat in the image.
 
更新:


系统版本[[2.0.0-4]]中，使用了不同的CTR方式，修正了上述缺陷。异或操作似乎是在文件中重复进行，但不再以0x200字节为单位。目前还不知道如何解密这种新的存档文件。
[[2.0.0-4]](以及之后)的系统中,可以使用不同的游戏卡CTR方式，修正了上述缺陷。在 [[2.2.0-4]] 中,系统检查[[NCSD]]标志.如果被置位,使用新的CRT方式,否则就使用0x200-byte CRT.发布 [[2.2.0-4]]之后的所有游戏[[NCSD]]都被置位了,CRT不再在image中重复.




Retrieved from "https://www.3dbrew.org/wiki/游戏存档"