I guess you could try to obfuscate your code, or using non documented opcodes (i.e.: anything related to YXH) to make debugging harder. But keep in mind that doing so will have an impact in performance, maybe you'll have to choose between performance and security.
Also, you could leave your code untouched, but use a CRC routine to check the integrity of your code (or at least the integrity of important parts of your code). Call that routine at various points (i.e. main menu, everytime you pause the game, complete a level or lose a life) to make it harder to find, and obfuscate only that routine. Check important parts (i.e.: game init, collision routine, dec lives, game over routine, that CRC routine and some places where it's called) to protect against "n lives", "infinite lives" and "inmunity" pokes.
Using the CRC routine out of your main bucle will save you from losing performance (or, at least, you will lose performance when the computer and the user are waiting), and still have some protection.
Post edited by Zup on
I was there, too
An' you know what they said?
Well, some of it was true!
Call that routine at various points (i.e. main menu, everytime you pause the game, complete a level or lose a life) to make it harder to find, and obfuscate only that routine.
'Breakpoint on read over a memory area'. Modern emulators are just that frighteningly resourceful, (then there's things like execution logs, IDA one-click disassembling etc... gotta think harder!)
And doing it in a loop in a few predefined places? Sorry - too easy. If you have to, it's better to think up some non-blatantly-obvious conditions for it to run, e.g. once when there's exactly X enemies on the screen and the player has Y item in their inventory etc
Then there's the question what to do once it finds that the code has been tampered with. IMO, don't just restore that DEC (HL) or what have you (and surely don't display a big red warning or something along the line). Rather, POKE to an address generated from the resulting CRC, sit back and enjoy the sight of unfortunate h4x0rs chasing 'weird mysterious bugs' to no end
You could use the code to decrypt your game data, in such a way that minor changes to the code have a large effect on the data; imagine whenever you enter a new room you decrypt the room definition into a buffer, XORing each byte with many bytes of the code, different ones each time.
It would be fixable by removing the decryption code and pre-decrypting the data, but that wouldn't be a simple POKE. Also it wouldn't stop someone just repeatedly resetting their lives counter to maximum. Also you'd need to fill all of RAM or they could set up an alternative interrupt handler which resets the lives counter every frame before calling the real handler (also not a simple POKE)
I don't know why you'd want to do all this though, it sounds like a lot of hard work to me for little gain.
In my game Mole Rat I included some very basic anti poke protection:
The game code went something like this:
LD A,(LIVES)
DEC A
LD (LIVES),A
The first thing most hackers look for and then blot out the DEC A for infy lives. Elsewhere in the code I had a mildly disguised check the 'DEC A' byte hadn't been altered. If it was the program restored it. Not that hard to unravel but another layer at least.
It foxed Andrew Ryals, but the scoundrel found numerous other things to POKE instead!
Ohhh :)
I asked just for learning and increasing my knowledge, not for implementing these techniques in real game. :)
When I was thinking about ways how it can be done:
- for multilevel game vital code can be loaded for each level, always replacing already poked data (and for each level it will be a little different);
- vital code can be a part of game data (for example, ld a, (lives) : dec a : ld (lives) is a part of level objects, thus replacing part of it changes gameplay)
Remember sometimes a hacker isnt looking to poke a game for infy lives sometimes disabling sprite collision detection routines is simpler or even relocated /highjacking the game over routine to relocate somewhere else. TBH I've gotten really lazy and usually do 255 live hacks if im really in the mood I'll really delve into a game but honestly, nowadays, there arn't many new tricks so whatever you implement will probably be a rehash of something old.
marsden and cooke were good - took me ages to poke costa capers eventually tracing to and patching a JR NZ, but i still didnt understand fully how the condition was met!
Comments
проще всего рассчитать crc куска кода и отслеживать его неизменность.
второй вариант - использовать один и тот же кусок кода для героя и врагов.
Also, you could leave your code untouched, but use a CRC routine to check the integrity of your code (or at least the integrity of important parts of your code). Call that routine at various points (i.e. main menu, everytime you pause the game, complete a level or lose a life) to make it harder to find, and obfuscate only that routine. Check important parts (i.e.: game init, collision routine, dec lives, game over routine, that CRC routine and some places where it's called) to protect against "n lives", "infinite lives" and "inmunity" pokes.
Using the CRC routine out of your main bucle will save you from losing performance (or, at least, you will lose performance when the computer and the user are waiting), and still have some protection.
An' you know what they said?
Well, some of it was true!
And doing it in a loop in a few predefined places? Sorry - too easy. If you have to, it's better to think up some non-blatantly-obvious conditions for it to run, e.g. once when there's exactly X enemies on the screen and the player has Y item in their inventory etc
Then there's the question what to do once it finds that the code has been tampered with. IMO, don't just restore that DEC (HL) or what have you (and surely don't display a big red warning or something along the line). Rather, POKE to an address generated from the resulting CRC, sit back and enjoy the sight of unfortunate h4x0rs chasing 'weird mysterious bugs' to no end
It would be fixable by removing the decryption code and pre-decrypting the data, but that wouldn't be a simple POKE. Also it wouldn't stop someone just repeatedly resetting their lives counter to maximum. Also you'd need to fill all of RAM or they could set up an alternative interrupt handler which resets the lives counter every frame before calling the real handler (also not a simple POKE)
I don't know why you'd want to do all this though, it sounds like a lot of hard work to me for little gain.
Step 2: consider how much of a performance hit you're willing to take for this.
Step 3: Reconsider.
Step 4: Do multi-level bookkeeping, with check failures causing subtle problems (such as removing one of the five keys required to get to level 3)
Step 5: Allocate data structures in random order.
Step 6: Hide values by creating a structure that's an array of pointers to individual bits, allocated in random order.
Step 7: Consider runtime encryption / decryption
Step 8: Implement all code in read only/position independent manner, and move code around in random manner.
Step 9: Seriously, why are you doing this.
http://goo.gl/q2j0NZ - make ZX Spectrum choose your own adventure games, no programming needed (release 3)
Games List 2016 - Games List 2015 - Games List 2014
The game code went something like this:
The first thing most hackers look for and then blot out the DEC A for infy lives. Elsewhere in the code I had a mildly disguised check the 'DEC A' byte hadn't been altered. If it was the program restored it. Not that hard to unravel but another layer at least.
It foxed Andrew Ryals, but the scoundrel found numerous other things to POKE instead!
I asked just for learning and increasing my knowledge, not for implementing these techniques in real game. :)
When I was thinking about ways how it can be done:
- for multilevel game vital code can be loaded for each level, always replacing already poked data (and for each level it will be a little different);
- vital code can be a part of game data (for example, ld a, (lives) : dec a : ld (lives) is a part of level objects, thus replacing part of it changes gameplay)
Anyway, thanks for overview.