Hacking ROM Hack Question about finding cheats

[jackfavvv]

So lets say I found a health cheat. However, the cheat isn't permanent because its address changes everytime I reset the system.
Any suggestions?

 

[FAST6191]

This is what is called pointer cheats. The Switch does also feature something called ASLR (address space layout randomisation, a security measure that jumbles up memory at operating system level so things are not in a predictable location to attack) but most search options if done properly should bypass that/handle it for you.

In days of old when programmers all had long grey beards and manipulated the very smallest of aspects then yeah addresses were fixed unless said grey beards did it as a measure of anti cheat.
However grey beards are expensive and you would rather employ the 23 year old spotty oik to make your games instead. Fortunately computing power increased and that opened up compiled languages, which also have perks for the grey beards too.

Compiled languages don't have to have a human mind keep track of what memory is used, initialised, can give it back when not in use (though failure to do that is what memory leaks are) and more to allow more to happen with the program/computer keeping track of where things are at (indeed some view memory location being handled by humans vs by the compiler as a distinction between the lowest level/bare metal stuff and high level). By the time of the Switch (and PC probably 25 years before that) then this approach is the default and why locations might change between levels, boots, whether you visited the settings first... the thing you use to keep track of where a given section of memory/data is at being known as a pointer. You can have a pointer to a pointer to a pointer... indeed such things are a common test when learning to program. They can and do exist but as doing that at some level is bad programming form (related to why you don't call a function within a function) then it is not necessarily that common.
However underneath it all there will be some part that is fixed and at that point you can take control.

Finding pointers can be done in a variety of ways.

The basic method is to find the location across a variety of boots (presumably most being different) and take savestates for all of those. You can then feed the locations and the corresponding savestates to a tool which will scan through it all and note what things might be a pointer (it is fairly obvious as anything that showcases a location of the area in that particular savestate and that showcase stays consistent between boots/loads then becomes what you want to look at, more colloquially this location does not contain the data I care about but it between various boots always contains the location where I can find it). I don't know what we are suggesting for the Switch these days but pointer finding tool is a good start for a search term of the relevant locations/guides.
Such things struggle with the pointers to pointers to pointers thing unless you finesse it (recall the earlier part about visiting settings, levels... you can go up the list by taking savestates before a last stage divergence and find the next step back) but hey.
More advanced methods involve actually diving into the code -- you might have to go back a few steps (the location might live not in normal memory depending upon what goes) but ultimately something in the code will have to parse out the pointer list to figure out where it needs to be. Work back enough stages and you find a fixed location you can work forwards from. However where basic cheat searching and pointer finding using the basic method don't require many programming skills then here you return to the grey beards of old and skills they employed. This will need you to employ a debugger, probably a break on read or break on write* to the area you found for that particular boot, when something reads/writes as appropriate to that location the debugger will say hold up this thing just did what you told me to watch out for, here are the last 10 or so instructions. Hopefully one of those is something reading the pointer to know where to read/write but could just be the start of the journey.

*break on write is easy as the health will go down when hit/change when healing. Break on read might come earlier and thus be closer to the initial pointer read as you generally first need to know if you have enough health to tank the hit/money to buy the item/need to have the game tell you not to waste the potion in the first place, though it does not always happen in that order so eh.

Once you have found the pointer then most modern cheat engines will have some kind of extra option for their basic "always write this value to this location" to instead be something like "always write this value to this location plus some other value" and the plus some other value being what you are supposed to have an additional line read in from memory (presumably from the pointer) beforehand to influence the next step**, maybe with a few more steps/checks if the health value does not appear until your are in the game proper and if you write that location while the intro screen is going on then crashes or bad things happen.

**some will also use this when working with data tables and wanting to target particular areas, characters, stats that are a fixed distance away (in essence doing your own pointer/pointer maths), and similar things with codes that might be the same across 500 areas but a fixed distance apart (say you have 500 characters and want them all to have max stats that could be written out in program form along the lines of add 2, set location +2 more, add 2, set location +2 more, end when 500 have happened, this being called a slide code). Cross those bridges as and when though.

 

[masagrator]

Every cheat making tutorial for Switch will explain this to you. Did you even try to read them first?

 

[izzeling]

@FAST6191 Thanks for this explanation! I was actually wondering this myself and I had read some tutorials but didn’t quite understand. I had made some codes for Cult of the Lamb but realized they were not corresponding after a reset. I’ll have to read further when I get home but this was very helpful!