BitBox02 firmware

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.

This commit fixes a single-word typo in a code comment ('man' to 'how'). It does not change any executable code, behavior, or security properties of the firmware.

This commit fixes a typo-like bug in the BitBox02 hardware wallet's Ethereum transaction signing code. The firmware was supposed to reject a 'max_fee_per_gas' value that has an unnecessary leading zero byte, but it was accidentally checking 'gas_limit' instead. Leading-zero values can cause the device and a connected computer to compute different transaction hashes, which could let an attacker trick the user into signing one transaction while the computer broadcasts a different one. The fix corrects the field check and adds tests for both fee fields.

This commit introduces a new asynchronous task engine into the BitBox02 firmware. It vendors third-party Rust libraries (async-task, concurrent-queue, crossbeam-utils) and adds a custom executor plus a small demo that shows an orientation screen and a delay. There is no indication in the commit message, diff, or supplied references that this change fixes or introduces a security vulnerability; it appears to be a routine architectural/feature addition.

This commit fixes a low-level coding issue in the firmware that talks to a Bluetooth chip (DA14531). The code was reading 2-byte numbers from positions in a byte buffer that might not be properly aligned in memory, which is undefined behavior in C. The fix uses memcpy instead of direct pointer casts, which is safe regardless of alignment. On its own this is a robustness/correctness fix; there is no direct evidence in the commit that it is exploitable as a security vulnerability.

This commit fixes a bug in the firmware that talks to a Bluetooth chip over a serial (UART) link. If a malformed or truncated message shorter than 5 bytes reached the validation step, the code would subtract 5 from the message length. Because the length was stored as an unsigned number, the result wrapped around to a very large value instead of becoming negative. That large value could then be used to read memory outside the intended buffer, potentially leaking data or causing the device to behave unpredictably. The fix rejects any frame shorter than 5 bytes before doing the subtraction.

This commit is a purely cosmetic code-formatting change. It shortens a single Python print statement from multiple lines to one line, with no change to what the program does or how it behaves.

This commit rewrites the BitBox02 firmware's date/time formatting from C to Rust and vendors several new Rust crates (time, deranged, powerfmt, num-conv) to do it. The change is described by the vendor as a code-quality and binary-size improvement, not a security fix. There is no direct evidence in the commit of a vulnerability being patched, but any rewrite of formatting code can in principle introduce subtle bugs such as buffer handling or timezone mistakes. The large amount of newly vendored code increases the supply-chain/bug surface that future audits should watch.

This commit adds a new graphical simulator for the BitBox03 hardware wallet. It is purely a development and testing tool: it creates a window that mimics the device screen, accepts simulated USB/TCP traffic, and can optionally pre-seed a test mnemonic. There is no change to the actual firmware that runs on real devices, and nothing in the commit fixes or introduces a security vulnerability in shipped products.

This commit rewrites a low-level serial-link framing and CRC routine from C into Rust for the BitBox02 hardware wallet's Bluetooth companion-chip (DA14531) communication. It removes a hand-generated C CRC implementation and uses a standard Rust `crc` crate instead. The change is a refactor/port, not a fix for a known vulnerability. There is no direct evidence in the commit or supplied references that this change addresses a security bug.

This commit adds unit tests for a Bluetooth/serial framing function and slightly relaxes four buffer-size checks from '<' to '<='. The change is described as 'off by one in the safe conservative direction', meaning the old checks rejected a perfectly-sized buffer as too small. The patch does not fix a memory corruption bug; it removes a false-positive assertion that could have caused a harmless device reset when a caller supplied an exactly-sized buffer. No security vulnerability is disclosed or demonstrated.

This commit is a code cleanup that moves multisig account storage operations behind a hardware-abstraction layer so tests can use a fake memory instead of real device memory. It does not appear to fix or introduce a security vulnerability. A few test files were updated to use the new fake memory, and one small bug was fixed where a test created a fresh fake device after registering an account, which would have made the test fail to find the registered account.

This commit only updates the CHANGELOG.md file to mark the release of firmware version 9.25.0. It does not change any source code, cryptographic routines, Bluetooth behavior, or password handling. The changelog mentions a password-stretching improvement and a Bluetooth bug fix, but those changes were made in earlier commits; this commit merely documents them.

This is an automated dependency update by Dependabot that bumps the Rust 'lru' crate from version 0.16.1 to 0.16.3 inside a graphical simulator test component. The change only modifies a test-only lockfile and does not touch the actual BitBox02 firmware code. There is no indication in the commit that this fixes a security issue, and the supplied references do not mention any security relevance.

This commit adds automatic cleanup calls for several 32-byte temporary buffers that hold sensitive values like password hashes, HMAC keys, and password secrets in the Optiga secure-element integration code. Previously these buffers were zero-initialized at declaration but not always explicitly erased before the function returned or after an early error path. The change reduces the chance that leftover cryptographic material remains in stack memory, which could lower the risk of information leakage if an attacker later reads process memory or a core dump. It is a defensive hardening patch rather than a fix for an actively exploitable bug.

This commit changes how the BitBox02 hardware wallet handles the password-stretching algorithm used to protect the wallet seed. When a user unlocks the device, if the seed was encrypted with an older, weaker stretching method, it is now automatically re-encrypted with the newer, stronger method. The change is a defensive upgrade, not a fix for an active attack, and it only affects the unlock flow after the correct password is entered.

This commit is a small internal optimization in the BitBox02 hardware wallet firmware. When a user creates or restores a password, the device previously performed two separate operations on the secure chip (Optiga/ATECC): one to initialize the new password and another to stretch it. The commit combines these into a single step, reducing the number of secure chip 'events' (internal counter operations). There is no direct security vulnerability being fixed; it is a performance and resource-usage improvement.

This commit adds a new password-stretching algorithm (V1) for BitBox02 devices that use the Optiga secure chip. It changes how the device turns a user's password into an encryption key, adding extra secure-chip-backed hashing steps and enforcing that newly created passwords use the new algorithm. Old V0 passwords can still be unlocked for backward compatibility. There is no direct evidence in the commit of a security vulnerability being fixed; it reads as a planned feature/upgrade.

This commit is a simple code cleanup: it renames a constant from KDF_NUM_ITERATIONS to KDF_NUM_ITERATIONS_V0 and updates the comment to clarify that the low number of iterations (2) applies only to an older password-stretching algorithm (V0). No behavior changes, no security fix, no vulnerability patch.

This commit adds a new memory flag that records which password-stretching algorithm was used to protect the wallet seed. It does not change the actual stretching math yet; it only stores the choice so future firmware can support a newer algorithm while still recognizing older backups. There is no immediate security fix, but it is infrastructure for a future security improvement.

This commit only updates copyright years in two LICENSE files. It makes no changes to software code, functionality, or security controls. There is no security relevance.

This commit removes an unused header file called keystore.h and updates the code that previously included it. The two constants that were defined in that header (KEYSTORE_U2F_SEED_LENGTH and XPUB_ENCODED_LEN) are no longer referenced through the header. In the U2F code, the seed length is now taken directly from the size of the local seed variable using sizeof(seed), which is functionally equivalent because the seed is a fixed-size array of the same length. There is no security-relevant change here—this is a cleanup refactor.

This commit simply removes a duplicate definition of a constant in one file because the same definition already exists in a header file. It is a routine cleanup with no security impact.

This commit rewrites the device factory-reset routine from C to Rust. It is a straightforward language port: the same steps (lock keystore, reset secure-chip keys, reset U2F counter, wipe memory, disable SmartEEPROM, show a status screen, reboot) are preserved. The change also adds unit tests and makes the unlock function asynchronous so it can call the new async reset. Nothing in the diff introduces a new vulnerability or changes security-critical behavior in a suspicious way.

This commit adds a new graphical simulator for the BitBox02 hardware wallet. It is a development and testing tool, not a change to the firmware that runs on real devices. There is no indication this commit fixes or introduces a security vulnerability.