Any Java Class Obfuscators Meet These Requirements?

[Will]

I am looking for any Java class obfuscators that meet these requirements for
a large custom Java application:

1. The obfuscator must be controllable with text file.
- Mandatory: It must be possible to protect some classes and interfaces
from obfuscation. This means that class name and names of public methods and
fields must not be changed.
- Nice to have: It must be possible to specify list of classes to obfuscate
instead of or in addition to the list of classes protected from obfuscation.
- Nice to have: Support of regular expressions in the configuration files.
For example: com.uscsw.xload.cons*

2. Mandatory: Persistent names map. We must be able to rebuild parts of the
system keeping the same obfuscation map.

3. Mandatory: The obfuscator should not change names of the packages without
explicit permission.

4. It must be possible to run obfuscator as a command line utility.

5. Mandatory: The obfuscator should not dictate the structure of the
project. It must be possible to specify source and target directories as
parameters

6. Mandatory: Obfuscator should do obfuscation only. It should not build jar
files.

7. Mandatory: Obfuscator should not rely on class loading tricks. It should
work on the source level only. We are using custom class loaders all over
the code.
Those class loaders are relying on standard jar file structure where package
name corresponds to the directory name and class name equal to jar entry
name.
So we cannot allow other custom class loaders except ours to run. Otherwise
their API must allow creation of standard Class object from raw bytes so we
could call it in our custom class loaders.

Is there anything that comes close to meeting the requirements shown above?

 

[Daniel Dyer]

Proguard (http://proguard.sourceforge.net) is my obfuscator of choice, it
seems to meet most, if not all, of your requirements (the only ones I'm
not sure about are the two below). It can be run standalone with a
configuration file or from within an Ant build script.

2. Mandatory: Persistent names map. We must be able to rebuild parts of
the system keeping the same obfuscation map.

Proguard outputs the mappings that it used so you can rebuild stack traces
from the output of obfuscated code. Do you mean that you want to have it
always map to the same obfuscated names everytime you build, even if the
code has changed substantially? I'm not sure exactly how Proguard works
in this respect. If you introduce new members it's possible that some of
the previously existing ones would have different obfuscated names. If
you don't introduce (or remove) members it will always obfuscate to the
same names.

7. Mandatory: Obfuscator should not rely on class loading tricks. It
should work on the source level only.

Proguard works on the class files, but it doesn't mess around with the JAR
structure (unless you ask it to repackage your code). I don't know of any
Java obfuscators that work on source code rather than compiled code.

Dan.

 

[Roedy Green]

I am looking for any Java class obfuscators that meet these requirements for
a large custom Java application:

To find candidates see http://mindprod.com/jgloss/obfuscator.html

 

[Roedy Green]

2. Mandatory: Persistent names map. We must be able to rebuild parts of the
system keeping the same obfuscation map.

The problem with that it requirement is it works at cross purposes
with the intent of the obfuscator. It makes the cracker's job ever so
much easier if you use a persistent map.

The idea of the obfuscator is to inconvenience yourself to the
bearable limit in order to make the cracker's life unbearable.

 

[Roedy Green]

6. Mandatory: Obfuscator should do obfuscation only. It should not build jar
files.

that one you can get around that requirement the same way you could
for the old jar signing utility that in insisted on building your
jars. You build your jar, expand it to a tree, and feed the tree to
the obfuscator

If that really bothers you, write a wrapper around the obfuscator that
does this transparently.

 

[Roedy Green]

7. Mandatory: Obfuscator should not rely on class loading tricks. It should
work on the source level only. We are using custom class loaders all over
the code.

There are likely some public domain Obfuscators. You might take the
code and massage it to your requirements, sacrificing some security
for convenience.

If you add a few of your own tricks, it will make you code much harder
to break than using something off the shelf.

Working from class files is a great simplicfication. There is no
parsing and no problem with mismatches *.java *.class files.