BitBox02 firmware

This commit adds a safety check to the BitBox02 hardware wallet's backup loading code. It now rejects backup files that claim to contain a 'seed' longer than 32 bytes. Without this check, a tampered or malformed backup could potentially cause memory corruption or unexpected behavior when the seed is later used. The change is defensive and includes a new test to confirm oversized seed lengths are rejected.

This commit adds a length check before showing a Bitcoin policy key on the BitBox02 device screen. Previously, an extremely long key string could be displayed or processed without a size limit. The fix rejects keys whose on-screen text exceeds the maximum body size the confirmation UI can handle, preventing potential display truncation, UI confusion, or memory-related issues during policy registration.

This update fixes a bug in how the BitBox02 hardware wallet reads backup files from an SD card. A tampered backup file could claim to contain a seed longer than the 32-byte limit, which previously caused the device to panic (crash) when listing backups. The fix rejects such malformed files, and a new test confirms the behavior.

This commit fixes a user-interface safety issue in the BitBox02 hardware wallet's Bitcoin multi-signature policy registration. Previously, a very long policy key could be approved by the user even though the device could not display the full key on its screen. The change now rejects keys whose on-screen confirmation text exceeds the device's maximum label size, preventing a scenario where a user might unknowingly approve a key they cannot fully verify.

This commit changes how users confirm sensitive actions on the BitBox03 hardware wallet. It replaces a 'hold/long-press to confirm' button with a 'slide to confirm' gesture, similar to the swipe gestures used on many smartphone lock screens. There is no indication of a security bug being fixed; it appears to be a user-interface design change.

This commit adds a new 'slide to confirm' user-interface control to the BitBox03 hardware wallet. It is a deliberate UX/security feature for high-risk actions (like approving transactions), replacing a simple tap with a drag gesture. The code also includes hardening against accidental or glitched touch input, and a full suite of simulator tests. There is no direct evidence in the commit that this fixes an active security vulnerability; it reads as a planned product improvement.

This commit fixes a UI cleanup bug in the BitBox02 hardware wallet's U2F (Universal 2nd Factor) feature. Previously, a 'Refresh webpage' screen could be destroyed without clearing the pointer that tracked it, potentially leaving a dangling reference. The patch adds a custom cleanup handler that nulls out the pointer when the screen is removed. There is no direct evidence in the commit of a security exploit, but use-after-free or dangling-pointer bugs in firmware can sometimes have security implications if they lead to crashes or memory corruption.

This commit fixes how a small on-screen reminder (the 'nudge screen') for U2F is created, tracked, and cleaned up. Before the fix, the code could lose track of the reminder screen or mishandle its removal, which might cause display glitches or memory issues. The patch makes cleanup more reliable by tying the global pointer to the screen's actual destruction.

This commit fixes a bug in the U2F confirmation workflow where the firmware could read a result from memory that had already been cleared, potentially giving an incorrect success/failure answer. The fix simply reads the result before wiping the state. It is a memory-use-order bug rather than an obvious exploit, but in a security device it could lead to wrong authorization decisions.

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 fixes a bug in the BitBox02 factory setup tool that receives debug messages over SEGGER RTT. Previously, if a message said it contained more bytes than were actually received, the code would copy whatever leftover data happened to be sitting in a stack buffer into a factory command. That could leak uninitialized memory or cause the device to act on garbage data. The fix adds a simple length check and rejects incomplete frames.

This commit fixes a minor but real security hygiene issue in the BitBox02 Plus hardware wallet. Before the patch, a 32-byte buffer meant to hold freshly generated random bytes for Bluetooth Low Energy (BLE) pairing security was not initialized. The code then immediately fills it with random data, so in normal operation the buffer is overwritten before use. However, if the random-generation function were to fail partially or unexpectedly, uninitialized memory could be used, which is poor practice for cryptographic material. The patch initializes the buffer to zeros as a safety net.

This commit adds a hard limit on how deeply nested Ethereum typed-message (EIP-712) structures can be when the BitBox02 hardware wallet signs them. Without the limit, an attacker could craft a message type that refers to itself over and over, causing the firmware to recurse until it runs out of stack memory and crashes. The patch caps recursion at 16 levels, validates the whole type tree before any user interaction or host callbacks, and adds tests for the boundary.

This commit adds a safety limit to how deeply nested a Bitcoin policy (a set of spending rules) can be before the BitBox02 hardware wallet will reject it. Without such a limit, an attacker could craft an unusually deep policy that causes the wallet's stack memory to overflow during normal processing, potentially crashing the device or causing undefined behavior. The fix caps the allowed depth and adds tests to confirm both the boundary and a known problematic shape are blocked.

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.