With the Google's Summer of Code (GSoC)[0] program Google is trying to motivate students from all over the world to participate in open source projects managed by various organizations. Therefore, every Google accepted organization publishes a number of topics relevant for the open source community. These topics are specially designed for GSoC students, which can either apply for one specific topic or simply suggest an interesting topic on their own. Accepted students are supervised by at least one mentor of the particular organization and sponsored by Google over a period of about three months -- Google's notion for the "Summer of Code".
Personally, I like the open source character of GSoC, which was the reason why I decided to apply for this year's event. I have applied for a project through the Honeynet Project[1]. To be more precise, my goal was to extend the open-source Xen hypervisor[2] to establish a foundation for DRAKVUF[3] on the ARM architecture. My project's abstract can be found on GSoC's homepage[4]. DRAKVUF is an open source, virtualization based binary analysis framework running on top of the Xen hypervisor. By using Virtual Machine Introspection (VMI) techniques, DRAKVUF is able to transparently monitor and control the state of a virtual machine from a level beyond the OS. While DRAKVUF is a powerful means to analyze malware, its use is currently limited to x86-64 based architectures. So, my GSoC project aimed to shift the scope of application of DRAKVUF towards ARM and thus the mobile market ultimately providing powerful malware analysis on mobile devices.
On x86-64 based systems, DRAKFUV is able -- among others -- to instrument and thus monitor binaries of interest for various analysis purposes. Even more, this can be done in a highly stealthy way by utilizing the system's hardware virtualization extensions. In short, the main idea is to maintain multiple 2nd stage memory translation tables representing different memory views for guests on the side of the hypervisor. For instance, the hypervisor can be configured to duplicate a specific page in the host's physical memory and assign one execute-only and one read-only view of the same page. While the execute-only page can be arbitrarily altered by the VMI-aware hypervisor or DRAKVUF for monitoring purposes, all guest read accesses to this particular page generate 2nd stage access violations and thus force the guest to trap into the hypervisor. On such violations, the hypervisor can switch to the integer, read-only memory view and satisfy the requested read access. Even more, modern Intel architectures allow to perform this switch without the need for expensive, explicit traps into the hypervisor but rather handle memory view switching directly within the context of the guest through the most recent virtualization extension called Virtualization Exceptions (#VE). After a read-request has been satisfied, the hypervisor can switch back to the altered, execute-only view and proceed guest execution. This mechanism is facilitated through the Xen altp2m subsystem[5] and is employed by DRAKVUF.
While the ARM architecture, does not provide sufficient hardware support to perform such as switch entirely in hardware, it is possible to enable a similar behavior in software. This is exactly the part where I come into play: The more specific goal of my GSoC project is to implement Xen's altp2m subsystem for ARM.
[0] Google Summer of Code
[1] The Honeynet Project
[2] The Xen Project
[3] DRAKVUF
[4] Foundations for DRAKVUF on ARM
[5] Stealthy monitoring with Xen altp2m
