Android Lab basierend auf virtuellen Geräten

Android Lab basierend auf virtuellen Geräten

Oliver Kunz
von Oliver Kunz
Lesezeit: 18 Minuten

In diesem Artikel dreht sich alles um den Aufbau eine Android Labs, das auf virtuellen Geräten läuft. Die Verwendung von physischen Geräten ist im Normalfall schnörkellos und benötigt weniger Zeit, um ein voll funktionsfähiges Lab zu sein. Dennoch gibt es bedeutende Nachteile. Wenn mehr als ein Analyst an einem App-Analyse-Projekt arbeitet, dann muss jeder Analyst ein eigenes Gerät mit identischem Setup besitzen (teure Lösung), oder das Zeit Management muss sehr gut sein (administrativer Overhead).

Ferner gilt es den Update-Cycle Androids zu beachten. Beim Kauf ist es nicht klar, wie viele zukünftige Android-Versionen vom Hersteller des Geräts unterstützt werden und wie lange es dauert, bis die unterstützten Updates erhältlich sein werden. Mit virtuellen Geräten können nicht nur mehrere Analysten am selben Projekt arbeiten, sondern das Problem des Update-Cycles löst sich ebenfalls.

Das virtuelle Android Lab

Eine Schlüsselvoraussetzung des Labs sind Kosteneffizienz, Skalierbarkeit und Stand der Updates. Ein Lab, das nur auf physischen Geräten basiert, würde an diesen Anforderungen scheitern.

Die Kombination all dieser Faktoren macht ein rein hardwarebasiertes Labs problematisch. Dennoch soll das nicht heissen, dass in einem voll funktionsfähigen Labs keine physischen Geräte vorhanden sein sollten. Es ist sogar wahrscheinlich, dass physische Geräte für gewisse Projekte sogar unabdingbar sind.

Die Alternative zu physischen Geräten sind virtuelle Maschinen – Emulatoren. Davon gibt es mehrere, vom im SDK inbegriffenen Emulator über die quelloffene Android-x86 bis hin zu Produkten wie GenyMotion oder Andy.

Die Android-x86 Portierung

Android-x86 ist ein Open-Source-Projekt, dessen Name Programm ist. Es geht darum, den Android Quellcode auf eine x86-Plattform zu portieren. Zum Zeitpunkt, an dem ich diesen Artikel im Herbst 2014 schreibe, bietet das Projekt eine Portierung von Android 4.4 an.

Die ISO-Datei kann als Live-Betriebssystem verwendet werden oder auf einer x86-Plattform installiert werden. Über die Installation müssen wir keine grossen Worte verlieren, denn jeder, der etwas Erfahrung mit der Erstellung von Linux/Unix Virtual Machines hat, kann die ISO in VMware oder VirtualBox zum Laufen bringen. Sollten dennoch Probleme auftauchen, bieten Blog Posts Hilfe.

Das Setup von Android-x86

Beim Start von Androind-x86 in einer VM wird der Ethernet-Link als Stellvertretung für mobile Netzwerkverbindung verwendet werden. Um Netzverkehr über einen Intercepting Proxy (zum Beispiel Burp Proxy) umzuleiten, sind noch einige weitere Schritte notwendig. Am einfachsten ist es wohl, eine weitere VM als Netzwerk-Proxy zu verwenden. Diese VM wird den ganzen HTTP- und HTTPS-Traffic von Android-x86 über den Intercepting Proxy leiten. Dieses Vorgehen wurde von Pascal Schaufelberger in einem früheren Labs-Artikel ausführlich beschrieben. Zusätzlich zu diesem Setup ist es ratsam, ein weiteres dediziertes virtuelles Netzwerk einzurichten, das sich mit dem Netzwerk verbindet, welches mit Android-x86 und der Proxy-VM kommuniziert. Dieser Link wird für die Android Debug Bridge (adb) verwendet.

Nutzer von VMware Player können keine zusätzlichen virtuellen Netzwerkinterfaces auf dem Host erstellen. Das macht die gleichzeitige Verwendung von adb und einem Intercepting Proxy, der Webtraffic überwacht, unmöglich. Daher muss in dem Falle die Netzwerkverbindung der Android-x86 VM rekonfiguriert werden.

Wie dem auch sei, um sich mit einem Gerät und adb verbinden zu können, ist die die IP-Adresse, die der Android-x86 VM gehört, notwendig. Gehen Sie in die Konsole, indem sie ALT+F1 drücken und führen Sie den Befehl netcfg aus. Danach starten Sie auf dem Host-System eine Command Line und führen Sie folgende Befehle aus, um adb und die Android-x86 VM zu verbinden.

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

Nach diesen Einstellungen kann über adb auf die Android-x86 VM zugegriffen werden. Sie sind nun in der Lage, den gesamten Netzwerkverkehr über einen Intercepting Proxy einzusehen und allen anderen Netzwerkverkehr auf der Proxy VM mit Tools wie tcpdump und tshark zu überwachen.

Zusammenfassung Android-x86 VM

Im Vergleich mit anderen Emulatoren bietet die Android-x86 VM gute Nutzbarkeit und ist ein gutes Tool für VM-basierte virtuelle Geräte. Allerdings erfordert das initiale Setup einen grösseren Aufwand und kann unter Umständen nicht die neueste Android-Version unterstützen. Android-x86 ist mit keinerlei Zusatzkosten verbunden.

Der GenyMotion Emulator

GenyMotion ist eine Firma, die Android-Emulatoren verkauft. GenyMotion bietet einige Produkte auf ihrer Website an. Eine Gratisversion eines Emulators ist zu Testzwecken und zum persönlichen Bedarf vorhanden. Das Tool kommt im Bündel mit Oracles VirtualBox oder als Standalone Software wenn VirtualBox bereits installiert ist.

Die Verwendung GenyMotions ist einfach: Ein Account ist notwendig, um auf die GenyMotion-Cloud zuzugreifen und die Software herunterzuladen. Weiter müssen die Images mit dem GenyMotion-Tool heruntergeladen werden, das da eine Art von Manager für virtuelle Geräte ist. Auf der positiven Seite steht die Tatsache, dass die virtuellen Gerätekonfigurationen so zahlreich sind, wie die des originalen Android SDK-Emulators.

Unter Umständen wollen Sie die automatischen Produktberichte zur Verbesserung des selbigen an GenyMotion deaktivieren.

Das GenyMotion Setup

Im Unterschied zu Android-x86 schaltet GenyMotion das mobile Netzwerk aus und aktiviert das virtuelle WLAN, welches das Netzwerkinterface von VirtualBox ist. Um die Proxy-Einstellungen zu konfigurieren, um einen Intercepting Proxy zu verwenden, befolgen Sie folgende einfachen Schritte:

  1. Gehen Sie zu den Wireless-Einstellungen (Settings → Wi-Fi)
  2. Klicken Sie lange auf das einzige vorhandene WLAN, mit dem sie verbunden sind (WiredSSID)
  3. Klicken Sie auf ändern und aktivieren Sie die Checkbox, die fortgeschrittene Optionen anbietet.
  4. Stellen Sie den Proxy auf manuell und füllen Sie die Felder aus.

Um mit adb zu verbinden sind keine weiteren Schritte notwendig. GenyMotion verbindet automatisch mit adb.

Zusammenfassung GenyMotion

GenyMotion ist eine solide Lösung zur Android-Emulation. Besonders interessant ist die Auswahl an virtuellen Geräten und Betriebssystemen. Wenn GenyMotion geschäftlich genutzt wird, dann ist eine Gebühr von 99 Euro pro User und Jahr fällig. Der Emulator ist schnell und responsiv. Das Interface erlaubt die Kontrolle von mehreren Hardware-Elementen ohne weitere Umschweife.

Der Android SDK-Emulator

Android SDK wird direkt mit einem Emulator ausgeliefert. Er ist Teil der Android SDK-Installation und es wird für jede neue Android-Version ein neues Emulator-Image geben. Mit der kommenden Version (Android L) inklusive stehen vier Systeme zum Download bereit.

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

* Normale Geräte wie Smartphone oder Tablet

Lab Setup Android SDK Emulator

Ein virtuelles Gerät wird mit AVD Manager erstellt. Das GUI erlaubt die Konfiguration von mehr als nur gerade dem Gerät und der verwendeten Android-Version, genau wie es GenyMotion tut.

Der AVD Manager

Nach der Erstellung eines virtuellen Geräts kann dieses direkt aus dem AVD Manager gestartet werden. Der Command Line Emulator, der sich im Verzeichnis PATH-TO-SDK\tools befindet, bietet viele Optionen, das Verhalten und die Ausführung der virtuellen Maschine zu beeinflussen. Zum Beispiel, wenn wir einen Intercepting Proxy nutzen wollen, dann ist die Option -http-proxy die Funktion, die einen Proxyserver für das virtuelle mobile Netzwerk konfiguriert.

Folgender Befehl startet ein virtuelles gerät und schaltet auch gleich den Proxy ein.

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

Wenn der Proxy während des Aufstartens des virtuellen Geräts nicht erreichbar ist, dann wird dieser ignoriert.

Der Android SDK Emulator hat den Ruf, sehr langsam und schwerfällig zu sein. Aber keine Panik, mit einigen kleinen Anpassungen kann die Performance verbessert werden. Bei der Erstellung des virtuellen Geräts müssen einfach folgende Schritte beachtet werden:

  1. Nutzen Sie so viel RAM wie Sie können. Eine Warnung wird unter Windows auftauchen, die davon abrät, mehr als 768MB RAM zu verwenden, da sonst das Gerät nicht funktionieren kann. Ignorieren Sie diese Warnung wenn möglich.
  2. Aktivieren Sie die Checkbox Use Host GPU, die Hardware OpenGLES-Emulation aktiviert.
  3. Downloaden Sie das Paket Intel x86 Emulator Accelerator (HAXM installer) im Menü Extras des SDK Managers.

Zusammenfassung SDK Emulator

Auch wenn die Emulation von der GPU unterstützt wird, ist das virtuelle Gerät etwas langsamer als es mit den anderen Emulatoren ist. Ein Vorteil ist aber, dass die Images der neuen Version zum Release Date frei erhältlich sein werden.

Eins, zwei oder drei?

Welche der Option in diesem Artikel jetzt die allgemein gültig beste Option ist, kann in dieser Form nicht beantwortet werden. Denn sie hängt zu grossen Teilen davon ab, welche Anforderungen an das Lab gestellt werden. Jede der drei Optionen hat Vor- wie auch Nachteile. Die Nutzung des original SDK Emulators ist sicher hilfreich, wenn es darum geht, mit den neuesten Android-Versionen zu arbeiten und die Performanceprobleme keine allzu grosse Rolle spielen. Zudem ist der Emulator sicher keine schlechte Lösung, wenn Command Line Switches wie -http-proxy benötigt werden.

Die anderen beiden Lösungen folgen einem anderen Ansatz und sind einfacher miteinander zu vergleichen. Android-x86 ist eine gute Option, sollt die neueste Android-Version nicht zwingend nötig sein und wenn das virtuelle Gerät in einer flexibleren und anpassbaren Umgebung funktionieren muss. Die Lösung ist zudem gratis, genau wie der Android SDK Emulator.

GenyMotion ist ein geschlossenes Produkt. Es kommt mit einer eigenen Lösung zum Virtual Device Management, einer eigenen Shell, die alle nötigen Schritte für den Developer – oder auch den Penetration Tester – übernimmt, um sofort loslegen zu können. GenyMotion fühlt sich besser in der Handhabung an und das User Interface erlaubt das Tweaken von vielen Hardware-Optionen. Dies ist wahrscheinlich für Entwickler wichtig, aber könnte auch Application Testern zugutekommen.

Burp Proxy Certificate Installation

Nach der Produktwahl kommt der Moment, an dem die Developer Ihrer Zielapplikation hoffentlich SSL-verschlüsseltes HTTP verwenden. Um dem Rechnung zu tragen, kann ein Burp CA Zertifikat installiert werden.

Diese einfache Aufgabe kann ganz schnell ganz schwer werden, wenn Ihnen bewusst wird, dass der Burp Proxy entweder über HTTP oder via http://PROXY-IP:PROXY-PORT/cert eine Datei namens cacert.der exportiert, Android aber eine .crt-Datei erwartet.

Um Burps CA Zertifikat zu installieren, können Sie diese Schritte befolgen:

  1. Öffnen Sie Burp Proxy und gehen Sie zum Tab Proxy
  2. Im Proxy_-Tab, klicken Sie auf _Options
  3. Klicken Sie auf CA certificate… und wählen Sie den Radiobutton Certificate in DER format an.
  4. Starten Sie nach dem Export eine Command Line
  5. Pushen Sie das CA Zertifikat auf das virtuelle Gerät, indem sie adb push PATH-TO-CA-CERT.DER /mnt/sdcard/CA-CERT.CRT (beachten Sie die neue Dateiendung .crt)
  6. Auf dem virtuellen Gerät, gehen sie zu Settings → Security → Install from SD Card
  7. Wählen Sie den Speicherort der Datei und klicken Sie darauf. Das Zertifikat wird nun installiert.

Dieser Vorgang funktioniert für fast alle Setups. Die grosse Ausnahme ist der SDK-Emulator für Android 4.4.2. Der Menüeintrag Install from SD Card öffnet einen Dateibrowser – genau wie bei anderen Versionen – aber dieser zeigt nicht die emulierte interne SD-Karte an.

Um das Zertifikat auf Android 4.4.2. SDK emulierten Geräten zu installieren, folgen Sie den ersten vier Schritten, die oben genannt werden. Dann laden Sie die Datei auf einen – im Idealfall internen und lediglich zu Testzwecken genutzten – Webserver und laden Sie im Webbrowser des virtuellen Geräts die Datei. Android wird diese als Zertifikat erkennen und die Installation beginnen.

Dieser Prozess wäre wesentlich einfacher, wenn entweder Android nicht nur .crt-Dateien ausfiltern würde oder Burp Proxy die Definition des Dateinamens für den Zugriff mit dem Browser via http://PROXY-IP:PROXY-PORT/cert erlauben würde.

Automation via ADB

Die Android Debug Bridge bietet ein breites Spektrum an Funktionen und ein gutes wie auch wertvolles Tool. Und ungeachtet des Systems, auf dem Ihr Android Lab aufgebaut ist, Sie werden mit adb Ihre eigenen Scripts bauen können.

Installation

Die Installation einer Applikation verändert das System. Die Details dieser Veränderung können während einer Analyse von grossem Wert sein. Daher wäre ein Script, das folgende Befehle ausführt, passend:

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 enthält eine grosse Menge an Informationen, die aus dem regulären Betrieb stammen. Daher sind alle Einträge, die mit /proc beginnen zu vernachlässigen, damit ersichtlich ist, was sich wirklich verändert hat. Wenn Sie einen Befehl finden, der nur in /data läuft, dann stehen die Chancen gut, dass einige Veränderungen nicht in fs-change-install.log aufgeführt werden.

De-Installation einer Applikation

Wie auch bei einer Installation wird bei einer Deinstallation das Filesystem verändert. Und ebenso kann diese Veränderung von grossem Interesse sein, weswegen auch hier ein Script wie das Folgende zum Tragen kommen kann.

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

Weitere kleine Helfer

Es gibt eine Vielzahl von weiteren kleinen Tweaks, die das Arbeiten mit adb im Alltag wesentlich vereinfachen. Alles, was Sie dazu brauchen, sind die Tools, die mit dem SDK geliefert werden und Scripting Skills.

Daher konzentriert sich dieser letzte Teil des Artikels auf die Kenntnis der Tools, die vom SDK bereitgestellt werden, deren Nützlichkeit und Hilfestellung im Rahmen der Applikationsanalyse.

Android Device Monitor

Dieses ausserordentlich hilfreiche Tool befindet sich im Ordner PATH-TO-SDK/tools und heisst monitor.bat. Unter anderem informiert das Script über die aktuell laufenden virtuellen Geräte, die laufenden Pakete, Heap, Allocation Tracker, Dateiexplorer und eine rollende Ansicht des Logs des Geräts.

Hilfreiche Befehle

Die untenstehende Tabelle zeigt nützliche Befehle für Analysten auf, um mit adb einen guten, soliden und schnellen Start zu finden.

Beschreibung Befehl
Output einer Liste aller installierten Pakete, inclusive deren Pfad adb shell pm list packages -f
Ein Paket aus dem System ziehen adb pull -p PATH-TO-PACKAGE
Backup der Application Data. adb backup -f BACKUP-NAME PACKAGE
Beliebige Datei auf das Gerät pushen adb push FILENAME DESTINATION-PATH
Beliebig Datei vom System ziehen adb pull -p FILE-PATH
Emulator für spezifisches virtuelles Gerät starten .\explorer.exe -avd VIRTUAL-DEVICE-NAME
Bugreport generieren adb bugreport

Fazit

Es gibt mehrere Wege, ein rein physisches Android Lab mit virtuellen Geräten auszubauen – oder ein solches Lab von Grund auf aufzubauen. Es lohnt sich, einen Schritt zurückzutreten und die Anforderungen an die Testumgebung nüchtern und analytisch zu betrachten. Es gibt gute, kostenlose Möglichkeiten, aber es könnte sich sogar lohnen, in eine andere Plattform zu investieren. In fast jedem Fall dürfte es so sein, dass die Lizenzkosten tiefer sind, als die Kosten eines neuen physischen Gerätes. Zudem wird die neueste Android-Version stets als Image vorhanden sein, womit sich das Warten auf das Update erübrigt.

Die Tools, die das Android SDK bereitstellt, sind einen guten Augenschein wert. Die Command-Line-basierte Ausführung von adb bietet eine Vielzahl Möglichkeiten, damit ihre Nutzer eigene Tools bauen können, die genau auf den Prozess im Arbeitsalltag passen.

Über den Autor

Oliver Kunz

Oliver Kunz ist seit 2010 im Bereich der Informationssicherheit aktiv. Hauptsächlich setzt er sich mit Incident Response, Computerforensik und der Sicherheit von mobilen Geräten auseinander.

Links

Sie wollen die Sicherheit Ihrer Firewall prüfen?

Unsere Spezialisten kontaktieren Sie gern!

×
Active Directory-Zertifikatsdienste

Active Directory-Zertifikatsdienste

Eric Maurer

Konkrete Kritik an CVSS4

Konkrete Kritik an CVSS4

Marc Ruef

Das neue NIST Cybersecurity Framework

Das neue NIST Cybersecurity Framework

Tomaso Vasella

Angriffsmöglichkeiten gegen Generative AI

Angriffsmöglichkeiten gegen Generative AI

Andrea Hauser

Sie wollen mehr?

Weitere Artikel im Archiv

Sie brauchen Unterstützung bei einem solchen Projekt?

Unsere Spezialisten kontaktieren Sie gern!

Sie wollen mehr?

Weitere Artikel im Archiv