BitBox02 firmware

This commit adds an optional mode for signing Ethereum typed messages (EIP-712) that skips the anti-klepto protocol, falling back to normal deterministic signatures. The change is intentional and documented: some DeFi apps need signatures that are reproducible by other wallets, which the anti-klepto protocol prevents. The feature is gated behind a new host flag and requires firmware v9.26.0 or newer. It does not remove anti-klepto from other signing paths such as Bitcoin or regular Ethereum transactions.

This commit refactors how random numbers are generated during the backup verification workflow. Previously, the code called a low-level device function directly; now it uses a hardware abstraction layer (HAL) interface so the same code can be tested with a mock random source. The change itself is a code-quality/testability improvement and does not appear to fix an active security vulnerability, but it touches the code that creates the random word-order challenges used to verify a user's seed backup.

This commit is purely a test-suite update for the BitBox02 hardware wallet's Ethereum transaction signing. It adds unit tests that verify the new 'streaming' mode for large transaction data produces the same cryptographic signatures as the older non-streaming mode, and updates test data files. There is no change to production firmware code or user-facing behavior, and nothing in the commit suggests a security vulnerability.

This commit adds new message definitions and generated code to support streaming large Ethereum transaction data in chunks, but it does not implement the actual streaming logic. Existing tests are updated only to include the new optional field set to zero, meaning the current behavior is unchanged. There is no indication this is a security fix or introduces a vulnerability.

This commit is a simple internal cleanup in the BitBox02 firmware's Rust code. It removes a shortcut (a 're-export') that made test-only user-interface helpers available under an old module path, and updates all test files to import those helpers directly from their new location. There is no change to the actual device behavior, no bug fix, and no security impact.

This commit rewrites the BitBox02 hardware wallet's main firmware loop from C to Rust. It is a large refactoring change that moves core USB, Bluetooth/UART, and workflow handling into Rust. The change itself is not a security fix and does not introduce an obvious vulnerability in the diff, but any rewrite of security-critical firmware code carries a risk of subtle behavioral differences or memory-safety edge cases at the C/Rust boundary. The commit message and diff do not describe any security issue or credit a researcher.

This commit turns on a stricter compiler warning that catches risky pointer casts in C code, and fixes the resulting warnings. The changes replace direct casts from byte buffers to larger types (like treating a raw byte array as a 32-bit number or USB frame) with safer memcpy-based copies. The commit message explicitly frames these as classes of undefined behavior (alignment and strict-aliasing issues) that could lead to miscompilation or incorrect reads. It is a hardening/correctness patch rather than a fix for a known exploitable bug, but the affected code paths include bootloader pairing-code handling, firmware version parsing, USB packet processing, and BLE pairing-code display.

This commit removes a duplicate low-level binding to a secp256k1 cryptographic function and replaces its use with an equivalent, already-vetted wrapper from the project's dependency on the bitcoin::secp256k1 Rust crate. It is a code cleanup/refactoring change with no security-relevant behavior change visible in the diff.

This commit is a build-system refactor: it moves the secp256k1 cryptographic library dependency into a new Rust crate called bitbox-secp256k1 so it can be built with normal Cargo tooling instead of CMake. The actual cryptographic functions (signing, nonce commitments, DLEQ proofs, etc.) are copied almost unchanged from existing modules into the new crate. There is no direct evidence in the commit that this fixes a security vulnerability or introduces a new exploit.

This commit rewrites a small piece of the BitBox02 factory-setup code from C to Rust. The code verifies a cryptographic signature on the device during factory setup. The change itself is a routine refactoring: it removes the old C secp256k1 library call and replaces it with an equivalent Rust call. There is no indication in the commit that this fixes a known security bug, and the new Rust code includes tests for invalid inputs. On its own, this looks like a defensive hardening/cleanup change rather than a vulnerability fix.

This commit is a straightforward internal refactoring: it moves the device-reboot-into-bootloader function behind a new 'System' hardware-abstraction trait so the rest of the Rust code calls it through a generic interface rather than directly. The actual reboot behavior, safety checks (a user confirmation screen), and underlying C function are unchanged. There is no new vulnerability here; it is normal code cleanup.

This commit rewrites a small piece of firmware logic from C to Rust. The logic decides whether the BitBox02 Nova hardware wallet should use Bluetooth or USB for communication. There is no obvious security bug introduced by the change; it appears to be a routine language port with matching behavior and added unit tests.

This commit updates the BitBox02 firmware's vendored copy of the Rust 'miniscript' library to version 13.0.0, along with its dependency 'hex-conservative'. The stated reason is to reduce firmware size by about 30 KB. The change is a routine dependency refresh; the commit message and diff do not describe any security bug being fixed, and no independent security advisory is supplied.

This commit is a code cleanup and test-improvement change. It moves two device-attestation helper functions from a direct hardware call into a software 'hardware abstraction layer' (HAL) so the code can be tested without the real device. It also adds unit tests that simulate the attestation process. There is no indication this fixes a security bug or introduces a new vulnerability.

This commit is a bulk license-header cleanup. It replaces long, multi-line copyright and Apache-2.0 license notices at the top of 429 source files with a single, standardized machine-readable tag: 'SPDX-License-Identifier: Apache-2.0'. No program logic, build rules, or file contents other than the header comments were changed. It does not introduce or fix any security vulnerability.

This commit is a routine code-style fix. It updates the Python formatter (black) configuration so the linter uses the correct pyproject.toml file, and reformats two Python files to match the new style rules. There are no security changes to the firmware or any sensitive logic.

This commit only fixes a typo in a code comment (docstring). It changes the description of when a function can return an error, matching the fact that the function now receives the private key directly rather than fetching it from a locked keystore. No actual code behavior is changed.

This is a small internal cleanup in the BitBox02 firmware's on-screen text input component. A helper function that fetches BIP39 seed words was simplified so callers no longer check its return value; the helper itself now aborts on failure. There is no security vulnerability here—just a minor code-style refactor that keeps the same failure behavior.

This commit simply moves a helper function that looks up a BIP39 word by its index from one source file to another. The function's behavior and the callers' logic are unchanged; it is a code cleanup with no security impact.

This commit is a simple code reorganization: it moves functions that perform secp256k1 cryptographic signing from a file named keystore.rs into a file named secp256k1.rs. The actual behavior of the code, including how private keys are used and how signatures are produced, does not change. It is a refactoring, not a security fix or vulnerability.

This commit updates the Rust compiler toolchain from an unspecified earlier version to Rust 1.92 for the BitBox02 hardware wallet firmware. It also refreshes many vendored third-party Rust libraries (such as libc, hashbrown, getopts) and build tools (cbindgen, bindgen). The stated reason is compatibility with the new toolchain, including a breaking change around panic handling. There is no direct evidence in the commit that this fixes a known security vulnerability, but toolchain and dependency updates can affect security-relevant behavior such as memory safety, panic handling, and type definitions used in cryptographic code.

This commit is a straightforward internal refactoring: it moves the device attestation signing function behind a hardware-abstraction-layer (HAL) interface so the code can be more easily tested. The actual cryptographic operation and the data it uses remain unchanged. There is no indication this fixes or introduces a security vulnerability.

This commit is a large internal refactoring of the BitBox02 firmware. It adds a new secure-chip key-derivation function (KDF) to the hardware abstraction layer (HAL) and threads that HAL through many existing functions so they can use it. The change touches 31 files and many tests, but it does not appear to introduce a new security vulnerability on its own. It is a structural change that prepares the code for using the secure chip's KDF more consistently.

This commit adds a new 'Change Password' feature to the BitBox02 hardware wallet. Instead of resetting the device and restoring from a backup, users can now change their device password directly. The wallet re-encrypts the stored seed with the new password while keeping the same accounts and identity. The change is a normal product feature, not a security fix, but it touches sensitive crypto code that protects the user's funds.

This commit adds two digital signature files for the BitBox02 firmware version 9.24.0. These signatures are used to publicly verify that the released firmware binaries are authentic and have not been tampered with. There is no code change and no indication of a security vulnerability.