BitBox02 firmware

This commit adds two helper scripts for developers to back up and restore BitBox02 flash memory areas using a Segger J-Link debugger. The scripts require physical hardware access and a debugging probe, and they are not part of the firmware that runs on the device. They do not change any device code or introduce a remote attack path.

This commit replaces unfinished placeholder code (which would crash with 'todo!()') with simple working user-interface placeholders for Bitcoin signing demonstrations. It adds basic on-screen prompts to confirm a recipient/amount and a total/fee, and makes progress/empty UI elements return real objects instead of crashing. There is no security issue visible in the diff; it is routine UI scaffolding.

This commit is a routine maintenance update for the BitBox02 hardware wallet firmware. It upgrades the pinned Rust compiler toolchain from an older version to Rust 1.96.0, updates the project's Docker build container and related developer tools (like clang-format and clang-tidy) from version 21 to 22, and refreshes several vendored Rust library dependencies to newer versions. The only application code change is a small test-only cleanup in the Bitcoin transaction signing tests to satisfy a new Rust linter warning. There is no direct evidence in the commit message or diff that this fixes a specific security vulnerability.

This commit removes the use of the standard snprintf formatting function from the BitBox02 bootloader's developer menu and replaces it with a small, fixed-format helper. The main goal is to reduce the bootloader's binary size and make the project's automated checks apply to all bootloader builds, not just production ones. There is no direct evidence this fixes an active security vulnerability, but it is a defensive hardening change that reduces attack surface by avoiding a complex formatting library in security-sensitive bootloader code.

This commit is a code-size optimization for the BitBox02 bootloader. It switches the Bluetooth Low Energy (BLE) firmware hash verification from a Rust SHA-256 implementation to an existing C-based SHA-256 implementation already used by the bootloader. The change saves 1,352 bytes and adds a CI check to prevent the larger Rust SHA-256 code from creeping back into production bootloaders. There is no indication this fixes a security vulnerability.

This commit removes the use of standard string-formatting functions (like snprintf and Rust's format!) from the bootloader and related low-level code, replacing them with smaller, fixed-size string builders. The stated goal is to reduce binary size ('bloat') in the production bootloader, not to fix a known security bug. The change also adds a CI check that rejects any future use of these formatting symbols in production bootloader builds. While removing complex formatting libraries from a bootloader is generally good defensive practice, the commit itself does not describe or demonstrate any exploitable vulnerability.

This commit is a simple code cleanup: it moves a handful of string-formatting helpers (for pairing codes, progress percentages, hash display, timers, and unknown-command messages) out of the main bootloader file into a new dedicated file, and adds unit tests for them. The actual formatting logic is unchanged, and there is no indication of any security fix or behavior change.

This commit removes a 100-character stack buffer and passes bootloader messages straight to the screen-drawing function. The old code used snprintf to copy the message into a fixed-size buffer, which could silently truncate very long strings. There is no direct evidence in the commit that this fixed a security vulnerability; it appears to be a cleanup or robustness improvement. The change does not introduce obvious new risks because the drawing function consumes the string immediately.

This commit changes the default on-screen font used by the bootloader from an 11x10 pixel font to a 9x9 pixel font. The only stated purpose is to make the bootloader firmware file smaller by avoiding inclusion of the larger font's data table. There is no indication this fixes a security vulnerability.

This commit replaces floating-point progress calculations with integer math to save firmware space. It removes the use of f32 arithmetic for progress bars in Bitcoin transaction signing and Bluetooth firmware upgrades. There is no direct security vulnerability in the change itself; it is a code-quality and size-reduction refactor. However, it introduces new integer arithmetic paths that must keep numerator/denominator assumptions valid to avoid incorrect progress display.

This commit is a user-interface cleanup: it removes a special 'draw text upside-down' flag from the graphics library and instead uses a generic 180-degree rotation helper when the screen is flipped. It does not fix a security vulnerability and does not appear to introduce one. The change is mostly about simplifying how text and buttons are rendered on the BitBox02 hardware wallet screen.

This commit changes the build system to enable Link-Time Optimization (LTO), a compiler technique that shrinks the final firmware size. It also adds safeguards to keep the stack protector security feature working under LTO and deliberately excludes sensitive low-level code (bootloader, factory setup, hardware drivers) from LTO to avoid subtle bugs. There is no direct evidence in the commit of a security vulnerability being fixed or introduced.

This commit adds a new factory-setup helper program for the BitBox03 hardware wallet and moves some debug logging code around. It does not change the main wallet firmware's security behavior. There is no indication this fixes or introduces a security vulnerability.

This commit adds a brand-new, minimal firmware binary for the BitBox03 hardware wallet. It is essentially a development stub: it initializes the board, sets up a debug logger, prints a log message, and then halts. There is no user-facing functionality, no cryptographic code, and no security-sensitive logic introduced in this change. It is a build-system and scaffolding addition, not a security fix or vulnerability.

This update fixes a crash in the BitBox02 hardware wallet when a user lists many backups over a Bluetooth connection. Previously, the device could run out of temporary buffer space while sending a large response, causing it to panic and stop working. The fix makes the Bluetooth sender check whether the whole next chunk fits before writing it, and if not, wait until space becomes available. USB connections were not affected because they use a different path.

This commit is a size-optimization cleanup, not a security fix. It replaces libsecp256k1's default fatal-error callbacks with smaller stubs so the firmware binary no longer pulls in unused standard-library printing and abort code. The behavior stays the same: on an internal or illegal-argument failure, the device still hangs forever instead of returning.

This commit is a code refactoring that moves the device attestation signing function from C code into Rust code. It converts the function to be asynchronous (async/await) and rewrites the parsing of the secure chip's DER-encoded signature in Rust. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a normal portability and maintainability improvement. The change does add safety checks for signature length and zeroizes sensitive buffers after use, which are good defensive practices.

This commit rewrites how the BitBox02 hardware wallet fetches random numbers from its secure chip. Previously, the secure chip's random generator was called in a blocking (synchronous) way. The change makes it asynchronous, so the firmware can do other work while waiting. It also removes an older, simpler random interface and now mixes the secure-chip randomness with the microcontroller's own randomness before using it for sensitive key material. The commit itself is a defensive refactor; it does not appear to fix a known exploit, but it removes a synchronous call that could stall the device and strengthens how random values are combined when creating password-stretching secrets.

This commit only adds two new digital signature files for an already-released firmware version (9.26.1). These signatures are used by independent builders to publicly attest that they reproduced the official firmware exactly from source code. No code, no firmware binary, and no behavior of the device changed. There is nothing here that could affect security of the BitBox02 itself.

This commit is purely a code-style and build-maintenance change. It makes the Rust code generated from protocol-buffer definitions be formatted by rustfmt automatically and included in style checks. No security-sensitive behavior is changed.

This commit is a build-system and code-organization refactor. It moves the automatically generated Rust protobuf message definitions from inside the main bitbox02-rust crate into a new, separate bitbox-proto crate. It also switches the generation flow from CMake to Cargo, adds a CI check to ensure the committed generated files stay in sync with the .proto source files, and avoids touching timestamps when regeneration produces identical output. There is no change to the actual device firmware logic or to how messages are parsed and validated.

This commit is a large refactoring that moves the password-stretching and secure-chip password operations from C into Rust for the BitBox02 firmware. It does not add new user-facing features or change the cryptographic algorithm; it reimplements the same OPTIGA secure-chip flows (HMAC verification, symmetric encryption, key generation, counter resets) in Rust with async wrappers. The old C implementation and its unit tests are removed, and equivalent Rust unit tests with deterministic fakes are added. There is no indication in the commit that this fixes a known security vulnerability.

This commit only reformats the Rust documentation comments for unsafe functions so they use the standard '# Safety' heading. No actual code logic, memory handling, or behavior changed. It is a documentation cleanup with no security impact.

This commit is a straightforward code cleanup: it changes the return type of password-stretching functions from a variable-length byte list to a fixed 32-byte array, because the result is always exactly 32 bytes. The change makes the code clearer and lets the compiler enforce the size, but it does not fix any security bug or change behavior.

This commit is a user-interface polish change for the BitBox02 hardware wallet. It replaces a generic 'waiting' spinner with the first frame of the unlock animation while the device is busy stretching the user's password. There is no security vulnerability or fix here—only a visual improvement to make the device look smoother during unlock.