Source-linked AI summary
Dexpler: Converting Android Dalvik Bytecode to Jimple for Static Analysis with Soot
Alexandre Bartel, Jacques Klein, Martin Monperrus, Yves Le Traon
TL;DR
Android applications are distributed as Dalvik bytecode, while existing static-analysis tools commonly operate on other representations. Dexpler directly converts Dalvik bytecode into Soot’s Jimple representation, and the paper reports that it converts every Dalvik instruction while successfully transforming and running an Android application. The authors identify unresolved typing issues as a current limitation.
Problem
Android applications are often distributed without source code, and disassemblers’ separate representations prevent reuse of existing static-analysis tools.
Method
Dexpler modifies Soot to directly read Dalvik bytecode, convert it to Jimple, and use Dedexer for parsing with Soot’s fast typing component for type inference.
Results
Dexpler converts every Dalvik instruction to Jimple and can transform Android applications such as the Snake game, which runs smoothly and works.
Takeaways & Limitations
Dalvik bytecode can be analyzed or transformed through Soot’s Jimple-based tooling without an intermediate Dalvik-to-Java-bytecode conversion.
Takeaways & Limitations
Typing remains limited because some Dalvik instructions provide insufficient information for Soot’s inference engine, which can raise an exception and stop.
Abstract
from arXiv · showhide
This paper introduces Dexpler, a software package which converts Dalvik bytecode to Jimple. Dexpler is built on top of Dedexer and Soot. As Jimple is Soot's main internal rep- resentation of code, the Dalvik bytecode can be manipu- lated with any Jimple based tool, for instance for performing point-to or flow analysis.
1. Introduction
Android applications are commonly distributed as Dalvik bytecode rather than Java bytecode, complicating reuse of existing Java static-analysis tools. Dexpler addresses this by directly converting Dalvik bytecode into Soot’s Jimple representation.
- Motivation: Android applications are usually distributed as Dalvik bytecode, because Java bytecode is transformed by dx before distribution.Dalvik bytecode is register-based and optimized for devices with limited memory and processing power.
- Motivation: Disassemblers use their own bytecode representations, which prevents Android analyses from using existing tools.This motivates converting Dalvik code into a representation already supported by static-analysis frameworks.
- Dexpler: Dexpler lets Soot directly read Dalvik bytecode and analyze or transform it in Jimple, eliminating the intermediate Dalvik-to-Java-bytecode conversion.Dexpler uses a disassembler and performs the remaining work itself or through Soot.
- Contributions: The paper describes a Dalvik-to-Jimple converter and provides a comprehensive mapping from Dalvik instructions to Jimple statements.These contributions target reuse of Jimple-based analysis and transformation tools.
- Evaluation: The paper evaluates Dexpler on test cases and one Android application, then discusses its current limitations and open research challenges.The application evaluation reports that the game runs smoothly and works.
2. Soot
Soot is a Java static-analysis and transformation framework that converts accepted inputs into Jimple. Dexpler extends Soot’s input pipeline with Dalvik-specific class and method sources.
- Soot Overview: Soot evolved from a Java compiler testbed into a tool for Java static analysis and transformation.It can check properties, support correctness guarantees, and enable transformations such as instrumentation and obfuscation.
- Soot Overview: Soot accepts Java source, Java bytecode, and Jimple source, converting each input format into its internal Jimple representation.Jimple is a stack-less three-address representation with 15 instructions.
- Java Bytecode Pipeline: When loading Java bytecode, Soot resolves classes and obtains method Jimple bodies through Coffi class and method source objects.Jimple code may be generated when an analysis requests a method’s active body.
- Dexpler Integration: Dexpler fills Soot’s missing Dalvik-to-Jimple module by adding DalvikClassSource and DalvikMethodSource alongside the existing Coffi parser structure.This incorporates Dalvik handling into Soot’s established class-loading architecture.
3. Dalvik Bytecode
Dalvik packages consolidate classes and shared homogeneous constant pools in a register-based executable format. Its incomplete type information and shared representation of null and zero complicate translation to Jimple.
- Dex File Structure: The dx compiler combines N Java bytecode classes into one Dalvik executable stored in a .dex file.The resulting file contains Dalvik classes and bytecode instructions.
- Dex File Structure: A .dex file uses shared homogeneous pools for strings, classes, fields, and methods, with class definitions linked to method bytecode.This differs from the per-class heterogeneous constant pool described for Java class files.
- Dalvik Instructions: Dalvik is register-based, so most instructions specify the registers they manipulate.Registers may be encoded using 4, 8, or 16 bits depending on the instruction.
- Dalvik Instructions: Dalvik has 237 listed opcodes, but only 217 instructions can practically be found in Android application packages.Twelve odex instructions are system-generated and eight instructions were never found in application code.
- Dalvik Instructions: Some Dalvik instructions do not provide register types, and both null and zero are represented as 0, creating translation problems for Jimple.The paper identifies these issues as problematic when translating Dalvik bytecode to Jimple.
4. Dexpler
Dexpler converts Dalvik bytecode directly into Jimple for Soot analysis, using Dedexer parsing, type inference, instruction mapping, and branch repair.
- 4. Dexpler: Dexpler leverages Dedexer and Soot’s fast typing component to convert Dalvik bytecode into Jimple classes, methods, and statements.The converter avoids an intermediate Dalvik-to-Java-bytecode conversion.
- 4. Dexpler: Dexpler infers local-variable types with fast typing, then applies the Jimple jop pack to optimize generated code.The optimization includes components such as the nop eliminator.
- 4. Dexpler: Each Dalvik instruction maps to a corresponding Jimple statement or group of statements, with registers mapped to Jimple local variables.The mapping covers instruction groups including moves, branches, getters and setters, method invocations, logic, and arithmetic.
- 4.4 Type Inference: Ambiguous constants require later correction because Dalvik initialization instructions may not distinguish null, integer, float, long, or double values.Null values are initially represented as IntConstant(0) and updated to NullConstant when later usage reveals a reference type.
- 4.5 Handling Branches: Dexpler resolves forward and backward control-flow issues by propagating inferred types and temporarily redirecting unresolved jumps through an initial nop.Jump targets are corrected after the method is fully processed, and the nop is removed during optimization.
- 4. Dexpler: Dexpler enables Soot to analyze or transform Dalvik bytecode after conversion to Jimple.Jimple is Soot’s internal representation used by downstream static-analysis tools.
5. Evaluation
Dexpler was evaluated on diverse test cases and the Snake Android application, where generated code executed successfully and supported call-graph and control-flow analysis.
- 5. Evaluation: Dexpler was evaluated on test cases covering arithmetic, branches, method calls, arrays, strings, null and zero usage, exceptions, and casts.The test workflow compared execution results from original Java-bytecode versions with versions reconstructed through Dexpler and Soot.
- 5.2 Android Application: The Snake application contained 11 classes, 39 methods, 550 lines of Java, 14 KiB of Dalvik bytecode, and 884 Dalvik instructions.Dexpler generated Jimple from the application’s Dalvik bytecode before Soot regenerated Java bytecode and the Android package.
- 5.2 Android Application: The repackaged Snake application ran smoothly, and the game worked on the Android emulator.This test exercised the conversion and repackaging pipeline on a real Android application.
- 5.3 Static Analysis on Snake: Soot generated a call graph and a control-flow graph for Snake to check whether the converted Jimple preserved the original code’s meaning.Figure 5 presents the control-flow graph for the addRandomApple method.
- 5. Evaluation: The prototype was successfully tested on both standalone test cases and an Android application.This is the paper’s overall evaluation conclusion.
6. Current Liminations
Dexpler can transform Android applications such as Snake, but its current implementation excludes optimized Dalvik opcodes and relies on assumptions about legally generated bytecode when inferring ambiguous types.
- Dexpler is able to transform Android applications such as the Snake game.
- Dexpler does not handle optimized Dalvik (odex) opcodes.
- Type inference for ambiguous declarations assumes Dalvik bytecode was generated from Java source code rather than hand-crafted maliciously.
- Under that assumption, comparisons are treated as involving variables with the same type; malicious bytecode may violate it and produce wrong inferences.
7. Related Work
Prior tools either convert Dalvik bytecode to Java bytecode or disassemble it into representations that cannot use existing analysis tools. Dexpler instead generates Jimple within Soot, preserving access to Soot-based analysis and transformation.
- Ded, Dex2jar, and undx convert Dalvik bytecode to Java bytecode before applying or enabling Java-oriented analysis.
- Dexpler generates Jimple code rather than directly generating Java bytecode.Because Jimple resides within Soot, Java bytecode can still be generated from it.
- Smali and Androguard disassemble Dalvik bytecode using their own representations, preventing them from leveraging existing analysis tools.
- Using Soot's internal representation allows existing tools to analyze and transform Dalvik bytecode.
8. Conclusion
Dexpler extends Soot to analyze Dalvik bytecode by combining Dedexer's parsing with Soot's fast typing, and converts every Dalvik instruction to Jimple. Further work targets typing robustness before performance comparisons.
- Dexpler extends Soot to analyze Dalvik bytecode and Android applications.It uses Dedexer to parse Dalvik dex files and Soot's fast typing component for type inference.
- Dexpler converts every Dalvik instruction to Jimple.
- The authors plan to improve robustness to unhandled typing issues before comparing Dexpler's performance with Java bytecode generation and analysis tools.
A. Jimple Code
Table 1 presents the Jimple-code representations of Dalvik instructions, including method-invocation mappings and opcode-specific assignments.
- A. Jimple Code: Table 1 organizes Dalvik instructions alongside their corresponding Jimple code representations.
- A. Jimple Code: The mapping table provides Jimple representations for Dalvik instructions rather than preserving only their opcode names.
- A. Jimple Code: The listed method-invocation entries map invoke-super/range and invoke-direct/range to invoke-special, invoke-static/range to invoke-static, and invoke-interface-range to invoke-interface.