BitBox02 firmware

This commit fixes a simulator-only bug where the graphical BitBox02 simulator was accidentally using real device randomness instead of the fixed test value used by other simulators/test builds. The change makes the graphical simulator use the same predictable 'factory randomness' as the C unit-testing simulator. This is a test/simulator hardening fix, not a fix for the real hardware wallet firmware.

This commit adds release artifacts for BitBox02 firmware version 9.26.1: two signed text files stating the expected firmware hash for the Multi and Bitcoin-only editions, their detached signatures, and a helper Python script that automates creating such assertion files in the future. There is no change to the actual firmware code, no bug fix, and no security patch.

This commit fixes a crash in the software simulator used for testing the BitBox02 hardware wallet. The simulator was trying to read a special memory address that only exists on the physical device, causing it to crash. The fix makes the simulator return a placeholder value of all zeros instead. This only affects test tooling, not real devices or user funds.

This commit rewrites how the BitBox02 hardware wallet performs a key-derivation operation inside its secure chip (OPTIGA). Previously the operation was synchronous and wrapped in C; now it is asynchronous and called from Rust through the existing async command bridge. The change touches many files because every caller of the KDF/keystore functions had to be updated to `await` the result. The diff itself is a large refactoring with no obvious security bug, but it introduces new async machinery around a sensitive cryptographic operation, so it warrants careful review for memory-safety and concurrency issues.

This is a small internal code cleanup in the BitBox02 firmware. It changes a helper function that computes SHA-256 hashes so that it returns a fixed 32-byte array instead of a variable-length vector. The only effects are removing an unnecessary type conversion and making the code clearer. There is no security bug being fixed here.

This commit is a simple rename of a Rust crate from 'bitbox02-noise' to 'bitbox-noise'. The code itself is unchanged; only file paths, package names, and import references are updated. There is no security fix or vulnerability introduced.

This commit is a code cleanup in the BitBox02 firmware's Rust code. It changes how random numbers are supplied when creating cryptographic keys for the Noise protocol, moving from a device-specific random type to a more generic hardware abstraction layer (HAL) random source. The commit message and diff do not describe this as fixing a security bug; it reads as an architectural refactor to simplify dependencies. There is no direct evidence in the commit that the old code was exploitable or that any vulnerability was fixed.

This commit is a routine code reorganization: it moves two small helper modules (one for generating random bytes, one for salting/hashing data) from an existing Rust crate into a new shared workspace crate named bitbox-core-utils. The actual logic, algorithms, and behavior are copied unchanged; only the file paths and import names are updated. There is no indication this fixes or introduces a security vulnerability.

This commit simply moves a test-only fake random number generator from one internal Rust module to another. The code is identical and is only used in automated tests running on a developer's computer, not in the real BitBox02 hardware wallet firmware. There is no security issue.

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 fixes a Rust build configuration issue so that the project's automated tests can run on a normal computer. It moves a required feature flag for the 'hex_lit' library from individual sub-crates to the shared workspace configuration. There is no indication this is a security fix or that it changes any runtime behavior on the actual BitBox02 device.

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 rewrites the secure-chip abstraction layer from C to Rust. It is a refactoring/porting change: the same underlying ATECC and Optiga hardware drivers are still used, but the dispatch logic that picks between them and the test fake is now implemented in Rust. No new security vulnerability is visible in the diff, but any rewrite of security-critical code carries a risk of subtle behavior changes.

This commit implements a placeholder random-number generator inside a graphical simulator for the BitBox03 hardware wallet. It replaces 'todo!' stubs with code that fills 32-byte buffers using the standard Rust 'rand' crate. The change only affects test/simulator code, not the real firmware or any production device, so it does not create a security vulnerability in shipped products. The only concern is that simulator developers must remember this is a non-cryptographic/test RNG and must not copy it into real hardware code.

This commit adds a new local simulator for the BitBox03 hardware wallet. It is purely test/development tooling: it wires up fake hardware components (fake memory, fake secure chip, fake SD card, etc.) and leaves many simulator functions as unimplemented 'todo!()' stubs. There is no indication this change affects real device firmware or introduces a security vulnerability.

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 introduces the initial hardware abstraction layer (HAL) for the BitBox03 and makes several safety improvements to the Rust bindings for the LVGL graphics library. Most changes are architectural or defensive: adding new safe wrappers, replacing borrowed C string pointers with owned copies, adding explicit unsafe markers, and removing some risky image-source APIs. There are also large additions of generated font data and placeholder TODO implementations for hardware interfaces. No obvious exploitable vulnerability is visible in the diff, but the commit is large and partially implemented, so the safety claims cannot be fully verified from this patch alone.

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 configuration updates. There is no indication it fixes a security bug or introduces a security vulnerability in the firmware itself.

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 is a code cleanup that moves where the device fetches a 32-byte secret key used to talk to the secure chip (Optiga). Previously, a low-level C module directly called a BB02-specific memory function. Now it goes through a Rust abstraction layer so the same module can be reused in a future BB03 device. The change does not alter how the key is stored, generated, or protected; it only reroutes the function call. There is no indication this fixes a security bug.

This is a build-system refactoring commit. It moves the generation of version.h and rust.h out of CMake and into a Python script and Rust build.rs, so the Rust code can be built standalone without CMake. There is no change to runtime firmware behavior, no bug fix, and no security patch visible in the diff.

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.