X hits on this document

327 views

0 shares

0 downloads

0 comments

74 / 120

garbage or illegal instructions into bytecode is not feasible. However, this technique does

remain viable for machine code, though there is some evidence that good disassemblers,

such as IDA Pro, do check for rudimentary opaque predicates [5]. The authors of

SandMark claim that the sole presence of opaque predicates in Java bytecode, without

garbage bytes of course, can make decompilation more difficult. Therefore, SandMark

implements several different algorithms for sprinkling opaque predicates throughout

bytecode. For example, SandMark includes an experimental “irreducibility” obfuscation

function which is briefly documented as “insert jumps into a method via opaque

predicates so that the control flow graph is irreducible. This inhibits decompilation.”

Unfortunately this was not the case with the program DateTime.java shown in Table 8.4

as Jad was still able to decompile DateTime.class without any problems despite the

changes made by SandMark's “irreducibility” obfuscation. The bytes of the unobfuscated

and obfuscated class files were compared to verify that SandMark did make significant

changes; perhaps SandMark does work for special cases, so more investigation is likely

warranted. In any event, opaque predicates seem to be far more effective when inserted

into machine code because of the absence of any type of verifier that validates all

machine instructions in a native binary before allowing it to execute.

SandMark's approach of using control flow obfuscations that leverage opaque

predicates in an attempt to the confuse decompilers is not unique because Zelix

Klassmaster, a commercial product, implements this approach as well. When Zelix

Klassmaster V5.2.3a was given DateTime.class as input with both “aggressive” control

66

Document info
Document views327
Page views328
Page last viewedMon Dec 05 00:37:45 UTC 2016
Pages120
Paragraphs2913
Words25794

Comments