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 and Lenny 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.

Prerequisites the necessary background information one needs to know before installing Ether, and links to obtain all prerequisite software.

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 requires a 64-bit capable CPU. Ether will not compile on a 32-bit platform.

The latest version of Ether compiles and runs on Debian Lenny. Other Linux distributions could conceivably work, but Debian Lenny 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.

Install the Xen kernel package for the kernel revision you are using. As of this writing, the package to install is linux-image-2.6.26-1-xen-amd64. Do not install all of Xen, only the Xen-enabled kernel, and do not boot into this kernel, yet.

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. Keep in mind that you will not be using the 2.6.18 kernel that the Xen 3.1.0 installation will try to use by default. Double check any /boot/grub/menu.lst entries to ensure they point at the Xen kernel in the Debian package you installed earlier.

Once Xen is installed and working, make a copy of the source tree you installed from for use as a backup.

Create a new entry in your /boot/grub/menu.lst file for the Ether patched Xen hypervisor. This should be the same as the normal Xen entry, but of course modified to point to the new hypervisor. Double check that your boot entry points to the correct kernel and to the correct hypervisor.

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

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.

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.

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.

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:

The unpack commands are responsible for instructing Ether to perform unpack execution detection. These commands 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.

Since Ether 0.1, there are two ways to do unpack-execution detection. One method, used via the unpack_hypervisor command, allocates 256Mb of memory from the domain heap and uses it as a bit map to track memory locations which have been written. The other method, used via the unpack_userspace command, does not require a single large allocation and instead uses a hash table in dom0 userspace to keep track of locations which have been written to.

While the unpack_hypervisor method is faster, the unpack_userspace method uses less memory. Both should be equally effective.

Prior to issuing the unpack_hypervisor command, the maximum memory for a domain should be set to 256Mb more than the domain will 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 commands will not automatically terminate. You must manually terminate the ether_ctl process via SIGINT (Ctrl + C).

EtherUnpack will also attempt to repair memory dumps to be more like normal PE files. The original executable can be given as a parameter to EtherUnpack to aid in this task. It does not matter whether hypervisor unpacking or user-space unpacking is used.

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.