Share: about how to use the anti-compiler, get the source inventory method

about the anti-compilerConceptually, the anti-compiler is very simple to use. He just turned the compiler upside down: you give it a. class file, it also gives you a source code file.
Some of the newer anti-compilers have a sophisticated graphical interface. But in the first example, we're going to use Mocha, which is a publicly available anti-compiler. At the end of this article, I'll talk about a newer anti-compiler under the GPL. (See Resources, download Mocha and get a list of Java anti-compilers. ）
Let's assume that there is a class file named Foo.class in the directory. It is very easy to decompile it with Mocha, just type the following command:
$ Java Mocha. Decompiler Foo.class
This generates a new file named Foo.mocha (Mocha uses the Foo.mocha name to avoid overwriting the original file's source code). This new file is the source file for Java, and assuming everything goes well, you can now compile it properly. Just rename it to Foo.java and you're ready to go.

But here's the problem: if you run Mocha on some code that you've changed, you'll notice that the code it generates is not exactly the same as the source code. Let me give you an example so that you can understand what I mean. The original source code shown in Listing 3 is from a test program named Foo.java.
Listing 3. A small part of the original source code of Foo.javaprivate int member = 10;       Public Foo () {int local = Returninteger ();       System.out.println ("Foo constructor");     Priv (local); }
The following is the code generated by Mocha
Listing 4. Source code of Foo.java generated by Mochaprivate int member;           Public Foo () {member = 10;           int local = Returninteger ();           System.out.println ("Foo constructor");       Priv (local); }
The member variable member of the two code fragments is different from the position initialized to 10. In the original source code, it is represented as an initial value in the same row as the Declaration, and in the compiled source, it is represented as an assignment statement in a constructor. The post-compilation code tells us a bit about how the source code is compiled, i.e. its initial value is compiled as an assignment in the constructor. You can learn a lot about how the Java compiler works by looking at its anti-compilation output.
Anti-compilation is difficult: Keep repeatingAlthough Mocha can indeed disassemble your target code, it does not always succeed. Because of the difficulties, no anti-compiler can accurately translate the source code, and each anti-compiler handles their translation of the vulnerability in a different way. For example, Mocha sometimes has some problems with the structure of the output accurate looping structure. If this is true, it will use pseudo-goto statements in the final output, as shown in Listing 5.
Listing 5. Mocha cannot correctly decompileif (I1 = = i3) goto 214 Else 138;           J3 = GetSegment (i3). Getzorder ();           if (J1! = 1) goto 177 else 154;           if (J3 > K2 && (!k1 | | J3 < J2)) Goto 203 Else 173;           Expression 0 if (J3 < K2 && (!k1 | | J3 > J2)) goto 203 Else 196;           Expression 0 if = = Goto 201 Continue; I2 = i3;
       Aside from Mocha's question, the anti-compiler can normally translate the source code more accurately. Once you know the weaknesses of an anti-compiler, you can manually parse and transform the post-compilation code so that they conform to the original source code more accurately. As the anti-compiler is becoming more and more outstanding,
       We ran into another question: What if you don't want anyone to decompile your code? Small in this friendship recommendation: Love encryption Android hack technology? How to Anti-compilation, the explanation is also good: http://www.ijiami.cn/newsInfo?id=289&v=3

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Share: about how to use the anti-compiler, get the source inventory method