FAQ

What is obfuscation?

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.

Obfuscation removes context from compiled code that humans (and reverse engineering tools) would use to decipher the code's meaning. The trick is to remove this context from evil intentions while retaining complete execution integrity with the original program. Allatori have accomplished this completely - your program will produce the same results as it did before obfuscation but the code is far more difficult to reverse-engineer.
Back to top

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.

Unfortunately, the control flow is still clearly visible. That is why you need Allatori's Flow Obfuscation.
Back to top

Allatori as a second generation Java obfuscator performs flow obfuscation in addition to name obfuscation. It makes slight changes to the bytecode that obscure the control flow without changing what the code does at runtime. Typically, selection and looping constructs are changed so that they no longer have a direct Java source code equivalent. Flow obfuscated bytecode typically forces decompilers to insert a series of labels and illegal 'goto' statements into the source code they produce. The source code is sometimes further obscured by decompiler errors.
Back to top

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.

Allatori's String Encryption technology encrypts your string literals where they are stored in the constant pools of your class files. In this case the string search after application's decompilation won't give the hacker anything. Allatori adds fragments of code to your classes so that your strings are decrypted at runtime, and that means that outwardly everything will be as usual.
Back to top

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.

So, every person armed with a Java decompiler may have a look at your code and reveal all secrets kept there. Such parts of your application as software licensing code, proprietary business logic or copy protection mechanisms seem to be extremely interesting for the hacker. Having studied your code, he can easily use it for his own purposes, which often don't coincide with yours. For example, having studied the security system and having found there a vulnerability, the hacker can create a particular exploit. Even the most trivial goals, such as stealing your unique ideas and algorithms and creating a crack to your application do take place. These ways of using your code can hardly please you. All those things mentioned seem to be enough for you to think it over for a while and to make the right choice. And if earlier you had some doubts, now you know for sure why and what for you need Allatori obfuscator.
Back to top

Software watermarking can be used to hide customer identification or copyright information into software applications, similar to how it can be hidden in other digital content such as songs, movies and images using steganography techniques. A watermark can be used to identify owners of the software or track the origin of a pirated copy.
Back to top

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.

Actually, the degree of size reduction of the application depends on the type of the application and configuration. According to our tests in the majority of cases this reduction can be about 10-40%, but sometimes when using lots of third party libraries this number can reach 60%.
Back to top

Yes, Allatori supports J2EE, J2SE and J2ME Java platforms.
Back to top

Allatori is written entirely in Java and technically should run on any platform that supports a 1.4+ Virtual Machine. It has been tested on all mentioned platforms.
Back to top

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.

In addition, Allatori adds control flow obfuscation (breaking many reverse engineering tools outright) and string encryption to thwart easy access to revealing text in your program code.
Back to top

No, the original source code is never needed. Allatori works strictly on class files.
Back to top

No. We leave compression to jar or zip. Allatori actually reduces the size of your class files by a combination of renaming, removal of unneeded information, and other space saving optimizations that always maintain compatibility with Java's class file format. It also removes unused constant pool entries and other unneeded information.
Back to top

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.

However, Allatori has no way of knowing if your native code accesses your Java fields or methods. If your native code does access any of your Java fields or methods then you will need to explicitly exclude the accessed member names and the fully qualified names of the classes that contain them from renaming.
Back to top

Obviously, you don't need to rename classes and methods that are designed as a public API. However, Allatori can be configured to still rename all private members of those classes and you can still apply control flow obfuscation and string encryption to those classes.
Back to top

If the name of the class is statically analyzable then Allatori can rename it. For example, if you had 'forName("com.company.SomeClass")' in your program, Allatori can rename the 'com.company.SomeClass' class and change this statement to reflect the new name.
Back to top

Encrypted strings are decrypted at runtime using code that has been added to the class. This means that the class will run slightly slower. Typically the performance impact is insignificant. The byte code size increase typically is in the range of 1-2%. It is recommended that you measure the impact on your classes.
Back to top

Generally, Allatori's flow obfuscation will slightly increase the size of your bytecode and in rare cases can slightly reduce its performance. It is a trade off between the degree of protection against decompilation and bytecode size and speed. Note that the size increase will vary from application to application and you should measure the impact on your bytecode.
Back to top

Allatori only attempts to obfuscate the flow of methods that already have some control flow complexity. So methods without 'if', 'switch', 'while' or 'for' constructs will not be flow obfuscated.
Back to top

Yes, Allatori has a command line interface that can be seamlessly integrated into build scripts.
Back to top

Yes. Allatori comes with Ant task and can be easily used with Apache Ant.
Back to top

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.

If you care about your intellectual property, you need Allatori. Take a right decision.
Back to top

Cannot find your question?
Contact us