BitBox02 firmware

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 routine release bookkeeping change. It updates the version number from v9.27.0 to v9.26.5 and reorganizes the changelog so that two bug fixes are listed under the new v9.26.5 release section instead of 'Unreleased'. The actual bug fixes were made in earlier commits and are not shown here. There is no code change that could directly affect device security.

This commit turns off a feature called BitBoxSync by default. Unless a developer explicitly enables it during build, any request to use BitBoxSync will now receive a standard 'disabled' error. The change is framed as temporary while API changes are pending. It is a defensive gating change, not a fix for a known active attack.

This commit replaces an unbounded task queue inside the BitBox02 firmware's Rust executor with a fixed 16-slot ring buffer. It also adds a hard limit of 16 active tasks and protects queue access with critical sections so interrupt-driven code and the main loop don't corrupt the queue. The change removes a third-party queue dependency and adds unit tests. It is a defensive hardening patch: it prevents memory exhaustion from an ever-growing queue and removes allocation from interrupt paths, but it does not by itself fix a known exploitable bug.

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 replaces a custom-built notification helper (a 'waker') inside the BitBox02 firmware's Rust code with a built-in, memory-safe no-op version. The old helper used heap memory and reference counting (Arc), which could be freed by interrupt routines while the memory allocator was already busy. The change removes that helper entirely and uses a static no-op waker instead, preventing a potential use-after-free or heap corruption issue during asynchronous task polling.

This commit fixes a concurrency bug in the BitBox02 hardware wallet's USB handling. When a U2F (two-factor authentication) workflow is still running on the device's screen, a new hardware wallet request could previously start and reset or cancel the U2F workflow, potentially corrupting its user-interface state. The fix makes new hardware wallet requests return 'busy' while any U2F workflow is active, and tracks U2F workflow lifetimes independently of their public result state.

This commit fixes a bug in how the BitBox02 hardware wallet's user-interface library clears style transitions. Previously, passing 'None' for a transition style would store a null pointer in LVGL's style state, which could later be dereferenced during state changes and crash or corrupt the UI. The patch now removes the local transition property instead of storing a null pointer, and wraps the transition setter in a safer Rust type. It also tightens other optional pointer-style setters and grid-template inputs so null pointers cannot be silently stored. The change is defensive hardening rather than a demonstrated remote exploit, but on a security device any UI crash or memory corruption is relevant.

This commit fixes a visual glitch on the BitBox02 hardware wallet screen. During some asynchronous security operations, the screen briefly showed the 'waiting' screen between two user-interface steps, causing an annoying flash. The change tells the device to keep showing the previous screen frame while it is still busy processing a USB request locally, instead of redrawing the waiting screen. It is a user-experience fix, not a cryptographic or access-control fix.

This commit adds a warning screen to the BitBox02 hardware wallet whenever a long message or value is about to be shown in a truncated form. Previously, the device could silently cut off the end of very long transaction details, message data, or policy names, potentially hiding important information from the user before they approve an action. The fix shows a 'Warning: the next value is too large to display in full' screen first, so users know they are not seeing the complete content.

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 firmware update relaxes the rules for valid Ethereum typed-data (EIP-712) names so they can contain a colon (:), which some decentralized apps use as a namespace separator. Member names still cannot contain colons. The change is presented as safe because a colon cannot be confused with the punctuation that separates type names, fields, and arrays in EIP-712 encoding.

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 fixes two memory-handling bugs in the BitBox02 hardware wallet's Rust LVGL UI bindings. First, line widgets were storing point data in dynamically allocated memory attached to the LVGL object and freeing it when the object was deleted; if the same points were shared or the attachment logic failed, this could lead to crashes or memory corruption. The fix requires callers to pass only statically allocated, never-freed point slices. Second, style-transition property lists were accepted without checking for a required terminator marker; an unterminated list could cause LVGL to read past the end of the array, leading to crashes or undefined behavior. The commit adds validation that panics at construction time if the terminator is missing.

This commit is a user-interface redesign for the BitBox03 hardware wallet: text buttons like 'Yes/No' and 'Back/Next' are replaced with icon buttons. It also adds a hidden demo screen that can only be opened in the simulator by setting the device name to a special test value. There is no direct security vulnerability visible in the code change, but it touches code that handles user confirmation and cancellation, so any bug here could affect whether a user correctly approves or rejects a sensitive action.

This commit adds a new Python client feature called BitBoxSync to the BitBox02 Python library. It introduces generated protobuf code, new API methods to request identity keys, sign various sync-related intents, and unwrap an encrypted namespace key, plus a demo menu in the developer test tool send_message.py. There is no indication in the commit that this fixes a security bug; it appears to be a normal feature addition.

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.