BitBox02 firmware

This commit simply alphabetically sorts three lists of C function, variable, and type names that the Rust build process is allowed to reference. No names were added or removed, only reordered. It has no effect on device behavior or security.

This commit adds a small helper function that reports how many more wrong password attempts are allowed before the device wipes itself. It also removes a testing-only restriction so the underlying counter can be read in normal builds. There is no security fix or vulnerability here—just a code cleanup to simplify a later change.

This firmware update fixes a timing inconsistency in how the BitBox02 hardware wallet handles device-unlock failures. Previously, only a wrong password triggered an immediate device reset after 10 failed attempts, while other unlock errors (such as a secure-chip malfunction) delayed the reset until the next unlock attempt. Now any serious unlock error causes the reset right away, making behavior more predictable and preventing a window where a failing secure chip could leave the device in an ambiguous state.

This commit only changes test code in a Rust firmware file. It replaces runtime hex string decoding with a compile-time `hex!()` macro and removes unnecessary `.unwrap()` and `.try_into()` conversions. There is no change to production behavior, no security fix, and no vulnerability introduced.

This commit is purely a code formatting change. It reorders two #include lines in a C header file so they are sorted alphabetically, matching the project's clang-format style. No functionality was changed, no security bug was fixed, and no new attack surface was introduced.

This commit is a developer-experience (DX) improvement that adds a debug breakpoint instruction inside the firmware's Rust panic handler. When the firmware crashes, it will now halt at a breakpoint if a debugger is attached, making it easier for developers to inspect the crash. It does not change any security-sensitive behavior in normal operation and does not introduce a vulnerability.

This commit only adds a new unit test and refactors existing test code to use a different hex literal helper. It does not change any production firmware behavior. The new test verifies that when a wrong password is entered during device unlock, the user sees a 'Wrong password, 9 tries remain' message and the device stays locked. There is no security fix or vulnerability here.

This commit only adds a single space after two type casts in the same C source file. It is a pure code-formatting change with no functional difference and no security relevance.

This commit only removes unnecessary calls to a test helper named fake_reset() inside unit tests. It does not change any production code that runs on the actual BitBox02 device, so it cannot affect real users or introduce a security vulnerability.

This commit only reformats three lines of C code using clang-format. It moves function arguments onto a single line instead of splitting them across two lines. No logic, behavior, or security properties of the code change.

This commit fixes a programming bug where the firmware could crash with a panic if the secure keystore returned certain error codes that the Rust code did not know how to handle. The patch adds mappings for two newly introduced error conditions (decryption failures and a key-stretching failure for retained seed backup) so they are reported gracefully instead of crashing the device. A crash could cause denial of service or unexpected device behavior, but there is no direct evidence in the commit that it could be exploited to steal funds or bypass security.

This commit is a routine internal code reorganization. It moves the keystore's `is_locked()` check from a low-level C-binding module into a higher-level Rust wrapper, renaming the original function to `_is_locked()` so the compiler flags any leftover direct uses. There is no change to what the function does or to any security behavior.

This commit is a routine internal code reorganization in the BitBox02 firmware. It moves a cryptographic helper function, used in the anti-klepto signing protocol, from a low-level C-wrapping module into a higher-level Rust keystore module. The actual behavior of the function does not change; callers are simply updated to use the new location. There is no indication this fixes a security vulnerability.

This commit is a routine internal code reorganization. It moves the function that creates secp256k1 signatures from a low-level Rust-C binding module into a higher-level Rust keystore module, and renames the original function so the compiler catches any remaining callers. The actual signing behavior, cryptographic math, and security properties are unchanged.

This commit is a routine internal code reorganization. It moves the keystore lock() function call from a low-level C wrapper into a higher-level Rust module and renames the original function so the compiler can catch any missed references. There is no change to what the function does or to any security behavior of the device.

This commit only updates the CHANGELOG.md file to add a new version heading (v9.24.0). It contains no code changes, no bug fixes, and no security-related content. It is a routine documentation/release-management edit.

This commit is a minor performance tweak to the function that checks whether an SD card is inserted. It reduces the wait time between status checks from 100 milliseconds to 5 milliseconds, while increasing the number of checks so the total maximum wait remains about one second. There is no security-relevant change here.

This commit only adds a new Rust helper library (hex_lit) to make test code easier to read. It replaces runtime hex decoding and ugly byte-string literals with compile-time hex macros in unit tests. There is no change to production firmware behavior, no security fix, and no vulnerability introduced.

This commit is a routine code cleanup. It removes a placeholder 'do nothing' function called ui_util_on_event_noop and replaces its uses with NULL, because the user-interface system already allows the on_event handler to be NULL. There is no security-relevant change.

This commit rewrites how on-screen buttons and gestures in the BitBox02 hardware wallet talk to each other. Previously, pressing a button or completing a gesture posted a global 'event' that other parts of the screen had to listen for, which the developer describes as 'racy.' The change replaces that with direct function callbacks, so a button press immediately calls the intended action in a predictable order. This is a code-quality and robustness improvement rather than a fix for a known exploitable bug, but race-prone event systems can in principle lead to wrong buttons being acted upon or actions happening twice.

This commit is a routine code cleanup: it removes two unused or trivial UI helper files (entry_screen and confirm_button) and inlines their simple behavior directly where needed. There is no security-relevant change, no bug fix, and no functional change to how the device handles sensitive actions like confirming transactions or entering passwords.

This commit is a simple code cleanup: it renames variables and parameters from 'callback param' to 'user data' across several UI component files in the BitBox02 firmware. No behavior changes, bug fixes, or security fixes are present. It is purely a naming convention update to match standard terminology.

This commit changes how the BitBox02 hardware wallet verifies a newly stored seed. Instead of re-stretching the user's password through the secure chip (which consumes several secure-chip operations), it reuses the already-stretched encryption key. This is a performance/reliability improvement to avoid hitting a secure-chip throttling limit after many device resets or restores. The commit itself is a defensive hardening change, not an obvious vulnerability fix, but it slightly changes the security assumptions around seed verification.

This commit is a performance and reliability improvement, not a security vulnerability fix. It changes how a hardware wallet sets up a new wallet seed so that it performs fewer operations on the secure chip. Previously, after creating or restoring a seed, the software immediately unlocked the wallet with the same password, which wasted secure chip operations. Now the creation/restore step also unlocks the wallet, reducing secure chip events by 5. This helps avoid hitting the secure chip's throttling limit (133 events) when users repeatedly reset or restore their device.

This commit fixes a single typo in a code comment (docstring). The example Bitcoin keypath was missing an apostrophe in one place (m/84/0'/0'/0/0 changed to m/84'/0'/0'/0/0). No actual program code was changed, so there is no functional or security impact.