使用obfuscate4e混淆RCP应用（转）

Getting started

content follows

 

Installation of the obfuscate4e feature

To install this feature you simply have to use the update site facilities built into the Eclipse IDE.

1. Inside Eclipse go to Help > Software Updates > Find and Install ... and define a remote site pointing to http://obfuscate4e.org/updates/
2. Select the obfuscate4e feature from the list of installable features
3. Accept the licenseand define the installation location.

    

4. Press Finish to install the software on your hard disk,

That's it! Now you can use obfuscation in your projects.

 

Configure the obfuscation

Now it's time to configure how obfuscate4e and its embedded obfuscator should work. We use the ProGuard obfuscator in this sectin. The configuration of other obfuscators will differ.

Execute the action Create Proguard obfuscation configuration from the context menu of the plugin MANIFEST.MF.

 

In the project folder appear two new files: customBuildCallbacks.xml and proguard.cfg. These files are managed inside your project (and also version controlled).

ProGuard allows to highly customize the obfuscation process. You can add cunfiguration statements to the proguard.cfg file. See http://proguard.sourceforge.net/manual/usage.html for valid configuration parameters.

 

Excluding classes or packages from obfuscation

Obfuscate4e detects exported packages and and writes the corresponding obfuscation exclusion statements automatically into the file proguard.cfg at your plugin's root directory.

Starting from version 0.7 of obfuscate4e all classes references from plugin extensions (in plugin.xml) are automatically inserted into the obfuscator exclusion list. Thus the obfuscate4e configuration should be updated whenever a new extension is added to the plugin.
Remark: This feature works only on Eclipse 3.4 (there seems to be a bug or non-implemented feature in Eclipse 3.2 and 3.3)

Of course you can add custom exclusion statements by hand. For instance If a class gets instantiated via reflection or is referenced by name in any other way, it has to be excluded.

 

Exclude all classes in a package

By default obfuscate4e adds all exported packages of a plugin to the exclusion list.

There are to options if you want to add other packages to the exclution list:

1. Export the package using the Manifest editor (if this is useful for your project)
2. Add a following lines to the plugin's proguard.cfg file:
   

   -keep class de.example.plugin.* {  public protected *; }

   Remark: If you modified the proguard.cfg file manually, then these changes will be lost when re-generating the configuration!

 

Exclude a single class

You might want to exclude a certain file from obfuscation. This might be the case if the class is used in an extension of your plugin.

To exclude a class from obfuscation you have to add a statement like

-keep class de.example.plugin.actions.MySpecialAction {   public protected *;}

to the proguard.cfg file. All other classes in the package de.example.plugin.actions are completely obfuscated.

Remark: If you modified the proguard.cfg file manually, then these changes will be lost when re-generating the configuration!

 

Exclude all classes of a certain kind

To exclude all classes that implement a certain interface or extend a certain class (e.g. all views, actions, perspectives, wizards, ...) in a generic way you need to exclude the appropriate interfaces or super classes:

-keep class * extends org.eclipse.ui.part.ViewPart {  public *;}-keep class * implements org.eclipse.jface.action.IAction {  public *;}-keep class * implements org.eclipse.ui.IPerspectiveFactory {  public *;}-keep class * implements org.eclipse.equinox.app.IApplication {  public *;}-keep class * implements org.eclipse.jface.wizard.IWizard {  public *;}

To exclude all access methods (getters and setters) there is another generic way:

-keep class * implements org.example.AnyInterface {  void set*(***);  void set*(int, ***);  boolean is*();  boolean is*(int);  *** get*();  *** get*(int);}

Remark: If you modified the proguard.cfg file manually, then these changes will be lost when re-generating the configuration!

 

Obfuscate your code

It's time to use your obfuscator. As it is embedded into the built process Eclipse runs the obfuscator when exporting a plugin, a project or a complete product.

Export a plugin with File > Export ...

 

The plugin will be obfuscated and exported.

If you run the obfuscation in "verbose" mode, then you can see ant processing the plugin and check the applied names mapping in the file proguard.map. This file is located in the folder temp.folder/ of the plugin. This file shows a list of processed files as well as the names of class, fields and methods after obfuscation.

 

 

Solving problems

If the obfuscate4e plugin does not work as expected, then you have some possibilities at hand.

• If the obfuscation works manually at first run, but not at subsequent runs: Refresh the Eclipse workspace and check if there is a folder @dot or temp.folder in the plugin project. If they are, then remove it. Eclipse PDEbuild doesn’t run the customBuildCallbacks if they exist.
• Check the obfuscation setting in the proguard.cfg file in your plugin project. The syntax of this file is explained at the Proguard website(look at the Usage section).
• Run the obfuscation in verbose mode. Ant produces some output which might show the problem.
• Go to the bug tracker, there might be solutions matching your problem.
• If you encountered a bug, then you might submit a bug report.

Please submit the following information:

• The version of your Java and Eclipseinstallations,
• The contents of proguard.cfg and temp.folder/proguard.map, if available,
• The output of the verbosemode Ant run (see next section for details),
• optionally the MANIFEST.MF of the plugin (to ease the check of the proguard configuration).

 

Inspect the obfuscated product

It is quite easy to look how obfuscate4e processed your product. You need a de-compiler and an exported Eclipse RCP product. I’ll describe the procedure on a linux box.

I use Jode. This Project seems “dead”, at least there were no new releases since 2004. But it works well for this job.

Download the latest jode distribution and extract the file jode*.jar. Then open a shell an go to the folder where you exported the product to. Now execute the command shown below:

java -jar ~/Apps/jode-1.1.2-pre1.jar $(echo plugins/*  | tr " " ",")

The $(echo plugins/* | tr " " ",") selects all jars and folders inside the plugins/ directory and compiles tthem into a comma separated list. That’s how jode expects the resources to be inspected.

A window pops up and you can traverse the class structure and look at the obfuscated build.

 

Run the obfuscator in verbose mode

It might happen that the obfuscation does not work as expected. In this case there may be some "strange" folders in your project and the generated plugin jar contains non-obfuscated classes.

But the build process runs in headless mode and no errors or warnings are printed out in the console view.

The easiest way to debug the obfuscation process is to create and execute a build.xml file for the plugin.

At first generate a build.xml file by clicking on PDE Tools > Create Ant Build File in the context menu of the project or the META-INF/MANIFEST.MF file.
Then run the build.xml file by clicking the Run As > Ant Build entry of the context menu of the build.xml file.
The output of the plugin build is shown in the console view. Warnings and error messages are highlighted.

 

The target post.@dot contains the messages relevant to the obfuscation. In the above screenshot there is a error message:

[subant] Failure for target 'post.@dot' of:          /prj/de.partmaster.mytest/customBuildCallbacks.xml[subant] The following error occurred while executing this line:[subant] /prj/de.partmaster.mytest/customBuildCallbacks.xml:119:          Problem: failed to create task or type proguard[subant] Cause: The name is undefined.[subant] Action: Check the spelling.[subant] Action: Check that any custom tasks/types have been declared.[subant] Action: Check that any <presetdef>/<macrodef>             declarations have taken place.

In this case Ant could not find the declaration of the proguard task. This should not happen in practice - otherwise check your Eclipse installation in Help > Software Updates > Manage configuration for broken plugin dependencies.
As a rule of thumb you should follow make sure that you

1. rebuild the customBuildCallbacks.xmlfile if you change the package structure of the plugin,
2. rebuild the build.xml file if you change anything in customBuildCallbacks.xml.
3. run the build.xmlscript in verbose mode if you cant find the error.
4. Attach the verbose console output together with the file proguard.properties to any bug report and name the version of Java and Eclipse you are using.

转载于:https://www.cnblogs.com/sunweige/archive/2012/01/30/2331728.html