Code Encryption

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 doodo 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.

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 doodo 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.

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.

Quote:

Original post by Anonymous Poster 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.

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:

Original post by Anonymous Poster 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).

That is rationalization for [a] lack of impluse control. What you suggest would be illegal.

[Edited by - Shannon Barber on April 13, 2006 9:56:45 PM]

Quote:

Original post by Anonymous Poster 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).

Okay, just make sure you tell us your name / the name of your software so that we can be sure not to buy it.

Certain major copy-protection systems use binary code encryption for security, to help slow down hacking efforts. The encryption is sophisticated enough that even attaching a debugger to the process memory and trying to read the code segments doesn't always produce sensible machine code.

The technique is useful, but it takes a huge amount of work to get it "right" in the sense that it is actually robust enough to deter hacking. Even stub-based decryption (e.g. UPX) is easy to defeat by careful process memory-space injection.

Many products encrypt machine code as a form of protection, but that is effectively worthless because the code must be decrypted to run on a CPU, and it's almost trivial to obtain the decrypted code from memory.

There are two somewhat related methods that are very effective, however:

The first is obfuscation. Instead of encrypting the executable, you essentially disassemble it and create code that does the same thing in a very nonobvious way. For example, instead of ever jumping directly somewhere, you could make every jump based on some value in a table, such as "jump table[eax*4]" and then have both the table and the registers modified as the program progresses so that it will be correct at each location for that location only. Thus, in order to change the program, the reverser must manually modify each jump, which could be difficult since a jump might be static or it might be dynamic (maybe the register is initialized using one of the SETcc instructions, or is calculated based on some formula to make a switch-like structure, etc) and each possible branch must be moved to a table specific to that one jump.

Second, there is virtualization. Essentially, the idea is that instead of encrypting machine code and decrypting it to feed the CPU, you can instead just make your own virtual machine that doesn't need the code decrypted. Either the virtual machine encrypts it's own state so that when it compares it with the input, it will match the same as if both were unencrypted, or the VM only decrypts one instruction at a time, which would make getting the code separated, entirely decrypted, and disassembled (which involves them creating an assembly language for your undocumented bytecode) very difficult. You can also employ simple tricks like using a linear congruential psuedorandom number generator to get the next instruction's address instead of simply incrementing a pointer. It would destroy cache coherency, but it would be confusing and difficult to analyze.

Then there is the best approach, which is to use virtualization and obfuscation together, interleaved, so that both a virtual machine and the actual CPU are doing things at the same time, and neither one is clear at all. By applying the obfuscation to the virtual machine, it becomes even more difficult to understand that part of the scheme. I believe this approach is the one taken by starforce (in addition to other things that should be entirely ignored for ideas, since those other things prevent legit customers from using the product), and for a less espensive solution, you could use something like EXE Cryptor (which I've heard a few good things about, but haven't used)

Quote:

Original post by Anonymous Poster ... along with some other code, that, when activated at some point in the future, will attempt to destroy the user's sytem.

Yeah. Kill them, kill kill kill!. They deserve it.

(BTW Why don't you steal the credit card info instead?)

Quote:

Original post by doodo 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.

My 2 cents:
A Thought... Doing obfuscation in C# or .Net in general is one thing and is fairly easy to reverse... (People already do it... nothing free out there, but you can get this done.)

Attempting to do this in C/C++ seems to be pointless... The people who hack C/C++ Code are very different than the people messing with C#/.Net Code...

Basically - For C/C++, it may be pointless as these hackers are 'generally' more intelligent that the C#/.Net hackers (which may not be considered hacking)

If you do this to C/C++ Code, your are going to slow your app... If you decrypt once and leave it in memory, than, again, it's pointless...

If I were you, I'd release a "Warez"/"Leaked" version myself with features missing or purposly buggy... At least this way, it will take longer for someone else to distribute it as you already have... (Basically - push a "shareware" version out, but don't label it so... If you have enough features on it people may not notice and you can leave bugs in it =D)

People have hinted at this but in my experience when we add encryption of any kind its not to stop hackers but mearly slow them down. I know lots of software, especially games, the majority of sales are in the early time frame from when they are released.

How long that time frame is is dependent on the software, for games its usally 2-3 months, for photoshop its closer to 6 months. All we hope for from our encryption is to get past this date. Any thing else is gravy.

Cheers
Chris

Maybe this is of interest:
http://www.strongbit.com/execryptor_inside.asp

There they describe a new apporach called code morphing. Basically the exe protector replaces the code of a function with code that performs the same calculation (i.e. is functionally equivalent), but is very hard to analyze (i.e. with tools like IDA). You don't need encryption, your code is fully functional all the time.

Quote:

Original post by nmi Maybe this is of interest: http://www.strongbit.com/execryptor_inside.asp There they describe a new apporach called code morphing. Basically the exe protector replaces the code of a function with code that performs the same calculation (i.e. is functionally equivalent), but is very hard to analyze (i.e. with tools like IDA). You don't need encryption, your code is fully functional all the time.

It's not new. It's old enough that the general technique has an official name that is an english word ("obfuscate"), and my entire large post discussed such techniques and also contained the link to the same product(though mine was to the main page).

Quote:

Original post by Anonymous Poster I don't agree. The technique used in ExeCryptor is called code morphing. It is similar to 'obfuscation' hozever it is not just the same. The transformation is not on source code level but in the machine code one. This is very innovative in win32 apps protection.

Yes, it's assembly/machine code obfuscation. It's also part of many protection schemes, such as StarForce. It was also used in viruses. Yes, polymorphism was the buzzword, but there were plenty that didn't do that but intentionally contained difficult-to-understand machine code sequences to help avoid dissassembly/decompilation.

Quote:

Original post by Anonymous Poster I don't agree. The technique used in ExeCryptor is called code morphing. It is similar to 'obfuscation' hozever it is not just the same. The transformation is not on source code level but in the machine code one. This is very innovative in win32 apps protection.

Are you talking about polymorphic code? There are exe smoothers, that could get rid of majority of obfuscations. Not to mention that OS could call heavily obfuscated code as unsafe and deny execution. It's also very bad for antiviruses, but surprisingly not as bad for virus manufacturers.

BTW It's from 1995 year inovative. Virus creators has tools for efficient polymorphing code for a long time. People that are using this for theirs own code protection obviously never tried to recover theirs own code from encrypted exe (after code base loss).

Are you the same nony that tryed to recommend a criminal activity for code protection?

Quote:

Original post by Anonymous Poster 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. 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.

wouldnt you just be better with some hackers and a few loyal customners than 50,00 lawsuits from people who had their machine destroyed becouse they upgraded their cpu or thir digital signature got corrupted