BitBox02 firmware

This commit is a code reorganization: it moves the BIP39 seed derivation and root fingerprint storage from one Rust module to another. The same logic is preserved, including a safety check that derives the seed twice to detect memory corruption. There is no visible security fix or vulnerability being introduced.

This commit adds two digital signature files for the BitBox02 firmware version 9.24.0. These signatures are part of the release attestation process, where a trusted person (here, 'nickez') cryptographically signs the released firmware so users can verify its authenticity. No code was changed, and there is no indication of any security bug or vulnerability.

This commit is a simple internal code reorganization: a function that converts a seed into a BIP39 recovery phrase is moved from one Rust module to another, with all callers updated. The actual behavior of the function is unchanged, and no security bug is introduced or fixed.

This commit is a code cleanup and refactoring change. It moves test-only helper functions (used to simulate an unlocked device during automated tests) from one internal Rust module to another, closer to where they are actually used. It also moves a BIP39 mnemonic-to-seed conversion function into a more appropriate module. There is no change to the actual device firmware behavior, user-facing functionality, or security logic.

This commit is a routine internal code reorganization in the BitBox02 firmware. It moves two existing keystore functions—used to unlock and copy the BIP39 seed—into a higher-level Rust wrapper module, and renames the original low-level functions with an underscore prefix so the compiler flags any remaining direct callers. The change does not alter the cryptographic behavior, add new user-facing features, or fix a known security bug. It is preparation for a future native Rust implementation.

This commit only rewrites comments in the factory setup code to explain why two bootloader flags are set the way they are. No code behavior is changed, so it has no security impact on its own.

This firmware update fixes a bug where using U2F security-key features over USB accidentally turned off Bluetooth Low Energy (BLE). Because iPhones and iPads can use U2F over USB, disabling BLE meant the device could not reconnect wirelessly after the iOS device woke up. The patch also makes the firmware ignore a harmless 64-byte 'wake-up' packet sent by iOS. There is no direct evidence this is an exploitable security vulnerability; it appears to be a connectivity/availability bug.

This commit adds release artifacts for BitBox02 firmware version 9.24.0. It contains two signed statements (assertions) confirming that building the source code at a specific git tag produces a firmware binary with a known SHA-256 hash. There is no code change, no bug fix, and no security-related content in the commit itself.

This commit adds release artifacts for firmware version 9.23.3 of the BitBox02 hardware wallet. It contains two signed text files (assertions) confirming the expected SHA-256 hash of the compiled firmware binary for both the standard and Bitcoin-only editions. There is no code change and no security issue visible in the diff.

This commit deliberately runs the wallet-unlock calculation twice instead of once, purely to keep the on-screen unlock animation from finishing too quickly after a performance improvement. The second run is used as a consistency check: if the two results don't match, the device reports a memory error. The change is framed as a user-experience fix that happens to add a safety double-check, not as a response to a known security bug.

This commit is a large internal refactoring of the BitBox02 firmware's BIP39 wallet-unlocking code. It converts the slow PBKDF2 key-stretching loop from a blocking (synchronous) operation into an asynchronous one, so the device can briefly pause each round to handle other tasks such as USB messages and screen animations. The commit also vendors the futures-core, futures-lite, and pin-project-lite Rust crates so the firmware can use async/await. The change is explicitly described by the authors as not yet fully functional on its own; a follow-up commit is needed to make the unlock animation work with the new async model. There is no direct evidence in the commit that this fixes or introduces a security vulnerability; it is primarily an architectural/performance change.

This commit updates the BitBox02 firmware's vendored copy of a Rust library (rust-bip39) used to turn a recovery phrase into a cryptographic seed. The main change is adding an async (cooperative multitasking) version of the seed-derivation function so the device can briefly pause between heavy PBKDF2 rounds instead of blocking the main loop. It also moves the dependency from a personal fork to the BitBoxSwiss organization fork and adjusts a transitive dependency version. There is no direct security fix or vulnerability patch visible in this commit; it is a dependency/vendor refresh and async API addition.

This commit is a hardening improvement, not a fix for an active vulnerability. It reduces how often the BitBox02 hardware wallet talks to its secure chip (the Optiga) when checking a password. Previously, an extra secure-chip call was made to fetch and compare the seed; now the device compares a locally retained hash instead. This lowers the chance of hitting the secure chip's throttling/lockout counter during normal use, which could otherwise make the device temporarily unusable or even require reset. The change does not introduce a known exploit path.

This commit changes the order of operations in two developer-only GDB scripts used with J-Link debuggers. Previously the scripts loaded new firmware onto the device and then reset the CPU; now they reset the CPU first and then load the firmware. The change is described as a reliability fix for odd behavior seen when the device's watchdog timer is enabled. It only affects how engineers flash firmware during development/debugging and does not change any firmware code, cryptography, or user-facing behavior.

This commit adds two digital signature files for firmware version 9.23.2. These signatures are part of the project's reproducible-build attestation process, where an independent party (nickez) confirms that the published firmware matches the publicly available source code. No code, no bug fix, and no security vulnerability is present in the change itself.

This commit adds two digital signature files to the repository. They are a third-party reproducible-build assertion for the BitBox02 firmware version 9.23.2, signed by someone named 'sutterseba'. It does not change any firmware code, fix any bug, or introduce any new feature. There is no security issue here.

This commit simply adds official release signatures and build attestation files for firmware version 9.23.2. It does not change any source code, fix any bug, or alter any behavior of the BitBox02 device. There is nothing in the commit that introduces or addresses a security issue.

This commit is a routine code cleanup: it changes many Rust source files to import a small async helper module from a shared utility crate (`util::bb02_async`) instead of from the local crate (`crate::bb02_async`). There is no change to program logic, no bug fix, and no security-relevant behavior.

This commit adds the ability to include OP_RETURN outputs when signing Bitcoin transactions on a BitBox02 hardware wallet. OP_RETURN is a special Bitcoin output type used to embed small pieces of data (like text or hashes) on the blockchain. The device now shows the user the data being embedded and asks for confirmation before signing. The commit also enforces that OP_RETURN outputs must carry zero Bitcoin value, so no money can accidentally be burned into them.

This commit is a straightforward refactoring: it moves the BIP39 seed derivation and wallet-unlock logic from C into Rust, splitting one C function into a Rust wrapper plus two existing C helper functions. There is no change to the cryptographic behavior, no new user-facing feature, and no obvious security bug introduced. It appears to be a code-quality/architecture change to prepare for making the unlock flow asynchronous.

This commit is a simple internal code reorganization. It splits one existing function, keystore_unlock_bip39(), into three smaller functions: a check, a finalize step, and the original wrapper that calls both. The actual behavior and security checks appear unchanged. There is no indication this fixes or introduces a security issue.

This is a routine maintenance update that upgrades the Rust compiler toolchain from an older version to Rust 1.90.0 for the BitBox02 hardware wallet firmware. It refreshes many third-party Rust libraries (vendored dependencies), adjusts build configuration files, and saves a small amount of firmware space. There is no direct evidence in the commit of a security vulnerability being fixed or introduced. The main security consideration is that compiler and library updates can change generated code behavior, so thorough testing is warranted, but nothing in the diff points to an active security issue.

This commit is a performance and reliability improvement, not a security fix. It changes how the BitBox02 hardware wallet restores a wallet so that the device does not repeatedly ask its secure chip for the same seed during restore. Instead, the seed is passed directly to the BIP39 unlock step and verified against a stored hash. The goal is to avoid hitting the secure chip's throttling limit (133 events) when users repeatedly reset or restore the device. The change does not remove any security check; it only avoids an unnecessary secure-chip read by comparing a hash of the seed instead.

This commit adds a new device API that lets a host computer request up to 20 Bitcoin extended public keys (xpubs) in a single call, instead of making one call per key. The goal is to reduce how often the device talks to its secure chip, avoiding a throttling safeguard. The change itself is a feature addition, not a fix for a known vulnerability, and the code applies existing keypath validation and a double-check against bitflips.

This commit swaps one internal cryptographic library for another when computing a special fingerprint used in a backup/recovery feature (BIP-85). The change is described by the developer as a cleanup to use a single, consistent library. There is no direct evidence in the commit that it fixes a security bug or that any vulnerability exists.