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 III. DOCKERIZED ANDROID: DESIGN Nowadays, it is imperative to integrate mobile systems into a Cyber Range due to the rising importance and ubiquitous usage of this kind of device. In [8] the difficulty of virtualizing mobile systems is highlighted as the main problem associated with this kind of integration. The main purpose of our work is actually the implementation of a framework that allows the integration of a mobile system in a container-based environment. We have focused our efforts on Android for several reasons: • it is open-source, so it is possible to easily reproduce the target environment; • it runs on nearly every device; • there are many external tools that can easily be integrated to provide enhanced features. A further reason for focusing on Android is related to compatibility issues. In the implemented system, the Android Emulator is used, and it is both open source and compatible with all host operating systems (Linux, Windows, and OS X). The iOS Simulator, on the other hand, is a closed platform that can only run on OS X, thus making it impossible to test and work on without a machine running OS X. We have opted for a container-based solution to take advantage of the associated performance improvements [4], as well as for the ever-increasing usage of this kind of virtualization over the traditional virtual machine approach in current applications. In particular, the resulting implementation should allow to: • run an Android virtualized device; • integrate a physical device; • control this device through a web browser; • control this device through the ADB (Android Debug Bridge) tool; • configure the main virtualized components; • install applications; • collect data; • define networking info; • configure usage options; • integrate other tools. We formalize these requirements as ten functional (F) requirements and five non-functional NF requirements. [F01] - Android virtual device execution. The resulting system has to allow the execution of an Android virtualized device in a container-based environment. Before the execution, the user should also be able to select a few significant options (like, e.g., the specific Android OS version). [F01] - Android virtual device execution. [F02] - Web browser device management. The user has to be able to access the device through a web browser using an ad hoc front-end. This front-end has to provide all the features through a clean and simple UI (i.e., the device has to be usable through such a UI). [F02] - Web browser device management. [F03] - ADB device management The user has to be able to access the device through the Android Debug Bridge either directly from the above-mentioned front-end UI or by accessing the container of the device itself. [F03] - ADB device management [F04] - Virtualized components configuration. The resulting system has to allow the user to configure all of the virtualized components of the emulated system. As an example, the user should be able to configure the GPS location of the device or use its SMS features. For obvious reasons, some hardware components cannot be fully virtualized. For example, the Android Emulator virtualizes the camera, but it is nearly impossible to use it in an attack chain. Some other components, like the microphone, could be virtualized and used in a simulated attack chain. A proper distinction is provided in Section V. [F04] - Virtualized components configuration. Android Emulator [F05] - Application management. The resulting system has to allow the user to manage the applications on the device. Namely, the user has to be able to install applications from files, as well as to install applications even from the Play Store (this last feature requires a Google Account, and for this reason, it is not mandatory). [F05] - Application management. [F06] - Data collection. The resulting system has to allow the user to collect data and record the sessions of the platform. This feature is particularly useful for cyber-range administrators interested in reviewing the actions performed by the users. [F06] - Data collection. [F07] - Networking configuration. The resulting system has to allow the user to configure the network before executing the container. For example, the user has to be able to configure the IP addresses of the devices. Another advanced feature is the ability to expose specific ports of the virtualized device, which are used to interact with specific device services. [F07] - Networking configuration. [F08] - Features configuration. All of the features described in the previous requirements must be configurable, meaning that before the execution of the container, the user can set some options or even decide the activation of a particular feature to customize the environment entirely. [F08] - Features configuration. [F09] - Third-party tools integration. The platform has to allow third-party tools integration with minimum effort, meaning that it should expose the proper interfaces in order to communicate with a third-party container that can be used as a tool. For example, the Mobile Security Framework (MobSF) [16] could be integrated and used in a particular configuration that allows the user to test the security of an app using the virtualized system. [F09] - Third-party tools integration. [F10] - Physical device integration. The system has to be able to integrate an Android physical device fully. Even when a physical device is connected, all of the features described previously must be usable in the same way. [F10] - Physical device integration. [NF01] - Management UI scalability. The front-end UI described in the requirement F02 has to be adaptive, meaning that it can be used with different screen resolutions. [NF01] - Management UI scalability. [NF02] - Image size shrinking. The resulting system (that could be either a single Docker image or multiple ones) has to be developed by trying to reduce as much as possible the dimensions of the resulting image to save space on the device that actually runs the system. In order to optimize the environment, we followed all the best practices suggested by the Docker Community [17] to keep the container’s size as low as possible. [NF02] - Image size shrinking. [NF03] - Separation of concerns. The Docker Community switched to the ’single concern’ principle [17], meaning that a single Docker image can run multiple processes if related to the same concern. The framework should keep this principle in mind when implementing its own images. [NF03] - Separation of concerns. [NF04] - Host cross-platform compatibility. The platform must be usable on different operating systems (i.e., Linux, macOS, Windows). [NF04] - Host cross-platform compatibility. [NF05] - Device type transparency. The resulting system has to also allow for the execution of a physical Android device transparently. The physical device should get connected via either a wired or a wireless communication channel. [NF05] - Device type transparency. Table II summarizes the above features; it is also used as a reference model in section V: 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.

Range

Google

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

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Building Smarter Cyber Ranges with Dockerized Android

Emulating Android Devices Securely in Containerized Cyber Ranges

Dockerized Android Architecture

How Dockerized Android Performs Across Different Operating Systems

Building Smarter Cyber Ranges with Dockerized Android

What is Cyber Range Training and Simulation in the Cloud?

Building Smarter Cyber Ranges with Dockerized Android

Emulating Android Devices Securely in Containerized Cyber Ranges

Dockerized Android Architecture

How Dockerized Android Performs Across Different Operating Systems

Building Smarter Cyber Ranges with Dockerized Android

What is Cyber Range Training and Simulation in the Cloud?

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps