Jump to content
  • Advertisement
Sign in to follow this  
Nice Coder

Anti-Piracy measure

This topic is 5051 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was thinking about anti-piracy measures... and i think i came up with a halfway-good idea. The basis of the ideas are this, you do your checks, in each check you poke a byte out into a block of memory. you have multiple checks poking the same byte into memory (and another set checking if its valid). you then execute that block of memory as a function, in that function, it scanns the executable and does a few things: 1.if there are breakpoints, it crashes the computer (causing a stack underflow/overflow, ect.) 2. if any of the cheat detection code is gone, or has reported an error, it causes the program to behave strangly and/or crash eventually (but doing it in a very hard to trace manner) and 3. decompiling the program/game into independant pieces, each piece has some of its instructions interchanged (eg. changing some opticodes with others which do the same thing). the pieces order is then scrambled, before the extra code is changed to allow the pieces to connect to each other the same way. The pieces are then written back to disk. extra data into how the pieces communicate with each other is written in the form of opticodes which are never executed, but still look like a normal program. These pieces (and extra info needed for the extra program) would be compiler generated, or generated by a tool. and would be optimized (and obfucated) to make it insanely hard to figure out what does what. using these pieces and also some extra data to store compressed versions of the pieces, as well as checksums allows the program which was made by the program to add missing checks back in. (or another version of the same piece, just to confuse any cracker more) Is this a new/good idea? Any comments would be welcomed. From, Nice coder Edit: Added rebuilding program part [Edited by - Nice Coder on September 12, 2004 5:52:33 AM]

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
In my opinion, copy protection that is easily detected is never going to work. Do what Settlers 3 did - make the copy protection create strange irregularities in the game. For example, the Iron Smelter in that game produced live pigs instead of iron instead when the game .exe was modified.

Share this post


Link to post
Share on other sites
Is this a new/good idea?

Well... how to crack it: Replace the stuff that calls the crashing function by some no operations. Still, that's not too bad, having to change maybe six bytes is much better than one or two.

Share this post


Link to post
Share on other sites
The thing about it is if it did detect that it was cracked, then the code created by the security checks would scramble the program and put the checks back in.
And as such you download a cracked copy (say only the first layer as cracked), you run it once and everything goes fine (you only play to test it, so you only go for about 10 minutes).
You load it again and guess what? the exe added the chacks back again, and now the cracked version is no longer cracked.
And the patch woudn't work because the part would be in a different location and may have different code then last time. (as such its like trying to destroy a polymorphic virus)

How about having the code generated by the crack detection generate new threads (maybe 2-3). each one checks that the other two and the game are all working fine.
If something goes wrong, the threads cascade an error until it its a trippoint where it may or may not cause the computer to crash (depending on conditions, so you get "phantom bugs" which would occur sometimes but not others). You could also have a thread which scans for things like softice, breakpoints, other debugging tools and crashes when it detects any. it could also hook writeprocessmemory and readprocessmemory, and crash when these are acessed.

Any and all errors should be accumulative if not too bad (as in, one part of copy protection lost). but all errors (when they choose to express themselves) should cause a cascade of other errors (which doesn't do anything by itself, all its doing is propogating a hard-to-find error signal), until it comes to a trippoint. at a trippoint, code at that piece (or part of that piece), causes another function to crash the program.

Nice idea?
From,
Nice coder

Share this post


Link to post
Share on other sites
Quote:
Original post by Nice Coder
The thing about it is if it did detect that it was cracked, then the code created by the security checks would scramble the program and put the checks back in.
And as such you download a cracked copy (say only the first layer as cracked), you run it once and everything goes fine (you only play to test it, so you only go for about 10 minutes).
You load it again and guess what? the exe added the chacks back again, and now the cracked version is no longer cracked.
And the patch woudn't work because the part would be in a different location and may have different code then last time. (as such its like trying to destroy a polymorphic virus)


The thing is, the cracker never executes the code that modifies the program.

Quote:
Original post by Nice Coder
How about having the code generated by the crack detection generate new threads (maybe 2-3). each one checks that the other two and the game are all working fine.
If something goes wrong, the threads cascade an error until it its a trippoint where it may or may not cause the computer to crash (depending on conditions, so you get "phantom bugs" which would occur sometimes but not others). You could also have a thread which scans for things like softice, breakpoints, other debugging tools and crashes when it detects any. it could also hook writeprocessmemory and readprocessmemory, and crash when these are acessed.

Any and all errors should be accumulative if not too bad (as in, one part of copy protection lost). but all errors (when they choose to express themselves) should cause a cascade of other errors (which doesn't do anything by itself, all its doing is propogating a hard-to-find error signal), until it comes to a trippoint. at a trippoint, code at that piece (or part of that piece), causes another function to crash the program.


Interesting... I can't really come up with some dead easy solution for this...

Although it's very much overkill and might kill performance :)

Share this post


Link to post
Share on other sites
I'm not very saavy on the copy protections but would embedding critical game code within the copy protection functions work? If they by passed the copy protection wouldn't that make the game operation fail?

Share this post


Link to post
Share on other sites
Quote:
Original post by Leffe
Is this a new/good idea?

Well... how to crack it: Replace the stuff that calls the crashing function by some no operations. Still, that's not too bad, having to change maybe six bytes is much better than one or two.


But how about changing 6 bytes, which get changed back as you were about to test it? and which are never in the same spots? and which make you restart everytime you crack something? doesn't sound as easy now...
as well as having a LOT more then 6 conditionals for copy protection. And all this is assuming you can FIND those six bytes, which would be hard because the six bytes that caused the problem may be hundreds of function calls down, and which caused that many fatal errors due to the butterfly effect (cascading error, its undetectable untill its too late),

That even without the extra kill-code the thing is dead. That and the actual kill code doesn't look like kill code,
it would just be your average texture loaderwhich gets given an index to an array which is out of bounds due to a tranfrorm which went wrong because the last trannsform went wrong because..... which went wrong because the value that should have been zero to zero the accumulator with, was not zero because of an extra push & pop caused by the extra kill code which changed an internal veriable which was then passed out of the function.

See what i mean, thats confusing!

Quote:
Original post by Leffe
Quote:
Original post by Nice Coder
The thing about it is if it did detect that it was cracked, then the code created by the security checks would scramble the program and put the checks back in.
And as such you download a cracked copy (say only the first layer as cracked), you run it once and everything goes fine (you only play to test it, so you only go for about 10 minutes).
You load it again and guess what? the exe added the chacks back again, and now the cracked version is no longer cracked.
And the patch woudn't work because the part would be in a different location and may have different code then last time. (as such its like trying to destroy a polymorphic virus)


The thing is, the cracker never executes the code that modifies the program.



The thing is, the cracker never knows what code modifies the program (and would not look for it, because it is uncommon), because the program just looks like random memory acesses. and would be camoflaged by other things which also use memory. (you can also add decoys here and there which are never actually pushed into the program).

The program is made up of bits and pieces which are assumbled in different bits of code at different times, its only activated once its finished. Now if you use parts of that "program" (bits which aren't executed) as the spot to put your global variables, then either your global variable saves are going to look like anti-crack code or your anti-crack code is going to look like a global variable save!

From,
Nice coder

Share this post


Link to post
Share on other sites
What about the new NoExecute thing on CPU's which prevents code from modifying executable memory? Your copy protection is redundant. People are not going to risk a virus just to run your game. I reckon your threads idea will cause bugs and memory leaks, specially if you are modifying executable memory.


Let's face it:

1. They ARE going to crack your game, whether you like it or not!
2. No game programmer is ever going to beat a cracker cause they are as good as you at coding, probably better.
3. I'd be more worried about whether the game was good or not.

Share this post


Link to post
Share on other sites
I read an article that explained copy-protection in a console game. (Can't remember the name of the game.)

It worked as follows:

There was some validation code spread around in the game.
If some modification was detected...the code did not crash...instead it modified some flags that caused logical errors later on.

Example:
Failing a validation at Level 2 in the game, removed some items in Level 8, these items where needed to complete the 8th level.

The story went like predicted:

A few days after the game's release some cracks where released that cracked the first few validation-routines. The crackers had no idea of the later validations, because:

*The game executed as expected, with no appearantly anormalies.
*They did not beat the game fully, so they did not notice the errors in the higher levels.

Conclusion:

It took about 2-3 months, until the first fully-operational cracks where available.
Enough time to sell the most copies of the game.

This is a kind of stealthy copy-protection used by Bohemia Interactive in their game "Operation Flashpoint", where cracked executables slowly lower framerates until it is unplayable.

But I did not try it...just bought it! ;)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!