Decompiling Java Bytecode: Problems, Traps and Pitfalls

  • Jerome Miecznikowski
  • Laurie Hendren
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 2304)

Abstract

Java virtual machines execute Java bytecode instructions. Since this bytecode is a higher level representation than traditional object code, it is possible to decompile it back to Java source. Many such decompilers have been developed and the conventional wisdom is that decompiling Java bytecode is relatively simple. This may be true when decompiling bytecode produced directly from a specific compiler, most often Sun’s javac compiler. In this case it is really a matter of inverting a known compilation strategy. However, there are many problems, traps and pitfalls when decompiling arbitrary verifiable Java bytecode. Such bytecode could be produced by other Java compilers, Java bytecode optimizers or Java bytecode obfuscators. Java bytecode can also be produced by compilers for other languages, including Haskell, Eiffel, ML, Ada and Fortran. These compilers often use very different code generation strategies from javac.

This paper outlines the problems and solutions we have found in our development of Dava, a decompiler for arbitrary Java bytecode. We first outline the problems in assigning types to variables and literals, and the problems due to expression evaluation on the Java stack. Then, we look at finding structured control flow with a particular emphasis on issues related to Java exceptions and synchronized blocks. Throughout the paper we provide small examples which are not properly decompiled by commonly used decompilers.

References

  1. 1.
    Z. Ammarguellat. A control-flow normalization algorithm and its complexity. IEEE Transactions on Software Engineering, 18(3):237–250, March 1992.CrossRefGoogle Scholar
  2. 2.
    B. S. Baker. An algorithm for structuring flowgraphs. Journal of the Association for Computing Machinery, pages 98–120, January 1977.Google Scholar
  3. 3.
    C. Cifuentes. Reverse Compilation Techniques. PhD thesis, Queensland University of Technology, July 1994.Google Scholar
  4. 4.
    A. M. Erosa and L. J. Hendren. Taming control flow: A structured approach to eliminating goto statements. In Proceedings of the 1994 International Conference on Computer Languages, pages 229–240, May 1994.Google Scholar
  5. 5.
    E. M. Gagnon, L. J. Hendren, and G. Marceau. Efficient inference of static types for Java bytecode. In Static Analysis Symposium 2000, Lecture Notes in Computer Science, pages 199–219, Santa Barbara, June 2000.Google Scholar
  6. 6.
  7. 8.
    T. Knoblock and J. Rehof. Type elaboration and subtype completion for java bytecode. In Proceedings 27th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages., 2000.Google Scholar
  8. 9.
    J. Miecznikowski and L. Hendren. Decompiling Java using staged encapsulation. In Proceedings of the Working Conference on Reverse Engineering, pages 368–374, October 2001.Google Scholar
  9. 11.
    T. A. Proebsting and S. A. Watterson. Krakatoa: Decompilation in Java (Does bytecode reveal source?). In 3rd USENIX Conference on Object-Oriented Technologies and Systems (COOTS’97), pages 185–197, June 1997.Google Scholar
  10. 12.
    L. Ramshaw. Eliminating go to’s while preserving program structure. Journal of the Association for Computing Machinery, 35(4):893–920, October 1988.MATHGoogle Scholar
  11. 13.
    Soot-a Java Optimization Framework. http://www.sable.mcgill.ca/soot/.
  12. 15.
    R. Vallée-Rai, E. Gagnon, L. Hendren, P. Lam, P. Pominville, and V. Sundaresan. Optimizing Java bytecode using the Soot framework: Is it feasible? In D. A. Watt, editor, Compiler Construction, 9th International Conference, volume 1781 of Lecture Notes in Computer Science, pages 18–34, Berlin, Germany, March 2000. Springer.CrossRefGoogle Scholar
  13. 16.
    WingDis-A Java Decompiler. http://www.wingsoft.com/wingdis.html.

Copyright information

© Springer-Verlag Berlin Heidelberg 2002

Authors and Affiliations

  • Jerome Miecznikowski
    • 1
  • Laurie Hendren
    • 1
  1. 1.Sable Research Group, School of Computer ScienceMcGill UniversityCanada

Personalised recommendations