游戏存档: Difference between revisions
No edit summary |
translate eng.ver www.3dbrew.org/w/index.php?title=Savegames&oldid=7872 |
||
Line 9: | Line 9: | ||
那么怎么在3DS上运用这种解密方法呢?首先,将游戏存档切成以512字节为单位长度的片段,然后将除了只包含FF以外的片段以二进制方式查看。现在寻找最常见的公共片段,那就是你的关键字序列。现在用你原始的游戏存档和这些关键字序列进行异或操作,你将得到一个完全解密的游戏存档。对关键字序列进行异或操作以产生加密的游戏存档。(译者注:异或运算的一个重要性质是,a^b^b=a;即使用同样的关键字b对a进行两次异或将得到a本身,所以使用关键字序列对加密的游戏存档异或会得到明文,再异或一次又得到加密的存档。) | 那么怎么在3DS上运用这种解密方法呢?首先,将游戏存档切成以512字节为单位长度的片段,然后将除了只包含FF以外的片段以二进制方式查看。现在寻找最常见的公共片段,那就是你的关键字序列。现在用你原始的游戏存档和这些关键字序列进行异或操作,你将得到一个完全解密的游戏存档。对关键字序列进行异或操作以产生加密的游戏存档。(译者注:异或运算的一个重要性质是,a^b^b=a;即使用同样的关键字b对a进行两次异或将得到a本身,所以使用关键字序列对加密的游戏存档异或会得到明文,再异或一次又得到加密的存档。) | ||
==== Savegame keyY ==== | |||
[[ | 所有的游戏卡和SD卡存储的游戏都是用AES-CTR加密的. The base CTR for gamecard savegames is all-zero. The gamecard savegame [[AES|keyslot]] keyY is unique for every region of each game. The [[NCSD]] partition flags determine the method used to generate this keyY. When the save [[NCSD]] flags checked by the running NATIVE_FIRM are all-zero, the system will use the repeating CTR, otherwise a proper CTR which never repeats within the image is used. When all of the flags checked by the running NATIVE_FIRM are clear, the keyY is a 8-byte block decrypted from the main [[NCCH#CXI|CXI]] + two u32 IDs read from gamecard commands. | ||
===== Hashed keyY and [[2.2.0-4]] Savegame Encryption ===== | |||
[[NCSD]] partition的特定标志位被置位时,用CXI数据hash计算一个 SHA-256 (same data used with the original plain keyY), and the 0x40-bytes read from a gamecard command(this 0x40-byte data is also read by [[Process_Services_PXI|GetRomId]]). hash的前0x10-byte用做keyY。当标志位[7]被置位时,CTR不再使用原先的CTR方式使用,在存档镜像中不会使用重复数据。[[2.2.0-4]] 升级后,所有零售版有NCSD的游戏image都被发现在使用这种加密方式。 (含[[2.2.0-4]]以上的[[System Update CFA|System update partition]]), . | |||
' | This keyY generation method was implemented with [[2.0.0-2]] via NCSD partition flag[3], however the proper CTR wasn't implemented for flag[7] until [[2.2.0-4]]. The hashed keyY flag[3] implemented with [[2.0.0-2]] was likely never used with retail gamecards. | ||
===== [[6.0.0-11]] Savegame keyY ===== | |||
[[6.0.0-11]] implemented support for generating the savegame keyY with a new method, this method is much more complex than previous keyY methods. This is enabled via new [[NCSD]] partition flags, all retail games which have the NCSD image finalized after the [[6.0.0-11]] release(and [[6.0.0-11]]+ in the system update partition) will have these flags set for using this new method. | |||
A SHA-256 hash is calculated over the data used with the above hashed keyY method, other data is hashed here as well. An [[AES]] MAC is then calculated over this hash, the output MAC is used for the savegame keyY. | |||
The keyY used for calculating this AES MAC is initialized while NATIVE_FIRM is loading, this keyY is generated via the [[RSA]] engine. The RSA slot used here is slot0(key-data for slot0 is initialized by bootrom), this RSA slot0 key-data is overwritten once the system boots any [[NCCH#CXI|CXIs]] from NAND like [[NS]]. | |||
=== Wear leveling === | === Wear leveling === | ||
3DS在游戏存档闪存芯片上引入了wear leveling 方案。这是通过使用blockmap和journal来实现的。blockmap在闪存上偏移量为0,其后是journal。初始状态由blockmap指定,然后journal对其进行应用。 | 3DS在游戏存档闪存芯片上引入了wear leveling 方案。这是通过使用blockmap和journal来实现的。blockmap在闪存上偏移量为0,其后是journal。初始状态由blockmap指定,然后journal对其进行应用。 | ||
Line 317: | Line 319: | ||
* This is the [[extdata]] equivalent of DISA, for extdata which use FS. DIFF is only used for extdata. | * This is the [[extdata]] equivalent of DISA, for extdata which use FS. DIFF is only used for extdata. | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
Line 347: | Line 347: | ||
| 0x20 | | 0x20 | ||
| 8 | | 8 | ||
| | | File Base Offset | ||
|- | |- | ||
| 0x28 | | 0x28 | ||
Line 355: | Line 355: | ||
| 0x30 | | 0x30 | ||
| 4 | | 4 | ||
| | | Active Partition Table (0 = Primary, 1 = Secondary) | ||
|- | |- | ||
| 0x34 | | 0x34 | ||
| 0x20 | | 0x20 | ||
| Hash of the | | Hash of the Active Partition Table | ||
|- | |- | ||
| 0x54 | | 0x54 |