Dasho FAQ

General

• What is Obfuscation?
  
• Why Obfuscate?
  
• What is Compaction?
  
• Why Compact?
  
• What is Software Watermarking?
  
• What types of applications should be obfuscated?

  ---

DashO

• Does DashO-Pro V3 support all Java platforms?
  
• Does DashO run on Platform X?
  
• Can I get an evaluation copy?
  
• Is DashO a profiling tool?
  
• Does DashO change the source code of my Java application?
  
• Will I need to distribute any extra runtime classes with my DashO'd application?
  
• Does DashO compress class files?
  

Technical

• How does DashO obfuscate class files?
  
• What is Overload Induction(tm)?
  
• What about obfuscating API Libraries?
  
• What is Control Flow Obfuscation?
  
• What is String Encryption?
  
• What if I specify an entry point but I don't have all the other classes available (e.g. they are not in the classpath)?
  
• How do I know what classes are dynamically loaded in third party libraries I'm using?
  
• Can I integrate DashO into my build process?
  
• How do I distribute a patch to my obfuscated program?
  
• Can DashO rename classes I dynamically load (i.e. via forName) ?
  
• I am getting an "Unknown Attribute" warning. What's that?
  
• How does DashO handle native method calls?
  
• Do I have fine-grained control of how DashO processes my program?
  
• How do I tell DashO to copy non-Java files to my final jar?
  

Embedded

• For a J2ME CLDC based application, do I run the preverifier on my class files before running them through DashO?
  
• Does it matter if I run preverified class files through DashO?
  

General

Obfuscation is the technology of shrouding the facts. It's not encryption, but in the context of Java code, it's better. Early in Java's life, several companies produced encrypting class loaders to fully encrypt Java classes. Decryption was done just-in-time prior to execution. Although this made classes completely unreadable, this methodology suffered from a classic encryption flaw: it needed to keep the decryption-key with the encrypted data. Therefore, an automated utility could be created to decrypt the code and put it out to disk. However, once that happens the fully unencrypted, unobfuscated code is in plain view.

As another comparison, we could compare encryption to locking a six item meal into a lockbox. Only the intended diner (i.e. the VM) has the key and we don't want anyone else to know what he or she is going to eat. Unfortunately, if someone can pick the lock (or find the key hidden on the bottom of the box), the food is in plain view. Obfuscation works more like putting the six-item meal into a blender and sending it to the diner in a baggie. Everyone can see the food in transit, but besides a lucky pea or some beef-colored goop, they don't know what the original meal is. The diner still gets the intended delivery and the meal still provides the same nutritional value as it did before (luckily, VMs aren't picky about taste). The trick of an obfuscator is to confuse observers, while still giving the VM the same delivery.

Without argument, obfuscation (or even encryption) is not 100% protection. Even compiled C++ is disassembleable. If a hacker is perseverant enough, they can find the meaning of your code. The purpose of obfuscation is to make the reverse engineering process extremely time consuming and painful so that it's not worth the effort. The goal is to stop all casual hackers 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. Preemptive's products 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.

Why Obfuscate?

Programs written for Java are easy to reverse engineer. This is not in any way a fault in the design of Java; it is simply a reality of modern, intermediate-compiled languages. Java uses of 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. After all, it is difficult to make something easy to understand, flexible, and extendable while simultaneously hiding its crucial details.

Therefore, anyone with a copy of JAD can look at your code and reverse engineer your source code. Suddenly, your software licensing code, copy protection mechanisms, and proprietary business logic are available for all to see - whether it's legal or not. Anyone can peruse the details of your software for whatever reason they like. They can search for security flaws to exploit, steal unique ideas, crack programs, etc. This should make you pause for thought.

With all of that said, this should not be a risk or a showstopper. Organizations concerned with their intellectual property on the Java platform need to understand that there is a solution to help thwart reverse engineering. Obfuscation is a technique that provides for seamless renaming of symbols in assemblies as well as other tricks to foil decompilers. Properly applied obfuscation can increase the protection against decompilation by many orders of magnitude, while leaving the application intact.

Also, since obfuscation indicates that the IP owner has taken measures to secure the IP, obfuscating your Java program may provide you with more legal options in the event it is required.

What is Compaction?

As part of the complete analysis of your application, it is possible to determine unneeded elements. The compaction, or pruning, process can then remove all the unused classes, methods, instance variables, design time metadata, and actual bytecode to produce a much smaller application. In addition, correctly applied obfuscation techniques such as PreEmptive's patented Overload Induction can have a compacting effect. Due to its heavy reuse of identifier names, it saves significant space.

Note: This entire process is performed on bytecode, not source.

The size reduction caused by compaction is staggering. Some customers have reported a 70% size reduction in their executable. We imagine those customers use large third party libraries that were heavily trimmed. In our tests, we see a solid 30-40% shrinking in many applications.

Why Compact?

Compacted programs tend to load faster and run on less memory. For many applications that are distributed on CD-ROM, the size of the application typically isn't a serious worry. However, more and more applications are involving a networked/distributed component, browser based, or written for embedded systems. In those cases, every byte counts and compaction is essential.

What is Software Watermarking?

Software watermarking is used to hide customer identification or copyright information within software applications, similar to how it is hidden in other digital content such as songs, movies, and images. A watermark is used to identify owners of the software or to track the origin of a pirated copy.

What types of applications should be obfuscated?

Anyone developing Java applications where the source code is not publicly available or there is private information embedded inside the code should obfuscate.

One argument we have heard is that "we are writing corporate-wide software, so we don't need to obfuscate." Assuming the company provides all employees access to the source code for that application, then this is true. But, if not, whoever has access to the application can easily reverse engineer the source code with a freely available tool or an online web submission. If you have any information such as SQL, username/passwords, proprietary business logic etc. inside the application it can be easily obtained. In addition, applications that have a networked/distributed component, browser based, or written for J2ME will clearly benefit from compaction.

DashO

DashO-Pro V3 supports J2EE, J2SE, J2ME with explicit support for MIDP and NTT DoCoMo iAppli(tm) applications. As of version 3.0, functionality for all platforms is included in one product.

Does DashO run on Platform X?

DashO is a 100% pure Java application that requires Java 2 Standard Edition (JDK 1.4 or higher) to run. DashO will run on any platform that meets this requirement.

Can I get an evaluation copy?

Yes. Preemptive Solutions provides a two week evaluation version of DashO. The evaluation versions are fully-functional but time limited to two weeks. In addition, the evaluation version inserts code in your application that prints a message when run.

Note: Applications that run through an evaluation version of DashO may not be distributed.

Is DashO a profiling tool?

No. DashO is a Java application packaging, optimization, and obfuscation system which complements a good profiling system. DashO products are not profilers. A profiler tells you where your code bottlenecks are (often due to poor performing algorithms, etc.). DashO's optimization capabilities can actually change your code into faster and leaner code sequences.

Does DashO change the source code of my Java application?

DashO works strictly on class files, the original source code is never needed.

Will I need to distribute any extra runtime classes with my DashO'd application?

No. DashO's output is your application, just manipulated so that it's smaller, faster, and harder to reverse-engineer. No additional classes are needed.

Does DashO compress class files?

No. We leave compression to jar or zip. DashO 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. For example, DashO removes unneeded elements from a program such as unused methods (public, private, etc.) and unused fields. It also removes unused constant pool entries and other unneeded class file attributes.

Technical

DashO V3 provides an unprecedented level of protection against Java code reverse-engineering. DashO uses all the "traditional" obfuscation techniques. It optionally removes debugging information and renames all possible method and field names. It is highly configurable so you can select a given method or group of methods (e.g. all publics) to be renamed or not. It is not limited to private methods.

DashO also includes our patented Overload Induction renaming system. There is simply no better renaming algorithm for code protection and size reduction. In addition, DashO adds control-flow obfuscation (breaking many reverse-engineering tools outright) and String encryption to thwart easy access to revealing text in your program code.

What is Overload Induction(tm)?

Overload Induction is DashO's patented renaming system. It induces method overloading on a massive scale. This algorithm determines all opportunities for name reuse and takes advantage of them. Many of our customers have reported a full 33% of ALL methods were renamed to a single character (such as "a"). Typically, 10% more are renamed to "b", etc.

The algorithm is certainly not limited to renaming to single characters, however, the impetus behind the development of this algorithm was to make the absolute smallest Java executables as possible. Standard renaming algorithms find a name such as "getX" and universally rename all instances of that string to another smaller string (again, such as "a"). Unfortunately, after that point, the character "a" can never be reused for fear of method name collisions. The Overload-Induction renaming system determines all collision points and calculates the minimal set of legal names.

What about obfuscating API Libraries?

Obviously, you don't want to rename classes and methods that are designed as a public API. However, DashO 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. This will still go a long way towards the prevention of the reverse-engineering of Java code.

What is Control Flow Obfuscation?

DashO includes a strong form of protection called Control Flow Obfuscation. Reverse-engineering tools and Java runtimes differ in one very important area: runtimes execute code - if the code says "goto", the runtime does. Reverse-engineering tools attempt to view sections of code at once and identify those pieces of code as for-loops, if-blocks, or whatever structures were present in the source code. Runtimes don't require those structures. Loops are simply a commonly followed goto.

Control Flow Obfuscation destroys the common perception of compiled control structures. The runtime doesn't care as one set of goto's has been replaced by another. But reverse engineering tools are left with spaghetti code. Since Java has no actual goto command (compiled Java bytecode does) this often poses a significant reverse-engineering problem.

What is String Encryption?

DashO implements runtime decrypted String encryption. Any encryption (or specifically decryption) done at runtime is inherently insecure. A smart hacker can eventually break it, but for Strings present in customer code, we found it worthwhile. Effectively, we apply a simple encryption algorithm to any strings in your application you desire.

Let's face it: if a hacker wants to get into your code, he doesn't blindly start searching renamed types. He probably searches on the string "Invalid License Key" which points him directly to the type where license handling is performed. Searching on strings is incredibly easy. String Encryption raises the bar for the casual hacker and deters that many more non-serious hackers. This algorithm incurs a tiny performance penalty at runtime but as with pretty much everything else in DashO, this option is fully configurable.

What if I specify an entry point but I don't have all the other classes available (e.g. they are not in the classpath)?

DashO needs to be able to find all classes referenced by your application in order to best package them and to take advantage of the advanced optimizations. You can tell DashO to "ignore" not found classes and DashO will package your application without them, so long as no required classes subclass the missing classes.

How do I know what classes are dynamically loaded in third party libraries I'm using?

DashO includes technology that automatically detects which classes are dynamically loaded. In our tests, it can make that determination with 100% certainty approximately 75% of the time. In the remaining cases, DashO will report the occurrence and a confidence level.

Can I integrate DashO into my build process?

Yes. DashO has a command line interface that can be seamlessly integrated into build scripts.

How do I distribute a patch to my obfuscated program?

Given that obfuscation operates on an entire program, changing program elements (for example, deleting a class) can change the renaming scheme across the board.

DashO includes incremental-obfuscation that forces DashO to use the same renaming scheme as it did on a previous run. Using this feature, you can create patches for obfuscated applications.

Can DashO rename classes I dynamically load (i.e. via forName) ?

If the name of the class is statically analyzable, then DashO can rename it (this feature is configured off by default). For example, if you had forName("Rectangle") in your program, DashO will rename the Rectangle class and change this statement to reflect the new name.

I am getting an "Unknown Attribute" warning. What's that?

These warnings occur when DashO encounters a non-standard class file attribute that it does not know how to handle. The name and length of the attribute is printed out. If the length is greater than 0, then the attribute may contain a reference to the constant pool. If this situation exists, DashO may output a corrupted class file, since it will not know about the reference when it rearranges the constant pool. Please contact technical support with the name and length of the attribute, as well as the name and version of your Java compiler. If your class files are corrupted, you will have to exclude them from your DashO run.

How does DashO handle native method calls?

Native methods are never renamed in DashO. In addition, the classes they reside in are not renamed. If you know it is safe to do so, you can optionally allow DashO to rename classes containing native methods using the general option "renamenativeclasses".

Do I have fine-grained control of how DashO processes my program?

Yes. DashO V3 allows most configuration options to be configured via regular expressions. This gives you a powerful tool to control how DashO runs.

How do I tell DashO to copy non-Java files to my final jar?

The include-non-class file option does this. It can copy any files into your jar at any relative destination you specify.

Embedded

DashO obfuscates before preverification. We've added the option to run the preverifier as a packaging convenience. If your build script already runs the preverifier you can turn it off in DashO by setting the "RunPreverifier" option to FALSE. Make sure DashO's destination directory matches the place that your preverifier is expecting its input to be.

Does it matter if I run preverified class files through DashO?

It is OK to run preverified classes through DashO Embedded Edition, but it will strip the extra information added by the preverifier from all classes that it outputs. This means that you must preverify your output classes after running DashO on them. The reason for this requirement is that DashO may invalidate the information inserted by the preverifier when it transforms your class files.