How It Works


Java Antidecompiler uses a new technology developed by BIS Guard & Co. and patented (priority of 2002)

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

Java Antidecompiler work-flow





Java Antidecompiler contains Antidecompiler itself and Java Preloader. Antidecompiler encrypts all classes in jar file, adds Preloader to encrypted jar, and makes changes in Manifest file.

Java Preloader

includes decryptor, class loader and "Sonar" module. When JVM starts it calls Preloader according to the modified Manifest. Java Preloader calls Sonar module that checks the environment integrity and the presence of hacker attacks. When Sonar detects suspicious changes in JRE or hacking attempts it just stops the program execution. If everything is OK the execution is passed to decryptor and then to class loader. Finally, the main class of the original program is called.



Before/After


Source code before protection

import ...

public class MyClass extends Frame
{
     String name;
     ...

     public MyClass()
     {
          ...
     }

     class Adapter extends WindowAdapter
     {
          ...
     }

     public static void main(String args[])
     {
          Frame frame = new MyClass();
          ...
     }
     ...
}

Compiled class



Protected class



And after any decompiler

null

Thus, if usual obfuscators make the reverse engineering time consuming, painful, and complicated enough, Java Antidecompiler makes it absolutely impossible.

Secure Server Authentication

Your Java application sends request, encrypted or not, to you authentication server page (php, jsp, asp.net, etc.). The server page analyzes the request and sends a responce depending on authentication criteria. Your app should decide either to run the full (activated) version or trial one (with restricted functionality), or completely exit JVM. The decision code is the weak point of the Standard scheme, because it can be easily intercepted or tampered even you use a very deep obfuscation.




Secure Server Authentication. Our solution uses a separate Authentication module, that performs all request/response/decision operations. This module is encrypted, so nobody can see them. Moreover the request URL will be protected from tampering.



Implementation. You have to provide three methods in your main class

static Map<String, String> getAuthenticationRequest(),
static void trial(String args[]),

and not mandatory errorMessage()

static void errorMessage()

public class YourMainClass extends Frame
{
private static final long serialVersionUID = 1L;

static Map<String, String> getAuthenticationRequest()
{
Map<String, String> params = new HashMap<String, String>();
// Fill params Map
String key, value;
key = "serialno";
value = JOptionPane.showInputDialog (null, "Serial No:",
"Enter your Serial No. please", JOptionPane.QUESTION_MESSAGE);
params.put(key, value);

return params;
}

// You may provide custom error message
static void errorMessage()
{
JOptionPane.showMessageDialog (null, "Wrong Serial No. Program will exit.",
"Java Notepad - Error", JOptionPane.ERROR_MESSAGE);
}

public static void trial(String args[])

{
// Trial setting, for example
trial = true;
main(args);
}

static boolean trial = false;

public static void main(String args[])
{
Frame frame = new YourMainClass();

if (trial)
frame.setTitle("YourMainClass Trial");
else
frame.setTitle("YourMainClass Activated");
...
}
...
}


Copyright © 2017 BIS Guard & Co. ToC Read Me User Guide Debugging EULA Modified Dec 20, 2016