BitBox02 firmware

This commit fixes a bootloader bug where the device rejected firmware updates that used the maximum allowed size. The off-by-one check meant legitimate full-sized firmware images could not be installed, potentially blocking updates. The fix changes the limit from 'one less than maximum' to 'maximum'. There is no direct evidence this was exploitable as an attack, but any bug in firmware-update verification deserves attention.

This is a large firmware commit that adds a new two-stage bootloader update mechanism for the BitBox02 hardware wallet. It replaces the old single bootloader with a small, fixed 'stage0' plus a separately signed 'stage1', and ships a special firmware image that can install both stages onto existing devices. The change also updates how firmware signatures are computed so that the product type is included in the hash, which is a security improvement. Because the commit is a major architectural rewrite and includes prebuilt binary blobs whose source is not shown, it carries normal supply-chain and implementation risks, but no specific vulnerability is visible in the diff.

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 changes how the BitBox02 firmware reads sensitive stored data (device name, seed birthdate, encryption keys, BLE identity, etc.). Previously, the firmware copied whole chunks from flash into RAM and then cleared them afterward. Now, for real firmware builds, it reads those fields directly from flash using typed pointers, so the data stays in flash and is not copied into RAM. This is mostly a performance and memory-usage improvement, but it removes the explicit RAM-clearing (util_zero) that used to happen after reading. That means sensitive bytes may remain longer in RAM if they are ever copied out, and any code that later reads from those RAM copies could be a concern. There is no direct vulnerability shown in the diff, but the change weakens one defensive layer (clearing sensitive RAM) and introduces more places where secrets are accessed through raw flash pointers.

This commit changes how the project's automated unit tests are run. It disables Address Space Layout Randomization (ASLR) only during testing, when available, by wrapping the test command with setarch -R. ASLR randomizes where programs are loaded in memory; turning it off for tests is often done to make memory-related test failures reproducible or to support debugging tools. This change affects only the developer/test build process, not the firmware that ships to users.

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 changes a code-style configuration file to silence one more clang-tidy warning about implicit conversions to booleans. It does not modify any firmware source code, behavior, or security logic. By itself it is not a vulnerability or a security fix.

This commit adds a new Rust build helper crate for the STM32U5A9J-DK development board. It compiles a single C file from STMicroelectronics' HAL library into an object file and links it into firmware builds so a custom board initialization function overrides the weak default. There is no indication of a security vulnerability or fix.

This commit adds a new Rust helper library and a Python script for creating and validating firmware image headers for the BitBox02/BitBox03 bootloader. It is purely an infrastructure/feature addition: it defines data structures, parsing routines, boot argument handling, and image-header tooling. There is no bug fix, no patch of an existing vulnerability, and no indication this change itself introduces a security flaw.

This commit adds a new internal debugging library called bitbox-debug and vendors several Rust dependencies (once_cell, portable-atomic, rtt-target). There is no indication in the commit message or diff that this fixes a security vulnerability. It appears to be a feature/infrastructure addition for firmware debugging.

This commit is a build-system improvement for the BitBox02 hardware wallet firmware. It creates a script that automatically generates local Cargo (Rust build tool) configuration files so that Rust code compiles correctly for the ARM microcontroller inside the device. It does not change any wallet logic, cryptography, or user-facing behavior. There is no indication this is a security fix or vulnerability patch.

This commit fixes a test-only simulator feature so that a command-line flag called --preseed actually loads a known test wallet. It only changes test/simulator code, not the real BitBox02/BitBox03 firmware that runs on the hardware wallet. There is no security-relevant change to production code.

This commit adds placeholder user-interface screens for restoring a wallet from a recovery phrase on the BitBox03 hardware wallet. It replaces some unfinished 'todo!' stubs with basic screens and adds a retry loop so users must enter a valid BIP39 word. There is no clear security bug in the change, but it is a new, incomplete UI implementation that could contain latent issues.

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 change only adjusts a code-quality tool configuration. It tells clang-tidy to skip linting header files located in an external driver directory (asf4-drivers). It does not modify firmware behavior, fix a bug, or change any executable code.

This commit only improves an internal CI script that checks the built firmware for unwanted software-implemented floating-point and other bloat-causing symbols. It is a build-hygiene and binary-size guard, not a security patch. There is no vulnerability being fixed here.

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 simply adds the official STMicroelectronics (ST) driver library for the STM32U5 microcontroller family into the project's source tree. It is a large import of vendor-provided header files, source files, and license files. There is no bug fix, no functional change to the wallet application, and no indication of a security issue being addressed.

This commit adds a visual progress bar that appears on the BitBox02 screen while the device is receiving large Ethereum transaction data or typed-message data from the host computer. It is purely a user-experience change: it shows 'Loading data...' with a progress fraction during streaming, and updates the test mock UI so automated tests can verify the progress values. There is no security-relevant change to cryptography, parsing, bounds checking, or host/device trust boundaries.