BitBox02 firmware

This commit is a small code cleanup in the BitBox hardware wallet firmware. It changes the way a 32-byte secret produced by the secure chip's key-derivation function (KDF) is represented in code, switching from a variable-length vector to a fixed 32-byte array. The commit message says this is 'for better clarity.' There is no direct evidence in the commit or supplied references that this fixes a security vulnerability.

This commit is a routine code cleanup, not a security fix. It changes a key-derivation function so it only accepts exactly 32-byte inputs instead of any length up to 127 bytes. The function was already only ever called with 32-byte inputs, so behavior does not change. The stated reason is to make a later code rewrite easier.

This commit is a routine firmware refactoring: it moves a single secure-chip counter read from a synchronous C function into a new asynchronous Rust wrapper. There is no indication of a security bug being fixed or introduced. The change is architectural groundwork for future async secure-chip operations.

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 change is purely about how the project runs its internal Rust unit tests and regenerates protobuf files. It removes a CMake custom target called 'rust-test' and instead makes the Makefile's 'run-rust-unit-tests' target run cargo directly, while adding a separate 'generate-protobufs' target. There is no change to the firmware code that runs on the device, no bug fix, and no security patch.

This commit is a routine code reorganization. It moves functions that manage Noise protocol cryptographic keys (used for secure communication between the BitBox device and apps) into a common hardware abstraction layer called the Memory HAL. The actual behavior of these functions is not changed; they are simply routed through a new trait interface so the same code can be reused across different BitBox hardware models and test environments. There is no indication this fixes a security bug.

This commit is a documentation-only change in the project's AGENTS.md file. It removes a shorthand make target ('make run-rust-unit-tests') and replaces it with the longer underlying cargo command that developers should run directly. There is no code change, no firmware change, and no security fix or vulnerability introduced.

This commit only updates developer-facing documentation (AGENTS.md). It tells contributors they can run Rust's cargo commands directly on their computer instead of inside the project's Docker/development wrapper script. No firmware code, build scripts, or security behavior changed.

This commit only adds missing test setup calls to two automated unit tests in the Ethereum signing code. It does not change any production firmware behavior, user-facing functionality, or security logic. There is no indication this fixes a vulnerability or affects real devices.

This commit fixes a serialization bug in the BitBox02 firmware's payment request validation for Ethereum transactions. Previously, Ethereum payment amounts were encoded as big-endian (most-significant-byte-first), but the SLIP-24 standard requires them to be little-endian (least-significant-byte-first). Because the device signs the payment request using one byte order but the validation code used another, a payment request could be generated that the device would accept even if the actual transaction amount did not match what the user saw on screen. The fix changes the code to serialize Ethereum amounts as 32-byte little-endian values, matching the standard and preventing amount mismatches.

This commit only changes placeholder text in documentation and unit tests. It replaces the fake token name 'LOL' with 'ETH' in code comments and test expectations. No real program behavior is altered, and there is no security relevance.

This commit is a routine internal refactoring: it changes one function in the secure-chip hardware abstraction layer from synchronous to asynchronous. It does not fix a bug, change any security behavior, or alter how data is validated. It only adjusts how the firmware waits for the secure chip's answer when reporting how many times a one-way counter can still be incremented.

This commit only adds a single line to the product changelog describing a new feature: support for swaps in payment requests. There are no code changes, no bug fixes, and no security-related content in the diff.

This commit changes how the BitBox02 hardware wallet displays very long swap-to amounts on its screen. Previously, an extremely long amount string could be shown in full, potentially overflowing the display or making the user interface unusable. Now, long decimal portions are truncated with '...' so the integer part and a fixed number of decimal digits remain visible. This is a UI hardening change rather than a fix for a remote exploit.

This commit adds a new on-screen user-interface component for confirming cryptocurrency swaps. It is a feature addition that refactors how swap confirmations are displayed, replacing a generic confirmation screen with a dedicated swap screen. There is no direct evidence in the commit that this fixes a security vulnerability or introduces a new attack path.

This commit is a straightforward code cleanup: it moves a tiny function that reports the hardware security chip model from C to Rust. The function always returned the same fixed value (OPTIGA_TRUST_M_V3), and after the change it still returns that same fixed value. There is no security-relevant change in behavior.

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 adds missing safety checks for Ethereum payment requests on the BitBox02 hardware wallet. Previously, when a user paid a merchant via a Bitcoin payment request that included an Ethereum coin-purchase memo, the device did not verify that the requested Ethereum coin type and the keypath matched a supported mainnet network. A malicious or buggy payment request could therefore ask the device to prove ownership of an address on an unexpected or test Ethereum network, potentially misleading the user or weakening the security guarantee of the payment request. The patch now rejects unsupported coin types (notably testnet coin type 1) and ensures the keypath's second component matches the declared coin type.

This commit changes a single line in a Rust package configuration file. It makes the 'app-u2f' feature of the bitbox03 package also enable the 'app-u2f' feature in the underlying 'bitbox-hal' hardware abstraction library. There is no visible bug fix or security patch in the diff itself; it appears to be a build/feature wiring change.

This commit changes a code-formatting helper script so it only processes files tracked by Git, instead of scanning every file in the source directories. The old behavior accidentally formatted files inside build/cache folders such as src/rust/target, which only made the script slower. There is no security issue here.

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 only updates internal unit tests to use a more specific mock object (TestingMemory instead of TestingHal). It does not change any production code, security behavior, or user-facing functionality. There is no security issue here.

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 simply moves two constant definitions from a C source file to a header file so they can be used by Rust code later. There is no functional code change, no bug fix, and no security relevance visible in the diff.