BitBox02 firmware

This commit turns on a stricter compiler warning that catches risky pointer casts in C code, and fixes the resulting warnings. The changes replace direct casts from byte buffers to larger types (like treating a raw byte array as a 32-bit number or USB frame) with safer memcpy-based copies. The commit message explicitly frames these as classes of undefined behavior (alignment and strict-aliasing issues) that could lead to miscompilation or incorrect reads. It is a hardening/correctness patch rather than a fix for a known exploitable bug, but the affected code paths include bootloader pairing-code handling, firmware version parsing, USB packet processing, and BLE pairing-code display.

This commit fixes a bug in the Bluetooth Low Energy (BLE) handling code for the BitBox02 hardware wallet. Previously, the code assumed incoming data packets were exactly 64 bytes long, but that size check was removed in release builds. If a malformed or partial packet arrived, the device could process leftover or incorrect data. The fix adds a runtime length check and drops any packet that is not the expected size before it is passed further into the system.

This commit fixes a low-level coding issue in the firmware that talks to a Bluetooth chip (DA14531). The code was reading 2-byte numbers from positions in a byte buffer that might not be properly aligned in memory, which is undefined behavior in C. The fix uses memcpy instead of direct pointer casts, which is safe regardless of alignment. On its own this is a robustness/correctness fix; there is no direct evidence in the commit that it is exploitable as a security vulnerability.

This commit fixes a bug in the firmware that talks to a Bluetooth chip over a serial (UART) link. If a malformed or truncated message shorter than 5 bytes reached the validation step, the code would subtract 5 from the message length. Because the length was stored as an unsigned number, the result wrapped around to a very large value instead of becoming negative. That large value could then be used to read memory outside the intended buffer, potentially leaking data or causing the device to behave unpredictably. The fix rejects any frame shorter than 5 bytes before doing the subtraction.

This is a small code cleanup change. A function that sends the device's Bluetooth name to a wireless chip is simplified by removing an unnecessary length parameter. The function now figures out the string length itself using strlen(), which is exactly what every caller was already doing. There is no security issue visible in this change.

This commit is a minor code cleanup in the BitBox02 firmware's Rust wrapper around secp256k1 cryptography. It removes temporary variables that held function return values and instead checks those return values directly inside 'if' conditions. There is no change to program logic, no security fix, and no new vulnerability.

This commit is a small code cleanup in the BitBox02 firmware's Rust code. It replaces runtime hex decoding with a compile-time macro for test data only. There is no security vulnerability here—just a dependency swap that makes unit tests slightly more efficient and removes an unused dev-dependency.

This commit hides a special testing-only function from the normal firmware build. The function itself is not a vulnerability; it is a build-hygiene change to make sure code meant only for unit tests is not compiled into the real device firmware. That reduces the attack surface slightly, but it does not fix any known bug.

This commit removes a duplicate low-level binding to a secp256k1 cryptographic function and replaces its use with an equivalent, already-vetted wrapper from the project's dependency on the bitcoin::secp256k1 Rust crate. It is a code cleanup/refactoring change with no security-relevant behavior change visible in the diff.

This commit is a build-system refactor: it moves the secp256k1 cryptographic library dependency into a new Rust crate called bitbox-secp256k1 so it can be built with normal Cargo tooling instead of CMake. The actual cryptographic functions (signing, nonce commitments, DLEQ proofs, etc.) are copied almost unchanged from existing modules into the new crate. There is no direct evidence in the commit that this fixes a security vulnerability or introduces a new exploit.

This commit rewrites a small piece of the BitBox02 factory-setup code from C to Rust. The code verifies a cryptographic signature on the device during factory setup. The change itself is a routine refactoring: it removes the old C secp256k1 library call and replaces it with an equivalent Rust call. There is no indication in the commit that this fixes a known security bug, and the new Rust code includes tests for invalid inputs. On its own, this looks like a defensive hardening/cleanup change rather than a vulnerability fix.

This commit is a purely cosmetic code-formatting change. It shortens a single Python print statement from multiple lines to one line, with no change to what the program does or how it behaves.

This commit rewrites the BitBox02 firmware's date/time formatting from C to Rust and vendors several new Rust crates (time, deranged, powerfmt, num-conv) to do it. The change is described by the vendor as a code-quality and binary-size improvement, not a security fix. There is no direct evidence in the commit of a vulnerability being patched, but any rewrite of formatting code can in principle introduce subtle bugs such as buffer handling or timezone mistakes. The large amount of newly vendored code increases the supply-chain/bug surface that future audits should watch.

This commit is a straightforward internal refactoring: it moves the device-reboot-into-bootloader function behind a new 'System' hardware-abstraction trait so the rest of the Rust code calls it through a generic interface rather than directly. The actual reboot behavior, safety checks (a user confirmation screen), and underlying C function are unchanged. There is no new vulnerability here; it is normal code cleanup.

This commit adds a new graphical simulator for the BitBox03 hardware wallet. It is purely a development and testing tool: it creates a window that mimics the device screen, accepts simulated USB/TCP traffic, and can optionally pre-seed a test mnemonic. There is no change to the actual firmware that runs on real devices, and nothing in the commit fixes or introduces a security vulnerability in shipped products.

This commit rewrites a low-level serial-link framing and CRC routine from C into Rust for the BitBox02 hardware wallet's Bluetooth companion-chip (DA14531) communication. It removes a hand-generated C CRC implementation and uses a standard Rust `crc` crate instead. The change is a refactor/port, not a fix for a known vulnerability. There is no direct evidence in the commit or supplied references that this change addresses a security bug.