Hacking Hacking with 3DS Save DeEncrypter

[Immortal_no1]

I wonder if the hex values are added together and then a modulus is used. I'll write a test app to see if that works. Otherwise I'm starting to run out of ideas...

try this http://www.cosc.canterbury.ac.nz/greg.ewin...ngineering.html

I just read the essay. It's rather interesting. I'll try and implment his process to our crc checks, if anyone else wants to give it a go, feel free.

 

[Edwii]

Noob question:

With this level of hacking, is this solely for modifying saves, or could this lead to opening the door to "jail braking" the 3DS(running home brew/ 3ds roms?)

 

[Immortal_no1]

Noob question:

With this level of hacking, is this solely for modifying saves, or could this lead to opening the door to "jail braking" the 3DS(running home brew/ 3ds roms?)

I refer you to post #100 in this thread
Aug 18 2011, 05:25 PM

I see where you're coming from and to tell the truth, we just don't know at this point if it can open the door for any potential exploits... but let me put forward a scenario... you save a game, maybe Zelda, you modify the save to change your name of your character to to "0x00" or "nop" or "0x90" depending on how it works, you save the change and rebuild the checksum. you startup your game and when it gets to a point where a character talks to your character....... they can't use your name anymore and possibly either "just continues" "or crashes" or possibly jump over the instruction to the next one in the game... and the location just happens to be in the gamesave data file. Now say we write an instruction at the address in the game save it jumps to, and tell it to jump to another area of memory. At this point if all were to go well we would then have the system output copious amounts of data to the screen which in effect would be ROM information. If you could redirect that to the SD card port you will have made a ROM dumper for that game. If it would be possible to freeze the game prior to that point you could possibly see about ejecting the cartridge and swapping it for another game and you then have a multi game ROM dumper.

It's all potential and the potential is limitless with the more games that are released.
It's all Hypothetical at this point until the checksums can be cracked and then we'll see what we've got.

 

[Edwii]

Noob question:

With this level of hacking, is this solely for modifying saves, or could this lead to opening the door to "jail braking" the 3DS(running home brew/ 3ds roms?)

I refer you to post #100 in this thread
Aug 18 2011, 05:25 PM

I see where you're coming from and to tell the truth, we just don't know at this point if it can open the door for any potential exploits... but let me put forward a scenario... you save a game, maybe Zelda, you modify the save to change your name of your character to to "0x00" or "nop" or "0x90" depending on how it works, you save the change and rebuild the checksum. you startup your game and when it gets to a point where a character talks to your character....... they can't use your name anymore and possibly either "just continues" "or crashes" or possibly jump over the instruction to the next one in the game... and the location just happens to be in the gamesave data file. Now say we write an instruction at the address in the game save it jumps to, and tell it to jump to another area of memory. At this point if all were to go well we would then have the system output copious amounts of data to the screen which in effect would be ROM information. If you could redirect that to the SD card port you will have made a ROM dumper for that game. If it would be possible to freeze the game prior to that point you could possibly see about ejecting the cartridge and swapping it for another game and you then have a multi game ROM dumper.

It's all potential and the potential is limitless with the more games that are released.
It's all Hypothetical at this point until the checksums can be cracked and then we'll see what we've got.

ah thanks, I had a feeling it was something a long those lines.

Is there any grunt work an average guy like me can contribute?

 

[lazymarek]

It's all potential and the potential is limitless with the more games that are released.
It's all Hypothetical at this point until the checksums can be cracked and then we'll see what we've got.

Yeah, first we need the control over the checksums then we could think about putting an exploit into the savefile.
Maybe we could use the files in the FS of the savefile ultimately to put the exploit in any of these files...?

QUOTEsee where you're coming from and to tell the truth, we just don't know at this point if it can open the door for any potential exploits... but let me put forward a scenario... you save a game, maybe Zelda, you modify the save to change your name of your character to to "0x00" or "nop" or "0x90" depending on how it works, you save the change and rebuild the checksum. you startup your game and when it gets to a point where a character talks to your character....... they can't use your name anymore and possibly either "just continues" "or crashes" or possibly jump over the instruction to the next one in the game... and the location just happens to be in the gamesave data file. Now say we write an instruction at the address in the game save it jumps to, and tell it to jump to another area of memory.

In x86 assembler NOP would be 0x90, but in ARM asm ther's no NOP I think...? you can use MOV r0, r0.
Are you sure that the Zelda game will execute the character's name? At this point you have thought about the Twilight Hack, right?
However, the Twilight Hack is a bit different I think, the name of the horse Epona is too long for the game and it overwrites the following stack with a jump instruction
to jump to the exploit code in the savefile.
Is this correct...?

 

[Immortal_no1]

Edwii, if you have any programming knowledge then you can have a go at whipping up an application to help with finding the crc's.

If you work for nintendo... even better, get us some datasheets on the game save control. Doubt you do though... shame.

You can try to surf the net to see if you can find anything useful to aid in our endevour to modify a gamesave.

Lazymarek, I know of the twilight hack but don't know the specifics, what I wrote in my earlier post was just my own thought and don't know if it would work or not. Recreating the header structure is my main objective so far. If we can all focus on that part at the moment then I think we can move this along faster.

 

[Immortal_no1]

Right, i've made a quick little app to test for modulus related CRC values, Click here for download

Simply input from and to values in Hex select a CRC scheme, click on Load to select your gamesave, then click on Get Modulus CRC, you can select between the Original Hex data, the original CRC and the Reversed CRC.

Have a play about with it and maybe we'll get something

 

[ichichfly]

Is it confirmed that it is a crc and not a hash functions or something like xor8 or xor or a sum or Adler or fletcher ?

ADD2: I tested 2 files found 2 blocks of 00 in the one file for a 00 block the checksum is 0x80 in the other 0x71 so I think the checksum is builded over the encrypted data

 

[Immortal_no1]

Is it confirmed that it is a crc and not a hash functions or something like xor8 or xor or a sum or Adler or fletcher ?

ADD2: I tested 2 files found 2 blocks of 00 in the one file for a 00 block the checksum is 0x80 in the other 0x71 so I think the checksum is builded over the encrypted data

I can agree with that. That's the way I've been looking at it. We don't know what type of checksum it uses so at the moment grab a pencil and paper and try out various combinations of things until we get something that works.

If you want to check various hashes go ahead, it's nice to have people that know what they're doing.

 

[ichichfly]

@ We don't know what type of checksum it uses so at the moment.

We shoud make some test to do that
xor: xor any Byte in the block with any value get any other byte out of the block and xor it with the same. If the checkbyte is calculated by xor the checkbyte is the sameas befor the xors

sum: add a Value to any 32bit block in the block and sub the same from an other 32 bit block in the block the value should be max 8 bit if that is used the checksum is the same as before

Fletcher and ?Adler?(I am not sure about Adler): exchange 2 blocks blocks can be 4/8/16/32 bit if that is used the checksum is the same as before

?crc? I am not sure: xor the message by B1 than the checkbit change by C1 xor the message with B2 and the checkbyte change by C2 xor the message by (B1 xor B2) and the checkbyte should change by (C1 xor C2)

 

[pachura]

Hi. A few questions:

1. Do you know for sure which bytes of the savegame store the checksum, or you're just guessing ? Are you taking into consideration that there can be more than one checksum ? Are you taking into consideration that checksums can be stored in 3DS' internal memory and not in the savegame itself ?

2. Are you in possession of a Flash writer in order to dump/write the savegame from/to 3DS gamecart ? Were you able to produce multiple savegame files from the same game with just minimal differences ? This is normally a good way to start...

3. Is the XOR-key used to decrypt savegames per-game, per-3DS, or is it different each time you save ?

 

[jalaneme]

Has anyone used the action replay save file manager/ gba adaptor to copy 3ds saves files to your pc? I still have one of these adaptors, I haven't used it in a while though but curious as if it would work.

 

[Immortal_no1]

Hi. A few questions:

1. Do you know for sure which bytes of the savegame store the checksum, or you're just guessing ? Are you taking into consideration that there can be more than one checksum ? Are you taking into consideration that checksums can be stored in 3DS' internal memory and not in the savegame itself ?

2. Are you in possession of a Flash writer in order to dump/write the savegame from/to 3DS gamecart ? Were you able to produce multiple savegame files from the same game with just minimal differences ? This is normally a good way to start...

3. Is the XOR-key used to decrypt savegames per-game, per-3DS, or is it different each time you save ?

If you have followed the thread from the beginning then i believe these questions have all been answered.

1. I know for sure that certain areas of the game save are checksums as i've been able to recreate the checksums, check through the thread, around page 9 i think i posted pictures and explained how to create the checksum for the Main data area.

2. Yes i am, and yes i have and the files have been posted in rar format, check through the thread and you'll see the links. And yes it was a good way to start

3. The XOR key used is different for every game, but the same for every time you make a save on the cartridge, hense you can use the same key every time you want to re-encrypt the data without having to decrypt the data.

Thank you for your questions, but please read through the thread, i don't want to spend time answering questions that have already been answered i'd rather spend that time trying to recreate the header data. This isn't a jab at you personally, just a reminder to everyone reading, alot of time is going into this project, since there are no donations, no sponsors, it's not an official product, the only help i have is from the people on this thread, and we need to keep the interest in this going and growing so we can get this thing done!

 

[Immortal_no1]

Has anyone used the action replay save file manager/ gba adaptor to copy 3ds saves files to your pc? I still have one of these adaptors, I haven't used it in a while though but curious as if it would work.

No i haven't, if you have one, give it a try and see what you get out of it. If it's not complete garbage, post the file in this thread and i'll have a look over it, perhaps it may be of some use.

 

[ichichfly]

1. Do you know for sure which bytes of the savegame store the checksum, or you're just guessing ? Are you taking into consideration that there can be more than one checksum ? Are you taking into consideration that checksums can be stored in 3DS' internal memory and not in the savegame itself ?

We are nearly sure that that there are checksums bytes in the sector_entry that are calculated over the phys_sec the first byte over the first 0x200 byte block of the block the secound over the second 0x200 byte block of the block and so one. Because they change wenn the data change also the same data result in the same byte and if the byte is changed without the data the save is corrupted.

ADD: update fixed some things now more games work also file extracting is now possible (not all games work) http://www.mediafire.com/?7zqrwxxmr2p4lll src soon

use it this way

3dssaveresorter.exe

virtual_3ds_save_file_analyser.exe than result in something like this

Partition0:
hashtabeloffset 2000
SAVEoffset 3000
SAVEsize D000

Partition1:
hashtabeloffset 10000
SAVEoffset 11000
SAVEsize D000

SAVE0:
savestatoffs 3400
filetabeloffs 3600

rootname: files: 2
Splinter3DS (0) start: 3800 size: 589
single (1) start: 3e00 size: b811

SAVE1:
savestatoffs 11400
filetabeloffs 11600

rootname: files: 2
Splinter3DS (0) start: 11800 size: 589
single (1) start: 11e00 size: b811

to extract a file use this

virtual_3ds_save_file_analyser.exe -e

 

[Immortal_no1]

Good Job ichichfly,

I think for the amount of work you've put into that i'll just have your application as a plug-in to the save De/Encrypter instead of rewriting it.

Do you mind if it gets packaged up with the app or would you prefer people to download it directly from you and add it manually?

 

[ichichfly]

Good Job ichichfly,

I think for the amount of work you've put into that i'll just have your application as a plug-in to the save De/Encrypter instead of rewriting it.

Do you mind if it gets packaged up with the app or would you prefer people to download it directly from you and add it manually?

You can pack them up with the app

ADDose someone know if I the 3ds cards savegame chips use 4 bit wide transmission or only SO/SI like the DS ones ?

 

[Immortal_no1]

I would asume that it would be the same as the DS, the 3ds doesn't seem any faster at saving and loading than the DS.

 

[Immortal_no1]

Here's a question:

Q. what calculation would you have to perform on a 0x200 (512)byte block of 0xFF to generate one byte of 0x0F?

The correct answers get a thumbs up from me.

 

[657]

just an idea, but if you could get three consoles to make three identical saves equal to your save states:

Save1-AAAAAAAA.sav
Name: AAAAAAAA
Score: 74768

Save2-BBBBBBBB.sav
Name: BBBBBBBB
Score: 75060

Save3-CCCCCCCC.sav
Name: CCCCCCCC
Score: 75292

then they could be compared in a bit analysis and see if all have the same hashes at the same offsets.
If the saves were made at the same point in the game, but the hashes were different,this POSSIBLY would let you know if there was a "per console" generated keycode of sorts.
or
If the saves were made at the same point in the game, AND the hashes were the same, this POSSIBLY would let you know if there was a "Master Key" generated keycode.

or i could be totally wrong and off base(or it would be to hard to get the exact same scores)
just an idea