BitBox02 firmware

This commit is a routine release-management update. It adds signed build assertions for three new BitBox02 firmware versions (9.26.2, 9.26.3, 9.26.4) and updates the release documentation and build helper script. The build script now deletes the v9.26.3 git tag after fetching because the released binaries accidentally included pre-release metadata, so the exact released binary can only be reproduced from the unsigned commit hash, not from the final tag. There is no code change to the firmware itself in this commit, and nothing in the materials suggests a security vulnerability.

This firmware update relaxes the rules for valid Ethereum typed-data (EIP-712) names so they can contain a colon (:), which some decentralized apps use as a namespace separator. Member names still cannot contain colons. The change is presented as safe because a colon cannot be confused with the punctuation that separates type names, fields, and arrays in EIP-712 encoding.

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 commit updates the third-party FatFs file-system library inside the BitBox02 firmware from version R0.14b to R0.16 plus an upstream patch. The change is a routine dependency refresh: it replaces the vendored source files with the newer upstream release while keeping BitBox's existing configuration (long-file-name support, tiny mode, code page 850, fixed timestamps, no exFAT, no labels, no 64-bit LBA). Most of the visible diff is documentation and metadata; the actual C source files (ff.c, ff.h, ffconf.h, diskio.c, etc.) are updated wholesale. The commit message does not claim to fix any security issue, and no independent security advisory or CVE is supplied.

This commit fixes two memory-handling bugs in the BitBox02 hardware wallet's Rust LVGL UI bindings. First, line widgets were storing point data in dynamically allocated memory attached to the LVGL object and freeing it when the object was deleted; if the same points were shared or the attachment logic failed, this could lead to crashes or memory corruption. The fix requires callers to pass only statically allocated, never-freed point slices. Second, style-transition property lists were accepted without checking for a required terminator marker; an unterminated list could cause LVGL to read past the end of the array, leading to crashes or undefined behavior. The commit adds validation that panics at construction time if the terminator is missing.

This commit is a user-interface redesign for the BitBox03 hardware wallet: text buttons like 'Yes/No' and 'Back/Next' are replaced with icon buttons. It also adds a hidden demo screen that can only be opened in the simulator by setting the device name to a special test value. There is no direct security vulnerability visible in the code change, but it touches code that handles user confirmation and cancellation, so any bug here could affect whether a user correctly approves or rejects a sensitive action.

This commit adds a new Python client feature called BitBoxSync to the BitBox02 Python library. It introduces generated protobuf code, new API methods to request identity keys, sign various sync-related intents, and unwrap an encrypted namespace key, plus a demo menu in the developer test tool send_message.py. There is no indication in the commit that this fixes a security bug; it appears to be a normal feature addition.

This commit adds a brand-new firmware feature called BitBoxSync, which lets the BitBox02 hardware wallet participate in a sync service by proving its identity, signing login/admin intents, and decrypting namespace encryption keys. The code introduces new cryptographic operations (Ed25519 signatures, X25519 key exchange, HKDF, ChaCha20-Poly1305) and new user-confirmation prompts. It is a large feature addition, not a documented security fix. There is no direct evidence of a vulnerability in the diff, but any new crypto API surface carries implementation risk and should be reviewed carefully.

This commit simply swaps in newer pre-built bootloader stage1 binary files (version 1.2.2 replacing 1.2.1) for four BitBox02 hardware variants and updates the corresponding checksum list. The actual code inside the new binary files is not shown in the diff, and no description of why the update was made is provided. There is no visible evidence in the commit that this fixes or introduces a security problem.

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 BitBox02 firmware update is a broad security patch that fixes several independent bugs: it prevents a maliciously oversized USB report from overflowing memory, stops a corrupted Bluetooth pairing database from being read or written with invalid lengths, allows full-size firmware images in the bootloader, hardens how Bitcoin, Cardano, Ethereum, and typed-data (EIP-712) transactions are parsed and shown to the user, and adds a user confirmation before creating backups. The changes are defensive and reduce the chance that an attacker could trick the device into signing something the user did not intend.

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.