VMM Based Rootkit Detection on Android

1. VMM Based Rootkit Detection on Android Midterm Meeting Pete Bohman, Adam Kunk, Erik Shaw (ONL)

2. Outline • The problem and why it is important • Our solution and why it is better • Proof of concept • LKM syscall table hook • Preliminary Design • Defensive syscall integrity LKM • Android VMM • Preliminary Results

3. The Problem • Detecting rootkits on Android smart phones • This is important because: • Smart phone use is tremendously growing (especially Android, it just took 1st place) • Phones are starting to be used like mini computers • Phones carry lots of sensitive data (more than a computer at times) • GPS location, contacts, text messages, call data, • People make purchases on their phones (billing info)

4. The Problem (cont.) • Rootkits are a major problem on any traditional monolithic operating system on our desktop computers • Android OS is modeled after the Linux kernel • This means that many of the attack methods (LKM rootkits) that are targeted for the Linux OS may be applicable to Android • Currently, power consumption is a major factor in the prevention methods

5. Our Solution • Two part solution: • VMM layer to live below the guest Android OS • Layer below approach to ensure integrity of the LKM that lives alongside the kernel • This is necessary in the event that another LKM attempts to hook into our LKM • Minimal execution in the VMM to preserve power • LKM that monitors the integrity of the syscall table and corresponding functions • Would be executed at regular intervals

6. Proof of concept • Demonstrating that the syscall table can be hooked • This is how a rootkit can try to hide from the operating system • (NOTE: We need to add a design picture of the syscall hooking LKM)

7. Preliminary Design (cont.) • Android VMM lives a layer below the guest operating system, the Android kernel • Android VMM will check integrity of the LKM that monitors the syscall table and pointed to functions • (picture will go here of our VMM design)

8. Preliminary Design (cont.) • Modifying the boot order is not enough • We must also modify the QEMU emulator to trap to our VMM • This allows our VMM to get execution after booting the Android guest OS • (picture will go here of our VMM interaction with qemu, how we trap into our VMM)

9. Preliminary Design (cont.) • (Picture will go here of our design for our LKM that checks integrity of syscall table and the functions contained within) • LKM checks integrity of syscall table and functions pointed to • This is checked periodically • Root of trust is placed within the VMM • The VMM checks integrity of this LKM from a layer below

10. Preliminary Results (boot time) • Boot times of normal Android (zImage) image versus the VMM (zVmm) image were measured. • The results to the right demonstrate the average of three boots for each image. • The Linux ‘time’ utility was used to obtain the ‘real’, ‘user’, and ‘sys’ running times of each boot. • The ‘boot time’ was measured as the time from booting the image in the Android emulator to the time it took for the emulator to boot up and unlock the initial screen.

11. Preliminary Results (boot time)

12. Preliminary Results (cont.) • If we get the syscall hooking LKM up and running, maybe we can show some data here • (Or, we might be able to do some power measurements by invoking some random function that does a hash of memory every minute or something, be creative)