Stringer – Java Obfuscator by Licel 3
Stringer Java Obfuscator safeguards Java application binaries (JARs, Java 9 Modules, OSGI, WARs, EARs, Eclipse RCP) against reverse engineering and modification.FEATURES
Encryption of Strings
Encryption of Resources
Hiding Method Calls, Field Types, and Field Access
Integrity control: Certificate Checks, JAR Content Checks, JAR sealing, Runtime Integrity Checks
Java Code Anti-Debugging
Resource Name Obfuscation
Transparent SSL Pinning / HTTP Public Key Pinning (HPKP)
Secure Code Execution Environment
Encryption of strings is used to hide the contents of string constants in Java applications. It is based on a strong cryptographic algorithm with the dynamic keys. These keys are calculated during the work of the protected application based on many parameters, and they can’t be extracted from the application’s code. As a result, if the code is decompiled, the contents of strings will be hidden and will be inaccessible for static analysis and decryption.Note:
We recommend to encrypt strings that contain sensitive data (logins, passwords, API credentials, keys, and so on), it’s also useful to encrypt some more strings in order to knock a malicious person out of the way, and to make the reverse engineering task much more complicated. A good approach is to have as many strings encrypted as possible until it is ok for the performance of the application. We do not recommend to use String Encryption for strings in open source libraries and for insensitive strings, because it may lead to a negative performance impact.
Hiding of method calls allows protecting the critical places of an application from the analysis and modification. This mechanism masks the calls of library methods and application methods with the dynamic functions constructed in a special way. It also hides field types and accesses to fields.
Note: It is recommended using this function only for classes which logic must be protected from analysis and modification, for example, critical application’s logic, work with the license, etc.
Note: This technique allows you to hide Java API calls or third-party API calls you use in your project, if your bytecode targeted to Java 7 it hides calls to methods with use ‘invokedynamic’ engine, so that it is almost impossible to decompile protected code and to figure out which method is going to be called in a certain place. It is also a part of our anti-decompiler technique.
For extra protection, Stringer may also encrypt resources — images, media clips, and other data files that are part of your application — using a modified AES algorithm. Encryption keys are different for each application, providing the best in class protection. The process is completely transparent to the application and requires no changes to its source code or build steps. You may precisely define the list of resources that should be protected using filters. Stringer Enterprise allows you to transparently obfuscate names of resource files.
Integrity Control/Tamper Resistance
A binary processed by Stringer with integrity protection enabled will not function if damaged or deliberately modified. This makes it impossible for hackers to disable a licensing subsystem or inject malicious code in your app, e.g. to obtain sensitive information such as passwords or credit card numbers of your application’s users. Stringer Enterprise allows you to manually configure the integrity control function: enable/disable the JAR’s signature check, JAR’s contents check and tamper detection/notification – how the protected application behaves after it was modified.
Stringer Enterprise allows you to set actions that will be performed when there have been attempts to modify applications’ content and/or the signature.
Application Size Optimization
Stringer Java Obfuscator can optionally optimize the processed class files for size by deleting redundant information such as debugging data, local variable names, etc. These optimizations may effectively nullify the decryption/integrity control overheads.
In order to eliminate the negative performance impact, it is needed to consider which classes/strings and resources should be protected. The set of classes/resources that should be protected can be specified with the help of a filter (filter format). If you need more detailed adjustment, for example, protection of class methods or individual fields, you can use the annotations mechanism (annotations). We recommend to set filters for classes where you have sensitive strings for String Encryption, classes where you have valuable logic – Hide Access, and add filters for valuable resources. And we would also recommend excluding all the open source libraries.
If no filters specified and corresponding functions are enabled, Stringer protects all the strings in all the classes (String Encryption), all the classes and method calls, fields (removes types) and field accesses in all the classes (Hide Access), encrypts resources (Resource Encryption).
There is a reference configuration file stringer.xml in the root folder of the distribution kit. It has exclusions for widespread open source libraries. String Encryption, Hide Access are enabled in this configuration. If you do not have your own configuration yet, we recommend to start with the reference configuration and then add settings that are relevant to your applications.
Stringer Java Obfuscator works with the following inputs:
Directory with class files and resources
JARs with classes and resources
Java 9 Modules (Experimental feature)
OSGI, WARs, EARs, Eclipse RCP projects (Enterprise version only)
Self-defence and monitoring of Java applications in runtime (REALTIME PROTECTION) Reinforced Integrity Control (Application/Environment) mechanisms Secure Code Execution (Enterprise version) Transport Layer Protection for HTTPS – Transparent SSL Pinning / HTTP Public Key Pinning (HPKP) (Enterprise version) Support for different containers in addition to JARs: Java 9 Modules, OSGI, WARs, EARs, Eclipse RCP (Enterprise version) Watermarking REALTIME PROTECTION
Anti-Emulator Java Code Anti-Debugging TAMPER NOTIFICATION
Added ability to launch emergency/reporting code if the integrity of a Java application is broken ENVIRONMENT CHECK
Added mechanisms that allow you to detect if an application is being debugged INTEGRITY CONTROL
Added ability to control the necessity of checking a signature’s certificate under a JAR file Added JAR-level integrity control mechanisms TRANSPORT LAYER SECURITY
The certificate pinning is implemented in accordance with RFC7469 – Public Key Pinning Extension for HTTP standard Reporting Pin Validation Failure mechanism has been implemented