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.