the-web-application-hackers-handbook

Chapter 5 n Bypassing Client-Side Controls 145
import if.if.if.if.else;
import java.awt.event.KeyEvent;
public class double extends public implements strict
{
public double(j j1)
{
_mthif();
_fldif = j1;
}
private void _mthif(ActionEvent actionevent)
{
_mthif(((KeyEvent) (null)));
switch(_fldif._mthnew()._fldif)
{
case 0:
_fldfloat.setEnabled(false);
_fldboolean.setEnabled(false);
_fldinstanceof.setEnabled(false);
_fldint.setEnabled(false);
break;
...
The obfuscation techniques commonly employed are as follows:
n Meaningful class, method, and member variable names are replaced
with meaningless expressions such as a, b, and c. This forces the reader
of decompiled code to identify the purpose of each item by studying how
it is used. This can make it difficult to keep track of different items while
tracing them through the source code.
n Going further, some obfuscators replace item names with keywords
reserved for the language, such as new and int. Although this technically
renders the bytecode illegal, most virtual machines (VMs) tolerate the
illegal code, and it executes normally. However, even if a decompiler
can handle the illegal bytecode, the resulting source code is even less
readable than that just described. More importantly, the source cannot
be recompiled without extensive reworking to consistently rename
illegally named items.
n Many obfuscators strip unnecessary debug and meta-information from
the bytecode, including source filenames and line numbers (which makes
stack traces less informative), local variable names (which frustrates debugging),
and inner class information (which stops reflection from working
properly).
n Redundant code may be added that creates and manipulates various kinds
of data in significant-looking ways but that is autonomous from the real
data actually being used by the application’s functionality.