DCENT_Toolbox

Decentralize every layer. Heat your home. Stack sats.

One command-line tool + keygen-style TUI for Bitcoin miners: scan, unlock, audit, flash, and prove — entirely from your own machine.

See dcent.nfo for the release NFO.

⚠️ Authorized use only. DCENT_Toolbox includes exploit, unlock, credential-recovery, and firmware-audit capabilities intended solely for hardware you own or are explicitly authorized to administer. Using these against miners you do not control is illegal in most jurisdictions. By using this tool you accept the terms in SECURITY.md and take full responsibility for how you use it. The software is provided as-is, without warranty (GPL-3.0). The techniques it implements are based on publicly documented research and CVEs.

DCENT_Toolbox is a fully open-source, fee-free, multi-vendor operator toolbox — a tool that scans, unlocks, audits, flashes, and verifies Bitcoin miners across four vendor ecosystems and five firmwares, with no cloud account, no devfee, and no license server. It runs locally on Windows, macOS, and Linux. ~75 top-level commands; 4,500+ offline tests passing.

Built by the Mining Hackers at D-Central Technologies — Canada's leading Bitcoin mining technology company since 2016, based in Laval, Québec. 2,500+ miners repaired, 400+ products shipped. This is the bench we use ourselves, released so every operator can own, repair, and understand their own hardware.

New here? Point it at any miner and run dcent doctor <ip> — the canonical first step. It's read-only, never destructive, and tells you exactly what to do next. Then dcent help getting-started.

Detect, plan, and act across DCENT_OS for Antminers, DCENT_OS for ESP devices, Bitmain, MicroBT WhatsMiner, Canaan/Avalon, and BitAxe ecosystems without switching applications:

• DCENT_OS installer coverage - S9 has a public-gated route; S17/S19/S19 Pro/S19j Pro/S19k Pro/S21 routes are shown with their lab, manual, or no-customer-write boundaries, plus exact ESP OTA/USB routes for Bitaxe Max, Ultra, Supra, Gamma, Hex Ultra, and Hex Supra.

• 6 firmware ecosystems detected & driven — Bitmain stock, BraiinsOS+, LuxOS, VNish, DCENT_OS for Antminers, and DCENT_OS for ESP / DCENT_axe — one CLI, one TUI.

• 4 real vendor backends — Bitmain (stock / BraiinsOS+ / LuxOS / VNish / DCENT_OS), MicroBT WhatsMiner (write-API crypto), Canaan/Avalon (cgminer + ascset), and BitAxe (full AxeOS surface). Unknown gear routes to a read-only generic cgminer backend — never a silent Bitmain mis-route.

• 7 control-board families — am1-XIL, am2-XIL, am3-BB, am3-AML, cv1835, bcb100, and esp32-s3.

• Locked-stock install planning + per-vendor revert-to-stock — install --auto-unlock runs the board-appropriate SSH-enable before planning the route: Zynq web-CGI rails, BeagleBone root-privesc, and brick-safe assisted Amlogic USB-OTG downgrade for March-2024..August-2025 locked boards. The install outcome is still model-specific: S9 has a route-backed install rail and still needs public artifact plus witnessed live-capstone evidence before production-release promotion; AM2 S19 Pro/S19j Pro supports guarded lab self-update only from an already-running DCENT_OS source, while vendor-source persistent first install remains a non-executable evidence gap; S17/plain S19/BB/Amlogic/CVitek lanes remain no-customer-write, manual, or hardware-limited routes (see the per-board reality matrix below).

• Fleet service — dcent serve headless daemon + Prometheus /metrics, alerting sinks, rack heatmap, grid curtailment, and Smart-PDU / Home-Assistant outlet control.

• 5-platform native-mining proof — am1-s9, am2-s19pro S19 Pro, am3-aml S21, am3-bb S19j Pro, and am2-XIL S19j Pro, all verified by dcent verify-mining against a V1–V14 cold-boot ladder.

• 0% DevFee, 0% cloud, GPL-3.0-only.

Who it's for:

• Recovery techs — dcent doctor <MINER_IP> triages a bricked unit in seconds.
• Home miners — dcent tui opens the keygen-style dashboard with a space-heater wizard.
• Fleet operators — dcent scan --range 192.168.1.0/24 discovers the LAN; dcent fleet status reports back.
• Hackers & researchers — dcent fingerprint <MINER_IP> maps the SoC + boot source + applicable exploits.

---

Quickstart

# 1. Install from a full source checkout/export until PyPI is published.
#    The checkout must contain pyproject.toml and src/dcent_toolbox/.
cd DCENT_Toolbox
python -m pip install -e .

# 2. Discover miners on your LAN
dcent scan --range 192.168.1.0/24

# 3. Full triage in ~5 seconds (canonical first step for every persona)
dcent doctor <ip>

# 4. Keygen-style dashboard  (needs the [tui] extra — see "Optional extras")
pip install -e ".[tui]"
dcent tui

# 5. Browse the help topics
dcent help getting-started

Next steps:

• Getting started — install and first commands
• Supported platforms — miners, firmwares, and control boards
• Installing DCENT_OS firmware — the companion open-source mining firmware

Optional extras:

pip install -e .                    # editable, repo checkout
pip install -e ".[tui]"              # Textual keygen dashboard (dcent tui)
pip install -e ".[audio]"            # chiptune playback in TUI
pip install -e ".[axe]"              # esptool + pyserial for BitAxe USB flash
pip install -e ".[bot]"              # httpx-only Telegram chat-ops controller
pip install -e ".[dev]"              # pytest + tooling
pip install -e ".[tui,audio,axe]"   # the full TUI experience

Prefer a single binary with no Python install? A PyInstaller one-file spec (packaging/pyinstaller/dcent.spec) plus a cross-platform build.py and a 3-OS GitHub Actions build matrix are in the tree for the planned standalone dcent executables. Codesigning / notarization / Authenticode is gated on operator-held secrets — no keys live in the repo, and signed binaries are a release artifact, not a live install path yet.

---

Honest by design — the proof-ladder

DCENT_Toolbox reports exactly what it proved, never more. Every action carries a proof-ladder state, so "the command ran" is never confused with "the outcome is verified" — an upload is accepted, not flashed; a reachable device is online, not mining. That honesty is enforced by the test suite, not a promise. Two labels you'll see:

• Live-validated — exercised against real miners (e.g. the BMU/EEPROM/dsPIC tooling and the five-platform mining proof).
• Operator-gated — code-complete and tested; the live write/execute step waits for your explicit go-ahead, on your own hardware.

Use dcent support --flash-readiness, dcent install --list-routes, and each command's --dry-run / --plan output to see exactly what a route will do before you run it. Where a capability is early, we label it plainly — the experimental Stratum V2 client, for instance, has no encrypted Noise handshake yet, so it is marked experimental rather than presented as production SV2. Non-localhost SV2 lab endpoints require --allow-non-localhost-lab and remain outside production SV2 compatibility until the real encrypted handshake lands.

---

LAN trust and SSH host keys

dcent is designed for owner-operated miners on a trusted LAN. SSH transport now uses trust-on-first-use host-key pinning instead of blind auto-add:

• Paramiko and native ssh/scp store first-seen keys in ~/.dcent/known_hosts (or $DCENT_HOME/.dcent/known_hosts).
• The Node legacy-dropbear helpers store first-seen SHA-256 host-key hashes in ~/.dcent/known_hosts.node.json.
• DCENT_TOOLBOX_KNOWN_HOSTS and DCENT_TOOLBOX_NODE_KNOWN_HOSTS can point those files somewhere else for CI or portable installs.

On first contact the key is pinned. On a later key change the transport refuses the connection and prints the expected/got fingerprints. If a miner was deliberately reimaged and its host key changed, verify the LAN target out of band and remove only that miner's known-hosts entry. Firmware package signing remains the primary integrity control; SSH TOFU is defense in depth against LAN misrouting or MITM during install.

---

Can it install DCENT_OS on any Antminer? — the honest per-board reality

Not on every board — and the reason is hardware, not software effort. Stock Antminers ship with SSH disabled and (post-July-2019) RSA-signed firmware. Getting a root foothold and flashing custom firmware hits a generational hardware wall: the signing chain cannot be forged, so each board generation either has a software foothold (a web-CGI command-injection path that flips on Dropbear) or it does not, in which case a physical rail (SD card / USB-OTG / console) or an external-eMMC reflash is the only way in. DCENT_Toolbox is explicit about exactly where each rung holds.

Taxonomy: Public-gated route (route-backed, with public artifact plus witnessed live capstone still required) · Lab route (requires exact backup/recovery/proof gates) · No customer write route (named, intentionally no write path) · Hardware/manual route required (requires physical media/console) · Hardware-limited (hardware-fused, board swap/external flash).

Control board · generation	Software SSH-enable on LOCKED stock	DCENT_OS install readiness	Verdict
Zynq / XIL — S9/S9i AM1	YES — remote web-CGI and signed-stock unlock rails, wired into install --auto-unlock	Route-backed S9 install rail exists, with public artifact + witnessed live capstone still required	Public-gated route
Zynq / XIL — S17/T17 AM2	Board-specific foothold possible; exact S17 stock route requires promotion evidence	Runtime-only on BraiinsOS; stock S17 has no customer write route	No customer write route
Zynq / XIL — S19 Pro / S19j Pro AM2	SSH foothold depends on source firmware; stock single-slot is not silently flashed	Runtime routes plus guarded DCENT_OS-source self-update; vendor-source first install has no executable method pending an authenticated capsule and state migration	Self-update lab / first-install evidence gap
Plain S19	Not inferred from S19 Pro/S19j Pro	Named platform entry; customer write route waits for exact board-target promotion	No customer write route
BeagleBone / AM335x (S19j / S19j Pro)	SSH is often present as non-root miner; 22322 escalation is fail-closed	Physical SD-first route; NAND install waits for SD recovery, NAND backup, and restore-to-stock promotion	Hardware/manual route required
Amlogic / A113D (S19j Pro / S19k Pro / S21)	A Mar-2024..Aug-2025 assisted USB-OTG downgrade exists; Sept-2025+ has no software path	Runtime/rootfs-window lab only with exact root SSH, backup, readback, and recovery proof	Lab route / hardware-limited
CVitek / CV1835 (S19k Pro/S21/KS3/S19XP)	NO — RSA+AES eFuse-locked FIP	No SD route; eMMC recovery and bench evidence required before write paths are exposed	Hardware-limited

Bottom line: "install DCENT_OS on any Antminer, software-only" is not true — Amlogic Sept-2025+ and CVitek CV1835 are hardware-fused with no software path (external eMMC or a control-board swap only). DCENT_Toolbox now keeps the unlock, route, artifact, and proof state separate: S9 is a public-gated route; S17/plain S19 have no customer write route; AM2 S19 Pro/S19j Pro has a DCENT_OS-source self-update lab route while vendor first install remains an evidence gap; BB, Amlogic, and CVitek lanes remain manual, lab, or hardware-limited routes. Running any live write is operator-gated on hardware you own. See Supported platforms and dcent support --flash-readiness for the route-backed breakdown.

---

Can it install DCENT_OS for ESP on Bitaxe-class miners?

Yes for the supported DCENT_OS-for-ESP package rails: a running AxeOS/DCENT_axe device can be updated over HTTP OTA, and a first flash uses USB serial. The toolbox now exposes exact route rows for the requested boards so package names, manifest boardTarget, and operator guidance stay model-specific.

Miner	ASIC	Board target	Install path	Current proof
Bitaxe Max	BM1397	bitaxe-max	OTA update or USB factory flash	Host-tested driver path
Bitaxe Ultra	BM1366	bitaxe-ultra	OTA update or USB factory flash	Host-tested driver path
Bitaxe Supra	BM1368	bitaxe-supra	OTA update or USB factory flash	Host-tested driver path
Bitaxe Gamma	BM1370	bitaxe-gamma	OTA update or USB factory flash	Host-tested driver path; Gamma live-verified
Bitaxe Hex Ultra	6x BM1366	bitaxe-hex-ultra	OTA update or USB factory flash	Hex dispatcher path host-tested; live soak pending
Bitaxe Hex Supra	6x BM1368	bitaxe-hex-supra	OTA update or USB factory flash	Host-tested hex dispatcher path, including the BM1368 job-id fix

# Running device: dcent install autoroutes Bitaxe/DCENT_OS ESP targets to OTA.
dcent install 192.168.1.42 -f dcentaxe-bitaxe-gamma-0.3.0-update.bin --dry-run

# Route-pinned ESP rail (same OTA transport, no SSH/NAND planner).
dcent install --route dcentos-esp-bitaxe-gamma-ota-usb 192.168.1.42 -f dcentaxe-bitaxe-gamma-0.3.0-update.bin --dry-run

# Explicit OTA rail.
dcent ota update 192.168.1.42 -f dcentaxe-bitaxe-gamma-0.3.0-update.bin --dry-run

# First USB serial flash.
dcent flash --list-ports
dcent flash --serial COM3 -f dcentaxe-bitaxe-gamma-0.3.0-factory.bin --dry-run

DCENT_OS-for-ESP package rails require the companion DCENT_axe manifest for route-pinned OTA and factory USB flows. Validation checks boardTarget, deviceModel, payload SHA-256, factory flash map, and ota.updateFitsSlot before upload or image write. Upload/image-write acceptance is not boot, rollback, thermal, or mining proof. LoRa mesh remains planned/default-OFF in the firmware binary.

---

What it does

dcent-toolbox combines multi-vendor + multi-firmware recovery, route planning, locked-stock install, local artifact inspection, a fleet service, and mining proof in one operator workflow — ~75 top-level commands today (run dcent --help for the live list). Treat the capability list as inventory, not permission to skip the route/proof checks.

The live-validated standouts: a 5-method SSH Enabler cascade (pre-July-2019 RSA bypass, July-2019+ runme.sh, CVE-2018-11220 hostname injection, signed-FIP AES-256-CBC unlock, API enabler); a dual-scheme BMU verifier (stock RSA-2048 two-layer, RSA-4096 OTA, S21 AES-CBC); an EEPROM XXTEA read/decrypt CLI with the Skot keys baked in and lower-level guarded write code kept out of casual workflows; a daemon-refused but lab-binary-restored dsPIC fw=0x86 recovery path; a 15-IOC firmware audit (DCENT-2026-001..015) plus a backdoor cleaner that removes a known atlas@anthill.farm SSH backdoor, kills the monitor-ipsig phone-home, and blocks an embedded DevFee on affected third-party firmware images; and the mining-proof verifier that classifies an install proof as PROVEN / PARTIAL / FAILED / UNVERIFIABLE against a V1–V14 cold-boot ladder (validated across 5 platforms).

The code-complete-but-operator-gated additions (no live miner contacted in tests; live write/execute requires explicit operator authorization): the locked-stock install lane (install --auto-unlock, amlogic-unlock USB-OTG downgrade for Mar-2024+ locked Amlogic boards, U-Boot/UART console rescue), per-vendor revert-to-stock for all four firmwares (BraiinsOS recovery-mode NAND rewrite, VNish dashd firmware/remove, DCENT_OS/LuxOS uninstall.sh), the dcent ota update-fleet A/B sysupgrade rail (fw_setenv-atomic), and the grid-curtailment / Smart-PDU power ops.

Read the install lane through the per-board matrix above, not as a blanket "any-board OTA": dcent install runs over an SSH session, and dcent install --auto-unlock runs the board-appropriate SSH-enable for LOCKED stock first. The Zynq web-CGI cascade web-unlocks both generations; BeagleBone (SSH already on, non-root) gets the 22322 root-privesc with a fail-closed drop; Amlogic Mar-2024..Aug-2025 gets a brick-safe assisted USB-OTG downgrade. Amlogic Sept-2025+ and CVitek have no software path (external eMMC or board swap only).

No cloud tether. No DevFee. No license-server gating. The toolbox runs entirely from your laptop / lab bench — no remote account, no license activation, no telemetry.

Five-platform native-mining proof contract: am1-s9 (BM1387, sustained cold-boot 2026-04-19), am2-s19pro S19 Pro (BM1398, 2026-04-10), am3-aml S21 (BM1368, 2026-04-11), am3-bb S19j Pro (BM1362, 2026-05-13), am2-XIL S19j Pro (BM1362, 2026-05-15). The verify-mining subcommand encodes the time-budget proof for all five platforms.

---

Deeper Quickstart — write paths and verify

# Diagnose any miner first
dcent doctor <MINER_IP>

# Browse by topic
dcent help recovery
dcent help unlock
dcent help re

# Open the keygen TUI
dcent tui

# Unlock only hardware you own/administer; audit before cleanup
dcent unlock <MINER_IP> --plan
dcent audit <MINER_IP>
dcent clean <MINER_IP> --dry-run

# Inspect SD-card readiness before any write
dcent sdcard matrix
dcent support --flash-readiness
dcent sdcard am3-bb-validate ./dcentos-am3-bb-s19jpro-sdcard.tar   # <path-to-your-DCENT_OS-artifact>

# Install + verify
dcent support --flash-readiness
dcent install --list-routes
dcent install <MINER_IP> --route <route-id> --dry-run --json
dcent verify-mining <MINER_IP> --wait 180

The 4 vendor backends it drives (multi-vendor detection only sets make=BITMAIN on a positive Bitmain signal — Unknown gear routes to a read-only generic cgminer backend, never a silent Bitmain mis-route):

• Bitmain — stock / BraiinsOS+ / LuxOS / VNish / DCENT_OS, full read + write surface.
• MicroBT WhatsMiner — BTMiner write-API crypto (get_token → md5_crypt(salt) → SHA-256 → AES-256-ECB + newsalt signature), which enables WhatsMiner OTA.
• Canaan / Avalon — cgminer JSON-RPC (port 4028) + ascset privileged writes (PROD=AvalonMiner detection).
• BitAxe — full AxeOS surface (settings PATCH, ASIC tuning bounds, statistics, identify/locate, wifi scan, OTA). DCENT_OS for ESP / DCENT_axe package validation and USB first-flash helpers are part of the same Bitaxe-class workflow.

The 6 firmware ecosystems it detects and works against:

• Bitmain stock (S9 / S17 / S19 / S19j Pro / S21 / T19 etc.)
• BraiinsOS+ (am1 Zynq 7010, am2 Zynq 7007S)
• LuxOS (Bitmain-derived stock fork, includes AM335x BeagleBone carriers)
• VNish (Zynq / Amlogic / BeagleBone / CVitek / Legacy)
• DCENT_OS (our own GPL-3.0 firmware / MIT tools)
• DCENT_OS for ESP devices / DCENT_axe (Bitaxe Max, Ultra, Supra, Gamma, Hex Ultra, Hex Supra)

The 7 control-board families it understands. Install support is route-specific; run dcent support --flash-readiness and dcent install --list-routes before assuming a write path is proven for a given unit.

• am1-XIL — Zynq 7010, S9 family
• am2-XIL — Zynq 7007S, S17 / S19 / S19j Pro (incl. Loki-modded XIL); S21 Hydro is cataloged only and has no install route until exact hardware proof exists
• am3-BB — AM335x BeagleBone (S19j Pro on S19J_IO_BOARD_V2_0)
• am3-AML — Amlogic A113D (S19j Pro / S19k Pro / S21 / T21)
• cv1835 — Cvitek CV1835 ARM64 (S19j Pro / S19k Pro / S21 / S19i / S19XP / T19)
• bcb100 — STM32MP15 Braiins Open Hardware control board
• esp32-s3 — Bitaxe-class DCENT_OS for ESP devices (Max, Ultra, Supra, Gamma, Hex Ultra, Hex Supra)

---

Operator Capabilities (Highlights)

A hand-picked slice of the ~75-command surface. Every write path still needs the command's own dry-run, confirmation, route, and proof vocabulary; upload acceptance is not mining proof, and an operator-gated command is command-construction only until you authorize it on real hardware.

Capability	Subcommand	What it does
SSH Enabler	dcent unlock	5-method web-CGI cascade (pre-Jul2019 RSA + Jul2019 runme.sh + hostname-inject CVE-2018-11220 + signed-FIP AES unlock + api_enabler). Authenticated-CGI injection (web-admin password, port 80), NOT an auth bypass. Both Zynq generations web-unlockable; BeagleBone gets the 22322 root-privesc; Amlogic Sept-2025+/CVitek have no software path. Code-complete, tested, reviewed (see per-board matrix)
Locked-stock onboarding	dcent install --auto-unlock	Route-specific unlock and install planning; dry-run default, --yes gated; live execution operator-gated. S9 has a route-backed install rail but remains public-artifact/live-capstone gated. AM2 S19 Pro/S19j Pro has a guarded DCENT_OS-source self-update lab route; stock/BraiinsOS/LuxOS/VNish first install is a non-executable evidence gap pending an authenticated capsule and state migration. S17/plain S19/BB/Amlogic/CVitek lanes are no-customer-write or manual routes as shown by dcent support --flash-readiness.
Amlogic USB-OTG unlock	dcent amlogic-unlock	Assisted USB-OTG downgrade driver for Mar-2024..Aug-2025 locked Amlogic A113D (flash pre-lock signed Bitmain image over micro-USB → chain rootfs-window). Brick-safe: validate_pre_burn fails CLOSED on unknown/cross model (MODEL_UNKNOWN/MODEL_MISMATCH). Sept-2025+ port-fused → hardware-limited, board swap only. Live burn operator-gated
Per-vendor revert-to-stock	dcent install --revert-to-stock	All 4 firmwares — BraiinsOS recovery-mode NAND rewrite, VNish dashd firmware/remove, DCENT_OS/LuxOS uninstall.sh; BraiinsOS/VNish proof pending
BMU dual-scheme verifier	dcent verify-bmu	RSA-2048 stock + RSA-4096 OTA + S21 AES-CBC
EEPROM XXTEA decrypt	dcent eeprom	Read-only CLI probe/decrypt; guarded writer code is not a casual operator command
dsPIC fw=0x86 recovery	pic-recovery dspic-reflash-fw86	Daemon refuses fw=0x86; lab binary restores
Mining-proof verifier	dcent verify-mining	V1–V14 ladder, 60s/120s/180s budgets, PROVEN/PARTIAL/FAILED/UNVERIFIABLE
15-IOC firmware audit	dcent audit	DCENT-2026-001..015, atlas@anthill.farm backdoor, monitor-ipsig phone-home, dashd RCE
Toolbox self-audit	dcent audit self	Audits the toolbox's own posture (secrets, redaction, pinned pubkey)
Backdoor cleaner	dcent clean	Remove backdoor key, kill phone-home, clear blacklist, block devfee; persistence still depends on firmware/storage
Fleet OTA rail	dcent ota update-fleet	Batch A/B sysupgrade (fw_setenv-atomic) + DCENT_OS-for-ESP Bitaxe OTA; full proof-ladder; live execution operator-gated
Headless fleet service	dcent serve	Daemon + Prometheus /metrics (127.0.0.1 default) + /status JSON + rules scheduler + Telegram/email/webhook alerting
Rack heatmap	dcent sitemap	Physical-layout fleet view + HTML export
Grid curtailment	dcent curtail/sleep/wake	Demand-response power management; wake restores pre-curtail state
Smart-PDU / Home-Assistant	dcent pdu on/off/cycle/status	Outlet control for units with no software power control (Shelly / Tasmota / Synaccess / HA)
Safe chat-ops	dcent bot	Telegram controller: OFF by default, allowlist + in-chat TTL typed-confirm; routes to existing backend paths only
NAND backup ritual	dcent backup family + TUI Ctrl+N	CLI lists storage; TUI wizard performs recovery-grade dumps with gates
SD card build/write	dcent sdcard build/write	Local image build plus guarded raw writer; OS disks refused; see vendor-blob disclosure below
Board fingerprint + exploit map	dcent fingerprint	6 board types + applicable-exploit-feasibility table (unimplemented vectors honestly marked "manual/not-automated")
Stratum proxy / share verifier	dcent stratum	Local Stratum recording, replay, vbits histograms
Firmware diffing	dcent unpack diff, dcent diff fleet	Binary-tree firmware diff and fleet version comparison
Fleet anomaly forensics	dcent forensics anomaly	Rule-based anomaly analysis from the RE corpus
Live devmem trio	dcent live	peek/poke + probe-chain + fpga regdump
Auto-doctor mode	dcent doctor	Read-only first pass with partial-result tolerant reporting
Power/profit loop	dcent autopilot	Local profit-aware loop; dry-run/status before unattended use
Rules engine	dcent rules	YAML triggers/actions + SQLite audit log
Shell completion	dcent completion	bash/zsh/fish completion scripts
Particles boot splash	dcent tui --intro	D-Central logo decode-reveal

---

Workflows by persona

Recovery tech

dcent doctor <MINER_IP>                        # what's wrong?
dcent fingerprint <MINER_IP>                   # board family + exploits
dcent backup nand <MINER_IP>                   # /proc/mtd inventory
dcent tui                                      # Ctrl+N for recovery-grade NAND backup
dcent install <MINER_IP> --route <chosen> --dry-run
dcent verify-mining <MINER_IP> --wait 180      # PROVEN/PARTIAL/FAILED

Hacker / researcher

dcent fingerprint <MINER_IP>                   # SoC + boot source + exploit feasibility
dcent extract-bmu firmware.bmu                 # RSA-2048 dual-layer or RSA-4096
dcent unpack analyze firmware.bmu              # tar.gz / UBIFS / cpio
dcent eeprom read <MINER_IP>                   # XXTEA-decrypted hashboard EEPROM
dcent probe vnish <MINER_IP>                   # full API + EEPROM + config exfil

Home miner (space-heater mode)

dcent tui                                       # browse the keygen dashboard
# In TUI: Ctrl+H → space-heater wizard
dcent fan auto <MINER_IP> --target-temp 65
dcent tune profile <MINER_IP> --profile silent  # ≤ 14,500 mV, fan ≤ 30
dcent verify-mining <MINER_IP>                  # accepted-share validation

Fleet operator

dcent scan --range 192.168.1.0/24 --dry-run     # plan discovery
dcent scan --range 192.168.1.0/24               # discover all miners
dcent doctor 192.168.1.0/24 --quick --markdown > daily-report.md
dcent fleet status --range 192.168.1.0/24       # bulk live view
dcent rules add cool-room-heat.yaml             # local rule registry

Bench developer (DCENT_OS itself)

dcent install --list-routes
dcent install <MINER_IP> --dry-run --route <key> --json
dcent verify-mining <MINER_IP> --wait 180
dcent sdcard matrix
dcent sdcard am3-bb-validate ./dcentos-am3-bb-s19jpro-sdcard.tar   # <path-to-your-DCENT_OS-artifact>

---

Sharing logs with D-Central support

Always use dcent diag bundle --redact <ip> instead of pasting raw journalctl or dcentrald.log output into a GitHub issue, the forum, or chat. Raw mining logs include your full Bitcoin payout address and pool credentials — that's the same privacy/security issue as leaking a credit-card number, since the address links your earnings to a public identity.

# Standard support flow (redacted by default — safe to share):
dcent diag bundle 192.168.1.100

# Custom output filename:
dcent diag bundle 192.168.1.100 --output ./tickets/case-42.tar.gz

# See what would be collected without contacting the miner:
dcent diag bundle --dry-run 192.168.1.100

# LAB ONLY: produce an unredacted bundle. Never share unredacted bundles
# outside a controlled lab — they contain your wallet, pool credentials,
# public IPs, and MAC addresses in cleartext.
dcent diag bundle --no-redact 192.168.1.100

What gets redacted automatically:

Category	Replacement
Wallet addresses	<wallet:redacted> (bech32, base58, hex 32/40/64)
SSH bearers / Argon2id	<bearer:redacted>
Public IP addresses	<ip:redacted> (LAN / RFC 1918 preserved)
MAC addresses	<mac:redacted-XX:XX> (last 4 hex preserved)
Pool URLs	<pool:hostname-redacted>:port
dcentrald.toml fields	url/worker/password/wallet -> <config:redacted>

The output is dcent-diag-bundle-<hostname>-<UTC-timestamp>.tar.gz with a MANIFEST.json describing the redaction rules applied.

---

About D-Central

DCENT_Toolbox is built by D-Central Technologies — the "Mining Hackers": a Laval, Québec workshop of engineers who mine, build, and repair Bitcoin hardware. Founded in 2016, D-Central is Canada's leading Bitcoin mining technology company, with thousands of miners repaired and hundreds of products shipped.

We open-source the tools we use ourselves because operators should be able to own, inspect, and repair their own hardware — no cloud account, no dev fee, no lock-in. DCENT_Toolbox is part of a broader effort to decentralize every layer of the Bitcoin mining stack, alongside our open firmware, DCENT_OS.

• 🌐 Website: https://d-central.tech/
• 🔧 Companion firmware: https://github.com/DCentralTech/DCENT_OS
• 🧭 How decisions are made: GOVERNANCE.md

---

The D-Central open-source Bitcoin mining ecosystem

All under one roof at github.com/DCentralTech — decentralize every layer: mining, tools, hardware, communication.

• DCENT_OS — open-source mining firmware for selected industrial Antminer and ESP32 Bitaxe-class targets, with Avalon and WhatsMiner work in development.
• DCENT_Toolbox — the open-source bench tool: scan, unlock, audit, flash, and prove — from your own machine.
• DCENT_axe — open-hardware Bitaxe-class boards (Solo / Quad / Hex) with integrated LoRa mesh.
• DCENT_Raven — LoRa-mesh accessory for any Bitaxe.

---

License

• GPL-3.0-only for DCENT_Toolbox (see LICENSE).
• Some generated/export helper snippets may carry their own SPDX headers where marked.
• 100% local execution — the toolbox NEVER phones home.
• 0% DevFee, 0% pool fee adder, 0% license-server gating.

Credits & third-party attribution

DCENT_Toolbox incorporates and builds on prior open-source work. The hash-board EEPROM decryption algorithm and key tables are derived from (and kept byte-identical to) skot/amlogic-cb-tools (GPL-3.0); the ASIC drivers, APIs, and protocols were informed by ESP-Miner (GPL-3.0), pyasic (Apache-2.0), and asic-rs (Apache-2.0). Full upstream copyright/license notices are preserved in THIRD_PARTY_NOTICES.md.

The do-not-regress list (a guarantee, not aspirational): the SSH-enabler 5-method cascade, the BMU dual-scheme verifier, the EEPROM XXTEA read/decrypt + guarded lower-level I²C writer, the dsPIC fw=0x86 daemon refusal + lab recovery, the EEPROM HAL write-protect (am2 0x50-0x57 denylist), destructive PIC ops behind the recovery-tool Cargo feature, the voltage_mv ≤ 14,500 clamp for am2, the fan_max_pwm ≤ 30 home-use cap, PIC heartbeat fail → voltage cut (NOT fan blast), restore-verified install gating, the 5-platform native-mining proof contract, GPL-3.0 firmware / MIT-Apache-2.0 tools, 100% local execution, and 0% DevFee / pool-fee adder.

Vendor-blob disclosure

Building a bootable SD-card image for the Antminer S19j Pro BeagleBone (AM3-BB) control board requires a small first-stage boot.bin (~48 KiB) that originates from the stock/VNish vendor firmware for that board — it is not re-implementable from open sources. DCENT_Toolbox does not bundle that blob; dcent sdcard build uses whatever first-stage the operator supplies from their own device, and the guarded SD writer refuses OS disks. Treat any such vendor first-stage as bench-proof material for hardware you own, not a redistributable artifact.

---

Links

• Capabilities & feature reference: CAPABILITIES.md
• Getting started: docs/GETTING_STARTED.md
• Supported platforms: docs/PLATFORMS.md
• Comparison vs other tools: docs/COMPARISON.md
• FAQ: docs/FAQ.md
• Configuration & CLI reference: docs/CONFIGURATION.md
• Contributing: CONTRIBUTING.md · Responsible use & security: SECURITY.md
• Third-party attribution: THIRD_PARTY_NOTICES.md
• DCENT_OS companion firmware: https://github.com/DCentralTech/DCENT_OS