Java String Encryption

When a competitor or hacker decompiles an obfuscated application, they will use any clue they can to locate the classes of interest to them. The string literals that are embedded in your application provide critical insights. These literals may be:

The text of the labels or other GUI components on your dialogs,
The text of your error messages,
The text of your exception messages.

The competitor or hacker decompiles all your classes then performs simple string searches on the generated source code.

Zelix KlassMaster's String Encryption technology encrypts your String literals where they are stored in the Constant Pools of your class files. It then adds fragments of code to your classes so that your Strings are decrypted at runtime. Note that Zelix KlassMaster™ offers different levels of String Encryption.

See the String Encryption Tutorial for more technical detail.

The example below demonstrates only the most simple and basic level. The more advanced enhanced level of String Encryption will by default make use of invokedynamic calls.

Bytecode Name Obfuscated then decompiled


void a(String s) {
   if(!s.equals(a()))
      throw new Exception("Wrong Password");
   else
      return;
}

Bytecode Name Obfuscated and String Encrypted then decompiled

void a(String s) {
   if(!s.equals(a()))
      throw new 
      Exception(b(c("Èk9@sg^W0~aa ÿ")));
   else
      return;
}

Limitations

Note that Zelix KlassMaster's String Encryption isn't and cannot be fundamentally irreversible. However, we are continually improving it to "harden" it against deobfuscation. For example, Zelix KlassMaster's Method Parameter Changes functionality significantly "hardens" Zelix KlassMaster's String Encryption if the enhanced setting is used.

Privacy

Refunds