arXiv CSopen access

Firmware Distribution as Attack Surface: A Security Study of ASIC Cryptocurrency Miners

Firmware Distribution as Attack Surface: A Security Study of ASIC Cryptocurrency Miners Pierre Pouliquen∗† , Hadrien Barral‡ , David Naccache∗ , Thibaut Heckmann† , Antoine Houssais† ∗ DI ENS, École normale supérieure, PSL, CNRS, 75005 Paris, France

[email protected] † Laboratoire de Recherche et d’Innovation, Gendarmerie Nationale, Chaire HUNUM, 77000 Melun, France

arXiv:2605.03770v1 [cs.CR] 5 May 2026

[email protected] ‡ Univ Gustave Eiffel, CNRS, LIGM, 77454 Marne-la-Vallée, France [email protected]

Abstract—ASIC cryptocurrency miners are a core component of blockchain infrastructures, directly converting computation and energy into monetary value. Despite their economic importance, their security is rarely evaluated in a structured manner. In this paper, we show that the firmware distribution ecosystem of mining devices fundamentally challenges existing trust assumptions. We introduce a scalable methodology based on the collection and static analysis of publicly distributed firmware artifacts, requiring neither device access nor runtime interaction. Applying this approach, we reconstruct and analyze 134 firmware images spanning manufacturers that account for over 99% of deployed miners (Bitmain, MicroBT, Canaan, Iceriver). Our results reveal that firmware artifacts alone are sufficient to recover internal architecture, identify security weaknesses, and reconstruct complete attack paths leading to high-impact adversarial objectives. In particular, our analysis reveals vulnerabilities that enable realistic large-scale attack scenarios, including firmware phishing and the exploitation of miners still operating over Stratum V1. Validation on two real devices confirms that publicly distributed artifacts closely reflect deployed software and that these weaknesses translate into attack capabilities. Overall, our study shows that firmware distribution mechanisms themselves constitute a primary attack surface, significantly lowering the barrier to compromise in the ASIC mining ecosystem.

I. I NTRODUCTION Cryptocurrencies are decentralized digital monetary systems in which transactions are recorded on a public blockchain and validated collectively by network participants rather than by a trusted central authority. Since the introduction of Bitcoin, these systems have evolved from a niche technological proposal into a large-scale financial and computational ecosystem. This sustained relevance is reflected both in the scientific literature and in economic indicators. A recent bibliometric analysis identifies more than 41 000 scientific publications related to blockchain technologies between 2008 and 2023, with over 60% of them published during the 2021–2023 period, indicating a persistent and growing research interest in cryptocurrencies and their underlying infrastructures [1], [2]. In parallel, the total market capitalization of all cryptocurrencies reached approximately $3 trillion USD in March/April 2024, with the largest asset (Bitcoin) alone accounting for roughly $1.7–$1.8 trillion USD at that time, underscoring the continued economic significance of this asset class [3]. Modern cryptocurrency miners are no longer general purpose computers

but networked embedded systems operated continuously in production environments and managed remotely at scale. Their firmware governs parameters that directly influence revenue, such as mining pool configuration, payout addresses, and operating frequency, as well as those related to safe operation, including power delivery and thermal management. Firmware correctness and integrity therefore directly affect both economic outcomes and operational stability. In parallel, the Application-Specific Integrated Circuit (ASIC) mining hardware market is dominated by a small number of manufacturers [4], whose design choices and firmware update mechanisms are deployed across a large fraction of the global hashrate. This strong vendor concentration implies that weaknesses in miner firmware do not remain confined to individual devices but can propagate in the ecosystem, affecting entire blockchain networks. Consequently, the security of cryptocurrencies now depends not only on cryptographic protocols, but also on the robustness of the firmware running on a limited set of mining platforms [5]. A. Our contribution We analyze the ASIC mining ecosystem by combining a market study of the dominant manufacturers with a security analysis of their products. Our approach relies on a reproducible methodology based on the systematic collection and static analysis of publicly distributed update firmware artifacts. Applied at scale, this method enables the recovery of detailed architectural and security relevant information without physical access to devices or dynamic interaction. Using this approach, we identify major vulnerabilities affecting realworld miners and show that firmware update packages alone expose a substantial attack surface and a large amount of sensitive operational information, significantly lowering the cost of attacks since it is not necessary to own the miner to know its vulnerabilities. B. Paper organization We begin by introducing the cryptocurrency mining ecosystem and its security implications (Section II). We then describe the firmware architecture and its main attack surfaces, with

a focus on the update workflow as a central trust boundary (Section III, Section IV). Next, we formalize an attacker model (Section V) and present its operational realization as an attack pipeline from access to impact (Section VI). We then introduce our large-scale firmware analysis methodology (Section VII), show the information that can be extracted (Section VIII), and derive realistic attack scenarios (Section IX). Finally, we validate our findings (Section X), discuss mitigations (Section XI), and conclude (Section XIII).

In these systems, ownership of funds is defined by cryptographic keys, and transactions are broadcast to a peer-to-peer network before being incorporated into blocks through collective validation. Miners emerged as a direct consequence of this design, assembling transactions into blocks and competing to solve proof-of-work challenges that are computationally costly to generate but easy to verify, thereby securing the ledger against adversarial manipulation. In practice, most miners do not operate independently but participate in mining pools, which coordinate the work of large numbers of devices. A pool assigns hashing jobs to connected miners, collects submitted shares as proof of contributed work, and distributes rewards proportionally. As a result, miners continuously maintain network connections to a small set of pool endpoints, making pool configuration parameters (such as pool addresses and payout identifiers) a central economic control surface. Early mining was performed on general-purpose Central Processing Unit (CPU)s, then on Graphics Processing Unit (GPU)s, and later on Field-Programmable Gate Array (FPGA)s. As competition intensified, mining evolved into a hardware arms race, leading to the development of Application-Specific Integrated Circuit (ASIC)s optimized exclusively for hash computation [20]. These machines exist solely to perform a cryptographic function at maximum efficiency. Modern cryptocurrency mining is therefore inseparable from specialized hardware and industrial deployment [4]. This evolution has produced a mining ecosystem that is decentralized at the protocol level but highly centralized at the hardware level. The global ASIC market is overwhelmingly dominated by a small number of manufacturers, primarily Bitmain (China) [21], MicroBT (China) [22], and Canaan (China) [23], which together supply more than 99% of deployed mining devices [4]. As a result, the security properties of cryptocurrencies now depend not only on cryptographic protocols, but also on the correctness, integrity, and update mechanisms of the firmware running on a limited set of mining platforms. Vulnerabilities at this layer can affect a significant fraction of the global hashrate and therefore constitute a systemic risk for the underlying blockchain networks.

C. Related work Prior work follows two largely independent directions: large-scale firmware analysis and cryptocurrency mining security. Firmware analysis has shown that publicly available images enable scalable vulnerability discovery without device access [6], later extended with dynamic and emulations techniques such as Firmadyne, Firm-AFL, and P2IM [7], [8], [9]. Surveys further systematize extraction methods and vulnerability classes in embedded firmware [10], [11]. In parallel, mining security research focuses on protocol and network-level attacks, including Stratum weaknesses, hashrate redirection, and routing attacks [12], [13], [14], [15], [16]. However, these directions remain disconnected: firmware studies are domain-agnostic, while mining security works do not consider firmware and update mechanisms. As summarized in Section B, no prior work combines cross-vendor firmware analysis with mining-specific attack modeling. Our work bridges this gap by linking firmware artifacts to concrete attacker capabilities and economic impact. II. W HAT IS CRYPTOCURRENCY AND WHY DO WE NEED MINING MACHINES ? Cryptocurrencies originate from early work on cryptographically enforced electronic cash. In 1983, in his seminal paper Blind Signatures for Untraceable Payments, Chaum introduced the first formal construction of a digital payment system based on cryptographic primitives, enabling privacy-preserving electronic transactions mediated by a trusted authority [17]. While these early proposals relied on centralized intermediaries, they established the foundational concepts of cryptographic money. Building on these ideas, Bitcoin, proposed by Nakamoto in 2008 [18], was the first system to maintain a consistent and antifraud transaction ledger in an open network without any trusted central authority. It combined public-key cryptography, hash functions, and a decentralized consensus mechanism based on proof-of-work, enabling mutually distrustful participants to agree on transaction validity. Subsequent systems such as Ethereum [19] generalized this model by introducing programmable smart contracts while initially retaining proof-of-work as a consensus mechanism. This further reinforced the economic role of mining infrastructures beyond simple transaction validation.

III. S OFTWARE ARCHITECTURE OF A CRYPTOCURRENCY MINER FIRMWARE

Figure 1 presents a functional architectural abstraction of a cryptocurrency miner firmware, designed to capture the organization of the software stack rather than provide an exhaustive description. After Boot and hardware initialization via Init, a lightweight embedded Operating System (OS) and its Libraries, most commonly Linux, are loaded and provide core services such as process management, networking, storage, and access to hardware drivers. The mining application (Miner) runs on top of this OS and implements the proof-of-work logic. It communicates with mining pools (Blockchain) using Stratum, the standard protocol through which miners receive work (hashing jobs) and submit computed shares. It then distributes work to the

2

Firmware architecture Boot

automatic update polling or enforced over-the-air patching. Updates are explicitly initiated through privileged management interfaces. Architecturally, this workflow corresponds to the Firmware Update component shown in Figure 1, which forms the trust boundary between the external management plane and internal system components (OS, Miner, and Libraries). Importantly, this same update path is also the primary observation point of our methodology. In practice, users download update packages from public vendor repositories, connect to the miner administration interface (embedded web interface or vendor management software), and upload the package for installation. Although these packages are often partial and do not constitute a complete system image, they remain sufficiently representative to expose the internal software structure, update logic, and trust boundaries of the device. A key property of this ecosystem is that these firmware packages are publicly accessible and can be collected at scale without requiring access to physical hardware. This enables offline analysis capable of recovering system architecture, identifying exposed services, and understanding securitycritical mechanisms, as these artifacts reflect the structural elements governing the deployed system. As a result, static analysis of these artifacts enables extensive offline reverse engineering, revealing operating system components, boot and update mechanisms, management services, authentication logic, and, in many cases, exploitable vulnerabilities. This asymmetry is exacerbated by the fact that firmware analysis is largely automated and low-cost, enabling attackers to prepare attacks at scale without facing network or operational constraints and without acquiring the hardware. This openness is not incidental but largely driven by economic constraints. Mining hardware profitability degrades rapidly over time, typically over weeks to months due to increasing network difficulty and hardware turnover, forcing operators to maximize short-term returns through overclocking and performance tuning [24]. This requirement encourages the use of modified or unofficial firmware. Vendors therefore expose or tolerate user control over performance parameters, which amplifies the security impact of weaknesses in update verification mechanisms.

Init

Physical components

OS

ASIC chips

Firmware Update

Libraries

Debug Port Physical or Software

Miner

WebServer

E.g. : SSH/UART

E.g. : HTTP.S API

E.g : Stratum

Blockchain

Control console

E.g. : TCP Socket

Supplier

User

Figure 1. Layered software architecture of a cryptocurrency mining firmware.

ASIC chips (Physical components) through OS control paths, collects results, and controls parameters including frequency, voltage, and thermal limits. In parallel, management components implement a management plane that either directly exposes a configuration API within the mining software, or relies on an HTML administrative interface provided by a WebServer, which forwards configuration commands to the mining process through internal control channels. These management interfaces are accessible to the operator either programmatically or through a browser, optionally via a Control console. The Firmware Update mechanism interacts with the operating system, the miner, and the web interface to define how software components can be replaced or modified over time, thereby shaping the update trust model and long-term security posture of the device. In addition, miners may expose a Debug port, either logically through remote access mechanisms such as SSH or physically through interfaces like Universal Asynchronous Receiver-Transmitter (UART), primarily intended for maintenance or vendor-side diagnostics. This architectural abstraction is sufficient to reason about miner behavior, control flows, update paths, and securityrelevant attack surfaces. The different elements are detailed in Section C in the appendix.

V. ATTACK OBJECTIVES AND ADVERSARIAL MODEL Cryptocurrency mining devices constitute high-value targets for adversaries because they operate continuously, expose network services by design, and directly convert computation and energy into monetary value [25]. Unlike most consumer IoT devices, whose compromise yields only indirect benefits, a miner produces a steady and measurable revenue stream as long as it remains operational. This economic asymmetry helps explain why illicit mining and cryptojacking have become persistent threat categories in the wild [26], [27], [28], [29], [11]. In this section, we focus on the objectives that an adversary may pursue once a mining device is compromised. Rather than describing how attacks are carried out, we characterize

IV. F IRMWARE UPDATE WORKFLOW AS A PRIMARY SECURITY ENTRY POINT

Cryptocurrency mining devices rely on a manual firmware update workflow under the direct control of the operator. Unlike consumer IoT ecosystems, miners do not implement

3

the impact of a compromise in terms of attacker goals and observable outcomes. This perspective allows us to reason about security at the level of consequences, independently of specific vulnerabilities or exploitation paths. Full device takeover and infrastructure abuse. An attacker may seek full control of the miner in order to repurpose it as a general-purpose networked system. Once compromised, miners can be integrated into botnets, used for DDoS attacks, or abused as proxy and relay nodes. This type of outcome is consistent with the broader history of embedded-device compromise, as illustrated by large-scale botnets such as Mirai and more recent Linux malware campaigns targeting networkconnected devices [30], [31]. In the mining ecosystem itself, prior reports and public disclosures have documented remote compromise, malicious code deployment, and persistent abuse of ASIC devices, making such scenarios realistic in practice [32], [33], [34], [35]. Cryptocurrency theft and revenue redirection. A central objective consists in diverting mining revenue without disrupting apparent device availability. This can be achieved by modifying wallet addresses, mining pool endpoints, or Stratum parameters, either locally through configuration tampering or firmware modification, or remotely via man-in-the-middle attacks on unauthenticated mining protocols. Prior work has shown that mining with Stratum V1 remains vulnerable to stealthy hashrate theft, share manipulation, and proxy redirection attacks [13], [12], [14], [15]. At the infrastructure level, routing manipulation can transparently redirect miners toward attacker pools without requiring local compromise [16], [36]. Similar behavior has also been observed in malware targeting mining software, where wallet addresses are replaced to redirect rewards [37]. These attacks are particularly effective because they preserve normal device operation while silently redirecting profits. Physical degradation and hardware damage. Beyond direct revenue theft, attackers may target the physical integrity and lifetime of mining hardware. By manipulating voltage, frequency, fan control, or thermal management parameters, an adversary can induce overheating, chronic instability, or accelerated component aging. This scenario is particularly relevant in mining environments because performance tuning and clock-rate adjustment are already central operational controls [24]. In addition, public reports on malware targeting ASIC devices indicate that hostile access to these parameters is not purely theoretical and may threaten device stability or safe operating conditions [38], [34]. Performance degradation and operational disruption. Finally, adversaries may seek to degrade mining performance without achieving persistent control. Network flooding, repeated service restarts, denial-of-service attacks, or resource exhaustion can significantly reduce hashrate and availability while remaining difficult to attribute. Such attacks have been observed in practice, notably through DDoS campaigns targeting mining pools and related infrastructure [39]. More generally, mining activity remains exposed to routing-level and network-level disruptions that can affect effective work

delivery and reward collection even without full compromise of the miner itself [16], [25]. VI. ATTACKER MODEL AND ATTACK PIPELINE This section provides an operational view of how the objectives described in Section V can be achieved in practice. We describe how an adversary progresses from initial access to concrete impact by interacting with the mining device through its exposed attack surface. Mining devices are typically deployed within private networks and are not directly exposed to the Internet. As a result, an attacker must first gain a foothold in the local environment in which miners operate. This initial access constitutes a necessary precondition for most realistic attacks. As illustrated in Figure 3, this can be achieved through several practical vectors, including network-level attacks (e.g., interception or manipulation of mining traffic), social engineering targeting operators (e.g., malicious firmware distribution), or compromise of adjacent infrastructure such as routers or management hosts. Once this foothold is obtained, the attacker can interact with the device through a limited set of entry points defined by its architecture (Section III), namely firmware update mechanisms, debug interfaces such as SSH, embedded management interfaces, and exposed APIs. These entry points define the effective attack surface available in practice. The attack can then be modeled as a progressive pipeline: Access → Entry point → Vulnerability → Capability → Objective Figure 2 summarizes the global relationships between entry points, vulnerabilities, capabilities, and final objectives. It highlights how each stage of the attack constrains the next, and how different attack paths may converge toward similar capabilities and outcomes. More precisely, entry points determine which vulnerabilities are reachable, vulnerabilities determine which functionalities can be accessed, and these functionalities translate into attacker capabilities such as firmware modification, configuration control, or access to physical parameters. These capabilities ultimately enable the objectives described in Section V. For completeness, the attacker workflow can also be represented as a temporal pipeline emphasizing execution steps rather than structural relationships. This alternative view is provided in Appendix 8. In practice, this attacker model allows us to reason from observed weaknesses in firmware artifacts to their security consequences. Rather than assessing vulnerabilities in isolation, we evaluate whether they can be composed along the attack pipeline to yield effective attacker capabilities and ultimately reach one of the objectives defined in Section V. In contrast to this attacker-centric view, our analysis pipeline adopts an analyst perspective, structuring the process from firmware collection to vulnerability identification and impact assessment. This complementary pipeline is presented in Appendix 9.

4

Entry point

Vulnerability / Functionality

No authentication Update Udpate

Low verification

Final goal

Critical overwrite Sensitive overwrite

1 Remote Code Execution

Full device takeover and infrastructure abuse.

Pool redirect Address replace

Cryptocurrency theft and revenue redirection.

Overclocking Fan control Component restart

Physical degradation and hardware damage

DoS Throttling

Performance degradation and operational disruption.

Weak/Default credentials SSH/Debug

Outdated openssl/crypto librairies Outdated kernel and unpatched component

No/Weak authentication

WebServer

Access to update

1

Access to wallet address Console

Clear communication

Access to physical properties

Make malicious requests indefinitely No/Weak authentication

Access to update

1

Access to wallet address

API API

Clear communication

Access to physical properties

Make malicious requests indefinitely

Figure 2. Structured view of the attack pipeline linking entry points, vulnerabilities, capabilities, and attacker objectives. This figure does not aim to exhaustively enumerate all possible paths, but rather to illustrate representative vulnerability chains in order to provide an intuitive understanding of how different attack scenarios can lead to concrete objectives.

Internet

LAN

sis remains representative of real-world systems while being conducted independently of operational environments. This enables reproducible comparisons across vendors, hardware generations, and firmware versions, and makes it possible to study the mining ecosystem at scale without depending on the availability of specific devices in a laboratory setting. Our approach introduces a shift in perspective by treating publicly available firmware artifacts not as auxiliary data, but as a central and sufficient source for reconstructing device architectures, identifying vulnerabilities, and deriving complete attack paths. Mining infrastructures provide a particularly relevant case study in this context, as firmware directly governs economically sensitive parameters, including pool endpoints, wallet identifiers, frequency, voltage, and cooling.

Miner Udpate

SSH/Debug

User Attacker

IHM Internet Gateway

Stratum

Router

Fonctionnality

API

Figure 3. Attacker perspective: gaining access to the miner network and positioning within the local environment through different compromise vectors.

VII. M ETHODOLOGY AND FIRMWARE CORPUS CONSTRUCTION

We aim to determine whether a device exposes the entry points, vulnerabilities, and capabilities required to reach concrete adversarial objectives. In contrast to the attacker-oriented viewpoint developed in Section VI, which describes how an adversary would progress from initial access to final impact, the methodology presented here adopts a global and systematic perspective. Rather than assuming a specific attack path, we enumerate devices, collect the corresponding artifacts, normalize the corpus, reconstruct analyzable firmware images, identify security-relevant weaknesses, and map them to the capabilities and objectives formalized in our attack model.

We present a methodology for the security analysis of cryptocurrency mining infrastructures that relies on the systematic examination of firmware artifacts publicly distributed by manufacturers. More precisely, we collect and analyze firmware update packages, full reflashing images, management tools, and associated technical documentation. Our approach relies exclusively on static analysis and does not require physical device acquisition, runtime interaction, or emulation. Because these artifacts correspond directly to software distributed for deployment on production devices, static analy-

5

Bitmain 123

MicroBT 65

Iceriver 22 Canaan 36

Figure 4. Distribution of commercially available ASIC miners models per manufacturer, derived from aggregated public mining ecosystem platforms.

Figure 5. An excerpt from the website https://download.canaan-creative.com/

versions made available through official vendor portals, even when the frontend interface only exposes a subset of files. Second, when vendors distribute firmware or tooling through public version control repositories, we directly clone the corresponding repositories in their entirety. This approach preserves full version history, metadata and directory structure, and allows us to capture both current and legacy firmware releases, auxiliary scripts, configuration templates and documentation exactly as published by the vendor or its ecosystem.[43] Third, for vendors hosting firmware artifacts on static file servers exposing directory listings, such as publicly accessible HTTP indexes, we deploy a recursive crawler to reconstruct the full directory hierarchy. This category includes sites that directly expose their internal storage layout, often backed by cloud object storage infrastructures. In these cases, the crawler enumerates directories and subdirectories, mirrors the site architecture, and selectively downloads relevant artifacts based on filename patterns, file extensions and directory context. Figure 5 illustrates a representative example of such a directory firmware repository.

A. Miner enumeration and ecosystem mapping We first construct an exhaustive inventory of commercially available ASIC miners by aggregating data from major public mining ecosystem platforms, including AsicMinerValue [40], MinerStat [41] and WhatToMine [42]. The complete device inventory used for this mapping is summarized in Appendix D. This initial mapping step allows us to identify dominant vendors, hardware families and firmware lineages, and to define a consistent naming and classification scheme for subsequent analysis. We focus on the three dominant miner vendors (Bitmain, MicroBT, and Canaan) and also include Iceriver. Together, these four account for the overwhelming majority of deployed mining hardware [4]. Additionally, this synthesized list constitutes the baseline for firmware collection and analysis throughout this work. Figure 4 illustrates the relative distribution of miners per manufacturer as derived from this aggregated inventory, highlighting the extreme concentration of the ASIC mining ecosystem.

C. Corpus normalization and firmware reconstruction

B. Automated collection of firmware and vendor artifacts

The collected firmware corpus is inherently heterogeneous, spanning multiple vendors, device families, time periods, and artifact types, including update packages, flash images, management tools, and documentation. To enable systematic analysis, we apply a normalization and reconstruction pipeline that transforms raw artifacts into a consistent and analyzable dataset. Each artifact is associated with a structured identifier composed of manufacturer, miner family, and firmware generation, inferred from filenames, embedded metadata, configuration files, and scripts. This enables the reconstruction of firmware lineages and the separation of device-specific firmware from generic tooling. Artifacts are then categorized into functional classes, primarily distinguishing update packages from full flash images. Since update packages often contain only partial components, we reconstruct complete firmware images through decompression, decryption, and filesystem extraction using standard tools (e.g., binwalk, ubireader), together with custom scripts and publicly available reverse-engineering utilities for proprietary formats.

For each identified miner model and manufacturer, we systematically collect all publicly accessible firmware images and associated vendor artifacts, including update packages, full reflashing images, management tools and documentation. Our collection methodology deliberately relies exclusively on open and publicly reachable distribution channels, without requiring any authentication, privileged access or physical interaction with mining hardware. In practice, artifact collection follows three complementary strategies, depending on the nature of the vendor distribution infrastructure. First, for official vendor websites exposing firmware through structured backend services, we perform automated scraping by identifying the underlying download APIs or backend endpoints used by the web interface. This typically involves enumerating API requests, catalog endpoints or JSON indices that list available firmware files. Once identified, these endpoints are queried programmatically to retrieve exhaustive file listings, which are then downloaded in bulk. This method enables massive and reproducible collection of all firmware

6

The initial dataset contains 871 firmware-related artifacts (Figure 6), extracted from a broader collection of 3,769 files including documentation and tooling. Although this corpus provides broad coverage across vendors, device families, and firmware generations, it exhibits significant heterogeneity in format, completeness, and redundancy, which prevents direct large-scale analysis without preprocessing. Our objective is to maximize analytical coverage while avoiding redundant work, as analyzing multiple artifacts corresponding to equivalent firmware instances does not provide additional security insight but significantly increases analysis cost. We first apply integrity and format validation to eliminate corrupted, truncated, or invalid artifacts that cannot be processed by standard tooling. We then attempt to decrypt, decompress, and unpack all remaining artifacts. Firmware packages frequently embed proprietary container formats, encryption schemes, or nested compression layers, which we handle using a combination of standard tools, custom scripts, and publicly available reverse-engineering utilities. For proprietary formats, extraction often relies on external technical knowledge and community reverse engineering efforts. Bitmain firmware distributed in the .bmu format requires dedicated unpacking logic together with formatspecific handling, which we perform using publicly available tools such as BitmainFirmwareUnpacker [44]. Iceriver firmware similarly relies on encrypted update containers. Reverse engineering efforts, notably those associated with custom firmware projects such as iceriver-oc [45], have shown that these containers rely on static, hardcoded secrets combined with standard symmetric cryptographic primitives. Once these secrets are recovered, the decryption process becomes reproducible and allows full extraction of embedded firmware components. Comparable efforts exist for MicroBT and related WhatsMiner ecosystems. However, reconstruction remains incomplete for a subset of artifacts due to stronger obfuscation, partially undocumented formats, and unresolved encryption or missing cryptographic material, leading to their exclusion from further analysis. We then evaluate reconstruction completeness. Many collected files correspond only to partial update payloads and do not expose a full system image. Since our analysis requires a coherent firmware environment, we retain only artifacts that allow reconstruction of a mountable filesystem together with executable binaries, configuration files, and sufficient contextual information to interpret update logic and exposed services. Artifacts that remain too partial to support reliable structural analysis are discarded. The dominant reduction factor is redundancy. Firmware ecosystems exhibit extensive reuse across models, generations, and minor releases, with many artifacts differing only by packaging variations, metadata changes, or limited version increments. A large fraction of the remaining artifacts corresponds to near-identical firmware images. Retaining all of them would artificially skew the analysis by over-representing specific firmware lineages without increasing the diversity of

observable security properties. To address this, we perform large-scale deduplication using binary similarity and structural comparison techniques, clustering similar artifacts and retaining a single representative image per cluster unless a variant provides meaningful cross-version differences. This process yields a final dataset of 134 distinct firmware images, including 102 Bitmain images, 9 MicroBT images, 12 Canaan images, and 11 Iceriver images. Overall, the reduction is driven primarily by redundancy rather than by data loss, which highlights a structural property of the ecosystem itself: firmware components and update mechanisms are heavily reused across devices. As a result, weaknesses identified in a representative subset are likely to generalize to a much larger deployment base.

410 260 Management Tools Documentation (PDF)

611

Flash firmwares Update firmwares

2592

Other 767

Figure 6. Distribution of collected firmware-related artifacts before filtering.

Filtering stage Initial candidates Integrity filtering Decryption step Reconstruction step Deduplication

Remaining

Removed

Main cause

871 820 690 612 134

– 51 130 78 478

Flash + update artifacts Corrupted / invalid files Encrypted / unsupported formats Partial / incremental updates Redundant variants

Table I C ORPUS REDUCTION PIPELINE . R EDUNDANCY ACROSS FIRMWARE VERSIONS IS THE DOMINANT REDUCTION FACTOR .

D. Static analysis and vulnerability mapping We perform static analysis across the normalized firmware corpus, combining string extraction, file system inspection, and script/binary analysis to identify vulnerability patterns relevant to the attack model of Section VI. Concretely, we search for hard-coded credentials in configuration files and binaries, authentication logic in web interfaces and APIs, update scripts and signature verification routines, exposed services (e.g., SSH, HTTP servers), and embedded cryptographic material such as keys, certificates, or initialization vectors. The analysis relies on standard tooling (e.g., binwalk, strings, file system parsers) as well as custom scripts to automatically extract and index relevant artifacts across all firmware images. For instance, we identify credential reuse through pattern matching in shadow files and initialization scripts, detect weak update mechanisms by inspecting flashing scripts and signature checks, and enumerate exposed services by analyzing startup scripts and configuration files. Network-related components are also examined to determine whether communications are

7

authenticated or encrypted, and whether APIs enforce access control. The objective is not to list all technical weaknesses, but to isolate those that are reachable given the entry points identified in the firmware. Automated vulnerability extraction produces a large number of candidate findings, which are then manually reviewed to confirm their validity and relevance. This step is necessary because firmware images often include unused components, legacy code, or generic tools that may appear vulnerable but are not actually exposed in the deployed system.

VIII. I NFORMATION RETRIEVED The purpose of this first section is to show that, beyond security aspects, a significant amount of critical information can already be recovered from these firmware images. A. OS Once unpacked, update artifacts reveal concrete and verifiable properties of the deployed software stack. These include the embedded Linux family, filesystem organization, init conventions, kernel lineage, and vendor-specific components. Such information is difficult to infer from network behavior alone. This insight directly guides static analysis by narrowing the expected locations of credentials, update logic, exposed services, and management interfaces. Out of the 134 extracted artifacts, we are able to identify the underlying Operating System (OS) for 121 images. The corpus is primarily based on Angstrom or OpenEmbedded, followed by Buildroot and OpenWrt. A small subset of images remains unclassified due to missing or non-recoverable root filesystem components. These OS fingerprints already provide useful guidance for analysis. OpenWrt images expose stable and easily identifiable configuration structures such as /etc/config and uci, whereas Buildroot and OpenEmbedded images more often correspond to tightly controlled vendor appliances with custom layouts and limited traces of standardized package management. Vendor distributions reflect differing engineering choices rather than uniform platform shifts. Bitmain spans multiple OS families across its update images, while MicroBT relies exclusively on OpenWrt in our dataset. Canaan exhibits a mixed profile across the Avalon family. Iceriver stands apart, as none of its update packages expose a recoverable root filesystem, which is consistent with a partial update strategy distributing only tightly packaged components.

E. Attack surface inference Building on the identified vulnerabilities, we determine whether they form coherent attack scenarios consistent with the model defined in Section VI. Rather than analyzing weaknesses in isolation, we evaluate how they combine with exposed entry points to enable concrete attacker actions. For each firmware image, we identify the most impactful scenario that can realistically be constructed. When multiple attack paths are possible, we retain the one leading to the highest level of compromise according to the capability hierarchy. This allows us to associate each device with a dominant attack scenario reflecting its worst-case exposure. This classification provides a simplified but operational view of the attack surface. Instead of reporting raw vulnerabilities, each miner is characterized by the strongest attack it enables, which makes it possible to compare devices and to identify broader trends across manufacturers. In particular, it allows us to determine whether a given vendor ecosystem tends to expose only limited attack paths or systematically enables high-impact compromises. F. Scope and interpretation of vulnerabilities Our analysis is restricted to weaknesses that can be linked to concrete attack paths, rather than attempting to exhaustively report all flaws present in the firmware. The methodology is purely static. We do not rely on emulation or runtime validation, which prevents direct observation of dynamic behaviors such as memory corruption or runtime privilege escalation. In addition, firmware artifacts are often partial and may omit critical components such as bootloaders or hardware-specific services. As a result, some protections present on deployed devices may not be visible in the analyzed images (e.g. a firewall). These limitations affect exploit validation but not structural analysis. The objective is to determine whether the conditions required for an attack scenario are present, not to guarantee end-to-end exploitability in all configurations. To mitigate these limitations, we complement the static analysis with targeted validation on real devices, as described in Section X. For each of the 134 reconstructed firmware images, we manually verified the presence of the identified weaknesses and their associated attack paths whenever direct inspection was possible. This validation step ensures that the reported findings correspond to actual device behavior and not only to artifacts of static analysis.

B. Miner Our empirical analysis highlights a strong structural convergence at the software level. Despite heterogeneity in hardware architectures and control logic, we find that the mining functionality itself consistently relies on a small set of longestablished open-source projects, predominantly appearing as outdated releases or heavily customized forks. Across the analyzed corpus, Iceriver devices rely on cpuminer-multi [46], [47] (version 1.3.7), a CPU-oriented mining software whose codebase originates from an older generation of cryptocurrency mining tools. MicroBT devices initially embed cgminer [48] version 4.9.2, before transitioning in more recent generations to a proprietary binary referred to as btminer. While the latter obscures its upstream origin, configuration semantics, Stratum protocol handling, and internal control patterns strongly indicate continuity with a cgminer 4.9.x codebase rather than a ground-up reimplementation. Canaan firmware exhibits a broader historical span, ranging from cgminer 4.0.0 in older devices to cgminer 4.11.1, the final official upstream release, in more recent models.

8

Bitmain devices show a similar evolution, progressing from early cgminer 3.4.3 deployments to cgminer 4.9.x, before consolidating around a proprietary fork known as bmminer, which retains the architectural and protocol foundations of cgminer while introducing vendor-specific extensions. Taken together, these observations show that the mining layer of contemporary miner firmware ecosystems remains anchored in software projects whose main upstream development dates back roughly to the 2014–2018 period. In other words, even in recent devices, the core mining logic often relies on software stacks designed and released several years ago, then incrementally adapted rather than fundamentally renewed. Vendors extend these legacy codebases through external management binaries, configuration layers, and hardware-specific drivers, effectively freezing the core mining logic while evolving the surrounding control infrastructure. This widespread reliance on aging open-source software has important implications. cgminer is distributed under the GNU General Public License version 31 , while cpuminer-multi is licensed under version 2 of the same license family. While license compliance is out of scope, this discussion clarifies software lineage and highlights the central role of open-source components in an ecosystem otherwise presented as highly proprietary. From a security perspective, this design choice concentrates risk on a limited set of legacy codebases. For example, cgminer versions up to 4.10.0 contained an authenticated remote code execution vulnerability in the remote management interface (CVE-2018-10058) [49]. Beyond known vulnerabilities, we performed a lightweight static analysis of cgminer and cpuminer-multi, two representative mining cores that remain widely reused across vendors. Our analysis relies on Semgrep [50], complemented by manual inspection of the upstream codebases [48], [46]. Across both projects, we consistently observe recurring classes of weaknesses. First, multiple code paths rely on unbounded string manipulation functions without explicit bounds checking, increasing the risk of buffer overflows in the presence of malformed inputs. Second, the codebases exhibit fragile memory management patterns, with manual allocation and deallocation logic that provides limited safety guarantees and may lead to use-after-free conditions or insufficient validation of allocation results. Third, externally controlled data originating from mining pools, configuration interfaces, or remote management channels is not systematically sanitized before being processed, exposing the software to injection or parsing vulnerabilities. Finally, several control and monitoring interfaces operate over plaintext communication channels, exposing sensitive operational data and increasing the attack surface for network-based adversaries. Given that these mining cores are reused across vendors through customized forks, often with limited visibility and reduced community review, such weaknesses may persist and

propagate across independently maintained firmware distributions. As a result, the mining layer itself constitutes a shared and largely homogeneous attack surface across otherwise heterogeneous devices. IX. S ECURITY EXPOSURES Security weaknesses in cryptocurrency mining devices are partially documented, including exposed management interfaces, hard-coded credentials, insecure update mechanisms, and backdoors [32], [33], [51], [52], [53], [54], [55], [35], [34]. However, these findings remain fragmented and lack a unified mapping to concrete attacker capabilities. We therefore systematize existing knowledge by linking vulnerabilities to operational attack scenarios. Our analysis shows that publicly available firmware artifacts already constitute a major attack surface: without device access, an adversary can reconstruct internal architecture, identify weaknesses, and prepare attacks offline at negligible cost. This challenges the current firmware trust model, where update artifacts implicitly enable large-scale reconnaissance. In the following, we map these weaknesses to realistic attacker actions and impacts. We have included a more comprehensive analysis of a model by vendor in the appendix Section E. A. Firmware phishing attack All major manufacturers rely on manual update workflows, in which operators are expected to download and flash firmware images obtained from vendor websites. This design inherently creates a highly scalable phishing attack surface. Across all major manufacturers, mining devices explicitly support reflashing using external firmware packages, including Secure Digital (SD) card based procedures, and routinely accept firmware originating outside official distribution infrastructures: • Bitmain documents SD card flashing and supports external firmware deployment [56], [57]. • MicroBT supports SD card flashing and has a large thirdparty firmware ecosystem [58], [59], [60], [61]. • Canaan firmware images are publicly redistributed through multiple external reseller platforms [62]. • Iceriver firmware packages are similarly redistributed by third-party vendors [63]. As long as a firmware package conforms to the expected update container format and passes basic validation logic, it gains persistent privileged execution on the device. This enables a class of social engineering attacks that we term firmware phishing attacks, in which adversaries distribute malicious firmware images masquerading as legitimate updates. Such images can embed wallet redirection logic, hidden mining pools, persistent backdoors, or destructive overclocking parameters. These attacks can be deployed at scale through impersonation of vendor after-sales support, for instance by advertising urgent security fixes or mandatory performance updates.

1 We reference upstream licenses solely to explain software lineage and security implications. We did not audit license compliance and make no legal claims.

9

[14], [66], [15]. Crucially, the vulnerability resides at the protocol layer itself and therefore affects miners regardless of firmware hardening or web interface security. Vendor documentation further reinforces this exposure. For most manufacturers, Stratum over plaintext TCP is the default and commonly documented configuration, with no requirement to enable encryption. Only Iceriver and Canaan document optional support for SSL or TLS endpoints, while still allowing unencrypted TCP connections. As a result, even when encrypted Stratum is technically available, nothing encourage user from deploying miners in an insecure plaintext mode. This makes miners vulnerable to the Cryptocurrency theft and revenue redirection attack scenario.

Figure 7. Warning displayed on the official Canaan support website in 2025, alerting users about fraudulent firmware update instructions and impersonation of support channels.

C. Local network threat model and high impact defaults This section does not aim to exhaustively enumerate individual vulnerabilities. Instead, it focuses on identifying which attack scenarios (as defined in Section V) are realistically achievable for each manufacturer, based on the exposed attack surface and observed configurations. The vulnerabilities discussed in the following subsections primarily matter for an adversary who can reach miners on their management network (Local Area Network (LAN) or internal fleet segment). In practice, miners are rarely exposed directly to the public Internet.2 They are typically placed behind Network Address Translation (NAT)s, firewalls, or dedicated Virtual Local Area Network (VLAN)s and administered from nearby workstations or management servers [25].This prerequisite commonly holds in mining and hosting environments, where attackers may gain internal access through compromised infrastructure, misconfigurations, or lateral movement. Under this model, weak credentials combined with reachable services (Secure Shell (SSH), web UI, or management APIs) provide immediate high-impact primitives, including persistent takeover, configuration tampering, and hashrate redirection. This type of attack remains realistic and well-documented in practice, as illustrated by prior work on lateral movement and internal network compromise, as well as real-world incidents affecting large-scale infrastructures [67], [68], [69], [70], [71]. As summarized in Table II, these attack primitives translate into widespread exploitability across vendors under a LAN threat model. The list in Appendix D also indicates which scenario we consider vulnerable to each model. 1) Bitmain: For Bitmain devices, we adopt a near exhaustive per model analysis strategy. Our firmware corpus contains almost one image per miner model or hardware family (102 usable images in total), covering 113 out of 123 Bitmain miners, excluding only the S23, KS7 and L11 families for which no extractable artifacts were available. Across all analyzed Bitmain firmware images, we consistently identify the presence of at least one user account protected by a weak or default password together with an active SSH service. This configuration alone is sufficient to enable immediate

Notably, this threat is explicitly acknowledged by manufacturers themselves. Canaan publicly warns users about ongoing impersonation of official support channels used to distribute fraudulent firmware updates [64]. We observed this warning displayed on Canaan’s official support website in 2025, as shown in Figure 7, indicating that firmware phishing is an active real-world attack vector rather than a hypothetical risk. In the absence of a strictly enforced secure boot mechanism with cryptographic root of trust, firmware authenticity ultimately relies on operator judgment. Firmware phishing therefore enables persistent compromise [65] of mining fleets without requiring software vulnerabilities, runtime exploits, or physical access, constituting a systemic weakness of the ASIC mining ecosystem. This directly enables the attack scenario of full device takeover and infrastructure abuse. B. Systemic use of stratum V1 over plaintext TCP We analyzed mining binaries, configuration files, startup scripts and vendor documentation across the full firmware corpus to identify supported mining communication protocols. Across all manufacturers, we did not observe any native support for Stratum V2 (a successor protocol with authenticated and encrypted transport) or mandatory encrypted Stratum channels. All devices rely on Stratum V1 and by default operate over plaintext TCP connections. Stratum V1 was designed for simplicity and low overhead, but provides no transport encryption, no authentication of pool endpoints, and no cryptographic integrity for job assignments or share submissions. Consequently, all mining pool communication is transmitted in cleartext and is fully malleable in transit. This design creates a systemic man-in-the-middle attack surface. Any adversary positioned on the network path, including local attackers, compromised gateways, or Internet Service Provider (ISP)s, can intercept, modify, and replay Stratum traffic. By altering wallet addresses, pool endpoints, or job parameters, an attacker can silently redirect hashrate and rewards without disrupting mining operations. These weaknesses are well documented in prior work. Stratum V1 has been shown to enable stealth hashrate theft, share manipulation, and proxy redirection attacks [13], [12],

2 To the best of our knowledge, an analysis conducted using https://www. shodan.io/ did not reveal any mining devices directly exposed to the public Internet.

10

Attack scenario on LAN Bitmain (123) MicroBT (65) Canaan (36) Iceriver (22)

remote administrative access, without requiring exploitation of software vulnerabilities. As a result, all analyzed Bitmain devices are directly susceptible to our strongest attack class, namely full device takeover and infrastructure abuse (see Section V). Although not all S21 miners ship with active local user accounts, the factory /etc/shadow.factory file still embeds a default password and SSH remains enabled, while the presence of an unauthenticated cleartext HTTP management interface and API remains exploitable, enabling at minimum Cryptocurrency theft and revenue redirection. 2) MicroBT: For MicroBT devices, firmware update artifacts could not be reliably extracted despite extensive static analysis efforts. Publicly distributed update packages exhibit high entropy and strong obfuscation, preventing reconstruction of usable update firmware images. As a result, our analysis relies on the alternative recovery mechanism supported by MicroBT [60]. These flashing images provide only partial visibility into the software stack: the mining application and web management interface are absent, and significant portions of the image are encrypted. In addition, miners still require a subsequent online firmware update after reflashing, further limiting the completeness of the recovered material. Unlike Bitmain, MicroBT firmware organization follows a control board centric model. We therefore structured our analysis by associating firmware artifacts with control board families (H616, H6OS, H6, and H3) rather than individual miner models. Under these constraints, our analysis does not expose direct administrative takeover primitives. The only demonstrable weakness corresponds to Performance degradation and operational disruption attack scenario, where network reachable management interfaces during discovery phases allow interactions that can disrupt normal miner operation. 3) Canaan: For Canaan devices, we successfully collected and extracted firmware images spanning a broad historical and product range, from early Avalon generations to recent consumer and professional models. Firmware and update images for Avalon 1 through Avalon 9, as well as Avalon 15 and the Avalon family, covering 18 out of 36 miners, were obtained from publicly accessible official sources, including the vendor download portal and public source code repositories (Figure 5) [72], [43]. These resources provide substantial visibility into firmware versions, update workflows, tooling, and documentation, enabling comprehensive offline analysis without requiring physical hardware. All fully extracted Avalon firmware images are vulnerable to the strongest attack scenario identified in this work, namely full device takeover and infrastructure abuse, due to an exposed SSH service combined with a factory account protected by weak credentials. For Avalon models where complete firmware reconstruction was not possible, complementary evidence from public vendor resources indicates exposure to a secondary yet critical attack scenario: Cryptocurrency theft and revenue redirection. In these cases, the management API follows an overly permissive trust model, granting administrative privileges to any authenticated client. This allows attackers with network access to modify mining pool endpoints, payout addresses, and hardware settings. Au-

Full device takeover Revenue redirection Physical degradation Performance disruption

113 113 113 113

0 0 0 65

26 34 34 34

0 22 22 22

Table II LAN ATTACK SCENARIOS : NUMBER OF VULNERABLE MINER MODELS PER MANUFACTURER ( TOTALS IN PARENTHESES ). F URTHER DETAILS IN S ECTION D.

thentication exchanges for sensitive actions are performed over plaintext channels, making them vulnerable to interception or replay by on-path adversaries. For certain generations (notably Avalon 12 to Avalon 14), vendor-documented API commands further allow the administrative password to be reset to a default value, effectively removing any remaining protection. Beyond revenue redirection, the exposed API also enables repeated fan and power control operations, potentially leading to performance degradation or hardware damage. 4) Iceriver: In contrast with other manufacturers, Iceriver firmware update packages are structurally partial and typically expose only isolated components, such as application binaries or web interface resources, rather than a full root filesystem. This limits the amount of information recoverable through static analysis and prevents reliable identification of the underlying operating system or default services such as SSH. Despite this limited visibility, we identified a critical weakness in the authentication logic of the Iceriver web management interface, which is shared across multiple miner models and generations. This flaw allows unauthorized access to administrative functions and enables direct modification of mining pool endpoints and wallet addresses. As a result, Iceriver devices are vulnerable to the Cryptocurrency theft and revenue redirection attack scenario described in Section V, even in the absence of full firmware visibility. X. VALIDATION ON REAL DEVICES To validate the relevance of our firmware findings, we complemented our analysis with measurements on two real devices. For each miner, we extracted data through two complementary paths: live acquisition by leveraging identified weaknesses to access and collect runtime artifacts, and cold NAND flash extraction to recover the most complete filesystem and boot material possible. In addition, we experimentally evaluated the attack scenarios introduced in Section V to assess their feasibility on real hardware. We applied this methodology to an Iceriver AL0 miner and to a Bitmain Antminer KS5, enabling a direct comparison between publicly distributed artifacts and the full firmware state. a) Iceriver.: Although Iceriver update packages are often structurally partial, our cross-artifact comparison shows that the security-relevant components they do expose are consistent with those observed on a real device. In particular, the embedded web management stack and boot artifacts such as BOOT.BIN closely match what we extracted from an Iceriver AL0 miner in our lab. Notably, no official firmware update

11

package is publicly available for the AL0 model. Nevertheless, the consistency observed across artifacts strongly suggests that Iceriver reuses the same firmware building blocks across models and generations. In particular, our boot analysis indicates reuse of the same Zynq boot chain (FSBL and UBoot 2019.01) across multiple BOOT.BIN variants, which strongly supports the hypothesis of a shared firmware lineage across devices and generations. This reuse suggests that vulnerabilities identified in publicly distributed, partial update artifacts can plausibly generalize to real-world deployments, as manufacturers tend to repackage and redeploy the same firmware building blocks. Importantly, analysis of the real AL0 filesystem reveals the presence of a preconfigured local user account (Miner168861) with a persistent password hash provisioned by the manufacturer, together with an active SSH service. This condition could not be observed from vendordistributed artifacts alone, both because these update packages do not expose a complete root filesystem and because no official update artifact is available for the AL0 miner model and indicates that deployed systems may expose additional attack surfaces beyond what update packages suggest. Finally, the client-side weakness identified in login.js (cookie handling) is present in both the downloaded web interface and the version extracted from the real device, reinforcing that this issue is not an artifact of incomplete update packages but a persistent flaw across Iceriver deployments. This configuration directly enables the Full device takeover and infrastructure abuse attack scenario defined in Section V, a risk that remains largely invisible when considering firmware artifacts alone and was therefore underestimated in the previous analysis. b) Bitmain.: For the Bitmain Antminer KS5, we performed a direct file comparison between the publicly distributed firmware image (release update payload) and the full filesystem extracted from the device eMMC. The comparison reveals that the delta between the two artifacts is limited and largely concentrated in configuration values and recompilation timestamps rather than in structural security hardening. In particular, we observe changes in the factory mining configuration (e.g., frequency and voltage defaults in /etc/cgminer.conf.factory) and in thermal management parameters (e.g., a non-zero minimum PWM threshold in /etc/topol.conf), which primarily affect performance and operational stability. We also identify minor differences in the update CGI scripts of the web interface, such as removing a default fallback value when emitting the bitmain-work-mode field and enabling dmesg output in a log endpoint. In addition, several core binaries (busybox, lighttpd, ntpd, and the mining control binary godminer) differ by hash and embed distinct build dates, indicating that the device image and the release artifact were built at different times or from slightly different source snapshots. However, from a security standpoint, these changes do not materially alter the dominant risk profile: the real device still exposes remote administration surfaces (notably SSH) combined with weak credential assumptions, which remains sufficient to enable full compromise by any

attacker with network access. This KS5 validation therefore supports a key conclusion of our work: while vendors may introduce incremental updates and operational tuning between distributed artifacts and deployed images, the persistence of high impact access primitives (e.g., password remote shells) dominates the security posture and renders smaller hardening deltas largely irrelevant in realistic threat models. XI. S ECURITY RECOMMENDATIONS Our results show that the security of ASIC mining infrastructures is determined primarily by the integrity of the firmware lifecycle rather than by isolated flaws. Mitigations should therefore focus on restoring clear trust boundaries across firmware distribution, installation, and execution. More fundamentally, these measures aim to disrupt the attacker pipeline introduced in Figure 8. In particular, they seek to break the progression from access to impact by reducing exposed entry points and eliminating exploitable vulnerabilities, thereby limiting the number of viable attack paths in the model of Figure 2. Concretely, this includes preventing trivial access to firmware artifacts, hindering their extraction or decryption, and mitigating their misuse for malicious updates or device takeover. This section outlines a set of implementation-level directions derived from the failure modes identified in Section IX. Rather than providing exhaustive guidelines, the objective is to characterize the minimal security properties required to restore well-defined trust boundaries across firmware execution, update, and management planes. A primary requirement is the establishment of a root of trust anchored in hardware, ensuring that only authenticated firmware can execute on the device. In practice, this relies on a secure boot chain in which each stage verifies the integrity and authenticity of the next using public key signatures. The corresponding verification key must be embedded in immutable storage, and verification must occur prior to execution. In addition, version control mechanisms are necessary to prevent rollback to vulnerable firmware versions, thereby enforcing forward-only evolution of the software stack [73]. Firmware update mechanisms must guarantee authenticity, integrity, and freshness. This implies that update packages are systematically authenticated before installation and that version monotonicity is enforced through trusted counters or equivalent mechanisms. A clear separation between verification and installation logic reduces attack surface, while update procedures should be designed to remain atomic, with explicit recovery paths in case of failure. These properties are consistent with the design principles of secure update frameworks such as TUF and Uptane [74], [75]. In particular, strengthening update mechanisms directly prevents attackers from leveraging firmware access to achieve persistence or large-scale compromise. The public availability of firmware artifacts requires that distribution channels provide authenticity guarantees independent of operator trust. This can be achieved through signed manifests, reproducible artifact identification via cryptographic

12

hashes, and authenticated transport mechanisms. Such measures reduce exposure to firmware substitution and phishing attacks, and align with established supply chain security practices [76]. Given the extensive code reuse across devices, consistent maintenance of shared components is required, supported by coordinated patching strategies. The extensive reuse of legacy components across firmware images implies that vulnerabilities propagate across product lines and persist over time. This necessitates a coordinated maintenance strategy at the vendor level, including tracking of embedded dependencies and synchronized patch deployment. The use of Software Bills of Materials facilitates this process by providing visibility into third-party components and associated risks [77]. Our empirical analysis shows that many high-impact attack scenarios stem from weak default configurations rather than complex software vulnerabilities. As a result, baseline security critically depends on secure-by-default settings, including the absence of default credentials, the restriction of remote access interfaces, and the use of strong authentication mechanisms. In particular, password-based remote access introduces unnecessary exposure and should be avoided in favor of stronger authentication schemes, in line with IoT baseline security standards [78]. These measures directly reduce the set of reachable entry points in the attack model. The mining communication layer constitutes a direct economic control channel and therefore requires integrity and authenticity guarantees. The widespread use of plaintext Stratum V1 introduces a systemic attack surface at the network level. Mitigations include the use of encrypted transport channels and the adoption of protocols providing authentication and integrity protection, such as Stratum V2. Prior work has demonstrated the feasibility of traffic manipulation attacks in the absence of such protections [12], [14]. Finally, baseline security also depends on minimal observability and response capabilities. The absence of visibility into security-relevant events limits detection and response capabilities, which motivates the integration of minimal audit mechanisms such as logging of update operations and authentication events, with integrity protection where feasible [79].

enable large-scale firmware phishing, and allow persistent full compromise without requiring software exploitation. • We propose a framework and a methodology for firmware analysis, enabling reproducible and large-scale inspection of firmware artifacts without requiring physical devices, and allowing recovery of internal architectures and reconstruction of attack paths. • We demonstrate the insecurity of the mining ecosystem: applying this methodology reveals that critical vulnerabilities are pervasive across all major vendors, with many devices exploitable under a LAN threat model, plaintext Stratum V1 enabling revenue redirection, and firmware phishing extending this risk to all deployments, requiring immediate remediation. This paper shows that the firmware distribution model inherently enables large-scale analysis, attack reconstruction, and cross-vendor exploitation, making security failures systemic rather than incidental.

XII. R EMEDIATION AND INFORMATION FOR MANUFACTURERS

Note for reviewers: we are in contact with the suppliers and will update this section once they have made further progress. XIII. C ONCLUSION Publicly distributed firmware for ASIC miners constitutes a primary attack surface at the scale of the ecosystem. By analyzing firmware from vendors covering approximately 99% of deployed mining hardware, we show that critical security failures are not isolated bugs but inherent properties of the firmware distribution model. The paper establishes the following: • The firmware update workflow is a systemic vulnerability: update artifacts alone expose the attack surface,

13

XIV. E THICAL C ONSIDERATIONS

[4] Cambridge Centre for Alternative Finance, “Cambridge digital mining industry report: Global operations, sentiment, and energy use,” https: //www.jbs.cam.ac.uk/wp-content/uploads/2025/04/2025-04-cambridge -digital-mining-industry-report.pdf, Apr. 2025, university of Cambridge, Judge Business School, First Edition. [5] V. Babkin, “firmwar: An imminent threat to the foundation of computing,” Black Hat Asia 2023 Briefings, Singapore, May 2023, presentation slides. [6] A. Costin, J. Zaddach, A. Francillon, and D. Balzarotti, “A Large-Scale analysis of the security of embedded firmwares,” in 23rd USENIX Security Symposium (USENIX Security 14). San Diego, CA, USA: USENIX Association, Aug. 2014, pp. 95–110. [Online]. Available: https://www.usenix.org/conference/usenixsecurity14/technical-sessions/ presentation/costin [7] A. Costin, A. Zarras, and A. Francillon, “Automated dynamic firmware analysis at scale: A case study on embedded web interfaces,” in Proceedings of the 11th ACM Asia Conference on Computer and Communications Security. New York, NY, USA: Association for Computing Machinery, 2016, pp. 437–448. [8] Y. Zheng, A. Davanian, H. Yin, C. Song, H. Zhu, and L. Sun, “FIRM-AFL: High-Throughput greybox fuzzing of IoT firmware via augmented process emulation,” in 28th USENIX Security Symposium (USENIX Security 19). Santa Clara, CA, USA: USENIX Association, Aug. 2019, pp. 1099–1114. [Online]. Available: https://www.usenix.o rg/conference/usenixsecurity19/presentation/zheng [9] B. Feng, A. Mera, and L. Lu, “P2IM: Scalable and hardwareindependent firmware testing via automatic peripheral interface modeling,” in 29th USENIX Security Symposium (USENIX Security 20). Virtual Event, USA: USENIX Association, Aug. 2020, pp. 1237–1254. [Online]. Available: https://www.usenix.org/conference/usenixsecurity 20/presentation/feng [10] S. U. Haq, Y. Singh, A. Sharma, R. Gupta, and D. Gupta, “A survey on iot and embedded device firmware security: Architecture, extraction techniques, and vulnerability analysis frameworks,” Discover Internet of Things, vol. 3, no. 1, p. 17, 2023. [Online]. Available: https://doi.org/10.1007/s43926-023-00045-2 [11] T. Bakhshi, B. Ghita, and I. Kuzminykh, “A review of iot firmware vulnerabilities and auditing techniques,” Sensors, vol. 24, no. 2, p. 708, Jan. 2024. [12] R. Recabarren and B. Carbunar, “Hardening stratum, the bitcoin pool mining protocol,” 2017. [Online]. Available: https://arxiv.org/abs/1703 .06545 [13] X. Liu, R. Chong, Y. Huang, Y. Zhang, and Q. Zhou, “Disappeared coins: Steal hashrate in stratum secretly,” Black Hat Asia 2021, 2021, conference presentation. [14] A. Gervais, G. Karame, K. Wüst, and V. Glykantzis, “On the security and performance of proof of work blockchains,” Financial Cryptography and Data Security, 2016, used as a reference for Stratum-related attack surface discussion. [15] L. Luu et al., “The unbearable lightness of bitcoin mining,” ACM CCS, 2015, reference used for mining-pool attack surface discussion. [16] M. Tran, T. von Arx, and L. Vanbever, “Routing attacks on cryptocurrency mining pools,” in 2024 IEEE Symposium on Security and Privacy (SP). Los Alamitos, CA, USA: IEEE, 2024, pp. 3805– 3821. [Online]. Available: https://doi.org/10.1109/SP54263.2024.00254 [17] D. Chaum, “Blind signatures for untraceable payments,” in Advances in Cryptology, D. Chaum, R. L. Rivest, and A. T. Sherman, Eds. Boston, MA, USA: Springer US, 1983, pp. 199–203. [18] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” https: //bitcoin.org/bitcoin.pdf, 2008, white paper. [19] V. Buterin, “A next-generation smart contract and decentralized application platform,” https://ethereum.org/en/whitepaper/, 2014. [20] Y. Sun, H. Yang, W. Zhang, and Y. Gu, “Asic design for bitcoin mining,” University of Michigan, Tech. Rep., 2021, eECS 570 Final Report. [Online]. Available: https://zwtaoumich.github.io/paper/EECS5 70 Final Report.pdf [21] Bitmain Technologies Ltd., “Bitmain official website,” https://www.bi tmain.com, 2025. [22] MicroBT Mining, “Whatsminer official website,” https://www.whatsm iner.com, 2025. [23] Canaan Creative Co., Ltd., “Canaan official website,” https://www.cana an.io, 2025. [24] M.-C. Yuen, K.-M. Lau, C.-W. Yung, and K.-F. Ng, “Adaptive overclocking mining algorithm selection approach in the cryptocurrency

The primary contribution of this work is a reproducible methodology for large-scale security analysis of firmware distribution ecosystems. This methodology is applied to the case of ASIC cryptocurrency miners using static analysis of firmware distribution artifacts that are publicly accessible on the Internet, with the objective of documenting systemic weaknesses in firmware lifecycles and management planes and providing mitigation guidance. The primary stakeholders are manufacturers, operators, and hosting providers, as well as the broader cryptocurrency ecosystem whose security depends on miner availability and integrity. Publication of security findings can increase adversarial awareness. This risk is mitigated by focusing on high level failure modes and by avoiding disclosure of exploitation steps or weaponizable artifacts. The study does not involve probing deployed miners, attempting exploitation, or interacting with production systems. All observations derive from artifacts collected via open distribution channels, including update packages, reflashing images, management tools, and documentation. Limited validation was performed on two devices under our control in a controlled environment solely to confirm that publicly distributed artifacts are representative of deployed software. Where high impact issues were identified, we initiated vendor notification and followed a coordinated disclosure mindset. We deliberately refrain from publishing information that would materially lower the cost of exploitation, such as ready-to-use payloads, credentials, exact bypass sequences, or end-to-end attack recipes. Our ethical analysis is guided by the principles of beneficence, respect for persons, justice, and respect for law and public interest. Publication is ethically appropriate because this ecosystem is highly concentrated and exhibits extensive code reuse across models and generations, allowing systematic weaknesses to propagate widely and persist. Securityby-obscurity around firmware distribution does not provide reliable protection and can hinder independent assessment by operators. By clarifying trust boundaries and recommending mitigations such as signed updates with anti-downgrade, safer defaults, hardened management planes, and secure mining communication, this work aims to reduce real-world harm and improve ecosystem resilience. R EFERENCES [1] L. Bao, J. Yang, X. Yang, and C. Rong, “Bibliometric analysis of scientific publications on blockchain research and applications,” 2025. [Online]. Available: https://arxiv.org/abs/2504.13387 [2] J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. A. Kroll, and E. W. Felten, “SoK: Research perspectives and challenges for bitcoin and cryptocurrencies,” in 2015 IEEE Symposium on Security and Privacy. Los Alamitos, CA, USA: IEEE, 2015, pp. 104–121. [3] X. Zhang, Z. Chen, and S. Wang, “A study of the impact of cryptocurrency price volatility on the stock and gold markets,” Finance Research Letters, vol. 69, p. 106114, 2024. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S1544612324011437

14

mining pool,” in Proceedings of the 2022 5th International Conference on Blockchain Technology and Applications, ser. ICBTA ’22. New York, NY, USA: Association for Computing Machinery, 2023, pp. 50–56. [Online]. Available: https://doi.org/10.1145/3581971.3581978 [25] European Union Agency for Cybersecurity (ENISA), “Enisa threat landscape report 2018: 15 top cyberthreats and trends,” ENISA, Tech. Rep., Jan. 2019, accessed 2026-01-26. [Online]. Available: https://www.enisa.europa.eu/sites/default/files/publications/WP2018%2 0O.1.2.1%20-%20ENISA%20Threat%20Landscape%202018.pdf [26] Kaspersky, “Crypto miners on the rise: Kaspersky experts report more than 230% growth in the number of malicious mining programs,” https: //www.kaspersky.com/about/press-releases/crypto-miners-on-the-rise-k aspersky-experts-report-more-than-230-growth-in-the-number-of-mal icious-mining-programs, Nov. 2022, kaspersky press release, accessed 2026-01-26. [27] F. Merces, “Miner malware targets iot, offered in the underground,” https://www.trendmicro.com/en us/research/18/e/cryptocurrency-minin g-malware-targeting-iot-being-offered-in-the-underground.html, May 2018, trend Micro Research, accessed 2026-01-26. [28] A. Zimba, M. Chishimba, C. Ngongola-Reinke, and T. F. Mbale, “Demystifying cryptocurrency mining attacks: A semi-supervised learning approach based on digital forensics and dynamic network characteristics,” 2021. [Online]. Available: https://arxiv.org/abs/2102.1 0634 [29] A. Sari and S. Kilic, “Exploiting cryptocurrency miners with OSINT techniques,” Transactions on Networks and Communications, vol. 5, no. 6, pp. 1–9, Dec. 2017. [30] Cloudflare, “Inside the mirai botnet,” https://blog.cloudflare.com/ins ide- mirai- the- infamous- iot- botnet- a- retrospective- analysis/, 2016, large-scale IoT botnet and DDoS attacks. [31] SC Media, “New malware targets linux devices for ddos and crypto mining,” https://www.scworld.com/brief/new-malware-targets-linux-n etwork-devices-for-ddos-crypto-mining, 2026, condiBot and Monaco malware. [32] D. Pauli, “Aussie researcher claims antminer bitcoin devices can be hijacked,” https://www.theregister.com/2016/07/12/aussie writes app to hijack scores of pricey antmine bitcoin miners/, 2016, accessed 2026. [33] R. Chirgwin, “Antminer has remote shutdown flaw (antbleed),” https: //www.theregister.com/2017/04/27/prospect of trouble in bitcoin wor ld major miner vulnerable/, 2017, accessed 2026. [34] D-Central Technologies, “Infected asics: A growing menace for crypto miners,” https://d-central.tech/infected-asics-a-growing-menace-for-cry pto-miners-everywhere/, 2025, industry report. [35] J. A. Chambers, “Cryptocurrency asic miners security and hacking audit,” https://jamesachambers.com/cryptocurrency-asic-miners-sec urity-and-hacking-audit/, 2022, security analysis blog. [36] Security Affairs, “Attacks on isp networks allows to steal $83,000 from bitcoin mining pools,” https://securityaffairs.com/27448/cyber-crime/bit coin-mining-pools-hack.html, 2014, bGP hijacking of mining traffic. [37] Netlab 360, “Satori coin robber malware analysis,” https://blog.netla b.360.com/botnets-never-die-satori-refuses-to-fade-away-en/, 2018, wallet replacement attack on mining software. [38] D-Central, “hant asic malware targeting miners,” https://d-central.tec h/infected-asics-a-growing-menace-for-crypto-miners-everywhere/, 2019, ransomware targeting Antminer devices. [39] CoinDesk, “Bitcoin mining pools targeted in wave of ddos attacks,” https://www.coindesk.com/markets/2015/03/12/bitcoin-mining-pools -targeted-in-wave-of-ddos-attacks, 2015, dD4BC attacks on mining pools. [40] “ASIC Miner Value,” https://www.asicminervalue.com, 2025. [41] “MinerStat Mining Hardware Database,” https://minerstat.com/hardwa re/asics, 2025. [42] “WhatToMine ASIC Mining Database,” https://whattomine.com/miners, 2025. [43] Canaan Creative, “Canaan creative public source code repositories,” ht tps://github.com/orgs/Canaan-Creative/repositories, 2020, accessed: 2026-01-28. [44] VladTheJunior, “Bitmainfirmwareunpacker,” https://github.com/Vla dTheJunior/BitmainFirmwareUnpacker, 2025, community tool for unpacking Bitmain proprietary .bmu firmware images. [45] rdugan, “iceriver-oc: Iceriver overclocking firmware,” https://github.c om/rdugan/iceriver-oc, 2024.

[46] T. Pruvot and contributors, “cpuminer-multi: Multi-threaded cpu miner,” https://github.com/tpruvot/cpuminer- multi, 2026, gPLv2-licensed GitHub repository. [47] Lucas Jones, “Cpuminer,” https://github.com/lucasjones/cpuminer-multi, 2014, original CPUMiner fork. [48] Kano and contributors, “cgminer: Multi-threaded multi-pool fpga and asic miner for bitcoin,” https://github.com/kanoi/cgminer, 2026, gitHub repository, fork of ckolivas/cgminer, accessed 2026-04-20. [49] MITRE Corporation, “Cve-2018-10058: cgminer and bfgminer remote management api authenticated code execution,” https://cve.mitre.org/cg i-bin/cvename.cgi?name=CVE-2018-10058, 2018, stack-based buffer overflow in cgminer ¡= 4.10.0. [50] Semgrep, Inc., “Semgrep: Lightweight static analysis for many languages,” https://github.com/semgrep/semgrep, 2026, version 1.150.0. [51] National Institute of Standards and Technology (NIST), “Cve-201811220: Bitmain antminer remote code execution,” https://nvd.nist.g ov/vuln/detail/CVE-2018-11220, 2018, nVD. [52] ——, “Cve-2022-36604: Canaan avalon authentication bypass,” https: //nvd.nist.gov/vuln/detail/CVE-2022-36604, 2022, nVD. [53] ——, “Cve-2022-24659: Goldshell path traversal,” https://nvd.nist.gov /vuln/detail/CVE-2022-24659, 2022, nVD. [54] ——, “Cve-2022-24660: Goldshell debug interface exposure,” https: //nvd.nist.gov/vuln/detail/CVE-2022-24660, 2022, nVD. [55] ——, “Cve-2022-24657: Goldshell hardcoded credentials,” https://nvd. nist.gov/vuln/detail/CVE-2022-24657, 2022, nVD. [56] Bitmain Technologies Ltd., “S19 xp flashing sd card instruction,” https: //support.bitmain.com/hc/en-us/articles/10202973537177-S19-XP-Flash ing-SD-card-Instruction, 2024. [57] “Antminer s19/s21 firmware installation,” https://support.awesomemin er.com/support/solutions/articles/35000189959-awesome-miner-antmi ner-s19-s21-firmware-installation, 2024. [58] Zeus Mining International Co., Ltd., “Whatsminer sd card flashing program,” https://www.zeusbtc.com/firmware- download/details/47 09-whatsminer-sd-card-flashing-program-download, 2024. [59] “WhatsMiner Series Firmware,” https://bixbit.io/en/firmwares/whatsmi ner-series-m2x, 2024. [60] “WhatsMiner SD Card Flashing Tutorial,” https://www.youtube.com/wa tch?v=WxqchyZvQkA, 2024. [61] Hitsxx, “Whatsminer Firmware Upgrade Toolkit,” https://github.com/H itsxx/Whatsminer, 2018, public GitHub repository providing firmware packaging and remote upgrade scripts for Whatsminer ASIC miners. [62] Zeus Mining International Co., Ltd., “Avalonminer firmware,” https: //www.zeusbtc.com/firmware-download/avalonminer-firmware/, 2024. [63] ——, “Iceriver miner firmware,” https://www.zeusbtc.com/firmware-d ownload/iceriver-miner-firmware/, 2024. [64] “Canaan Official Notice on Impersonated Support,” https://www.canaan .io/support/, 2025. [65] Notepad++ Project, “Notepad++ hijacked by state-sponsored hackers,” https://notepad- plus- plus.org/news/hijacked- incident- info- updat e/, Feb. 2026, security incident report describing an infrastructure-level compromise of the Notepad++ update distribution channel between June and December 2025. [66] R. Konoth et al., “Bad leverage: A study of cryptocurrency mining malware,” IEEE Security & Privacy, 2018, reference used for malware and mining abuse discussion. [67] G. Ho, M. Dhiman, D. Akhawe, V. Paxson, S. Savage, G. M. Voelker, and D. Wagner, “Hopper: Modeling and detecting lateral movement,” in 30th USENIX Security Symposium (USENIX Security 21). Virtual Event, USA: USENIX Association, Aug. 2021, pp. 3093–3110. [Online]. Available: https://www.usenix.org/conference/us enixsecurity21/presentation/ho [68] A. Niakanlahiji, J. Wei, M. R. Alam, Q. Wang, and B.-T. Chu, “ShadowMove: A stealthy lateral movement strategy,” in 29th USENIX Security Symposium (USENIX Security 20). Virtual Event, USA: USENIX Association, Aug. 2020, pp. 559–576. [Online]. Available: https://www.usenix.org/conference/usenixsecurity20/presentation/niakan lahiji [69] A. Jony, M. N. Islam, and R. A. Talukder, “A secure token-based approach for dhcp client authentication and replay attack prevention,” in 2024 27th International Conference on Computer and Information Technology (ICCIT). Los Alamitos, CA, USA: IEEE, 2024, pp. 855– 860.

15

[70] E. Medina, “‘Cybersecurity Issue’ forces systems shutdown at mgm hotels and casinos,” https://www.nytimes.com/2023/09/11/technol ogy/mgm-cyberattack.html, Sep. 2023, the New York Times. [71] J. Rundle and C. Stupp, “Unitedhealth hack: What you need to know,” https://www.wsj.com/articles/unitedhealth-hack-what-you-need-to-kno w-45efc28c, May 2024, the Wall Street Journal. [72] Canaan Creative, “Canaan creative official firmware download portal,” https://download.canaan-creative.com/, 2020, accessed: 2026-01-28. [73] National Institute of Standards and Technology, “Platform firmware resiliency guidelines,” https://csrc.nist.gov/publications/detail/sp/8 00-193/final, 2018. [74] R. Kuppusamy et al., “The update framework (tuf),” USENIX Security Workshop, 2017, workshop reference. [75] ——, “Uptane: Securing software updates for automobiles,” https://up tane.org, 2019. [76] ENISA, “Good practices for supply chain cybersecurity,” https://www. enisa.europa.eu/publications/good-practices-for-supply-chain-cybersecu rity, 2019. [77] National Telecommunications and Information Administration, “The minimum elements for a software bill of materials (sbom),” https://www. ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom, 2021. [78] ETSI, “Cyber security for consumer internet of things: Baseline requirements,” https://www.etsi.org/deliver/etsi en/303600 303699/303645/02. 01.01 60/en 303645v020101p.pdf, 2020. [79] National Institute of Standards and Technology, “Guide to computer security log management,” https://csrc.nist.gov/publications/detail/sp/8 00-92/final, 2006.

16

Work Costin et al. [6] Firmadyne [7] Firm-AFL [8] Stratum attacks [12], [13] Routing attacks [16] This work

A PPENDIX A O PEN S CIENCE This work contributes a reproducible methodology for largescale security analysis of cryptocurrency mining firmware based on publicly accessible distribution artifacts. To support open and verifiable research while avoiding legal and ethical risks, we do not redistribute proprietary firmware images. We considered the following artifacts: vendor firmware update and flashing packages, unpacked firmware filesystems, collection and extraction scripts, static analysis tools, and validation configurations. Raw firmware binaries, unpacked filesystems, and end-to-end extraction pipelines are not publicly released. These artifacts are derived from production firmware distributed by major manufacturers and exhibit extensive code reuse across models and generations. Publishing them would materially lower the cost of exploitation at scale before mitigations are deployed. Instead, we provide full methodological transparency. The paper details how to identify firmware distribution channels, collect publicly available artifacts, normalize formats, extract firmware contents, and perform static analysis without interacting with deployed systems. Reproducibility is achieved by reapplying the methodology rather than by reusing an identical dataset. The approach is vendor agnostic and transferable to other embedded and industrial firmware ecosystems. For transparency, the paper cites the publicly available opensource repositories and tools that informed and supported our analysis. These references are provided in the bibliography.

Firmware Yes Yes Yes No No Yes

Mining-specific No No No Yes Yes Yes

Attack scenarios No No No Yes Yes Yes

Cross-vendor Yes No No No No Yes

Table III C OMPARISON WITH RELATED WORK

they do not consider the firmware layer that governs update mechanisms, management interfaces, and device behavior, leaving a significant portion of the attack surface unexplored. Public vulnerability disclosures further illustrate the existence of security weaknesses in real-world mining devices. Prior reports document backdoors and remote access mechanisms in Bitmain miners [33], [51], as well as authentication and API flaws affecting Avalon and Goldshell devices [52], [53], [54], [55]. These findings consistently highlight recurring issues such as weak authentication, insecure update mechanisms, and exposed management interfaces. However, such disclosures remain fragmented, vendor-specific, and largely disconnected from a broader analysis of the attack surface. In particular, they do not capture the role of firmware distribution mechanisms as a primary entry point for large-scale attacks. Overall, existing literature lacks a unified approach combining firmware-level analysis with mining-specific threat modeling. Firmware studies do not capture domain-specific attack implications, while mining security works overlook firmware distribution and update mechanisms. Existing vulnerability disclosures, although valuable, provide only partial visibility and do not explain how individual weaknesses compose into complete attack paths. Our work addresses this gap by combining cross-vendor firmware analysis with mining-specific attack modeling. We rely on publicly distributed update artifacts as a reproducible evidence source, reconstruct internal architectures, and systematically map firmware-level weaknesses to concrete attacker capabilities and economic impact. This approach enables us to identify systemic design failures in the firmware lifecycle rather than isolated vulnerabilities. A structured comparison with prior work is provided in Table III, highlighting that our approach uniquely combines firmware analysis, mining-specific modeling, attack scenario construction, and cross-vendor coverage.

A PPENDIX B E XTENDED COMPARISON WITH RELATED WORK Prior work on firmware security and cryptocurrency mining follows two largely independent directions, which we detail below to highlight the gap addressed by our contribution. Large-scale firmware analysis has demonstrated that publicly available firmware images enable scalable vulnerability discovery without requiring physical access to devices [6]. This approach has been extended with dynamic analysis and emulation frameworks such as Firmadyne, Firm-AFL, and P2IM [7], [8], [9], allowing deeper exploration of runtime behaviors and vulnerability classes. More recent surveys further systematize extraction techniques and common weaknesses in embedded firmware ecosystems [10], [11]. However, these works remain domain-agnostic and do not consider the specific constraints, attack surfaces, or economic incentives of cryptocurrency mining infrastructures. In particular, they do not model firmware update workflows as a primary attack vector, nor do they relate findings to concrete attacker objectives. In parallel, prior work on cryptocurrency mining security has primarily focused on protocol and network-level threats. Several studies analyze weaknesses of the Stratum protocol, including man-in-the-middle attacks, hashrate redirection, and share manipulation [12], [13], [14], [15]. Other works investigate routing-level attacks on mining pools or largescale cryptojacking campaigns [16], [29], [28]. While these works provide valuable insights into network-level threats,

A PPENDIX C F IRMWARE ARCHITECTURE IN DETAILS We describe the firmware architecture of a cryptocurrency miner by decomposing it into its main software and hardware components, following the abstraction introduced in Figure 1. • Boot: Early boot stage responsible for initializing the platform and transferring control to the system initialization logic. • Init: System initialization phase configuring hardware and preparing the runtime environment. • Operating System (OS): Embedded system (typically Linux) providing core services such as process management, networking, storage, and hardware abstraction.

17

Libraries: Shared components providing reusable functionalities, including cryptography, networking utilities, and system helpers. • Miner: Core application implementing the proof-of-work algorithm and orchestrating hashing operations on the hardware. • Blockchain / Mining Pool: External endpoint used to receive mining jobs and submit computed shares (e.g., via Stratum). • Web Server: Embedded interface exposing graphical monitoring and configuration capabilities. • Control Console: Optional interface enabling remote or fleet-level management. • API: Programmatic interface allowing automated configuration, monitoring, and integration with external systems. • Firmware Update: Mechanism responsible for installing firmware images or partial updates and enforcing the associated trust model. • Debug Interfaces: High-privilege access mechanisms, either software-based (e.g., SSH) or physical (e.g., UART), used for maintenance and diagnostics. • Hardware Components: Underlying platform including SoC, memory, networking interfaces, and sensors hosting the firmware stack. • ASIC Chips: Dedicated hardware executing hashing operations under the control of the miner software.

2024: S21E XP HYD 430T, S21 XP Hydro, S21+, S21 Immersion 300T, S21E XP Hyd 3U, S21 Pro, AL1 Pro, AL1, S21 XP, DR7, L9 17.6Gh, L9 16Gh, KS5 Pro, KS5, S21 Hydro, S21. 2023: T21, KS3, X5, S19K Pro (115Th), S19j XP, Z15 Pro, S19k Pro, E9 Pro, D9. 2022: HS3, K7, S19j Pro+, S19 XP Hydro, KA3, E9, S19 XP, S19 Pro+ Hyd, S19 Pro Hyd, L7. 2021: Z15e, L7 9500Mh, L7 9300Mh, L7 9160Mh, L7 9050Mh, DR5 (35Th), D7, S19j Pro (96Th), S19j Pro (104Th), S19j Pro (110Th), S19j Pro (100Th), S19j (90Th). 2020: Z15, T19, S19 Pro, S19 (95Th), K5, T17+ 55Th, S17 Pro 59Th, S17+ 67Th, T17+ 58Th, T17 42Th, S17+ 70Th. 2019: T17+ 64Th, S17+ 73Th, S17+ 76Th, S9 SE 17Th, T17e, S17e 64T, S17e 60T, S17 59Th, Z11J, Z11E, S9k, S9 SE 16Th, S17 Pro 56Th, T17 40Th, S17 Pro 50Th, S17 Pro 53Th, S17 56Th, S17 53Th, Z11, B7. 2018: DR5 (34Th), T15 (eco mode), T15, S15 (eco mode), S15, D5, S11, Z9, S9j 14.5T, S9 Hydro, E3, S9i, L3++, B3, X3, V9, A3, T9+. 2017 and earlier: L3+, S9, T9, R4, S7-LN, S7, S5, S3.

•

MicroBT WhatsMiner. 2025: M79S, M78S, M76S+, M76S, M76, M73S+, M73S, M73, M72S, M70S+, M70S, M70. 2024: M66S++, M63S++, M60S++, M61S, M66S+, M63S+, M60S+. 2023: M66S, M66S Hydro, M66, M66 Hydro, M66s, M63S, M63S Hydro, M63, M63 Hydro, M63s, M60, M60S, M53S+, M56, M56S, M56 Hydro, M36S+, M53s, M53, M53S Hydro, M53 Hydro, M50s++. 2022: M33s++, M50, M50s. 2021 and earlier: M32s, M32, M31s+, M31s, M30s+, M30s++, M30s, M20 45T, M20S 65T, M20S 68T, M20s, M21, M21S 56T, M21S 58T, M21s, D1, M10, M10s, M10S, M3X, M3. Canaan Avalon. 2026: A16XP-300T, A16-282T. 2025: A1566HA 2U, Q, A15Pro-221T, A15 Pro 218T, Nano 3S, Mini 3. 2024: A15XP 206T, 1566, A1566I, A1366I, Nano 3. 2023: 1466, A1446. 2022: 1366, 1346. 2021: 1126 Pro, 1246 85T, 1246 (90Th). 2020: 1246 96T, 1166 PRO 78Th, 1166 PRO 72Th, 1146 Pro, 1146, 1166. 2019: 1066, 1047, 911, 852. 2018: 921, 1126, 841, 821. 2017 and earlier: 741, 1.

A PPENDIX D C HRONOLOGICAL L ISTING OF ASIC M INERS BY M ANUFACTURER To improve readability and highlight temporal trends in the ASIC mining ecosystem, we group commercially available mining devices by manufacturer and release year, listing model names without algorithmic or performance details. Models are color-coded according to the most impactful attack scenario achievable under a LAN threat model, following a worst-case ordering (red > orange > yellow > blue > black) : full device takeover, cryptocurrency theft and revenue redirection, physical degradation and hardware damage, and performance degradation and operational disruption. This classification is restricted to attackers with network access to the miner environment. Outside this model, all devices are exposed to firmware phishing and plaintext Stratum V1 attacks, which enable at least revenue redirection, and would therefore place all miners in the orange category at least. As a reminder, this categorization by scenario should be taken with caution since it is not impossible that the vulnerabilities found in the update packages are not present or are disabled on the real models.

IceRiver. 2025: ALEO AE3, ALEO AE2, ALEO AE1 Lite (250MH), ALEO AE1 Lite (300MH), ALEO AE0, KAS KS7, KAS KS7 Lite. 2024: KS2 Lite, AL2 Lite, AL3, RX0, ALPH AL0, KS0 Ultra, KS5M, KS5L. 2023: KS0 Pro, KS1, KS2, KS3, KS3L, KS3M, KS0.

A PPENDIX E D EEPER A NALYSIS OF R ECENT F IRMWARE Issue

File

Partial signature verification of update arti- sbin/updateproc.sh facts. Unsalted MD5 password hashing. www/pages/cgi-bin/passwd.cgi lib/lighttpd/mod_auth.so Runtime-enabled Dropbear SSH service. etc/init.d/S50dropbear Legacy services (Telnet, FTP, TFTP) sup- etc/services ported. Status endpoint leaks runtime information. lib/lighttpd/mod_status.so Cookies missing HttpOnly. lib/lighttpd/mod_usertrack.so Legacy SSH algorithms enabled. sbin/dropbear Table IV V ULNERABILITIES IDENTIFIED BY STATIC ANALYSIS IN B ITMAIN MINERS .

Bitmain Antminer. 2026: U3S23H. 2025: U2L9H, S21 Immersion 239T, L11 Hyd 2U, L9 Hyd 2U, L11 Hyd 6U, L11 Pro, L11, S21e Hyd (310Th), S23 Hyd 3U, S23 Hyd, S23 Immersion, S23, KS7 40T, S21e Hyd, S19 XP+ Hyd, S21+ Hydro, S21 XP+ Hyd, E11.

18

Issue

Issue

File

SSH service enabled at boot time.

File

SSH activation via temporary file trigger. /tmp/dropbear_on SSH config allows password auth and root etc/config/dropbear login. MD5 password hash with weak defaults. etc/shadow Bootloader integrity verified via external etc/uboot.md5 checksum only. Table VI V ULNERABILITIES IDENTIFIED BY STATIC ANALYSIS IN M ICRO BT MINERS .

usr/sbin/sshd etc/init.d/S50sshd Default SSH configuration with limited etc/ssh/sshd_config hardening. Authentication secrets stored in the root etc/shadow filesystem. OpenSSH linked against legacy OpenSSL usr/sbin/sshd 1.1.1. usr/lib/libssl.so.1.1 Privileged CGI actions without explicit administrator.html CSRF protection. reboot.html networkcfg.html Table V V ULNERABILITIES IDENTIFIED BY STATIC ANALYSIS IN C ANAAN MINERS .

Issue

File

Legacy password hashing (unsalted MD5). bg/linux-*/bin/authpass HTTP Digest authentication using MD5. bg/linux-*/obj/httpLib.o Cookies missing HttpOnly. bg/web/js/login.js Client-side dynamic code execution via bg/web/js/translate.js eval. Unsafe C string functions (sprintf, bg/controllers/user.c strcpy). Table VII V ULNERABILITIES IDENTIFIED BY STATIC ANALYSIS IN I CERIVER MINERS .

This section presents a deeper, targeted analysis of cryptocurrency miner firmware, focusing exclusively on recent and actively deployed models. While the previous sections provide a large and longitudinal view of the ecosystem, the goal here is to evaluate the current security posture of one modern devices per manufacturer. A. Bitmain

We begin with Bitmain by anThe vulnerabilities are summarized in Table VI. alyzing a recent firmware image, The flash-resident firmware contains configuration files and Bitmain_2025-11-19_FR-1.27_251009-S19XP_2B_Hyd initialization scripts for several system components. However, , corresponding to an Antminer S19 XP Hyd device. executable binaries for core libraries and services (e.g., SSH We first perform a file-level static analysis to identify daemon, cryptographic libraries, standard C library) are not concrete implementation weaknesses affecting update verifipresent in the extracted flash image. As a result, component cation, authentication mechanisms, and exposed services. The versions cannot be reliably recovered through static analysis. resulting vulnerabilities are summarized in Table IV. We deliberately avoid inferring versions from indirect traces In addition, we extract and enumerate the main embedded or configuration artifacts. software components and their versions in order to characterize the underlying software stack and assess its reliance on legacy D. Iceriver components: We analyze Iceriver through a static analysis of the embedded web management stack, the only firmware component available as a standalone artifact. The vulnerabilities are summarized in Table VII. To characterize software obsolescence, we enumerate the runtime components and versions explicitly present in the web stack: B. Canaan • Embedthis Appweb 4.x (embedded web server and ESP We analyze a Canaan Avalon 15 firmware update package framework) : • glibc 2.2.5–2.4 (legacy symbol versions referenced by Canaan Avalon 15xHY release OTA 2025111202 773bb92.aup binaries) The vulnerabilities are summarized in Table V. The embedded • Jansson 4.11.0 (libjansson.so.4.11.0) software stack includes: • lighttpd 1.4.32 • BusyBox v1.29.3 • Dropbear SSH 2018.76 • GNU libc (glibc) 2.25

• libstdc++ 6.0.24 • U-Boot 2016.07 • OpenSSL 1.1.1 (early)

• BusyBox v1.33.0 • OpenSSH (sshd) 8.3p1 • GNU libc (glibc) 2.33 • OpenSSL 1.1.1i • libstdc++ GLIBCXX 3.4.28 (CXXABI 1.3.12) C. MicroBT We analyze a MicroBT firmware flash image corresponding to a WhatsMiner device. This analysis is restricted to flashresident firmware components. Parts of the firmware image are encrypted, and additional software components are provisioned later through the update mechanism.

19

MITM Stratum

Find a target

Download the update firmware of the target

Unzip, Decrypt ...

Vulnerabilities analyze

Target a method

Firmware update phishing

Attack from the internal network

Figure 8. Attacker pipeline from initial access to final objectives.

Check if no trace of stratumv2 our stratumv1 + ssl/tls

Enumerate all miners from a vendor

Download all update firmwares and other documents from this vendor

Unzip, Decrypt ...

Vulnerabilities analyze (research on strings)

Sort to keep only the necessary stuff For each miner

Figure 9. Analysis pipeline.

20

Verified manually all the firmware vulnerabilities

Check if sensible to firmware update phishing

Check the worst attack scenario and which goal it permits

Conclude on the security of a miner

Related documents

• The Complexity Kink: A Prompt-Side Structural Complexity Index for Code-Generation Reliability#978496
• Semantic Layer Induction from Raw Telemetry via Hierarchical LLM and RAG Abstraction#978497
• The Output-Space Hypothesis: Enumerative Equivalence Checking for Tensor Programs#978498
• DeltaSelect: Affordable A/B Testing for Coding Agents#978499
• Code-as-Auditor: Executable Compliance Reasoning via Regulation-to-Code#978500