BitBox02 firmware

This commit only adds Apache-2.0 license header comments to 16 source files that were missing them. It makes no functional changes to the BitBox02 firmware or its Python tools. There is no security impact.

This commit is a bulk license-header cleanup. It replaces long, multi-line copyright and Apache-2.0 license notices at the top of 429 source files with a single, standardized machine-readable tag: 'SPDX-License-Identifier: Apache-2.0'. No program logic, build rules, or file contents other than the header comments were changed. It does not introduce or fix any security vulnerability.

This commit is a routine code-style fix. It updates the Python formatter (black) configuration so the linter uses the correct pyproject.toml file, and reformats two Python files to match the new style rules. There are no security changes to the firmware or any sensitive logic.

This commit only fixes a typo in a code comment (docstring). It changes the description of when a function can return an error, matching the fact that the function now receives the private key directly rather than fetching it from a locked keystore. No actual code behavior is changed.

This commit is a routine code cleanup. It removes a locally defined constant for compressed secp256k1 public key size (33 bytes) and replaces it with an equivalent constant already provided by the upstream Rust bitcoin/secp256k1 library. The numeric value and behavior remain exactly the same.

This is a small internal cleanup in the BitBox02 firmware's on-screen text input component. A helper function that fetches BIP39 seed words was simplified so callers no longer check its return value; the helper itself now aborts on failure. There is no security vulnerability here—just a minor code-style refactor that keeps the same failure behavior.

This commit removes an old C source file called keystore.c and moves two small cryptographic helper functions directly into the Rust part of the project. The functions themselves still do exactly the same secp256k1 signing and nonce-commitment work as before; they are just called from Rust instead of going through a thin C wrapper. There is no indication this fixes or introduces a security bug.

This commit is a simple code reorganization: it moves functions that perform secp256k1 cryptographic signing from a file named keystore.rs into a file named secp256k1.rs. The actual behavior of the code, including how private keys are used and how signatures are produced, does not change. It is a refactoring, not a security fix or vulnerability.

This commit simply moves a helper function that looks up a BIP39 word by its index from one source file to another. The function's behavior and the callers' logic are unchanged; it is a code cleanup with no security impact.

This commit only updates user documentation (README) and adds a binary firmware file. There is no code change that fixes or introduces a security vulnerability. It is a routine documentation improvement.

This commit updates the Rust compiler toolchain from an unspecified earlier version to Rust 1.92 for the BitBox02 hardware wallet firmware. It also refreshes many vendored third-party Rust libraries (such as libc, hashbrown, getopts) and build tools (cbindgen, bindgen). The stated reason is compatibility with the new toolchain, including a breaking change around panic handling. There is no direct evidence in the commit that this fixes a known security vulnerability, but toolchain and dependency updates can affect security-relevant behavior such as memory safety, panic handling, and type definitions used in cryptographic code.

This commit adds unit tests for two cryptographic helper functions and slightly reorders their internal steps so the output buffer is only written after the HMAC calculation is complete. The change makes it safe for the output buffer to overlap with the input or key buffers, and documents that overlap is allowed. There is no new vulnerability here; it is a defensive hardening and testing improvement.

This commit is a code refactoring that introduces a new 'Memory' hardware abstraction layer (HAL) in the BitBox02 firmware. It moves direct memory access calls behind a trait interface so the code can be more easily tested with mock memory. There is no direct evidence in the commit of a security vulnerability being fixed; it appears to be a structural improvement that also adds unit tests for password entry behavior.

This commit is a straightforward internal refactoring: it moves the device attestation signing function behind a hardware-abstraction-layer (HAL) interface so the code can be more easily tested. The actual cryptographic operation and the data it uses remain unchanged. There is no indication this fixes or introduces a security vulnerability.

This commit is a large internal refactoring of the BitBox02 firmware. It adds a new secure-chip key-derivation function (KDF) to the hardware abstraction layer (HAL) and threads that HAL through many existing functions so they can use it. The change touches 31 files and many tests, but it does not appear to introduce a new security vulnerability on its own. It is a structural change that prepares the code for using the secure chip's KDF more consistently.

This commit adds a new 'Change Password' feature to the BitBox02 hardware wallet. Instead of resetting the device and restoring from a backup, users can now change their device password directly. The wallet re-encrypts the stored seed with the new password while keeping the same accounts and identity. The change is a normal product feature, not a security fix, but it touches sensitive crypto code that protects the user's funds.

This commit adds two digital signature files for the BitBox02 firmware version 9.24.0. These signatures are used to publicly verify that the released firmware binaries are authentic and have not been tampered with. There is no code change and no indication of a security vulnerability.

This commit is a routine refactoring that rewrites existing C unit tests in Rust. It does not change the actual firmware behavior or fix any security issue. One redundant test was removed, and several internal test-only helpers were added so the Rust tests can call the same underlying C memory functions.

This commit only adds a new automated test to the BitBox02 firmware. It checks that entering the wrong password repeatedly while the device is already locked correctly triggers the lockout mechanism and eventually wipes the seed. There is no change to production code, no new feature, and no fix to an existing bug.

This commit rewrites the BitBox02's startup orientation screen from C to Rust and introduces a new shared delay/timer subsystem. It is a refactoring change: the device still asks the user to pick screen orientation at boot, then waits 1.3 seconds before switching to the lock screen and enabling USB/Bluetooth. The rewrite changes how internal timers and product-version strings are handled, but it does not add or remove security features. There is no vendor statement that this fixes a security bug.

This commit rewrites two internal seed-handling functions from C to Rust as part of an ongoing porting effort. It moves where the encrypted wallet seed is stored and how it is decrypted, but keeps the same encryption design. There is no direct evidence in the commit that this fixes or introduces a security bug; it is primarily a code-rewrite change.

This commit rewrites the code that keeps the BIP-39 seed temporarily encrypted in memory, moving it from C to Rust. It is a refactoring/porting change, not a fix for a known bug or attack. The same encryption approach is preserved, but the change touches sensitive seed-handling code, so it deserves careful review.

This commit is purely a code-style change. It tells the project's automatic formatter (clang-format) to indent preprocessor directives like #if, #include, and #error, and then applies that new rule across many source files. No program logic, security checks, or behavior were changed.

This commit is a routine code refactor, not a security fix. It moves the source of random numbers behind a new 'hardware abstraction layer' (HAL) interface so the same code can use a fake predictable random generator during automated tests and the real secure random generator on the actual BitBox02 device. The only production behavior change is that Taproot/Schnorr signing now fetches its auxiliary randomness through this new interface instead of calling the device's random function directly. The real-device implementation still uses the same secure random function as before, so security properties are unchanged.

This commit is a straightforward refactoring: it moves an existing anti-klepto protocol unit test from C to Rust. No production firmware code is changed, and no security vulnerability is introduced or fixed. The same cryptographic checks are still performed, just in a different test language.