cybersecsi/dockerized-androidUn framework basé sur des conteneurs pour permettre l'intégration de composants mobiles dans les plateformes de formation en sécurité.
Dockerized Android est un framework basé sur des conteneurs qui permet d'exécuter un émulateur Android dans Docker et de le contrôler via un navigateur. Ce projet a été développé pour fournir un point de départ pour intégrer des composants de sécurité mobile dans des Cyber Ranges, mais il peut être utilisé à n'importe quelle fin. Quoi qu'il en soit, pour les besoins de développement et de test, le projet suggéré est docker-android.
Comme indiqué dans la brève description ci-dessus, ce projet a été créé pour fournir un point de départ pour l'introduction de composants de sécurité mobile dans les Cyber Ranges. Pour cette raison, les fonctionnalités déjà développées et celles qui seront ajoutées à l'avenir aideront l'utilisateur à configurer plus facilement une simulation réaliste (par exemple pour la formation à la sécurité). Ce README est assez long, vous voudrez peut-être passer directement à la partie "How to run".
Les fonctionnalités suivantes sont actuellement disponibles :
| Configuration initiale | Configuration du gestionnaire d'instances | Configuration manuelle |
|---|---|---|
| initial-setup | instance-manager-setup | manual-setup |
| Fonctionnalités de la boîte à outils | Changement d'instance |
|---|---|
| toolbox | instance-switch |
Le projet est composé de trois éléments principaux :
Le composant Core est celui qui exécute tous les processus nécessaires au fonctionnement d'un composant Android (émulé ou réel) dans un conteneur Docker, tout en exposant certaines fonctionnalités à l'extérieur. C'est sans aucun doute la partie la plus complexe car elle doit gérer différents processus afin de fournir un ensemble de fonctionnalités. La figure ci-dessus montre une distinction claire entre les processus de longue durée, les processus de démarrage et les scripts utilitaires. De plus, cette figure montre qu'il y a 6 processus de longue durée, ce qui est une légère inexactitude ajoutée pour donner une vue d'ensemble du composant Core ; en réalité, il existe deux variantes différentes du composant Core :
La principale différence architecturale concerne les processus de longue durée : le Core pour émulateur exécute le processus de longue durée emulator tandis que le Core pour appareil réel exécute le processus de longue durée scrcpy pour afficher et contrôler l'appareil physique. Les autres parties sont assez similaires, avec seulement une logique différente pour suivre un comportement différent selon le type du composant Core.
Le composant UI fournit un moyen simple d'utiliser toutes les fonctionnalités exposées par le backend et ajoute également la possibilité d'afficher et de contrôler l'appareil. L'utilisateur doit insérer manuellement l'adresse du composant Core et les ports correspondants (le port exposé par le backend et le port exposé par websockify) ; grâce à cette configuration manuelle, il est possible de modifier les ports par défaut (qui sont 4242 pour le backend et 6080 pour websockify).
Le composant Instance Manager a pour tâche de fournir toutes les informations (c'est-à-dire les adresses et les ports) sur les Cores en cours d'exécution via une seule API REST. Cela se fait en écrivant un simple fichier de configuration JSON qui contient toutes les informations sur les Cores présents dans le docker-compose afin d'éviter le travail pénible de les ajouter un par un manuellement. La structure du fichier de configuration JSON est la suivante :
{
"instances": [
{
"name": [Chaîne générique pour identifier l'appareil],
"address": [Adresse du composant],
"core_port": [Port du backend],
"vnc_port": [Port VNC]
}
]
}