Hacking Hacking with 3DS Save DeEncrypter

[Immortal_no1]

First main draft of the Rre-CRC of a save complete. you can pick it up here:

Game Save ReCRC.pdf

Name: Game Save ReCRC.pdf
Size: 561,220 bytes
SHA-256 fb53816337a268ed95373cbff179d50eac35fbd6a032f94e94f321d4ab1b8a30
MD5 71e1c299dfa67550b918b04d92383e72

Let me know if it needs to be changed in any way. It's rather technical but that's the point.

I have re-uploaded my XOR app which you can find here:
XOR APP Download

Also Included Link to MonkeyBall 3D CRC Test Files.rar
MonkeyBall 3D CRC Test Files.rar

 

[Immortal_no1]

Since the saves that can now be generated are still appearing as corrupted, there are only 3 other areas which i have mapped which may make the difference.
Super MonkeyBall 3D - Save3-CCCCCCCC
The 0x10 bytes at 0x15000 "CFD812527BDA7B981D08AEBC59F30E04"

The 0x20 bytes at 0x1543C "A0E90E3BBF299B05544ECFF788EB235377E43A02D84827B744D049B1AB909861"
The 0x20 bytes at 0x1944C "A0E90E3BBF299B05544ECFF788EB235377E43A02D84827B744D049B1AB909861"

The 0x20 bytes at 0x1C000 "E17676A07D8B15FE761514D3F400E4421CB8A2A59B3039EB41648EF5DA3623F2"
The 0x20 bytes at 0x1C020 "A5641389F657F4599F59C870EEB60429C0502DDEB21C2FFCA5260132A4DD66AC"

I think the next thing to do would be to mod one of the saves name and score in the data block 0x8000 to the same as another save. Perform the CRC and fix the header.
At this point the Save is corrupted, so we then replace the CRC at 0x15000 with the one from the file we're trying to recreate and fix the header.

If thats a no go then revert back to the file before that change and swap the CRC data at 0x1543C and 0x1944C with the data from the other save, rebuild the header and retest if that works.
If thats a no go then revert back to the file before that change and swap the CRC data at 0x1C000 with the data from the other save, rebuild the header and retest if that works.
If thats a no go then revert back to the file before that change and swap the CRC data at 0x1C020 with the data from the other save, rebuild the header and retest if that works.

If that doesn't work then i guess that we have to put it all in. But at the point the save data will be identical and WILL work.

At least this way we can tell which of the CRC's that we have left need to be changed, then we can start to focus on that one.

If both of them need to be changed then we'll focus on whichever one looks to be the most promising first.

Any Objections/ ideas for this?

 

[ItsMetaKnight]

This tool includes malware, my antivirus says.

 

[Immortal_no1]

This tool includes malware, my antivirus says.

Which tool and what antivirus? The XOR app?

I'll scan them again. I scanned them beforehand.

My McAfee shows no issues. I can't see how it can see it as malware, it doesn't rely on any external processes.

 

[how_do_i_do_that]

VirusTotal Scan: here


He likely has either one of the following AV scanners:
AntiVir
McAfee-GW-Edition
Sophos
SUPERAntiSpyware

 

[Immortal_no1]

VirusTotal Scan: here


He likely has either one of the following AV scanners:
AntiVir
McAfee-GW-Edition
Sophos
SUPERAntiSpyware

Good job, i can tell you it's clean. There's a possibility that it's mistaking the XOR function as a suspicious heuristic form, but that would mean that the malware scanner really should be updated to overlook this.

If people are bothered by the false positives then you can do the XOR manually or use microsoft's Calc application.

Just put it in Programmers mode -> View Programmer
then select Hex input
Then put in your Input Value -> say 21
then press the Xor button
then put in the Xor Value -> say CC
then press =
you will get the value ED

Think i have gotten to the bottom of the False positive issue, It's to do with the EXE packer that i'm using to shrink the size of the EXE. The way the packer packs the data (heuristic) is being reported as malware. There is no problem with the EXE in any way shape or form.

 

[ichichfly]

Can someone please test this MonkeyBall 3D save http://www.mediafire.com/?apa6444jj67748y

 

[Immortal_no1]

Can someone please test this MonkeyBall 3D save http://www.mediafire.com/?apa6444jj67748y

Tested and it didn't show corruption, what changes have been made to this?

 

[lazymarek]

wow, can you make not corrupted savegames? Can you post a tut or tell us how you have done this!?

 

[Immortal_no1]

wow, can you make not corrupted savegames? Can you post a tut or tell us how you have done this!?

Let Ichichfly explain a little more first, don't jump to conclusions. I say this because all the game saves the i put up had score information, however the file which i just tested had no score information as though it was fresh. just wait.

 

[ichichfly]

It was yust a check if the first bytes (virtual File) are realy a checksum. No they are not so only 2 arears can contain the checksums we need the one at the start of the hash tabel (0x40 byte) and the one in the DIFI (0x20 byte)

 

[Immortal_no1]

Right, i diffed the files, yes i can see the 1 byte change to the 0x10 bytes at 0x15000 and i can see the change of the header byte too. So you used the Save1-AAAAAAAA.sav as your base.

Here is the dilemma:
Tested Save1-AAAAAAAA.sav and score in 1st place is my score.
Tested raw.bin and the score is set to AiAi 15000, so it would appear then although the game didn't show corruption, it may have jumped to the backup copy of the save data.

So the first thought of it being a CRC still may be correct, it just doesn't cause the game to re-initialize the data on startup.

 

[Immortal_no1]

Right, The last few checksums to be recalculated are hard, none of my test apps have so far found them, my apps are still working away trying to find them but it ay take a while if they are found ata all.

I have created 4 save files there is only a 1 byte difference in all the files. The checksums that you see are qhat you get from having a 1 byte data difference. The checksums in the header change because the checksums through the file change. This suggests that the all the checksums either include the header data as part of their data check or they include the other checksums as part of their check, otherwise some of the checksums would be the same.

The file can be downloaded here:
Download Me

Hopefully someone can use this information for some good.

 

[Immortal_no1]

Another month has passed by and still no more progress has been made on finding out what the other hashes are. It is suspected that the first 2 hashes in the hash table (for 128k gamesaves) are to do with the SAVE partitions, i beleive that there are more hashes in gamesaves of 512k.

I have modified my test apps to test for endian issues and reverse byte checksums, so far.... Nothing.

I'm running out of ideas.

If the Crown3DS is released soon i hope that it will help in finding what these hashes are.

If anyone has any ideas on how the checksums may be calculated post it here so we can look into it. my computers have been running 24/7 for the last few weeks trying to figure it out. It's possible that the hashes may have a prefix of some other information like the MAC address, this hasn't been looked into yet, if someone feels like trying it out... go for it.

I still have to listed to TempTalk ep4 - 11-Oct-2011 to hear what was said about piracy, but there may be something that was said that will spark an idea.

 

[elisherer]

I also made a program that checked every possible hash in the file (every block size possible from every offset),
It checked SHA-256 because the hashes were 32bytes... still no success!
I'm afraid they are using some 'salt' (an extra piece of data to hash with the information to make the hash completely different).
If that's the case then we can't find it.
You can use 3dsexplorer to see where the hashes at and what size are they (it is typically 2 and they are both 32 bytes) It's in the IVFC of the SAVE partition and the DATA partition...

 

[Immortal_no1]

The one which i made checks every possible combination from every offset,

SHA-256 of byte 0, byte 1, byte 2, etc
increments number of bytes to check by 1 after it completes, then checks bytes 0+1, then 1+2
all the time checking the has i'm looking for as a standard value also as a flipped endian WORD .
loops until all combinations are complete,
Once all is complete it flips the endian of the file by WORD and restarts the scan.
Once that completes it reverses the file and repeats both of the previous searches.

Takes a loooong time to complete. Every possible combination is attempted.
This is currently running on both of the decrypted and encrypted files.

It finds all of the hashes that we know of but I was hoping that it would have found others that we don't know yet.

I'll have a look at you source and see if it's faster than my implementation, if it is then i'll modify yours and see if that can find anything.

 

[elisherer]

I'm working on a more optimized solution for brute force...it's not in the app (you can see the 'super brute force' I wrote in the code, but its quite slow).
I'll commit the update as soon as i'm done..

 

[Immortal_no1]

I'm working on a more optimized solution for brute force...it's not in the app (you can see the 'super brute force' I wrote in the code, but its quite slow).
I'll commit the update as soon as i'm done..

Sounds good, looking forward to it.

 

[elisherer]

I commited the new hash tool but it's rather slow...see the source to change it if you want...
(still no version...download the exe from the bin directory)

 

[GamecraftAdmin]

How about hacking the extra data of one of the free apps like nintendo video with this knowledge this way you should have easier access