An Evaluation of Current Java Bytecode Decompilers

Abstract

Abstract-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 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.

The Strengths and Behavioral Quirks of Java Bytecode Decompilers

“…We evaluate eight recent and notable decompilers on code produced by two different compilers. This study is at least one order of magnitude larger than the related work [8], [9]. Our results are important for different people: 1) for all users of decompilation, our paper shows significant differences between decompilers and provide well-founded empirical evidence to choose the best ones; 2) for researchers in decompilation, our results shows that the problem is not solved, and we isolate a subset of 157 Java classes that no state-of-the-art decompiler can correctly handle: 3) for authors of decompilers, our experiments have identified bugs in their decompilers (2 have already been fixed, and counting) and our methodology of semantic equivalence modulo inputs can be 1 embedded in the QA process of all decompilers in the world.…”

“…In order to get a set of real world Java projects to evaluate the eight decompilers, we reuse the set of projects of Pawlak and colleagues [21]. To these 13 projects we added a fourteenth one named DcTest made out of examples collected from previous decompiler evaluations [8], [9]. 6 Table II shows a summary of this dataset: the Java version in which they are written, the number of Java source files, the number of unit tests as reported by Apache Maven, and the number of Java lines of code in their sources.…”

Side-channel watermarks for embedded software

“…In this work we present a software watermarking mechanism that can be inserted at the assembly level and that is especially useful for embedded applications. Most software watermarking mechanisms need either the software code to detect the watermark [4] or access to the memory structure during execution [7] [2]. However, in the embedded environment it is not easy to access the suspected code because in many cases, especially in those systems where code copying is a relevant threat, the memory is protected from unauthorized read operations.…”

“…However, in the embedded environment it is not easy to access the suspected code because in many cases, especially in those systems where code copying is a relevant threat, the memory is protected from unauthorized read operations. Another drawback of many previously proposed methods is that they have proven to be not very robust against code-transformation attacks [4]. In [4] every tested static software watermark mechanism was successfully removed using standard code-transformation software.…”

“…Another drawback of many previously proposed methods is that they have proven to be not very robust against code-transformation attacks [4]. In [4] every tested static software watermark mechanism was successfully removed using standard code-transformation software. Our This work was supported by the NSF Grants 0916854, 0964641, and 0923313.…”