The purpose of this article is to warn developers about futility of using class-file encryption obfuscators for application protection and uselessness of spending money on it. All the protection methods are described in the fundamental work of Dmitry Leskov - Protect Your Java Code — Through Obfuscators And Beyond. When we are using class file encryption method we assume that the byte-code is encrypted and when the application starts decrypted byte-code through custom ClassLoader or JVMTI-interface loads into JVM.
June 1, 2012
The 1.0.5 version of our Stringer Java Obfuscator is released, codename Cienfuegos.
May 2, 2012
Today the most common problem for Android developers is to protect their application from custom malware attacks, in accordance with "Test: Malware Protection for Android - March 2012" by AV-TEST. We have a solution: Stringer Java Obfuscator...
April 25, 2012
Since 1.0.4 version you can use annotations for a finger tuning of the protection process. By default, if there are no @secured annotations all class files will be protected in accordance with include/exlude filter. If you have @secured annotations in a project only classes and/or its elements with @secure annotation will be protected.
April 23, 2012
The new version of Stringer Java Obfuscator is here.
April 13, 2012
We added support of two most common Java open source IDE: Eclipse and NetBeans.
April 11, 2012
For protection of Java programs we usually use obfuscators. Obfuscators allow us to rename classes, methods and fields automatically and change bytecode control flow.
April 10, 2012
We are glad to inform you about the release of a new Stringer version. Today Stringer Java Obfuscator is the easiest and most secure way to protect your Java based application from reverse engineering and hacking (including Android).
March 15, 2012
Stringer Java Obfuscator 1.0.2 Released Buy full version or download fully functional 15-day trial - https://jfxstore.com/stringer/
February 14, 2012
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