Program Analysis of Google Chrome
Tested Android Application
The android Chrome application is taken as demonstration application originally developed by the Goolgle Team on Android platform. It features 4552 classes, 14184 methods and was written in Java code. The first method used is conversion of java codes in to soot’s intermediate representation Jimple files for each 4552 java classes and graphical representation for each 14184 methods which further converted in to control flow graph and call graph based on nodes and edges inside the method. Secondly, the generated Dalvik bytecode contains Dalvik instructions.
From the Dalvik bytecode of the Chrome application I generate Jimple code in one second (duration for the Dalvik to Jimple conversion only). Then I ask Soot to generate Java bytecode from the Jimple representation. I convert the Java bytecode back to Dalvik, repackage an Android application and launch it on the Android emulator. The application runs smoothly and the app is working.
Static Analysis on Chrome
I use Soot to generate a call graph of the Chrome application, portion of the control flow graph represented in Figure 2.
Control Flow analysis Graph (Call Graph) for org.chromium.chrome.browser.preferences.website.WebsitemergePermissionInfoForTopLevelOrigin(org.chromium.chrome.browser.preferences. website.WebsiteAddress,java.util.List) Method Extracted from the Generated Jimple Representation. .36 seconds (duration from the launch time of Soot until Soot has finished). I perform this to check that the generated call graph and CFG correspond to the original code meaning that the conversion from Dalvik to Jimple is correct for this code.
I have successfully tested Soot as IR Jimple conversion to and another tool Dalvik bytecode to an Android application.
Figure 2: Partial Call graph for (chrome.browser.preferences.website) method
Process Analysis
Firstly, I used soot for conversion of Chrome.apk i.e. downloads from google play store to Soot’s Intermediate Representation Jimple and Soot’s CFG Viewer to produce graphical representation of all the methods from classes as dot files based on existing works of Droiddel[7].
Second Method, since there no existing tool directly converts Dalvik bytecode to Jimple. I either found tools to convert Dalvik bytecode to Java bytecode or tools to disassemble and/or assemble assemble Dalvik bytecode using an intermediate representation [4].
Dalvik to Java Bytecode Converter Ded is a Dalvik bytecode to Java bytecode converter. Once the Java bytecode is generated, Soot is used to optimize the code. Dex2jar also generates Java bytecode from Dalvik bytecode but no not use any external tool to optimize the resulting Java bytecode [5]. Undx is also a Dalvik to Java bytecode converter but seems to be unavailable. I on the other hand do not directly generate Java bytecode but Jimple code.
From there, since the Jimple code is within Soot, I can generate Java bytecode as well. Dalvik Assembler/Disassembler Smali or Androguard can be used to reverse engineer Dalvik bytecode. They use their own representation of the Dalvik bytecode: they cannot leverage existing analysis tools. This tool, use Soot’s internal representation which allows existing tools to analyze/transform the Dalvik bytecode [7].
Conclusion
Here we introduced a new analysis that integrates and enhances existing Android app static analyses. I have presented the phenomena of static analysis of android apps based on the control flow graphs by using soot. I successfully use conversion of an android app (java byte code) into dalvik bytecode (android app). And generate the control flow graphs from java methods and perform the static analysis.
This can further be used for static analysis of any android apps or java programs and computation of nodes and edges for the analysis of the complex algorithm. Finally, it is also can be used on static fields, implicit flow, distinguish different receive intents as well as other data channels.
