Decompiling Java - SCAM2009 Presentation
Upcoming SlideShare
Loading in...5
×
 

Decompiling Java - SCAM2009 Presentation

on

  • 1,525 views

Decompilation of Java bytecode is the act of transforming Java bytecode to Java source code. Although easier than that of decompilation of machine code, problems still arise in Java bytecode ...

Decompilation of Java bytecode is the act of transforming Java bytecode to Java source code. Although easier than that of decompilation of machine code, problems still arise in Java bytecode decompilation. These include type inference of local variables and exception-handling. Since the last such evaluation (2003) several new commercial, free and open-source Java decompilers have appeared and some of the older ones have been updated. In this paper, we evaluate the currently available Java bytecode decompilers using an extension of the criteria that were used in the original study. Although there has been a slight improvement since this study, it was found that none passed all of the tests, each of which were designed to target different problem areas. We give reasons for this lack of success and suggest methods by which future Java bytecode decompilers could be improved.

Presented at the Ninth IEEE International Working Conference on Source Code Analysis and Manipulation (SCAM 2009).

Statistics

Views

Total Views
1,525
Views on SlideShare
1,467
Embed Views
58

Actions

Likes
1
Downloads
32
Comments
0

2 Embeds 58

http://jameshamilton.eu 53
http://dev.jameshamilton.eu 5

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Decompiling Java - SCAM2009 Presentation Decompiling Java - SCAM2009 Presentation Presentation Transcript

  • Decompiling Java James Hamilton, PhD Student 0 1 0 0 0 0 1 1 0 1 1 0 0 0 1 0 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 1 1 0 0 1 0 0 0 1 1 1 0 1
  • What we did
    • We tested 10 different decompilers with the latests Java class file format using 10 different test programs.
    • In 2003, Emmerik tested the first 8 + 2 other, unobtainable ones.
  • What is a Java Decompiler?
    • transforms Java bytecode into Java source code
    public class HelloWorld { public static void main(String[] args) { System.out.println(&quot;Hello World&quot;); } } public class HelloWorld extends java.lang.Object{ public HelloWorld(); Code: 0: aload_0 1: invokespecial #1; //Method java/lang/Object.&quot;<init>&quot;:()V 4: return public static void main(java.lang.String[]); Code: 0: getstatic #2; //Field java/lang/System.out:Ljava/io/PrintStream; 3: ldc #3; //String Hello World 5: invokevirtual #4; //Method java/io/PrintStream.println:(Ljava/lang/String;)V 8: return }
  • What are they for? Static Single Assignment for Decompilation, Michael Van Emmerik, 2007
  • Java bytecode cycle
  • Java bytecode cycle
  • Assumption about how the bytecode was generated
    • Java compiler generated bytecode
      • most likely Sun's javac
    • aribtrary bytecode
      • generated by another language to Java bytecode compiler
      • generated manually by a programmer
      • transformed Java compiled bytecode
  • Our evaluation
    • 10 decompilers tested
    • 10 programs testing different problem areas
      • 6 javac generated
      • 4 abitrary
    • based on a 2003 survey
    • effectiveness scale
    • + indication of the general effectiveness of a Java decompiler.
    • - manual inspection and subjective scale.
    Emmerik, 2003, http://www.program-transformation.org/Transform/JavaDecompilerTests
  • Results
    • many of the current decompilers cannot parse the latest class files
      • 4 obsolete
      • 3 unmaintained
    • no currently maintained commercial decompilers
    • best decompiler? depends on the tool which generated the class file
      • Dava for abitrary bytecode
      • Java Decompiler or JODE for javac bytecode
  • The sorts of problems the Java decompilers had
    • Type inference for local variables – giving the tighest possible type to local variables
    • Exception handling
    • Control flow
  • Where decompilers failed public class TypeSet { public void m1(Integer i, String s) { untyped x; if(i != null) x = i; else x = s; m2(x); } public void m2(Comparable x) { } }
    • this example is easy but multiple inheritance via interfaces complicates things*.
    • is this really a problem, if all we need is compilable code?
    • can we just make everything an object, and use typecasts?
    invokevirtual TypeSet/m2(Ljava/lang/Comparable;)V Example from: Java and the Java Virtual Machine: Definition, Verification and Validation, Stärk et al, 2001 * see Efficient Inference of Static Types for Java Bytecode, Gagnon et al. 2000 and Efficient local type inference, Bellamy et al. 2008. Type Inference
  • most decompilers, except Dava, do not expect this. System.out.println(&quot;a&quot;); label_0: { try { System.out.println(&quot;b&quot;); }catch (RuntimeException $r9) { System.out.println(&quot;g&quot;); break label_0; } try { System.out.println(&quot;c&quot;); }catch (RuntimeException $r9) { System.out.println(&quot;g&quot;); break label_0; }catch (Exception $r6) { System.out.println(&quot;e&quot;); break label_0; } try { System.out.println(&quot;d&quot;); }catch (Exception $r6) { System.out.println(&quot;e&quot;); } } //end label_0: System.out.println(&quot;f&quot;); Example from: Decompiling Java Bytecode: Problems, Traps and Pitfalls, Miecznikowski et al, 2002 Where decompilers failed Intersecting try-catch blocks
  • public static int foo(int i, int j) { while (true) { try{ while (i < j) i = j++/i; }catch (RuntimeException re) { i = 10; continue; } break; } return j; } Example from: Decompiling Java Bytecode: Problems, Traps and Pitfalls, Miecznikowski et al, 2002 Where decompilers failed Control Flow
    • Not much improvement in 6 years
      • all decompilers aren't very good
    • Problems caused by newer class file specification
    • Different decompilers for different problems
    • can we produce a decompiler which combines the best of javac decompilers and abitrary decompilers?
    • do we really need to perform type inference if the only condition is that we require re-compilable code?
    • are the problems with the Java decompilers fundamental or just bugs?
    Conclusion Questions