Data Transfer with SSID
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.
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.
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.
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.
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.
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.
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.
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:
For adb connection, there are no further steps required. GenyMotion connects the virtual device and adb automatically.
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 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.
* regular devices: e.g. smartphone, tablet
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:
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.
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.
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
To install Burp’s CA certificate follow these steps:
PATH-TO-CA-CERT.DER /mnt/sdcard/CA-CERT.CRT(note the new filename ending –
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
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.
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
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
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
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.
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.
The table below shows some useful commands for analysts getting started with adb.
|Output a list of all installed packages, including the path to the package.||adb shell pm list packages -f|
|Pull a package from the system.||adb pull -p PATH-TO-PACKAGE|
|Backup the application data.||adb backup -f BACKUP-NAME PACKAGE|
|Push any file to the device||adb push FILENAME DSTIONATION-PATH|
|Pull any file from device||adb pull -p FILE-PATH|
|Start Emulator for a specific virtual device||.\explorer.exe -avd VIRTUAL-DEVICE-NAME|
|Generate a bug report||adb bugreport|
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.
Our experts will get in contact with you!
Our experts will get in contact with you!
Further articles available here