FAQ

Obfuscation is the technology of the reality shrouding. This is not a complete encryption of the Java code, though there was a time when this method was used. Taking into consideration Java, obfuscation seems to be better. As it was mentioned above, at the beginning of Java's development some developers encoded their applications and libraries completely, and together with them they offered special class loaders, which deciphered the code right before its execution. Although those encrypted classes were absolutely unreadable, this kind of solution needed placing a special key for decoding into the application. In this case, if the hacker once found out the key, it was quite easy for him to decrypt the application and save it on his hard drive. Then with the help of any available decompiler he could without efforts get the source code, which he could use the way he wished.

Here we came across the most interesting question: how can we get the source code out of the compiled one? It turns out to be really simple. Unlike C++, the source code of which turns into a machine code during compilation, Java source code is compiled into the so-called 'bytecode'. This bytecode can be easily decompiled back into a source code. Actually, the machine code got from C++ can be disassembled too, but unlike the disassembled code, where there won't be any man-oriented string, in Java code all information from the sources will be present. So, all the names of the classes, methods and variables will be reconstructed, all the string literals will be in their primordial state. And this decompiled code will differ from the source one only in one point: there will be no comments, because they are eliminated during compilation.

It's obvious, that if there existed a way to eliminate from the bytecode all info, that could be grasped by a human being, to understand decompiled Java code would be as difficult as to understand disassembled one. Well, there is such a way - it's obfuscation. And though obfuscation can't guarantee 100%-protection of your code from reverse engineering (code can be decompiled and studied, however), it becomes much more difficult - and sometimes even impossible - to understand obfuscated code. In fact, obfuscation must be grasped as not only a way to defend the code, but as a way to turn the process of reverse engineering into a time consuming operation, that requires big efforts. The goal is to stop all casual intruders and as many serious hackers as possible.

Allatori's name obfuscation mechanism changes meaningful class, field and method names to meaningless strings. Although Allatori is a second generation Java obfuscator, it also performs excellent name obfuscation. Unlike some other obfuscators, it has been engineered to handle any kinds of dependencies and schemes of inheritance.

The new names that Allatori generates are extremely short so it reduces the size of your byte code. In the name obfuscated byte code the package, class, field and method names have been renamed and the original names can never be recovered.

When a competitors or hackers decompile 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:
1. The text of the labels or other GUI components on your dialogs,
2. The text of your error messages,
3. The text of your exception messages.

A simple search of the string in the code will in a jiff show the exact place, where it's used, - that means it will localize the necessary piece of code and, as a consequence, make it much easier for the hacker to understand the algorithm of your program. String literals can become a starting point for exploring the whole application.

Programs written in Java are easy to reverse engineer. In no circumstances the Java design can be blamed. It's just the nature of modern and intermediate-compiled language. Java uses expressive file syntax for delivery of executable code: bytecode. Being much higher-level than binary machine code, the intermediate files are laden with identifiers and algorithms that are immediately observable and ultimately understandable.

As part of the complete analysis of your application, it is possible to determine unneeded elements. The process responsible for minimization can eliminate all classes, methods and variables out of use and even pieces of actual bytecode to produce a much smaller application. In addition, correctly used methods of obfuscation, such as name obfuscation, lead to significant size reduction.

Allatori provides an unprecedented level of protection against Java code reverse engineering. Allatori uses all the "traditional" obfuscation techniques. It obfuscates debugging information and renames all possible method and field names. It is highly configurable so you can choose a given method or group of methods to be renamed or not. It is not limited to private methods.

Native methods are never renamed by Allatori. In addition the classes they reside in are not renamed. Allatori default exclusions will automatically handle any native methods by ensuring that the names of the native methods themselves and the fully qualified names of the classes that contain them will not be changed.

As it was already mentioned above, you need Allatori to protect your application from being reverse-engineered. You also need it to protect the algorithms in your libraries from being copied or being used against you. Like some customers, you may be required to use Allatori by the US Department of State and the National Security Agency in order to be granted export licenses for your products.

Moreover, you need not just a usual obfuscator, but the one that can provide the highest level of protection and performance of your application.