Android platform is now a focus of attackers and security researchers. It’s very essential to provide a convenient and multi-functional tool to detect and analyze the malware. I’d like to improve the APKInsepctor with improvement of UI and adding of more features to assist the analysis of malware. The new version of APKinspector will be a powerful tool with multiple security functions such as permission analysis and static analysis as well as a user-friendly tool with convenient GUI and easy-to-use configuration. The planned new feature includes but not limited to fine-grained CFG, permission analysis model, call graph, data flow analysis and repackaging.
The primary goal is to improve current GUI of APKinspector implement new analysis methodology to assist static analysis of Android malware. The features to add are described in the following:
(1) Automatically installation:
The installation process includes many steps and configurations. The newbies might run into problems of versions and lib dependency. I’d like to use shell to automate the installation process. First, I’d like to investigate the possible library dependencies and errors and detect the current system to avoid the errors. Then write shell code to follow the steps and configurations. Finally, run a simple sample test to indentify if the installation is successful. The whole installation process is shown below:
(2) Fine-grained Graph View to Source View:
The current graph view to source view only supports block level. If the users can operate each instruction, it might be more clear and helpful.
I hope the user can jump freely between the graph view and source view with the exact position of each instruction or even register by just press the space bar. This function can serve the analyzers with a clear understanding of both the whole program and the details.
My initial idea is to utilize the androguard function of generating CFG. When the user press the space bar at one instruction in the CFG, APKinspector is triggered to recognize the position of the codes. Calculate the offsets of the instructions in the code blocks and identify the position of the instructions according to the offsets when the users transfer between graph view and source view. The position of the instruction is determined by the position of the block and the offset and each instruction is represented by a unique textview control. The cursor then moves to the position calculated above. Jumping from codes view to graph view is similar. Furthermore, we may operate with the opcode and register of each instruction when necessary. The process is illustrated in the following graph:
Besides, the view of instruction is affected by the length of the instruction. Optimization of the instruction might be applied to show the entire instruction clearly for the hint function. Finally, the users will be presented with detailed graph view and they can easily interact with instruction or even registers in the program.
(3) Call Graph:
Currently, APKinspector only provide descriptions of call in and call out. It would be better if a call graph is provided to the users. I’d like to draw a static call graph to represent every possible execution of the program. If time permits, a context-sensitive call graph is a better choice. The solution is to record the call in/out relationship of each node and use Graphviz to draw the call graph. Firstly, we generate the dot format of the call graph by Garphviz. The next step is to parse the dot file to get the descriptions of the nodes and edges. Finally, we run QT to draw the call graph according to the detailed information about the nodes and edges. The solution provides flexible interaction with the users. They can click at each node of the function in the call graph to view the code of the function.
Another feature is to track the sensitive API and display the calling chain of those APIs. We can also use Graphviz to illustrate the call graph of those important APIs. The users can also configure to track the APIs they concern.
This feature likes the navigation buttons in a browser. When user wants to view the last method, he just clicks the GoBack button and then the current view will jump to the last method’s view. There’s also a GoForward button for viewing the forward method. To implement this feature, we can keep the viewing history.
This feature is very useful when you analyze many methods. With this feature, it can save much time to find and click the same method you analyzed a second ago.
(5) Repackaging Ability:
There might be some registers that we want to track. If we can add logs into the tested applications, we won’t be bothered to modify some low-level code when the platform is updated. To assist the users to modify the code, we should build a link between the Dalvik code and the smali code. We use apktool to reverse the applications to smali code. When user want to modify the code under the view of CFG, they will first jump to the smali code view and then revise the smali code.
|File name||Size||Date submitted|