Ether: Malware Analysis via Hardware Virtualization Extensions

  • Paper
  • Source Code
  • Malware
  • Contact

Source Code

Ether comes in two components: one is patch set to the Xen hypervisor (version 3.1.0), and the other a userspace application which runs in a Xen dom0.

Ether is research quality code. It has only been tested on Debian Etch as the host operating system, and Windows XP Service Pack 2 as the guest operating system. In its present form Ether is not meant to be used in a production environment, but should instead be used as a research tool. All code is licensed under the GPL, unless otherwise noted in the file.

The directions for downloading, building and using Ether are outlined below in several separate sections.
  1. Prerequisites the necessary background information one needs to know before installing Ether, and links to obtain all prerequisite software.
  2. Patching the Xen Hypervisor describes how to patch Xen 3.1.0 with the Ether patches and how to successfully build the resulting code.
  3. Building the Ether Controller details the prerequisites for building the Ether controller application and the application build process.
  4. Preparing the Guests lists the requirements for guest operating systems Ether can trace and how to make them more compatible with Ether.
  5. Using Ether outlines the features of Ether and how to make use of Ether to do analysis on guest virtual machines.

Prerequisites

Ether uses Intel VT for transparent malware analysis, and therefore must be run on bare metal. Also, the machine onto which you are installing Ether must have an Intel VT capable processor and have Intel VT enabled in the BIOS. By default most BIOSes leave Intel VT disabled. Do not attempt to install Ether in a virtual machine.

Ether was developed on a Debian Etch system and that is the distribution assumed throughout this guide. Other Linux distributions could conceivably work, but Debian Etch is the only one on which Ether has been tested. The only guest operating system tested with Ether is Windows XP Service Pack 2, hence a Windows XP SP2 installation medium is also required.

Prerequisite download links:

  • Debian Etch:
    • http://www.debian.org/distrib/
  • Xen 3.1.0 Source:
    • http://bits.xensource.com/oss-xen/release/3.1.0/src.tgz/xen-3.1.0-src.tgz
  • Ether Xen Patch Set:
    • ether.patch.gz
  • Ether Controller:
    • ether_ctl.tar.gz
  • Ether Paper:
    • ether_ccs_2008.pdf

The basic installation outline is roughly the following:

  • Start with a fresh bare-metal install of Debian Etch with the standard Debian kernel.
  • Install Xen 3.1.0 from source and verify the Xen install works.
  • Patch the Xen kernel with the Ether patches.
  • Install the Ether userspace.
  • Install Windows XP SP2 domUs.
  • Analyze malware!

Patching the Xen Hypervisor

  • Start with a vanilla install of Debian Etch. Use the standard kernel provided, and not the Xen kernel, as you will be compiling Xen from source.
  • Download the source to the Xen hypervisor version 3.1.0. The Xen source code is available direct from XenSource at http://bits.xensource.com/oss-xen/release/3.1.0/src.tgz/xen-3.1.0-src.tgz
    artem@vmstudent:~/$ mkdir ether
    artem@vmstudent:~/$ cd ether
    artem@vmstudent:~/ether$ wget http://bits.xensource.com/oss-xen/release/3.1.0/src.tgz/xen-3.1.0-src.tgz
    artem@vmstudent:~/ether$ tar -xvzf ./xen-3.1.0-src.tgz
  • Build and install Xen 3.1.0 from the source you just downloaded. There are many excellent installation guides available on the web and can be found via a simple search.
  • Once Xen is installed and working, make a copy of the source tree you installed from for use as a backup.
  • Download and apply the Ether patch to the original source tree:
    • artem@vmstudent:~/ether$ wget http://ether.gtisc.gatech.edu/ether.patch.gz
    artem@vmstudent:~/ether$ gunzip ether.patch.gz
    artem@vmstudent:~/ether$ patch -p0 < ether.patch
    patching file ./xen-3.1.0-src/xen/arch/x86/hvm/ether_bp.c
    patching file ./xen-3.1.0-src/xen/arch/x86/hvm/ether.c
    patching file ./xen-3.1.0-src/xen/arch/x86/hvm/ether_unpack.c
    patching file ./xen-3.1.0-src/xen/arch/x86/hvm/hvm.c
    patching file ./xen-3.1.0-src/xen/arch/x86/hvm/Makefile
    patching file ./xen-3.1.0-src/xen/arch/x86/hvm/nls.c
    patching file ./xen-3.1.0-src/xen/arch/x86/hvm/vmx/vmcs.c
    patching file ./xen-3.1.0-src/xen/arch/x86/hvm/vmx/vmx.c
    patching file ./xen-3.1.0-src/xen/arch/x86/mm/shadow/common.c
    patching file ./xen-3.1.0-src/xen/arch/x86/mm/shadow/multi.c
    patching file ./xen-3.1.0-src/xen/arch/x86/mm/shadow/private.h
    patching file ./xen-3.1.0-src/xen/arch/x86/mm/shadow/types.h
    patching file ./xen-3.1.0-src/xen/common/domctl.c
    patching file ./xen-3.1.0-src/xen/common/event_channel.c
    patching file ./xen-3.1.0-src/xen/include/asm-x86/hvm/domain.h
    patching file ./xen-3.1.0-src/xen/include/asm-x86/hvm/ether_bp.h
    patching file ./xen-3.1.0-src/xen/include/asm-x86/hvm/ether.h
    patching file ./xen-3.1.0-src/xen/include/asm-x86/hvm/ether_unpack.h
    patching file ./xen-3.1.0-src/xen/include/asm-x86/hvm/msw.h
    patching file ./xen-3.1.0-src/xen/include/asm-x86/hvm/nls.h
    patching file ./xen-3.1.0-src/xen/include/asm-x86/hvm/support.h
    patching file ./xen-3.1.0-src/xen/include/asm-x86/hvm/vmx/vmcs.h
    patching file ./xen-3.1.0-src/xen/include/asm-x86/hvm/vmx/vmx.h
    patching file ./xen-3.1.0-src/xen/include/asm-x86/paging.h
    patching file ./xen-3.1.0-src/xen/include/public/domctl.h
    patching file ./xen-3.1.0-src/xen/include/public/hvm/ether.h
    patching file ./xen-3.1.0-src/xen/include/xen/event.h
    patching file ./xen-3.1.0-src/xen/symlink_header.sh
  • Compile the modified Xen source. Only Xen itself needs to be recompiled, and not the dom0 kernel.
    artem@vmstudent:~/ether$ cd xen-3.1.0-src/xen
    artem@vmstudent:~/ether/xen-3.1.0-src/xen$ make clean && make
  • Create a new entry in your /boot/grub/menu.lst file for the Ether patched Xen kernel. This should be the same as the normal Xen entry, but of course modified to point to the new hypervisor.
  • Copy the Ether patched Xen to your /boot directory. Ensure the destination you copy to matches the file GRUB expects to load on bootup.
    artem@vmstudent:~/ether/xen-3.1.0-src/xen$ sudo cp -v ./xen.gz /boot/xen-ether.gz
  • Insert a symbolic link from the public Ether header files in the source tree to the global include directory. This will ensure the Ether userspace will compile. There is a script provided for this, which assumes default locations present on Debian Etch.
    artem@vmstudent:~/ether/xen-3.1.0-src/xen$ chmod +x ./symlink_header.sh
    artem@vmstudent:~/ether/xen-3.1.0-src/xen$ sudo ./symlink_header.sh
  • Restart the machine and cross your fingers. Be sure to select the boot entry you created for Ether in the GRUB menu during bootup. Once the machine boots up, proceed to the next step of building the Ether controller.

Building the Ether Controller

  • The Ether controller relies on several external libraries. On Debian Etch, the following packages must be installed prior to building Ether.
    • libdisasm0
    • libdisasm-dev
    • bison
    • flex
  • Download the Ether controller source: ether_ctl.tar.gz. This application is meant to be run in domain 0 of an Ether patched Xen hypervisor.
    artem@vmstudent:~/ether$ wget http://ether.gtisc.gatech.edu/ether_ctl.tar.gz
    artem@vmstudent:~/ether$ tar -xvzf ./ether_ctl.tar.gz
  • Build the Ether controller.
    • artem@vmstudent:~/ether$ cd ether_ctl
    artem@vmstudent:~/ether/ether_ctl$ make clean && make

Preparing the Guests

The only guest operating system Ether has been extensively tested with is Windows XP Service Pack 2. When installing the OS on a domU, do it with the APIC disabled in the hvm guest configuration file.

There is a Windows guest installation guide provided by XenSource available at http://ether.gtisc.gatech.edu/xen_install_windows.pdf

Example hvm guest configuration file:

import os, re
arch = os.uname()[4]
if re.search('64', arch):
     arch_libdir = 'lib64'
else:
     arch_libdir = 'lib'
#----------------------------------------------------------------------------
# Kernel image file.
kernel = "/usr/lib/xen/boot/hvmloader"
# The domain build function. HVM domain uses 'hvm'.
builder='hvm'
# Initial memory allocation (in megabytes) for the new domain.
memory = 128
# A name for your domain. All domains must have different names.
name = "windows-001"
# enable/disable HVM guest ACPI, default=0 (disabled)
acpi=0
# enable/disable HVM guest APIC, default=0 (disabled)
apic=0
# Pae
pae=0
cpus = "1" # all vcpus run on CPU1
vif = [ 'type=ioemu, mac=aa:cc:b0:00:00:11, bridge=xenbr1' ]
disk = [ 'file:<path to disk image>,ioemu:hda,w' ]
boot="cda"
vnc=1
vncviewer=0
ne2000=0

Once the Windows XP Service Pack 2 guest is installed, the boot.ini file needs to be edited to disable PAE in the guest. The current version of Ether does not support memory write detection in PAE guests. Both the /noexecute=alwaysoff and the /nopae options must be added to boot.ini to actually disable PAE in Windows.

Example Windows boot.ini file:

[boot loader]
timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect /nopae /noexecute=alwaysoff

Using Ether

This version of Ether can be used to trace Windows Native API calls executed by an application (and their return values), instructions executed by that application, any unpack-execution behavior, and also memory writes. In addition, introspection of Native API calls is performed. Such introspection includes displayin system call names, interpretation of typed arguments, attempted DNS lookups, and TCP connection attempts.

The general format of Ether controller invocation is:

artem@vmstudent:~/ether/ether_ctl$ sudo ./ether <domain_id> <command> [parameters]

Specific Ether Features:

  • System Call Tracing
    System call tracing is performed by the systrace command. By default, Ether will trace system calls executed by every process in the guest operating system. However, a specific process may also be selected. The other optional parameter passed to the systrace command is the guest virtual address on a page guaranteed to be marked as non-present. By default it is assumed to be 0xFFFFD0AE.

    To trace all Native API calls executed by every process in the guest:

    artem@vmstudent:~/ether/ether_ctl$ sudo ./ether 1 systrace

    To trace system calls for a specific process:

    artem@vmstudent:~/ether/ether_ctl$ sudo ./ether 1 systrace exe_file

    To trace system calls for a specific process using an alternate not-present address:

    artem@vmstudent:~/ether/ether_ctl$ sudo ./ether 1 systrace exe_file 0xDDDD1234

    To trace system calls for a all processes using an alternate not-present address:

    artem@vmstudent:~/ether/ether_ctl$ sudo ./ether 1 systrace % 0xDDDD1234
  • Unpack-Execution Detection

    The unpack command is responsible for instructing Ether to perform unpack execution detection. This command will only attempt to detect unpack execution in a specific process, the name of which is specified as a parameter to the command. Any unpack-execution layers found in the guest are saved in the images directory. The target does not have to be executing when the command is issued, Ether will attempt to match the name to any processes executed after the command is entered.

    Prior to issuing the unpack command, it is important that the maximum memory available to the domain is at least 256Mb more than the domain memory use. Ether needs to allocate 256Mb of memory from the domain heap to keep track of dirty guest memory addresses. A shell script, prepare_domain.sh, is provided for the purpose of automating this preparation process.

    The unpack command will not automatically terminate. You must manually terminate the ether_ctl process via SIGINT (Ctrl + C).
    artem@vmstudent:~/ether/ether_ctl$ sudo ./prepare_domain.sh 1
    artem@vmstudent:~/ether/ether_ctl$ sudo ./ether 1 unpack packed_file
  • Instruction-Level Tracing

    The instrtrace command will display instructions executed by a specific process in the system. The parameters to this command are the domain and the process name to trace. The Ether controller will attempt to disassemble and display the executed instructions. Some instructions however do not disassemble correctly. I believe this is a fault of the disassembler library

    artem@vmstudent:~/ether/ether_ctl$ sudo ./ether 1 instrtrace exe_file
  • Memory Write Detection

    Memory write detection is performed by the memwrite command. As an argument, the command takes the name of a process for which to trace memory writes. The guest virtual address of the instruction causing the write, the guest virtual address of the write location, and the calculated length of the write are reported.

    artem@vmstudent:~/ether/ether_ctl$ sudo ./ether 1 memwrite exe_file