There is "compile" (compile), there is "decompile" (decompile), there is "decompile", there will be "reverse-compile." This is especially true for the middle yards of Java and. NET virtual machines.
The result of the Java program being compiled is the Java bytecode, and the. NET compiled results are CIL (Common intermediate Language), both of which have the following characteristics:
-the same stack-type (stack-based) instruction set.
-High-order object-oriented machine language
-Nothing to do with platform
-code Validation
-symbolic Link
Any of these features can make the program more easily decompile, and all five points are more difficult to combine. So it's fairly easy to decompile Java and. Net. The web is spread around the Java reverse compiler (Decompiler), you can turn the compiled file back to the original code,
believed soon afterwards. NET will also encounter the same problem. (At least, I'm trying to write a. NET decompiler, like sabotage.) ）
Just imagine if you would give someone a Java and. NET program that you've developed with your hard toil (Cai?). , as long as he can launch the source code through the counter compiler, your smart property is likely to be violated.
To protect yourself, you have to reverse-compile the Java or. NET software before shipping it, which is often called obfuscation (obfuscate). The confusing program code, still follows the original file format and instruction set, so it can still execute, and the execution result is the same as before the confusion. Only the confused code of the program becomes more messy and less easily decompile successfully.
Some Java development tools (such as JBuilder) have an enclosing obfuscation (obfuscator), or you can purchase a more powerful obfuscation. These commercial obfuscation usually only do three things:
-Organize each method internally in a more messy way.
-Remove symbolic data from Java Constant Pool, or within. NET metadata, such as the name of private method.
-Remove debug information, such as Java localvariabletable and linenumbertable, from all.
If the role of Obfuscator is just like the above general, only method local role, the effect is not.
To dramatically increase the difficulty of decompile, you must match the following:
Confusion within the-class: confusing the method within the class.
Confusion between-class: confusing relationships between classes, such as merging or dismantling parent categories and subcategories.
There are some academic papers to study the above two points, but the results are still small, and must be manually adjusted, can not be automatically processed by the software. This aspect deserves to be put into more in-depth research.
Confusing programs can run into the following questions:
-Usually the efficiency gets worse
-May not be able to execute. I want to be in a situation where it could be a mix-up or the JVM's fault.
If the confusion between the "class", a little careless, it is likely to be unable to implement. " For example: Java program if useful to instanceof, or C # program useful to is, it is necessary to be very careful to "class between the confusion", otherwise disastrous consequences. "
The purpose of confusion is two levels:
1. Let the program not be automatically decompile: for example, make some extraordinary jumps (goto), let the program block
The relationship of (block) cannot be identified with a particular pattern.
2. Let the program even if the compiler is successful, and not easily read by programmers understand: find ways to add some difficult to see through the program code to deceive programmers.
Obfuscator is not a panacea, if met a proficient in obfuscating technology, with profiling Tools, the original code will fall into his hands. Therefore, when using obfuscator, you must have such psychological preparation: "To prevent a gentleman, may be a villain, to prevent fools, not smart people." It's best to put software in server instead of selling software to customers.
