Changes

Jump to navigation Jump to search
238 bytes removed ,  22:47, 21 July 2012
no edit summary
Line 1: Line 1: −
This page describes the format, encryption, etc. of savegames stored in 3DS game cartridges/gamecards and SD/NAND. You can find savegames from various 3DS games on the [[Games]] page.
+
This page describes the format and encryption of savegames stored in 3DS game cartridges/gamecards and SD/NAND. You can find savegames from various 3DS games on the [[Games]] page.
       
=== Gamecard Savegame Encryption ===
 
=== Gamecard Savegame Encryption ===
   −
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.
+
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 AES-CTR, 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.
    
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.
 
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.
Line 10: Line 10:  
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.
 
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.
   −
All savegames, including non-gamecard savegames, are encrypted with AES-CTR. The base CTR never changes after savegame creation. The CTR used for gamecard savegames eventually repeats, while non-gamecard savegames don't use a repeating CTR. For the old gamecard CTR method, it repeated every 0x200-bytes. With the new method it repeats at least every 0x1000-bytes, but the exact period isn't known for certain.
+
All savegames, including non-gamecard savegames, are encrypted with AES-CTR. The base CTR never changes after savegame creation. The CTR used for gamecard savegames eventually repeats, while non-gamecard savegames don't use a repeating CTR. For the old gamecard CTR method, it repeated every 0x200-bytes. With the new method it repeats at least every 0x1000-bytes, but the exact period isn't known for certain. Non-gamecard savegames use a separate CTR method from the gamecard savegames.
   −
Update:
+
With system version [[2.0.0-4]] the system now uses a different CTR method, which fixed the above flaw. The CTR seems to repeat in the image but not every 0x200 bytes. The CTR may repeat every 0x1000 bytes. Every title since "Super Mario 3D Land" which have the [[NCSD|CCI]] NVer version set to the  [[2.0.0-4]] NVer version or higher uses this improved method, while older titles still use the old 0x200-byte period.
 
  −
With system version [[2.0.0-4]] the system now uses a different CTR method, which fixed the above flaw. The xorpad seems to repeat in the file but not every 0x200 bytes. So for now it is unknown how to decrypt the newer save files.
  −
 
  −
'''Games to use the new encryption:'''
  −
* Super Mario 3D Land
  −
* Mario Kart 7
  −
* Need for Speed - The Run
  −
 
  −
'''Some information:'''
  −
* Old games saves still use the old 0x200-bytes AES-CTR xorpad.
  −
* New games saves can be backed-up and restored.
  −
* The wearleveling stayed the same.
  −
* Xoring two files together can produce some clear text
  −
* It's been spotted that the AES-CTR xorpad repeated after 0x1000 bytes (so it might be the maximum length but still it's not proved).
      
=== Wear leveling ===
 
=== Wear leveling ===

Navigation menu