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]

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

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?

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

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! ;)

Are you talking about this?

(awesome, awesome read, by the way)