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: VMM • Android VMM lives a layer below the guest operating system, the Android kernel • Android VMM will check integrity of the LKM that monitors the syscalltable

8. Preliminary Design: VMM (cont.) • Reproduce VMM design described in “Embedded VMM for Portable Virtual Machines” • Booting and Initialization • VMM image contains guest OSs as binary data • Enable Cache and MMU • Guest OS Loading • Load each OS at a separate physical address • Individual virtual machine state structure • Memory Management • Manage VMM page tables • Shadow page tables for guest OS

9. Preliminary Design: VMM (cont.) • Full virtualization through hardware virtualization extensions. • Modified QEMU ARMv7 CPU Emulator to trap to VMM upon privileged instruction execution. • Bhardwaj et al. A Choices Hypervisor on the ARM Architecture. Bhardwaj et al. • Kalla et al. Embedded VMM for Portable Virtual Machines

10. 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

11. 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.

12. Preliminary Results (boot time)

13. 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)