Java program anti-Encryption

Anti-encryption of Java programs-general Linux technology-Linux programming and kernel information. The following is a detailed description. First, let's take a look at the anti-encryption process of Java programs, that is, the Crack process. Only by understanding this process can we effectively encrypt our programs.

We usually get two types of Crack packages for Java programs: one is KeyGen (registration code generator) and the other is replacement modification;

First, let's look at the first one. When we find the KeyGen of an application, we always admire the person who made the KeyGen and think it is amazing, but you should analyze it carefully, why does he make KeyGen? Only
He knows very well about the encryption algorithm of this Java program. What are such people? One is the person in the company. That's impossible. Unless it's inner, it's still like conjecture and reverse push. Is this possible? Oh, that's even worse. Where does this algorithm come from? The secret itself is often leaked ...... Looking back, how does the Java application know that the registration code you entered is correct? Well, you should start with the application ......
The obtained encryption algorithm naturally comes down with KeyGen ...... (But this is also exclusive. If it is encrypted using a public key pair, there is no way to do it. You can only use the second method .)

This method is only suitable for dealing with situations where there is only one registration number and nothing else, classic representatives Borland JBuilder & Optimizeit Suite

Let's look at the second one. Why do we need to replace and modify it? We modified that part? Don't think about it. It must be part of License verification. Why don't we look for encryption algorithms like the above method? There are two reasons: (1) using the above method for uncertainty; (2) Java requires not only the Key, but also other License configurations; in this case, we only need to find the class used for License verification and modify and replace it.

This method is used in any situation. The classic representative is BEA WebLogic.

After the above analysis, our problem is concentrated. The key is how to find the part used for License verification or the part of the encryption algorithm. We need three tools: one is the standard JVM provided by Sun, and the other is your
Patience and care :), one is Jad (a classic Java decompilation tool ).

The first step is positioning. This is also the most critical step. Here we take Together For JBuilder Edition as an example to start Together and see what it looks like first? Well, when I come up, I will ask for License. OK,
Every link exits. Find the Together startup Bat file and find its startup command: java ....., OK. When Java is started, give a parameter "-Xrunhprof: cpu = times", save the parameter, at startup, or
License, exit. At this time, we can find that there is an additional java.hprof.txt file in this directory. Open it and check that it is the Dump file of the jvm I want. There are a lot of contents. It doesn't matter. Let's take a look.

We can see a lot of familiar things in this file: java. */com. sun. */javax. * Wait, but this is not what we care about. What we want is com. togethersoft. * Or some zd without the package name. d. (In this example, almost all Java applications will be confused. In fact, the obfuscation principle is also very simple. Let's talk about it later .) First look for any License related, Serach, hey, sure enough, row 474: com.togethersoft.together.impl.ide.license.LicenseSetup.exe cute ([DashoPro-V2-050200]: Unknown line ), go to the Jar package in the heap classpath and find it (WinRAR is recommended). Find it and decompile it with Jad. At first glance, there is no confusion, but a zae class is used, after reading the name, you will know that it has been confused. Ignore it first, and then look at the following sentence IdeLicenseAccess. setLicense (zae1), OK, and then find IdeLicenseAccess. Haha. In this case, all License verification is implemented in this class. The object-oriented method is good. Haha :)

After the positioning is complete, the next thing is to modify the two classes according to the Conjecture method, block the actual content of the execute method in LicenseSetup, modify IdeLicenseAccess, and return true for multiple verifications, compile and replace it. Don't be too happy. It's not over yet. Be responsible !! Start Together. Sure enough, don't use License now. There is a boot screen and it goes in, but it's gray. What's going on? When you look at the console, there are a bunch of errors. It doesn't matter, you are afraid that there will be no errors, find the root cause. Another IdeLicenseUtil class has a problem, and then decompile, modify, and replace it. This is done. Start again, test, OK.

In this case, a Java application is ready. It's actually quite easy to see.

Let's talk about obfuscation. We may all know that the names of the methods and variables will not change after the Java Class is decompiled back. Why? This is to record the structure of the Class file. In short, the Class file contains another constant pool (constant pool) this stores the names of variables and methods and other things related to the Class. What we call obfuscation is to use a tool to blur the stuff in this constant pool, in this way, we can cheat the anti-compiler and you, huh, huh :) that's why sometimes The Decompilation back-to-back stuff cannot be compiled.