Hi people. I'm wondering: how people create cracks? I mean. If I have an .exe file how this can be cracked? I've heard software like Black ice (or something) which crackers use - how?

I'm not so much concern about crackers and I won't be using any heavy methods to protect my software but I'm a bit curious to make it a little harder for crackers - but so that it won't hurt the customers in any way.

Here's my current ideas for the product and issues related to copy protecting it. I would like you to comment them:
1.1) the demo and the full version will be same - altough variable "registered" is either true or false: to indicate trial/full version. Notice: both full/trial version players can play the same game session in the Internet (trial version owners just have limited amount of functionality)

1.2) the game is online game - so, when you connect to internet the game can connect to our mysql server and see whether the keycode is valid and return either TRUE/FALSE depending on it.

1.3) keycodes could be in format: 1243-1234-1234-1243 (maybe with letters added... so that would make it: 0-9, a-z, A-Z but we must make very sure that user can recognize each letter from number easily. like small "L", big "I" and number "1" can look similar in some font types)

community issues:

2.1) keycodes are linked to certain customers (keycode, username, email) and they can use our community (forums etc.) and automatically retrieve forgotten keycode. when playing the game the keycodes can also return your account name so you will be seen in game with the same name as your account name.

2.2) player can join clans (at least in the later versions) and these are also handled using the database. when joining to clan the server could check that given keycode (and username?) are valid.

2.3) everything else in the community (voting for new features, adding game times, creating clans etc.) would also be protected same way.

2.4) full version players' staticstic ("how many stones carried", "how many morphlings kicked", "how many games played" etc.) can be measured (using the keycode...) and marked into database.

extra stuff:

3.1) I thought it could be possible to host to check if joining client is having valid keycode and kicking him out of game if the keycode is not valid & player is using cracker of some sort.

3.2) would it be possible to try to fool a cracker by putting ALL code in one file, then checking which words are after variable & function defining (like function getRegisterStatus() would notice "getRegisterStatus") and then the program would search & replace each function & variable with cryptic text? (like "getRegisterStatus" => "2PPxxgsk68bdbnWx001")

3.3) I've heard about different .exe versions (meaning different trial/full OR different full/full - like 5 different full.exe versions) but that sounds little "too much more work" ;)

3.4) When .exe is compiled I would run an "exe packer" software which will reduce the exe size and perhaps add more copy protection (how in fact they work..? I've heard these software sellers to promote the software by saying that it affects copy protection)

phew... long text :)

I'm very new to this stuff and I would appreciate if you guys could shed some light here :) Give your suggestions & ideas.

Well, I'm not much a hacker, but here are my 2c. :)

At first, your model does not requre registration codes. For _online_ game just issuing account/password for registered users will be enought.

1.1) Why don't you make two players check each other? However, it will requre some assymetric encriptyon to prevent cheating and abuse, but

1.2) Won't work. Your program can be traced, mysql traffic can be sniffed and substituted.

1.3) Whatever. Everybody using Copy-Paste to enter codes.

2.1) - 2.4) Will work.

3.1) Won't work. Server can be hacked same way as client.

3.2) Won't work. "2PPxxgsk68bdbnWx001" is not valid function name :). Besides, why don't you consider publishing compiled .exe instead of source code? :D

3.4) Will give some protection. But not too much, mostly agains lame and lazy hackers.

In order to "make it harder" for crackers you should be familiar with assembly language, and if possible, crack a couple of applications yourself, as a learning experience. It's the only way to see the problem through the eyes of the crackers.

How are cracks made? I'll present an extremely simplified explanation.

Say your game includes this code :
if (!isRegistered())
{
MessageBox("You aren't registered");
exit();
}

(rest of the code)

The assembly code generated for that by the compiler looks vaguely similar to this :

call 0x004f1234 ; Address of isRegistered()
test eax ; Load relevant flags
jz 0x0040abcd ; If the Zero flag is on, jump to an address below
push 0x0045f432 ; Push address of the string
call 0x004f5678 ; Address of MessageBox()
call 0x004f9876 ; Address of exit()
(rest of the code) ; At address 0x0040abcd

With a disassembler such as BlackICE or SoftICE, the cracker usually puts a breakpoint in MessageBox(); when the execution stops there, if the parameter says "Not registered", he looks at where was the function called, and finds the call 0x004f5678 line. Looking above it, he sees a call (to isRegistered(), but the name doesn't appear) and a conditional jump which skips the call to MessageBox(). So he just changes that "JZ" opcode for a "JMP" (unconditional jump) by changing a 0x74 for a 0x75 (or the other way around, I don't remember), and that's it. It's exactly as if you wrote this code originally :
isRegistered();
if (false)
{
MessageBox("You aren't registered");
exit();
}

(rest of the code)
I repeat, this is a very simplified explanation and the examples won't compile, but it should give you an approximate idea of what's going on.

@Stilgar:

3.2) Won't work. "2PPxxgsk68bdbnWx001" is not valid function name . Besides, why don't you consider publishing compiled .exe instead of source code?
=> of course it would be compiled :)
the thing here was to prevent stuff ggambett mentioned. and now I ask for ggambet: could this kind of naming work here?

I have to read more carefully your posts and reply again if all is not clear.

As far as I know, idea 3.1 where you would do server-side checks of keycodes and boot people with invalid keycodes, is about as effective a copy protection method as you can muster these days. However, this is only effective if you personally are running the game servers! If you have a public game server setup, like Quake and Unreal engines offer, the server .exe can be hacked as well to remove the checks. This has happened already with Unreal Tournament 2003, with many user-run servers no longer doing serial code checks.

But if the game servers are all operated by yourself, then they should be fairly well protected from hacking as long as you have decent server administering skills. Then you can not only check for invalid codes but check for duplicate codes too. If you're getting a lot of people logging in using the same keycode, then chances are that code has been leaked.

Tying all the player's personal stuff to the keycode is an additional deterent, since it discourages multiple people from trying to share the same account. This is similar to Ultima Online and Everquest, where 20 people can't exactly share the same keycode since they would all want their own characters.

- Air

Also! Regarding function names: This is an entirely irrelevant thing to do. There are no function or variable names contained in a compiled exe as long as you turn off all debug information (standard Release Mode behavior in most compilers). ggambett's example included comments which would not exist normally, for the purpose of helping you understand what a hacker sees.

A hacker can look at hex addresses and see what they are in relation to the raw machine code and data. They will figure out what your code does rather quickly, labels or not.

Put simply, there is no way to protect your user's exe from hacking. Even sophistocated copy protection tools used for commercial games gets cracked in a few days. Since you are doing an online game, you are best off relying on server-side checks for most, if not all, of your copy protection.

Someone posted this a while ago:

http://www.gamasutra.com/features/20011017/dodd_01.htm

Good information.

Originally posted by Morphecy
1.2) the game is online game - so, when you connect to internet the game can connect to our mysql server and see whether the keycode is valid and return either TRUE/FALSE depending on it.

A more efficient thing would be, IMHO, to send actual data, needed by the game, from the server to the client. If the key isn't correct, then send flawed data. This should be "dynmanic" data, ie not a simple file that the hacker could just save and reuse, but data that depends on input parameters... for example the server could compute the AI or something...

About servers: the servers are run by players.

@Jake Stine: thank you for clearing this function name issue.

@Lizardsoft: I shall check that. thanks.

@StAn: hey, you gave me an idea. it is true that we have trial/full version player playing the same games. but the game list is fetched using TCP/IP connection to our MySQL database. We could also send the keycode when fetching the game list. If the keycode is valid then we could fetch the whole list, but if the keycode is not valid then we would fetch only first game that is NOT full. (okay... this is not big deal but at least it would make sure that players with valid keycodes could choose their game but not buying customers / hackers would have to play first game they fetch)

Would 3.3 idea be efficient about that method which ggambett mentioned? (the idea: to create 5 different game.exe files with functions/variables in different order)

notice: the one big part of this whole issue that players have accounts which they can use to participate in a small community and interact in many ways. it's not just the game - but also the community.

that's also one reason (the other reason is that I prefer making it easy for the customer than toying around with copy protection that can be anyways being hacked :)) why I'm not going to put heavy hack protection in game. just something to keep lazy hackers away.

Full versus Trial
You guys have put me into situation where I think again whether the trial & full versions should be different. I think I could leave the code almost similar, but I don't put all images in the trial package (for example: the image buttons which let you use morphing powers available in full version only) - those could be downloaded after purchasing the product. that way even if people crack the trial version to "be" full version there wouldn't be imagebuttons to show and that way launching the game would give error and shut the game. would this be efficient?

still... I really want to make it as easy as possible. meaning: people can put keycode in the game and *simsalabim*, you can continue playing RIGHT AWAY (no downloading, no waiting) the full version. I want to make it easy for buying customers. And this is controversial to stuff mentioned in the previous paragraph.



P.S. maaan you give me information. flood like! :) have to read this whole text carefully few times. big thanks. more comments are welcome - especially suggestion for which kind of copy protection I should use.

As mentioned above, when the hacker breaks into your code and runs through the assembler, they tend to look for strings first. If they see anythihng like "Unregistered" "Trial Version" or similar, then they have their starting point instantly.

A simple way to avoid this is to XOR the character data of key words and phrases like registered and trial version. And whatever you do, don't put the XOR calls immediately before the call to the trial version check - the next step for the hacker is to step through the progam very slowly until the trial version warning comes up, then they trace backwards to the last few function calls. If they see a bunch of XORs before those function calls they know they have the right place. Instead, make a de-XORing function that can take a pointer to the character data and deXOR it. This way the character data is stored as a variable, far away from the actual checks/functions that use it.

Also, as I mentioned they will step backwards through your code from the point of the trial version warning. If you can put a lot of distance (in terms of code execution) between your trial version checks and the trial warning dialogs, that will slow them down as they will have to trace through a ton of code to find the right functions.

And the golden rule - duplicate and vary. Do not ever just have one simple check. Make multiple checks throughout the code, all called at different times, and all using a different approach. This is the method that will best deters most hackers. And try to avoid using the registry for registration checks - that's far too easy to hack.

Alright. thanks.

Anti-hacking FAQ:

http://www.inner-smile.com/nocrack.phtml

Oooh I just had a new idea....

Place one of your registration checks in a small dll file. Now store a copy of that dll in one of your data folders and name it something life videoconfig.dat or graphics.dat (something the hackers would think it normal to access). Now when you start up your program you could create a copy of that file that overwrites the dll file. Then simply load the dll and activate the registration.

Of course hackers could remove the call to the function if they realise that's a registration check - so be sure to use only silent checks in that dll. And add a few different calls around your program.

Of course, as that site mentions it's worth adding program vital code into the registration functions. So you could use the dll to load in some textures or something, meaning they would need to call it.

Not impossible to crack, but certainly different to the usual approaches and would probably deter your average hacker long enough for him to find a new game to crack.


edit: one trick I didn't see listed on that site:

Timing checks. Most cracker software works by allowing the user to step through the assembler while the program is being executed in memory (just like the step debugging in Visual Studio). Grab the system counter time before you start any registration checks, then compare it afterwards. If more time than can reasonbaly be assumed has passed (say 3 seconds or so for a simple function) then someone is stepping through your program - crash the machine :)

Okay. thank you guys.