Java obfuscator logging guard

Java obfuscator logging guard

Java obfuscators retroguard-v2.3.1
JavaCodeThe. Class generated after compilation containsSource codeAll information in (excluding comments), especially when debugging information is saved. Therefore, a normally compiled java. Class file can be decompiled very easily. There are many decompilation tools, one of which is very powerful is Jad.
To avoid this situation and protect developers' work, another tool called Java obfuscator is developed. Java obfuscators are used to confuse compiled code, making it hard to be confused by decompiled code or decompiled code. There are also many Java obfuscators. One of the more powerful ones is javasguard (I only say it is strong because I still have some doubts about its efficacy ).

Here I will introduce how to use guard.
Decompress the downloaded .tar.gz or. ZIP file. Only the javasguard. jar file is useful. The others are source code and documentation.
Producer guard obfuscated jar files. You need to configure it before using it. You can manually edit the configuration file. A better way is to use the GUI tool provided by Alibaba guard to generate the configuration file. The usage is as follows:

Java-classpath extends guard.jar;xxx.jar;yyy.zip;... rggui 
Set parameters in the Wizard of the GUI. The above-classpath should list all packages on which the jar to be obfuscated depends.
For details about how to use rggui, see the docdocs.html documentation of Alibaba guard.
After the configuration file is generated, you can run mongoguard for obfuscation. The usage is as follows:

Java-classpath xxx.jar;yyy.zip;... javasguard vvv-unofb.jar vvv. Jar vvv. RGS vvv. Log 
Here, the vvv-unofb.jar is the unobfuscated JAR file, vvv. jar is the JAR file generated after obfuscation, vvv. RGS is the configuration file, vvv. log is the log file. The default configuration file name is script. RGS, and the default log file name is mongoguard. log.

Note the following when generating the configuration file:
1. All public class names, method names, and variable names should be retained. Because all the content set to public represents the interface of the entire package. If a content is not intended for external access, it should not be set to public.
2. If a class in the package uses Java. lang. class or Java. lang. A Method in classloader loads a class. If this class is out of the package, no special processing is required. If this class is in the package, you need to keep the class name of this class, otherwise, this class cannot be found after obfuscation.
3. All debugging information in the package (source file name, row number, variable/parameter information, etc.) should be deleted.

Mongoguard also has a so-called "incremental obfuscation" Method for patching. The main point of this method is to use the log file generated in the last obfuscation as the configuration file for the next obfuscation, so that you can generate a patch jar that only contains modifications. Put this path jar before the last obfuscated jar in classpath. There are two methods for this incremental obfuscation:
1. Each patch jar contains only the changes that have occurred since the obfuscation of the previous version, so that each patch jar will be small, but the classpath will grow.
2. Each patch jar contains the changes that have occurred since obfuscation of the previous major version (2.0, 3.0, and 4.0), so that the patch jar between the two major versions will become larger and larger. However, classpath only requires minor changes.
Original article: http://download.csdn.net/source/4103531.