BitBox02 firmware

This commit tightens validation for Ethereum addresses used when signing typed messages (EIP-712). Previously, an address of any hex length after the '0x' prefix was accepted and padded to 32 bytes. Now only exactly 20-byte (40 hex character) addresses are allowed. This prevents malformed or truncated addresses from being silently encoded and signed, which could lead to a user approving a signature for an unintended address or contract.

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 firmware update fixes several security issues in the BitBox02 hardware wallet. The most important change is that when signing Bitcoin transactions, the device now verifies that the previous transaction output's script (the 'pubkey script') matches the keypath the wallet is being asked to sign with. This closes a gap where a malicious or buggy host app could ask the wallet to sign an input while claiming it belongs to a different address/key than it actually does. The update also hardens the U2F/FIDO workflow so that an attacker cannot swap or replay a different request while the user is still confirming one on screen, and it prevents Bluetooth pairing prompts from popping up on top of other wallet tasks. The changelog simply says 'Security improvements', so the vendor has not publicly detailed the exact vulnerabilities.

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 update changes how the BitBox02 hardware wallet displays very large transaction and swap amounts. Previously, long amounts were simply cut off with '...' on the device screen, which could hide important digits. Now the firmware either uses a smaller font to fit the full amount, or shows the full amount on a separate scrollable screen. The change also adds a length limit on externally supplied payment-request amounts to prevent abuse. This is a user-interface improvement that reduces the risk of a user approving a transaction whose displayed amount has been misleadingly truncated.

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 fixes a fee-warning gap in the BitBox02 Bitcoin signing flow. Previously, transactions that only sent money back to yourself (change outputs) or only carried an OP_RETURN message had no 'send amount' to compare the fee against, so the device would not warn even if the fee was huge. The patch now compares the fee to the total value of all transaction inputs in those cases, and still warns the user when the fee exceeds 10% of that total. It also updates the on-screen wording to say whether the percentage is relative to the send amount or to all inputs.

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 changes how the BitBox02 hardware wallet shows large transaction and swap amounts on its small screen. Previously, long amounts were silently cut off with '...', which could hide the true value from the user. Now the device either shrinks the font or shows the full amount on a scrollable screen. The change also adds checks to reject absurdly long externally supplied swap amount strings. The main security benefit is that users can now verify the complete amount they are approving, reducing the chance of being tricked by a truncated value.

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 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.