ROM Hack NDS Save Hacking Help

[Wellington2k]

Hey.

I need help hacking a save game of New Super Mario Bros.

I tried loading it in a hex editor, but I got random junk.

So I converted it to raw format, still got junk in the hex editor.

I'm using Hex Workshop.

All I want is to change the point number count to 99999999.

Any help, I know it's possible.

 

[Gericom]

Save file hacking is very difficult, I tried in mkds some time ago but I didn't got something out of it.

 

[Wellington2k]

Really?

I though I'd just have to convert it to it's raw format, then just find the variable.

Is there a link that I can go to for help?

 

[Dirbaio]

I'vw never tried save hacking, but from what I know, it's quire hard. You'd have to find it somehow, then edit it. Also, NSMB saves are somehow protected/checksummed. If you modify something, NSMB gives a corrupt save warning, and it erases it all. So that checksum'd need to be cracked too.

The way to go to do that is either use an Action Replay code, or do some RAM searching in desmume to get max score in-game and then save.

 

[Wellington2k]

See, the reason behind this is that I won a USB R4i SaveDongle from r4i-sdhc.com.

I wanted to hack a save extracted from one of my NDS games then put it back in.

Show my friends and they'll wonder how I got so many points.

 

[Gericom]

It would be nice if we could hack the saves. Also at mkds. But what I found at mkds is that a piece at the beginning always change if you change something. And if you copy and reïnsert, the settings are back. But there aren't any values that are the same.

 

[Poryhack]

Save file hacking is very difficult, I tried in mkds some time ago but I didn't got something out of it.

I have to disagree with you here. Unless the save file is encrypted its a pretty straightforward affair; just time-consuming more than anything. Checksums are largely standard so you can find algorithms to fix them online assuming you can figure out what block of data it's calculated from. The rest is solely tweaking one variable at a time in game and noting the offsets where there are changes.

EDIT: Apparently the DS has a BIOS function for calculating CRC16, a commonly used checksum algorithm. I would guess that many games use this.

EDIT2: I guess pokemon is significantly more complicated than I thought but I don't know about other games.

 

[Wellington2k]

Save file hacking is very difficult, I tried in mkds some time ago but I didn't got something out of it.

I have to disagree with you here. Unless the save file is encrypted its a pretty straightforward affair; just time-consuming more than anything. Checksums are largely standard so you can find algorithms to fix them online assuming you can figure out what block of data it's calculated from. The rest is solely tweaking one variable at a time in game and noting the offsets where there are changes.

EDIT: Apparently the DS has a BIOS function for calculating CRC16, a commonly used checksum algorithm. I would guess that many games use this.

EDIT2: I guess pokemon is significantly more complicated than I thought but I don't know about other games.

Have you had any luck?

 

[Auryn]

it look simple but it's not.
Find your values is easy and already found them
The problem is that each save is mirrored and have an own checksum that doesn't seem to be CRC16.
I give you what I got so that maybe somebody can try to finish this but I am too tired...almost 24 hours up...sorry.

@x00: unknow (maybe mini games save data?)
2 bytes: checksum (apparently only for this block)
8 bytes: Mario2d
4 bytes: 9000
1 byte: (used or not flag)
rest null
last 4 bytes: 00 or FF (didn't found out yet what they mean)

@x100: save 1 data
2 bytes: checksum (maybe connected with the 4 bytes above?? but only for this block
8 bytes: Mario 2d
4 bytes: 7000
1 byte: flag. 00 if not used / 01 if used
The various C0/D0 seem to be the alternate pathway or houses unlocked.
@x11E: Wellingtons points in little endian form so it should be (reading on a hex editor FF0EF505)
If i didn't make a mistake, the checksum start from this point till x351 (yes, the last 00 byte is out of range) but need confirmation.
rest is FF

@x380: save 2
same format as save 1

@x600: save 3
same format as save 1

@x880: unknow (maybe Mario vs Luigi save data??)
2 bytes: checksum (probably only for this block)
8 bytes: Mario 2d
4 bytes: 3000
1 byte: 01 seems always activated and full of FF

@x1000:
everything described above is mirrored starting from here.

Good luck

 

[Gericom]

>>Auryn Can you also take a look at the save files of mkds?

 

[Wellington2k]

Thanks Auyrn!

I'll try this once I get my SaveDongle!

 

[Auryn]

@Gericom: Lately I am busy alot but i did take a quick look. It's much harder because it's compressed or crypted and again it's mirrored later in the save.
Did you ever try to use cheat codes and see if the modified values get stored??

If there is a copy of the savegame in ram, it's probably possible to trace back to the compression/cryption routine and if you are really lucky, there is even a version that is not compressed/crypted in the ram but that is high level hacking.

What you could try to do is to search for values in a ram dump of Desmune and see if you find (example) the number of cups won in a location that is not at the same as a cheat code. If you find some and the cheats codes values are not saved and more values are one near the other are found in the same spot in ram, maybe you found the uncompressed/uncrypted version of the save in the ram (it's really a long shot) but worth a try.



@Wellington: That is still not the solution, more check need to be done.
First there is need to find out what the game does if one of the 2 copies of the save is corrupt:
1)will it just take the good one and play normally and overwrite both saves next time it saves.
2)or already block you on start up.

Case 1: This is what made me unsure about the data that is within checksum range. To test this you need to nullify (or FF) one of the 2 blocks of save 1 (as example). and reload the game. If it still accept it then you need to always change 1 byte within the other block and reload the game.
If it stops you, then you modified a byte that is a checksum or inside the checksum range. Like this you should find the first and the last byte in the checksum range. When you found this, you can start to try to figure out what kind of checksum it is.
My tip is to use Hex workshop, mark those bytes in range and from the tool menu "checksum", it will give a table with many kind of checksum, if one is the same as the one in the save game...you have free hand to change what you want now

Case 2: the game not only check the checksum but checks if the 2 copies of the game are identical. Basically this change nothing apart that make you do the same work as case1 but 2 times in the 2 saves.

 

[Wellington2k]

Hmmm...

I even tried getting another save game with all points (So as to see if there is a difference) and it crashes it.

 

[Auryn]

I was wondering what is the ultimate goal of this that you are trying to do because what you trying to do can be done in less than a min with a cheat code.

Anyway 3 things:
-A correction of the data above, the checksum range seem to start from the M of Mario for each block
-the 2 save games don't have to be identical (tried by nullifying a save)
-by taking a look at the arm9 I found out what the 5 savegames block are and I wasn't off by much

.T.h.i.s. .s.a.v.e.d. .d.a.t.a. .h.a.s. .b.e.e.n.
.c.o.r.r.u.p.t.e.d. .a.n.d. .m.u.s.t. .b.e. .e.r.a.s.e.d...
[.F.i.l.e. .1.]...[.F.i.l.e. .2.]...[.F.i.l.e. .3.]...[.M.i.n.i.g.a.m.e.s.]...
A.l.l. .s.a.v.e.d. .d.a.t.a. .h.a.s. .b.e.e.n.
.c.o.r.r.u.p.t.e.d. .a.n.d. .m.u.s.t. .b.e.
.e.r.a.s.e.d.....
T.h.e. .s.a.v.e.d. .O.p.t.i.o.n.s. .d.a.t.a. .h.a.s.
.b.e.e.n. .c.o.r.r.u.p.t.e.d. .a.n.d. .m.u.s.t. .b.e.
.e.r.a.s.e.d.

So there are the options save, 3 savegames and the mini games save.
This confirms my analisis of the save games and the different checksums for each save game block.