Hacking Hacking with 3DS Save DeEncrypter

[CollosalPokemon]

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

If it was a "per console" key wouldn't the saves not be share-able? I know they are share-able (just not editable yet) and they are region-locked. But I could take a save from, for example, a random guy's OoT (US) and put it on my US OoT cart and it would work. (assuming the save was just ripped and given to me, unedited)

For example if anyone wants to download saves from another person ("macrox") several US saves that can be used on a US OoT without problems: (I tested them)

http://macrox.gshi.org/3DS%20Saves/

Just a thought about this.

 

[Immortal_no1]

Lets keep focus.
If we can figure out this calculation question we'll be quite a bit closer.
What calculation would you have to perform on a 0x200 (512)byte block of 0xFF to generate one byte of 0x0F?

If we get the answer to this then we can regenerate the header data, and we can finally see where we stand in relation to the other checksums.

 

[pachura]

Do you know what is the size of the checksum you are looking for ?
Is there a single per-file checksum, or one per 512-bytes' block ?

 

[Immortal_no1]

48 0F 0F 0F 0F 0F 0F 0F
C0 5B AC A2 80 80 80 80
90 BF A3 0F 0F 0F 0F 0F
90 BF 47 0F 0F 0F 0F 0F
3A BF 47 0F 0F 0F 0F 0F

All the above values are supposedly checksums. These are bytes from the bottom of the header, as these are the ones that we're interested in.

If you look at the PDF i provided a little while ago, the addresses of these are in the 3rd column and multiplied by 0x1000, so for example, .... the checksum on the topline starting with 48 should be generated from...

'0x1C x 0x1000' = 0x1C000 -> you will need to look at the PDF to know what this is

Just by looking at the checksum values it doesn't appear to be anything we normally see, for it would appear to be a single byte checksum for a given area.

Since there are 8 bytes, i would guess that the given area is 0x200bytes, as 0x1000 / 8 = 0x200.

We see that there are lots of occurrences of the value 0x0F in the checksums, i would put it to you that those checksums are generated from bytes of 0xFF. That is why i put forward the question about how to make a single byte of 0x0F from a 0x200 byte block of FF.

So to answer your question.... there are LOTS of checksums, just only a few we need to change to get the header to be read correctly by the 3DS, and therefore our modifications to work 'possibly'

 

[ichichfly]

@Immortal_no1

Do you have a game that have a 0x200 save game sector that is every time you save exactly the same as before with an exception of a text?

That can help finding the checksums

ADD: Sorry for my bad English

 

[Immortal_no1]

@Immortal_no1

Do you have a game that have a 0x200 save game sector that is every time you save exactly the same as before with an exception of a text?

That can help finding the checksums

ADD: Sorry for my bad English

I think that you'll find that if you erase/reflash the eeprom of the game and then allow the game to reinitialize the data it will start with the default eeprom setup and at that point 2 of the checksums that haven't been calculated yet nare already in place upon initialization. It makes me wonder if they are xored with a checksum somewhere else. I'll have to have a look.

 

[lazymarek]

Do you have found something out about the checksums?
Maybe there are news for you:
http://www.3dbrew.org/wiki/Savegames
http://www.3dbrew.org/wiki/Talk:Savegames

 

[ichichfly]

Do you have found something out about the checksums?
Maybe there are news for you:
http://www.3dbrew.org/wiki/Savegames
http://www.3dbrew.org/wiki/Talk:Savegames

most of that is already known but something is wrong in the talk

This is most likely a custom checksum algorithm. Standard CRC8 would yield zero for a zero block.

Most time they use a XorIn that is not zero and there is may also an XorOut

to find out what function is use try this

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 same as before 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: exchange 2 blocks blocks can be 4/8/16/32 bit if that is used the checksum is the same as before

crc: 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)

example crc in this case crc-16 but also work with crc-8

06 06 01 05 crc is 1A21

06 06 01 05 xor 01 02 03 04 = 07 04 02 01 crc is 1580

06 06 01 05 xor 08 09 01 02 = 0E 0F 00 07 crc is 2973

06 06 01 05 xor 01 02 03 04 xor 08 09 01 02 = 0F 0D 03 03 crc is 26D2 (2973 xor 1580 xor 1A21)

 

[lazymarek]

Any news? About finding checksums?

 

[how_do_i_do_that]

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.

It doesn't work dumping 3DS saves, the adaptor can't see the 3DS cart. Codejunkie never even gotten around to making a fix for dumping pokemon HG/SS saves let alone 3DS saves.

 

[Cyan]

I see you posted some source code two pages back.
I suggest you use the [code] tag, it will keep the indentation

your source 
{
ÂÂÂÂwith indentation
}

and if it's very long, you can even make it overflow auto by using [codebox]
CODE
long_code_here = ';
.
.
.
.
.
.
It will put a scrollbar

.
.
.
.
if it's too long

 

[Immortal_no1]

That's a handy thing to know.

I'll have to use that in the future.

------
I made a wuick Xor application, i forgot to upload it before i left for work, so i'll upoad it when i get home.

It's a simple,
XOR DATA IN (HEX)
XOR KEY IN (HEX)
XOR DATA OUT (HEX)

if you want any modifications made that you can think of, let me know within the next 6 hours.

 

[Immortal_no1]

Will add a History list, so that the list of actions that have been performed can be logged, just so that you don't have to keep writing them down.

 

[Immortal_no1]

Here's my quick XOR app

XOR Data App

remember it's a quick app, if you have problems.... look at what you're doing then PM me with the problem

 

[ichichfly]

OK the check bytes are to ~ 99,5 % likely crc or something very similar to crc

ADD: Thanks earny for the saves

 

[Immortal_no1]

That confirms my first thoughts. I'm thinking on what the next move should be. We can't just go at it and button-bash. I've tried lots of types of crc and so far hit nothing. It must be a custom crc unless the crc is not of 0x200 bytes which wouldn't really suit the save header structure.

So a custom crc... since it's one byte crc values it would suggest it's an 8 bit crc, the question is... is the value at the end xor'ed with something to give you.the final value or is there an xor at the begining of the process... and what is the polynominal value used? I want to make an application that will automatically go through and test this but I haven't a clue at the moment where to start. Ichi you have any skills in this area?

 

[Arisotura]

I already ran an app that tries every polynomial+xorin+xorout combination on a few blocks, and got nothing.

The CRC may be calculated with reflection, or it may just not be a CRC at all. Perhaps it's some obscure hashing method.

Also, you may find different blocks with identical checksums, meaning that the algorithm is easily prone to collisions. That may or may not help.

 

[Immortal_no1]

I already ran an app that tries every polynomial+xorin+xorout combination on a few blocks, and got nothing.

The CRC may be calculated with reflection, or it may just not be a CRC at all. Perhaps it's some obscure hashing method.

Also, you may find different blocks with identical checksums, meaning that the algorithm is easily prone to collisions. That may or may not help.

did you try blocks of 0x200 in size?

If you can run every permutation again and log the settings which gave you the correct output, can you try with the same settings on another block to see if any of them also give the correct one?

Or post your app if it's userfriendly

 

[Arisotura]

I tried 0x200 large blocks, indeed.

Also, my app isn't userfriendly at all and is being modified like every 5 minutes, so uh... however, I can give you two different blocks that yield the same checksum (0x70): http://www.mediafire.com/?mtbba1c7z4bviz8.

 

[ichichfly]

May it is a crc 16 with a xor or something of both bytes.

I think this is the end for this.

since there are 1000 of ways the checkbyte can be calculated