This evaluation examines Dockerized Android’s strengths and limits: emulators support automated ADB features (SMS injection, GPS emulation, container IPs) but miss hardware like Bluetooth, forcing real-device tests for vectors like BlueBorne. The paper reproduces attacks (CVE-2018-7661 PoC and BlueBorne kill-chains), highlights cross-platform compatibility issues (WSL nested virtualization, macOS USB sharing), and maps which platform requirements are fully/partially met.This evaluation examines Dockerized Android’s strengths and limits: emulators support automated ADB features (SMS injection, GPS emulation, container IPs) but miss hardware like Bluetooth, forcing real-device tests for vectors like BlueBorne. The paper reproduces attacks (CVE-2018-7661 PoC and BlueBorne kill-chains), highlights cross-platform compatibility issues (WSL nested virtualization, macOS USB sharing), and maps which platform requirements are fully/partially met.

How Dockerized Android Performs Across Different Operating Systems

2025/10/16 06:00

:::info 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).

:::

Abstract and I. Introduction

II. Related Work

III. Dockerized Android: Design

IV. Dockerized Android Architecture

V. Evaluation

VI. Conclusion and Future Developments, and References

V. EVALUATION

This section assesses the Dockerized Android platform by examining several aspects. Firstly, we emphasize the differences between the Core for Emulator and Core for Real Device components in terms of features and highlight compatibility with the three most used Operating Systems. Then, we provide practical usage examples of Dockerized Android and discuss coverage of the requirements defined in Section III.

\ Fig. 3. UI Dockerized Android

\ A. Differences between Core for Emulator and Core for Real Device

\ Even if a significant effort has been put into creating a system that has the same features for both kinds of devices, there are limitations when emulation is used:

\ • SMS ADB send/reception feature: in emulated devices, it is possible to automate the send and reception of SMS messages through the ADB software. Obviously, this is not natively possible for real devices. Therefore, the user must manually send and receive SMS messages to implement SMS attack scenarios. A solution to address this problem could be the realization of a custom Android application that could be installed on a real device and could be instrumented to send and receive messages automatically.

\ • Networking: networking is quite different between the Emulator and the Real device flavors. In the emulator version, the AVD is created inside the Docker container, and therefore it shares the container’s IP address. Instead, the real device is physically connected to the machine that runs the container and keeps its own IP address.

\ • Hardware virtualization: for the hardware components, the situation is quite different, too: some hardware devices like the GPS and the microphone can be emulated. In particular, the GPS location of the device can be set through ADB, and the microphone of the host machine can be shared with the emulator. There are other hardware components that currently cannot be emulated, like, e.g. Bluetooth.

\ B. Host evaluation for cross-platform compatibility

\ The non-functional requirement NF04 (Cross-platform compatibility) states that the resulting system should be usable from within any host OS. This refers to the OS of the machine that runs the Docker containers. Table III provides a summary of the compatibility with Linux, Windows, and OS X.

\ TABLE IIIHOST OS COMPATIBILITY COMPARISON

\ The problem with Windows is that currently, the best way to use Docker is through the Windows Subsystem for Linux (WSL) framework. Unfortunately, WSL does not support nested virtualization yet, and this feature is required to run the Android emulator inside a Docker container. However, the feature will be available in upcoming WSL releases. It might be possible to run the Core for Emulator flavor on Windows by using a virtual machine, though losing all of the performance benefits associated with containerization. A similar issue does exist with OS X, with which there is currently no way to run the Core for Emulator. Besides, OS X does not allow sharing the USB device with a Docker container. For this reason, the only ways to use the Core for Real Device flavor are to either run ADB over Wi-Fi or connect to the host ADB from within the Docker container.

\ In the remainder of this section, we show the effectiveness of Dockerized Android in reproducing security kill chains by using both the Core for Emulator and Core for Real Device.

\ C. Security attack reproduction on the emulator

\ We herein focus on a sample vulnerability scenario associated with CVE-2018-7661[1]. This CVE is related to the free version of the application “Wi-Fi Baby Monitor”. This application has to be installed on two devices in order to act as a so-called baby monitor (a radio system used to remotely listen to sounds emitted by an infant). As reported in the National Vulnerability Database, “Wi-Fi Baby Monitor Free & Lite” before version 2.02.2 allows remote attackers to obtain audio data via certain specific requests to TCP port numbers 8258 and 8257”.

\ TABLE IVREQUIREMENTS FOR WI-FI BABY MONITOR

\ The premium version of this application offers users the ability to specify a password to use in the pairing process. By monitoring the network traffic, it is possible to observe that:

\ • the initial connection takes place on port 8257;

\ • the same sequence is always sent to start the pairing process;

\ • at the end of the pairing process, a new connection is started on port 8258. This port is used to transmit the audio data;

\ • after connecting to the port 8258, the other connection on the port 8257 is kept open and used as a heartbeat for the session;

\ • on the heartbeat connection, the client periodically sends the hexadecimal byte 0x01 (about once per second);

\ The proof of concept that allows the attacker to obtain audio data is given in [21]. This Proof of Concept (PoC) is easily reproducible on Dockerized Android through the realization of an infrastructure composed of three services:

\ • core-emulator: an instance of the Core component with a pre-installed Baby Monitor app acting as the sender;

\ • ui: the UI component to control what is going on;

\ • attacker: a customized version of Kali Linux that automatically installs all the dependencies needed for the execution of the PoC.

\ This is also a perfect example to show the Port Forwarding feature used to enable the communications.

\ D. Security attack reproduction on the real device

\ With the real device, we examine a further vulnerability, known as BlueBorne. The term “BlueBorne” refers to multiple security vulnerabilities related to the implementation of Bluetooth. These vulnerabilities were discovered by a group of researchers from Armis Security, an IoT security company, in September 2017. According to Armis, at the time of discovery, around 8.2 billion devices were potentially affected by the BlueBorne attack vector, which affects the Bluetooth implementations in Android, iOS, Microsoft, and Linux, hence impacting almost all Bluetooth device types such as smartphones, laptops, and smartwatches. BlueBorne was analyzed in detail in a paper published on the 12th of September 2017 by Ben Seri and Gregor Vishnepolsk [22]. Eight different vulnerabilities can be used as part of the attack vector.

\ Regarding Android, all devices and versions (therefore versions older than Android Oreo, which was released in December 2017) are affected by the above-mentioned vulnerabilities, except for devices that support BLE (Bluetooth Low Energy). In general, two requirements should be satisfied to exploit the vulnerability: (i) the target device must have Bluetooth enabled; (ii) the attacker must be close enough to the target device. As the Bluetooth feature is not available in the Core Emulator, the kill-chain in question can only be reproduced on real devices.

\ 1) BlueBorne full reproduction on Dockerized Android: In order to show the effectiveness of Dockerized Android, we developed a kill chain that exploits two Remote Code Execution (RCE) vulnerabilities that affect Android, i.e., CVE-2017- 0781 and CVE-2017-0782. These vulnerabilities fall within the Bluetooth set vulnerability’s set defined “BlueBorne” and discovered by a group of security researchers from Armis Security [23].

\ The diagram in Fig. 4 gives an overview of the developed kill chain:

\

  1. The attacker creates a phishing email through Gophish, a phishing generator software.

\ 2) The phishing email is sent to a victim’s mailbox.

\ 3) The victim reads the phishing email and erroneously clicks a malicious link contained in the email’s body.

\ 4) The malicious link allows the attacker to trigger an attack that downloads and installs a fake application on the victim’s mobile device.

\ 5) The malicious information sends relevant mobile information to the attacker. This information is required for the exploitation of the two vulnerabilities.

\ 6) The attacker crafts a malicious payload to exploit the vulnerabilities.

\ 7) The attacker sends the attack by exploiting the Bluetooth component’s vulnerabilities and has remote access to the victim’s device.

\ Fig. 4. Exploit Chain Overview

\ The complex scenario covers several threats defined in Table I. Table V shows such threats and both the platform functionalities and components that allow the scenario reproduction. The

\ TABLE VTHREATS, SCENARIO’S STEPS, FEATURES AND COMPONENTS

\ scenario requires complex network communications (F07) and involves the utilization of Bluetooth. For this reason, we have to use a physical device (F10). In the proposed scenario, we have to simulate the installation of the malicious application when the user receives the email. This can be done either manually (F02) or by implementing utility ADB scripts (F03). In order to reproduce the scenario, additional elements are needed:

\ • Gophish: a webapp that allows to craft and send phishing emails, for which a Docker version already exists.

\ • Ghidra: an application created by the National Security Agency (NSA) for reverse engineering purposes. In this context, it is used to get some useful information about the target device. This application is used on the host machine without Docker.

\ • Fake Spotify: a seemingly benign application that pretends to provide the user with a free version of the well-known Spotify Premium app, but rather sends to the attacker’s server exfiltrated files that are reverse-engineered on Ghidra. Also, this app was created without the usage of Docker.

\ Listing 1. docker-compose.yaml for the BlueBorne kill chain

\ It is composed of five services, two of which are the subcomponents of Dockerized Android. The remaining three are briefly described in the following:

\ • attacker_phishing: contains the Gophish component used to craft and send the phishing email that tricks the user into downloading the malicious Fake Spotify app;

\ • attackerwebserver: contains the webserver used to receive the files sent by the malicious app, which are reverse engineered in order to find information allowing the attacker to exploit the vulnerability on the target device;

\ • attacker_blueborne: the service used by the attacker to execute the attack on the target device and obtain a reverse shell on it.

\ E. Requirements coverage

\ In Table II we have illustrated the defined requirements for the realization of our platform. The following table contains all the requirements and their corresponding status:

\ TABLE VIREQUIREMENTS EVALUATION

\ Requirement F04, as detailed before, is set to Partial because of the inability to correctly configure all the hardware components (for example the Bluetooth device). Requirement F06 is set to partial because ADB gives the ability to record the screen out-of-the-box, but this feature was not exposed or made easier to use through the UI. Finally, requirements F07 (Network Configuration) and F09 (Third-Party Tools integration) are granted by default because of the usage of Docker. The network can be defined in any possible way through the docker-compose file, and third-party tools can be easily used together with this system.

\

:::info This paper is available on arxiv under CC by-SA 4.0 Deed (Attribution-Sahrealike 4.0 International license.

:::


[1] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-7661

Disclaimer: The articles reposted on this site are sourced from public platforms and are provided for informational purposes only. They do not necessarily reflect the views of MEXC. All rights remain with the original authors. If you believe any content infringes on third-party rights, please contact service@support.mexc.com for removal. MEXC makes no guarantees regarding the accuracy, completeness, or timeliness of the content and is not responsible for any actions taken based on the information provided. The content does not constitute financial, legal, or other professional advice, nor should it be considered a recommendation or endorsement by MEXC.
Share Insights

You May Also Like

Ethereum unveils roadmap focusing on scaling, interoperability, and security at Japan Dev Conference

Ethereum unveils roadmap focusing on scaling, interoperability, and security at Japan Dev Conference

The post Ethereum unveils roadmap focusing on scaling, interoperability, and security at Japan Dev Conference appeared on BitcoinEthereumNews.com. Key Takeaways Ethereum’s new roadmap was presented by Vitalik Buterin at the Japan Dev Conference. Short-term priorities include Layer 1 scaling and raising gas limits to enhance transaction throughput. Vitalik Buterin presented Ethereum’s development roadmap at the Japan Dev Conference today, outlining the blockchain platform’s priorities across multiple timeframes. The short-term goals focus on scaling solutions and increasing Layer 1 gas limits to improve transaction capacity. Mid-term objectives target enhanced cross-Layer 2 interoperability and faster network responsiveness to create a more seamless user experience across different scaling solutions. The long-term vision emphasizes building a secure, simple, quantum-resistant, and formally verified minimalist Ethereum network. This approach aims to future-proof the platform against emerging technological threats while maintaining its core functionality. The roadmap presentation comes as Ethereum continues to compete with other blockchain platforms for market share in the smart contract and decentralized application space. Source: https://cryptobriefing.com/ethereum-roadmap-scaling-interoperability-security-japan/
Share
BitcoinEthereumNews2025/09/18 00:25
Understanding Bitcoin Mining Through the Lens of Dutch Disease

Understanding Bitcoin Mining Through the Lens of Dutch Disease

There’s a paradox at the heart of modern economics: sometimes, discovering a valuable resource can make a country poorer. It sounds impossible — how can sudden wealth lead to economic decline? Yet this pattern has repeated across decades and continents, from the Netherlands’ natural gas boom in the 1960s to oil discoveries in numerous developing countries. Economists have a name for this phenomenon: Dutch Disease. Today, as Bitcoin Mining operations establish themselves in regions around the world, attracted by cheap resources. With electricity and favorable regulations, economists are asking an intriguing question: Does cryptocurrency mining share enough characteristics with traditional resource booms to trigger similar economic distortions? Or is this digital industry different enough to avoid the pitfalls that have plagued oil-rich and gas-rich nations? The Kazakhstan Case Study In 2021, Kazakhstan became a global Bitcoin mining hub after China’s cryptocurrency ban. Within months, mining operations consumed nearly 8% of the nation’s electricity. The initial windfall — investment, jobs, tax revenue — quickly turned to crisis. By early 2022, the country faced rolling blackouts, surging energy costs for manufacturers, and public protests. The government imposed strict mining limits, but damage to traditional industries was already done. This pattern has a name: Dutch Disease. Understanding Dutch Disease Dutch Disease describes how sudden resource wealth can paradoxically weaken an economy. The term comes from the Netherlands’ experience after discovering North Sea gas in 1959. Despite the windfall, the Dutch economy suffered as the booming gas sector drove up wages and currency values, making traditional manufacturing uncompetitive. The mechanisms were interconnected: Foreign buyers needed Dutch guilders to purchase gas, strengthening the currency and making Dutch exports expensive. The gas sector bid up wages, forcing manufacturers to raise pay while competing in global markets where they couldn’t pass those costs along. The most talented workers and infrastructure investment flowed to gas extraction rather than diverse economic activities. When gas prices eventually fell in the 1980s, the Netherlands found itself with a hollowed-out industrial base — wealthier in raw terms but economically weaker. The textile factories had closed. Manufacturing expertise had evaporated. The younger generation possessed skills in gas extraction but limited training in other industries. This pattern has repeated globally. Nigeria’s oil discovery devastated its agricultural sector. Venezuela’s resource wealth correlates with chronic economic instability. The phenomenon is so familiar that economists call it the “resource curse” — the observation that countries with abundant natural resources often perform worse economically than countries without them. Bitcoin mining creates similar dynamics. Mining operations are essentially warehouses of specialized computers solving mathematical puzzles to earn bitcoin rewards (currently worth over $200,000 per block) — the catch: massive electricity consumption. A single facility can consume as much power as a small city, creating economic pressures comparable to those of traditional resource booms. How Mining Crowds Out Other Industries Dutch Disease operates through four interconnected channels: Resource Competition: Mining operations consume massive amounts of electricity at preferential rates, leaving less capacity for factories, data centers, and residential users. In constrained power grids, this creates a zero-sum competition in which mining’s profitability directly undermines other industries. Textile manufacturers in El Salvador reported a 40% increase in electricity costs within a year of nearby mining operations — costs that made global competitiveness untenable. Price Inflation: Mining operators bidding aggressively for electricity, real estate, technical labor, and infrastructure drive up input costs across regional economies. Small and medium enterprises operating on thin margins are particularly vulnerable to these shocks. Talent Reallocation: High mining wages draw skilled electricians, engineers, and technicians from traditional sectors. Universities report declining enrollment in manufacturing engineering as students pivot toward cryptocurrency specializations — skills that may prove narrow if mining operations relocate or profitability collapses. Infrastructure Lock-In: Grid capacity, cooling systems, and telecommunications networks optimized for mining rather than diversified development make regions increasingly dependent on a single volatile industry. This specialization makes economic diversification progressively more difficult and expensive. Where Vulnerability Is Highest The risk of mining-induced Dutch Disease depends on several structural factors: Small, undiversified economies face the most significant risk. When mining represents 5–10% of GDP or electricity consumption, it can dominate economic outcomes. El Salvador’s embrace of Bitcoin and Central Asian republics with significant mining operations exemplify this concentration risk. Subsidized energy creates perverse incentives. When governments provide electricity at a loss, mining operations enjoy artificial profitability that attracts excessive investment, intensifying Dutch Disease dynamics. The disconnect between private returns and social costs ensures mining expands beyond economically efficient levels. Weak governance limits effective responses. Without robust monitoring, transparent pricing, or enforceable frameworks, governments struggle to course-correct even when distortions become apparent. Rapid, unplanned growth creates an immediate crisis. When operations scale faster than infrastructure can accommodate, the result is blackouts, equipment damage, and cascading economic disruptions. Why Bitcoin Mining Differs from Traditional Resource Curses Several distinctions suggest mining-induced distortions may be more manageable than historical resource curses: Operational Mobility: Unlike oil fields, mining facilities can relocate relatively quickly. When China banned mining in 2021, operators moved to Kazakhstan, the U.S., and elsewhere within months. This mobility creates different dynamics — governments have leverage through regulation and pricing, but also face competition. The threat of exit disciplines both miners and regulators, potentially yielding more efficient outcomes than traditional resource sectors, where geographic necessity reduces flexibility. No Currency Appreciation: Classical Dutch Disease devastated manufacturing due to currency appreciation. Bitcoin mining doesn’t trigger this mechanism — mining revenues are traded globally and typically converted offshore, avoiding the local currency effects that made Dutch products uncompetitive in the 1960s. Export-oriented manufacturing can remain price-competitive if direct resource competition and input costs are managed. Profitability Volatility: Mining economics are extraordinarily sensitive to Bitcoin prices, network difficulty, and energy costs. When Bitcoin fell from $65,000 to under $20,000 in 2022, many operations became unprofitable and shut down rapidly. This boom-bust cycle, while disruptive, prevents the permanent structural transformation characterizing oil-dependent economies. Resources get released back to the broader economy during busts. Repurposable Infrastructure: Mining facilities can be repurposed as regular data centers. Electrical infrastructure serves other industrial uses. Telecommunications upgrades benefit diverse businesses. Unlike exhausted oil fields requiring environmental cleanup, mining infrastructure can support cloud computing, AI research, or other digital economy activities — creating potential for positive spillovers. Managing the Risk: Three Approaches Bitcoin stakeholders and host regions should consider three strategies to capture benefits while mitigating Dutch Disease risks: Dynamic Energy Pricing: Moving from fixed, subsidized rates toward pricing that reflects actual resource scarcity and opportunity costs. Iceland and Nordic countries have implemented time-of-use pricing and interruptible contracts that allow mining during off-peak periods while preserving capacity for critical uses during demand surges. Transparent, rule-based pricing formulas that adjust for baseline generation costs, grid congestion during peak periods, and environmental externalities let mining flourish when economically appropriate while automatically constraining it during resource competition. The challenge is political — subsidized electricity often exists for good reasons, including supporting industrial development and helping low-income residents. But allowing below-cost electricity to attract mining operations that may harm more than help represents a false economy. Different jurisdictions are finding different balances: some embrace market-based pricing, others maintain subsidies while restricting mining access, and some ban mining outright. Concentration Limits: Formal constraints on mining’s share of regional electricity and economic activity can prevent dominance. Norway has experimented with caps limiting mining to specific percentages of regional power capacity. The logic is straightforward: if mining represents 10–15% of electricity use, it’s significant but doesn’t dominate. If it reaches 40–50%, Dutch Disease risks become severe. These caps create certainty for all stakeholders. Miners understand expansion parameters. Other industries know they won’t be entirely squeezed out. Grid operators can plan with more explicit constraints. The challenge lies in determining appropriate thresholds — too low forgoes legitimate opportunity, too high fails to prevent problems. Smaller, less diversified economies warrant more conservative limits than larger, more robust ones. Multi-Purpose Infrastructure: Rather than specializing exclusively in mining, strategic planning should ensure investments serve broader purposes. Grid expansion benefiting diverse industrial users, telecommunications targeting rural connectivity alongside mining needs, and workforce programs emphasizing transferable skills (data center operations, electrical systems management, cybersecurity) can treat mining as a bridge industry, justifying infrastructure that enables broader digital economy development. Singapore’s evolution from an oil-refining hub to a diversified financial and technology center provides a valuable template: leverage the initial high-value industry to build capabilities that support economic complexity, rather than becoming path-dependent on a single volatile sector. Some regions are applying this thinking to Bitcoin mining — asking what infrastructure serves mining today but could enable cloud computing, AI research, or other digital activities tomorrow. Conclusion The parallels between Bitcoin mining and Dutch Disease are significant: sudden, high-value activity that crowds out traditional industries through resource competition, price inflation, talent reallocation, and infrastructure specialization. Kazakhstan’s 2021–2022 experience demonstrates this pattern can unfold rapidly. Yet essential differences exist. Mining’s mobility, currency neutrality, profitability volatility, and repurposable infrastructure create policy opportunities unavailable to governments confronting traditional resource curses. The question isn’t whether mining causes economic distortion — in some contexts it clearly has — but whether stakeholders will act to channel this activity toward sustainable development. For the Bitcoin community, this means recognizing that long-term industry viability depends on avoiding the resource curse pattern. Regions devastated by boom-bust cycles will ultimately restrict or ban mining regardless of short-term benefits. Sustainable growth requires accepting pricing that reflects actual costs, respecting concentration limits, and contributing to infrastructure that serves broader economic purposes. For host regions, the challenge is capturing mining’s benefits without sacrificing economic diversity. History shows resource booms that seem profitable in the moment often weaken economies in the long run. The key is recognizing risks during the boom — when everything seems positive and there’s pressure to embrace the opportunity uncritically — rather than waiting until damage becomes undeniable. The next decade will determine whether Bitcoin mining becomes a cautionary tale of resource misallocation or a case study in integrating volatile, technology-intensive industries into developing economies without triggering historical pathologies. The outcome depends not on the technology itself, but on whether humans shaping investment and policy decisions learn from history’s repeated lessons about how sudden wealth can become an economic curse. References Canadian economy suffers from ‘Dutch disease’ | Correspondent Frank Kuin. https://frankkuin.com/en/2005/11/03/dutch-disease-canada/ Sovereign Wealth Funds — Angadh Nanjangud. https://angadh.com/sovereignwealthfunds Understanding Bitcoin Mining Through the Lens of Dutch Disease was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story
Share
Medium2025/11/05 13:53