Hammer Miner Firmware: Thor OS Updates, Downloads & the Open Option

Hammer Miner firmware is vendor-controlled end to end: the vendor runs a GitHub organization whose repo names mirror the open AxeOS stack and publishes real update binaries there — and publishes no source and no license. This page is the firmware layer for Hammer hardware: which chip each model actually runs, how the stock “Thor OS” update channel really works, what our reverse-engineering established about signing and security, and the one third-party option that exists — D-Central’s DCENT_axe — with its experimental status, its Scrypt exclusion, and its wrong-model risk stated exactly where the flash button is. For hardware specs, see the Hammer Miner spec page.

Jump to: models & chips · stock updates · signing & security · flashing DCENT_axe

Two families, two algorithms — keep them straight

Hammer sells two unrelated silicon families under one brand, and every firmware decision starts here:

Model	ASIC	Algorithm	DCENT_axe image	Image status
BC01	1× BM1370 (5 nm, S21 Pro gen)	SHA-256 (Bitcoin)	`dcentaxe-hammer-bc01`	Experimental
BC01-Pro (retail “Thor X1”)	1× BM1373 (S23-generation silicon)	SHA-256 (Bitcoin)	`dcentaxe-hammer-bc01-pro`	Experimental — least-evidenced image on the flasher
BC02	2× BM1370	SHA-256 (Bitcoin)	`dcentaxe-hammer-bc02`	Experimental
BC04 / Thor	4× BM1370	SHA-256 (Bitcoin)	`dcentaxe-hammer-bc04`	Experimental
DC02 / DC04 / DC06	2/4/6× MSBT0501	Scrypt (Litecoin + Dogecoin merged)	`dcentaxe-hammer-dc02/dc04/dc06`	Experimental — boots, does not mine (see below)

One diagnostic fact worth pinning, from our firmware reverse-engineering: the BM1373 silicon reports chip ID 0x1372, not 0x1373 — verified across the vendor firmware corpus, whose own accept logic was widened to a range to cope. If a tool reads 0x1372 on a BC01-Pro, that is the BM1373 answering, not a wrong chip (Verified against binaries).

Provenance note (Supported, from the same RE): the Hammer line appears to be a rebrand of “Volc” — volcminer.com is hard-coded in the i18n of all six web-UI partitions, the OTA magic string is GULLPOWER, and the DC02’s OTA file is literally volc-miner.bin. Recorded as an observation about origin, nothing more.

Stock “Thor OS” and the real vendor update channel

Hammer’s stock firmware is branded Thor OS (some resellers say “HammerOS”) and is vendor-controlled. The github.com/HammerMiner organization exists, with APP/WWW repo naming that mirrors the open ESP-Miner + AxeOS split — but the repositories themselves contain only a README and a version file each, and none declares a license. The releases attached to those repositories, however, are real: this is where vendor firmware updates actually ship, as compiled binaries. Checked against the GitHub API in August 2026:

Repo	Latest release	Asset
HammerMiner/BC01-APP	V2.0.3-20260625 (Jun 2026)	`bc01-miner-2.0.3-20260625-update.bin`
HammerMiner/BC04-APP	V3.0.2-20260802 (Aug 2026)	`bc04-3.0.2-20260802-update.bin`
HammerMiner/X1	v1.0.2-20260806 (Aug 2026)	`thorx1-1.0.2-20260806-update.bin`
HammerMiner/BC04	v1.0.1 (Jul 2026)	`Thor-BC04.bin`

Stated factually: that is a binary distribution channel, not an open-source publication. Owners can update from it — grab the update .bin for your model and apply it through the device web UI — but nobody outside the vendor can read what those updates contain, and with no license granted, the open-looking repo names confer no rights. We’d genuinely welcome the source showing up in those repos; the naming suggests it was at least contemplated.

As of August 2026 we found no independent community firmware fork for Hammer hardware — unlike Lucky Miner, where four GPL-3.0 forks exist. DCENT_axe is currently the only third-party firmware targeting these boards.

What our reverse-engineering established about signing

Because no source is published, the facts below come from D-Central’s reverse-engineering of the vendor firmware corpus — labeled accordingly:

v1.x builds are unsigned; the OTA update container is proprietary but its integrity scheme is a masked plain SHA256 with per-model XOR keys (Verified against binaries).
v2.0.x (BC01) and v3.0.x (BC04) builds introduce real Secure Boot V2 signing (RSA-3072) (Verified against binaries). Whether a given retail unit has Secure Boot permanently enabled in eFuse is Unknown — we have not probed physical units. If it is enabled on your unit, unsigned third-party images will not boot on it. This matters before you flash anything below.
secure_version=0 across the corpus — no anti-rollback, so vendor firmware downgrades are not version-blocked (Verified against binaries).
The analyzed builds pre-fill root/root and leave authentication unimplemented, meaning anyone on the same LAN can reach the dashboard and flash the device (Supported, RE). Owner guidance, not a dunk: run these miners on a trusted network segment.

DCENT_axe for Hammer — the status box comes before the button

Status: Experimental. LiveProof::None. D-Central owns no Hammer hardware. The Hammer images on /flash/ are reverse-engineered from vendor firmware and host-tested only — they have never been bench-tested on a real Hammer board, and they carry no code signatures yet. Three more truths belong in the same box:

The Scrypt models are not served. The DC02 / DC04 / DC06 images boot to a dashboard, but the MSBT0501 driver does not yet enumerate the chips — they do not hash on this firmware today. We publish that instead of hiding it. If you own a DC-series Hammer and want mining firmware, stock is currently your only option.
Wrong model = hardware risk, not just no hashing. DCENT_axe does not read the board’s identity strap; it trusts the model you select. A wrong image doesn’t merely map pins wrong — on these boards a wrong image can drive a push-pull output onto the fan-tach line at every boot, an electrical-stress condition on hardware that did nothing to deserve it. Identify your exact model before flashing; if you cannot identify it, do not flash. The “Thor” name is applied to two different boards (the single-chip BM1373 Thor X1 / BC01-Pro and the four-chip BM1370 BC04 / Thor) — match the board, not the marketing name.
Secure Boot may refuse the image. Per the section above, units updated to v2.0.x / v3.0.x vendor firmware may have Secure Boot V2 active; whether it is eFuse-enforced per unit is Unknown. An unsigned image will not boot on a Secure-Boot-enforced unit — if your board refuses DCENT_axe after a correct flash, this is the likely reason, and the recovery path below still applies.

What you get if your unit accepts it: a GPL-3.0 firmware you can read, build and verify — on hardware whose stock firmware you can’t. The browser flasher is, as far as we know, the only web flasher covering Bitaxe, Lucky Miner and Hammer Miner hardware in one place; each image ships with a published SHA256.

Action: connect over USB and enter ROM download mode (hold BOOT / GPIO0 strap, tap RESET). You should see: a new serial device. What it proves: the ESP32-S3 mask-ROM bootloader is reachable — the rail that makes this class of board recoverable (Supported: it works unless the vendor burned DIS_DOWNLOAD_MODE, which we have not observed in the corpus). Undo: power-cycle; nothing written.
Action: on /flash/, select your exact Hammer model and flash. You should see: the write verify against the published SHA256, then the DCENT_axe dashboard on the device IP. What it proves: your unit is not Secure-Boot-enforced and the image runs — a report either way on the source repository issues is live-hardware evidence this family currently lacks.
To return to stock: apply the vendor’s update .bin for your model from the HammerMiner GitHub releases above via the web UI, or serial-flash a saved stock image. Save one before you first flash.

If the board seems bricked

Same physics as every ESP32-S3 board: ROM download mode survives any application firmware, so a serial re-flash of a known-good image recovers the device (Supported — unless DIS_DOWNLOAD_MODE is burned, not observed in the corpus). Family-level map: ASIC control-board recovery playbook, ESP32 section; symptom twin: board won’t enter bootloader.

Hammer Miner firmware questions

How do I update Hammer Miner stock firmware?

From the vendor’s GitHub releases: HammerMiner/BC01-APP, BC04-APP and X1 attach compiled update binaries (e.g. bc04-3.0.2-20260802-update.bin), applied through the device web UI. The repositories publish binaries only — no source, no license.

Is Thor OS open source?

No. The stock firmware is vendor-controlled: the HammerMiner GitHub repos carry APP/WWW names that mirror the open AxeOS stack but contain only READMEs and version files, with no published source and no open-source license as of August 2026. The device architecture closely mirrors ESP-Miner + AxeOS, but with no source to inspect we do not claim a lineage we cannot confirm.

Can I flash open firmware on a Hammer DC02, DC04 or DC06?

You can flash DCENT_axe on them, but you shouldn’t expect mining: the Scrypt DC-series images boot to a dashboard and stop there — the MSBT0501 driver does not yet enumerate the chips, so there is no hashrate. DCENT_axe does not serve the Scrypt models today; stock is the only mining firmware for them.

What happens if I pick the wrong Hammer model in the flasher?

The firmware trusts your selection — there is no identity-strap check — so a wrong pick gives the wrong pin map, and on Hammer boards a wrong image can drive a push-pull output onto the fan-tach line at every boot: an electrical-stress condition, not just a non-mining one. Match the image to the exact board, especially across the two different “Thor”-branded models.

Will DCENT_axe boot on a Hammer running the latest vendor update?

Unknown, honestly. Vendor builds v2.0.x (BC01) and v3.0.x (BC04) introduce Secure Boot V2 (RSA-3072) signing; if Secure Boot is eFuse-enforced on your unit, an unsigned image will not boot. We have not probed retail units to establish per-unit enforcement. The ROM download mode remains available for returning to stock either way.

Related products, repair, and setup paths

Last reviewed August 13, 2026.