Like I said it is almost impossible to decrypt if you don''t know what to decrypt. People are using very popular crypters which are basically encrypted already. Now, if you write simple equation where every byte is increased by 2 like Y=X+2 now the encrypting algo does this backwards. When cracker starts to encrypt it he notices that it doesn''t have any logical/popular algo. Let me say, it takes hellamuch time to try understand what is happening when suddenly every byte is byte +-X. You can increase the time spent in these simple traps by making second one, crypting the crypt.

Of course this can be easily hacked if you know what is happening, but when cracker opens it, he just firstly tries to find popular crypting algo, if he doesn''t find it he tries to figure it out by himself. Also I suggest doing this by language which doesn''t compile variables, like basic if I remember right.

Time comes, time goes and I only am.

i don''t know much about it but i have read some material on cracking passwords, I also like to attempt to stop the inevitable.

picture this:

if (txtUserInput == ProgramPassword)
{
//some kind of code goes here
}

is just as easy as saying.....:

if (txtUserInput != ProgramPassword)
{
//some kind of code goes here
}


It does not matter if you program it in C, asm, VB, YOMAMACODE, or anything else you could come up with.

You kind of need to hide it in a box, which is hidden in a box, which is hidden in a box, which is hidden in a box.(BIG BLACK BOX IDEA) and still if they want it bad enough it''s done.




***"When I die, don't bury me, Just hook me up to my computer and I will live forever!"***

Hello all,

Just as a note, it''s actually NOT illegal to disassemble programs to *learn* from them, we just don''t need to tell anyone that we are *learning* to crack a game. . .

If you really want to learn to protect your program and you''ve programmed it in C/C++. Write some primitive protection algorithm, and then try crack it using a disassembler yourself. Once you''ve done it, think to yourself: "how can I make it harder for MYSELF to crack it?". Then add schemes accordingly. Repeat this process until you feel that YOU would not be able to crack it. In reality, this is probably the best you can do.

Take into account, that businesses all over the world pay millions for programs to organise their data (databases, expert systems etc. . .) which shows the potential of a large mass of data to REALLY muddle things up.

Now for some protection schemes:

1.) As someone above mentioned, you can add extra useless lines of code, but that doesn''t really confuse things too much. However if you made these lines of code morph into more useless lines of code, just by having self-modifying code. (this REALLY confuses most people, but again there are some brilliant crackers out there).

2.) Add a checksum to a section of your code, have another piece of code which adds all the opcodes together and then checks if it is equal to a certain number, then that code would detect if the branch instruction has been changed, and if it has been, it changes it back . .cheeky!!
It would take AGES for the cracker to find that code because it could be virtually ANYWHERE.
What''s more, you can MOVE this verifying code around, by just recopying from an encrypted buffer, and the cracker would be none-the-wiser . . .usually.

Well, of course to implement both of the above, you''d probably have to learn some assembler language. Learn 32-bit for the windows programs, and familiarise yourself with 16-bit, it''s a good platform to stand on.

Hope I''ve helped,
FReY


------------------------------------------
The world is queer my friend, ''cept for me and thee. But yes, even thou art oft freaked
------------------------------------------

One thing to remember,

useless lines of code, checksums, checking passwords multiple times, encrypted keys, etc

have all been done and cracked successfully.

Although they are good ways to stop the average teenage cracker, the problem is that there are many people who are much better, and tricks like these won''t really work that well.

Also, most stolen software and sabotage comes from inside the company, not just someone who buys a game and decides to crack it. It''s really hard to protect yourself when one of the programmers is the person who''s putting it all over IRC, and knows all the methods of protection that is being used.

The only type of protection I have ever seen that actually works (and here I am on a limited basis) is for online games that the main program is on their server, and even those have many flaws.

It comes down to faith that people will be honest and pay for it. Just put something simple in that the typical player won''t be able to figure out. Why? Because if you kill yourself trying to make it uncrackable, you are just going to be disappointed in the end.

I''ve been playing with the idea of encrypting the code of different parts of the games with keys that can only derived by playing through the parts before the one you want to decrypt (this is completely transparent to the user). This would force a hacker to play through each part of the game before being able to decrypt the next part.

The encryption technique is called clueless agent encryption because the key is not stored anywhere in the software but is figured out from environmental parameters at runtime. I don''t know if it''s applicable to games but if it is, it might be an effective way to slow down hackers. One research paper on clueless agent encryption can be found here:
http://www.counterpane.com/clueless-agents.html

Henry

1) Good remark from several posters : the CRACKER is to the HACKER what the terrorist is to the alchemist. They both use explosives.

2) What do you want to protect it against ? Copying or cheating ? If you mean copying, I''d say forget it. Two year''s worth of work on a copy protection system ended in 1995 and were reduced to nothingness when I tried it on Windows 95 machines with Phoenix Bios. Ever heard of the "Please reinstall Windows 95" error message ?
In other words, building an efficient protection means using undocumented features. Using undocumented features means your program will autodestroy when confronted with new versions of OSes or TSRs.

Btw., obfuscating the program won''t help very much for copy protection : nobody actually tries to understand the program from an asm source code. If you are faced with a "malevolent third-party", the person will trace your program. And there is no real protection against tracing.


If you are trying to protect it against cheating... why would you do this in the first place ?



Henry, the idea seems interesting. I have just begun looking at your article so please forgive me for asking questions you may answer at some point.

*In order to cipher part n+1 in the first place, you have to assign it a key. I assume this is a private key, with a private key protocol, since the receiving code is in the hands of the malevolent third party in any case.

*Once you have fixed this key, you have to hide it into parts 1..n of the code. Since the exact machine-level execution of these parts is unknown and its modelling is very likely to be undecidable, this means that you have to hide it into user-provided key points. Unless I missed something, the division of the key is trivial. You can even trivially put some redundancy if you do want to allow several paths.

*Each of the key points will have to make some kind of a "system" call in order to provide its part of the key.

*How do you hide the system call ? You could do this on smartcards by flooding the cracker with machine-level almost identical excutions but this time, it would be rather simple to filter the meaningful ones. Just by playing the game.

*And anyway, can your system protect the execution twice ?

Be reading you,
David

P.S. :
Just like our Dostoïevsky-quoting Anonymous poster, I apologize for my English. I am also French and I just came back from the Spring beer fest in München. You get the idea.

>> *In order to cipher part n+1 in the first place, you have to assign it a key. I assume this is a private key, with a private key protocol, since the receiving code is in the hands of the malevolent third party in any case. >>

I would probably use some symmetric encryption algorithm like DES, yes. Who knows, maybe public key cryptography could be useful but I have not really thought about that.

>> *Once you have fixed this key, you have to hide it into parts 1..n of the code. Since the exact machine-level execution of these parts is unknown and its modelling is very likely to be undecidable, this means that you have to hide it into user-provided key points. Unless I missed something, the division of the key is trivial. You can even
trivially put some redundancy if you do want to allow several paths. >>

Well, you don''t hide the key. You generate the key in a similar way that the player would. You can have a completely open algorithm that assembles the key from various parameters in the game whose states will only be set if the player completes a level. The problem would be to make the sum of those parameters unpredictable enough for it to take longer for a hacker to figure out the values of those parameters than it would take for him to play through the level (this is the minimum security requirement that all the parts of the security system must meet).

I figured one would use various kinds of redundancy since it allows a greater amount of entropy in the parameters.

>> *Each of the key points will have to make some kind of a "system" call in order to provide its part of the key. >>

Well, you can have a key assembly algorithm that is more or less open to the attacker at the end of each part of the game. The algorithm would assemble the key for the next part from various parameters and the security would lie in the idea that the attacker can''t figure out what those paramaters would be in less time than it takes to play through the part of the game where those parameters are set.

>> *How do you hide the system call? >>
You don''t. Everything is done in the open. The idea builds on the fact that the game manipulates various openly available parameters in a way that takes longer to analyze than to just play through the game.

>> *And anyway, can your system protect the execution twice ? >>
No, once someone has gotten access to all parts of the game, they must have gotten all they keys to the game.

This is just an idea that I''ve toyed with and I really don''t know if it would work in practice. Security engineering just happens to be one of my interest along with game programming.

Henry

nes8bit, yeah, if you know assembly, and dissassemble the code, it''s very easy to get around just about any password protection. The easiest are the ones that ask for something up front and don''t allow you to continue if you don''t give the right info. You just branch around that entire area.

E:cb woof!

quote: Original post by Dan Smith

Ga:

It does not prevent cracking by writing your code in assembly. Its the same as writing it in C++ or Visual Basic.

Infact, if you write it in assembly, it might be easier to crack because it will be cleaner code when you put it in a deassembler (deassemblers are very easy to find)


-Dan Smith
dans@3dgamedev.com

I don''t mean just translating routines to assembly, I mean you could write it in a way it would be very hard to read for anyone who disassembles it.

Visit our homepage: www.rarebyte.de.st

GA

quote: Original post by FReY
Just as a note, it''s actually NOT illegal to disassemble programs to *learn* from them, we just don''t need to tell anyone that we are *learning* to crack a game. . .

If the license agreement that you accept says that it is illegal to reverse engineer or disassemble the application, then it IS illegal to do so no matter what your reason is. People should read those things... Do you realize that you probably no longer own your own soul?

As for preventing hacking, I say why bother? There''s nothing that will deter a determined "professional." You''re really just wasting your time and annoying your legitimate customers. I suggest putting that effort into making a game that is so fun that everyone will want to buy it.


Josh
http://www.jh-software.com