BitBox02 firmware

This commit fixes a class of low-level memory-safety bugs where Rust code was given buffers containing uninitialized bytes. Rust's rules require every byte of a slice to be initialized, even if the function will overwrite them. Passing uninitialized memory could let the compiler make unsafe assumptions, but the commit message says no actual exploit or data leak was observed. The fix initializes buffers before handing them to Rust and switches some helpers to use raw pointers so they can legally write into uninitialized memory.

This commit fixes a bug in how the BitBox02 hardware wallet wipes files from its SD card. Before erasing a file, the device now checks the file's reported size against a safe maximum. Without this check, a tampered SD card could claim a file is gigantic, causing the device to get stuck in a long overwrite loop. The fix prevents a denial-of-service style attack where a malicious or corrupted SD card could make the device hang or behave unexpectedly during cleanup of old backups. The commit says it mitigates the impact of CVE-2026-6682 without changing the third-party FAT filesystem code.

This update adds a safety check when the BitBox02 hardware wallet mounts a microSD card. A malicious or deliberately malformed FAT filesystem could trick the device's file-system library into placing user data inside attacker-controlled bookkeeping sectors, potentially leading to code execution or data corruption when the device later reads or writes files. The fix validates that the filesystem's internal layout is sane before using it, and leaves the third-party library code unchanged.

This update fixes the BitBox02 bootloader's firmware-erase routine. Previously, when erasing leftover padding after a firmware update, the bootloader started erasing at the exact page where the firmware ended. Because flash memory can only be erased in larger fixed-size blocks, this could leave the final firmware chunk sharing an erase block with padding. That shared block might be erased unintentionally, potentially corrupting the newly written firmware. The fix aligns the erase start to a full erase-block boundary and re-checks whether pages are already erased before acting. The changelog explicitly calls this a fix for 'partially erased flash blocks.'

This commit adds production bootloader upgrade files for the BitBox02 hardware wallet and updates build scripts to use them. It is a routine asset-management change: replacing placeholder development hashes with real signed production binaries and enabling previously disabled build targets. There is no code change to how the device operates, no reported vulnerability, and no indication of a security incident.

This commit fixes a build script used only for development/testing versions of the BitBox02 bootloader upgrade. It makes the development-stage1 bootloader images unsigned again, while keeping production images fully signature-verified. The change is a build/development tooling fix, not a security patch for shipped devices.

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 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 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 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 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 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 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 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 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 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 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 changes how the BitBox02 hardware wallet warns users about very large Ethereum transaction data and typed messages. Previously, large transaction data was shown only as a byte count with the message 'too large to display.' Now the device shows a preview of the actual hex data (up to the screen limit, with a '...' truncation indicator) and adds a warning screen saying the value is too large to display in full. The change also reuses the same truncation logic already used for EIP-712 typed messages, so both flows behave consistently. The commit does not fix a vulnerability, but it improves the user's ability to inspect what they are signing.

This commit is a code-quality refactor for unit tests only. It introduces a small Rust helper macro called async_test::test that lets developers write async test functions directly, instead of manually wrapping async code in a block_on() call. The change touches many test files but does not alter any production firmware behavior, user-facing functionality, or security logic.

This commit rewrites the firmware's USB report queue from C to Rust. It is a large refactoring that replaces a hand-written C ring buffer with a Rust VecDeque wrapped in a C-compatible FFI. The change touches the core USB communication path used by both the main hardware wallet (HWW) and U2F interfaces. There is no explicit security bug fixed or introduced in the diff, but any mistake in the boundary between C and Rust could affect how the device receives and sends USB messages.

This commit is a large revert that removes a previously added graphical simulator feature (LVGL init) from the BitBox02 firmware repository. It deletes the LVGL submodule, vendored Rust dependencies, simulator code, and related build files. There is no indication in the commit message or diff that this change fixes a security vulnerability; it appears to be a routine rollback of an unfinished or unwanted feature.