BitBox02 firmware

This commit adds an extra on-device confirmation step when signing Ethereum typed messages (EIP-712). Before walking through the message fields, the BitBox02 now shows the user the 'primary type' (for example 'Authorize' or 'Revoke'). The goal is to prevent a malicious computer program from swapping one message type for another that has the same field shapes, because the device would then bind the user-approved signature to the wrong type. It is a hardening fix rather than a clear-cut vulnerability patch.

This commit adds support for timestamp-based Bitcoin transaction locktimes in the BitBox02 hardware wallet. Previously, locktimes at or above 500,000,000 were rejected; now they are accepted and shown to the user as a UTC date and time. The commit also removes the on-screen 'RBF' (Replace-By-Fee) indicator because RBF is a network policy, not a guaranteed property of the signed transaction. This is a normal feature addition with no obvious security bug, though it changes what transaction details users see before signing.

This commit is a build-system and test-infrastructure fix. It changes Rust conditional-compilation flags so that unit tests can compile and run on a normal computer (host target) instead of only on the embedded device. It also limits the custom panic handler to bare-metal ARM builds and exposes some test-only helper functions under the test configuration. There is no change to runtime security behavior for end users.

This commit improves how sensitive cryptographic key material is erased from memory in the BitBox02 hardware wallet. It wraps temporary derived keys (SHA-512 outputs and a stretched seed encryption key) with a Rust helper that automatically clears the memory when the value is no longer needed. This reduces the chance that fragments of private-key-related material remain in RAM longer than necessary, but it is a hardening change rather than a fix for an obvious, directly exploitable bug.

This change makes sure that production versions of the BitBox03 hardware wallet do not include SEGGER RTT (Real-Time Transfer) debug sections. RTT is a debugging feature that lets a connected computer exchange data with the device while it runs. In a production device, leaving those debug sections linked into the final firmware could give an attacker with physical access an extra channel to read memory or interact with the device. The patch marks release builds as 'production' and makes the linker throw an error if any RTT control or buffer sections are still present.

This commit only adds documentation comments and does not change any code behavior. It explains that when a host computer does not provide an anti-klepto nonce commitment during Bitcoin or Ethereum signing, the device falls back to a historical signing mode that lacks anti-klepto protection. The actual fallback behavior already existed; this change just documents it more clearly.

This commit only adds documentation comments and does not change any program behavior. It explains that when a security feature called anti-klepto is left out of older Bitcoin and Ethereum signing requests, the device falls back to a historical, deterministic signing method that lacks anti-klepto protection. For EIP-712 typed messages, it falls back to plain RFC6979. No code logic is altered.

This commit improves how the BitBox02 hardware wallet generates the secret seed used to back up cryptocurrency. It adds an extra source of randomness—derived from the user's password—into the seed creation process. The change also documents that the seed already mixes randomness from the device's main chip, its secure chip, and factory-installed randomness. There is no direct evidence in the commit that this fixes a known exploitable vulnerability; it appears to be a defense-in-depth improvement to make the seed harder to predict or weaken.

This commit only adds and updates comments in the code to better explain where the randomness used to create wallet seeds comes from. It does not change any actual behavior, logic, or security properties of the firmware.

This commit fixes a class of low-level memory-safety bugs where Rust code was given buffers containing uninitialized bytes. Rust's rules require every byte of a slice to be initialized, even if the function will overwrite them. Passing uninitialized memory could let the compiler make unsafe assumptions, but the commit message says no actual exploit or data leak was observed. The fix initializes buffers before handing them to Rust and switches some helpers to use raw pointers so they can legally write into uninitialized memory.

This commit only adds a new test to the firmware's Bitcoin transaction-signing code. The new test takes existing test vectors, injects the signatures produced by the firmware, and then verifies that the resulting transaction is valid and its scripts pass. It does not change any production signing logic, fix a bug, or alter behavior visible to users.

This commit is a minor code cleanup in a Python helper script. It moves existing bootloader connection logic into a small nested helper function to satisfy a style checker (pylint's limit on the number of return statements). No behavior changes, no security fixes, and no new functionality were introduced.

This commit is a large test-infrastructure change. It adds a new Rust crate that generates shared Bitcoin transaction test vectors as PSBTs, updates firmware tests to use those vectors, and removes some older overlapping tests. There is no change to production firmware code, no new feature exposed to users, and no fix for a security bug.

This commit is a routine release-management update. It adds signed build assertions for three new BitBox02 firmware versions (9.26.2, 9.26.3, 9.26.4) and updates the release documentation and build helper script. The build script now deletes the v9.26.3 git tag after fetching because the released binaries accidentally included pre-release metadata, so the exact released binary can only be reproduced from the unsigned commit hash, not from the final tag. There is no code change to the firmware itself in this commit, and nothing in the materials suggests a security vulnerability.

This commit fixes a bug in how the BitBox02 hardware wallet wipes files from its SD card. Before erasing a file, the device now checks the file's reported size against a safe maximum. Without this check, a tampered SD card could claim a file is gigantic, causing the device to get stuck in a long overwrite loop. The fix prevents a denial-of-service style attack where a malicious or corrupted SD card could make the device hang or behave unexpectedly during cleanup of old backups. The commit says it mitigates the impact of CVE-2026-6682 without changing the third-party FAT filesystem code.

This update adds a safety check when the BitBox02 hardware wallet mounts a microSD card. A malicious or deliberately malformed FAT filesystem could trick the device's file-system library into placing user data inside attacker-controlled bookkeeping sectors, potentially leading to code execution or data corruption when the device later reads or writes files. The fix validates that the filesystem's internal layout is sane before using it, and leaves the third-party library code unchanged.

This commit updates the third-party FatFs file-system library inside the BitBox02 firmware from version R0.14b to R0.16 plus an upstream patch. The change is a routine dependency refresh: it replaces the vendored source files with the newer upstream release while keeping BitBox's existing configuration (long-file-name support, tiny mode, code page 850, fixed timestamps, no exFAT, no labels, no 64-bit LBA). Most of the visible diff is documentation and metadata; the actual C source files (ff.c, ff.h, ffconf.h, diskio.c, etc.) are updated wholesale. The commit message does not claim to fix any security issue, and no independent security advisory or CVE is supplied.

This commit adds a brand-new firmware feature called BitBoxSync, which lets the BitBox02 hardware wallet participate in a sync service by proving its identity, signing login/admin intents, and decrypting namespace encryption keys. The code introduces new cryptographic operations (Ed25519 signatures, X25519 key exchange, HKDF, ChaCha20-Poly1305) and new user-confirmation prompts. It is a large feature addition, not a documented security fix. There is no direct evidence of a vulnerability in the diff, but any new crypto API surface carries implementation risk and should be reviewed carefully.

This commit simply swaps in newer pre-built bootloader stage1 binary files (version 1.2.2 replacing 1.2.1) for four BitBox02 hardware variants and updates the corresponding checksum list. The actual code inside the new binary files is not shown in the diff, and no description of why the update was made is provided. There is no visible evidence in the commit that this fixes or introduces a security problem.

This update fixes the BitBox02 bootloader's firmware-erase routine. Previously, when erasing leftover padding after a firmware update, the bootloader started erasing at the exact page where the firmware ended. Because flash memory can only be erased in larger fixed-size blocks, this could leave the final firmware chunk sharing an erase block with padding. That shared block might be erased unintentionally, potentially corrupting the newly written firmware. The fix aligns the erase start to a full erase-block boundary and re-checks whether pages are already erased before acting. The changelog explicitly calls this a fix for 'partially erased flash blocks.'

This commit adds production bootloader upgrade files for the BitBox02 hardware wallet and updates build scripts to use them. It is a routine asset-management change: replacing placeholder development hashes with real signed production binaries and enabling previously disabled build targets. There is no code change to how the device operates, no reported vulnerability, and no indication of a security incident.

This commit fixes a build script used only for development/testing versions of the BitBox02 bootloader upgrade. It makes the development-stage1 bootloader images unsigned again, while keeping production images fully signature-verified. The change is a build/development tooling fix, not a security patch for shipped devices.

This BitBox02 firmware update is a broad security patch that fixes several independent bugs: it prevents a maliciously oversized USB report from overflowing memory, stops a corrupted Bluetooth pairing database from being read or written with invalid lengths, allows full-size firmware images in the bootloader, hardens how Bitcoin, Cardano, Ethereum, and typed-data (EIP-712) transactions are parsed and shown to the user, and adds a user confirmation before creating backups. The changes are defensive and reduce the chance that an attacker could trick the device into signing something the user did not intend.

This commit fixes a bootloader bug where the device rejected firmware updates that used the maximum allowed size. The off-by-one check meant legitimate full-sized firmware images could not be installed, potentially blocking updates. The fix changes the limit from 'one less than maximum' to 'maximum'. There is no direct evidence this was exploitable as an attack, but any bug in firmware-update verification deserves attention.

This is a large firmware commit that adds a new two-stage bootloader update mechanism for the BitBox02 hardware wallet. It replaces the old single bootloader with a small, fixed 'stage0' plus a separately signed 'stage1', and ships a special firmware image that can install both stages onto existing devices. The change also updates how firmware signatures are computed so that the product type is included in the hash, which is a security improvement. Because the commit is a major architectural rewrite and includes prebuilt binary blobs whose source is not shown, it carries normal supply-chain and implementation risks, but no specific vulnerability is visible in the diff.