Stringer - A New Approach to Securing Java Applications

Usually, obfuscators are used to protect Java programs. Obfuscators allow you to rename classes, methods, variables, change the control flow of the bytecode. All obfuscators including free and paid can do these functions.

The goal of bytecode obfuscation is to build such a set of JVM commands from which the decompiler could not build the correct Java source code.

The confrontation between obfuscators and decompilers continues all the time.

For example, in the framework of the research project Soot simultaneously developed obfuscator JBCO and decompiler DAVA , developers who compete with each other.

Why do intruders and bona fide developers need to decompile Java programs?

• Proprietary API Reverse Engineering
• Bytecode modification to disable various licensing mechanisms
• Gaining access to sensitive information

The classic obfuscator does relatively well with protection against the second type of attack. It helps poorly from reverse engineering, because Java programs use the Java API, which is public and the obfuscator cannot change it. There is one exception, but this is not even an obfuscator, but a full-fledged virtual machine with a native implementation of the Java API - Excelsior JET .

It's no secret that there is currently a “boom” in trojans, which, using vulnerabilities in the JVM, penetrate the user's computer to carry out their malicious actions, to the greatest extent with respect to programs that work with financial and other valuable information.

Modern security tools for Java code should rather not protect it from decompilation, but should organize a “sandbox” inside the Java “sandbox” :)

We faced these problems while developing a licensing system for Java / Java FX applications - C3 . And so was born Stringer .

Now back to reality. Most of the logic that developers of commercial Java applications (including various Android applications) would like to protect are tied to strings ... Oh, these java.lang.String's.

For instance. We have a graphical client that receives data in a specific format from an Internet resource, parses it and displays it to the user. It is enough for an attacker to access the constant pool of the Java class and it will not be difficult for him to make a clone program.
Typically, developers use their string encryption features or use obfuscators with support for these functions to protect against these attacks.

Stringer can do this task very well:

• Encryption is based on the AES algorithm with dynamic encryption keys for each secured Java package
• The logic of decryption functions is dynamically embedded in existing class files:
  A fragment of a decompiled class file before embedding protection:
  

  
  public class App
  {
      public static void main(String args[])
      {
          System.out.println("Hello World!");
      }
  }
  

  
  A fragment of the decompiled class-file after embedding the protection:
  

  
  public class App
  {
      public static void main(String args[])
      {
          System.out.println(main("\u916E\u2E67\uCB8D\u16B9\u479D\u7669\u3F20\uD7DC\u75C5\u30F1\uEC7E\uA26B\uEEB0\u2F0E\u4828\u19C6"));
      }
      ....
  }
  

  
  
• Decryption call context protection

Plus, the above-mentioned possibility of organizing a sandbox: protection against the use of reflection, protection of private fields of classes and methods, protection of final fields of classes from modification.

We believe that almost every developer needs a string encryption function, and for companies that want to protect users of their products from information theft Stringer allows you to organize a secure environment inside a Java application, but this topic is worth a separate post ...

We are currently developing Stringer for Android applications.

Stay tuned :)

PS
By the way, nobody cracked our CrackMe.
Besides users of Habr, users of Javalobby very actively participated. The total downloads were about a thousand, and only one of the participants reached the stage of interaction with the licensing server.