Discussions

The Russian company Smardec, a creator of software for Java programmers, has released its new product Allatori, a Java obfuscator. In the domain of Java code protection, Allatori stops attempts to decompile any application protected by the obfuscator.
Protection methods in the function set include:
1. Name Obfuscation
2. Flow Obfuscation
3. Debug Info Obfuscation
4. String Encryption
5. Watermarking
Stack Trace Utility is another feature. It is supplied with the obfuscator and makes obfuscated debug information comprehensible and adequate. A program module is also included, which uses information about decompiler work faults for creating special insertions into an obfuscated code that lead to decompilation failure.
Allatori Obfuscator was designed to suit any automated build environment. It's command line interface can be seamlessly integrated into build scripts. Moreover, Smardec has made the integration with Apache Ant build tool. Allatori comes with an Ant interface and can be used for any other Ant task.

Sounds very Italian. I suggest renaming it to Obfuskatnik.
On another note, Smardec's website does not contain names, photos or addresses, even the contact page display no emails with Javascript turned off. This is what I call obfuscation ;-)

A quote from http://www.allatori.com/faq.html
"Why do I need Allatori?
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."
It's interesting that they mentioned US Department of State as an example. Knowing that Allatori product is actually developed in Belorusia which affairs with Western World is so bad nowadays that US State recently even rejected Belurusia president airplane to fly over US territory.

Every time I've tried to use one of these products, it absolutely kills my SOAP web services. I configure them to ignore the service classes, and it seems to do that, but serialization still breaks miserably, one way or the other.
It also greatly complicates supporting customers who are getting exceptions in their logs with zero identifiable information, as well as making profiling significantly more difficult.
Combined with the fact that the tool can reverse engineer its own obfuscation, and therefore it seems more of a security through obscurity (in tool picking), I wonder what real value there is here.
James

Every time I've tried to use one of these products, it absolutely kills my SOAP web services. I configure them to ignore the service classes, and it seems to do that, but serialization still breaks miserably, one way or the other.

ProGuard allows you to obfuscate classes that are serializable by keeping fields and methods that may be needed.

It also greatly complicates supporting customers who are getting exceptions in their logs with zero identifiable information, as well as making profiling significantly more difficult.

You can recreate the original stack trace withh ProGuard using ReTrace and profiling is not much of a problem as a file is normally generated that keeps the mappings of the original code to the obfuscated version.

Combined with the fact that the tool can reverse engineer its own obfuscation, and therefore it seems more of a security through obscurity (in tool picking), I wonder what real value there is here.

James

The obfuscation tool can reverse engineer but the code will not be as intelligble as before.
I have mentioned ProGuard here but most tools we evaluated had all of these features and more. We are using ProGuard to obfuscate our code which runs in JBoss with some Spring, AOP, reflection etc and we configured ProGuard to handle all these situations perfectly fine.
Hope this helps you decide to do some more research before bashing it. I find this happens so often, people come here read some tool/methodology/practice and then naive software engineers take it back to their work place and cause mayhem with their FUD.
Keep it real

ProGuard allows you to obfuscate classes that are serializable by keeping fields and methods that may be needed.

I don't want to get into a tit-for-tat thing, so I'll limit my response to saying that I've used ProGuard. I ended up having to make 90% of my project clear-mode, and getting the most important code protected would have required a major refactoring. Even then, I had problems with things like the native XML serializer not being able to deserialize objects stored in a db from build to build.
I'll readily admit I was a new user to ProGuard. But with this kind of tool, I imagine _most_ of the users are new users. This isn't like an IDE or revision control system where you use it day-in, day-out. I am a very knowledgeable Java developer overall, so it also wasn't a case of a Jr Engineer taking on too much. I simply didn't have more than the 3 days I spent trying to make it work for our application.
I'm readily willing to believe that with enough effort and experience using the tool, I could get satisfactory results for projects that either contemplated using obfuscation up front or that are just lucky enough to have their true intellectual property properly hidden behind enough layers of abstraction to obfuscate it without impacting the rest of the program. But when you try it for the first time, don't be surprised if you have to go to extreme lengths to make it work, especially if you publish public interfaces to the world, either via documented APIs or Web Services.
James
p.s. As a user of tools like SoftICE and VTune, I think you should also consider just how protectable _any_ code is that actually has to run on a user's system.

There are disadvantages with obfuscating code, so of course one should first make sure that there is some substantial intellectual property to protect. If there is, then it might be worthwile to obfuscate that particular module and let the rest of the code be.
There not much point in obfuscating a DAO layer, since everyone knows how to write one anyhow. But there might be a reason to obfuscate the implementation of a new encryption algorithm that one tries to get a patent on.
Code that represents substantial intellectual value is usually also worth testing and profiling extensivelly before obfuscation - and deployment. So, the garbled stacktraces and problems with profiling might be of less inportance for this kind of code.

Combined with the fact that the tool can reverse engineer its own obfuscation.

Because the obfuscator (any decent obfuscator) saves the translation info apart, without this info is not possible to restore the original names (of course is possible to "understand" the obfuscated code using many many many hours). I suppose Allatori works in this way.
Jose M. Arranz
JNIEasy, Java Native Objects

TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations technology projects - with its network of technology-specific websites, events and online magazines.