Sign in to follow this  

Anti-Piracy measure

This topic is 4839 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
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
Delays are good and usefull... but are better if the cracker doesn't expect delays.
So: you have the normal crash code, cascade errors which crash the game/make it unplayable, and the "extra" code so that if a crack is detected, it would say change the checksums of bits and pieces of the levels (randomly... :)). it would also remove a few key elements of gameplay. Of course with all this editing, it should tack on a few (specially made) extra bytes so that a strait CRC32 won't tell the difference... :)

From,
Nice coder

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You are describing an anti-cracking method. It prevents people from tampering with your code. It does not prevent peoples from copying your games. You need som copy protection scheme first. Then make sure that it's hard to tamper with that code. Imo the two needs to be tightly coupled together.

I like what they did in Spyro the Dragon on PSX.

Our company actually did a similar thing before on the PC with a racing-game called Motorhead.
We had several anti-hack methods that used "stealth technology" and no obvious way to see if the game was cracked.

For instance we had a league race mode that made you race a few races gaining a score based on your position. If you after a season (all races done) had above a certain score, a new season was unlocked and so on. This scoring failed if the game was hacked and you could never unlock the second season. We got 3000+ mails from people complaining that the game couldn't count :) We always asked politely if they where perhaps playing using a backup and to make sure that the purchased the product at a legitemate store, not one reply.

Another thing we did was to make the cars go 5% slower in multiplayer races if the game was hacked ;).

The most vurneable point in an anti-hack system is the "if (gameIsHacked) then" statement IMO. If a cracker sees a checksum test, he put's a breakpoint on the stored checksum. Then it easy to spots all places that reads from that address and if there is a branch based on that just skip it. A better way is to NOT test the checksum, but use it directly instead.

For instance we had a table with physic-settings for our tyres, frictions, inertia, slip-angles etc, basicly alot of technical stuff that's very sensitive to small changes and used the checksum to "decrypt" these values. If the checksum was invalid the cars went berserk. Sometimes they couldn't move because of high friction, sometimes they behaved like soap skidding all over the level and sometime they had reversed friction, thus accelerating like crazy. I'd like to see the hacker who reverse engineered our physics to find out which parameters where crazy :).

We had several diffrent checksums that overlapped eachother and was done in different ways (the asm code was very different making a search impossible). We never used the result of an checksum directly, we always delayed the usage of it and masked it into some "real" code.

Some other nasty stuff we did was to take check sum A xor it with checksum B xor it with constant C (choosen so that A ^ B ^ C = 0), then we took C and xored it with a random texture pointer. This caused a crash somewhere on the track in out renderer. This is also hard to trace backwards.

In effect I think it took over 4 month before there was a complete crack out there. Razor 1911 release something like 5 different "Final release, all working!" versions.

The game sold around 400K units and were bundled with another 600K units.

Share this post


Link to post
Share on other sites
hehe.... shameless plug: OISCVM may be useful for that %)
other thread about similar thing
anyway i don't see why they can't copy both game and valid serial code.

edit: take a look at that _wonderful_ code:

int s[]
.....
.....
int i=0;
while(i!=0xF47B16CA)
i^=((s[s[i+2]]=s[s[i]]-s[s[i+1]])>>31)&&(s[i+3])+s[i+4];
somehow use your s somewhere.

[grin] .

Anonymous Poster:
i like idea about making it go unnoticed,5..10% speed decrease,etc :). But checksum computing is a problem, they can put read-breakpoints and trace access to code area, and they don't have to rev-eng physics, only checksum code.

it all can be done using OISCVM: just do some critical(but not speed-critical) processing inside OISCVM and also calculate checksum there. You can write and read to outside-of-array from OISCVM, so everything is completely messed up (also you can use your own version of OISCVM).

[Edited by - Dmytry on September 15, 2004 7:19:49 AM]

Share this post


Link to post
Share on other sites
I thought about this a bit a year or two back and came to the conclusion that you need to remove that crucial 'if(isCracked)...' statement too. You could have loads of such code, and generate a program to mangle your final .cpp files adding it all over the place automatically before the build, but that's just a matter of time. I guess if you put in 2000 checks they might just get bored since it wouldn't require a clever cracker - no test of skill, just patience! However using the special variables somehow would be better. Physics is one area, graphics another. You could have a texture with 'This is a pirated copy' which is blended with your backbuffer weighted on if a hack is detected. The hacker would then be required to understand D3D/OGL programming, if you could hide the texture somehow...

Share this post


Link to post
Share on other sites
I have no clue of disk-formats....

but shouldn't it be possible...to hardcode disk-serial-numbers or something similar?

I guess such a approach doesn't fit to industial-disk-production...but maybe if you distribute shareware/development tools or something like that..that is meant for smaller audiences?

The disc becomes a kind of dongle....but I think that would not be legal...since the costumer must be able to burn backups

Share this post


Link to post
Share on other sites
The idea is, that the anti-copy protection would be distributed inside the code. And the code cannot be changed (easily), so the copy protection would be hard to remove.

This would also have other advantages, if (during the first stage of cracking) crackers manage to "remove" one or more of the protection systems (like say the anti copy protection), without changing the web of "data" opticodes in the correct manner, would lead to the corruption as the exe is put back together...

Another way would be to infuse a serial INTO the game exe, so that once registered (with name, email adress, credit card number embedded in some way using something like asymetric encryption), so that once you find a hacked exe, you can "check up" on them.
I'm also quite sure that it should be possible to get the game to recognised that it is registered properly...

Also, since when was it illegal to make sure that the user cannot have backups? how about if you give out backups (that can only be used on correct machine) with proof of purchace?

From,
Nice coder (DENC)

Share this post


Link to post
Share on other sites
I don't think lowering the fps (or similar approaches) is a good idea. Friends who have tried the pirated game will basically tell you that the game sucks and dissuade you from buying it.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Anonymous Poster
Our company actually did a similar thing before on the PC with a racing-game called Motorhead.
We had several anti-hack methods that used "stealth technology" and no obvious way to see if the game was cracked.


That was a great game, really nice graphics effects, archtecture and presentation (even on my s3 card, heh). I could never get past the first season though... *cough*

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
You are describing an anti-cracking method. It prevents people from tampering with your code. It does not prevent peoples from copying your games. You need som copy protection scheme first. Then make sure that it's hard to tamper with that code. Imo the two needs to be tightly coupled together.

I like what they did in Spyro the Dragon on PSX.

Our company actually did a similar thing before on the PC with a racing-game called Motorhead.
We had several anti-hack methods that used "stealth technology" and no obvious way to see if the game was cracked.

For instance we had a league race mode that made you race a few races gaining a score based on your position. If you after a season (all races done) had above a certain score, a new season was unlocked and so on. This scoring failed if the game was hacked and you could never unlock the second season. We got 3000+ mails from people complaining that the game couldn't count :) We always asked politely if they where perhaps playing using a backup and to make sure that the purchased the product at a legitemate store, not one reply.

Another thing we did was to make the cars go 5% slower in multiplayer races if the game was hacked ;).

The most vurneable point in an anti-hack system is the "if (gameIsHacked) then" statement IMO. If a cracker sees a checksum test, he put's a breakpoint on the stored checksum. Then it easy to spots all places that reads from that address and if there is a branch based on that just skip it. A better way is to NOT test the checksum, but use it directly instead.

For instance we had a table with physic-settings for our tyres, frictions, inertia, slip-angles etc, basicly alot of technical stuff that's very sensitive to small changes and used the checksum to "decrypt" these values. If the checksum was invalid the cars went berserk. Sometimes they couldn't move because of high friction, sometimes they behaved like soap skidding all over the level and sometime they had reversed friction, thus accelerating like crazy. I'd like to see the hacker who reverse engineered our physics to find out which parameters where crazy :).

We had several diffrent checksums that overlapped eachother and was done in different ways (the asm code was very different making a search impossible). We never used the result of an checksum directly, we always delayed the usage of it and masked it into some "real" code.

Some other nasty stuff we did was to take check sum A xor it with checksum B xor it with constant C (choosen so that A ^ B ^ C = 0), then we took C and xored it with a random texture pointer. This caused a crash somewhere on the track in out renderer. This is also hard to trace backwards.

In effect I think it took over 4 month before there was a complete crack out there. Razor 1911 release something like 5 different "Final release, all working!" versions.

The game sold around 400K units and were bundled with another 600K units.


The above deserves a repost.

Totally love meshing the checksum with game data. [lol]

Share this post


Link to post
Share on other sites

This topic is 4839 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this