Mining Firmware Security: Official Sources, Verification & Infection Response

There is a firmware file on your desktop right now — named for your miner, pulled from a page that looked official — and your cursor is over the flash button. Before you press it, answer one question: can you prove where that file came from? Authenticity is established by provenance, and provenance has three checkable parts: the file came from the vendor’s official channel, it matches a vendor-published hash where one exists, and on signed-firmware Antminers the machine itself refuses images Bitmain didn’t sign. A mining firmware image runs with total control of a machine that earns money and sits on your network. In January 2019, thousands of Antminers were locked by malware that spread through exactly this moment — owners flashing “overclock” firmware from unofficial downloads. This page is the decision layer for that moment. It walks the three situations a miner owner actually faces: you haven’t downloaded yet, you have the file and are about to flash, and you think a miner is already infected — with the official channel for every major vendor, what each vendor actually gives you to verify against, and the recovery path that ends with a machine you trust again.

Jump to: what a bad file costs · before you download · the mirror problem · before you flash · signed firmware · suspected infection · firmware you can read

Sixty seconds of history: what a bad file costs

Three documented incidents define the threat model, and none of them is hypothetical.

hAnt, January 2019. Malware spread through third-party “overclocking” firmware for the Antminer S9, T9 and L3+, downloaded from unofficial sources. Infected machines displayed a ransom demand — pay 10 BTC, or the malware would spread to more devices — and threatened to overheat the hardware. Chinese industry reporting put the infection count in the thousands of rigs across large farms. The recovery that worked was not negotiation: it was an SD-card reflash with clean firmware, machine by machine (Supported: contemporaneous reporting by 8BTC and security outlets).

The fake Bitmain shop, 2021. Kaspersky documented a phishing campaign that lured buyers through Google Docs notification emails to a professionally built clone of the Bitmain site on a lookalike domain, selling “in stock” Antminer S19j units at market price, crypto-only payment, with a countdown timer for pressure (Verified: Kaspersky’s published writeup). The writeup documents the scam storefront itself — and the technique is the point: Bitmain-brand clone sites are professionally executed businesses, and the same clone playbook is how unofficial firmware circulates.

Antbleed, 2017. Even factory firmware has earned scrutiny: stock Antminer firmware was documented to contain a remote-shutdown capability, disclosed publicly in 2017 and subsequently patched by Bitmain (historical). Independent researchers have since shown that ASIC firmware images can be unpacked and audited from the outside — serhack’s 2019 teardown “Unpacking ASIC firmware: AntMiner Exploited” is the reference work, and this page stands on that shoulders-of-giants tradition of public auditing rather than repeating its exploit detail.

The pattern across all three: the attacker’s door is provenance, not cryptography. Nobody broke SHA-256 — someone offered a better-sounding download. Bitmain’s own security guidance says the same thing from the vendor side: do not install firmware not provided by Bitmain, “especially firmware claiming to help overclock S9 or T9 series miners” (Supported: Bitmain support, virus-prevention article). Unofficial “performance” builds have historically been the carrier — hAnt rode one in — and that generalization needs no named accusations to be useful.

The record, in one table — incidents with credible public sourcing, not forum accusations. It is short, which is itself informative: the pattern repeats.

Path 1 — You haven’t downloaded yet: go to the one right place

The single highest-value habit in mining firmware security costs nothing: never reach a firmware download through a search result, a marketplace listing, a forum attachment, or a link someone sent you. Bookmark the vendor’s official channel once, verified carefully, and only ever download from the bookmark. The malware and scam incidents in the section above began with a plausible-looking link.

Here is the official channel for each major vendor, and — because this varies more than most owners expect — what each vendor publishes that lets you verify a file after download:

Two nuances worth pinning. First, what makes a link official is where you found it, not what it looks like. Braiins’ Academy install docs link some legacy SD images through Google Drive folders — visually indistinguishable from anyone’s file share, official because the link originates on academy.braiins.com (Verified). Second, the inverse: a GitHub organization full of open-sounding repo names is not automatically a source channel — Braiins’ own GitHub org hosts 90+ open-source tool repos and distributes no firmware binaries there (Verified); Bitaxe’s org is the opposite, the only channel there is. Learn your vendor’s actual shape once, then stop trusting appearances.

The mirror problem: many “official” sites, one vendor

Search for firmware for any popular Antminer model and most of what ranks is download portals — some rehosting real files, some impossible to trace to any vendor at all. For at least one major firmware vendor, the situation is starker: multiple live vnish-branded domains each present themselves as the official site, with mutually incompatible claims — at most one lineage can be genuine. VNish’s own advisory exists precisely for this problem: it names vnish.group, vnish.us, vnish.cn and vnish.es as the only four official domains, and acknowledges that users searching for the official site “may face some difficulties” (Verified: vnish.group official-sites page, fetched 2026-08-13; the advisory’s behavioral tells are quoted in the table above). Bitmain has published its own version of the same warning, a “Statement Regarding Fraudulent Websites” declaring that sites using Bitmain’s name and logo without authorization are not Bitmain channels, and that bitmain.com is the only official website (Supported: Bitmain support article).

We are deliberately not naming any third-party download site as malicious — a rehost may carry an untouched file. That is exactly the problem: you cannot tell. A rehosted binary with no vendor hash to check against is unverifiable, and unverifiable is a “no” for a file that gets total control of a revenue-producing machine. The vendors’ own advisories above are the security lesson; this page just asks you to act on them.

Path 2 — File in hand: verify it before it touches a miner

You downloaded from the official channel. Now prove the bytes you hold are the bytes the vendor published. Whether you can depends on the vendor — the table above tells you which of three cases you are in.

Case 1 — the vendor publishes verification material (Braiins). Compute the SHA-256 of your file and compare, character for character:

• Linux: sha256sum firmware-file.tar.gz
• macOS: shasum -a 256 firmware-file.tar.gz
• Windows (PowerShell): Get-FileHash .\firmware-file.tar.gz -Algorithm SHA256

1. Action: run the command for your OS on the downloaded file. You should see: a 64-character hexadecimal fingerprint. What it proves: nothing yet — it is your file’s fingerprint, waiting to be compared.
2. Action: compare it against the SHA-256 published beside that exact asset on the official release listing. You should see: an exact match, every character. What it proves: your file is byte-identical to the file the vendor published. A mismatch by even one character means it is not the published file — delete it and re-download from the official channel. Do not flash a mismatch, ever, and do not “try it anyway to see.”

Braiins goes further than the hash: its main download page also publishes a GPG public key (braiins-os.gpg.pub) with the instruction to verify the image signature by GPG — the hash proves your bytes match the archive listing; the GPG signature ties the release to Braiins’ own key. The hands-on GPG workflow is in our firmware verification guide.

Case 2 — the assets live on GitHub Releases (Bitaxe, ePIC). Neither project ships its own checksum file, but GitHub computes a SHA-256 digest for every release asset and displays it on the release page (it is also in the release API’s digest field). Open the official release page, expand the asset’s digest, and compare it against your locally computed hash exactly as above (Verified: digests present for ESP-Miner v2.14.2 assets). This verifies your download against GitHub’s copy — which, combined with the org identity (bitaxeorg, epicblockchain) being the canonical channel, is the practical authenticity story for these projects.

Case 3 — no published reference exists (Bitmain, VNish, LuxOS). Honesty over ritual: computing a hash with nothing official to compare it against verifies nothing. For these vendors your verification is the channel — the bookmark discipline from Path 1, plus each vendor’s own mechanisms: Bitmain’s on-device signature check rejects tampered or unofficial images at install time (next section), VNish publishes behavioral tells (dev-fee ceiling, monitoring compatibility), and LuxOS is delivered through the vendor’s own tooling rather than loose binaries. One genuinely useful hash habit remains even here: record your file’s SHA-256 when you download it. You cannot prove it authentic, but you can prove later that the file you flashed is the file you downloaded — which matters on the day something goes wrong.

Signed firmware: when the miner itself checks the file

Since 2019, Bitmain has shipped generations of “security firmware” whose defining features are a firmware signature function and disabled SSH — positioned by Bitmain as protection against “illegal ways of hacking the miners, blocking the channels of virus transmission and remote attacks” (Supported: Bitmain’s ANTMINER Security Firmwares Q&A). The observable behavior on those units: signed release filenames end with “sig,” installing security firmware is one-way — downgrade is not possible — and uploading an unsigned image fails with “System upgrade failed – signature not found!!!” The original Q&A generation covered the S17, T17, S17 Pro, S15, T15, S9, S9i, S9j, L3+, DR5 and Z11 (Supported). Third-party tooling documents the same everyday symptom as “Firmware installation failed – missing signature” (Supported: Awesome Miner support docs).

The lock has since tightened. Starting March 2024, Bitmain shipped Amlogic control boards with firmware locks that block third-party firmware installation entirely — S19/S21-series units with post-03/2024 Amlogic boards need a documented unlocking procedure before Braiins OS+, VNish or LuxOS can be installed (Supported: third-party vendor compatibility notes; Bitmain does not document the lock dates itself). And stock firmware released after September 2025 reportedly locks the SD-card downgrade path and disables the micro-USB port (Supported, same sourcing). We track every one of these events, per vendor and per generation, on the ASIC firmware lock & security event tracker — check it before assuming anything about your unit’s generation.

Read the signature check honestly, because it cuts both ways. When you meant to flash stock firmware and the miner rejects a file with a signature error, that is the system working — the machine just refused an image Bitmain never signed, which is precisely what it would do to a trojaned one. When you chose custom firmware, the same mechanism is the wall between you and your own hardware — the trade-off we examine in The Amlogic Lock: why Bitmain can brick your miner. Both statements are true at once; a security feature and a lock-in mechanism can be the same code. The same architecture has now reached small miners too: some ESP32-class clone hardware ships builds with flash-level Secure Boot V2 signing — see the Hammer Miner firmware page for a documented case, established by our own reverse-engineering.

Path 3 — You think a miner is infected

Modern infections rarely announce themselves with a ransom screen the way hAnt did. On S19/S21-generation hardware the tells are quieter, and two of them are near-definitive:

• A pool you never configured — typically appearing as a third pool entry, sometimes visible only in the configuration file rather than the dashboard. Your machine is paying someone else with your electricity.
• Configuration that reverts after reboot — you correct the pool settings, reboot, and the foreign entry is back. Something with more persistence than the web UI is rewriting them.
• Supporting signs: pool-side hashrate persistently below what the dashboard reports; credentials that stop working; SSH or web UI behaving differently than stock.

The same tells, as a triage table:

If you see the first two, stop treating it as a configuration problem. Here is the decision path:

1. Isolate first. Disconnect the machine from the network before anything else, and treat every miner on the same network segment as suspect until individually checked — infections in mining farms have historically not stayed on one machine. Our guide to identifying and isolating infected miners covers the containment step in detail.
2. Do not “clean” a running infection through its own web UI and call it done. A compromised firmware controls what its own interface shows you and what an upgrade appears to do. The trustworthy recovery on this class of hardware is the one that worked against hAnt: wipe and reflash from SD card with a verified image, so the machine boots from bytes you control rather than bytes the infection controls. The procedures live in our ASIC miner virus prevention and removal guide and the older but still-relevant infected ASICs walkthrough.
3. The recovery image must itself pass Paths 1 and 2. This is the loop that closes the page: an infection recovery performed with an unverified image from a rehost site is not a recovery, it is a reinstall. Official channel, hash check where one exists, signed image where the platform enforces it.
4. After reflash: change the miner’s passwords, rotate pool credentials, confirm the pool list is yours, and watch pool-side hashrate for a few days — the symptom that found the infection is also the cheapest monitor for its return.

The auditability angle: firmware you can read

Everything above is defense under information asymmetry: with closed firmware, provenance discipline is the only tool you have, because nobody outside the vendor can read what an image does. Open-source firmware does not make discipline unnecessary — you still verify what you download — but it changes what is knowable. Security events happen in public: when ESP-Miner shipped a CSRF fix in v2.5.0, it landed as a visible changelog entry in an auditable codebase — disclosure and fix in the open, the process working as designed. The ESP-Miner/AxeOS stack that runs the Bitaxe is fully open; Mujina, the 256 Foundation’s GPL-licensed multi-vendor firmware, extends the same principle toward industrial hardware; and our own DCENT_OS is GPL-3.0 with a 0% default dev fee — its signing and security model is documented on the DCENT_OS firmware security page. To be plain about what we are not saying: closed firmware is not malicious by nature, and the established closed vendors run real release engineering. The difference is who can check — and after sixty seconds of the history at the top of this page, “who can check” is the whole subject. Survey the landscape in our open-source mining firmware options guide and the open-source mining registry.

Record last verified: 2026-08-13. Vendor channels, checksum practices, and every quoted advisory string were re-checked against the live vendor pages on that date.

Mining firmware security questions

How can I tell if an Antminer firmware file is fake?

Usually not by looking at the file — a repackaged image can be visually identical to a real one. Authenticity is established by provenance: the file came from the vendor’s official channel (for Bitmain, the service.bitmain.com download portal reached from bitmain.com), it matches a vendor-published hash where one exists, and on signed-firmware Antminers the machine itself will refuse images Bitmain didn’t sign. If a file arrived through a search ad, marketplace, forum or chat link, treat it as unverifiable and re-download from the official channel instead.

Where do I download official Antminer firmware?

From Bitmain’s own download portal at service.bitmain.com/support/download, reached from bitmain.com via Customer Support → Firmware Download and selecting your model. Bitmain’s published fraud statement names bitmain.com as its only official website. Firmware for the same models offered anywhere else is a rehost at best — and with no Bitmain-published reference hash confirmed, there is no way to verify a rehosted copy after the fact.

How do I verify a firmware download with SHA-256?

Compute the file’s hash — sha256sum file on Linux, shasum -a 256 file on macOS, Get-FileHash .\file -Algorithm SHA256 in Windows PowerShell — and compare it character-for-character against the official reference: Braiins publishes a SHA-256 beside every asset on downloads.braiins.com and a GPG public key with verify-by-GPG instructions on its main download page, and GitHub-hosted projects (Bitaxe’s ESP-Miner, ePIC) carry a platform-computed SHA-256 digest on each release asset. Any mismatch means the file is not the published file: delete and re-download. VNish and LuxOS publish no reference hashes, so for those the verification is using the official channel itself.

What are the signs my ASIC miner’s firmware is infected?

The two strongest signs on modern hardware: a pool entry you never configured (often a third pool, sometimes visible only in the config file), and settings that revert after every reboot despite you correcting them. Supporting signs include pool-side hashrate persistently below the dashboard’s number and login credentials that stop working. Any one of these justifies isolating the machine from the network immediately and checking its neighbors.

How do I remove malware from an ASIC miner?

Isolate the miner from the network, then wipe and reflash it from SD card with a verified firmware image — do not trust a “clean-up” performed through the compromised firmware’s own web interface, which the infection controls. The recovery image must come from the vendor’s official channel and pass whatever verification exists for it (published SHA-256, GPG signature, GitHub digest, or the miner’s own signature check). Afterward, change passwords, rotate pool credentials, and monitor pool-side hashrate. Step-by-step procedures are in our ASIC miner virus prevention and removal guide.

Is custom mining firmware safe to install?

Established custom firmware from the vendor’s official channel is a different risk class from a random “performance” build on a download portal — the documented malware incidents rode unofficial rehosts and too-good-to-be-true overclock images, not official releases. Judge safety by checkable facts: an official channel you can bookmark, a published dev-fee schedule, verification material (Braiins publishes per-asset SHA-256 and a GPG key; open-source projects add auditable source), and honest install documentation. On post-March-2024 Amlogic Antminers, note that installing any third-party firmware first requires a documented unlock — see our firmware lock tracker for your model’s current state.

Does signed Bitmain firmware protect against malicious images?

Against tampered install images, yes: signed-firmware generations refuse anything Bitmain didn’t sign, failing with “signature not found” at install time, and downgrade off signed firmware is blocked. That is a genuine backstop — and the same mechanism also blocks legitimate third-party firmware, which is why the lock landscape (2019 security firmware, the March 2024 Amlogic lock, post-September-2025 SD restrictions) matters to buyers. We track it event by event on the ASIC firmware lock tracker.

Why does my Antminer say “signature not found” when I flash?

Your miner is running Bitmain security firmware, which only accepts images Bitmain has cryptographically signed — the stock error is “System upgrade failed – signature not found!!!” (some tools report it as “missing signature”). If you were flashing an official stock image, get the file for your exact model from Bitmain’s portal; note signed generations also refuse downgrades. If you were flashing third-party firmware, the signature check is the lock working as designed — on post-March-2024 Amlogic boards a documented unlock procedure is required first, covered on our ASIC firmware lock tracker.

Related pages

• How to verify mining firmware authenticity: SHA-256 and GPG guide — the hands-on companion to Path 2
• ASIC firmware lock & security event tracker — per-vendor signing and lockdown events, kept current
• The Amlogic Lock: why Bitmain can brick your miner
• ASIC miner virus prevention and removal guide — the procedures behind Path 3
• Identify and isolate infected miners on your network
• Infected ASICs: a growing menace
• DCENT_OS firmware security — how our own firmware handles signing and verification
• Mining firmware comparison 2026 — choosing between the firmwares this page teaches you to obtain safely