X hits on this document

341 views

0 shares

0 downloads

0 comments

71 / 120

234")).toString());

21: 22:

}

return true;

23: 24: 25: 26: 27: 28: 29: 30: 31: 32:

}

}

public static void main(String arg0[]) { CheckLimitation checklimitation = new CheckLimitation(); boolean flag = true; for(int i = 0; i < arg0.length && flag; i++) if(!checklimitation.a(arg0[i])) flag = false;

}

Note that each string literal is decrypted using the Obfuscator class which was generated

by SandMark. Since Obfuscator is a public class, it must be generated into a separate file

named Obfuscator.class—making it very straight-forward for a reverser to isolate,

decompile, and learn the encryption algorithm. The danger of giving away the code for

the string decryption algorithm is that it could then be used to programmatically update

the constants pool section of the bytecode to contain the plaintext versions of each string

literal, essentially undoing the obfuscation. Ideally, we would like to prevent a reverser

from being able to successfully decompile the obfuscated bytecode; this can be

accomplished through control flow obfuscations which we explore next.

8.2 Preventing Decompilation of Java Bytecode

One of the most popular, and fragile, techniques for preventing decompilation

involves the use of opaque predicates which introduce false ambiguities into the control

flow of a program—tricking a decompiler into traversing garbage bytes that are

masquerading as the logic contained in an else clause. Opaque predicates are false

branches, branches that appear to be conditional but are really not [5]. For example, the

63

Document info
Document views341
Page views342
Page last viewedTue Dec 06 18:53:30 UTC 2016
Pages120
Paragraphs2913
Words25794

Comments