Keystone 3 firmware

This commit only changes a single software version number (the build counter from 0 to 2) in a header file. There is no functional code change, no bug fix, and no security-related content visible in the diff.

This commit adds support for a new software wallet called Nabox to the Keystone 3 hardware wallet firmware. It is a routine feature addition: new icon images, generated image source files, and registration of the wallet in UI lists. There is no indication of a security fix or vulnerability.

This commit is a user-interface cleanup for the 'connect wallet' screen. It removes many unused wallet-list image files and their generated C code, updates one remaining icon (Backpack) to a larger size, and refreshes an image-hash file. There is no visible change to security-sensitive code, cryptography, transaction handling, or communication logic.

This commit fixes a single-character bug in the hardware wallet's 'connect wallet' screen. The original code used a single equals sign (=) instead of a double equals sign (==), which in C means it assigned a value rather than checking it. As a result, the code always treated the wallet as a Bitcoin wallet and ran the Bitcoin-specific tutorial branch, regardless of which wallet the user actually selected. The fix changes it to a proper comparison (==).

This commit fixes a crash in the TON (The Open Network) signing code for the Keystone 3 hardware wallet. Previously, if a user had not set a custom derivation path, the code would blindly copy the seed bytes into a fixed 32-byte secret key buffer. If the seed was shorter than 32 bytes, this would read past the end of the seed data, causing a crash or undefined behavior. The fix checks the seed length first and returns a controlled error if it is too short.

This commit is a routine user-interface update for the Keystone 3 hardware wallet firmware. It swaps in a larger Zeus wallet icon, adds a new Bitcoin wallet-list icon, updates the corresponding image asset files, refreshes an image-hash file, and adjusts a few UI labels and status-bar resources. There is no change to cryptographic code, transaction signing, key handling, parsing of untrusted data, or any other security-sensitive logic.

This commit only changes one line in a Chinese-language changelog, correcting the heading 'Bug Fixes' to 'Bug 修复' (Chinese for 'Bug Fixes'). No code, configuration, or documentation with security implications was modified.

This commit only edits the formatting and wording of a product changelog. It adds blank lines and changes headings like 'BTC-ONLY' to 'BTC Only' and 'CYPHERPUNK' to 'Cypherpunk'. No code, configuration, or security-related content was changed.

This commit only adds a new version entry to the changelog files and bumps the firmware version number from 2.2.20 to 2.3.0. It does not change any executable code, cryptographic logic, or security-sensitive behavior. There is no security issue in this commit itself.

This commit is a routine maintenance change titled 'chore: optimize test and lints'. It updates code-coverage thresholds in CI workflows, adds Rust lint configuration for a nightly coverage feature, removes an obsolete nightly Rust feature flag, and adjusts some test data and test cases. There is no indication of a security fix or vulnerability being addressed.

This commit fixes a software crash in the wallet connection screen of the Keystone 3 hardware wallet firmware. The code now checks whether a selected coin/wallet type was found before continuing. Without this check, the device could crash when connecting to a wallet it does not recognize, likely causing a denial of service rather than theft of funds.

This commit only reformats two lines of Rust source code. It does not change what the code does, only how it is visually laid out. There is no security relevance.

This commit fixes how the Keystone hardware wallet handles Bitcoin 'sign message' QR codes. Previously, many malformed or unsupported message formats were reported as 'unsupported transaction,' which could mislead users. The change introduces a clearer 'Invalid Message' error and adds a new Japanese font glyph. It is primarily a user-experience and error-handling improvement, not a fix for a known exploit.

This commit fixes a Bitcoin multisig signing flow in the Keystone 3 hardware wallet firmware. Previously, when a transaction did not need a signature, the code exported the PSBT but did not properly handle the result object; when it did need a signature, it signed but skipped updating the UI status and freeing the result. The patch unifies both branches so the result is always processed and cleaned up. It also wraps some legacy Keystone transaction code in a WEB3_VERSION compile guard, likely preventing it from running on Bitcoin-only firmware builds where it could behave incorrectly.

This commit refactors how the Keystone hardware wallet exports Bitcoin account data (extended public keys) when pairing with BlueWallet and other apps. Previously BlueWallet received only three key types (Native SegWit, SegWit, Legacy). Now it uses the same function as Sparrow/Zeus/UniSat, which also includes the Taproot key type. This is a feature addition, not a vulnerability fix, and does not change how secrets are handled.

This commit changes two Zcash-related functions in the Keystone hardware wallet firmware so that the wallet seed is no longer treated as a mutable buffer and is no longer explicitly wiped (zeroized) from memory after use. The title says 'fix zcash unwrap,' suggesting the change was made to resolve a Rust panic caused by calling .unwrap() or by a mutability mismatch. Removing zeroize reduces memory cleanup of the secret seed, which could leave sensitive material in memory longer than intended. However, the diff alone does not prove an exploitable vulnerability; it may simply trade one bug for another.

This commit adds a single missing function declaration (PreparePublicKeys) in a Bitcoin UI source file. It is a straightforward build fix with no visible security relevance.

This commit is purely a code-formatting change. It only rewrites two test assertions in a Rust file so they fit on single lines instead of being split across multiple lines. No logic, behavior, or security checks were changed.

This commit only adds and updates unit tests. It does not change any production code. The tests verify that all-zero and all-0xFF seeds are rejected as invalid by several cryptographic modules. There is no security fix or vulnerability introduced here.

This firmware update adds a safety check that refuses to use cryptocurrency seeds made entirely of 0x00 or 0xFF bytes across Cardano, Bitcoin-style (secp256k1), Ed25519, RSA, and Zcash key operations. Such 'trivial' seeds produce predictable or weak private keys that attackers could guess. The patch also moves a memory-clearing call in Ethereum batch signing so the seed is wiped only after all transactions are processed, rather than after the first one. The commit message does not call this a security fix, but the change clearly reduces a key-derivation risk.

This commit fixes a bug in the Bitcoin PSBT (Partially Signed Bitcoin Transaction) handling code of the Keystone 3 hardware wallet firmware. The bug involved passing the wrong size for the master fingerprint (mfp) buffer to several Rust/C FFI functions. In C, `sizeof(mfp)` where `mfp` is a function parameter of type `uint8_t*` gives the size of a pointer (typically 4 or 8 bytes), not the actual 4-byte array length. The fix adds an explicit `mfpLen` parameter so the correct length (4 bytes) is passed. The commit title 'psbt crash' suggests this mismatch caused crashes when parsing or signing PSBTs. A separate cleanup refactors how public key arrays are prepared to avoid stack-use-after-scope issues.

This commit fixes how the Keystone hardware wallet selects the Cardano (ADA) key derivation algorithm when a passphrase is used. Previously, the selected derivation style was stored in a global variable that was not reset between wallet sessions. If a user switched between a standard wallet and a passphrase-protected wallet, the device could continue using the wrong derivation path, producing Cardano public keys and addresses that do not match the user's expected wallet. This could make funds appear missing or, in rare cases, lead to sending or receiving to an unintended address family. The patch resets the derivation choice when memory is freed and re-initializes it from the current account type when the key-derivation screen is opened.