Authors:
(1) Daniele Capone, SecSI srl, Napoli, Italy (daniele.capone@secsi.io);
(2) Francesco Caturano, Dept. of Electrical Engineering and Information, Technology University of Napoli Federico II, Napoli, Italy (francesco.caturano@unina.i)
(3) Angelo Delicato, SecSI srl, Napoli, Italy (angelo.delicato@secsi.io);
(4) Gaetano Perrone, Dept. of Electrical Engineering and Information Technology, University of Napoli Federico II, Napoli, Italy (gaetano.perrone@unina.it)
(5) Simon Pietro Romano, Dept. of Electrical Engineering and Information Technology, University of Napoli Federico II, Napoli, Italy (spromano@unina.it). Authors: Authors: (1) Daniele Capone, SecSI srl, Napoli, Italy (daniele.capone@secsi.io); SecSI srl (2) Francesco Caturano, Dept. of Electrical Engineering and Information, Technology University of Napoli Federico II, Napoli, Italy (francesco.caturano@unina.i) Dept. of Electrical Engineering and Information, Technology University of Napoli Federico II (3) Angelo Delicato, SecSI srl, Napoli, Italy (angelo.delicato@secsi.io); SecSI srl, (4) Gaetano Perrone, Dept. of Electrical Engineering and Information Technology, University of Napoli Federico II, Napoli, Italy (gaetano.perrone@unina.it) Dept. of Electrical Engineering and Information Technology, University of Napoli Federico II, Napoli, Italy (5) Simon Pietro Romano, Dept. of Electrical Engineering and Information Technology, University of Napoli Federico II, Napoli, Italy (spromano@unina.it). Dept. of Electrical Engineering and Information Technology, University of Napoli Federico II Table of Links Abstract and I. Introduction Abstract and I. Introduction II. Related Work II. Related Work III. Dockerized Android: Design III. Dockerized Android: Design IV. Dockerized Android Architecture IV. Dockerized Android Architecture V. Evaluation V. Evaluation VI. Conclusion and Future Developments, and References VI. Conclusion and Future Developments, and References IV. DOCKERIZED ANDROID ARCHITECTURE This section shows the architecture of Dockerized Android. Fig. 1 provides a high-level view of the Dockerized Android platform that allows identifying the key components it comprises: • Android Mobile Component: is the Android system accessible from the other components. It can be indifferently an emulated device or a real one connected to the machine hosting the container (through a cable or wireless). This component has to provide all of the features related to the Android OS itself, but also the hardware components that can be simulated (like the GPS or the microphone through the integration of an external device); • Android Mobile Component • adb: is the well-known Android Debug Bridge allowing to control an Android system (either an emulated one or a real one) through a command-line interface. This component allows having a shell on the device, configure options, install applications, etc. It has to be externally accessible to provide a higher level of configuration and increase the end-user experience as well; adb • Screen Sharing: the goal of this component is to provide a server that can be used by another component in order to give the user a simpler way to access and control the mobile device; • Screen Sharing: • Custom API: as several features are integrated into the system, this component provides access to the external tools with a uniform interface that hides the underlying cumbersome integration mechanisms; • Custom API: • Management UI: is the application front-end that can be accessed by the user to control the mobile device and enable the other features provided by the platform; The UI uses the VNC (Virtual Network Computing) component to let the user control the device through a web browser, the abd component to provide a shell to interact with the device in a more advanced way, and the Custom API to provide access to other features effortless; • Management UI • Extra Tools: this component encloses the external tools used to add further features to the platform. • Extra Tools: Fig. 2 shows a in-depth view of the modules implemented in the framework: The architecture can be divided into two parts: • Core: executes all the processes needed to run an Android Component (Emulated or Real) inside a Docker container, also exposing some features to the outside. Core • UI: gives the user a UI to access the Core component in a simpler way through a web browser. UI The Core component is composed of several modules that execute “long-lived processes” (i.e., processes that offer several functionalities along with all the Dockerized Android execution), “start processes” (i.e., processes executed during the framework’s bootstrap phase), and “utility scripts”. The internal modules implement several features: • xvdb, srcpy, and x11vnc modules simulate a real display and synchronize the device’s monitor with a virtual X server in the host system (i.e., the computer system that executes Dockerized Android). • xvdb, srcpy, and x11vnc • The websockify module converts the VNC communication protocol used by x11vnc to Web Socket network protocol; in this way, it is possible to view the mobile’s screen through a Web browser. websockify module • The emulator component manages the Android Virtual Device that emulates the mobile device when an emulated device is used. emulator component • The backend module written in Node.js implements an extendible interface that allows adding cyber-range focused features, such as the dispatch of a malicious SMS or e-mail to simulate phishing attacks. backend module • The adb-utils module implements several utility scripts that use the ADB tool for implementing other functionality, such as the installation of vulnerable Android applications or instruments the mobile device with mobile security toolkits, such as Frida [19]. adb-utils • The rinetd-forward module manages the emulator’s port forwarding by enabling the network communication between all the components. rinetd-forward The UI component is composed of a React Frontend and is served through an NGINX server. The UI is developed using the most recent features provided by the React framework, like Hooks and Context, in order to follow the principle of strong cohesion and loose coupling. The UI provides a simple way to use all the features exposed by the backend and also adds the ability to display and control the device. The user has to manually insert the address of the Core component and the corresponding ports (the port exposed by the backend and the port exposed by websockify. Fig. 3 shows the most interesting Dockerized Android user interface view. The implementation of the above-mentioned architecture is publicly accessible on GitHub [20]. This paper is available on arxiv under CC by-SA 4.0 Deed (Attribution-Sahrealike 4.0 International license. This paper is available on arxiv under CC by-SA 4.0 Deed (Attribution-Sahrealike 4.0 International license. available on arxiv

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

GitHub

How Dockerized Android Performs Across Different Operating Systems

How to Run Android in Docker: Design, Integration, and Performance Benefits

Read My Stories

Too Long; Didn't Read

Download free Tech Leaders Productivity Report!

Dockerized Android Architecture

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Emulating Android Devices Securely in Containerized Cyber Ranges

Emulating Android Devices Securely in Containerized Cyber Ranges

How to Run Android in Docker: Design, Integration, and Performance Benefits

How Dockerized Android Performs Across Different Operating Systems

What is Cyber Range Training and Simulation in the Cloud?

Emulating Android Devices Securely in Containerized Cyber Ranges

Emulating Android Devices Securely in Containerized Cyber Ranges

How to Run Android in Docker: Design, Integration, and Performance Benefits

How Dockerized Android Performs Across Different Operating Systems

What is Cyber Range Training and Simulation in the Cloud?

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps