Common Questions - RetroGuard Documentation

Prev	Contents	Next

How do I... obfuscate and deploy my software as several jars?

The correct approach is to temporarily package all classes as a single jar, obfuscate this using RetroGuard, and then split the obfuscated jar as required for deployment. This would be made difficult by the meaningless, obfuscated names of the classes. However, the tool 'RGpatch' (described here) can be used to split the obfuscated jar into multiple parts. For example:


jar cf in.jar com/myco/app1/*.class com/myco/app2/*.class com/myco/util/*.class

vi script.rgs

java -classpath retroguard.jar RetroGuard in.jar out.jar script.rgs retroguard.log

java -classpath retroguard.jar RGpatch out.jar app1.jar retroguard.log app1.classlist

java -classpath retroguard.jar RGpatch out.jar app2.jar retroguard.log app2.classlist

java -classpath retroguard.jar RGpatch out.jar util.jar retroguard.log util.classlist

Here 'app1.classlist' lists the unobfuscated names of the classes to be packaged in 'app1.jar'; similarly for 'app2.classlist' and 'util.classlist'.

Note that obfuscating two or more parts of a Java application separately will fail, since many of the obfuscated names in the separate jars will collide.

How do I... obfuscate a Java library?

If your Java library has a well-defined public interface, just list the classes, methods, and fields of this interface in the RetroGuard script file as shown in the previous section. RetroGuard can even help enforce your specified library interface since other classes and methods become inaccessible after obfuscation.

If you are not sure which classes, methods, and fields should be accessed in the library, it is safest to leave all public / protected / default-access methods and fields (and their classes) unobfuscated. This can be done with the single script line:


.class ** protected

Due the many identifiers left unobfuscated, this script line reduces RetroGuard's ability to deter decompilation and reverse engineering of your library. However, there are still code compression benefits due to obfuscation of private methods and fields and the removal of classfile attributes.

If you would like debugging stack traces to remain unaffected by obfuscation, the attibutes 'SourceFile' and 'LineNumberTable' should also be preserved:


.attribute SourceFile

.attribute LineNumberTable

Alternatively, add the following script line to retain the LineNumberTable attributes and to include dummy SourceFile attributes that contain only a constant string:


.option LineNumberDebug

This has the advantage of deleting the unobfuscated name of the class from the SourceFile attribute.

How do I... obfuscate JSPs?

Java Server Pages are usually compiled to servlet classes by your application server when the page is first requested. Obfuscation doesn't have a role in this configuration because the original JSP source files are available on the server.

However, if you plan to deploy your JSPs pre-compiled (which is allowed by most application servers) RetroGuard can be used to obfuscate the pre-compiled JSP/servlet classes as usual.

How do I... obfuscate JavaScript?

RetroGuard is purely a Java VM obfuscator and doesn't understand JavaScript; perhaps Google can help find an appropriate tool. JavaScript (properly ECMAScript) has no connection to Java other than a coincidence in language name.

However, RetroGuard can obfuscate Java classes generated from any language that targets the Java VM. Most often this language is Java, but there are many other possibilities (see Languages for the Java VM by Robert Tolksdorf for an extensive list). So long as the compiled classes accurately conform to the Java Virtual Machine Specification, RetroGuard should work normally.


Prev	Contents	Next



	Copyright © 1998-2007 Retrologic Systems.

	All rights reserved.