Nothing can be more frustrating than discovering a mistake without the source code being able to modify it. It is for this reason that the Java anti-compiler appears, which can completely turn the compiled bytecode back into source code. Although the code anti-compiler is not just for the Java language, it has never been used publicly or extensively as in Java developers.
The opposite of anti-compilation is obfuscation. It is not so easy to protect your code and valuable technical secrets, assuming that the anti-compiler can easily get the source code from the compiled code. With the widespread use of the Java anti-compiler, the Java obfuscation processor is also popular, and its role is to put a smokescreen in front of your code. Anti-compilation and obfuscation have sparked a debate in the field of business development-much of the debate is focused on the Java language.
In this article, I'll let you understand the specific process of code decompile and obfuscation, discuss the theoretical issues behind these two technologies, and briefly talk about the controversies they cause in the field of business programming. I'll also introduce some of the more famous anti-compiler and fuzzy processors (commercial and open-source), and use them to create some examples as the articles go deeper.
What is anti-compilation? Anti-compilation is the process of translating the target code into source code. This should be clear, because compiling is a process of translating source code into target code. But what is the target code? The general definition is that the target code is a language-based code that can be executed directly from a real or virtual machine. For languages like C, the target code typically runs on the hardware CPU, while the Java target code typically runs on the virtual machine.
Anti-compilation is difficultAs described above, anti-compilation sounds simpler, but it is actually very difficult-essentially, it involves inferring large-scale, high-level behavior based on small-scale, low-order behavior. In order to have an intuitive understanding of this, we see a computer program as a complex corporate organizational structure. Senior managers gave their subordinates a similar "maximize technical productivity" command, and the subordinates turned these commands into more specific actions, such as installing a new XML database.
As a new employee of the company, you might ask subordinates what he or she is doing and get an answer, "I'm installing a new XML database." "From this sentence, you cannot infer that the ultimate goal is to maximize technical productivity. After all, the ultimate goal is different, such as the possibility of separating the supply chain or accumulating consumer data.
However, if you are a curious type of person, you may ask a few more questions and have different levels of subordinates in your company answer your questions. Finally, when all the answers are summed up, you may guess that the bigger goal of the enterprise is to maximize the technical production capacity.
If you think of the way a computer program works like a company's organizational structure, then the above analogy will give you a direct impression of why the decompile code is not irrelevant. From a comparative theoretical point of view, here to cite the outstanding researcher in this field Cristina Cifuentes describes the anti-compilation process:
Any binary retrofit project requires the disassembly of the code stored in the binary file. Theoretically, separating the data and code on von Neumann is like a downtime problem, so a complete static translation is not possible. However, different techniques can actually be used to increase the proportion of code that can be statically translated, or to take advantage of dynamic translation techniques that can be used in operation.--"Binary reengineering of distributed Object Technology"(See Resources)
Translating the target code into source code is not the only problem that comes up when you decompile it. A Java class file potentially contains a number of different types of information. Knowing what kind of information your class files might contain is important to understand how you use that information and what you do with it. This is actually what the Java disassembler is going to do.
Disassembly of a class fileThe true binary format of Java class files is not very important. It is important to know what different kinds of information are included in those bytes. At this point, we'll take advantage of a tool that most JDK has--javap. JAVAP is a Java code disassembler, which is different from the anti-compiler. The disassembler converts the object code in machine-readable format (as shown in Listing 1) into human-readable code (as shown in Listing 2).
Listing 1. The original contents of a class file0000000 feca beba 0300 2d00 4200 0008 081f 34000000020 0008 073f 2c00 0007 0735 3600 0007 07370000040 3800 0007 0a39 0400 000a 0007 0a150000060 0800 000a 0008 0a17 0800 1800 0009 ...
Listing 2. Output of JAVAPLocal variables for method void Priv (int.) Foo This pc=0, length=35, slot=0 int argument pc=0, length=35, slot= 1Method void Main (java.lang.string[]) 0 new #4 3 invokespecial #10 6 return
Note that the source code is not shown in Listing 2. The first part of the list lists the local variables of the method, and the second part is the assembly code, which is also the object code that people can read.
element in a class file  JAVAP is used to disassemble or unpack a class file. Here is a brief list of the information contained in a Java class file that can be disassembled by using JAVAP:
- member variable. Each class file contains all the name information and type information that corresponds to each data member of the class.
- After disassembly method. Each method of the class is represented by a string of virtual machine directives, with its type signature. The
- line number. each section in each method is mapped to the source code line, where possible, the source line is used to generate the section. This enables real-time systems and debuggers to provide stack traces for programs that are in a running state.
- local variable name Once the method is compiled, the local variables of the method do not require a name, but they can be included by using the-G option on the Javac compiler. This also enables real-time systems and debuggers to help you.
Now that we have some knowledge of the internals of the Java class file, how do we see how we can transform this information to achieve our goal? So there are small partners who want to know how to prevent anti-compilation, the small part recommends a related protection tutorial here:
Friendship recommended Love Encryption: A brief introduction to the security analysis of a social app to prevent the anti-compilation method of the app
About: The internal situation of Java class files Course Detail analysis