Sharing: The principle and use of disassembly tools and fuzzy processing tools

anti-compilation and threats to securityAlthough, most of the code decompile is completely aboveboard, but the fact is that a good disassembler is one of the necessary tools for software infringement. This is why, especially for developers in the commercial and non-open source areas, the existence of cheap (or free) Java code disassembly Tools is a serious problem.
In terms of language itself, Java code is very easy to disassemble because of its relatively simple Java virtual machine (compared to a real microprocessor) and its well-written bytecode format. This, along with the growing popularity of the Java language in the Web development platform, has caused a lot of controversy in the field of commercial development. Since the first release of Mocha in 1996, companies and individuals who have invested in protecting their source code have been yelling at the Java anti-compiler.

In fact, when Mocha first published, its author Hanpeter Van Vliet was threatened by lawsuits from some companies (see Resources）。 At first, he removed the anti-compiler from his website, but he later offered a better solution in the form of Crema. Crema is a Java obfuscation processor that is completely opposed to Mocha.
Since the release of Crema, many Java obfuscation processors have begun to appear, some of which are commercial and some are open source. As you can see, a good Java blur processor protects your Java code to a great extent.
a confrontational code obfuscation
Code obfuscation literally means blurring the behavior of your code. The Java obfuscation processor changes the program in an imperceptible way, so that itsRunIt is identical to the JVM, but it makes it more confusing for those trying to understand the program.
Let's take a look at what happens when the disassembler encounters a obfuscated code. Listing 6 shows the result of Mocha after trying to disassemble the Java code that was obfuscated by a tool called Jmangle. Please note that the following small program is the same as the one we used in the previous list, although at first glance you would not think so.
Listing 6: Jmangle obfuscated codePublic Foo () {jm2 = 10;           int i = JM0 ();           System.out.println ("Foo constructor");       JM1 (i); }
A fuzzy processor like Jmangle converts many variable names and method names (and sometimes even the names of classes and packages) into meaningless strings. This makes it difficult to read the program, but for the JVM it is essentially the same as the original program.
become despicableAll of the fuzzy processors have to make the markup meaningless, but they do more than that. Crema is notorious because it uses a lot of despicable means to stop disassembly, and there are many fuzzy processors that have appeared to emulate it.
A common way to obfuscate code is to use an illegal string instead of a tag in a class file, which is a step further than using meaningless strings. The alternative might be a keyword, such as private, or even a meaningless tag like * * *. Some virtual machines-especially in browsers-don't respond legally to these wacky usages. Technically, a variable like = is the opposite of Java's specification; some virtual machines can ignore it, while others cannot.
Crema Placing BombsThe other trick that Crema uses, literally, is the bomb. The Crema has the ability to completely shut down the Mocha. It adds a small "bomb" to the compiled code, causing Mocha to crash when it tries to decompile the code.
Unfortunately, Crema is gone, but a tool called Hosemocha is specifically designed to shut down Mocha. To understand how Hosemocha works, we will use JAVAP, a trustworthy disassembler. Listing 7 shows the code before the Hosemocha placed the bomb.
Listing 7: The code before the bomb is placedMethod void Main (java.lang.string[]) 0 new #4 3 invokespecial #10 6 return
The following is the code after Hosemocha processing.
Listing 8: Code after placing the bombMethod void Main (java.lang.string[]) 0 new #4 3 invokespecial #10 6 return 7 pop
Did you see the bomb? Please note that this program now returns a pop statement after the return. Wait a minute--what can a function do after it returns? Obviously, it can't, and that's the key. Placing a directive after the return statement ensures that it will not be executed. What you see here is simply impossible to disassemble. Because it doesn't correspond to any possible Java source code, it doesn't make any sense.
But why is this small obstacle causing Mocha to collapse? Mocha can simply ignore it, or send a warning message and go on. Although Mocha's vulnerability to such bombs can be considered a procedural error, it is more likely that Van Vliet deliberately set up in response to an attack on Mocha.
so far, we've learned about older disassembly tools and obfuscation tools--though a bit outdated, but still better. However, similar tools have become more mature over the years, especially in the graphical interface. At the end of this article, if you do not want anyone to decompile your code, small in this friendship recommendation: Love encryption How anti-compilation, the explanation is also good:http://www.ijiami.cn/newsInfo?id=289&v=3

Sharing: The principle and use of disassembly tools and fuzzy processing tools