BitBox02 firmware

This commit changes how the BitBox02 hardware wallet generates random numbers used to create secret keys and encrypt stored data. Previously, the firmware used a single 32-byte random value from the microcontroller. After this change, it mixes three sources: the microcontroller's random generator, the secure chip's random generator, and a fixed 32-byte 'factory randomness' value stored in a special flash memory location. The commit also adds a factory script to write that fixed value into devices during production. The change is a defensive hardening measure, not a fix for an active bug, but it introduces a new dependency: if the factory randomness is not actually random or is reused across devices, it could weaken security instead of strengthening it.

This commit changes how the BitBox02 hardware wallet warns users about very large Ethereum transaction data and typed messages. Previously, large transaction data was shown only as a byte count with the message 'too large to display.' Now the device shows a preview of the actual hex data (up to the screen limit, with a '...' truncation indicator) and adds a warning screen saying the value is too large to display in full. The change also reuses the same truncation logic already used for EIP-712 typed messages, so both flows behave consistently. The commit does not fix a vulnerability, but it improves the user's ability to inspect what they are signing.

This commit is a code-quality refactor for unit tests only. It introduces a small Rust helper macro called async_test::test that lets developers write async test functions directly, instead of manually wrapping async code in a block_on() call. The change touches many test files but does not alter any production firmware behavior, user-facing functionality, or security logic.

This commit adds a new optional 'payment request' field to Ethereum EIP-1559 signing requests in the BitBox02 firmware's protocol definitions and generated code. It does not contain any actual implementation of how that field is processed, validated, or shown to the user. Based only on the code changed here, there is no identifiable security vulnerability.

This commit rewrites the firmware's USB report queue from C to Rust. It is a large refactoring that replaces a hand-written C ring buffer with a Rust VecDeque wrapped in a C-compatible FFI. The change touches the core USB communication path used by both the main hardware wallet (HWW) and U2F interfaces. There is no explicit security bug fixed or introduced in the diff, but any mistake in the boundary between C and Rust could affect how the device receives and sends USB messages.

This commit extends an existing Ethereum data-streaming feature so it also works for EIP-712 typed messages with large data fields (e.g., a 50 KB 'bytes' field). Previously, only large Ethereum transaction data could be streamed in chunks; now the same chunking is applied to typed-message values. The change also improves on-screen display of long values by warning the user when a value is too large to show in full and by showing an ellipsis. It is a feature addition with defensive input checks, not a fix for a known vulnerability.

This commit is a large revert that removes a previously added graphical simulator feature (LVGL init) from the BitBox02 firmware repository. It deletes the LVGL submodule, vendored Rust dependencies, simulator code, and related build files. There is no indication in the commit message or diff that this change fixes a security vulnerability; it appears to be a routine rollback of an unfinished or unwanted feature.

This commit adds a new graphical simulator for the BitBox02 hardware wallet using the LVGL UI library. It is a large development-only change that introduces simulator code, vendored Rust dependencies, and build tooling. There is no indication from the commit title, message, or diff that this fixes or introduces any security vulnerability.

This commit adds a new 'coin purchase memo' feature to BitBox02 payment requests. It lets a payment request include details about a separate coin purchase (e.g., '0.25 ETH to address 0x...') and verifies that the listed Ethereum address really belongs to the wallet by deriving it from a provided keypath. The change is mostly a feature addition, but it introduces cross-currency validation logic and a TODO noting that the user-interface confirmation for this new memo type is not yet implemented.

This commit only cleans up test code by removing unnecessary calls to a mock memory setup function. It does not change the actual firmware that runs on the BitBox02 device, so it has no security impact on users.

This commit is a straightforward internal code refactor. It introduces a new 'KeystoreHal' adapter so that the keystore code can borrow only the hardware subsystems it needs (memory, random number generator, secure chip) instead of borrowing the entire HAL, which also contains the user interface. The stated reason is to allow a UI animation to run in parallel while the device unlocks. There is no change to security logic, cryptography, or user-facing behavior.

This is a small internal code cleanup in the BitBox02 firmware's Rust code. It changes a helper function so it borrows only the memory/storage part of the hardware abstraction layer, rather than the whole hardware abstraction layer. The commit message says this is preparation for a future change where the user interface part of the hardware layer will be used at the same time during wallet unlocking. There is no direct security fix here and no vulnerability is described.

This commit is a routine internal code cleanup. It moves the definitions of confirmation-screen parameters and fonts out of the workflow layer and into the hardware-abstraction (HAL) layer, then updates all call sites to use the new names. There is no change to user-facing behavior, no bug fix, and no security vulnerability being addressed.

This is a routine build-system and toolchain update for the BitBox02 firmware. It adds support for a new ARM processor target (Cortex-M33), upgrades the Rust compiler, LLVM, and the ARM GNU toolchain, and pulls in newer versions of some third-party Rust libraries. There is no direct evidence in the commit of a security vulnerability being fixed or introduced. The main risk is the usual one with large toolchain and dependency updates: a small chance that compiler, library, or behavior changes could introduce subtle bugs, but nothing in the diff points to an exploitable flaw.

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