This technology includes the Java byte code and resources encryption, custom class and resource loading, and implementation of "detect and reject" tactics for preventing interception and other hacker attacks. Java Antidecompiler uses "keyless encryption". It means that the encryption key is not hard-coded but calculated at runtime and thus can't be extracted from the decompiled code.

The diagrams below show both the protection process and the workflow of the protected application as well as a few code snippets.

Java Antidecompiler API work-flows

Diagram 1. Protection step by step
The protection process consists of several simple steps:

1. Opening the source API jar file and any dependencies files, if they are present. The user will select these files at the beginning of the process wizard.

2. Validation of the original jar API for correctness. This is crucial, as the next step involves parsing, and we want to avoid unnecessary issues. Additionally, we will check for any hacking attempts in the source API, such as dumping, reflection, and so on.

3. The next step involves extracting the mockups of all classes included in the API. This is done using simple byte code manipulation and reflection. An example snippet for extracting method headers is provided below

4. A static callback method will be inserted into each class mockup for switching the class loaders (see Diagram 3).

5. In the last stage, we will collect class mockups, the encrypted source API, and add the Preloader and SerialNo classes to work in production mode. This way, we will have a protected API.

Diagram 2. Compilation or development time









It should be noted that the snippet codes are simplified and can’t be used in real apps. Additional technological underpinnings of our algorithms can be found in our Apology blog and DZone I, DZone II pages.