I''m still having a problem with the suggestions like "slow the game down" or "make units disappear".

We''re making a game so that it''s hard to tell if a crack worked or not. This means (inevitably) some "bad" cracks will get posted, propagating faster than rumours do.

Mr. Random User acquires a full copy of the game, applys the crack, and plays. He finds the frame rate to be slow or choppy. Units disappear on him. Pathfinding is lousy. His own units are too dumb to know not to attack their own base.

Now, these are our "subtle" ways of indicating a cracked version. But he doesn''t know this. Instead, he says "this game is buggy and slow" and decides never to play it again, certainly never to purchase it.

Now, you could help defuse that by having a notification message like: "bet you wonder why (bad thing X) was happening. well, a crack was detected. this measure was added in so thieves wouldn''t be able to play the full, normal version. etc..." That might help. I''d probably chuckle and go out and buy the game, since the coders were clearly cool.

But then again, that tells the potential cracker what sorts of thing to look for when cracking...

The problem with saying "Crack detected" is that it tells the cracker that their method didn't work. If you don't make the message appear immediately, then the player will still play the buggy game, figure the game sucks, and stop playing. Unless the message appears very soon, the player might stop playing before they see it. And if it appears soon, it tells the cracker it didn't work, and they find the code that displays the message and works back from there.
In effect, the message nullifys any work done to prevent cracks from working. You might as well just stop the game when a crack is detected and tell the cracker the code to change to fix it.

[edited by - Extrarius on February 2, 2003 5:01:25 PM]

Here''s a possible solution:

Why does a guy obtain a pirate copy of a game? Because he will have heard from a friend, or from a website, or from that it was cool.

So he picks up it, and it doesn''t play well for him. So he contacts his friend (who has a legal copy) and says ''why did you say it was cool? X and Y don''t work, and Z is slow and terrible!'' The friend responds, ''works fine for me, must be your computer.''

So the guy tries to contact tech support.. except that because he has a pirate copy of the game, he isn''t entitled to any tech support.

So he gives up, believing that his machine won''t run it. But when he realises his friend has the same machine spec as him, he gets an inkling of what might be wrong...

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.

Just make page 1 of tech support say something about cracked versions being buggy, or you could do like a lot of companies do and actually PUT all those bugs into v1.0, and release patch v1.1 the day it is released, so anybody that gets an early leak has to suffer at least until the game comes out =-) And if you put all the subtle crack responses into v1.1, then the people that cracked the game would end up still having all these bugs, but legit players would no longer see the bugs as soon as the get the first patch =-)

[edited by - Extrarius on February 2, 2003 6:49:51 PM]

Solution: after crack detection, one or more timing systems kick in (eg an int decremented every frame or every 3 seconds etc) when these counters run down OR the game is quit, a crack detection message is posted.

Even if the cracker finds the timing code, they won''t nessecarily find the crack detection code that initialised it because that code sensibly didn''t hardcode offsets etc.

Additionally, suppose the compiler program for the game''s script generates unique extra exit code to test the timers, the cracker will have to disassemble the script (which has also been obfusticated with eg self-modifying) for EVERY SINGLE LEVEL to find all the timers. It could easily be a mammoth task, especially if the level was divided into hubs, each with it''s own script.

It wouldn''t be out of the question to randomly compile crack detection into every infrequently called script (there might be several or more in every level), meaning the code search space could have increased by dozens of megabytes in a large game. If the method of compiling the crack code is also randomised, it makes writing an automatic process very difficult.

Using these kinds of methods, the problem can be increased by orders of magnitude if there is a widespread change in the detection methods throughout the game. Automating the changes at level build time creates a diverse set of problems.

Also, if anyone with a legitimate copy creates their own content (with the supplied editing tools ), their scripts will have to be cracked seperately before they will work on an illegal copy. This will isolate online cheats.

********


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

A refinement to my earlier idea: if a player installs a cracked copy of a game (i.e. they didn''t crack it themselves), then they get problems and the error message "a number of game subsystems were not operating correctly. Please contact tech support."

Differentiating between users who are creating cracks and users who are simply applying them is important. People who decide to spend their time creating the cracks usually can''t be persuaded to go buy the game, whereas the other group will more likely give in.

Superpig
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.

<vent>
A thing you should definitely _NOT_ do to stop piracy: put faulty CD detection code in a patch. I''m _____REALLY_____ mad at blizzard right now because the latest warcraft3 patch (1.05) comes stocked with securom CD detection that is apparently faulty because it doesn''t detect my original CD in the drive that let me play fine previous to 1.05. I followed all the instructions on their tech support page and none of them work so I use the email form at the end of all the steps and I get a reply after a few days listing the steps on the page I already tried, with a new step saying to collect system info and send it back to them. The instructions were flawed and impossible to follow (because they refered to files and directories that didnt exist) but I did the best I could and sent of my system specs to them and now I''m waiting for the second reply still >=-(
</vent>

quote: Superpig:
Differentiating between users who are creating cracks and users who are simply applying them is important.

I would agree, but I don''t think you can actually do this.

I am creating a crack: probably softice is loaded, I''m manipulating code in memory. I am testing a crack: exe is modified. I am a random person using a crack: exe is modified. How can you tell the difference between the last two?

If you could tell when someone was actively cracking, as versus passively (ie applying a crack), many of the above suggestions would be great, including the moderately "cruel" ones (disappearing units, etc). But you always code for Worst Case Scenario when you have time. Worst case is: your detection failed, and you''re ticking off a person who would have bought your game, but now is not going to.

So, here''s my suggestion once a crack is detected:
- set lots of flags all over the place
- all saved games will have a (say) 2hr countdown timer in them
- if user quits and countdown is under 1hr, nothing is displayed
- if under 1hr, very subtle effects start, if you really want
- if they quit and it''s under 1hr, "crack detected" notification(s)
- once under 5min, cannot save, cannot load, auto notifications
- once down to zero, game exits with verbose notification

If you do this, then (in theory) nothing is detectable to the active cracker for an hour (this assumes, of course, that your flags are not blatantly obvious...). The average Joe Copier is probably going to be playing an extended stint at the game, and will be there the whole two hours. He''s probably trying it out for the first time.. and most first sessions are quite long.

As for the "coolness" factor.. no, these aren''t cool suggestions, and don''t hurt the cracker in any way. I know the initial question was for things that would "make the hacker really angry". Regardless, this feels like a bad idea to me.

I''ll admit that I have "tried" a few games in my time. The bad ones, I delete, since there''s no point in keeping them. The good ones I try to go out and purchase. Since I''m a year or so behind the "bleeding edge", this can be hard, since for some foolish reason games are yanked off the shelves after a paltry few months.

But if I try a game and it felt sluggish or buggy, it''s *gone*. No second chances. Even if it claims "oh, you were using a cracked version and those are ''known'' to be buggy"... come on! ''Known'' to be buggy? Like the company is good friends with the crackers... and like any crack has ever been ''buggy'' except for not being a full crack!

I''ll be the first to admit that I''m not the average demographic. But I used to buy at least a game a week. Less now, but still... the "try before you buy" has always seemed best to me, as it''s the only true way to tell good from bad. If I''m trying out your game, and it looks shoddy, it''s not going on my shopping list, regardless of messages that pop up. The messages just indicate that the crack was bad. The performance and bugs indicate what your code is like.

So I guess I''m advocating: don''t waste your time with subtle effects. They''re cool, yeah. (yeah!) Fun to think about. Hey, I spent several hours coming up with subtle things to do! But ultimately, as happy as you are with them, they''re bound to annoy some potential customer. So why waste the time coding them?

If you want to "try b4 u buy", get the liberally distributed demo version!

I think it is possible to tell the difference between a cracker and a crack user, it''s all in behaviours. The most obvious one is that crack makers usually don''t spend hours exploring the game to see if any obscure problems have crept in, so time-delaying detection and response disqualifies all the lazy crackers from trying. We need to identify every such weak point.

The real key issue isn''t technological, it''s psychological. Forcing a cracker to spend hours tracking down each tiny problem will make them VERY angry, but crack users will eventually stumble across the message and realise they need to find a better crack or get the full version, by which time thay may decide to buy.

I agree, generating bugs is a bad idea, but units spelling out the word "cracked" is obviously not a bug. Recieving "you''re a dirty cracker" messages from online players is obviously not a bug. "This game was saved from an illegal version" is obvoiusly not a bug. All these take time to manifest themselves.

The psychology is the reason "flooding the internet with fake cracks" is such a genius idea. It makes using cracks much more difficult but legitimate players are totally insulated.




Here''s another suggestion for the pool: if someone sprays a wall with machine gun fire, the marks spell out "cracked version". It could be implemented by modifying the wall''s "toutch" event handler, making it hard to trace, and the alphabet lines are described mathematically, making it hard to identify.

One more suggestion: generate loads of "IsCracked" and "ValidateChecksum" type labels which lead to meaningless places in code eg a blit function.

********


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

format their hard drive.

*grin*