OSDev.org

I've just finished my encryption program, but I have one concern:

How can I prevent disassembly?

The concern arises because my program is relatively lightweight. Unfortunatley, I don't have much experience with disassembly, so disassembling it myself and trying to backtrace isn't an option.

Don't even try.

The old mantra: "There's no such thing as client side security."

If it's on their machine, they can break it. Simple as that.

JamesM wrote:Don't even try.

The old mantra: "There's no such thing as client side security."

If it's on their machine, they can break it. Simple as that.

I guess for my personal uses, I know everyone who uses my computers couldn't disassemble a clothes-pin, let alone a computer program...

But I'd give some of you guys on this site about 20 minutes. So in a word: t'sucks.

dudeman wrote:I've just finished my encryption program, but I have one concern:

How can I prevent disassembly?

The concern arises because my program is relatively lightweight. Unfortunatley, I don't have much experience with disassembly, so disassembling it myself and trying to backtrace isn't an option.

Do you mean lightweight as in - if someone had access to the source, then he/she could easily decrypt previously encrpyted data? If so this is very bad and you need to rethink your encryption program. All the proven/accepted ciphhers/hashes/whatever have been open sourced and tested by many people and are proven to be secure.

About disassembly - what you want is a packer ( I assume its a PE file? ). If you just want something to pack your file then find a later version of asprotect. If you want to learn about it yourself then google binary protection, and make sure to read:

http://www.phrack.org/issues.html?issue ... 3&mode=txt

Ideally you want something that will pack/unpack parts of your binary on the fly after execution, unpacking at the beginning is pretty useless.

You can't stop anyone skilled at Dissasembly. However you can harden Static Code Analysis, Ease of Understanding and Perhaps even add code to make it extremely difficult to reproduce.

Firsty, get an Logic Code Obfuscator (not just something that makes the source code unreadable, but that actually makes following the object code hard)

Secondly, Encrypt your application (using some other algorithm), and decrypt it at launch time, this prevents Static Code Analysis on the actual file (until they decrypt it at least).

Also, Dynamic Code Creation at runtime that spreads the code across the heap is complicated to develop in a useful way, but should set dissasembling back till only the top 20% of people trying to dissasemble would bother, and those people probably have absolutely no interest in your application.

However, Any algorithm that requires people to not see it in order to be secure, is not secure. The best algorithm's are public knowledge, have been eavily analyzed and still continue to keep data secure.

i suggest including a whole bunch of functions that are never called, and perhaps do some fancy bit twiddling, like something taken from an OS.

this will mean the eventual code is much longer, and that inexperienced disassemblers will get easily lost.

Do you mean lightweight as in - if someone had access to the source, then he/she could easily decrypt previously encrpyted data?

I mean lightweight as in small number of source files.

Also, Dynamic Code Creation at runtime that spreads the code across the heap is complicated to develop in a useful way, but should set dissasembling back till only the top 20% of people trying to dissasemble would bother, and those people probably have absolutely no interest in your application.

Ha ha, yeah, I'm not hiding any great secrets, nor do I think the top code-breakers have any interest in my program or what it would ultimately be used for.

However, Any algorithm that requires people to not see it in order to be secure, is not secure. The best algorithm's are public knowledge, have been eavily analyzed and still continue to keep data secure.

Hmmm. What exactly do you mean? If I tell you how my program works it wouldn't be too far off from showing you the source code? How can a public algorithm be secure (not that I doubt what you're saying, I'm just curious how that works)?

No offense, but how can you develop and encryption algorithm if you haven't studied the field?

Take a look at AES, it's details are public knowledge and anyone can implement an encryptor or decryptor supporting it (i have written many). However, simply having this knowledge doesn't mean i can break into data without the Key, because the algorithm is completely secure.

Unfortunately i've never studied the mathematics of Encryption, due to the amount that isn't in the public domain, i've never been interested in pursuing the topic. Perhaps one the NSA releases the research that put's them 50 years ahead of us, i'll begun to study it.

I also advise, reading some Bruce Schneier, for a good description of how Cryptography works in general </plugging the god>

good encryption algorithms rely on the fact that there is a key (say, a password) that is unknown to third parties. The algorithm is such that you cannot retrieve the encrypted data, nor can you deduce the key. Only with the key you can decrypt encrypt the data.

People can more easily remember a key, and even if a key is found then all data encrypted with a different key is still secure, even though it uses the same algorithm.

Such algorithms are based around the fact that they aren't prone to any attacks, except brute force. For a key of sufficient length, this would take longer than the unverse's lifetime, and hence is not worth trying.

If the algorithm is the secret, then there need be only one leakage to allow all encrypted data ever to be decrypted, hence making the algorithm useless.

The main difference is that keys are trivial to make, while algorithms are not. A lost key can easily be substituted for a new one. An algorithm can not.


Once again: inventing algorithms is for the experts in the area. If you want security, use something that has survived real life: AES, Blowfish, RSA

good encryption algorithms rely on the fact that there is a key (say, a password) that is unknown to third parties. The algorithm is such that you cannot retrieve the encrypted data, nor can you deduce the key. Only with the key you can decrypt encrypt the data.

in that respect than yes, I suppose the algorithm doesn't matter. If you'd like to hear it, here ya' go:

1. user creates password.

2. a key is generated by using a 3-variable pdf (probability density function).

3. this key dictates how the info is encrypted as it enters a 3-D array ([8][8][8]). -there are as many of these arrays as needed.

Now the best part:

4. the key is never reused, in fact, it not only defines the encryption techinque, but also the next key to be used in the next array (all these arrays are placed in a queue btw).

5. The user can actually set the level of encryption, the only consequence being, the higher the level, the more useless crap is inserted, and therefore producing more and more bloated a file. But even on a low setting I'm fairly comfortable with the level of security.

I've never studied encryption, and I really have no way of testing its effectiveness.

Pleez do tell me how this seems as far as an encryption technique, I'd like to learn more, I think it's interesting.

There are some companies word wide that can protect as well your application.
In case that you are not a company and you don't want to spend money, you have to make a protector for your applications.

The most commot executable format now for windows is PE-32.

The first think you have to do is to make an PE-32 editor. Find a similar application over the internet and compare the results with your application. If results are same, then you have fully understand the PE structure.

After that you are ready to add functionallity for software protection.

Below you will find some protection methods that an executable protector must do.

Encryption.

Every section of PE file must be seperate encrypted.
It's good to be used different algorithm of encryption in every protection, to prevent generic cracks.
Encryption can be in levels and parts. It's better to decrypt only the part of code that will executed. After the execution it's good to encrypt again.

Compression.

Some of PE file sections can be compressed

Anti-Dump

Most hackers use code dumping to get the decrypted executable from memory. Applications that do this, uses the process information and dumps the executable as it is in the memory. But don't dumps automatically the memory areas that application has allocate. So it's a good trick to decrypt some parts of your code to allocated memory. To do this you must write your code without relocations (data), so can be executed as well in any memory address.

Import table

You must encrypt and remove the original import table. Without import table is impossible to the hacker to reconstruct the dumped file.
Create your own import with two entries only. GetProcAddress and LoadLibrary. Thats all you need to fixup all import calls at runtime. It's also good to recreate the original import table to allocated memory and not at the original place.
Decrypt one function name, resolve the address, delete the function name from memory and then go to the next imported function (anti-dump).

Relocation table

In most executables is useless, but if you want to make a good protector, you must handle relocations as well. The method is simmilar to resolving import table.

Original EIP

It's good trick to put the protector's code to different start of original executable. Keep the original EIP to know where this original application will start when the protector's job done.

Debug prevention

There are a lot of common methods that prevent debugging. The most are useless because is known from hachers and can bypassed easylly.
The only good debug prevention for me is to put dummy code between critical (protectors) code. This will mess the debugger while disassembling, and hides some instructions.

Encrypt it over and over again for about 100 times. With different algorithms and keys! It might take forever to start up but it'll be more secure.

The problem with encryption, is that they key must be hidden inside of the executable along with the code to decrypt it.

So you do it over and over again 100 times just to piss the deassembler (hopefully they give up a around 5/6 times).

This isn't very secure though, since the final executable becomes extracted in memory so someone could extract the code from a memory dump.

If the user uses something, then there is no way to make it secure. Take DRM for instance. If I have a DRM'ed song, and want to deDRM it, all I have to do is play it, and record it somehow. (It won't be of the highest quality, but I'm no audio buff.) If I can hear, see, or experience something, then somewhere, somehow, it is in an unencrypted form on my computer or airwaves.

It's a pointless effort.

lukem_95 wrote:i suggest including a whole bunch of functions that are never called, and perhaps do some fancy bit twiddling, like something taken from an OS.

this will mean the eventual code is much longer, and that inexperienced disassemblers will get easily lost.

Do NOT do this.. any decent compiler will simply optimize all this out
Also I do not think he is worried about inexperienced disassemblers.

Anyway there seems to be alot of lost hope in this thread. There are packers that unpack say X bytes, run the code they contain, repack them, and grab the next X bytes. Even with alot of skill & patience its quite painful to full reverse something like this.

Also what about applications that implement their own small virtual machine that emulates instructions. Now not are you only reversing the application but you first have to figure out the small emulator included with them.

Protecting your application on disk and in memory is not 100% possible, but it is not as hopeless as this thread makes it seem.

It's all merely obfuscation. The only way to prevent someone from disassembling your code is to not give them the key. Which means they couldn't run the code either.

Everything else is just making it less easy. Which might result in just the opposite, in that hackers feel challenged...

I don't see the sense in this, anyway. You can't effectively protect your IP that way, and as an encryption scheme, it's a hoax.