Today’s article is all about building an Android Lab based on virtual devices. While using physical devices is straight-forward and requires less effort for setting up a lab, there are drawbacks to consider. For example, if more than one analyst works on a project where the analysis of an Android app is required, either all have a device (expensive solution) or a good time schedule (administrative overhead) is necessary.

Another drawback is the update cycle of Android. On purchase, it’s uncertain how many new versions will be supported by the manufacturer of the device and how long it will take until the device can be updated. Using virtual devices reduces the cost and allows multiple analysts to work on their engagement at the same time.

Virtual Device Android Lab

Key requirements for the Android Lab are cost effectiveness, scalability and the state as well as frequency of updates. A lab solely based on physical devices would fail those requirements.

• Not scalable: An increasing headcount and/or project-count would require the purchase of even more devices.
• Expensive: Purchase of hardware is more expensive than the use of virtual devices (which may come at the cost of a license fee)
• Android Update-cycle: Physical devices may not receive the newest version in due time. Too many variables can influence the updating process of a device (Google, Manufacturer, Network Provider). Long term, having bleeding-edge Android systems equals buying new devices on release date every so often.

The combination of those issues make the use of a hardware-only based Android Lab problematic. However, this does not mean there shouldn’t be physical devices ready for testing. It’s likely that a project requires the use of a physical device.

The alternative to a physical device are virtual devices – known as emulators. There are different options available, from the SDK-included emulator, to the open source Android-x86 port, to other products like GenyMotion or Andy. The following sections give a quick overview of some of these options.

The Android-x86 Port

Android-x86 is an open source project. The name already discloses its goal – the porting of the Android source code to an x86 platform. As of this writing in autumn 2014, the project provides a port of the Android 4.4 version.

The ISO file can be used as a live OS or installed on x86 systems. We are not going into detail about the installation of Android-x86 on a VMware or VirtualBox VM. The process is straight forward and easy to handle for experienced users when it comes to the creation of Linux/Unix VM systems. In case of trouble, there are a number of blog posts that can help.

Lab Setup Android-x86

When started in a VM, the Ethernet link will be used as mobile network connection. To route network traffic via an intercepting proxy (e.g.: Burp Proxy), a few more steps are necessary. Probably the simplest solution is the use of another VM as network proxy. This VM will forward any HTTP and HTTPS traffic from the Android-x86 VM to the intercepting proxy. Such a setup was described in an earlier scip Labs article by Pascal Schaufelberger. Additionally to that setup, it is advised to create another dedicated virtual network interface connecting to the network where the Android-x86 and proxy VM are communicating. This link will be used for any Android Debug Bridge (adb) connection.

Note: VMware Player users cannot create an additional virtual network interface on the host. Therefore, using adb and intercepting web traffic at the same time is not possible. One has to reconfigure the network of the Android-x86 VM.

Anyhow, to connect to the device and adb the IP address assigned to the Android-x86 VM is required. Enter the console by pressing Alt+F1 and execute the command netcfg. On the host system, start a command line and execute the following commands to connect adb and the Android-x86 VM.

* check for any connected devices
adb devices
* connect to Android-x68
adb connect <IP-ADDRESS>
* list the connected devices
adb devices

After this configuration, the Android-x86 VM can be accessed via adb. You are now able to monitor its network traffic via intercepting proxy and monitor any other network traffic on the proxy VM using a tool such as tcpdump or tshark.

Conclusion Android-x86 VM

Comparing the Android-x86 VM with other emulators offers good usability and is a great tool for VM based virtual devices. It does, however, require a more hands-on approach during the initial setup and may not provide a stable latest version of Android. This solution comes at no additional cost.

The GenyMotion Emulator

GenyMotion is a company selling Android emulators. There is no specific reason why GenyMotion was used for this article.

GenyMotion offers a variety of products on their web site. A free version is available for testing and personal use. The tool comes as bundle with Oracle’s VirtualBox or as an additional piece of software if VirtualBox is already installed.

Using it is straight forward; an account is required to access the GenyMotion cloud and download the software, as well as the images from within the GenyMotion tool. The tool is some kind of virtual device manager. On the plus side, there’s the fact that the virtual device configurations that are available are as numerous as with the original Android SDK Emulator.

Hint: You might want to disable that the GenyMotion tool reports back to GenyMotion for product improvements.

Lab Setup GenyMotion

Different than Android-x86, GenyMotion disables the mobile network and enables a virtual WLAN, which is the network interface used by VirtualBox. To configure the proxy settings, for the use of an intercepting proxy, follow these simple steps:

1. Navigate to the wireless settings (Settings → Wi-Fi)
2. Long-click on the only available and connected wireless LAN (WiredSSID)
3. Choose Modify network and tick the checkbox for Show advanced options
4. Set the drop-down list Proxy on Manual and fill-in the blanks

For adb connection, there are no further steps required. GenyMotion connects the virtual device and adb automatically.

Conclusion GenyMotion

GenyMotion provides a solid virtual emulator. Especially interesting is the device and OS range offered to create a virtual device. If used for business, a 99 Euro license fee per year and user is charged. The emulator is quick and responsive. The interface allows controlling various hardware elements without much trouble.

The Android SDK Emulator

The Android SDK ships an emulator by itself. It is part of the Android SDK installation. For ever new Android version, there will be a new emulator image. With the current version (Android L), four system images are available for download.

1. ARM based for Android TV
2. Intel based for Android TV
3. ARM based for regular devices *
4. Intel based for regular devices *

* regular devices: e.g. smartphone, tablet

Lab Setup Android SDK Emulator

A virtual device is created by using AVD Manager. The GUI allows configuring more than just the device and Android version – much like GenyMotion does.

After its creation, a virtual device can be started directly in the AVD Manager. The command line emulator (located in PATH-TO-SDK\tools) offers many switches to start and influence the execution of the virtual device. For example to declare the use of an intercepting proxy the switch -http-proxy configures a proxy server for the virtual mobile network.

This command starts a virtual device and sets the proxy option.

.\emulator.exe -avd VIRTUAL-DEVICE-NAME -http-proxy http://PROXY-IP:PROXY-PORT

Note: if the proxy is not reachable during the power-on of the virtual device, it will be ignored.

The Android SDK emulator has a reputation for being very slow and clumsy. But don’t panic, there are some tweaks to enhance the performance. While creating a virtual device make sure to follow these steps:

1. Use as much RAM as possible for the virtual device. In Windows, a notification pops up that says that using more than 768 MB RAM may fail. If you can, ignore this warning.
2. Tick the checkbox Use Host GPU (Enables Hardware OpenGLES emulation)
3. Download the package Intel x86 Emulator Accelerator (HAXM installer) located under Extras using SDK Manager

Conclusion SDK Emulator

Even with GPU enabled emulation, the virtual device is slightly slower than the other two emulators. An advantage is that the SDK will provide an image right at the release date of a new version at no cost.

Option One, Two or Three?

There is not really an answer to the question which solution is the best. The answer greatly depends on the Android Lab requirements. All three options have their advantages and disadvantages. Using the original SDK emulator certainly is helpful if bleeding-edge Android versions are required and the performance drawback does not factor into testing too much. Additionally, if any of the command line switches, such as -http-proxy, are needed this is a good way to go.

The other two options follow a different approach and are easier to compare with each other. Android-x86 is a good option if the newest Android version is not required and the virtual device needs to operate in a more customizable environment. The solution comes at no cost, just like the Android SDK emulator.

GenyMotion on the other hand is a closed product. It comes with its own virtual device management application, a special shell, and performs all the necessary tasks for a developer – or penetration tester – to start right away. The handling feels slightly better than it does with Android-x86 and the user interface allows the tweaking of many hardware features. This is most likely more important to developers, but could come in handy during an application test as well.

Burp Proxy Certificate Installation

There will be the moment when the developers of your target application – hopefully – use SSL encrypted HTTP. To get rid of the warning messages that this creates, Burp’s CA certificate can be installed.

This simple task can become a real hassle when you realize that Burp Proxy exports – or provides via http://PROXY-IP:PROXY-PORT/cert – a file named cacert.der and Android expects a .crt file.

To install Burp’s CA certificate follow these steps:

1. Open Burp Proxy and navigate to the tab Proxy
2. In the Proxy tab, navigate to Options
3. Click the button CA certificate … and choose the radio button Certificate in DER format
4. Finish the export procedure and start a command line
5. Push the CA cert on the virtual device using adb push PATH-TO-CA-CERT.DER /mnt/sdcard/CA-CERT.CRT (note the new filename ending – .crt)
6. On the virtual device navigate to Settings → Security → Install from SD card
7. Choose the location and click on the file. The certificate installation starts

This procedure works for almost any setup. The one notable exception is the SDK Emulator for Android 4.4.2. The menu item Install from SD card opens a file browser – as it does with all the other versions – but does not show the emulated internal SD card.

To install Burp’s CA certificate for an Android 4.4.2 SDK Emulator device, follow the first four steps described in the procedure above. Then place the file on a web server. It’s advised to use an internal test web server for this one. Now in the virtual device, start the web browser and browse to that file. Android will recognize the certificate and starts the installation process.

The last procedure would be much easier if either Android would not filter for .crt files specifically, or Burp Proxy would allow setting the filename for the browser access via http://PROXY-IP:PROXY-PORT/cert.

Automation via ADB

The Android Debug Bridge offers wide range of functionalities and is a great and valuable tool. No matter on which host system you’re working, you will be able to build your own scripts with this tool.

Application Installation

The installation of an application changes the operating system. The information about said changes may be of great value during the performing of analyses. Therefore, a script executing the following commands would help you out.

adb shell touch /mnt/sdcard/test
adb install PATH-TO-APK
adb shell find / -type f -newer /mnt/sdcard/test > fs-change-install.log
adb shell rm /mnt/sdcard/test

The fs-change-install.log contains a lot of information which stems from regular operation. Therefore all entries starting with /proc can be removed to see what really has changed. If the find command only runs in /data, chances are that some changes are not seen in fs-change-install.log.

Application De-installation

Just like any installation, information about file system changes after uninstallation of an application can be of interest. Another script executing the following commands would provide this information.

adb shell touch /mnt/sdcard/test
adb uninstall PACKAGENAME
adb shell find / -type f -newer /mnt/sdcard/test > fs-change-uninstall.log
adb shell rm /mnt/sdcard/test

Other Little Helpers

There are a lot of options for automation. All you need is the knowledge of the tools provided by the SDK and some scripting skills.

The last part of this article focuses on the knowledge of the tools the SDK provides, their usefulness and their helpfulness during the task of application analysis.

Android Device Monitor

This particularly helpful tool is located in PATH-TO-SDK/tools and called monitor.bat. Among other information, it lists the currently running virtual devices, their current running packages, Heap, Allocation Tracker, File Explorer and a rolling view of the device’s log.

Helpful Commands

The table below shows some useful commands for analysts getting started with adb.

Conclusion

Using virtual devices, there are several options for extending an Android Lab based solely on physical devices. The same options apply when establishing a new Lab altogether. It is worth taking a step back and analyzing the needs and requirements of the test environment. There are good free solutions available, but you might want to invest in a platform that will end up costing licensing fees. Needless to say, the license fee is most likely less than a physical device and the newest Android version will be ready for testing.

The tools provided by the Android SDK are worth taking a closer look at. The command line based execution of adb offers a great possibility to create your own tools, streamlined to the specific process.

About the Author

Oliver Kunz has been in information security since 2010. Mainly, he deals with incident response, forensics and the security of mobile devices.

Links

• http://developer.android.com/tools/help/adb.html
• http://developer.android.com/tools/help/emulator.html
• http://portswigger.net/burp/proxy.html
• http://www.android-x86.org
• http://www.android-x86.org/download
• http://www.andyroid.net
• http://www.genymotion.com/
• http://www.scip.ch/en/?labs.20121206
• http://xmodulo.com/2013/02/how-to-install-and-run-android-vm-on-vmware-player.html
• https://www.virtualbox.org/