1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
|
<!doctype html PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<meta http-equiv="content-style-type" content="text/css">
<link rel="stylesheet" type="text/css" href="style.css">
<title>ProGuard FAQ</title>
</head>
<body>
<h2>Frequently Asked Questions</h2>
<h3>Contents</h3>
<ol>
<li><a href="#shrinking">What is shrinking?</a>
<li><a href="#obfuscation">What is obfuscation?</a>
<li><a href="#optimization">What kind of optimizations does <b>ProGuard</b>
support?</a>
<li><a href="#commercial">Can I use <b>ProGuard</b> to process my commercial
application?</a>
<li><a href="#jdk1.4">Does <b>ProGuard</b> work with JDK1.4? JDK5.0?</a>
<li><a href="#j2me">Does <b>ProGuard</b> work with J2ME?</a>
<li><a href="#ant">Does <b>ProGuard</b> have support for Ant?</a>
<li><a href="#gui">Does <b>ProGuard</b> come with a GUI?</a>
<li><a href="#forname">Does <b>ProGuard</b> handle <code>Class.forName</code>
calls?</a>
<li><a href="#resource">Does <b>ProGuard</b> handle resource files?</a>
<li><a href="#encrypt">Does <b>ProGuard</b> encrypt strings constants?</a>
<li><a href="#flow">Does <b>ProGuard</b> perform control flow obfuscation?</a>
<li><a href="#incremental">Does <b>ProGuard</b> support incremental
obfuscation?</a>
<li><a href="#keywords">Can <b>ProGuard</b> obfuscate using reserved
keywords?</a>
<li><a href="#stacktrace">Can <b>ProGuard</b> reconstruct obfuscated stack
traces?</a>
</ol>
<a name="shrinking"> </a>
<h3>What is shrinking?</h3>
Java source code (.java files) is typically compiled to bytecode (.class
files). Complete programs or program libraries are usually zipped up and
distributed as Java archives (.jar files). Bytecode is more compact than Java
source code, but it may still contain a lot of unused code, especially if it
uses program libraries. Shrinking programs such as <b>ProGuard</b> can analyze
bytecode and remove unused classes, fields, and methods. The program remains
functionally equivalent, including the information given in exception stack
traces.
<a name="obfuscation"> </a>
<h3>What is obfuscation?</h3>
By default, compiled bytecode still contains a lot of debugging information:
source file names, line numbers, field names, method names, argument names,
variable names, etc. This information makes it straightforward to decompile
the bytecode and reverse-engineer entire programs. Sometimes, this is not
desirable. Obfuscators such as <b>ProGuard</b> can remove the debugging
information and replace all names by meaningless character sequences, making
it much harder to reverse-engineer the code. It further compacts the code as a
bonus. The program remains functionally equivalent, except for the class
names, method names, and line numbers given in exception stack traces.
<a name="optimization"> </a>
<h3>What kind of optimizations does <b>ProGuard</b> support?</h3>
Apart from removing unused classes, fields, and methods in the shrinking step,
<b>ProGuard</b> can also perform optimizations at the bytecode level, inside
methods:
<ul>
<li>Evaluate constant expressions.
<li>Remove unnecessary field accesses.
<li>Remove unnecessary method calls.
<li>Remove unnecessary branches.
<li>Remove unnecessary comparisons and instanceof tests.
<li>Remove unused code.
<li>Remove write-only fields.
<li>Remove unused method parameters.
<li>Various peephole optimizations like push/pop simplification.
<li>Make classes static and final when possible.
<li>Make methods private, static, and final when possible.
<li>Inline simple getters and setters when possible.
<li>Replace interfaces that have single implementations.
<li>Optionally remove logging code.
</ul>
The positive effects of these optimizations will depend on your code and on
the virtual machine on which the code is executed. Simple virtual machines may
benefit more than advanced virtual machines with sophisticated JIT compilers.
At the very least, your bytecode may become a bit smaller.
<p>
A notable optimization that isn't supported yet is the inlining of constant
fields that are not marked as final.
<a name="commercial"> </a>
<h3>Can I use <b>ProGuard</b> to process my commercial application?</h3>
Yes, you can. <b>ProGuard</b> itself is distributed under the GPL, but this
doesn't affect the programs that you process. Your code remains yours, and
its license can remain the same.
<a name="jdk1.4"> </a>
<h3>Does <b>ProGuard</b> work with JDK1.4? JDK5.0?</h3>
Yes. Class files compiled with JDK1.4 are targeted at JRE1.2 by default. Class
files compiled with JDK5.0 may have additional attributes for supporting
generics and annotations. The compiled class files have slightly different
structures from older class files. <b>ProGuard</b> handles all versions
correctly.
<a name="j2me"> </a>
<h3>Does <b>ProGuard</b> work with J2ME?</h3>
Yes. <b>ProGuard</b> itself runs in J2SE, but you can freely specify the
run-time environment at which your programs are targeted, including J2ME. For
instance, you can specify <code>midpapi20.jar</code> and
<code>cldcapi11.jar</code> as the run-time libraries, instead of J2SE's
traditional <code>rt.jar</code>. All of <b>ProGuard</b>'s powerful
configuration options remain available. The <a
href="manual/examples.html">example section</a> of the <a
href="manual/index.html">ProGuard User Manual</a> illustrates how to process
<a href="manual/examples.html#midlet">a single midlet</a> or <a
href="manual/examples.html#midlets">all midlets</a> in your input jar, for
instance.
<p>
In addition, <b>ProGuard</b> provides an obfuscator plug-in for the J2ME
Wireless Toolkit.
<a name="ant"> </a>
<h3>Does <b>ProGuard</b> have support for Ant?</h3>
Yes. <b>ProGuard</b> provides an Ant task, so that it integrates seamlessly
into your Ant build processes. You can still use configurations in
<b>ProGuard</b>'s own readable format. Alternatively, if you prefer XML, you
can specify the equivalent XML configuration.
<a name="gui"> </a>
<h3>Does <b>ProGuard</b> come with a GUI?</h3>
Yes. First of all, <b>ProGuard</b> is perfectly usable as a command-line tool
that can easily be integrated into any automatic build process. For casual
users, there's also a graphical user interface that makes creating, loading,
editing, executing, and saving ProGuard configurations a breeze.
<a name="forname"> </a>
<h3>Does <b>ProGuard</b> handle <code>Class.forName</code> calls?</h3>
Yes. <b>ProGuard</b> automatically handles
<code>Class.forName("SomeClass")</code> and <code>SomeClass.class</code>
constructs. The referenced classes are preserved in the shrinking phase, and
the string arguments are properly replaced in the obfuscation phase.
<p>
With variable string arguments, it's generally not possible to determine their
possible values. They might be read from a configuration file, for instance.
However, <b>ProGuard</b> will note constructs like
"<code>(SomeClass)Class.forName(variable).newInstance()</code>". These might
be an indication that the class or interface <code>SomeClass</code> and/or its
implementations may need to be preserved. The user can adapt his configuration
accordingly.
<a name="resource"> </a>
<h3>Does <b>ProGuard</b> handle resource files?</h3>
Yes, in the sense that <b>ProGuard</b> copies all non-class resource files
from the given input jars to the output jars. Their names and contents remain
unchanged.
<a name="encrypt"> </a>
<h3>Does <b>ProGuard</b> encrypt strings constants?</h3>
No. Storing encrypted string constants in program code is fairly futile, since
the encryption has to be perfectly reversible by definition. Moreover, the
decryption costs additional memory and computation at run-time. If this feature
is ever incorporated, I'll provide a tool to decrypt the strings as well.
<a name="flow"> </a>
<h3>Does <b>ProGuard</b> perform flow obfuscation?</h3>
No. Control obfuscation injects additional branches into the bytecode, in an
attempt to fool decompilers. This operation may confuse JIT compilers as well,
adversely affecting performance. It may be added as an option in the future,
but it doesn't have the highest priority. I will focus mostly on the
optimization step, which may already restructure the code to the point where
decompilers get confused.
<a name="incremental"> </a>
<h3>Does <b>ProGuard</b> support incremental obfuscation?</h3>
Yes. This feature allows you to specify a previous obfuscation mapping file in
a new obfuscation step, in order to produce add-ons or patches for obfuscated
code.
<a name="keywords"> </a>
<h3>Can <b>ProGuard</b> obfuscate using reserved keywords?</h3>
Yes. You can specify your own obfuscation dictionary, such as a list of
reserved key words, identifiers with foreign characters, random source files,
or a text by Shakespeare. Note that this hardly improves the obfuscation.
Decent decompilers can automatically replace reserved keywords, and the effect
can be undone fairly easily, by obfuscating again with simpler names.
<a name="stacktrace"> </a>
<h3>Can <b>ProGuard</b> reconstruct obfuscated stack traces?</h3>
Yes. <b>ProGuard</b> comes with a companion tool, <b>ReTrace</b>, that can
'de-obfuscate' stack traces produced by obfuscated applications. The
reconstruction is based on the mapping file that <b>ProGuard</b> can write
out. If line numbers have been obfuscated away, a list of alternative method
names is presented for each obfuscated method name that has an ambiguous
reverse mapping. Please refer to the <a href="manual/index.html">ProGuard User
Manual</a> for more details.
<hr>
<address>
Copyright © 2002-2005
<a href="http://www.graphics.cornell.edu/~eric/">Eric Lafortune</a>.
</address>
</body>
</html>
|
