ROM Hack Disable save game on Kingdom Hearts on boot

[mte90]

I am using my same tool https://gbatemp.net/threads/gbaatm-rebirth-gba-auto-trainer-maker-a-new-hope.564321/ to patch the GBA rom.
The point is that after you pick the language the savegame is changed also if it is on boot, so there are no new stuff to save. This create issue with the cheat trainer because start before the game, values changed and the savegame is different. The problem happening it is that is moving back the story to the previous finished castle/campaign/call as you want.
SO my idea was to disable this savegame on boot and see if creates some problems in the game, in this way I can use the cheat but not loose anything that I unlocked during the game.
Anyone has some suggestions? Usually gba hacking guides explains how to change a value in the memory but not this kind of code so I am open to any suggestions.

 

[FAST6191]

If it is just for you I would back up the game save and copy it to a new ROM (hopefully your flash cart is a name using cart rather than a game serial, though GBATA can probably fix a header if you do fancy changing it).

If you want to disable it properly.
If it is right at the start of the game then set a break on write to the save section in no$gba or whatever debugger you are using.
Should be easy enough to go back from there and NOP that particular save attempt but leave the rest intact.
Alternatively if you can find the "this language selected" value in RAM you can set a break on write to that and figure out what is changing it and disable any save interaction from that.
You can also trigger a break on read for a button read but I am not a great fan of that.

 

[ghjfdtg]

What is even the problem? The first post is a bit hard to decipher.

 

[mte90]

What is even the problem? The first post is a bit hard to decipher.

Sorry for the issue. The problem it is that as a cheat trainer is starting before the game, change some values in memory, the game execute a savegame on boot always (also if doesn't make so much sense) and breaks few things like the story progress and other things.
So my idea was to remove this save at boot in the rom so I can play nicely.

If it is just for you I would back up the game save and copy it to a new ROM (hopefully your flash cart is a name using cart rather than a game serial, though GBATA can probably fix a header if you do fancy changing it).

If you want to disable it properly.
If it is right at the start of the game then set a break on write to the save section in no$gba or whatever debugger you are using.
Should be easy enough to go back from there and NOP that particular save attempt but leave the rest intact.
Alternatively if you can find the "this language selected" value in RAM you can set a break on write to that and figure out what is changing it and disable any save interaction from that.
You can also trigger a break on read for a button read but I am not a great fan of that.

I am using on the real GBA, (I have the backup of course) but the hint to look for language address memory is not a bad idea after all. I am looking to find a good debugger on Linux (no$gba require to run with wine and I don't like that idea, mgba doesn't have yet a nice debugger).
Looking at my dev experience I was thinking to decompile the rom and look in the code for the command that save (I guess there is a specific assembly command) and remove the code that execute at start (and rebuild the rom), so I don't need any look in the memory address.

 

[FAST6191]

For ROM hacking for real I normally just bit the bullet and go to Windows (be it a VM or an old laptop of something). If nothing else too much stuff is written in old versions of VB that are a nightmare to get working on modern Windows or even a fresh install of XP or something, and Wine... it makes it cry really.

I have a version of ndstool and a hex editor on Linux that I use for that sort of thing to give basic assessments of file formats and the like but anything particularly exotic is a Windows job.

There might well be some kind person that compiled something like vba-sdl-h (it is all command line but feature wise it will match no$gba) for Linux but I have not checked and don't know where you might find it today. Don't know what goes for the versions of VBA that support the gdb debugger stuff (I tend to avoid that one entirely).

Anyway I think I might have misread the original post.
Normally when people want enable/disable cheats it is to enable or disable them according to their whims (usually something like disable random battles for a while but enable them again later, or "just so I can get past this section") but second to that is to dodge issues with say the game using a section of memory for a minigame/opening logo/whatever else it wants to do that is not the main game and crashing as a result.
Is that what you have here, albeit a more subtle version? If so there are plenty of options for "press this for full health" rather than infinite health all the time style of things.
http://www.bsfree.org/hack/hacking_gba.html

"to decompile the rom... (and rebuild the rom)"
While many GBA games were written mostly in C with only inline assembly such that decompile is a sensible term that is still not something we really do. Even getting a disassembly to the point where you can usefully assemble it again into a working ROM it is a feat that maybe only a pokemon game that hackers spent years on get anywhere with.
There are some nice assemblers you can tell to inject code/assemble code for a given memory location, though here I imagine you will mostly just be NOPing a section to skip a save grab/read/check/write/whatever.

 

[mte90]

After starting this thread I investigate a bit disassembling and is not easy so much, but for me it is enough to get the assembly and repacking. In this way it will be more simple than patch the binary rom, at least for me. Because it will be enough to look for the commands that save game and disable the subroutine call on boot, but maybe is my mindset as developer talking it in this way. I guess that the assembly command to save it is very specific so with a search it is easy to spot.
Anyway I will try with those emulators and see how it is the debugger.

In my case abut cheats is more like that this rom at starting save again the savegame and doesn't make so much sense and this create issues with cheats as strange effect that corrupt it.

 

[FAST6191]

So basically dodging an autosave when you played with cheats to avoid issues when playing for real again (drop a save before you play kill everybody in the town and then load back as if nothing ever happened). For that I would probably back up a save or spin off a copy and play that.

You can make a static disassembly easily enough (be warned you will have two of the things -- ARM and Thumb modes remember) and if it occurs that early in the boot sequence you might even be able to hand run the code to get there, or at least open up the text find and try some obvious choices for memory locations and types of commands.
If you have full fat IDA (free is X86 only) then it will have one, crystaltile2 can also do it, various debugging emulators will spit something out, not sure what I am suggesting for a standalone static GBA one these days (think ndsdis2 but for GBA) and I imagine most of the standalone ones (if say radare2 or https://ghidra-sre.org/ has something, or even just the options from GCC) will not have nice GBA additions to tell you what is a SWI call or have some of the basic fixed memory locations taken as standard that all the rest will.

I get wanting to have a nice potentially commented full disassembly in front of you, and if you can get such a thing then great, but that is years of active effort (pretty much only pokemon on the GBA), a leak or other release of code. Most hackers however figure out roughly where they want to be looking either by finding a cheat or having some breakpoints or other fancy feature from a debugger (for the NES but an example of some of the things available https://tasvideos.github.io/fceux/web/help/fceux.html?CodeDataLogger.html , can also do an elimination approach https://tasvideos.github.io/fceux/web/help/fceux.html?TraceLogger.html ) guide them in. Staring at a basic machine made dump of a blind disassembly gets very old, very fast.

 

[hippy dave]

As far as I know (claiming no expertise, been doing gba dev for all of a few weeks), the only way to perform a save action is to write to the relevant memory region, and there don't seem to be any SWI calls to handle this so it must happen directly in the game's code. Of course it might be in a reusable subroutine rather than smack in the middle of the startup code, but should still be helpful to track it down.

So look for writes to these addresses:

0E000000-0E00FFFF   Game Pak SRAM    (max 64 KBytes) - 8bit Bus width

(courtesy of the ubiquitous GBATEK)

...you could search a disassembly listing, or set a breakpoint in an emulator with debugger (no$gba was always a popular option afaik).


edit: I've just realised this might only be relevant to sram save type, and I dunno what the kingdom heart game uses.

I was looking at the source code of Chishm's SendSave recently for an example of writing to sram, but it also handles the other types. Also has these memory defines for them...

#define EEPROM_ADDRESS (volatile u16*)0xD000000 

#define SRAM_ADDRESS (volatile u16*)0x0E000000

#define FLASH_1M_ADDRESS (volatile u16*)0x09FE0000

 

[mte90]

I am investigating and do a new savegame when the Load button is pressed.
I am trying VBA-M because Mgba as debugger is not very friendly.

I see that the savegame as KHCOM_BACKUP_VER00000013 this string that is the same in the rom. If I change this string the rom will not found any savegame.
Probably it is used to verify what savegame to load during the development of the game itself.

Anyway I can find various mention of that in the memory, 3 are part of my savegame but there are others also in the memory address shared above.
https://i.imgur.com/rdtEzPD.png

 

[mte90]

I found a way using emulator to get a savegame with cheats enabled.
Basically I disable the write permission to the savegame on boot, re-add them when I want to save the game after boot.

So I investigated a bit more and seems that a savegame by everdrive is the problem of broken savegame, if I open the game with the savegame everything is fine. If I open again it is broken.
This happen with the clean rom and the savegame copied by everdrive.
Happens on Mgba and VBA so maybe the srm is different from sav for specific things.
EDIT: Happens also on everdrive the same issue, so probably the game has some checks about the savegame if it is mainpulated.

 

[mte90]

Finally I understood the issue.
I was applying cheats to see if everything was fine, save and reboot the game. On rebooting when I saw the values changed I close the game without save again.
This is the issue.

Looking with debugger I saw that those memory address are empty, so the game is moved back to the status of the previous savegame. In this way I was thinking that is broken the savegame but instead the game expect that if I turn off the game to save.

So basically with this game you need to save if you want to turn off also if you don't care or the savegame will be move back to the previous savegame itself on a different place, history state and so on.