
Un framework basato su contenitori per abilitare l'integrazione di componenti mobili nelle piattaforme di formazione sulla sicurezza.
Dockerized Android è un framework basato su container che consente di eseguire un emulatore Android all'interno di Docker e controllarlo tramite browser. Questo progetto è stato sviluppato per fornire un punto di partenza per l'integrazione di componenti di sicurezza mobile nei Cyber Range, ma può essere utilizzato per qualsiasi scopo. Comunque, a scopi di sviluppo e test, il progetto suggerito è docker-android.
Come detto nella breve descrizione sopra, questo progetto è stato creato per fornire un punto di partenza per l'introduzione di componenti di sicurezza mobile nei Cyber Range. Per questo motivo, le funzionalità già sviluppate e quelle che verranno aggiunte in futuro aiuteranno l'utente a rendere più semplice impostare una simulazione realistica (ad esempio per la formazione sulla sicurezza). Questa README è piuttosto lunga, forse vuoi saltare direttamente alla parte "Come eseguire".
Le seguenti funzionalità sono attualmente disponibili:
| Configurazione iniziale | Configurazione Instance Manager | Configurazione manuale |
|---|---|---|
| initial-setup | instance-manager-setup | manual-setup |
| Funzionalità della toolbox | Cambio istanza |
|---|---|
| toolbox | instance-switch |
Il progetto è composto da tre parti principali:
Il componente Core è quello che esegue tutti i processi necessari per far funzionare un componente Android (Emulato o Reale) all'interno di un container Docker, esponendo anche alcune funzionalità all'esterno. È senza dubbio la parte più complessa perché deve gestire diversi processi per fornire un insieme di funzionalità. La figura sopra mostra una chiara distinzione tra processi long-lived, processi start e script utilità. Inoltre, questa figura mostra che ci sono 6 processi long-lived, questa è una piccola inesattezza aggiunta per fornire una panoramica generale del componente Core; in realtà ci sono due diverse varianti del componente Core:
La principale differenza architetturale riguarda i processi long-lived: il Core per Emulatore esegue il processo long-lived emulator mentre il Core per Dispositivo Reale esegue il processo long-lived scrcpy per visualizzare e controllare il dispositivo fisico. Le altre parti sono abbastanza simili con solo un po' di logica per seguire un comportamento diverso in base al tipo di componente Core.
Il componente UI fornisce un modo semplice per utilizzare tutte le funzionalità esposte dal backend e aggiunge anche la capacità di visualizzare e controllare il dispositivo. L'utente deve inserire manualmente l'indirizzo del componente Core e le porte corrispondenti (la porta esposta dal backend e la porta esposta da websockify); attraverso questa configurazione manuale è possibile cambiare le porte predefinite (che sono 4242 per il backend e 6080 per websockify).
Il componente Instance Manager ha il compito di fornire tutte le informazioni (cioè indirizzi e porte) sui Core in esecuzione attraverso una singola API REST. Questo viene fatto scrivendo un semplice file di configurazione JSON che contiene tutte le informazioni sui Core presenti nel docker-compose per evitare il noioso lavoro di aggiungerli manualmente uno per uno. La struttura del file di configurazione JSON è la seguente:
{
"instances": [
{
"name": [Generic string to identify the device],
"address": [Address of the component],
"core_port": [Port of the backend],
"vnc_port": [Port of VNC]
}
]
}