How does an unlimited energy trainer work?
category: code [glöplog]
Hello all.
With the C64 and Amiga in mind, how does an unlimited energy trainer work?
I imagine that the trainer puts the entire game in its own infinite loop, and watches a memory location, and if it changes then change it back to max. If that is correct, why doesn't it burn all the performance as it must be very costly to check a byte value at each cycle?
On the Amiga there were some games that could return to the OS after quitting the game, which I assume means, that it didn't used absolute addressing. How could a trainer then know which location to modify on the fly?
With the C64 and Amiga in mind, how does an unlimited energy trainer work?
I imagine that the trainer puts the entire game in its own infinite loop, and watches a memory location, and if it changes then change it back to max. If that is correct, why doesn't it burn all the performance as it must be very costly to check a byte value at each cycle?
On the Amiga there were some games that could return to the OS after quitting the game, which I assume means, that it didn't used absolute addressing. How could a trainer then know which location to modify on the fly?
Nah. Just overwrite the instruction that changes the energy counter :)
Ok, that's brutal =) But makes a lot of sense, because I also wondered how you make sure that the game didn't notice that the value dropped. So now I know.
Thanks =)
Thanks =)
The question header looks like it's taken from stackoverflow... :)
Quote:
because I also wondered how you make sure that the game didn't notice that the value dropped
Most games just don't care. You don't write code for something that you don't anticipate.
that's what denuvo is for these days! ;)
I guess I have taken damage from posting on that site so much =)
That makes sense...
Quote:
Most games just don't care. You don't write code for something that you don't anticipate.
That makes sense...
What Marq said, similar process applies to PC too, you can also inject code to hook a function or to call your own injected code to do things. But then Denuvo or VAC might come into play there....
Quote:
Most games just don't care.
When it comes to Amiga games this is not necessarily correct, there are LOTS of games with more or less subtle checks if the code has been tampered with! Mostly used as copy protection but quite often also to make the life of the trainer maker harder.
Quote:
On the Amiga there were some games that could return to the OS after quitting the game, which I assume means, that it didn't used absolute addressing. How could a trainer then know which location to modify on the fly?
You just use dos.library to load the excutable (LoadSeg) and then just patch the corresponding location in memory and start the game. Quite simple actually.
Very nice! Thanks! =)
I vaguely remember a memory resident DOS TSR program^ to (kind of) make your own trainer. You'd play the game, switch to the tool, enter a number (f.e. current number of lives), back to the game, drop one, enter the cheat tool again, enter the new number and so forth to narrow down the possible memory addresses, where the life count was stored and overwrite that to your hearts content. ;)
(^ might have been Game Wizard, but didn't check.)
(^ might have been Game Wizard, but didn't check.)
tomaes: action replay was commonly used to do that. Maybe there were software equivalents later, I don't remember.
