BitBox02 firmware

This commit adds a new 'session reset' command to the BitBox02 hardware wallet's USB protocol. It lets the host computer cleanly reset the device connection if a previous operation was interrupted, instead of leaving the device stuck mid-task. The change also fixes a minor timeout-handling issue for the existing INFO command so that merely checking the firmware version no longer keeps an abandoned operation alive. The commit is framed as a robustness improvement, not a security fix, and there is no disclosed vulnerability.

This commit fixes a bug in the BitBox02 hardware wallet where unplugging the USB cable at the wrong moment could leave a half-finished operation running. If the device stayed powered and a new host reconnected, the new host's first message could be misinterpreted as a continuation of the old operation, producing a confusing encrypted error instead of a proper response. The fix adds a new 'reset session' command that the companion app sends at the start of every connection on firmware 9.28.0 and newer, which cancels any leftover task, clears queued responses, resets the encrypted Noise channel, and restores the user interface. The change also lets the host ask for the firmware version without extending an abandoned operation's timeout, so it can safely decide whether to reset.

This commit relaxes a version check in the BitBox02 bootloader upgrade code. Previously, the firmware installer required that a stage0 bootloader descriptor's version exactly matched the currently expected image version. Now it accepts descriptors whose version differs, as long as the magic number and product ID still match. The change is framed as improving compatibility across bootloader descriptor layouts, not as fixing a security bug. The accompanying tests verify that both older and newer stage0 versions are accepted.

This commit fixes a display behavior issue during startup of the BitBox02 hardware wallet. Previously, when the device turned on, the screen's reset pin was left in a state that could allow leftover images or text from an earlier session to briefly appear at low brightness before the device finished booting. The change ensures the screen is kept fully blank (held in reset) until the firmware is ready to draw a clean screen. This is a defensive fix to prevent a user from seeing stale or misleading information during boot.

This commit trims the BitBox02 factory-setup firmware image by switching stored root attestation public keys from 65-byte uncompressed to 33-byte compressed secp256k1 keys, and by using a smaller static secp256k1 verification context instead of a full signing context. It also adds a self-test and a helper that computes the key identifier from the uncompressed form so existing host tooling keeps working. The changes are framed as a size-reduction/cleanup patch; there is no direct evidence in the commit of a security vulnerability being fixed.

This commit adds extra safety checks in the BitBox02 Python library for ECDSA signatures used in Bitcoin and Ethereum signing. It now validates that signatures have the correct length, use valid numbers, and use the safer low-S form. It also validates the recovery ID for recoverable signatures. These are defensive hardening changes rather than a fix for a known active exploit, but they close a gap where a malicious or buggy device could return malformed or malleable signatures that the host software would previously accept.

This commit is a hardening and size-optimization change for the BitBox02 factory-setup firmware. It stores the 110 built-in root attestation public keys in compressed (33-byte) form instead of uncompressed (65-byte) form, and marks the table as read-only (`const`). This shrinks the firmware image by about 2.6 KB and reduces RAM use by about 7 KB. A new helper is added so the device can still compute the same public-key identifiers used by host software, and the existing signature verification behavior is preserved. There is no direct vulnerability being fixed; the main security benefit is making the key table tamper-resistant in RAM because it now lives in read-only memory.

This commit swaps one internal cryptography library for another when computing HMAC-SHA256 in the factory-setup code. The goal is to reduce firmware size by reusing an existing SHA-256 implementation, not to fix a security bug. New test vectors were added to confirm the new implementation still produces the correct answers.

This commit changes how the BitBox02 factory-setup program checks digital signatures. It switches from a dynamically created crypto context to a built-in, read-only verification context, which makes the factory-setup firmware about 35 KB smaller. The commit also adds an explicit self-test because the new static context skips the automatic self-test that the old path performed. The change is a size optimization, not a fix for an active security flaw, but it touches cryptographic verification code used during device manufacturing.

This commit is a performance optimization in the BitBox02 factory setup process. It changes how the device picks which trusted root public key to use when verifying an attestation certificate. Previously, the device tried verifying the signature against every known root key until one worked, which could take up to about 2.4 seconds. Now it first looks up the correct root key using a short identifier (a hash of the public key) and then verifies the signature only once, taking less than 0.1 seconds. The security properties remain the same: the signature is still checked, just faster.

This commit is a large feature merge that adds initial support for a new hardware variant, the BitBox03 (STM32U5-based development kit). It introduces new bootloader and firmware binaries, board support crates, vendored Rust dependencies (once_cell, portable-atomic, rtt-target), build scripts, and CI targets. There is no indication in the commit message or diff that this is a security fix or that it addresses any vulnerability. It appears to be routine product/platform enablement work.

This commit adds signed release assertions for the BitBox02 firmware version 9.27.1. It contains only text files and detached signatures that record the expected SHA-256 hash of the official firmware binaries. There is no code change, no bug fix, and no security patch.

This commit simply adds official signed release artifacts for BitBox02 firmware version 9.27.1. It contains two text files with build attestations and two detached signatures. There is no code change, no bug fix, and no security-relevant content in the diff itself.

This commit adds a new read-only piece of information to the BitBox02 device info API: the installed bootloader's marketing version string. It does not change how the device boots, signs, or verifies anything. It is purely an informational feature for apps and users to see which bootloader is installed, and it is not treated by the authors as a security fix.

This commit improves the Python firmware-flashing tool for BitBox hardware wallets. It adds clearer warnings, requires user confirmation before flashing, detects firmware type automatically instead of relying on filename or a debug flag, and exposes more detailed bootloader error messages. The changes are primarily usability and safety improvements for a developer/testing tool, not a fix for an exploitable device vulnerability.

This commit improves a Python helper used by developers to flash firmware onto BitBox hardware wallets. It makes the tool smarter about whether the connected device is a production or development unit, detects signed vs unsigned firmware files automatically, and adds clearer warnings and confirmation prompts. The changes are mostly usability and safety improvements for a developer-facing script, not a fix for a remote attack on user devices.

This commit is a merge that adds and updates release-helper scripts for the BitBox02 hardware wallet. It introduces a new script to draft GitHub firmware releases, refactors existing scripts to share a common parser for signed firmware files, and adds type annotations and tests. There is no direct evidence in the diff of a security vulnerability or malicious change; it appears to be routine release-tooling maintenance.

This commit adds a new read-only field to the BitBox02's device information response so the host app can learn which bootloader version is installed. It does not change how data is signed, encrypted, or authorized. The main security-relevant aspect is that the firmware now reads a small version string from the bootloader area and validates the bootloader header's magic value and length before exposing it. This is a defensive information-disclosure change rather than a vulnerability fix.

This commit adds vendored copies of two Rust embedded-crates (cortex-m-rt and its companion macro crate) plus a large auto-generated STM32U5 peripheral access crate to the BitBox02 firmware repository. Vendoring means the project is no longer fetching these libraries from the public crates registry at build time; instead it uses its own frozen copy. The change itself is a build-system/dependency-management refactor. There is no direct evidence in the commit message or diff that this fixes a known security vulnerability, but vendoring can affect how future upstream security patches are applied and the STM32 register definitions are security-relevant because they control hardware protections (TrustZone, debug, flash, etc.).

This commit only adds two digital signature files for an already-released firmware version (v9.26.5). These signatures are used by users to independently verify that the published firmware binary matches what a specific signer reviewed. No code, no firmware binary, and no behavior of the device or software is changed. There is no security vulnerability here.

This commit fixes a security hygiene issue in the BitBox02 firmware's on-screen text-entry code. Previously, when a user typed a PIN or passphrase, the code briefly created an intermediate plain-text copy of the secret that was not securely erased from memory after use. The patch reads the secret directly into a zeroizing container so it is wiped when no longer needed. The same commit also removes a visual flicker on disabled navigation buttons and changes a simulator command-line flag from '--lock' to '--unlock'.

This commit replaces a standard text-formatting function (snprintf) with a small hand-written loop to display a six-digit Bluetooth pairing code on the BitBox02 hardware wallet screen. The change is described by the author as a cleanup to silence a compiler warning and make the numeric bounds more obvious. There is no direct evidence in the commit that this fixes an exploitable security bug.

This commit adds support for timestamp-based Bitcoin nLockTime values (values of 500,000,000 or higher) in the BitBox02 hardware wallet. Previously, such locktimes were rejected as invalid. The change also removes the on-screen RBF (Replace-By-Fee) status display from locktime confirmations and updates the Python library to require firmware version 9.27.0 when using timestamp locktimes. It is a feature addition with associated UI changes, not a security fix for a known vulnerability.

This commit adds signed release assertions for BitBox02 firmware version 9.26.5. These are text files plus cryptographic signatures that record the expected SHA-256 hash of the compiled firmware. They are part of the reproducible-build verification process and do not change any firmware code, wallet logic, or device behavior. There is no security vulnerability here.

This commit updates the BitBox02 Python library so it refuses to sign Bitcoin and Ethereum transactions or messages unless the hardware wallet is running a firmware version that supports the anti-klepto feature. Anti-klepto is a protocol that helps prevent a compromised device from leaking secret key material through biased randomness in signatures. The change removes older, less-protected fallback signing paths and bumps the library version to 8.0.0 because it now requires newer firmware.