Program Analysis of Google Chrome

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.

Static Analysis of Android Apps Using Soot

Static Analysis of Android Apps Using Soot

Related Work

There are some previous works were done on this fields but all are yet to be conclusive to fully analysis android application. Some of the research that follows parital analysis works are:

Flow Droid: It is a context-sensitive, flow-based, field-based, object-sensitive, and lifecycle aware static taint analysis tool for java as well as android programming. Unlike many other static-analysis approaches for android it aims for an analysis with very high recall and accuracy of android programs  To achieve the main goal it accomplished two main challenges as increase in precision and builds an analysis that is context-, flow-, field- and object-sensitive; to increase recall It create a complete model of program lifecycle. 

However, the analysis [10] uses the application instrumentation tools such as Soot and Heros. The Flow Droid uses a very precise call graph which helps us to ensure flow-sensitive and context-sensitivity. Its IFDS-based flow functions guarantee field and object sensitivity. As a result of the highly precise and efficient alias, the procedure for searching is crucial for contextsensitivity in conjunction with field-sensitivity.

Inter-procedural Analysis: While analyzing the resemblance of the efficiency and effectiveness for the inter-procedural class analysis based on the Cartesian product algorithm and   profileguided class which are predicted for the optimizing self-program[8].

But it is the fact that it has very little difference in term of the outcome or performance among the three configurations optimization i.e. using only profile-guided class prediction, using only inter-procedural class analysis, and using both techniques [8]. 

Iterative algorithms: As of now, the main iterative algorithm that has really been executed is Plevyak's iterative algorithms [9]. Various papers proposing new call graph generating calculations have exactly surveyed the adequacy of their calculation by executing them in an improving compiler and utilizing the subsequent control flow graph to perform at least one or more inter-procedural analyses

Soot

Soot [1] was created at McGill University as a java compiler, further developed and become an android static analysis and transformation tool. Soot can be used for multiple tasks i.e. code analyze, transformation of java programs or android apps, instrumentation of an android apps, check that certain properties hold or guarantee correctness of programs.

Multiple tools based on Soot have been developed to perform transformations such as translation of Java to C, instrumentation of android apps or java programs, obfuscator for Java, software watermarking, Soot accepts Java source code, Java bytecode and Jimple source code as input files[1].

Any input format is converted into Soot’s internal representation: Jimple, Baf Grimph and Shimple. Java SIMPLE, is a stack-less, three address representation which features only 15 instructions. Any method code can be viewed as a graph of Jimple statements associated with a list of Jimple local variables.

Dalivk bytecode

Android uses Dalvik Virtual Machine [2, 3] as a main component which is a kind of Java Virtual Machine specially designed and optimized for Android applications. The Dalvik VM makes uses features like memory management and multi-threading, which is intrinsic in the Java language from Linux core system.

The Dalvik VM enables every Android application to run in its own process, with its own instance of the Dalvik virtual machine. Android application developers write Android applications using standard Java programming language with the set of core libraries, which enabled by the Android runtime.