Okay, here''s a summary, with credit, of the best (IMHO) ideas on this thread

game entities behaving wrongly: guns jamming, units spawning or disappearing, mis-timing races (superpig)

game difficulty increases followed by a "winners don''t cheat" type message, claiming modified files are "corrupt" (Seigfried)

the frequency and regularity of checking is eccentric, making the cracker think a cheat has worked because it won''t get checked for another hour (Tazzel3D)

slowly corrupt random writeable bytes in memory (Extrarius)

don''t inline the function, write loads of slightly different checks (Kohai)

according to the version number, the compiler shuffles functions and enables/disables check code ie each patch or update has to be re-cracked (walkingcarcass)

audio and visual data becomes corrupt;
disable or corrupt saving and loading (walkingcarcass)

server checks cd-key database;
modify game economics so composition of resources becomes slowly less desireable;
remove useful items eg powerups (OmniBrain)

disable just enough items to make the level or stage uncompleteable (Pik)

flood the internet with fake cracks, let cracked versions be played for a couple of hours as a kind of advertisment (Tazzel3D)

mess with deallocation, causing swap file useage. FAQ says "cracked versions often have suddenly lower performance" (OctDev)

RE: deliberately fragment allocations, deallocate suddenly causing page faults, let an exception handler give the "cracked" message (walkingcarcass)

have unique checks at very long times into the game (Run_The_Shadows)

have a dependancy chain of checks ie if a one-off check finds a crack 2 hours into the game, it initialises checking code 1 hour into the game. if the cracker fixes the 2 hour one then save-loads to find the next instead of backtracking, the 1 hour chack will go unnoticed. when the crack is released, 80% of the checks are still there to anyone who plays the game start to finish;
run checks on obscure events eg the 90th console command;
disable certain paths in nonlinear stories- the cracker has to play every possible version of the story to find all cracks, esp if checks aren''t run 100% of the time;
subliminal "cracked version" messages and uncomfortable sounds (walkingcarcass)

gradual handicaps eg jumping (superpig)

keycodes and other important data carried over from previous levels means the cracker can''t easily skip to the end to fix a crack there (eg a keycode is randomly generated and used twice) (Tazzel3D)

bias the random number generator (Extrarius)

if a crack has been detected, wait until the game has been exited, restarted and then on loading the next level declare a cracked version;
rewrite code to a level loading script to a) post a crack message, and b) rewrite itself so it loads fine the second time: almost impossible to tell when the crack was found if you rewrite a script 2 or 3 levels ahead (walkingcarcass)

add shortcuts to start menu/desktop/favourites etc to "Buy the legal version of XXX";
NPCs become less helpful (modify social allegiance variables);
add humour to "this game is cracked: buy it for real" messages;
permanently store a detected crack (so un-cracking makes no difference);
exe constantly rewrites itself, registry entries etc;
immediatly write crack information to all savegames (encrypted);
modify data which is supposed to be static (eg hit points);
less interesting shops etc;
darken gamma;
collapse fog of war, radar angles etc;
add jitter to framerate, input devices and network lag;
delay/reposition sounds etc;
send false offensive messages to network players (or false offensive messages from those players); (Merle (way to go ))

encrypt savegames with game code. they won''t be decrypted properly loading on uncracked (or differently cracked) versions. (walkingcarcass)

a garbage area hides data eg checksums and is traversed by some "up", "left" etc algorithm (superpig)

a crack detection searches not for cracks, but for the presence of changes mady by other crack detections eg if a key is missing, chances are it was deleted as a result of crack detection (walkingcarcass)


********


A Problem Worthy of Attack
Proves It''s Worth by Fighting Back

Perhaps you were giving a summary of just the different crack protection ideas, but if you were summarizing this entire thread, you left out my comments on the rights of the legit customers who happen to use cracks in order to play the game on a CDROM-less environment, like my laptop for instance, among other things.

I didn''t feel like reading through all 4 pages of this post, but one of the suggestions on page 2 inspired an interesting idea, which might have already been mentioned, but as I said, I decided to skip the last 2 pages before I forgot my idea.

Anyway:

How about a client-only emulation of server-client protection schemes? Basically, every little bit, pull a random memory address from an inlined function (so it''s used multiplicatively throughout the program and can''t easily be mass changed) that takes a long value from it, encrypts a message describing what it''s doing, and pops it off to a little manager that replies with a message encrypted with an equally randomly attained value (possibly another method to further complicate things).

The original caller would need to decrypt this message and check EVERY aspect of it to ensure that it was on the right track (variable x is what value it should be, state y is set properly, etc). If even the slightest oddity is detecting, extend the idea further by issuing one of the many annoyances, such as changing flags to make the game progressively more difficult.

And, of course, these values wouldn''t be limited to memory entries, it could be registry values, checksums, file lengths, arbitrary values from specific files, etc. The manager, of course, would need to know how the message was encrypted, so instead of just telling it, or having a global variable with the value used, keep up with the last 2 or 3 values used, and have an algorithm to determine what is going to be used next. Calculate this, again, with inlined functions and you have a very interesting, yet fairly effective, I''d imagine, system to deter changes to any game state involved in the checks.

sorry, GBGames, i''m *not* saying your opinion is insignificant but this thread exists on the assumption that making games easy to copy is a bad thing

********


A Problem Worthy of Attack
Proves It''s Worth by Fighting Back

sardak, and what would stop me as a cracker/hacker to simply modify this client-side server-simulation to say all time "ok, game is a legal copy"?

The point is: EVERYTHING you hand out can be modified.
It doesn''t matter if your copy protection is included in the game or is running as a seperate process on the gamers machine.
The idea of a server-side copy protection is to have a database with all valid serial keys. You don''t want to hand out this list of valid keys to your customer.

this cracking business doesn''t just apply to piracy, it includes cracks to make the game misbehave to a player''s advantage eg 110% health

how''s this for subtle, a crack detection piece of code allows the client to become out-of-synch. slighlty different responses from eg the physics engine (or just set the FPU rounding mode to truncate instead of nearest). discrepencies mount up over time, eventually the cracker is dying for no apparent reason: the other players see them running into a corner or whatever and are an easy target

********


A Problem Worthy of Attack
Proves It''s Worth by Fighting Back

I love the idea of odd behaviour of in-game objects (although I''d follow up eventually with some sort of anti-piracy message so people would realize what''s going on). The random gun jamming someone suggested is great. Imagine the frustration if your car got flat tires every couple of minutes in Vice City, or your most powerful character in an RPG deserted you citing an ethical dilemma (what a laugh that would be in something like Sea Dogs, one of your ships sails off leaving a message that they won''t continue to be party to your ''piracy''). Surely you people have some similar ideas, this isn''t the place for talk of checksums and self modifying code.

Genre by genre, unique ways of discouraging cracking through obfustcated hinderences:

FPS(Action)(Single Player) - Constant disk access/memory allocation. A normal player will play what amounts to an optimized version while a cracker will have to deal with overactive harddrive accessing and 25-45% more memory being used up.

FPS(Action)(Multiplayer) - Slow down cracker ''stuff''. If a weapon usually takes 3 seconds to switch to, a cracked version would take 4 or 5. For humor on the other side of things, whenever a cracker tried to use VOIP technology, nullify it and play a "I am a dirty cheater!" WAV for all players who would normally hear his broadcast.

FPS(Other) - ''Accidentally'' untextured models/maps. It''s not going to stop a cracker in his/her tracks, but playing a game with textures randomly missing isn''t pretty.

RTS - Randomly disappearing units, or force units to get ''confused'' more easily. When a cracked player gives a group of units an order, have them lag for a couple of seconds and then take a very round-about path to the waypoint.

RPG - Replace key items with believable but faulty replacements. When they kill the Dark Dragon 5 hours into the game, a paid player will get A Holy Sword of Might while a cracked user will get a Holy Sword of Strength or some other minor variation. Later in the game, require a player to actually have a HSoM to finish key plot points. Also, set it up to where every time they use a healing potion, it costs them money as well.



-This is where the world drops off
-ryan@lecherousjester.com

quote: Original post by Run_The_Shadows
RTS - Randomly disappearing units, or force units to get ''confused'' more easily. When a cracked player gives a group of units an order, have them lag for a couple of seconds and then take a very round-about path to the waypoint.

I like the idea of an alternate pathfinding algorithm... maybe something like the number of waypoints a route contains must be proportinal to the distance between the start and end points. That would happen sometimes anyway, but by increasing the proportion... the cracker would have to constantly click short distances to get his units to move in the correct manner.

Or the units could move of their own accord, you come back a few minutes and your group of grenediers has scattered inbetween your buildings

What if units move, one every few seconds, into a new group where the formation spells "crack" or "cheat". Because it is built up slowly, it might take ten or fifteen minutes to see. What if units mutiny on their cheating commander?

********


A Problem Worthy of Attack
Proves It''s Worth by Fighting Back