Forget code signing, meet Stringer Java Obfuscator 1.1
Digital signing has been the major method of protection against class file modification for a long time. Actually this method has a significant drawback – application operability does not depend on a digital sign. Checking a signature inside the application can be easily removed (even if classic obfuscators are applied). Yes, most likely we will see a notification that an application is not signed when an applet/Java FX application is started. But computer competence of most users leaves much to be desired and the chances are high that a user will ignore the notification and run the application anyway. It might lead to the theft of sensitive information, back door penetration, unauthorized malware installation and other malicious actions that might affect both user operation and vendor software and services. That is why it is vitally important for us as developers to take care of implementing protection technologies that will prevent application modification most of the times.
In the new version of Stringer Java Obfuscator we combined our well-proven function of string protection with a mechanism of hiding Java API calls and added an additional runtime-check of classes when calling a function of decrypting strings. This approach combines byte code and checking its integrity in runtime providing a qualitatively new protection of your Java-applications.
If you compile your application for Java 7 its performance increases 5-10% compared to the original one. So you do both protect your application and increase its performance.
This protection mechanism is available only for Java SE/EE/Java FX applications so far, an Android version is coming soon.
Release notes: Stringer Java Obfuscator 1.1.2
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)