ProGuard 1.5: Open Source Class File Shrinker / Obfuscator


News: ProGuard 1.5: Open Source Class File Shrinker / Obfuscator

  1. A new version, 1.5, of ProGuard has been released on SourceForge. ProGuard is a Java class file shrinker and obfuscator, that can detect and remove unused classes, fields, methods, and attributes. It can then rename the remaining classes, fields, and methods using short meaningless names.

    Changes for Version 1.5:

    Fixed processing of retrofitted library interfaces
    Fixed processing of .class constructs in internal classes targeted at JRE1.2 (the default in JDK1.4)
    Fixed -dump option when -outjar option is not present
    Updated documentation and examples

    Check out ProGuard

    Do many of you obfuscate your code?

    What obfuscators do you use?

    Threaded Messages (17)

  2. Yes[ Go to top ]

    Yes - I use an obfuscater whenever delivering jar files
    to external customers.

    I use an old piece of software called JMangle.

    Old, but easy to use and apperently does the job well.
  3. Is it configurable?[ Go to top ]

    One thing I would worry about with code chrinkers is the removal of methods it 'thinks' are unnecessary. I was using IDEA to inspect some code last night and found several methods in which the IDE thought could be removed. But we are using Digester for some of our code and relying upon reflection to invoke the methods when necessary. I would assume this software would think these methods were not used as well since they are never 'directly' called in code.

    Any one have experience with similar situations?

  4. Never[ Go to top ]

    I would never let an obfuscator delete methods.

    Too many things can go wrong.
  5. Obscurity or Size?[ Go to top ]

    Why are people using obfuscators? Is it for security through obscurity or for the size/performance impacts?

    Dave Wolf
  6. for obscurity[ Go to top ]

    I use them to prevent access to easily understandable source code. Size/performance is not one of the reasons.
  7. Why obfuscate ?[ Go to top ]

    To make reverse engineering sligthly more difficult !
  8. Common Things can Foil Obfuscation[ Go to top ]

    I was taked with adding obfuscation to a medium-sized client/sever pair w/java 1.1 and here were my observations:

    - any methods that are accesssed via reflection need to be excluded from obfuscation

    - any classes that are loaded via Class.forName("foo") need to be excluded from obfuscation

    - properly obfuscating swing applications is very difficult due to the dynamic nature of the swing components

    - expect to spend several iterations of full regression sweeps to validate the obfuscated product

    - if you are adding obfuscation late in the development cycle, expect to produce parallel builds (obfuscated and non obfuscated) so that QA can repro bugs. One big problem with debugging obfuscated code is the fact that you will not get a stack trace that's meaningful.

    - obfuscation will drastically reduce your jarsize and your memory footprint

    - good luck patching an obfuscated applicaiton in the field. You will probably have to redeliver a new jar instead of just the updated classes.
  9. Thanks for the Leasons Learned.[ Go to top ]

    Thanks for sharing Craig.
  10. Not my experience[ Go to top ]

    A good obfuscater allows you to specify that public
    class/member/method names are not to be mangled.

    A good obfuscator produces a map of mangled names that can
    be used to analyze a stacktrace.

    My experience with JMangle is just run it and ship the
    result and forget about it.

    OK - it has also been our experience that we need
    to distribute full jars. But we would have wanted to
    do that anyway.
  11. Class.forName()[ Go to top ]

    - any classes that are loaded via Class.forName("foo") need to be excluded from obfuscation

    This is IMO not true for ProGuard.
  12. Is it configurable?[ Go to top ]

    I don't think anything should ever remove public classes and/or methods. You might be deploying your jar as a library and then.. Not to mention reflection etc.
    Removing unused private methods is safe though. (if you're doing reflection on private methods I would say something is wrong with your code..)
    All the rest is debatable and should be probably configurable.
  13. with a test suite ...[ Go to top ]

    Maybe if you have a good test suite for your application you can remove unused classes more safety.
  14. I am currently developping J2ME applications and there I can surely say you can't deploy any serious application without obfuscation. And Proguard does a great job there!
    In J2ME the main benefit of obfuscation is in shrinking the size of the code.

    I have used Retroguard ( but from my experience Proguard produces about 5% smaller jars.

    The security aspect is also important but it is not gonna be as easy to get the jar file of the J2ME application once OTA capable phones become available as it is with applets.

    In J2ME the removal of unused methods and classes is of great help, because otherwise I would have to do it by hand. Without such a tool it won't be possible to write a descent J2ME library. I'll have to rip it off in every application and it will be just easier to write a lot of stuff a new.

    Does anybody know if Proguard removes methods that are not called at all, or methods which call stacks are not invoked?
  15. Proguard article[ Go to top ]

    There is a useful article about Proguard and MIDlet obfuscation at
    that includes a class to integrate Proguard with Sun's Wireless Toolkit
  16. Incremental Obfuscation[ Go to top ]

    this software do not manage incremental obfuscation which is essential to incremental jar update in java web start for example (in fact a few does !)
  17. Other obfuscators: Alphaworks JAX[ Go to top ]

    What does it do that JAX didn't do in 1998?!

    I know that it hasn't been developed (at least in the Alphaworks version) since then, but IIRC, JAX also does method devirtualisation, class merging and other stuff...

    I haven't needed to use it for a long time, but the only issue I remember having with it was that it took ages to work through all the features and work out what they did...

  18. Thank you all for your interest in ProGuard. Even when processor speeds and memory capacity are increasing all the time, I personally liked the idea of my code being made a bit leaner, without much effort. For simple applications or libraries, processing the code can be trivial. For code that uses a lot of introspection, shrinking and obfuscation can be more complicated.

    In any case, ProGuard was designed to be easily configurable, so it can scale with increasingly complex code. For example, ProGuard accepts the following option:

    -keep public class * extends java.applet.Applet

    This would preserve all public applets, including other classes, methods, and fields that are required in the output jar. Note that ProGuard automatically recognizes Class.forName calls with constant string arguments. It also gives hints about other classes that you may want to keep because they might be created dynamically.

    Similarly, one can preserve all applications in the input jars:

    -keepclasseswithmembers public class * {
        public static void main(java.lang.String[]);

    In some cases, one wants to preserve all classes that implement an interface:

    -keep public class mypackage.** implements MyInterface

    The templates allow to quickly specify entire groups of classes, methods, and fields, constraining them based on their access flags, names, interfaces or superclasses, and class members. The templates are more resilient against changes than, say, a fixed set of names. This simple and robust configuration is probably the chief advantage of ProGuard compared to other obfuscators. Please feel free to download it and report your experiences.

    Eric (author of ProGuard).