ROM Hack Hacking strings in Etrian Odyssey II save

[eyeball226]

Due to the well known brokenness of the password system used to transfer to Etrian Odyssey II, I have to use another person's password. Although you're given the opportunity to change the guild name to your own, people keep saying 'Oh, you're those guys from *some-other-person's-guild*!'.

I was thinking it should be possible to change the name by hacking the save file but it's not as simple as I was hoping. I had hoped I'd be able to find an ASCII string in a hex editor but it would appear not to be stored that way. Does anyone have any ideas how the string might be encoded?

 

[FAST6191]

Even if it was a simple string (or a lightly compressed one) in the save you would likely also have the checksum to deal with and those can be somewhat custom. Entirely doable but more effort than you want to go in for if you only want a simple name change.

Easier to find the location of the name in the RAM and trying to change that. The only problem will be whether it gets written back when you save (technically it would not have to be but most would find it easier to just dump all the data back into the save and load it back up rather than fetching it piecemeal).

Possible option 2. Figure out how it is encoded in the save password transfer. Can you change guild name on the first game anywhere near the point where you can export the password? Make a few subtle changes and see how it plays out in the resulting password. You can also then use said new passwords to narrow down the RAM location more easily in the sequel (if you have 10 passwords and the only real differences are the name then in the sequel the differences should mainly just be where the name is hiding.

If we have to go deep on the assembly side of things then a custom name tends to take a bit more to think about for the text handler than simply decoding a text file, not much as it is only a simple variable but still more and this can make tracking it down easier. Bonus is you can presumably find the call for a variable (it tends to be obvious if you are reading the script through) and stick it wherever you like in the text if you want to have more chances to follow what it is doing or get it in a better place to analyse things.

 

[eyeball226]

Even if it was a simple string (or a lightly compressed one) in the save you would likely also have the checksum to deal with and those can be somewhat custom. Entirely doable but more effort than you want to go in for if you only want a simple name change.

Argh, I hadn't thought of that.

Easier to find the location of the name in the RAM and trying to change that. The only problem will be whether it gets written back when you save (technically it would not have to be but most would find it easier to just dump all the data back into the save and load it back up rather than fetching it piecemeal).

This is a good idea. I had wondered something similar but I haven't had any luck poking around in the NO$GBA debug version. Even if it doesn't write the guild name every save, it's got to do it at the beginning right? Perhaps the perfect moment to try and edit this in RAM is just after entering the password. Still, I'm lost as to where in there it might be.

Possible option 2. Figure out how it is encoded in the save password transfer. Can you change guild name on the first game anywhere near the point where you can export the password? Make a few subtle changes and see how it plays out in the resulting password. You can also then use said new passwords to narrow down the RAM location more easily in the sequel (if you have 10 passwords and the only real differences are the name then in the sequel the differences should mainly just be where the name is hiding.

Unfortunately you can't change your guild name in the first game at all and you only get the opportunity to export a password after the last boss of the main story. Not only that, but every time you use the password option it seems to generate a new one, even if none of the details encoded have changed. I have seen them repeat, but there seem to be enough that it would be extremely time consuming to make a change and then wait for the password you copied to come round again to see what had changed.

If we have to go deep on the assembly side of things then a custom name tends to take a bit more to think about for the text handler than simply decoding a text file, not much as it is only a simple variable but still more and this can make tracking it down easier. Bonus is you can presumably find the call for a variable (it tends to be obvious if you are reading the script through) and stick it wherever you like in the text if you want to have more chances to follow what it is doing or get it in a better place to analyse things.

Assembly is definitely waaay beyond my extremely meagre abilities. Thanks for taking the time to make such a detailed post but it's becoming increasingly clear how out of my depth I am. Editing it in RAM seems my best bet, but I don't think I have the skills to find it.

 

[FAST6191]

On editing in RAM I neglected to mention that the "dump all user data" part also tends to mean it is just kicked to a section and referenced when needed, see also why when we are looking for firmware settings for language forcing cheats/hacks it will tend to be the other more obvious parts of the firmware data first searched for and then move through that to find the language part. Some games will sort it all out into relevant sections or calculate other things but definitely still worth a look.

What might also work is if the name is referenced twice (your chosen name and the original one). If there are two variables and the devs neglected to account for one then it might be the same before the change. Look then for what changes with the name change and if there is a second segment that was the same as the pre name change segment.

Watching it decode the password in the sequel is not a bad plan.

Pity on the one time password thing. I might have to look at it and see one day but if it counts game time or something as part of it then, and has some kind of embedded checksum of its own then that could make for a fairly big change in resulting passes.

I also neglected to mention you can sometimes break a checksum check in a game such that it accepts the incorrect one (it tends to only be an if - else thing, or a compare and branch in assembly). Usually a bit harder to do than doing the checksum once you know how it works (if it is a simple bytesum of a given area that is easy, and your hex editor may even do it for you) but saves you having to step through the routine to figure it out in the first place and then possibly code it.

Final thing. If you are dumping RAM and comparing it and it is saying [lots of] bytes changed and you reckon that is not getting you where you want you may be right, minor trick though is to do nothing but maybe wait a couple of seconds (let the music play, animations spin...), dump the memory again and then see what changed. What changed there is likely not what you want so you can largely ignore those sections in future passes.

 

[eyeball226]

Thanks, that's all really helpful advice! I'm feeling a bit less despondent about it now, I think I'll have another stab at this after I've recovered from work (which may be tonight or may be the weekend).

 

[eyeball226]

So, I gave up way back when I made this thread but I've returned with renewed vigour (or something).

I know little about hacking save for a bit of hex editing save files in my youth. I know I need to compare before and after snapshots of memory to find the spot I'm looking for, but I have no idea how to go about that, and more crucially I can't work out what to google in order to learn how.

Could someone point me in the right direction, either to a guide or just the right search terms to stick in Google?

 

[FAST6191]

I normally use a higher end hex editor. Hex workshop has a file compare, even a resyncing compare if you need that. Not sure what we are pointing people at as far as free software right now. https://www.guiffy.com/Binary-Diff-Tool.html was high up in a search though and apparently available for free. Most of the time you can do things for free but where a fancy editor is all in one you might have to combine the efforts of a few programs, old but still accurate enough https://gbatemp.net/threads/rom-hacking-hex-editors-mid-2012-discussion.326873/ .

For search times file compare, binary compare, possibly diff and binary diff (as in difference) but you might also get patches/patch making for that one which is less useful (well technically it is very useful but you would then be lumped with figuring out the patch format so best go with a nice GUI tool).

There are some things that might get in the way. Pokemon for instance quite famously cycles between a few spots, partially to avoid writing the same bit all the time and partially so you can have the backup of however long back it was.

Anyway assuming you have an easy route (or can work around it -- figuring out where the saves land is one thing, saving twice to land back on the same spot if it is just the two things cycled between is another) then depending upon what is in the game there will likely be two or three areas that change.
1) The checksum area. If something changes then the checksum changes.
2) Any gameplay time, step counters, save counters and whatever else goes up just for being saved or in the game.
3) The data you want to know about.

Easiest way to eliminate 1) and 2) is save, dump the save, save again and compare. As you changed nothing else then whatever changes when you actually change what you want (harder for names/strings, easier for things like potions or money),

 

[eyeball226]

I normally use a higher end hex editor. Hex workshop has a file compare, even a resyncing compare if you need that. Not sure what we are pointing people at as far as free software right now. https://www.guiffy.com/Binary-Diff-Tool.html was high up in a search though and apparently available for free. Most of the time you can do things for free but where a fancy editor is all in one you might have to combine the efforts of a few programs, old but still accurate enough https://gbatemp.net/threads/rom-hacking-hex-editors-mid-2012-discussion.326873/ .

For search times file compare, binary compare, possibly diff and binary diff (as in difference) but you might also get patches/patch making for that one which is less useful (well technically it is very useful but you would then be lumped with figuring out the patch format so best go with a nice GUI tool).

There are some things that might get in the way. Pokemon for instance quite famously cycles between a few spots, partially to avoid writing the same bit all the time and partially so you can have the backup of however long back it was.

Anyway assuming you have an easy route (or can work around it -- figuring out where the saves land is one thing, saving twice to land back on the same spot if it is just the two things cycled between is another) then depending upon what is in the game there will likely be two or three areas that change.
1) The checksum area. If something changes then the checksum changes.
2) Any gameplay time, step counters, save counters and whatever else goes up just for being saved or in the game.
3) The data you want to know about.

Easiest way to eliminate 1) and 2) is save, dump the save, save again and compare. As you changed nothing else then whatever changes when you actually change what you want (harder for names/strings, easier for things like potions or money),

When I originally made this thread you suggested that it might be difficult to find the string in the save file and that it might be better to look for it while it's loaded in memory.
Is there any facility in no$gba debug to do those differential searches on the memory of the machine or would I have to do a "before" memory dump and an "after" memory dump and then compare them in the hex editor?

Thank you by the way, both for your advice back in 2017 and tonight.

 

[FAST6191]

It is likely not so difficult to find but if you also have to either figure out the hashing method or a means to bypass it then it gets more tricky. Finding it in memory and allowing the game to handle its own hashing/the hashing for you is often far nicer if it is just a thing you want to do for yourself.

Memory compare.
Two main approaches
What do you think cheat search is? Can be annoying to find names and things you can't repeatedly change (there is a reason most cheats are things you can lose or gain endlessly) with this but a careful use of savestates and the "has not changed" search can get things done.

Savestates. Almost by definition they are a copy of the memory. no$gba might compress them but should also have an option somewhere. That said a debug emulator should be able to dump the ARM9 main memory ( http://problemkaputt.de/gbatek.htm#dsmemorymaps ) happily enough.

 

[eyeball226]

It is likely not so difficult to find but if you also have to either figure out the hashing method or a means to bypass it then it gets more tricky. Finding it in memory and allowing the game to handle its own hashing/the hashing for you is often far nicer if it is just a thing you want to do for yourself.

Memory compare.
Two main approaches
What do you think cheat search is? Can be annoying to find names and things you can't repeatedly change (there is a reason most cheats are things you can lose or gain endlessly) with this but a careful use of savestates and the "has not changed" search can get things done.

Savestates. Almost by definition they are a copy of the memory. no$gba might compress them but should also have an option somewhere. That said a debug emulator should be able to dump the ARM9 main memory ( http://problemkaputt.de/gbatek.htm#dsmemorymaps ) happily enough.

Duh, of course. Thank you, yes! It hadn't occurred to me to try using a save state, while I knew that they must contain a dump of the RAM I wasn't sure if it would be a raw dump or what. I'll search through the options to see if there's anything to do with compression or a checksum that might prevent reloading the state.
I had also thought about using a cheat search, but as you say it's not well suited to things that aren't constantly changing. Might be useful to eliminate things like the music engine from my differential search in the hex editor.
Thank you for your patience and willingness to explain what I imagine to be pretty elementary concepts.
I enjoy learning and I really appreciate your help.

 

[FAST6191]

There should not be a checksum in a savestate. Theoretically it could happen and maybe for high end network/virtual machine type things there might be one but for simple low memory systems in a basic emulator then no as enough people do savestate editing that it would only really serve to frustrate them. Likewise there could be some anti cheat within the game but that is unlikely to bother this.

Savestates might change between emulators (some might use one section before another, or pad something out) and the "almost" part of the earlier line was remembering that DS flash carts can't read the 3d memory so they just guess/ignore it and thus technically aren't a full copy of memory, whatever emulator or flash cart you use though then all the good stuff is there.

Cheat search wise. If you make a savestate before you enter it then you can search just after, exhaust whatever searches you have, restore beforehand and do another search. You can try searching as you enter it but they are not always the same thing as what will land in the final game (it is a way people sometimes use to find out how text is handled) and you might find you just spent your time finding where the text input box stores its data (which can have its own perks as you might be able to enter valid data but data not available on whatever keyboard it provides you, though same should be possible if you find where it actually is in the game).

Edit.
Forgot to also give another possible shortcut.
If you find the text in the save (see methods in an earlier post) then while you might not be able to change it in the save without figuring out the hash/bypassing the hash check then you could still find the same data in RAM and change that -- most saves just amount to what is essentially a small memory dump and restore later, especially on the DS where space is not at such a premium as the NES or something.

 

[eyeball226]

Ok, I found the option in no$gba to save states uncompressed/raw and have a few snapshots at different points.
When I compare then in guiffy it throws up a java.lang.NegativeArraySizeException. It then proceeds to compare them, but it seems to think the second file is quite a bit smaller (which obviously it isn't).
I'm going to see if I can find another free compare tool.

Meanwhile, I have a sort of lead on how the text might be encoded.
https://forums.exophase.com/threads/guide-etrian-odyssey-ii-us-rom-hacking.13150/

Unfortunately, the link to the table image is dead. Does anyone recognise that scheme?

EDIT: Seems pretty simple actually, it's just -31 to the ASCII number of that character. I was assuming it would be something harder!