Hacking Hacking with 3DS Save DeEncrypter

[Immortal_no1]

I'm going to update my tutorial soon. I think there's still a little more work to do before we can use modified saves.

 

[ichichfly]

update of the 3dssavesorter http://www.mediafire.com/?dw14ob6x0b4eo4t

new functions are to check the checksum fix the checksum and make a physical file out of a virtual

-r (generate the virtal file out of the raw decrypted)

-b (apply changes in a virtual File to a raw decrypted (checksums are not fixed)) (untested)

-f (fix all checksums that are not in the virtual file) (untested)

 

[Sebiroth]

Can I use the software together with the new NDS XPloder?

 

[CollosalPokemon]

Can I use the software together with the new NDS XPloder?

Can you backup your retail 3DS cart's save files with NDS XPloader? (I'm not familiar with it)

If you can, yes.

If you can't, then no.

 

[Immortal_no1]

ichichfly, i think i have a hardware challenge to you.

You have a Cyclone II FPGA Starter Development Kit right? it's what you wrote in your topic.

Do you have the ability to create a simple Passthrough for the EEPROM data from a 3DS cart?

I'm starting to have a look at the hardware hopefully i will see a list of requests from the EEPROM lines with locations and data. It's just a thought, but it should work, ibut i thinki i need a faster board than my AVR Minimus. Was only a cheap Fiver, but did what i originally needed it to. Otherwise i;ll look at getting a Atmel Dragon board, lots of pinouts, and i'll make a complete passthrough for it as i think the response time for the 3ds cartridge is a lot faster than that of the DS

I'm thinking that may be the best way to get the locations of the data used in the next CRC's

 

[ichichfly]

ichichfly, i think i have a hardware challenge to you.

You have a Cyclone II FPGA Starter Development Kit right? it's what you wrote in your topic.

Do you have the ability to create a simple Passthrough for the EEPROM data from a 3DS cart?

I'm starting to have a look at the hardware hopefully i will see a list of requests from the EEPROM lines with locations and data. It's just a thought, but it should work, ibut i thinki i need a faster board than my AVR Minimus. Was only a cheap Fiver, but did what i originally needed it to. Otherwise i;ll look at getting a Atmel Dragon board, lots of pinouts, and i'll make a complete passthrough for it as i think the response time for the 3ds cartridge is a lot faster than that of the DS

I'm thinking that may be the best way to get the locations of the data used in the next CRC's

both SPI(EEPROM) and ROM transfers have a maximal speed of 16.6MHz.

ADD: Do you know if 4 bit wide transmission or only SO/SI is used for SPI (the EEPROM) in the 3ds cards?

 

[lazymarek]

Can we use your 3dssaveresorter to make modified savegames which are not corrupted?
Is this the correct sythax for it:

-f

?

 

[Immortal_no1]

Can we use your 3dssaveresorter to make modified savegames which are not corrupted?
Is this the correct sythax for it:

-f

?

Currently No we can't make saves which are not corrupted.

Fixing the header data was a must and now can be done.

According to what i can see there's still the CRC in the DISA block and also the CRC at the bottom of the DPFS block.

We know how to create the CRC for the DISA block, however we don't know how the data within the DISA block relates to the data in the Save areas.
As far as i know we don't have a solution for finding the DPFS CRC...

A diff between saves shows that the data in the DISA and DIFI and DPFS blocks is the same it's just the 0x10 bytes at the start of the 0x1000 sized block and the CRC's that differ.

Correct me if i'm wrong ichichfly?

Where would you like to start? the 0x10 byte CRC at the top?

 

[lazymarek]

Currently No we can't make saves which are not corrupted.

Fixing the header data was a must and now can be done.

According to what i can see there's still the CRC in the DISA block and also the CRC at the bottom of the DPFS block.

We know how to create the CRC for the DISA block, however we don't know how the data within the DISA block relates to the data in the Save areas.
As far as i know we don't have a solution for finding the DPFS CRC...

I think the 3DS doesn't check them?

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

 

[Immortal_no1]

I know that much, but there are 2 hashes in the DISA block, one at the top and one at the bottom. the one at the bottom is a SHA-256 based hash, however the one at the top is only 16 bytes long, which could be a SHA-1 or MD5 but we don't know the data that it hashes to be sure.


Just a simple score change i made generated a corrupted save. Here's some info i've been looking at for a little while now:

Save2-BBBBBBBB.sav

Score - 75060 - 342501
Name: - BBBBBBBB - 0202020202020202

hash at 15000
337F791C9F2B628267754F41A1313540 - Need to find how this is generated

DISA hash at 1516C
251F10AB3C348FD6ED829BAE08D3091B294A26CB6DF57D8F6A26CBC570CE6EEC
DPFS hash at 1543C
0C77000486499699E8D320424CE9800F5DEE1E72EE379428FEBA1A9B646394B2 - DPFS has is the same at 1543C & 1943C
DPFS hash at 1943C
0C77000486499699E8D320424CE9800F5DEE1E72EE379428FEBA1A9B646394B2 - DPFS has is the same at 1543C & 1943C

hash at 1C000
EC6272813A4058555358B8F42F4D1E6BF6B9540BB2EC9D565B0C6FF55DE7EA47 - Need to find how this is generated. (created when data is initialized prior to playing the game)
3F2523978999A708BE6979DB13B83D7EDF6BA357C802FC2DF126EA8AF65E8C93 - Need to find how this is generated. (created when data is initialized prior to playing the game)
B4D67710799DBEE0CEA47D2F2AAF416C662781CD8C5A086E71F2FE2B10A10BD3 - same in all saves
E31D263B9F3F125A1F42DBB142D33191E1120B3F50620E9EBFEC10233D4919D5 - hash of 8000-8FFF

The Hash at the end of DISA is from 6200 - 632B = 0x12C this is a SHA-256
970F122AB7A5CCC791AF2C0772A214D879279C4D22FBC921EF6A7B3F4A890D89


Save3-CCCCCCCC.sav

Score - 75292 - 1C2601
Name: CCCCCCCC - 0303030303030303

hash at 15000
CFD812527BDA7B981D08AEBC59F30E04 - Need to find how this is generated.

DISA hash at 1516C
982F00F30B814149B5A466C8A3D7F93CB52F5AAF515985A15E93456AF1FF918E
DPFS hash at 1543C
A0E90E3BBF299B05544ECFF788EB235377E43A02D84827B744D049B1AB909861 - DPFS has is the same at 1543C & 1943C
DPFS hash at 1943C
A0E90E3BBF299B05544ECFF788EB235377E43A02D84827B744D049B1AB909861 - DPFS has is the same at 1543C & 1943C

hash at 1C000
E17676A07D8B15FE761514D3F400E4421CB8A2A59B3039EB41648EF5DA3623F2 - Need to find how this is generated. (created when data is initialized prior to playing the game)
A5641389F657F4599F59C870EEB60429C0502DDEB21C2FFCA5260132A4DD66AC - Need to find how this is generated. (created when data is initialized prior to playing the game)
B4D67710799DBEE0CEA47D2F2AAF416C662781CD8C5A086E71F2FE2B10A10BD3 - same in all saves
098E0450538E9EDDB618729102712CC0F61C035F2CA48BB4B5BE9F04CE2A4115 - hash of 8000-8FFF

The Hash at the end of DISA is from 6200 - 632B = 0x12C this is a SHA-256
970F122AB7A5CCC791AF2C0772A214D879279C4D22FBC921EF6A7B3F4A890D89

I don't know how useful it will be to the trolls out there but ichichfly you may be able to use it for something. It's nothing that we don't already know though i don't think.

 

[Arisotura]

If by 'DPFS CRC' you mean the last 4 bytes in the DIFI blocks, the 3dbrew page says that they are garbage and appear as FF FF FF FF in an encrypted save.

Also there's no CRC in the DISA block, did you mean the hash? Those aren't the same.

 

[Immortal_no1]

If by 'DPFS CRC' you mean the last 4 bytes in the DIFI blocks, the 3dbrew page says that they are garbage and appear as FF FF FF FF in an encrypted save.

Also there's no CRC in the DISA block, did you mean the hash? Those aren't the same.

That much i do know, in fact i think it may even have been me who put up that information on 3dsbrew.

At the bottom of the DPFS block, there is a large block of data the first 0x20 bytes of that is the CRC, the rest of that is garbage you get from the XOR process to get the decrypted save.

 

[ichichfly]

I know that much, but there are 2 hashes in the DISA block, one at the top and one at the bottom. the one at the bottom is a SHA-256 based hash, however the one at the top is only 16 bytes long, which could be a SHA-1 or MD5 but we don't know the data that it hashes to be sure.


Just a simple score change i made generated a corrupted save. Here's some info i've been looking at for a little while now:

Save2-BBBBBBBB.sav

Score - 75060 - 342501
Name: - BBBBBBBB - 0202020202020202

hash at 15000
337F791C9F2B628267754F41A1313540 - Need to find how this is generated

DISA hash at 1516C
251F10AB3C348FD6ED829BAE08D3091B294A26CB6DF57D8F6A26CBC570CE6EEC
DPFS hash at 1543C
0C77000486499699E8D320424CE9800F5DEE1E72EE379428FEBA1A9B646394B2 - DPFS has is the same at 1543C & 1943C
DPFS hash at 1943C
0C77000486499699E8D320424CE9800F5DEE1E72EE379428FEBA1A9B646394B2 - DPFS has is the same at 1543C & 1943C

hash at 1C000
EC6272813A4058555358B8F42F4D1E6BF6B9540BB2EC9D565B0C6FF55DE7EA47 - Need to find how this is generated. (created when data is initialized prior to playing the game)
3F2523978999A708BE6979DB13B83D7EDF6BA357C802FC2DF126EA8AF65E8C93 - Need to find how this is generated. (created when data is initialized prior to playing the game)
B4D67710799DBEE0CEA47D2F2AAF416C662781CD8C5A086E71F2FE2B10A10BD3 - same in all saves
E31D263B9F3F125A1F42DBB142D33191E1120B3F50620E9EBFEC10233D4919D5 - hash of 8000-8FFF

The Hash at the end of DISA is from 6200 - 632B = 0x12C this is a SHA-256
970F122AB7A5CCC791AF2C0772A214D879279C4D22FBC921EF6A7B3F4A890D89


Save3-CCCCCCCC.sav

Score - 75292 - 1C2601
Name: CCCCCCCC - 0303030303030303

hash at 15000
CFD812527BDA7B981D08AEBC59F30E04 - Need to find how this is generated.

DISA hash at 1516C
982F00F30B814149B5A466C8A3D7F93CB52F5AAF515985A15E93456AF1FF918E
DPFS hash at 1543C
A0E90E3BBF299B05544ECFF788EB235377E43A02D84827B744D049B1AB909861 - DPFS has is the same at 1543C & 1943C
DPFS hash at 1943C
A0E90E3BBF299B05544ECFF788EB235377E43A02D84827B744D049B1AB909861 - DPFS has is the same at 1543C & 1943C

hash at 1C000
E17676A07D8B15FE761514D3F400E4421CB8A2A59B3039EB41648EF5DA3623F2 - Need to find how this is generated. (created when data is initialized prior to playing the game)
A5641389F657F4599F59C870EEB60429C0502DDEB21C2FFCA5260132A4DD66AC - Need to find how this is generated. (created when data is initialized prior to playing the game)
B4D67710799DBEE0CEA47D2F2AAF416C662781CD8C5A086E71F2FE2B10A10BD3 - same in all saves
098E0450538E9EDDB618729102712CC0F61C035F2CA48BB4B5BE9F04CE2A4115 - hash of 8000-8FFF

The Hash at the end of DISA is from 6200 - 632B = 0x12C this is a SHA-256
970F122AB7A5CCC791AF2C0772A214D879279C4D22FBC921EF6A7B3F4A890D89

I don't know how useful it will be to the trolls out there but ichichfly you may be able to use it for something. It's nothing that we don't already know though i don't think.

in the virtual file I found the following changes

0x0 - 0xF maybe only random data
0x16C sha-256 DISA known
0x43C maybe sha-256 unknown
0x2000 hash tabel first 2 unknown other known

the save data

ADD: update now fix the missing crc that is calculated in some games http://www.mediafire.com/?3zc2o62b8buckzc

 

[Immortal_no1]

I enjoyed the "what the f**k are you doing ???" when you run the common /? help command with your app

"3dssaveresorter.exe /?"

 

[ichichfly]

I enjoyed the "what the f**k are you doing ???" when you run the common /? help command with your app

"3dssaveresorter.exe /?"

http://www.mediafire.com/?vw3uc9q9ec0gctb

Now a better message is used.

 

[lazymarek]

Any progress, Immortal (tutorial, deEncrypter)?
Can you just make a small tutorial about changing all known checksums correctly when we have modified a savegame, please?

 

[Immortal_no1]

i'll try and add something in the next couple of days. I'll try to make it as detailed as i can using what we currently know.

 

[Immortal_no1]

I've written about 95% of the tutorial.

Ichichfly is there a way we can use your app to pass in the modified encrypted file only and have it check and output the corrected modified file?

Such as:

3dssaveresorter.exe -F (enc_mod_file.sav output_enc_mod_file.sav)
Where output_enc_mod_file.sav gets created in the process unless the header CRCs all match?

 

[silentblue1987]

Yes this is the right thread for the unix/linux question. The plaintext was seen on some ninja game savefile way back when. It was referencing a bgm file inside the rom, probably background files for the save menu or something.

I read this entire thread from page 1, but don't bother looking for it. Stay on track, you're leagues ahead of anything I could figure out.

 

[Immortal_no1]

Were you referring to the samurai warriors chronicles BGM reference in the save?

That's the only thing i can think of...