3dbrew - User contributions [en]

Mii Maker

2012-11-02T16:28:43Z

Immortal: /* Mii QR Code format */

'''Mii Maker''' lets you create Miis, like Wii Mii Channel. Here you can transfer Miis locally from other 3DSes, or from Wii Mii Channel. 3DS Miis can't be transfered to Wii Mii Channel, only from Wii.

== Wii Mii Channel transfer protocol ==

The Wii beacons are similar to the usual multi-cart NDS beacons, except: beacon_type is zero, and payload size is 0x14. The payload data is just the Wii UTF-16 nickname, with some extra unused zero data. The usual multi-cast NDS protocol is used for sending the 3DS nick to the Wii. After many keep-alive frames, it eventually sends a bunch of frames, each containing the whole Mii. There's a 6-byte header, followed by [http://wiibrew.org/wiki/Wiimote/Mii_Data Mii data]. At the end of these frames like most NDS frames is the 0200 byte marker.

== Mii QR Code format ==

3DS Mii QR is a standard 57x57 pixel Level 10 High ECC QR code with 'Mii' logo in center (refer to [http://www.denso-wave.com/qrcode Denso-Wave Inc] web site for QR Code format specifications). It contain 112 byte of binary data. 3DS seems to have fully implemented QR-code decoder, as it can interpret such Mii binary data being encoded even in the smallest possible for that data size Level 6 Low ECC QR code. The data itself is encrypted, presumably AES-CTR since some xorpads can be determined from known plaintext here. The CTR might be based on data stored here?

{| class="wikitable"
|-
! Offset
! Length
!
|-
| 0x0
| 0x4
| Mii ID (big-endian 32-bit unsigned integer)

The most significant 3 bits determine whether the Mii is Special, Foreign, or Normal [http://www.davidhawley.co.uk/special-miis-gold-pants-and-creating.aspx]

time_offset = (mii_id & 0x0FFFFFFF) * 2;

time_offset is the time the Mii was created, represented as the number of seconds since 01/01/2010 00:00:00
|-
| 0x4
| 0x4
| High 4 octets of MAC address [http://www.adminsub.net/mac-address-finder/nintendo]
|-
| 0x8
| 0x1
| unknown
|-
| 0x9
| 0x1
| Allow Copying
|-
| 0xA
| 0xE
| unknown
|-
| 0x18
| 0x2
| Bit-mapped: Birthday (4bit-day,5bit-month), Sex, Shirt, ??
|-
| 0x1A
| 0x14
| UTF-16 Mii Name
|-
| 0x2E
| 0x2
| unknown
|-
| 0x30
| 0x1
| Mii Sharing Value
|-
| 0x31
| 0xB
| unknown
|-
| 0x3C
| 0x1
| Allow Copying
|-
| 0x3D
| 0x3
| unknown
|-
| 0x40
| 0x1
| Mii Sharing Value
|-
| 0x41
| 0x7
| unknown
|-
| 0x48
| 0x14
| UTF-16 Author Name
|-
| 0x5C
| 0x2
| unknown
|-
| 0x5E
| 0x2
| unknown (seems like the start of the checksum)
|-
| 0x60
| 0x10
| AES-CCM MAC?
|}

* Codes made from the same 3DS for the same Mii are encrypted with the same xorpad (you can recreate it by xoring with known values from this table).

Friend code

2011-10-11T17:21:32Z

Immortal:

{| class="wikitable" border="1"
|-
! width="32%" | User
! width="20%" | Friend code
! width="8%" |Region
! width="30%" |Comment here
! |Mii image
|-
| Matyapiro31
| <nowiki>4339-2455-6521</nowiki>
| Japan
| Let's hack 3DS! But how?
| [[File:HNI 0019.JPG]]
|-
| Crediar
| 2535-3625-3742
| Europe
| None
|
|-
| Kazuma
| 2277-6646-9164
| Europe
| None
|
|-
| SaltyPancakes
| 0044-2836-4738
| Europe
| None
|
|-
| Inspectah
| 3909-7495-9525
| Europe
| None
|
|-
| XanLoves
| 3995-6523-2805
| Europe
| None
|
|-
| muhkuh2005
| 2449-4689-9707
| Europe
| Germanfag
|
|-
| RHOPKINS13
| 4854-6450-1577
| USA
| None
| [[File:RHOPKINS13_Mii.JPG]]
|-
| fishuyo
| 2535-3630-0678
| USA
| None
|
|-
| marcosxd
| 0216-0901-5448
| Mexico
| Crediar add me please, I already added you :)
|
|-
| Mafril
| 5112-3460-1421
| USA
| None
| [[File:Mafril_Mii.JPG]]
|-
|Epicdude
|0130-1922-3022
|USA
|
|-
|David
|3553-9962-0973
|USA
|Add me
|
|-
| Muzer
| 3136-6762-5385
| Europe
| I have added everyone on this list who has a valid friend code (David and marcosxd don't) - so please add me if you get the chance.
| [[File:Muzer_Mii.jpg|120px]]
|-
| Rikku2000
| <nowiki>1461-6425-0347</nowiki>
| Germany
| None
|
|-
|Elisherer
|0001-3489-0550
|USA
|None
|[[File:Elisherer_Mii.JPG|120px]]
|-
|Liam87
|2664-2361-9358
|England
|Add me please, i have added everyone on here, thank you
|
|-
|Luishane
|1289-8459-2533
|Venezuela
|Add me...thanks
|
|-
|Immortal_no1
|0516-7257-0011
|UK
|Add me and PM me on gbatemp.net with yours or e-mail me on "immortal_no1@hotmail.com"
|
|-

Friend code

2011-10-11T17:20:35Z

Immortal:

{| class="wikitable" border="1"
|-
! width="32%" | User
! width="20%" | Friend code
! width="8%" |Region
! width="30%" |Comment here
! |Mii image
|-
| Matyapiro31
| <nowiki>4339-2455-6521</nowiki>
| Japan
| Let's hack 3DS! But how?
| [[File:HNI 0019.JPG]]
|-
| Crediar
| 2535-3625-3742
| Europe
| None
|
|-
| Kazuma
| 2277-6646-9164
| Europe
| None
|
|-
| SaltyPancakes
| 0044-2836-4738
| Europe
| None
|
|-
| Inspectah
| 3909-7495-9525
| Europe
| None
|
|-
| XanLoves
| 3995-6523-2805
| Europe
| None
|
|-
| muhkuh2005
| 2449-4689-9707
| Europe
| Germanfag
|
|-
| RHOPKINS13
| 4854-6450-1577
| USA
| None
| [[File:RHOPKINS13_Mii.JPG]]
|-
| fishuyo
| 2535-3630-0678
| USA
| None
|
|-
| marcosxd
| 0216-0901-5448
| Mexico
| Crediar add me please, I already added you :)
|
|-
| Mafril
| 5112-3460-1421
| USA
| None
| [[File:Mafril_Mii.JPG]]
|-
|Epicdude
|0130-1922-3022
|USA
|
|-
|David
|3553-9962-0973
|USA
|Add me
|
|-
| Muzer
| 3136-6762-5385
| Europe
| I have added everyone on this list who has a valid friend code (David and marcosxd don't) - so please add me if you get the chance.
| [[File:Muzer_Mii.jpg|120px]]
|-
| Rikku2000
| <nowiki>1461-6425-0347</nowiki>
| Germany
| None
|
|-
|Elisherer
|0001-3489-0550
|USA
|None
|[[File:Elisherer_Mii.JPG|120px]]
|-
|Liam87
|2664-2361-9358
|England
|Add me please, i have added everyone on here, thank you
|-
|Luishane
|1289-8459-2533
|Venezuela
|Add me...thanks
|-
|Immortal_no1
|0516-7257-0011
|UK
|Add me and PM me on gbatemp.net with yours or e-mail me on "immortal_no1@hotmail.com"
|-

Savegames

2011-08-19T06:18:28Z

Immortal: /* Partitions */

=== 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.

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.

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.

=== Wear leveling ===

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.

The blockmap structure is simple:
<pre>
struct header_entry {
uint8_t chksums[8];
uint8_t phys_sec;
uint8_t alloc_cnt;
} __attribute__((__packed__));
</pre>

The journal structure is as follows:
<pre>
struct sector_entry {
uint8_t virt_sec; // Mapped to sector
uint8_t prev_virt_sec; // Physical sector previously mapped to
uint8_t phys_sec; // Mapped from sector
uint8_t prev_phys_sec; // Virtual sector previously mapped to
uint8_t phys_realloc_cnt; // Amount of times physical sector has been remapped
uint8_t virt_realloc_cnt; // Amount of times virtual sector has been remapped
uint8_t chksums[8];
} __attribute__((__packed__));

struct long_sector_entry{
struct sector_entry sector;
struct sector_entry dupe;
uint32_t magic;
}__attribute__((__packed__));
</pre>

With magic being a constant 0x080d6ce0.

=== Partitions ===

There can be multiple partitions on the chip. For some games one is a backup partition, some other games seem to use only one partition, yet other games actually use multiple partitions. Partitions are defined at the start of the de-wearleveled blob. At offset 0x200 into the image, the DIFI blobs start. These 0x130 large blobs describe the partitions. Every DIFI blob describes a partition. In order to find the partitions, you will need the uint32_t at 0x9C into the DIFI block, and the uint32_t at 0xA4. The uint32_t at 0x9C describes the length of the hash table at the start of the partition, the uint32_t at 0xA4 is the length of the filesystem. Partitions are catted together, so the end of one partition is the beginning of the next.

The first partition starts at 0x2000. The hashtable at the start of the partitions describe each in-use block in the partition with a SHA256 of the 0x1000 sized block.

* The exact location of the partition can vary in each save/game.
* The first two hashes don't seem to be associated with any 0x1000 block.
* (edit) The last 0x20 bytes of the hash table, doesn't appear to change along with the rest of the data and repeats at the end of all other hash-tables, even when the hashes/data are different. (edit) The last 0x20 bytes of the hash table is NULL data, it is because the Hash table is only 0x1E0 in size and the XOR hash is 0x200 in size, so the 0x20 bytes you see at the end is actually 0x20 bytes of (FF) xor'd with the last 0x20 bytes of the key. Thus the data recurs. --[[User:Immortal|Immortal]] 09:14, 19 August 2011 (GMT)

The hash in the DISA blob hashes 300 bytes of the first DIFI blob.

* If the uint32 before the hash in the DISA is 0x01, the first DIFI blob is hashed, if it's 0x00 the second DIFI is hashed. The offsets and size for each DIFI can be found beneath the DISA tag (10h, 20h and 18h, 30h relative to the DISA location).

=== Filesystem ===

Savefiles are stored on the FLASH in a custom filesystem called SAVE. SAVE has a header which describes where the various bits of the filesystem live. The most important is the FST or filesystem table. You can find the FST by first finding the file base offset which is the offset to which all the entries in the FST are relative. The file base offset is a uint16_t at 0x58 from the filesystem start. The FST offset is a uint32_t at 0x6C and is in blocks (which are 0x200 bytes large).

Once you've found the FST, parsing it is fairly straightforward.

<pre>
struct fs_entry {
u32 node_cnt;
u8 filename[0x10];
u32 index;
u32 unk1; // magic?
u32 block_offset;
u32 file_size;
u32 unk2;
u32 unk3; // flags and/or date?
u32 unk4;
}
</pre>

The first entry is the root directory, easily identifiable by the node_cnt being larger than 1. The node_cnt includes the root directory itself, so there are node_cnt - 1 files in the root directory. The entries that follow after the root directory are the actual files. Reading them out is as simple as taking the file base offset and adding (block_offset * 0x200) to it.

Example from Super MonkeyBall 3D:
<pre>
0003800: 04000000 21000000 00000000 00000000 ....!...........
0003810: 00000000 00000000 00000000 00000000 ................
0003820: 00000000 00000000 00000000 00000000 ................
0003830: 01000000 736d6233 64732e64 61740000 ....smb3ds.dat..
0003840: 00000000 00000000 d57b1100 05000000 .........{......
0003850: e4060000 00000000 c8cf0008 00000000 ................
0003860: 01000000 6d677265 706c6179 30302e64 ....mgreplay00.d
0003870: 61740000 01000000 d57b1100 09000000 at.......{......
0003880: 1c210000 00000000 cd331000 00000000 .!.......3......
0003890: 01000000 6d677265 706c6179 30312e64 ....mgreplay01.d
00038a0: 61740000 02000000 d57b1100 1a000000 at.......{......
00038b0: 1c210000 00000000 00000000 00000000 .!..............
</pre>

=== Initialization ===

When a save EEPROM contains all xFFFF blocks it's assumed uninitialized by the game cartridges and it initializes default data in place, without prompting the user.

[[セーブデータ|Japanese]]

Savegames

2011-08-19T06:13:51Z

Immortal: /* Partitions */

=== 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.

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.

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.

=== Wear leveling ===

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.

The blockmap structure is simple:
<pre>
struct header_entry {
uint8_t chksums[8];
uint8_t phys_sec;
uint8_t alloc_cnt;
} __attribute__((__packed__));
</pre>

The journal structure is as follows:
<pre>
struct sector_entry {
uint8_t virt_sec; // Mapped to sector
uint8_t prev_virt_sec; // Physical sector previously mapped to
uint8_t phys_sec; // Mapped from sector
uint8_t prev_phys_sec; // Virtual sector previously mapped to
uint8_t phys_realloc_cnt; // Amount of times physical sector has been remapped
uint8_t virt_realloc_cnt; // Amount of times virtual sector has been remapped
uint8_t chksums[8];
} __attribute__((__packed__));

struct long_sector_entry{
struct sector_entry sector;
struct sector_entry dupe;
uint32_t magic;
}__attribute__((__packed__));
</pre>

With magic being a constant 0x080d6ce0.

=== Partitions ===

There can be multiple partitions on the chip. For some games one is a backup partition, some other games seem to use only one partition, yet other games actually use multiple partitions. Partitions are defined at the start of the de-wearleveled blob. At offset 0x200 into the image, the DIFI blobs start. These 0x130 large blobs describe the partitions. Every DIFI blob describes a partition. In order to find the partitions, you will need the uint32_t at 0x9C into the DIFI block, and the uint32_t at 0xA4. The uint32_t at 0x9C describes the length of the hash table at the start of the partition, the uint32_t at 0xA4 is the length of the filesystem. Partitions are catted together, so the end of one partition is the beginning of the next.

The first partition starts at 0x2000. The hashtable at the start of the partitions describe each in-use block in the partition with a SHA256 of the 0x1000 sized block.

* The exact location of the partition can vary in each save/game.
* The first two hashes don't seem to be associated with any 0x1000 block.

* (edit)The last 0x20 bytes of the hash table, doesn't appear to change along with the rest of the data and repeats at the end of all other hash-tables, even when the hashes/data are different. (edit) The last 0x20 bytes of the hash table is NULL data, it is because the Hash table is only 0x1E0 in size and the XOR hash is 0x200 in size, so the 0x20 bytes you see at the end is actually 0x20 bytes of (FF) xor'd with the last 0x20 bytes of the key. Thus the data recurs.

The hash in the DISA blob hashes 300 bytes of the first DIFI blob.

* If the uint32 before the hash in the DISA is 0x01, the first DIFI blob is hashed, if it's 0x00 the second DIFI is hashed. The offsets and size for each DIFI can be found beneath the DISA tag (10h, 20h and 18h, 30h relative to the DISA location). --[[User:Immortal|Immortal]] 09:14, 19 August 2011 (GMT)

=== Filesystem ===

Savefiles are stored on the FLASH in a custom filesystem called SAVE. SAVE has a header which describes where the various bits of the filesystem live. The most important is the FST or filesystem table. You can find the FST by first finding the file base offset which is the offset to which all the entries in the FST are relative. The file base offset is a uint16_t at 0x58 from the filesystem start. The FST offset is a uint32_t at 0x6C and is in blocks (which are 0x200 bytes large).

Once you've found the FST, parsing it is fairly straightforward.

<pre>
struct fs_entry {
u32 node_cnt;
u8 filename[0x10];
u32 index;
u32 unk1; // magic?
u32 block_offset;
u32 file_size;
u32 unk2;
u32 unk3; // flags and/or date?
u32 unk4;
}
</pre>

The first entry is the root directory, easily identifiable by the node_cnt being larger than 1. The node_cnt includes the root directory itself, so there are node_cnt - 1 files in the root directory. The entries that follow after the root directory are the actual files. Reading them out is as simple as taking the file base offset and adding (block_offset * 0x200) to it.

Example from Super MonkeyBall 3D:
<pre>
0003800: 04000000 21000000 00000000 00000000 ....!...........
0003810: 00000000 00000000 00000000 00000000 ................
0003820: 00000000 00000000 00000000 00000000 ................
0003830: 01000000 736d6233 64732e64 61740000 ....smb3ds.dat..
0003840: 00000000 00000000 d57b1100 05000000 .........{......
0003850: e4060000 00000000 c8cf0008 00000000 ................
0003860: 01000000 6d677265 706c6179 30302e64 ....mgreplay00.d
0003870: 61740000 01000000 d57b1100 09000000 at.......{......
0003880: 1c210000 00000000 cd331000 00000000 .!.......3......
0003890: 01000000 6d677265 706c6179 30312e64 ....mgreplay01.d
00038a0: 61740000 02000000 d57b1100 1a000000 at.......{......
00038b0: 1c210000 00000000 00000000 00000000 .!..............
</pre>

=== Initialization ===

When a save EEPROM contains all xFFFF blocks it's assumed uninitialized by the game cartridges and it initializes default data in place, without prompting the user.

[[セーブデータ|Japanese]]

Talk:Savegames

2011-08-18T07:10:51Z

Immortal:

Unknowns:
* Hashes at the end of each DIFI blob.
* How order / location of hash vs. partitioned blocks is determined. (since not sequentially).

I think there should be a page with infos on how to dump/restore saves.
[[メインページ|Matyapiro]]:So then,I show you how to do dump and restore saves.
First,you should have either Nintendo DS/Lite or NDS Adapter a tool to dump DS saves.
It can restore saves,but Almost saves cannot dump with NDS Adapter,but some of them can.
If you have Nintendo DS or DS Lite,you should try DSaveManager.
It uses FTP to dump saves,only dump. Last,I show you another save backup tool for DS. NDS Backup Tool by Rudolph. Eepinator by WinterMute

Hardware:
* NDS Adapter Plus (by hkems)
* DS/DSLite & DSaveManager
* Neo SMS4 (by neoflash, untested)

But I cannot find any key word like player name,high score or play time
if I decrypt the save.

How do you think about whether any other encryption or special way to read/write save used ?[[User talk:Matyapiro31|Matyapiro]]

* I found those things in a SSFIV saved game...

The important offsets are usually constant, the values change, it's not hard to look for an offset of data that's changing predictably after you re-save.

Sometimes you have to use your imagination. To find 20,000 points in SSFIV, you'd search for "0xC8" ( 200 in decimal == "20,000" in game ) because it stores the points in multiples of 100. It's easier to see if you're editing saves in front of yourself and constantly making minor changes to it - to see where those changes show up later. --jl

So we need analyze project with each save.?[[User talk:Matyapiro31|Matyapiro]]
* Only if you're trying to figure out where the game data is. Just common sense.
* You can examine each save manually after making small changes ( while playing with it on the 3DS ) but we still don't know what all the hashes are being used for.

spell error?What's this?
~Partitions are "catted" together　
[[User talk:Matyapiro31|Matyapiro]]
* Con'''cat'''enated. Attached, joined, appended. One follows after the other. lol.

I looked into that blockmap structure thing, but I fear I didn't get it right...
* sectors would be 4096 bytes. The Rayman 3D save is 128mb and has 31 blockmap entries; the Ridge Racer 3D save is 1mb but only has 127 blockmap entries (however the second half of that save is mostly a mirror of the first half, except for the first (special) sector).
* the dword at the beginning of the image tells the sector size (1<<val = sector size)?
* blockmap entries are phys_sec,alloc_cnt,checksum instead of checksum,phys_sec,alloc_cnt. There are then two spare bytes between the blockmap and the journal.
* bit7 of phys_sec in blockmap entries is set when the entry's checksum isn't zero
--[[User:Luigi2us|Luigi2us]] 18:29, 4 August 2011 (CEST)

3DS Save De/Encrypter

3DS Save De/Encrypter application needs useful info on the header Blockmap\Journal foe save modification. I'm so close i can feel it.
--[[User:Immortal|Immortal]] 10:10, 18 August 2011 (GMT)

Talk:Savegames

2011-08-18T07:10:02Z

Immortal:

Unknowns:
* Hashes at the end of each DIFI blob.
* How order / location of hash vs. partitioned blocks is determined. (since not sequentially).

I think there should be a page with infos on how to dump/restore saves.
[[メインページ|Matyapiro]]:So then,I show you how to do dump and restore saves.
First,you should have either Nintendo DS/Lite or NDS Adapter a tool to dump DS saves.
It can restore saves,but Almost saves cannot dump with NDS Adapter,but some of them can.
If you have Nintendo DS or DS Lite,you should try DSaveManager.
It uses FTP to dump saves,only dump. Last,I show you another save backup tool for DS. NDS Backup Tool by Rudolph. Eepinator by WinterMute

Hardware:
* NDS Adapter Plus (by hkems)
* DS/DSLite & DSaveManager
* Neo SMS4 (by neoflash, untested)

But I cannot find any key word like player name,high score or play time
if I decrypt the save.

How do you think about whether any other encryption or special way to read/write save used ?[[User talk:Matyapiro31|Matyapiro]]

* I found those things in a SSFIV saved game...

The important offsets are usually constant, the values change, it's not hard to look for an offset of data that's changing predictably after you re-save.

Sometimes you have to use your imagination. To find 20,000 points in SSFIV, you'd search for "0xC8" ( 200 in decimal == "20,000" in game ) because it stores the points in multiples of 100. It's easier to see if you're editing saves in front of yourself and constantly making minor changes to it - to see where those changes show up later. --jl

So we need analyze project with each save.?[[User talk:Matyapiro31|Matyapiro]]
* Only if you're trying to figure out where the game data is. Just common sense.
* You can examine each save manually after making small changes ( while playing with it on the 3DS ) but we still don't know what all the hashes are being used for.

spell error?What's this?
~Partitions are "catted" together　
[[User talk:Matyapiro31|Matyapiro]]
* Con'''cat'''enated. Attached, joined, appended. One follows after the other. lol.

I looked into that blockmap structure thing, but I fear I didn't get it right...
* sectors would be 4096 bytes. The Rayman 3D save is 128mb and has 31 blockmap entries; the Ridge Racer 3D save is 1mb but only has 127 blockmap entries (however the second half of that save is mostly a mirror of the first half, except for the first (special) sector).
* the dword at the beginning of the image tells the sector size (1<<val = sector size)?
* blockmap entries are phys_sec,alloc_cnt,checksum instead of checksum,phys_sec,alloc_cnt. There are then two spare bytes between the blockmap and the journal.
* bit7 of phys_sec in blockmap entries is set when the entry's checksum isn't zero
--[[User:Luigi2us|Luigi2us]] 18:29, 4 August 2011 (CEST)

3DS Save De/Encrypter:
3DS Save De/Encrypter application needs useful info on the header Blockmap\Journal foe save modification. I'm so close i can feel it.
--[[User:Immortal|Immortal]] 10:10, 18 August 2011 (GMT)

Talk:Savegames

2011-08-18T07:08:27Z

Immortal:

Unknowns:
* Hashes at the end of each DIFI blob.
* How order / location of hash vs. partitioned blocks is determined. (since not sequentially).

I think there should be a page with infos on how to dump/restore saves.
[[メインページ|Matyapiro]]:So then,I show you how to do dump and restore saves.
First,you should have either Nintendo DS/Lite or NDS Adapter a tool to dump DS saves.
It can restore saves,but Almost saves cannot dump with NDS Adapter,but some of them can.
If you have Nintendo DS or DS Lite,you should try DSaveManager.
It uses FTP to dump saves,only dump. Last,I show you another save backup tool for DS. NDS Backup Tool by Rudolph. Eepinator by WinterMute

Hardware:
* NDS Adapter Plus (by hkems)
* DS/DSLite & DSaveManager
* Neo SMS4 (by neoflash, untested)

But I cannot find any key word like player name,high score or play time
if I decrypt the save.

How do you think about whether any other encryption or special way to read/write save used ?[[User talk:Matyapiro31|Matyapiro]]

* I found those things in a SSFIV saved game...

The important offsets are usually constant, the values change, it's not hard to look for an offset of data that's changing predictably after you re-save.

Sometimes you have to use your imagination. To find 20,000 points in SSFIV, you'd search for "0xC8" ( 200 in decimal == "20,000" in game ) because it stores the points in multiples of 100. It's easier to see if you're editing saves in front of yourself and constantly making minor changes to it - to see where those changes show up later. --jl

So we need analyze project with each save.?[[User talk:Matyapiro31|Matyapiro]]
* Only if you're trying to figure out where the game data is. Just common sense.
* You can examine each save manually after making small changes ( while playing with it on the 3DS ) but we still don't know what all the hashes are being used for.

spell error?What's this?
~Partitions are "catted" together　
[[User talk:Matyapiro31|Matyapiro]]
* Con'''cat'''enated. Attached, joined, appended. One follows after the other. lol.

I looked into that blockmap structure thing, but I fear I didn't get it right...
* sectors would be 4096 bytes. The Rayman 3D save is 128mb and has 31 blockmap entries; the Ridge Racer 3D save is 1mb but only has 127 blockmap entries (however the second half of that save is mostly a mirror of the first half, except for the first (special) sector).
* the dword at the beginning of the image tells the sector size (1<<val = sector size)?
* blockmap entries are phys_sec,alloc_cnt,checksum instead of checksum,phys_sec,alloc_cnt. There are then two spare bytes between the blockmap and the journal.
* bit7 of phys_sec in blockmap entries is set when the entry's checksum isn't zero
--[[User:Luigi2us|Luigi2us]] 18:29, 4 August 2011 (CEST)

3DS Save De/Encrypter application needs useful info on the header Blockmap\Journal foe save modification. I'm so close i can feel it.

3DS Save DeEncrypter3DS

2011-08-05T14:06:13Z

Immortal: just removed no essential old info

{{Infobox homebrew
| title = 3DS Save DeEncrypter
| image =
| type = system tool
| author = [[User:Blite|Blite]]
| download = http://hotfile.com/dl/125810393/5d24186/3DS_Save_DeEncrypter_v1.4.zip.html
| version = 1.4
}}

3DS Save DeEncrypter v1.4 released by Blite to Decrypt and encrypt 3DS gamesaves. Windows GUI used so no need for console commands.

v1.4 -Decryption now places "FF" into decrypted file incase of CRC checksum miscalculations.
So now removed the need for backwards compatability with 3DS SaveTool by crediar.
-Some people have said they needed a file to get the application running so added
COMCTL32.OCX to archive for those people that need it.
-Added an icon for aesthetics.

v1.3 -Added creation of EEPROM save Reset to restore Game cartridges to Factory default (e.g. 0xFF)

v1.2 -Major upgrade to the speed of the decryption/encryption.
-Save File info added to FIle menu.

v1.1 -Conversion of decrypted files using 3DS Save DeEncrypter to those that 3DSaveTool will support

v1.0 -Works on all computers tested with so far, no issues with critical sections using MSVCR100.dll as it down't use it.

Tested on all games that i own and works. Encryption of files correctly binary compares with the origional encrypted file.

Down the line
-CRC info in Save File info
-Specific game save information: currently working on: - Resident Evil Mercenaries

3DS Save DeEncrypter3DS

2011-08-05T14:05:37Z

Immortal: Updated to v1.4

{{Infobox homebrew
| title = 3DS Save DeEncrypter
| image =
| type = system tool
| author = [[User:Blite|Blite]]
| download = http://hotfile.com/dl/125810393/5d24186/3DS_Save_DeEncrypter_v1.4.zip.html
| version = 1.4
}}

3DS Save DeEncrypter v1.4 released by Blite to Decrypt and encrypt 3DS gamesaves. Windows GUI used so no need for console commands.

v1.4 -Decryption now places "FF" into decrypted file incase of CRC checksum miscalculations.
So now removed the need for backwards compatability with 3DS SaveTool by crediar.
-Some people have said they needed a file to get the application running so added
COMCTL32.OCX to archive for those people that need it.
-Added an icon for aesthetics.

v1.3 -Added creation of EEPROM save Reset to restore Game cartridges to Factory default (e.g. 0xFF)

v1.2 -Major upgrade to the speed of the decryption/encryption.
-Save File info added to FIle menu.

v1.1 -Conversion of decrypted files using 3DS Save DeEncrypter to those that 3DSaveTool will support

v1.0 -Works on all computers tested with so far, no issues with critical sections using MSVCR100.dll as it down't use it.

-Decryption places "DE AD BE EF" into decrypted file for easy tracking and re-encryption,
Tested on all games that i own and works. Encryption of files correctly binary compares with the origional encrypted file.

Down the line
-CRC info in Save File info
-Specific game save information: currently working on: - Resident Evil Mercenaries