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 is a routine Python code refactor. It moves an existing 'reset session' command from one internal class to another and adds a version check so older firmware simply skips it. There is no security bug being fixed here; it is purely organizational cleanup and test updates.

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 adds a new recovery-word entry screen for the upcoming BitBox03 hardware wallet. It is a large feature patch: it introduces a dedicated BIP39 wordlist keyboard, a new recovery-words review screen, and changes how the device handles going back versus cancelling during seed restoration. There is no direct evidence in the commit that this fixes a security vulnerability; it reads as a user-experience and hardware-support change. The code does improve clarity around cancel/back handling and adds confirmation prompts before aborting a restore, which is a sensible defensive design, but it is not presented by the vendor as a security fix.

This commit improves the BitBox02 hardware wallet's Ethereum token-approval screen. When a user signs an ERC20 token transfer, the device now also shows the token's smart-contract address if the token symbol is ambiguous (the same ticker, like 'UNI', is used by multiple contracts) or if the token is completely unknown. This helps prevent 'look-alike' token scams where a malicious contract uses a familiar symbol but is actually a worthless or harmful token. The change also blocks payment requests for unknown tokens. It is a defensive hardening patch, not an exploit fix for already-broken code.

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 hardens the BitBox02 firmware so it stops trusting that incoming text strings are valid UTF-8 or plain ASCII. It replaces risky C string copies with length-checked, UTF-8-aware helpers, rejects non-ASCII characters at UI boundaries, and prevents malformed multi-byte characters from being cut in half when labels or device names are truncated. The changes reduce the chance that an attacker could crash the device or hide parts of a message by sending carefully crafted strings.

This commit fixes a coding guideline violation in the BitBox02 factory setup code. A 32-byte buffer that receives output from a Rust function was not initialized to zeroes before use. The accompanying documentation now explicitly requires such initialization. The actual security impact is limited because the buffer is immediately filled by a hash function if it succeeds, and failure paths in this specific factory-setup function appear to abort rather than leak the uninitialized buffer. However, uninitialized stack memory is a well-known source of bugs, so the change is defensive.

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 tweaks how the BitBox02 hardware wallet displays a payment-request memo on screen. It changes the label from 'Memo from\n\nMerchant' to 'Memo from: Merchant' and makes the screen scrollable so long merchant names don't get cut off. It also updates test snapshots and bumps the firmware version to 9.27.2. There is no indication this fixes a security vulnerability; it appears to be a user-interface improvement.

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 a progress bar that appears while the BitBox02 is loading large Ethereum transaction data from a connected computer. It is a user-experience improvement, not a security fix. The code only changes how progress is displayed during normal data streaming and adds tests to verify the progress bar shows the right percentages.

This commit adds a configuration file for OpenOCD, a debugging tool used during hardware development and testing. It tells the debugger how to connect to an STM32U5 test board using a J-Link adapter. There is no change to firmware code, no user-facing feature, and no security-relevant behavior.

This commit only adds explanatory comments to Python type-stub files describing what happens when an optional anti-klepto host nonce commitment is left out. It does not change any firmware logic, cryptographic code, or default behavior. The comments document an already-existing fallback mode, making the behavior more transparent rather than introducing a new vulnerability.

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 only updates documentation comments in automatically generated Python type-stub files for the BitBox02's protocol messages. It explains that leaving out an optional 'host nonce commitment' field causes the device to fall back to older, non-anti-klepto signing behavior. No code logic, firmware behavior, or API rules were changed.

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 adds support for signing Bitcoin messages using keys under a new keypath prefix, m/48', alongside the previously allowed m/45'. It is a feature expansion, not a fix for a security flaw. The change is documented in the changelog and version bump, with no indication of a security issue.