SD Card Firmware Flashing & Recovery Guide for ASIC Miners

When Your Miner Goes Dark: The SD Card Recovery Guide

There is a moment every ASIC miner operator dreads. You power on your machine and nothing responds. No web interface. No hashrate. Maybe the LEDs blink in a pattern you have never seen before (check our Antminer error code reference). Maybe the fans spin up and the machine sits there, endlessly rebooting. Maybe you tried a firmware update and it failed halfway through. Your miner is bricked.

A bricked miner is not a dead miner. In the vast majority of cases, the hardware is perfectly fine — the hashboards, the ASIC chips, the power delivery, the cooling system — all intact. What broke is software. The firmware on the control board’s NAND flash memory became corrupted, incomplete, or overwritten with something the bootloader cannot execute. The miner’s brain is scrambled, but the body is untouched.

This is where SD card firmware recovery enters the picture. By writing a known-good firmware image to a MicroSD card and booting the control board from it, you bypass the corrupted internal flash entirely. The miner loads firmware from the SD card, and from there you can either run directly off the card or reflash the internal NAND to restore permanent operation. It is the nuclear reset button for ASIC miners — the procedure that turns a $3,000 paperweight back into a hashing machine.

SD card recovery is one of the most common procedures we perform at D-Central Technologies. Across 2,500+ miners repaired since 2016 in our Laval, Quebec facility, firmware-related issues account for a significant percentage of all repair tickets. Failed updates, malware infections, power-loss-during-flash incidents, and botched custom firmware installations — we see them all, daily. This guide distills that experience into a comprehensive manual covering every major ASIC platform: Antminer (S9 through S21), Whatsminer (see our Whatsminer error code reference), and open-source miners like Bitaxe and NerdAxe.

Common Causes of Bricked Miners

Understanding how firmware gets corrupted helps you prevent it from happening again — and helps you diagnose whether SD card recovery is the right solution:

• Interrupted firmware update — Power loss during a web interface firmware flash is the single most common cause of bricked miners. The NAND flash ends up with a partially written image that the bootloader cannot execute.
• Flashing wrong firmware version — Installing firmware meant for a different control board type (e.g., Xilinx firmware on an Amlogic board, or S19 firmware on an S17) corrupts the boot partition.
• Malware / firmware virus — Compromised firmware downloaded from unofficial sources can overwrite critical system partitions, redirect hashrate to attacker pools, and prevent legitimate firmware from being installed via the web interface.
• Failed alternative firmware installation — Botched Braiins OS+, VNish, or LuxOS installations that abort partway through can leave neither the old nor new firmware functional.
• NAND flash degradation — The NAND flash chips on control boards have limited write cycles. Older miners (S9, L3+) that have been reflashed dozens of times may experience NAND wear that causes boot failures.
• Corrupt configuration — Sometimes the firmware itself is intact but the configuration partition is corrupted, causing boot loops. This is common after sudden power losses during mining operation (not during updates).
• Unauthorized modifications — SSH-level changes to system files, custom scripts that modify boot sequences, or root filesystem modifications that break critical services.

What You Need

Before you start any firmware recovery procedure, gather everything on this list. Nothing derails a recovery faster than discovering mid-procedure that your SD card is the wrong size or your card reader does not work.

SD Card Requirements by Model

This is critical — using the wrong size SD card is one of the most common reasons recovery fails. The control board’s bootloader expects specific partition layouts, and cards that are too large or too small will not be recognized.

Understanding Control Boards

The control board is the brain of your ASIC miner. It runs the firmware, communicates with the hashboards, manages the pool connection, and provides the web interface you use for configuration. Different control board types require different recovery procedures, different firmware files, and sometimes different tools entirely. Before you attempt any recovery, you must identify your control board type.

Xilinx (Zynq) Control Boards

Xilinx Zynq-based boards are found in the Antminer S9, T9/T9+, L3+, S17/T17 series, and early S19 models (C55 and C71 board variants). The Xilinx Zynq is an SoC that combines a dual-core ARM Cortex-A9 processor with programmable FPGA logic. The ARM core runs Linux and the miner’s web interface, while the FPGA handles the high-speed communication with ASIC chips on the hashboards.

Identifying a Xilinx board is straightforward. Look for:

• An external MicroSD card slot — usually located next to the Ethernet RJ45 port
• A Xilinx-branded chip on the board (often marked XC7Z010 or XC7Z020)
• On S9/L3+ boards: the classic green PCB with an SD slot, Ethernet port, and 2-pin reset button
• On S17/T17 boards: a slightly larger board with a similar layout but different connector configuration

Amlogic Control Boards

Amlogic-based boards use the Amlogic A311D or S905D3 SoC and are found in late-production S19 models, the S21 series, and T21 series. These boards represent Bitmain’s shift away from Xilinx — likely for cost reasons, as the Amlogic SoCs are significantly cheaper than Zynq parts.

The critical difference for recovery: Amlogic boards typically do not have an SD card slot. Instead, they have a Micro USB port on the front of the control board. Recovery is performed using the Amlogic USB Burning Tool on a Windows computer, connected via Micro USB cable. This is fundamentally different from the SD card process and requires its own section in this guide.

Identifying an Amlogic board:

• Micro USB port visible on the front of the control board (instead of or in addition to an SD slot)
• Usually found in miners manufactured 2022 or later
• May have the Amlogic chip visible (marked A311D or S905D3)
• Check your miner’s firmware version string — Amlogic boards often show aml in the version identifier

BeagleBone Black (BBB) Control Boards

Some mid-production S19 models (late 2021 through 2022) use a control board based on the Texas Instruments AM335x SoC — the same processor used in the BeagleBone Black single-board computer. These boards have an internal MicroSD slot located on the underside of the board, inside the miner enclosure. You must open the miner to access it.

BBB boards accept SD card recovery, but the firmware image format is different from Xilinx boards. You need the specific BBB recovery image for your exact S19 variant.

Quick Board Identification Guide

For a detailed visual identification guide with photos of every control board type, see our Antminer Control Board Identification Guide.

Downloading Official Firmware

The firmware file is the most critical component of this entire process. Flash a legitimate image and your miner comes back to life. Flash a compromised image and you have just installed a backdoor on your own hardware that silently steals your hashrate. This is not paranoia — it is the reality of mining in an adversarial environment.

Official Firmware Sources

Understanding Firmware File Types

Manufacturers distribute firmware in different formats depending on the intended update method. Using the wrong format is a common mistake:

• .tar.gz — Compressed archive. This is typically the web interface update format. You upload this file through the miner’s web dashboard. It is not for SD card imaging (unless the manufacturer specifically says it is for the SD card recovery method for that particular model).
• .img / .img.gz — Raw disk image. This is the SD card recovery format. You write this to the SD card using balenaEtcher or dd. It overwrites the card’s entire filesystem structure, including partition table.
• .zip — Compressed container. May contain either a .img file (extract first, then flash) or a set of files to be copied to a FAT32-formatted card (Whatsminer style).
• .swu — MicroBT’s update package format for Whatsminer firmware updates via the web interface.
• .bin — Binary firmware file. Used in some older recovery methods and for Amlogic USB Burning Tool.

SD Card Preparation

A successful firmware recovery starts with a properly prepared SD card. Skipping steps here is the number one reason experienced miners fail at what should be a routine procedure.

Step 1: Format the SD Card

Even if the card is new, format it first. Cards may have hidden partitions from previous imaging operations that interfere with the flash process.

For raw image flashing (Antminer S9/S17/S19 Xilinx/BBB):

If you are using balenaEtcher or dd, the imaging tool overwrites the entire card including the partition table. Technically, pre-formatting is not strictly necessary — but we recommend formatting anyway to verify the card is functional and writable before committing to a 10-minute write operation.

For file-copy methods (some Whatsminer, some S9 recovery methods):

The card must be formatted as FAT32. Windows’ built-in format tool does not offer FAT32 for cards larger than 32GB — use the SD Card Formatter tool by the SD Association (free download) or a tool like Rufus that can force FAT32 on larger cards.

# Identify your SD card device (BE CAREFUL — wrong device = data loss)
lsblk

# Unmount if mounted (replace sdX with your device letter)
sudo umount /dev/sdX1

# Format as FAT32
sudo mkfs.vfat -F 32 /dev/sdX1

# Or wipe and create fresh partition table + FAT32 partition:
sudo wipefs -a /dev/sdX
sudo parted /dev/sdX mklabel msdos
sudo parted /dev/sdX mkpart primary fat32 1MiB 100%
sudo mkfs.vfat -F 32 /dev/sdX1

Step 2: Write the Firmware Image

balenaEtcher is the recommended tool for writing raw .img files to SD cards. It is free, cross-platform (Windows/macOS/Linux), validates the write after completion, and is nearly impossible to misuse. Download it from etcher.balena.io.

Using balenaEtcher:

1. Insert the MicroSD card into your card reader
2. Open balenaEtcher
3. Click “Flash from file” and select the firmware .img file (you can select .img.gz files directly — Etcher handles decompression)
4. Click “Select target” and choose your SD card — verify the drive letter and size match your card, not your hard drive
5. Click “Flash!” and wait for the write and validation to complete
6. When Etcher shows “Flash Complete!” the card is ready

Alternative: Using dd on Linux/macOS:

# Identify your SD card (look for the card's size to confirm)
lsblk

# Unmount all partitions on the card
sudo umount /dev/sdX*

# Write the image (replace firmware.img with your actual filename)
# bs=4M sets the block size for faster writes
sudo dd if=firmware.img of=/dev/sdX bs=4M status=progress conv=fsync

# Sync to ensure all data is written
sync

# On macOS, use /dev/rdiskN instead of /dev/diskN for faster writes:
sudo dd if=firmware.img of=/dev/rdisk2 bs=4m

Alternative: Using Win32 Disk Imager on Windows:

1. Download and install Win32 Disk Imager
2. Run as Administrator
3. Select the firmware .img file (extract from .gz or .zip first — Win32 Disk Imager does not handle compression)
4. Select the drive letter corresponding to your SD card
5. Click Write and confirm
6. Wait for completion — do not eject the card until the tool reports success

Step 3: Verify the Write

After imaging, do not assume the write succeeded. balenaEtcher automatically verifies, but if you used dd or Win32 Disk Imager:

• Eject and re-insert the SD card
• If Windows asks you to “format the drive” — that is normal for raw Linux images. Click Cancel. The card is correctly written; Windows simply cannot read the Linux filesystem.
• On Linux, you can verify with: sudo dd if=/dev/sdX bs=4M count=1 | hexdump -C | head — you should see filesystem signatures, not all zeros.

Antminer S9 / T9 / L3+ Recovery (Xilinx Boards)

The S9 family (including T9, T9+, and L3+) uses the oldest and most straightforward SD card recovery process. These machines have been around since 2016 and the process is well-documented and reliable. The Xilinx Zynq control board has an external MicroSD slot that is easy to access without opening the miner.

Firmware File Naming for S9/L3+

The S9’s bootloader is particular about file naming. Depending on the recovery method, you may need files named in a specific way on the SD card’s root directory. Two methods exist:

Method 1: Raw Image Flash (Recommended)

Download the official SD card recovery image (.img file) from Bitmain’s support site. Flash it to the card using balenaEtcher. This method creates the correct partition structure and file layout automatically. No file renaming needed.

Method 2: File Copy (Legacy Method)

Some older recovery instructions call for formatting the card as FAT32 and copying specific files to the root directory. For the S9, the bootloader looks for specific filenames:

• boot.bin — First-stage bootloader (FSBL)
• devicetree.dtb — Device tree blob
• uImage — Linux kernel image
• uramdisk.image.gz — Root filesystem (ramdisk)

These files must be in the card’s root directory with exact filenames — no extra extensions, no subfolders. If the recovery package comes as a .zip, extract it and copy all files to the card root.

Step-by-Step S9/T9/L3+ Recovery

1. Power off the miner completely. Disconnect the PSU power cable. Wait 10 seconds for capacitors to discharge.
2. Locate the MicroSD slot on the control board. On the S9, it is on the front panel next to the Ethernet port and the small IP Report button.
3. Insert the prepared MicroSD card into the slot. Push until it clicks into place. The card’s label should face upward (contacts face down).
4. Locate the reset/IP Report button next to the SD card slot. On some S9 boards, there is also a small jumper or dip switch that must be set to boot from SD card. Check your specific board revision:
   • On most S9 boards: simply inserting the SD card and powering on is sufficient — the bootloader checks the SD card first automatically
   • On some board revisions: you may need to hold the IP Report button (small tactile switch) while powering on, then release after 5 seconds
   • On rare early revisions: a jumper near the SD card slot must be moved to the “SD” position
5. Connect the Ethernet cable to the miner’s control board.
6. Power on the miner. Reconnect the PSU power cable.
7. Wait 3–5 minutes. The miner will boot from the SD card. The green and red LEDs on the control board will blink during the boot process. Do not power off during this time.
8. Scan your network for the miner’s IP address. Use your router’s DHCP client list, Advanced IP Scanner, or the Bitmain IP Reporter tool.
9. Access the web interface at the miner’s IP address. Default credentials: username root, password root.
10. Flash the internal NAND from within the web interface. Navigate to System > Upgrade and upload the standard firmware .tar.gz file. This writes the firmware to the internal NAND flash so the miner can boot without the SD card.
11. After the flash completes and the miner reboots, power off, remove the SD card, and power on again. The miner should now boot from internal NAND with clean firmware.

Antminer S17 / T17 Series Recovery (Amlogic/Xilinx Boards)

The S17 and T17 series (S17, S17+, S17e, S17 Pro, T17, T17+, T17e) are notoriously the most problematic Antminer generation. Their control boards are Xilinx-based (similar architecture to the S9) but the recovery process has important differences. These miners also suffer from the highest firmware corruption rates of any Antminer generation — largely due to the well-documented thermal issues that plague S17 hashboards, which cause crashes that corrupt the filesystem.

Step-by-Step S17/T17 Recovery

1. Download the correct SD card recovery image from Bitmain’s support site. The S17 and T17 use different firmware files from each other, and the S17+ uses different firmware from the base S17. Triple-check you have the right file for your exact model variant.
2. Flash the image to a MicroSD card using balenaEtcher. The S17 series requires a raw image flash — the file-copy method used on some S9 recoveries does not work here.
3. Power off the miner completely and disconnect the PSU.
4. Locate the MicroSD card slot. On the S17/T17 series, it is on the control board panel, accessible from outside the miner. The slot is typically next to the Ethernet port, similar to the S9 layout but on a different board form factor.
5. Insert the MicroSD card.
6. Connect the Ethernet cable.
7. Power on the miner. The S17/T17 bootloader automatically checks for a bootable SD card and will boot from it if present.
8. Wait 5–10 minutes. The S17 series takes longer to boot from SD card than the S9. LED indicators:
   • Solid green LED — Normal boot in progress
   • Blinking green — Firmware loading / NAND flash in progress
   • Solid red LED — Error condition (wrong firmware, bad SD card, or hardware failure)
9. Scan for the miner’s IP address and access the web interface.
10. Flash the internal NAND by uploading stock firmware through System > Upgrade.
11. Power off, remove the SD card, and power on to confirm the miner boots cleanly from internal NAND.

S17/T17 Special Considerations

• Thermal damage correlation: If your S17 bricked itself during normal operation (not during a firmware update), the underlying cause is likely thermal — a hashboard overheating triggered a crash that corrupted the filesystem. After recovering firmware, inspect the hashboards for thermal damage before resuming operation. See our S17 Maintenance Guide for diagnostic procedures.
• Repeated corruption: If the S17 keeps corrupting its firmware after successful recovery, the NAND flash chip itself may be degraded. Consider replacing the control board.
• S17 Pro difference: The S17 Pro has a slightly different control board layout. The SD card slot is in the same general area but double-check your specific board revision.

Antminer S19 Series Recovery

The S19 series is where firmware recovery gets complicated. Bitmain used four different control board types across the S19 production run (2020–2023), and each requires a different recovery approach. Before attempting recovery, you must identify your exact control board type using the identification matrix in the control boards section above.

S19 with Xilinx (C55/C71) Control Board

Early S19 models shipped with Xilinx Zynq-based control boards (identified as C55 or C71 board variants). These have an external MicroSD slot next to the Ethernet port, similar to the S9 layout.

The recovery process is nearly identical to the S17:

1. Download the S19 Xilinx-specific recovery image from Bitmain (labeled for C55 or C71 board)
2. Flash to MicroSD using balenaEtcher
3. Power off miner, insert card, connect Ethernet
4. Power on — the bootloader auto-detects the SD card
5. Wait 5–10 minutes for boot, then access web interface
6. Flash internal NAND via System > Upgrade
7. Remove card and reboot

S19 with BeagleBone (AM335x) Control Board

Mid-production S19 models use the BeagleBone-based control board with an internal MicroSD slot. You must open the miner to access it.

1. Download the S19 BBB-specific recovery image (different from the Xilinx image)
2. Flash to MicroSD using balenaEtcher
3. Power off and disconnect all power
4. Open the miner enclosure — remove the fan shroud and access the control board
5. Locate the MicroSD slot on the underside of the control board (you may need to partially remove the board to access it)
6. Insert the prepared MicroSD card
7. Reassemble, connect Ethernet, and power on
8. The board boots from the SD card and either auto-flashes the NAND or provides a web interface for manual flashing
9. After successful recovery, power off, disassemble again, remove the SD card, reassemble, and boot normally

S19 / S21 with Amlogic Control Board (USB Recovery)

Late-production S19 models and the entire S21 series use Amlogic-based control boards. These boards do not have an SD card slot. Recovery is performed via Micro USB cable using the Amlogic USB Burning Tool on a Windows computer.

This is a fundamentally different process from SD card recovery:

1. Download the Amlogic USB Burning Tool — this is a Windows-only application. Bitmain distributes it alongside the S19/S21 firmware recovery packages. It may also be available from Amlogic community resources.
2. Download the correct firmware package for your specific S19/S21 model with Amlogic board. The file is typically a .img that gets loaded into the USB Burning Tool.
3. Install the Amlogic USB drivers on your Windows computer. The USB Burning Tool installer usually includes these drivers, but you may need to install them separately on some Windows versions.
4. Power off the miner completely.
5. Connect a Micro USB cable from your Windows computer to the Micro USB port on the Amlogic control board.
6. Open the USB Burning Tool and load the firmware image file.
7. Power on the miner while connected via USB. The USB Burning Tool should detect the Amlogic board in recovery mode.
8. Click “Start” in the USB Burning Tool. The tool will write the firmware directly to the control board’s internal eMMC storage via USB.
9. Wait for the process to complete — typically 5–15 minutes. Do not disconnect the USB cable or power off the miner during this process.
10. Once complete, disconnect the USB cable and reboot the miner. It should boot with clean firmware.

Antminer S21 Series Recovery

The S21 series (S21, S21+, S21 Pro, S21 XP, T21) exclusively uses Amlogic-based control boards. There is no SD card slot on any S21 model — all recovery is performed via the USB Burning Tool method described in the Amlogic section above.

S21-Specific Recovery Process

1. Obtain the S21-specific firmware recovery package from Bitmain’s support site. Select your exact S21 variant — the S21, S21+, and S21 Pro use different firmware.
2. Install the Amlogic USB Burning Tool and USB drivers on your Windows computer.
3. Power off the S21 and disconnect the PSU.
4. Locate the Micro USB port on the S21’s control board panel. It is typically on the front of the miner, near the Ethernet port.
5. Connect Micro USB cable from your PC to the S21.
6. Open the USB Burning Tool, click File > Import Image, and load the S21 firmware file.
7. Power on the S21. The USB Burning Tool should detect the device within 30 seconds. If it does not detect:
   • Try a different USB cable (data-capable, not charge-only)
   • Try a different USB port on your computer (USB 2.0 ports often work better than USB 3.0 for this)
   • Ensure the Amlogic USB drivers are properly installed
   • Some boards require holding a reset button while powering on to enter recovery mode — check Bitmain’s documentation for your specific batch
8. Click “Start” to begin the flash process.
9. Wait for completion. The tool will report success or failure. On success, disconnect USB and reboot.

S21 Recovery Notes

• No macOS/Linux support: The Amlogic USB Burning Tool is Windows-only. If you only have a Mac or Linux machine, you will need access to a Windows computer (or a Windows VM with USB passthrough) for S21 recovery.
• USB cable quality matters: Cheap Micro USB cables that are designed only for charging (no data lines) will not work. Use a known-good data cable.
• S21 Hydro: Immersion-cooled S21 Hydro models use the same Amlogic board and USB recovery process, but accessing the control board port may require draining the dielectric fluid first.

Whatsminer M30S / M50S / M60S Recovery

MicroBT’s Whatsminer series uses a different recovery architecture than Bitmain’s Antminer. Whatsminer recovery can be performed via SD card or via the WhatsMinerTool desktop application, depending on the model and the severity of the firmware corruption.

Method 1: SD Card Recovery

Whatsminer SD card recovery uses a file-copy method rather than a raw image flash. You format the SD card as FAT32, then copy the recovery package files to the card’s root directory.

1. Download the recovery firmware package for your specific Whatsminer model from MicroBT’s download page. The package is typically a .zip file.
2. Format a MicroSD card as FAT32. Use a card between 4GB and 16GB. Whatsminer control boards have been reported to have issues with cards larger than 32GB.
3. Extract the recovery package and copy all files to the root directory of the SD card. Do not place them in a subfolder. The exact files vary by model but typically include firmware binaries and a configuration file.
4. Safely eject the SD card from your computer.
5. Power off the Whatsminer and disconnect the PSU.
6. Insert the MicroSD card into the slot on the Whatsminer’s control board. The slot location varies by model — on the M30S, it is on the control board accessible from the miner’s back panel.
7. Power on the miner. The control board detects the recovery package on the SD card and begins the firmware recovery process automatically.
8. Wait 5–15 minutes. The miner’s LED indicators will show recovery progress:
   • Slow blinking green — Recovery in progress
   • Solid green — Recovery complete, normal boot
   • Fast blinking red — Recovery failed (wrong firmware, bad card, or hardware issue)
9. Once recovery completes, the miner should be accessible via its web interface at the default IP or via DHCP.
10. Power off, remove the SD card, and power on to confirm normal operation.

Method 2: WhatsMinerTool Recovery

MicroBT provides the WhatsMinerTool — a Windows desktop application that can update and recover Whatsminer firmware over the network. This method requires the miner to be at least partially booting and reachable on the network (even if the web interface is not functional). If the miner is completely bricked and unreachable on the network, use the SD card method instead.

1. Download WhatsMinerTool from MicroBT’s download page.
2. Install and launch the tool on a Windows computer connected to the same network as the miner.
3. Scan for miners — the tool should detect your Whatsminer and display its IP address, model, and firmware version.
4. Select the miner from the list, then navigate to the firmware update/recovery section.
5. Load the firmware file (.swu format for standard updates, or the recovery package for deeper recovery).
6. Initiate the update. The tool handles the transfer and flash process over the network.
7. Wait for completion — typically 10–20 minutes. The tool will report success or failure.

Bitaxe / NerdAxe / Open-Source Miner Recovery

Open-source miners like the Bitaxe, NerdAxe, NerdQAxe, and Nerdminer use ESP32-based microcontrollers, which means firmware recovery is fundamentally different from ASIC miners. There is no SD card involved — firmware is flashed via USB serial connection or web-based flasher.

Bitaxe: Web Flasher Method (Easiest)

The Bitaxe community maintains a web-based firmware flasher that runs directly in your Chrome or Edge browser using Web Serial API. This is the simplest recovery method available for any mining device:

1. Connect the Bitaxe to your computer via USB-C cable
2. Open the Bitaxe web flasher in Chrome or Edge (other browsers do not support Web Serial). The URL is typically listed in the AxeOS repository on GitHub.
3. Click “Connect” and select the Bitaxe’s serial port from the browser dialog
4. Select the correct firmware version for your Bitaxe model (Supra, Ultra, Hex, Gamma, GT)
5. Click “Flash” and wait for the process to complete (typically 1–2 minutes)
6. The Bitaxe will reboot with fresh firmware

Bitaxe / NerdAxe: esptool.py Method (Advanced)

If the web flasher does not work (driver issues, serial connection problems), you can use esptool.py from the command line:

# Install esptool (requires Python 3)
pip install esptool

# Erase the existing firmware completely
esptool.py --chip esp32s3 --port COM3 erase_flash

# Flash the new firmware (replace with your actual firmware .bin file)
# Adjust --port to match your serial port (COM3 on Windows, /dev/ttyUSB0 on Linux)
esptool.py --chip esp32s3 --port COM3 --baud 460800 
  write_flash -z 0x0 firmware.bin

# For Bitaxe models using ESP32-S3 with separate bootloader/partition/app:
esptool.py --chip esp32s3 --port COM3 --baud 460800 
  write_flash 0x0 bootloader.bin 0x8000 partition-table.bin 0x10000 app.bin

For detailed Bitaxe firmware procedures, see our dedicated guides: Bitaxe Supra Setup, Bitaxe Hex Setup, Bitaxe Firmware Update Guide, and Bitaxe Troubleshooting Guide.

Recovering from Malware / Compromised Firmware

Mining malware is a multi-million dollar criminal industry. Compromised firmware variants exist for every popular ASIC miner, and they are distributed through fake download sites, Telegram groups, second-hand miners with pre-installed backdoors, and even compromised legitimate firmware update servers. If your miner has been infected, SD card recovery is the only reliable way to remove the malware.

How to Detect Compromised Firmware

Malware-infected miners often show no obvious symptoms in the web interface. The dashboard may look completely normal while your hashrate is being stolen. Here are the signs to watch for:

• Pool address mismatch: SSH into the miner and check the actual mining process. Compare the pool address and worker name in the running process against what the web interface displays. Malware often shows your configured pool in the web UI while actually mining to a different address.
• Hashrate discrepancy: If your pool dashboard shows significantly less hashrate than the miner’s web interface claims, the difference is being redirected to the attacker’s pool.
• Cannot change pool settings: Some malware variants prevent pool configuration changes — the web interface appears to accept the change but the miner continues mining to the attacker’s pool.
• SSH disabled or password changed: If you cannot SSH into your miner with the expected credentials, and you did not change them, the firmware may be compromised.
• Unexpected outbound connections: Monitor your network traffic. An infected miner will connect to the attacker’s pool server — typically on non-standard ports or to unusual IP addresses.
• Firmware version looks unusual: Check the firmware version string in the web interface. Legitimate firmware shows a recognizable version format. Modified firmware may show an unexpected version string, or the version page may be altered to show a “normal” version while running compromised code.
• Web interface update blocked: If attempting to flash clean firmware through the web interface fails, times out, or appears to succeed but the miner reboots with the same compromised firmware, the malware has likely locked down the web update path. SD card recovery is your only option.

# SSH into the miner (default user: root, password: root)
ssh root@MINER_IP

# Check the running cgminer/bmminer configuration
cat /config/cgminer.conf

# Check the actual running process arguments
ps | grep -E "cgminer|bmminer"

# Look for any pool addresses you did not configure
# Malware typically adds a hidden pool or replaces your primary pool

# Check for modified system files
md5sum /usr/bin/cgminer
# Compare with known-good checksum from the manufacturer

# Check for suspicious cron jobs or startup scripts
crontab -l
cat /etc/init.d/rcS
ls -la /etc/init.d/

For a deeper dive into reading your miner’s diagnostic output, see our Kernel Log Reading Guide.

Clean Flash Procedure for Infected Miners

A standard firmware update through the web interface is not sufficient to remove persistent malware. Advanced malware modifies the bootloader or writes to protected partitions that survive a normal firmware update. The SD card / USB recovery method writes to the entire storage, including the bootloader, which is why it is the only reliable removal method.

1. Download clean firmware from the official manufacturer website (see the official sources table). Verify the checksum if provided.
2. Prepare the SD card / USB Burning Tool as described in the model-specific sections above.
3. Disconnect the miner from your network before powering it on with the recovery media. This prevents the infected firmware from phoning home or spreading to other miners during the brief window before the clean flash completes.
4. Perform the full SD card / USB recovery per your model’s procedure.
5. After recovery, immediately change all credentials:
   • Change the web interface password (default root/root should never be left as-is)
   • Change the SSH password: passwd root
   • Configure your mining pool settings
   • Verify pool configuration by SSHing in and checking the running process (as shown above)
6. Monitor the miner for 24 hours after recovery. Compare the hashrate shown in the web interface against what your pool reports. They should match within normal variance (±5%).
7. Secure your network: If one miner was infected, scan all miners on your network. Malware can spread laterally between miners on the same subnet.

Common Mistakes & Troubleshooting

Firmware recovery is straightforward when everything goes right. When it does not, here are the most common failure points and how to resolve them.

Problem: Miner Does Not Boot After Inserting SD Card

Problem: SD Card Size Issues

Using a 64GB or 128GB MicroSD card is one of the most common mistakes. Many ASIC control board bootloaders cannot read SDXC cards (cards larger than 32GB), because SDXC cards default to the exFAT filesystem which the bootloader does not support. Even if you format a 64GB card as FAT32, some bootloaders still reject it because of the card’s capacity reporting in its internal controller.

Best practice: Keep a few 4GB or 8GB MicroSD cards dedicated for firmware recovery operations. They are cheap, they work with every miner, and having them ready eliminates the most common failure point.

Problem: Windows Says “You Need to Format the Disk”

After flashing a raw .img firmware image to an SD card, reinserting it in your Windows computer will trigger a dialog saying “You need to format the disk in drive X: before you can use it.” This is normal and expected. Click Cancel. The card contains a Linux filesystem that Windows cannot read. The card is correctly formatted for the miner — do not let Windows reformat it.

Understanding LED Indicators During Recovery

During the recovery process, the control board’s LEDs communicate status. Patterns vary by model, but these general patterns are common across most Antminer models:

• Slow blinking green — Normal boot process, firmware loading
• Fast blinking green — Firmware write to NAND in progress (do NOT power off)
• Solid green — Boot complete, miner operational
• Solid red — Error: firmware incompatible, boot failure, or hardware issue
• Blinking red — Repeated boot failure or recovery failure
• Alternating red/green — Self-test or diagnostic mode (varies by model)

If you see a solid red LED after inserting the SD card and powering on, power off immediately, re-verify your firmware file is correct for your exact model and control board type, and try again with a freshly flashed card.

Problem: Recovery Works But Firmware Keeps Corrupting

If your miner successfully recovers from the SD card but keeps corrupting its internal firmware (requiring re-recovery every few days or weeks), the issue is likely one of:

• Degraded NAND flash: The internal storage has worn out from too many write cycles. Common on older S9 and L3+ units that have been reflashed many times. The solution is to replace the control board.
• Power quality issues: Unstable PSU output or frequent power outages cause filesystem corruption during writes. Use a UPS and verify your PSU is delivering clean, stable power.
• Overheating control board: Some S17 boards overheat and crash, corrupting the filesystem. Verify adequate airflow over the control board.
• Persistent malware: If the miner was previously infected, ensure you are performing a full recovery (not just a web interface update) to overwrite any bootloader-level malware.

Quick Reference: Recovery Method by Model

Use this table as a quick lookup when you need to recover a specific miner model. It tells you exactly what method, what card size, and what tool to use.

Frequently Asked Questions

When to Call a Professional

SD card firmware recovery is a skill every miner operator should have. But there are situations where the issue goes beyond firmware and requires professional diagnosis:

• Repeated recovery failures — If you have tried multiple SD cards, verified the correct firmware file, and the miner still will not recover, the control board may have hardware damage (degraded NAND, failed SoC, damaged SD card interface).
• Hardware symptoms alongside firmware issues — If the miner was making unusual noises, smelled burnt, or showed signs of physical damage before the firmware issue, there is likely underlying hardware damage that firmware recovery will not fix.
• Amlogic board complications — USB Burning Tool recovery on Amlogic boards can be finicky, especially on locked boards from 2024+. If the tool repeatedly fails to detect the board, professional recovery with specialized equipment may be needed.
• Malware that survives SD card recovery — Extremely rare, but some advanced malware modifies the SPI flash on the board itself (separate from the main NAND). If your miner keeps getting reinfected after clean flashes, it needs forensic-level analysis.
• Fleet-wide recovery — If you need to recover firmware on dozens or hundreds of miners simultaneously (e.g., after a malware incident), D-Central can handle mass recovery operations at our facility.

Your hardware is sovereign. Every miner you recover from a brick, every machine you clean of malware and return to honest work, every hash that gets directed back to a pool of your choosing — that is decentralization in action. Firmware recovery is not just a technical skill. It is an act of resistance against the forces that want to centralize, control, and extract value from the Bitcoin network. Learn it, practice it, and share the knowledge. The network depends on miners who can maintain their own machines.

Every hash counts. Keep them yours.