The main purpose of obfuscation is to build a JVM instruction set which the decompiler could not build into the correct source code in Java.
The war between obfuscators and decompiles continues constantly.
For example, in a research project Soot researchers simultaneously developed an obfuscator JBCO and a decompiler DAVA , developers are competing with each other.
Why bad actors and developers want to decompile Java programs?
- reverse-engineering of proprietary API
- bytecode modification to disable the various licensing mechanisms
- to get access to "sensitive" information
Nowadays, classical name-obfuscators do not add any security to your application, all they do is the optimization of your code and shrinking the size of your application.
And it is very ineffective in case of reverse-engineering because obviously, Java programs use the Java API, which is public and an obfuscator can not change it. There are even solutions which allow one to recover method names and class names with use of special dictionaries. Though there is one exception, but it's not even obfuscator, it's a virtual machine with a native implementation of the Java API, for example - Excelsior JET.
It's no secret that the "boom" of Trojans is going on, which are exploiting vulnerabilities in the JVM, enter the user's computer to carry out their malicious actions, especially in relation to programs that work with financial and other high-risk information.
Modern means of protecting Java code should not only protect applications from reverse engineering but also organize an additional "sandbox" within the Java's "sandbox": control access to the class fields and methods by reflection API, restrict to modify and access private fields, members, and final fields, detect anomalies, and have active protection techniques against debuggers and other monitoring tools.
We have faced these problems when we were developing a licensing system for Java / Java FX applications - C3. And so was born Stringer .
Now back to reality. Most of (usually about 80-90%) the logic that developers of commercial software would like to protect (including various applications for Android) is tied to a string... Oh, java.lang.Strings...
For example, we have got a graphical client app that gets a resource from the Internet in a specific format, parses and displays to the user. An attacker would have sufficient access to constant-pool of a Java class and it will have no difficulty making the program-clone.
Usually, developers use self-made string encryption functions or an obfuscator that has a function to protect against these attacks.
Stringer is able to perform this task, as well. This is a new way, a simple and elegant, to protect the code from any evil intent. And in integration with C3 Cloud Licensing you get the highest level of protection against attackers, especially when you use JavaCards (C3 Hardware Protection).
We believe that almost every developer needs to have a toolkit of such kind to encrypt the constant pool. For companies that want to protect users of its products from information theft, Stringer allows you to organize a secure environment within the Java-based applications. This will be discussed in the next publications.
At the moment we are working on Stringer for Android applications!
If you have any questions write or call us.