Restore Stock Firmware on an ASIC Miner: Safe Downgrade Guide

Three different jobs share one name, and picking the wrong one is how people lose a weekend. A factory reset clears your settings and leaves the firmware exactly where it is. A revert takes the firmware off and puts the manufacturer’s back on. An unbrick is what you do when the machine is already dark. This page is about the middle one — the deliberate, planned return to factory firmware, and the downgrade that usually comes with it — and about the two questions nobody in this corner of the web answers straight: can you actually get back, and is the “stock” file you found really stock?

It is a decision layer, not a procedure. The mechanics of writing an SD card, per model and per control board, are already covered in exhausting detail in our SD card firmware flashing and recovery guide, and the install side lives in the Antminer firmware update guide. What is missing everywhere — including on our own site until now — is the layer above them: which operation you actually want, whether the vendor documents a way back at all, what the reversal destroys, and how to tell whether the file in your downloads folder deserves to touch a miner.

Status labels used throughout this page.   Verified quoted from the vendor’s own documentation or measured directly.   Supported credible, but not stated outright by a primary source.   Unknown nobody has published it, and we are not guessing.

Jump to: three jobs, one name · does this unit stay reversible? · the way back, firmware by firmware · where the answer is no · what going back costs · proving a stock image is stock · other manufacturers · questions

Three jobs, one name

Search for “reset my Antminer” and you will get answers to all three of these, mixed together, usually without anyone saying which one they are describing. They are not interchangeable. One of them keeps your firmware, one replaces it, and one assumes it is already broken.

The clearest statement of the first row comes from a firmware vendor rather than from us, and it is worth quoting because it is the sentence most of the web gets backwards. Braiins documents that a factory reset “returns your miner’s configuration to its defaults while keeping Braiins OS installed” — the firmware does not change, the version does not change, only the configuration goes back to defaults. Verified (Braiins Academy, factory-reset documentation, re-checked 2026-08-14.) The same page carries a warning that applies to all three rows above: “A factory reset cannot be undone. Back up any configuration you want to keep before continuing.” Verified

Credit where it is due: of the firmware vendors surveyed for this page, Braiins is the only one that draws that line explicitly in its own documentation. That is a documentation standard worth naming, not a competitive slight.

The practical test. If your miner is running VNish, LuxOS, Braiins OS+, Hiveon or ePIC and you perform a factory reset, you will still be running VNish, LuxOS, Braiins OS+, Hiveon or ePIC afterwards — at the same version, with the same dev fee, minus your settings. If the reason you pressed the button was “I want this firmware off my machine,” a reset was the wrong button.

Model-specific reset procedures already live in the error-code library, and they are a different job from this page: Antminer factory reset procedure · WhatsMiner button reset.

Before you flash: does this unit stay reversible?

Restoring the manufacturer’s image is one flash. Whether you can ever go the other way again depends on which manufacturer image you land on. Two firmware vendors publish dated compatibility rules, and they agree with each other.

HashCore — the documentation portal for the firmware long sold as VNish, published as “from the creators of the legendary Vnish” — publishes a compatibility timeline keyed to the stock build’s release date. Verified

The vendor adds its own risk note: “Firmwares from September 2025 and newer may be completely incompatible with current methods.” Verified And separately: “Factory Bitmain firmwares (released after March 2024) often include protection: disabled SSH and prohibition of third-party software installation.” Verified

Luxor draws the line in the same place from the other side of the industry. Its LuxOS compatibility page states that remote installation is required for machines with CVITEK control boards, and for any machine with Bitmain firmware dated March 2024 or newer. Verified Braiins reaches the same conclusion architecturally: its Amlogic page is a remote installation guide consisting of VPN setup, an IP-range scan and coordination with vendor support — an assisted procedure, not a self-service one. Verified

We track the lock landscape event by event on the ASIC firmware lock and security event tracker, and the ownership argument behind it is in The Amlogic Lock. If you do not know which control board is in your machine, start at which Antminer control board do I have? — the answer changes the media, the method and the risk.

The documented way back, firmware by firmware

Every row below is a path the vendor itself publishes. Where a vendor publishes nothing, the cell says Unknown and stays that way. We are not going to infer a procedure for a machine that costs more than a car, and an unlabelled guess on a page about provenance would be self-defeating.

Braiins OS+ — the cleanest reversal on the board

On the S9 and S17 generations, Braiins OS+ can be run entirely from the SD card, and the vendor is unusually explicit about what that means for reversibility: “The internal memory is kept intact and Braiins OS does not alter it in any way. After the SD card is removed, the stock firmware will boot, with all the previous settings.” Verified (Braiins Academy installation documentation, fetched 2026-08-14 — the sentence appears three separate times, once each for the S9/S9i/S9j and S17 sections.) That is the least destructive reversal any vendor offers on this list: your settings survive because your stock firmware was never touched.

For the S19 and S21 series the vendor’s tool does it in bulk. The Braiins Toolbox command is firmware restore, documented as a way to “batch uninstall aftermarket firmware. The device will return to running the factory firmware without the user having to take any further action.” Verified The published syntax takes IP addresses, concurrency and credentials — no factory image is listed as something you supply.

The honest gap, published rather than papered over. “Without the user having to take any further action” implies the factory image is either retained on the device or supplied by the tool. Braiins does not say which, and we are not going to guess. Unknown The same applies to the optional internal-storage install on the S9 — the install guide describes overwriting internal storage and does not state that a backup of the original firmware is taken first. Do not assume a backup exists on the machine. If you are planning to reverse later, the SD-card route is the one with a documented, guaranteed way back. Models outside the S19 and S21 series are not addressed by the uninstall page at all. Unknown

LuxOS — one API call, and three honest gaps

Luxor publishes a dedicated uninstall command in the LuxOS miner API. It “uninstalls LuxOS from the miner and restores stock firmware”, takes a valid session ID as its parameter, and returns immediately with status code 350 while the uninstall continues in the background. Verified The call is issued to the miner on TCP 4028, the same port the rest of the miner API uses, and the same operation is available through Luxor’s Commander interface. Verified

Worth stating precisely because it is unusual: the command page publishes no supported-model list, no prerequisites and no warnings. Unknown That is an observation about the documentation, not a promise about your machine — and the origin of the stock image the command restores is not stated either. Because the command returns immediately while the work continues in the background, there is no documented success signal other than watching the miner come back. Plan for that, and do not cut power because the API answered quickly.

Luxor separately publishes a per-model SD recovery library covering S19 Vanilla, S19 XP, S19j Pro, S19j Pro+, S19j XP, S19k Pro, S21, S21 Pro and T21 across Xilinx, Amlogic, BeagleBone and CVitek variants Verified — a useful cross-check on which board and model combinations that vendor considers serviceable at all.

Two points of canon while you are here, because both get misreported constantly and both bear on why people leave: LuxOS collects a 2.8% dev fee, always — the benefit of pointing a LuxOS miner at Luxor’s own pool is free pool fees, which is not a dev-fee waiver. Verified And LuxOS is the one third-party firmware that genuinely flashes MicroBT hardware. Verified

VNish / HashCore — two paths that behave very differently

VNish firmware is now published under the HashCore brand, and the authoritative technical documentation lives on the HashCore documentation portal rather than on the older marketing site. Two reversal paths exist and they are not equivalent.

The miner menu. The vendor’s own FAQ states the firmware allows rollback to the stock firmware version in one click, directly from the miner menu. Verified Where that stock image comes from is not stated. Unknown

The Toolkit. The fleet tool carries an explicit “downgrading or restoring factory firmware” procedure, and here the provenance question lands squarely on you: the vendor’s instruction is to “Select and download the appropriate firmware for your miner”, then “Copy the firmware files to the SD card or USB drive”. Verified The vendor also documents which media works with which board family: “boards with an Amlogic processor may require an OTG adapter and flashing via Micro-USB, while boards with Xilinx and CVITEK processors can be flashed via the SD card slot.” Published media limits are SD cards up to 16 GB or USB drives up to 8 GB, USB 2.0 recommended. Verified

Their warning is the most consequential sentence in this whole section, and it is the reason we do not treat a revert as a casual operation: “Do not interrupt the installation or restoration process by disconnecting power or removing the media. This can lead to damage to the low-level software, and recovery will then only be possible at a service center.” Verified A restore is not a moment to test a marginal PDU. What the restore preserves or erases is not stated anywhere in that procedure. Unknown

On the warranty claim, publish the hedge, not the headline. The vendor states its firmware “leaves no traces” in the system when correctly reverted, which “theoretically” might help preserve the warranty — and the same documentation states plainly that “Installation of any third-party software, including Vnish, technically constitutes grounds for voiding the factory warranty.” Verified (Both the vendor’s own words.) Those two sentences belong together. The second one is the operative fact.

One correction worth making, because it is widely repeated backwards: there is no priced licence for this firmware. The vendor’s own structured data prices the product at zero, and across the whole documentation portal there is no pricing, licence or activation page. Verified The dev fee is the monetisation — a developer commission of 2–2.8% of hashrate redirected to the developers’ pool, which “may vary in real time but remains within the limits specified in the agreement.” Verified An unlicensed install is not a crippled install. If you are reverting because you believed you were running a hobbled unlicensed build, that premise was wrong, and the decision may deserve a second look.

The CVitek behaviour that changes what “revert” means

On CVitek control boards, the vendor documents something that reads like a bug and is actually a platform behaviour: during a normal reboot the device “may spontaneously revert to the factory software”, and a background scanner service is required for custom firmware to survive across restarts. Verified (Corroborated by the Toolkit’s own “restart CV firmware on detection” setting, which exists to automatically restore custom firmware when it is found missing after a scan.)

Read it in both directions. If you are trying to keep custom firmware on a CV board, this is why it keeps disappearing. If you are trying to get back to stock, the platform is already working in your favour. And if a miner you restored is running the old firmware again the next morning, the restore probably worked and a scanner re-flashed it — stop the service or take the miner off that management network before you conclude the procedure failed.

ePIC — where the honest answer involves a screwdriver

ePIC ships two things and they have very different reversal stories. UMC OS as firmware runs on a range of Antminer S19x and S21 models; the UMC Control Board is separately described by ePIC as “a proprietary replacement control board for Antminer S19x and S21 series miners”. Verified The product page also documents tuning modes, the UMC V5 control-board bundle, a dev fee of 1.5% on mining rewards for the firmware-only product (reduced in January 2026), and its own warranty position: “Installing custom Antminer firmware, including UMC OS, typically voids the Bitmain hardware warranty — consistent with all third-party Bitcoin mining firmware solutions.” Verified

What that page does not publish: an uninstall path, a revert-to-stock procedure, a recovery procedure, or SD-card guidance. Unknown That is a statement about what is published, not a claim that it cannot be done, and we are not going to invent one. If you are on ePIC firmware and want to leave, the supported move is to ask ePIC. For units running on the replacement control board, the route back to factory condition is refitting the original Bitmain control board, which is a hardware operation rather than a flash — that last sentence follows from the vendor’s own description of the hardware bundle rather than from anything ePIC spells out. Supported

Hiveon — Unknown, and we are going to say Unknown

Hiveon’s ASIC firmware product page lists its supported models and its performance claims, and documents the benefits of installing and nothing about removing: no uninstall procedure, no revert-to-stock guidance, no recovery instructions, no SD-card guidance and no dev-fee figure. Unknown In this pass we could not reach a Hiveon documentation host at all: the help subdomain did not resolve, the knowledge-base path returned 404, and the sitemap was unavailable from two different network routes.

That is not a claim that Hiveon firmware cannot be removed. It is a statement that we could not find the vendor documenting how, and we would rather publish that than invent a procedure. Our locked position on the fee is unchanged by that page: up to 3% on S19-generation hardware, and Unknown for S21 and T21. We would rather publish Unknown than round a competitor’s number.

Where the answer is no

This is the section the rest of the web leaves out, because “no” does not sell anything. Six cases, all of them real, all of them sourced.

No 1 — Bitmain “security firmware” is a one-way door

Bitmain has shipped generations of security firmware whose defining features are a firmware signature check and disabled SSH. Installing it is documented as one-way: downgrade is not possible, and an unsigned image fails with a signature error. The original vendor Q&A generation covered the S17, T17, S17 Pro, S15, S9, S9i, S9j, L3+, DR5 and Z11. Supported (Bitmain’s security-firmware Q&A, as recorded in our mining firmware security pillar.)

If your unit is on that firmware, an older stock build is not available to you through any vendor-documented route. Plan around it rather than hunting for a way through it.

No 2 — Amlogic boards on recent stock firmware

Two independent firmware vendors document the same progressive closure of Bitmain’s stock firmware, from different angles and with different dates. Luxor requires remote installation for any Bitmain firmware dated March 2024 or newer. Verified HashCore publishes a dated compatibility timeline that goes further: for Amlogic control boards running FR 1.20 firmware and newer — the class of stock firmware released from late September 2025 onward — SSH is blocked, as is the ability to downgrade via SD card. Verified

For a reader on that firmware the honest answer is: there is no vendor-documented software path back to an earlier build, and the machine should be treated as fixed to its current firmware line. For the background on how the lock came to exist and what it means for ownership, see The Amlogic Lock.

No 3 — a signature error is the system working

This one deserves saying out loud, because it is the exact moment a reader goes looking for a workaround. When you meant to flash stock firmware and the miner rejects the file with a signature error, the machine just refused an image the manufacturer never signed — which is precisely what it would do to a tampered one. The mechanism cannot tell the difference between “a stock file that is not really stock” and “a stock file that has been modified,” and that is the whole point of it.

The correct next step is a better file, not a different method. Go back to provenance. The same check that is standing between you and a five-minute flash is the check that would stand between a compromised image and your fleet.

No 4 — reverting does not un-void a warranty

Every vendor surveyed states, in its own documentation, that installing third-party firmware is grounds for voiding the factory warranty. The strongest counter-claim any of them makes is that a correct reversal “leaves no traces” and “theoretically” might help — and a hedge that size is the vendor telling you not to rely on it. Whether a manufacturer honours a warranty on a machine that ran third-party firmware is the manufacturer’s call, and neither we nor the firmware vendor can promise it. Unknown Plan for the machine to be out of warranty and be pleasantly surprised.

Plan the reversal for the reasons that actually hold up: ending a dev fee, returning a unit to a known and documented state before it changes hands, restoring the factory performance envelope, or removing firmware you no longer trust. A warranty claim is not one of them.

No 5 — where the electrical conditions are not right

The vendor warning bears repeating in its own words: interrupting a restore “can lead to damage to the low-level software, and recovery will then only be possible at a service center.” Verified A restore writes to flash. Do not run one on a circuit that browns out, on a PSU you already suspect, or on a machine with an intermittent power connector. Fix the power first.

No 6 — where the miner is already broken

If it does not boot, does not get an IP, or shows hashboard faults, a firmware revert is not the fix and may destroy your evidence. A reversal will not repair hardware. Diagnose first — ASIC troubleshooting, the control-board recovery playbook and bricked miner recovery are the right doors. Model-specific reversal faults are already catalogued: Antminer S9 downgrade issues · WhatsMiner M60S rollback failed · IceRiver downgrade / rollback · Goldshell downgrade / rollback.

And if the machine is genuinely beyond a software fix, that is a repair conversation. D-Central runs an ASIC repair operation out of Montreal and works on control boards, hashboards and PSUs; a board damaged by an interrupted flash is a normal thing to send in rather than a lost cause.

What going back costs you

Erased outright: pool and worker configuration, the dashboard password, fleet-monitoring enrolment, any custom fan curve or schedule, and every tuning result the firmware derived. Luxor’s own recovery documentation puts the practical version of this plainly: once the miner is back online, no pools will be configured. Write down your pool URLs, worker names and static IP before you start, not after. Expect the web-interface password to be back at the manufacturer default, and change it immediately — default credentials on mining hardware are actively scanned for.

The part people underestimate. A tuning profile is not a settings file you can copy back. Modern autotuners calculate voltage and frequency at runtime from a scan of the specific hardware in front of them, which is why two units of the same model settle on different numbers. The values are derived, not preset. The vendor’s own model table makes the shape of this concrete: it publishes chips and voltage domains per model — an S19 Pro is listed at 114 chips across 38 domains. Those are the vendor’s own numbers, and they refute the marketing line that voltage is controlled chip by chip: voltage on these machines is regulated per power domain, not per chip. Verified What you lose in a reversal is therefore a measurement of your machine, not a preference. Re-deriving it means running the tuner again: VNish documents its autotune as a 3 to 4 hour process that runs without additional reboots. Verified

What you get back: factory hashrate, factory efficiency, factory power draw, and a machine in the state the manufacturer describes. The dev fee stops — stock firmware from all three major manufacturers takes none, and that is often the whole point of the exercise. If the purpose of the exercise was a resale, a return, or a clean baseline for diagnosing something, that is exactly the outcome you wanted. If the purpose was more hashrate, this was the wrong page — see the firmware comparison.

And the part that is not recoverable at all: whether custom firmware can be reinstalled later depends entirely on which stock build you land on. That is the irreversible decision, and it is why the reversibility section comes before this one.

Proving a “stock” image is really stock

Authenticity is established by provenance, and our mining firmware security pillar sets the definition this site works to: 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 the manufacturer did not sign. One half is not provenance. This section applies that definition to one narrow class of file that is served badly everywhere — stock images — and does not restate the mechanics. The hands-on hashing and signature workflow is in the firmware verification guide.

What “stock” means, by manufacturer

“Stock” is not one thing. It is a specific build, and each manufacturer names builds differently — which determines how precisely you can even describe what you are restoring.

Now the hard part. Which exact stock build shipped on your specific unit is, for most machines, unknowable after the fact. Unknown Once custom firmware has overwritten it, the original build string is gone unless you recorded it. If you are about to install custom firmware and think you may ever want the machine back to its stock rather than a stock, write down the firmware version from the miner’s status page first. It costs ten seconds and it is unrecoverable afterwards.

What each manufacturer gives you to check against

• Bitmain publishes no reference file hashes we can point you at. Unknown Computing a SHA-256 of a Bitmain image and having nothing official to compare it against verifies nothing about authorship — it is a ritual, not a check. What Bitmain does have on the generations that enforce it is the on-device signature check, and that is a genuinely stronger guarantee than a hash published on a web page, because the verifier is the machine rather than the website. Signed release filenames carry a sig marker; on those units, the flash either succeeds or the image was not signed by the manufacturer. Verified
• MicroBT publishes no authenticity mechanism for the firmware image, and the documented update flow contains none: the protocol sends a four-byte length prefix and then the raw file, with the only verification being to read the version string back afterwards. Verified Whether BTMiner checks a signature internally is Unknown — we are stating what is published, not what the device does in private.
• Braiins publishes a SHA-256 for each release asset and a GPG public key with instructions to verify the image signature — the strongest verification story of any industrial mining firmware vendor we have surveyed. Verified Naming that is not an endorsement of their firmware; it is a statement about their release engineering, and it is the standard the rest of the field should be held to.
• Canaan publishes the miner application firmware source and binds version strings to commits, which means a build can in principle be reproduced and compared. Verified Read the licence carefully: the current miner firmware is released under BUSL-1.1, which makes it source-available — not an OSI-approved licence, with a four-year cliff to GPLv3 and commercial use requiring a Canaan licence. The controller is a Kanzhi K230 carrying two RISC-V cores. Verified Check the licence file before assuming redistribution rights.
• HashCore / VNish offers an MD5 checksum published on its website. Verified Our own reading, stated as ours and not theirs: MD5 detects a corrupted download, not a substituted one. It is a transport-integrity check. Treat a matching MD5 as evidence the transfer worked, not as evidence of who built the file. Supported

Provenance is a spectrum, and it is fair to say so without any adjectives about anybody: public source with commit-bound versions is stronger than a published signature, which is stronger than a checksum on a web page, which is stronger than nothing published at all. That ordering is derived entirely from what each vendor documents about its own product.

The redistribution problem, with a receipt

A stock image hosted by a firmware vendor, a reseller, a repair shop or a forum is a copy. It may be a perfectly good copy. You cannot tell, because there is nothing published to compare it against.

Here is the concrete case, and it is not hypothetical. Luxor’s own SD-recovery knowledge base publishes per-model, per-control-board recovery pages, and the S21 Amlogic page links a “stock recovery image” for a Bitmain miner, hosted on a Google Cloud Storage bucket, with no checksum, hash or signature published alongside it. The page states its purpose: to downgrade the miner to a build older than March 2024, so that Luxor’s installer can subsequently install LuxOS. Verified (Luxor SD-recovery documentation, fetched 2026-08-14.)

That is a completely reasonable engineering decision for their install flow. It is also a different operation from “restore my miner to factory condition,” and the difference matters:

A “stock” image can be old stock, chosen precisely because old stock is still open to third-party installation. Reverting with it does not return your machine to the manufacturer’s current firmware or its current security posture. It returns it to whichever build happened to suit somebody else’s installer. Nobody in that search result tells you this, and it is the single most useful thing on this page.

Our own archive, described honestly

D-Central keeps an archive of firmware images, recovery images and manufacturer service documents, some of them for machines whose original download pages no longer exist. It is genuinely useful for exactly the situation this page describes — restoring an older stock build, on hardware nobody is publishing files for any more. It contains manufacturer artefacts we did not author. By the definition above, that puts us in the same category as the sites this section is describing, so here is our position without softening:

• Go to the manufacturer first. Our archive is a mirror and not a channel, we do not present it as one, and it exists because a repair bench needs known-good files on hand, not because we are a distribution point.
• We publish a SHA-256 for every file we host, computed by us, so you can prove the copy you downloaded is byte-identical to the copy we are serving. What that proves: the file has not changed since we mirrored it. What it does not prove: that the manufacturer authored it. A hash from us is integrity, not authenticity. Those are two different claims and we are not going to blur them into one reassuring sentence.
• Where we cannot establish where a file originally came from, we publish its source as Unknown. We do not infer a vendor URL from a filename, because a fabricated provenance link on a provenance page would be worse than no page at all.
• Where a manufacturer’s signature check exists, that is the check that matters — more than our hash, and more than anyone else’s. The miner is a better verifier than any web page, including this one.
• The archive is excluded from search indexes. It is a bench resource, not a destination.

The full record — every file, its SHA-256, and exactly what we can and cannot establish about where it came from — is published at the firmware mirror provenance record. The vendor-channel directory, which is where you should start, is official ASIC firmware channels.

If that reads as an awkward admission, it is meant to. Everyone ranking for “restore stock firmware” is redistributing something. The difference we are proposing is not that we do not mirror — it is that we tell you exactly what our hash proves and exactly where our knowledge stops. Where a manufacturer’s own channel still serves the file you need, use the manufacturer’s channel. Use an archive when the alternative is a forum attachment with no hash at all.

Other manufacturers, briefly

Whatsminer / MicroBT

Third-party firmware for Whatsminer exists, but it is narrow. LuxOS flashes ten M50 and M60-generation miner types Verified (from Luxor’s own compatibility table), and ePIC supports Whatsminer through a replacement control board rather than as firmware alone. Verified Braiins, Hiveon and VNish/HashCore are Bitmain-only, each stated on the vendor’s own supported-models page. For most Whatsminer models in the field the honest answer is still “stock only” — but “Whatsminer is stock-only” as a blanket sentence is wrong, and any page still saying it needs updating. Model-level update, recovery and custom-firmware detail is in our WhatsMiner firmware guide; if you are not sure which generation you own, start at the M-series decoder.

Avalon / Canaan

No third-party firmware vendor supports Avalon — five separate vendor pages exclude it, and none of them is ambiguous. Verified There is nothing to revert from, which makes this the simplest row on the board: what you have is what the manufacturer shipped, and updates go forward rather than sideways.

What Canaan does have is unusual enough to credit. It publishes the source of its current miner application firmware, ships per-generation developer documentation, and openly documents its own warranty-voiding “privileged” tier rather than pretending it does not exist. The licence precision above applies here too: source-available under BUSL-1.1 is the accurate description, and it is not the same thing as an OSI-approved licence. Firmware update procedure: our AvalonMiner firmware upgrade guide, and the architecture is decoded on the Avalon A-series page.

Bitaxe and open-source hardware

Reverting is barely a category here. The firmware is public, releases are published with a platform-computed SHA-256 for every asset, and “stock” is simply a tagged release you can re-flash whenever you like. That is what provenance looks like when it is designed in rather than bolted on.

DCENT_OS, our own firmware, is GPL-3.0 with public source and takes no dev fee. Its supported hardware is deliberately narrow — Zynq/Xilinx S9 and S19j Pro class Verified — and we hold ourselves to the standard this page applies to everyone else, so our own exit is documented and linked rather than buried: Uninstall DCENT_OS — restore stock firmware covers the exit doors by how the firmware was installed, and DCENT_OS rollback and UART recovery covers the serial-console route. For an SD-card trial the uninstall is removing the card. Firmware you cannot leave is not firmware you own.

Credit where it is owed: the SD-boot and control-board recovery techniques this whole category rests on were worked out by the open-source mining community long before any of the current firmware vendors productised them.

Restore-to-stock questions

Is a factory reset the same as restoring stock firmware?

No. A factory reset clears your configuration and leaves the installed firmware exactly where it is — Braiins documents its own reset as returning the configuration to defaults “while keeping Braiins OS installed.” If third-party firmware is on the machine before a reset, it is still there afterwards, at the same version and with the same dev fee. Restoring stock firmware is a separate operation that replaces the firmware itself.

How do I remove Braiins OS+ and get my Antminer back to stock?

It depends how it was installed. If Braiins OS+ is running from an SD card — the usual arrangement on the S9 and S17 generations — the vendor states that internal memory is untouched, so removing the card and power-cycling boots the original stock firmware with your previous settings intact. For S19 and S21 units the vendor’s Braiins Toolbox provides a firmware restore command that returns the device to factory firmware. Where that factory image comes from is not stated by the vendor: Unknown. Models outside the S19 and S21 series are not covered by that page, and it does not say whether a copy of your original factory image is stored on the machine — do not assume one is.

How do I uninstall LuxOS?

Luxor publishes an uninstallluxos command in the LuxOS miner API, issued to the miner on TCP 4028 with a valid session ID. It is documented as uninstalling LuxOS and restoring stock firmware, and it returns immediately while the uninstall continues in the background — so do not cut power just because the command answered. The same operation is available in Luxor’s Commander interface. Luxor does not publish a supported-model list, prerequisites or warnings for that command, and the origin of the restored stock image is not stated.

Does VNish put the original Bitmain firmware back for me?

Partly, and it depends on the path. The vendor’s FAQ describes a one-click rollback to stock from the miner’s own menu, without saying where that image comes from. The HashCore Toolkit path is explicit that you supply the file: its documented procedure is to select and download the appropriate firmware for your miner, then copy it to an SD card or USB drive. Amlogic boards may need an OTG adapter and Micro-USB; Xilinx and CVitek boards use the SD slot. The vendor also warns that interrupting a restoration can damage low-level software, leaving service-centre recovery as the only option.

Can I downgrade an Antminer that is running Bitmain security firmware?

No, not by any vendor-documented route. Installing Bitmain security firmware is documented as one-way, and unsigned images are rejected with a signature error. Separately, Amlogic control boards running the FR 1.20 firmware line and newer have SSH blocked and SD-card downgrade disabled, per a firmware vendor’s own compatibility documentation. Treat those machines as fixed to their current firmware line and plan around it.

My Antminer says “signature not found” when I flash stock firmware. What now?

That message means the miner refused an image the manufacturer did not sign, which is exactly what it would do to a tampered file. It is the protection working, not an obstacle to route around. Get the file from the manufacturer’s own channel and try again. If you cannot obtain a signed image for your model, the honest conclusion is that this path is closed for that unit rather than that a workaround is needed.

Is the “stock” firmware file on a firmware vendor’s website safe to use?

It is a copy, and you cannot verify it, because manufacturers of industrial miners generally publish no reference hashes to compare against. There is a second problem that is less obvious: at least one firmware vendor publishes a Bitmain “stock recovery image” whose documented purpose is to move the miner to a build older than March 2024, so that their own installer will work. A stock image can be deliberately old stock. Reverting with it does not put you on current factory firmware.

Does going back to stock restore my warranty?

Assume not. Every vendor surveyed states in its own documentation that installing third-party firmware is grounds for voiding the factory warranty. The strongest counter-claim on offer is one vendor’s statement that a correct reversal “leaves no traces” and “theoretically” might help — a hedge that size is the vendor telling you not to build a plan on it. Reverting before service is often possible, but it is not universal and it does not restore a voided warranty. Revert for reasons that hold: ending a dev fee, restoring a known state, or removing firmware you no longer trust.

Related pages

• Mining firmware security — the provenance definition this page applies, plus infection response.
• Firmware verification guide — running SHA-256 and GPG checks step by step.
• Firmware mirror provenance record — every file we host, its hash, and where our knowledge stops.
• Official ASIC firmware channels — the per-vendor directory of where the real downloads live.
• SD card firmware flashing & recovery guide — the mechanics behind every media-based path above.
• Antminer firmware update guide — every model, every method, in the other direction.
• ASIC firmware lock & security event tracker — can you still flash this model, event by event.
• Which Antminer control board do I have? — the answer changes the media, the method and the risk.
• ASIC control-board recovery playbook — if a restore stops halfway.
• Firmware update failed — bricked miner recovery — for when this stopped being a planned reversal.
• Resetting a miner to factory settings — the settings reset, which is a different operation.
• Firmware types explained — what each category commits you to.
• Mining firmware comparison — fees, licence boundaries and support matrices, if you are choosing where to go next.
• WhatsMiner firmware guide — update, recovery and the narrow third-party support that genuinely exists.
• Uninstall DCENT_OS — our own exit door, documented to the same standard.

Record last verified: 2026-08-14. Every vendor procedure quoted on this page was re-checked against the live vendor documentation on that date. Where a vendor publishes nothing, this page says Unknown rather than filling the gap.