   Code Encryption
  Any type of programming language is compiled down to machine code. This being C++, C, or any other type of language out there. Is it possible to take a function/method written in C++ and encode it using 128 bit encryption? For example, lets say joe hopes on the program, he opens it up and puts his username and password in. It creates a decryption key and it jumps and decodes a function that reads all the data into the program. Without doing that the program will not run.Now lets say joe losses the software and is now available over some bit torrent web site. Some hacker has attempted to jump over the username and password section of code in assembly, but is currently stuck because the function/method has been encrypted. Myself I have heard of it been done, but I cannot find and reference about how to go about doing it within C or C++ to encode a function a compile time, and decode it during runtime.    
  uh, or that hacker just grabs the decripted code in memory (the second its decrypted), before rewriting the exe so that it will run without the username/pass.You forget that the hacker already paid for the software.   ;  As NiceCoder says this is an effort in futility. It stops nothing.However, if you are still interested I would suggest reading up on the P.E file format (the format used for Win32 Exes). It would be easier to have the whole EXE encrypted with a decoder stub than just encrypt one section (if the section to be encrypted has alot of outside dependancies). Also look at the way that executable compressors work - the idea is the same.The only time I have seen code encryption serve a purpose was for viruses to avoid detection software - The bulk of the virus body is encrypted/compressed and a polymorphic loader stub is used to decrypt\uncompress the virus as required.(I previously worked with polymorphic code techniques from the dual perspectives of optimisation and virus detection).Mike.;  Yes i have considered that, and they can do it I know i've done it myself. Im more or less looking for ways to make modifications to the exe much more difficult for a hacker. Pretty much removing 80% of the script kiddies from hacking the software. I do know that proventing sombody from hacking the exe is allmost impossible, but making sure only the top 5% of hackers can actualy do it is another thing.   ;  You don't even have to watch for the decrypted code, you just watch for the constructed key, and then provide that to the decryption process, regardless of the username and password the user provides at startup (if it's not removed entirely)   ;Quote:Original post by doodoYes i have considered that, and they can do it I know i've done it myself. Im more or less looking for ways to make modifications to the exe much more difficult for a hacker. Pretty much removing 80% of the script kiddies from hacking the software. I do know that proventing sombody from hacking the exe is allmost impossible, but making sure only the top 5% of hackers can actualy do it is another thing.Hélas, script kiddies don't hack. They use already hacked softwares, hacked by the top 5%. If your software is popular enough, it will be hacked, no matter what the protection is.Regards,   ;Quote:Original post by doodoYes i have considered that, and they can do it I know i've done it myself. Im more or less looking for ways to make modifications to the exe much more difficult for a hacker. Pretty much removing 80% of the script kiddies from hacking the software. I do know that proventing sombody from hacking the exe is allmost impossible, but making sure only the top 5% of hackers can actualy do it is another thing.Doesn't matter.It's enough that one person manages to hack your app. Then he puts it on a bittorrent website, and *everyone* can get it.So unless you can prevent *everyone* from hacking your app (which you can't), it's a waste of time.   ;  You can't stop hacking, but you can get the hacker---and provide strong incentives against hacking.When a user buys your software, digitally sign it to that person's personal information (name, address, etc., whatever you use to charge his credit card), in a very subtle, impossible-to-detect way. Like, for example, the order of the functions in the executable binary (of course don't use this method since I've already mentioned it).If he hacks the program and distributes it, you can link the torrent EXE back to the person who bought the software.Meanwhile, have some self-patching/self-updating code in your game, which is responsible for auto-fixing bugs as the fixes are made available. If your server detects the EXE calling for self-patching is actually hacked (because you have registered it as so on the server), it can send back both the patch, along with some other code, that, when activated at some point in the future, will attempt to destroy the user's sytem.This is not foolproof but it's very good.I want each CPU to come with its own private/public key. When buying software, the customer's CPU will supply the public key to the website server, which will then use the key to encrypt the data, and send it back to the customer. The CPU is the only thing that can decode the software, using its private key which is inaccessible to the rest of the world. It just needs to take care that no one can access the memory of encrypted code.This will put an end to piracy.   ;Quote:Original post by Anonymous PosterYou can't stop hacking, but you can get the hacker---and provide strong incentives against hacking.When a user buys your software, digitally sign it to that person's personal information (name, address, etc., whatever you use to charge his credit card), in a very subtle, impossible-to-detect way. Like, for example, the order of the functions in the executable binary (of course don't use this method since I've already mentioned it).If he hacks the program and distributes it, you can link the torrent EXE back to the person who bought the software.Meanwhile, have some self-patching/self-updating code in your game, which is responsible for auto-fixing bugs as the fixes are made available. If your server detects the EXE calling for self-patching is actually hacked (because you have registered it as so on the server), it can send back both the patch, along with some other code, that, when activated at some point in the future, will attempt to destroy the user's sytem.This is not foolproof but it's very good.I want each CPU to come with its own private/public key. When buying software, the customer's CPU will supply the public key to the website server, which will then use the key to encrypt the data, and send it back to the customer. The CPU is the only thing that can decode the software, using its private key which is inaccessible to the rest of the world. It just needs to take care that no one can access the memory of encrypted code.This will put an end to piracy.The idea behind this is already in use and is the only truly "hackproof" method that I've seen.  Specifically selling the person the key instead of the software.  Look at Valve. however the good point you brush against is mixed with some incredibly bad points.First, if Microsoft and it's lawyers are not allowed to grab personal info on those who steal their OS, you'll most likely run into a heap of problems yourself if you try.  People dislike being spied on.Next, preventing access is fine, but destroying a user's system?  Please tell me you're joking.  Even assuming that it isn't some parent's kid who activates your kill code at the system and you end up destroying the parent's files.  Assuming the kill code is activated on the purpotrator's computer, it's still a moral abomination.  Imagine a digital artist who has five years of their work stored on the system and you destroy all of that because they attempted to steal your program.  It's like slitting a person's neck because they punched you.   ;Quote:Next, preventing access is fine, but destroying a user's system?  Please tell me you're joking.  Even assuming that it isn't some parent's kid who activates your kill code at the system and you end up destroying the parent's files.  Assuming the kill code is activated on the purpotrator's computer, it's still a moral abomination.  Imagine a digital artist who has five years of their work stored on the system and you destroy all of that because they attempted to steal your program.  It's like slitting a person's neck because they punched you.Actually I care around a knife at all times and would not hestitate to stab someone if they tried to attack me. My property is my property.I'm perfectly fine with destroying someone's computer because they or their children downloaded pirated software. They brought the problem upon themselves (either directly, or by not controlling what their kids were doing/giving them their own computers).   