Exception is an uncontrollable situation which can not handle by programs. For exam-ple, crash is an unpredictable programs termination usually happen in real world. This main reason for situation caused by the programmers that they do not assigned the error handler in source code. Other reasons such as buffer overflow, memory corruption may effected by some input or read and write memory very frequently. In the other hand, an invalid input may also affect the control flow lead to the exception happening.
The explicit flows will always to be executed, since the if condition was only satisfied by the “conditional true” expression in the control flow. Exception in explicit flows will easily discover by executing the program, but not suitable for implicit flows because its not always to be executed.
As mention in Section4.3, during the progress of path exploration, explicit flows and implicit flows would covered and executed by symbolic exploration engine. In this part, we focused on an external exception handler to intercept the crash signal without inspect the application’s source code.
Chapter 5
Implementation
In this chapter, we explain the details about our method was implemented on top of S2E[34], which is a system wide symbolic execution platform. Our symbolic environment on S2E that assist symbolic propagation through symbolic components over black-box and white-box mode. To gain faster testing life cycle, we reduced testing time by porting our environment to x86 Android[35]. Moreover, we have modified Android kernel to intercept system call and collecting exception signal for further diagnosis.
5.1 Symbolic Environment
5.1.1 The architecture of S
2E
S2E platform has an ability to perform symbolic execution on the whole operation system rather than applications. This platform come with the combination of QEMU[36] and KLEE[37]. KLEE is a symbolic execution engine build on top of the LLVM compiler infrastructure. It implement symbolic execution by interpreting LLVM bitcode. QEMU is a process emulator that relies on dynamic binary translation to translate instructions between two different CPU architecture. Whenever any programs test inside QEMU emulator accessed symbolic data, S2E platform switch to LLVM back-end to translate instructions into LLVM bitcode and feed KLEE engine to perform symbolic execution over the whole system. The architecture of S2E is shown in Figure 9
Figure 9: The architecture of S2E.
5.1.2 ARM Android on S
2E
The official Android is formerly designed for ARM architecture and processor. ARM-based processors provider greater power efficiency with higher performance and lower power consumption.[38] Most of the smartphone vendors are embedded ARM-based CPU to gain performance and long lasting battery life.
In the development phase, developer allow to test and debug their application in em-ulator that emulates Android environment by Android QEMU come with Android Soft-ware Development Kits(SDK). The emulator is not targeted for specify ARM System-On-Chip(SoC), instead Android QEMU used to create a virtual ARM SoC called Goldfish[39]
to replace the functionality of real hardware and periphery devices. Figure10shown that the emulator(as known as Android QEMU) run as virtual machines in a process on the guest operating system. At the first step, Android QEMU uses dynamic binary transla-tion(DBT) to translate ARM instructions into x86 instructions to emulate a smartphone environment. For the second step, S2E emulate whole system environment and prepare to performs symbolic execution. We do not recommend to experiment on this approach, since S2E QEMU takes more than 5 minutes to boot Windows 7 as the guest operating system, and we still not successful yet to boot Android on Android QEMU. Emulator that executed in another emulator is complicated and it slow down the testing life cycle.
Leakalizer in Section 3.4 proposed their prototype by porting S2E to ARM. They modified parts of S2E to boot an Android software stack inside S2E.
Figure 10: The architecture of ARM Android on top of S2E and the screenshot of the Android emulator that emulates virtual smartphone devices to run Android software stack on x86 S2E QEMU.
5.1.3 x86 Android on S
2E
x86 Android[35] is another unofficial branch of Android, which enabling Android software stack executed on x86 CPU. Besides ARM-based smartphones, x86 Android also porting to some netbooks PC such like Asus Eeepc to run Android as a native operating system.
Since x86 Android aim for non-smartphone devices, some phone functionality and Gold-fish is not necessary to virtualize and implement, i.e. telephone communication, camera, sensors and others. Although lack of some basic phone functionality, Internet access and App usages still work well in x86 Android.
Figure 11 shown that x86 Android run as native operating system on S2E without emulate Goldfish. CRAXdroid based this approach to construct an environment for black-box and white-black-box testing mode.
Figure 11: The architecture of x86 Android on top of S2E and the screenshot of the x86 Android run as native operating system.
5.1.4 The architecture of CRAXdroid
The overall architecture of our CRAXdroid testing environment is based on x86 Android on top of S2E platform shown at Figure 12. In this figure, testing is divided into two parts which is black-box and white-box mode. Furthermore, three outcome provides by CRAXdroid such as branch coverage details, exception information, and white-box verification.
Figure 12: The architecture of CRAXdroid.
5.2 Symbolic Components
Figure13 shown that CRAXdroid establishes communication between Android and S2E at three abstraction levels, Java code, C/C++ code, and assembly code. The left side shows that white-box testing is relied on platform layer, while black-box testing at the right side is relied on system layer. We discuss the details in following sub section.
5.2.1 Platform Layer
We defined platform layer which is middleware of Android, i.e. Android runtime, Android API. Android runtime is an essential core libraries that used to support the environment
Figure 13: The implementation of symbolic value propagate through white-box and black-box mode.
for Apps to run smoothly on Android. To archive Apps testing purpose, various of testing units can be inject into the Android runtime. In this layer, we bridge the connection to lower layer(i.e. System-layer) and carry out the symbolic value to construct the testing units(e.g, Char, Int).
For example, Char and Int are the common types used in programming language.
Developer is able to leverage the symbolic execution technique by using this types of variable in their source code. The symbolic value can assigned to variable by the native function in Appendix7, which connected to symbolic interfaces.
5.2.2 System Layer
We defined system layer which is OS level, i.e. Linux kernel, Java Native Interface(JNI).
In contrast with the platform-layer, system-layer do not need to modify the variable or operands within the Apps source code. Instead, CRAXDroid passively provide the symbolic units “outside the box” as the external components for Apps environment. While the Apps testing in black-box mode, App may require to access the external components such as file I/O, and network I/O. Once the Apps was accessed the external components, symbolic execution will be perform.