Transcript VMM Based Rootkit Detection on Android

Midterm Meeting
Pete Bohman, Adam Kunk, Erik Shaw (ONL)
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
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)
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
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
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)
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)
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)
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
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.
Preliminary Results (boot time)
Android Boot Times of Images
90
80
70
Time (s)
60
50
40
30
20
10
0
zImage
real
70.263
user
46.65233333
sys
22.10233333
zVmm
84.05
58.64533
23.84267
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)