BitBox02 firmware

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 adds a new method called mcu_32_bytes to the random number generation abstraction layer in the BitBox02 firmware. It is a straightforward code addition that exposes an existing microcontroller random function through the Rust hardware abstraction layer, and adds corresponding test support. There is no indication this fixes or introduces a security vulnerability.

This commit is a routine internal code cleanup in the BitBox02 firmware's Rust hardware-abstraction layer. It restructures how subsystems (screen UI, random number generator, SD card, secure chip, memory, system control) are accessed so that multiple subsystems can be borrowed at the same time. The stated reason is to let the user-interface code use the random generator for a mnemonic quiz feature. There is no security fix or vulnerability patch here.

This commit is a code cleanup in the BitBox02 firmware's Ethereum transaction signing module. It replaces a generic/template-based approach with dynamic dispatch (using Rust trait objects) to reduce firmware size by about 1,776 bytes. There is no indication in the commit or supplied references that this fixes a security vulnerability or changes security-relevant behavior.

This commit is a code cleanup in the BitBox02 Ethereum signing code. It merges two separate ways of feeding transaction data into one unified mechanism, with no intended behavior change. The only functional difference visible in the diff is a minor type change in a length check (from `usize` to `u32`), which does not appear to introduce a security issue. There is no indication this is a security fix.

This commit is a routine code cleanup: it moves Ethereum transaction test data out of Rust source files into separate JSON files and adds small helper scripts to generate that data. It also makes minor type-casting fixes in unrelated test code. There is no change to the actual transaction signing logic or to any code that runs on the device in production.

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 support for signing Ethereum transactions with very large 'data' fields by streaming the data in 4 KB chunks instead of loading it all at once. It also adds safety checks: streamed and inline data cannot both be provided, and streamed data is capped at 1 MB. The change is a feature/refactoring with embedded defensive checks, but it is not described by the vendor as a security fix.

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 refactors how the BitBox02 hardware wallet computes the Ethereum transaction hash (sighash) when the transaction contains a very large 'data' field. Previously, the entire data field had to be held in memory at once, which could fail if it was too large for a single USB message. The change makes the hashing process 'streaming' or 'asynchronous', so the device can receive and hash the data in smaller chunks. The commit itself is a feature/robustness improvement, not a direct security fix, but it touches the core cryptographic hashing path for Ethereum transactions.

This is a routine internal cleanup in the BitBox02 firmware's user-interface code. It removes an artificial lifetime marker (a 'PhantomData' placeholder) from the Rust 'Component' type because the underlying callbacks that once required it have already been removed. There is no change to security logic, user-facing behavior, or how the device handles secrets.

This commit is a routine internal refactoring of the BitBox02 firmware's user-interface code. It rewrites one transaction-fee confirmation screen to use Rust's async/await style instead of a callback style, and removes an unused 'on_drop' cleanup field. There is no indication of a security bug being fixed or introduced.

This commit is a routine internal refactor of the BitBox02 firmware's user-interface code. It converts the transaction-address confirmation screen from a callback-based (synchronous-style) API to an async/await API. There is no indication in the commit that it fixes a security bug or changes security behavior; it appears to be a code-quality improvement.