cybersecsi/dockerized-androidEin containerbasiertes Framework zur Ermöglichung der Integration mobiler Komponenten in Sicherheitsschulungsplattformen
Dockerized Android ist ein containerbasiertes Framework, das es ermöglicht, einen Android-Emulator in Docker auszuführen und über einen Browser zu steuern. Dieses Projekt wurde entwickelt, um einen Ausgangspunkt für die Integration mobiler Sicherheitskomponenten in Cyber Ranges zu bieten, kann aber für jeden Zweck verwendet werden. Für Entwicklungs- und Testzwecke wird jedoch das Projekt docker-android empfohlen.
Wie in der kurzen Beschreibung oben erwähnt, wurde dieses Projekt erstellt, um einen Ausgangspunkt für die Einführung mobiler Sicherheitskomponenten in Cyber Ranges zu bieten. Aus diesem Grund helfen die bereits entwickelten Funktionen sowie die zukünftig hinzugefügten Funktionen dem Benutzer, eine realistische Simulation (z. B. für Sicherheitstrainings) einfacher einzurichten. Diese README ist ziemlich lang, vielleicht möchten Sie direkt zum Teil „So wird's ausgeführt“ springen.
Derzeit sind folgende Funktionen verfügbar:
| Ersteinrichtung | Instance Manager Einrichtung | Manuelle Einrichtung |
|---|---|---|
| initial-setup | instance-manager-setup | manual-setup |
| Toolbox-Funktionen | Instanzwechsel |
|---|---|
| toolbox | instance-switch |
Das Projekt besteht aus drei Hauptkomponenten:
Die Core-Komponente führt alle Prozesse aus, die zum Betreiben einer Android-Komponente (emuliert oder real) innerhalb eines Docker-Containers erforderlich sind, und stellt einige Funktionen nach außen zur Verfügung. Sie ist zweifellos der komplexeste Teil, da sie verschiedene Prozesse verwalten muss, um eine Reihe von Funktionen bereitzustellen. Die obige Abbildung zeigt eine klare Unterscheidung zwischen langlebigen Prozessen, Startprozessen und Hilfsskripten. Außerdem zeigt die Abbildung, dass es 6 langlebige Prozesse gibt – dies ist eine kleine Ungenauigkeit, die hinzugefügt wurde, um einen allgemeinen Überblick über die Core-Komponente zu geben. In Wirklichkeit gibt es zwei unterschiedliche Varianten der Core-Komponente:
Der Hauptarchitekturunterschied betrifft die langlebigen Prozesse: Der Core für Emulator führt den langlebigen Emulator-Prozess aus, während der Core für echtes Gerät den langlebigen scrcpy-Prozess ausführt, um das physische Gerät anzuzeigen und zu steuern. Die anderen Teile sind recht ähnlich, lediglich mit etwas Logik, um je nach Art der Core-Komponente ein anderes Verhalten zu ermöglichen.
Die UI-Komponente bietet eine einfache Möglichkeit, alle vom Backend bereitgestellten Funktionen zu nutzen und ermöglicht zudem die Anzeige und Steuerung des Geräts. Der Benutzer muss manuell die Adresse der Core-Komponente sowie die entsprechenden Ports eingeben (den vom Backend bereitgestellten Port und den von websockify bereitgestellten Port); durch diese manuelle Einrichtung können die Standardports (4242 für das Backend und 6080 für websockify) geändert werden.
Die Instance Manager-Komponente hat die Aufgabe, alle Informationen (d. h. Adressen und Ports) über die laufenden Cores über eine einzige REST-API bereitzustellen. Dies geschieht durch das Schreiben einer einfachen JSON-Konfigurationsdatei, die alle Informationen über die Cores enthält, die in der docker-compose vorhanden sind, um die mühsame manuelle Eingabe zu vermeiden. Die Struktur der JSON-Konfigurationsdatei ist wie folgt:
{
"instances": [
{
"name": [Generischer String zur Identifizierung des Geräts],
"address": [Adresse der Komponente],
"core_port": [Port des Backends],
"vnc_port": [Port von VNC]
}
]
}