Security: Protecting your game from hackers and pirates

#1 I know one tried and true method.

Dont get popular.

Because as soon as your game gets popular, you are going to inevitably be the target of hackers and warez-kiddies.
My best bet to combat this would be get to know hackers and find out the points of their trade and build a project around not making your project vulnerable or making the vulnerabilities as such that they report to your server(s) that cheating is occuring / something is amiss and the server and/or administrator can do something about it. Would require a lot of heavy planning and implementation I imagine.

#2 In my experience, No matter what you try, there will always be someone who figures out how to break your copyright code.. Then they'll make the cracked version available for all those who aren't smart enough to break the protection but are smart enough to use the internet.

Just seems to be a delaying technique. Delay the crackers long enough so you can make some sales from the shelves before it becomes available for free..

Possible stratergies?

You could make your game subscription based.. so the user needs an active account, the exe and data becomes a side issue.. but this only works for online pay to use games.

If your game is downloadable, You could try a referral scheme... Refer this game to your friends and get a partial rebate on the original price.. Use money as an incentive to get people actively policing the piracy themselves. But some people would try to abuse this scheme to get money off. but it would mean giving the game to other people is less tempting.

You could try an obfuscation tool, scramble up your code and make it difficult to reverse engineer.. never used one.. does this affect performance?

You can put a watermark in your graphics to catch obvious copiers in other games, but it involves you looking for culprits manually and it doesn't stop people using the graphics and modifying them to their own ends.. breaking the watermark.

Making it difficult to cheat is tricky... I suppose it's a server coding issue more than anything, Only get the client to send the bare minimum information and do all calculations on the server.. i.e. health, collision, ammo... But LAG is your enemy. and it still doesn't stop people changing textures to make things more visible

You could send info about a random game file on each network message, get each client to compare and report back.. any differences and the rogue player is booted. if this is dones carefully, there will be minimal network impact and will mean that hacked versions will be thrown out after a while

Software patents are evil and should be eradicated from the planet.

Personally not tried any of these, probably would just go for an email the key approach... yeah, it's easily broken but at least the honest user can write down the key and still install and play the game in a few year time, after the company has perhaps stopped supporting the game or is unable to re-issue keys. Probably put somethign in that after a few years, the key isn't even needed to reinstall.

#3 This is from the work I've done on my RonzCode. It explains how using the code in your program can be used as a locking mechanism for just about any information you wish to encrypt.

Quote:
How It Works
---------------

,/ Key
E) Locked Lock
E/ Unlocked Lock
=|= Locked
=^= Unlocked

,/ A // Key A - Masterkey - Prog. A (Security Prog.)
E) B // Lock B - Key C Lock - Prog. B (Program)
,/ C // Key C - Codekey - Prog. B (Program)
E) D // Lock D - Code Lock - Prog. A (Security Prog.)
E) E // Lock E - Locked Code - Prog. B (Program)

,/ A != E) D || E) E // Key A, Masterkey, cannot unlock Lock D, locked, or Lock E, also
// locked
,/ C =|= E) B // Key C, Codekey, is locked by Lock B, locked
,/ A =^= E) B // Key A, Masterkey, unlocks Lock B, which was locked
E/ B =^= ,/ C // Lock B, unlocked, unlocks Key C, Codekey
,/ C =^= E) D // Key C, Codekey, unlocks Lock D, which was locked
E/ D == ,/ A =^= E) E // Lock D, unlocked, defines Key A, Masterkey, which unlocks Locked
// Code E, which was locked

The coding itself contains the unlock key, which is also encrypted. It uses a quad-randomization to prevent hacking or value corruption. Should a value be altered, it would destroy the code integrity therefore corrupting the entire program.

The code, when initiated, is sent to the master security server, which breaks down the code to verify it, sends the unlock method, and swaps it. It forwards the correct method back to the client, which unlocks and registers the code. Afterwards, the security server sends a rewrite to the code and re-scrambles the structure. This last part could be ommited if need be.

Using this, you could put out demos which contain everything necissary to upgrade to full version. Each version of the game could use a completely unique code and still be coherent with the code architecture, thus we can discern from hacked copies during the verification process.

Granted, it still needs some testing during the process, which is why I need help making the unlock program. The code can be decrypted manually, it just takes forever!

Once I get it right, I hope to release it to the community and GG.

- Ronixus

#4 I think this would make an excellent roundtable at IGC.

#5 I think it's an area often neglected, and if you do any type of online multiplayer game (and/or a for-profit game) this is a very crucial piece to consider.

I have a code security background, once I finish my current Torque project I'll see if there's any resource I can write around this stuff too.

#6 IMHO....

Multiplayer based games are easier to control because you can create an "account" system, whereas an account is required to play. A totally random key can be generated (to defeat keygens) and then STORED in the system, linked to each account.

This way:

*There is only one key per account.
*Each key can only be used once.
*Keys are not verified via an algorythm, but matched to a stored value in a database.

You don't want to necessarily prevent piracy of your software. You cannot stop that. What you want to do is stop people from USING it once they have it. GIVE the software away.... But make them pay for an account to use it.

THAT is copy protection you cannot beat.

#7 @Bryce: for multiplayer type games, I think the bigger problem is hacking rather than piracy.

piracy at least can generate good hype around your game, and some people are the "try before i buy" types... I'm not saying piracy is a good thing, it's just there are some positives.

hacking is a worse problem. it will leave people who "play fair" at a disadvantage, and they can get fed up with a game where they always get owned by the hackers. This will cause them to not recomend the game to their friends, etc.

#8 I'd be curious to hear the GG guys wiegh in on this - really like to know how effective thier ignition system has been thus far? (C;

#9

Quote:Multiplayer based games are easier to control because you can create an "account" system, whereas an account is required to play.

This brings about in my mind the validity of the Steam system. No internet connection to "turn on" your freshly bought Half Life 2 ? Then you aint playing it. A hassle but one honest people were willing to put up with to play their games. Problem I saw there however is this was cracked and bypassed as well (because of the single player nature). And making single player game report to the master server everytime they are played I dont think would be accepted at all, it was barely accepted the "one shot activation" with Half Life 2. I think the creative use of multistage encyrption suggested would be a place to begin finally making cracking too difficult to engineer, but I am not sure how it would be implemented (my lack of programming know-how showing through again).

#10 One thing that I have done in the past with enterprise software, not with games, is to contract a hacker or hacker group...

Believe it or not some of them do real work too. :) I have contracted several hacker / cracker types towards the end of the development cycle to specifically test my software security and make recommendations.

In reality it is just like breaking up the rest of the projects work. You have the guys who are good at art doing the art and the programmers programming. Why not get someone who specializes in security to work on the security aspect?

Just one way to look at it that I have not seen in any of the other posts.

#11 Tom Bampton provided some great feedback when I did some stuff to encrypt art assets for Torque demos since those assets were sold in other peoples' content packs. The bottom line is, though, if someone wants to crack something, they will. The decision making comes in when you figure out how good is "good enough" for DRM.

#12 The encryption I speak of can be put in place of any data that requires security since it also can contain the information to decode it (ideal for single player games).

It wouldn't be suggested to encode the entire code of a program because this would mean technicly increasing the size four-fold, but rather portions of it or even in place of values which need protection from hacks. This leads us to unmoddifiable data!

@ Pat -
If you or Tom would like some more inside details on what I have accomplished, and I can have your word to keep the details safe, I could send you more info in an email. I still need to program this into code, but I have all of the encryption details completed, and since this can be benificial to the community once it's completed, I could use any help to make it work.

- Ronixus

#13 Crypto of this nature is a rabbit hole. You cannot make a client side asset secure. Not with clever programming, not with clever hardware. Ultimately it must be accessible to be rendered or used, at which point the client has access to it... and they can do whatever they want with it, if they are sufficiently determined.

Look at SecuROM, and how many games use it - and how many days, on average, it takes for those games to show up, fully cracked, on warez sites. SecuROM is not staffed by idiots, nor do they have a small budget.

The only thing that client side crypto of this nature can succeed at is obscuring data temporarily. As Tom demonstrated, with a bit of determination and experience, even pretty clever crypto can be cracked in the matter of days. You can try to be more clever, but you'll end up in a race you can't win.

You can see this pattern play out again and again in software piracy, and the result is always the same. Ignition is a great copy protection scheme, but it's no more secure than any other commercial anti-piracy scheme. It's effective at keeping honest people honest. In the case of games like Lore, where you have to use your reg key to play online, the success rate of the antipiracy measures goes up tremendously - authenticating with outside servers to access resources that only they control is secure, and works. (Look at HL/HL2, Tribes 2, Lore, etc.) Pure client side solutions don't.

So that's why we don't spend a lot of time or effort on ultimately futile crypto schemes here at GG. Pat's effort was great, and served its purpose for protecting content pack content from casual hackers. But you'll note its not something we're betting our business on.

#14

Quote:
Making it difficult for hackers to cheat in online games

Never trust the server, can go a long way. Building your code and structure around this will make it so much easier later on.

Quote:
Catching hackers who cheat in online games

Log suspected attempts to a file and boot the intruder. There's not much else you can do.. just make sure they won't come back as quickly and destroy the experience for the rest of your fanbase.

#15 @Stefan: I think you mean "Never trust the client"

@Ben: you are totally right. The only real gain of security schemes is to keep the honest honest, and to raise the bar for those trying to be dishonest.

The only real debate is how far should you raise the bar, and what's the most effective way of doing this :)

#16 The below is a simple message done in RonzCode, including the key to work it:

0XT9T52P2XL31HL4DI7W 9S QO73KY8G63CB3ZNAVY0R AN42J2QF7LB4QYXLU52QEQM11IL5EN5A0
R3TF9005M91J57283 82TX8 94X907A68W2795FL1I57 I3YB9M95 T14J42R04Y6A02 T8 54BP0F
45502Q1A85P5B95IIN0 27L4 BF MX2Y
15Q70191A89Q95XXQQL9159QQL0350192503541AQ0QA9QQ9153QQXQ8Q452509Q5A9TP085TFTIAF9F599J9RF5PFJ9R5WP5TX0P5958TI959IF99F5599999AJ850P5F05IFL01  L5L46575N33X755L05X75 B0 L 20 YNIL47 745775LNN77376XIN20 51N45 F T  0 Y80X0BJJ2X402F02X4 7F   MF 7B  Y  XY0X 02BFXXJX82 BMF 0 BY0
QQL3AQ750539XQ7150591535Q95055A2QQ9150145J9R9I985RPWF9J85555F5595JXP555IB9JF555T85X75Y47 NT0B53X LN N5LNYNX 0 NN427X5LN LIN2X47YXTBTF70J2T2B B02B7B2 F BBYMX202B   B
QQL0990L5XQJ9R5XF5R59JX75  5 5N3X2X4  0 4BJ2
Q1350T951LYN  7B

Enjoy!

- Ronixus

#17 I give anyone props if they can even come close to cracking the code above, any portion of it. Heck, I'll even provide hints if someone wants them and I still give anyone 5 years to come close.

Besides, it's just a simple cryptogram, right?

Here's a big hint - The first two lines deal with the key.

Good luck to anyone who attempts this. My suggestion is not to get too worked up trying to solve any of it, just admit it's unhackable.

- Ronixus

#18 I think the best way is to just delete all .cs files, put in some passwords, copyright everything, then encrypt all your graphics so no one can use them.

@Christopher Everything's unhackable. There are always ways. ;) Nah, I'm no hacker. I'm just a Torque newbie! :)

#19 @Matt:
Eh, copyright everything? "Ok"

@Jason:

Quote:
@Stefan: I think you mean "Never trust the client"

I must have been asleep. :) Yes of course.

@Christopher:

Quote:
just admit it's unhackable.

There is no algorithm on earth that is unhackable. Especially not an algorithm that you store inside your application. It can always be reverse engineered, and even without the actual code shown to you, it's possible. I hope you're kidding.

#20 The code above is not an algorithm, it is a purely cryptographic encoding system. The only thing about it that would relate to algorythmic would be the millions of ways the code could be sorted.

The code above only accounts for the english alphabet. It can quite genuinly account for any and all assortments of characters just by extending the code to that which it applies to.

The key to how it works is using the quad-level encryption I've devised for it. This makes for an incomprehensible, random assortment of code structure that, without the aforementioned knowledge, is completely unhackable. I can even designate the coding into three levels of encryption (hint: the code above is Level 2 encryption).

The way it works in a program is by substituting static values with static encryption - encryption which remains in it's encrypted form and is constantly re-randomized. The data it protects is only obtained when it is accessed and decoded on an on-demand basis, after which it is re-encoded with a new, random encryption.

The only way that can be cracked is if I told you how, which is what I wanted to share with Pat and the rest of the GG staff in order to develop the system to use it in games.

I can assure you, it can be done.

As for reverse engineering, the totally un-algorythmic form of the code makes it so it only works as intendid, or not at all.

Of course, I do see the dangers of such a code as well...

- Ronixus

"Ronixus - To know what thou doust not know."