Keystone 3 firmware

This is a one-line build-configuration fix for the Keystone hardware wallet's Zcash transparent transaction signing. Previously, the code that signs the transparent (non-shielded) part of a Zcash PCZT transaction was only compiled when the 'multi_coins' feature was enabled. The change also enables that signing code when the 'cypherpunk' feature is enabled. Without this fix, a device built with only the 'cypherpunk' feature could produce an incomplete or invalid Zcash transaction signature, likely causing the transaction to be rejected by the network rather than stealing funds.

This commit adds support for a new wallet partner called Gero Wallet in the Keystone 3 firmware. It is a routine feature addition: a new icon, a new entry in wallet lists, a tutorial link, and recognition of the wallet's origin name when handling key-derivation requests. There is no indication of a security fix or vulnerability.

This commit fixes a product limitation: Keystone 3 hardware wallets using a SLIP39-style recovery phrase could not connect to the Keystone mobile app for Zcash. The patch removes Zcash from the list of coins shared when a SLIP39 wallet is used, and it makes the underlying Rust code accept a missing Zcash seed fingerprint. There is no direct evidence this is a security vulnerability; it appears to be a compatibility/functional bug fix.

This commit fixes a build-configuration bug that could prevent creating or saving public key information when using a SLIP39 passphrase. The old code accidentally skipped the normal key-derivation path for certain crypto types in non-Bitcoin-only builds, which could leave required public key data unset and cause account setup to fail. The patch restructures the conditional compilation so each build variant (Cypherpunk, Web3, Bitcoin-only) follows the correct derivation branch.

This commit is a large refactor of how the Keystone 3 firmware handles Zcash transactions. It splits the code into two build flavors: a 'multi-coins' build that supports only transparent (public) Zcash addresses using a normal xpub, and a 'cypherpunk' build that also supports shielded Orchard addresses using a unified full viewing key (UFVK). The change reorganizes feature flags, renames functions, and adjusts how Zcash account data is cached when wallets are created or unlocked. There is no explicit security fix or vulnerability disclosure in the commit message, and the diff itself is mostly structural. A few small items stand out as worth checking: a typo in a feature-guard macro (CYBERPUNK_VERSION vs CYPHERPUNK_VERSION) could leave the cypherpunk UI path disabled, and a debug printf was left in production key-handling code. On its own, this commit does not appear to introduce a clear exploitable vulnerability, but it is a partial refactor and the new multi-coins transparent-only path is simpler and exposes less shielded-key material than before.

This commit is a work-in-progress 'temp commit' that refactors Zcash support in the Keystone 3 firmware. It moves Zcash UI code from a 'cypherpunk' build variant into the standard multi-coin build, splits a combined Zcash UFVK/seed-fingerprint getter into separate functions, adds a new Zcash seed fingerprint parameter to the Keystone Connect wallet QR/UR generation, and enables the 'zcash' feature in the Rust multi-coins build. There is no clear security fix or vulnerability being patched; it appears to be feature plumbing and code reorganisation.

This commit adds support for the Zcash (ZEC) cryptocurrency to the Keystone 3 hardware wallet firmware. It introduces address generation, derivation path handling, UI elements, and wallet connection data for Zcash. There is no indication of a security fix or vulnerability being patched.

This commit adds support for Litecoin (LTC) native SegWit addresses (the 'ltc1...' format) to the Keystone 3 hardware wallet firmware. It is a feature addition: it lets users generate and display a new type of LTC address and export the corresponding public key. There is no indication in the commit that it fixes a security bug or vulnerability.

This commit fixes the firmware's build for a software simulator. It removes an unused public-key derivation step in Bitcoin PSBT handling, relaxes a hardware-only flash-read assertion when compiling the simulator, and adds a simulator-only header. There is no clear security fix for real hardware; the changes are build-compatibility adjustments.

This commit adds support for Litecoin (LTC) native SegWit addresses (the 'ltc1...' format) to the Keystone 3 hardware wallet firmware. It is a feature addition: it lets users generate and display LTC native SegWit receive addresses, export the corresponding extended public key, and includes new UI labels and a tutorial. There is no indication in the commit that this fixes a security bug or introduces a vulnerability.

This commit fixes build errors in the simulator (non-production) build of the Keystone 3 firmware. It removes an unused public-key derivation step in Bitcoin PSBT handling, relaxes a hardware flash-read assertion when compiling for the simulator, and adds a simulator-only header include. There is no evidence of a security vulnerability being patched.

This commit changes how the Keystone 3 hardware wallet displays Bitcoin transaction recipients. Specifically, it hides the 'change' label on outputs that return bitcoin to the user's own wallet when the transaction comes from a 'legacy' format. This is a user-interface change, not a fix for stealing funds. It may reduce user clarity during transaction review, but it does not by itself allow an attacker to move coins.

This commit fixes how the Keystone 3 hardware wallet parses Bitcoin PSBT (Partially Signed Bitcoin Transaction) outputs. The change adds verification that an output's Bitcoin address actually matches the public key and derivation path claimed in the transaction, rather than trusting the PSBT's output metadata blindly. If the previous code accepted incorrect or attacker-controlled output data, a user could be tricked into approving a transaction that sends funds to an unexpected address. The commit also refactors some address-calculation code into a shared helper.

This commit changes how the Keystone hardware wallet labels Bitcoin transaction outputs on its screen. It adds a new 'is_mine' flag and shows 'Change' or 'Receive' labels next to outputs that belong to the user's own wallet. The goal appears to be helping users more easily recognize their own change outputs during transaction review, which is a usability and anti-confusion improvement rather than a fix for an exploitable vulnerability.

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.

This commit is a routine code cleanup in the Ethereum module of the Keystone 3 firmware. It renames a function for clarity, changes some function signatures to accept data slices instead of owned vectors for efficiency, and replaces a few direct `.unwrap()` calls with safer `.unwrap_or_default()` handling. There is no indication this fixes a security vulnerability.

This commit is a code-review hardening pass for the Cardano wallet module in the Keystone 3 firmware. It replaces many Rust `.unwrap()` calls with proper error handling, adds bounds checks for derivation paths and public keys, zeroizes sensitive seed/entropy buffers after use, and fixes a seed-length bug for BIP39 vs SLIP39 accounts. Most changes reduce the chance that malformed transaction data or missing key material causes a crash or leaks secrets, but the commit is broad and includes many test additions, so it is better characterized as defensive cleanup than a single fixed vulnerability.

This commit is a code review and cleanup of the Cosmos cryptocurrency support in the Keystone 3 hardware wallet firmware. It fixes several small but real issues: it corrects a buffer-size mismatch when copying passwords/passphrases into memory, avoids unnecessary cloning of transaction data, adds zeroing of the seed buffer after signing, and fixes memory leaks and repeated JSON parsing in the Cosmos UI code. There is no clear evidence of an exploitable remote attack, but the changes reduce the chance of memory corruption and secret leakage.

This commit refactors the Sui blockchain support in the Keystone 3 hardware wallet firmware. The main security-relevant changes are: replacing several panic-prone `.unwrap()` calls with proper error handling, adding checks for empty derivation paths that previously could have caused crashes or undefined behavior, validating public key length during address generation, and ensuring the wallet's seed is wiped from memory (zeroized) more reliably after signing. The commit also fixes a memory-freeing bug in the user interface where the wrong type of result could be freed depending on whether a normal transaction or a 'sign message hash' request was being handled.

This commit hardens how a hardware wallet (Keystone 3) handles sensitive RSA prime numbers used for Arweave transactions. It adds explicit length checks on seeds and prime inputs, switches to a safer memory-clearing helper (`zeroize` in Rust, `memset_s`/`CLEAR_ARRAY` in C), and removes an unused RSA helper that could have accepted arbitrary-length secrets. The changes reduce the risk of crashes, memory leaks of secret material, and misuse of malformed keys, but the commit itself is a defensive refactor rather than a fix for a confirmed active exploit.

This commit updates the Rust zeroize library from version 1.8.1 to 1.8.2 in a cryptocurrency hardware wallet firmware project. The zeroize library is used to securely erase sensitive data like private keys from memory after use. The commit also adds a large Chinese-language technical specification document for Sui blockchain support. The actual code change is a routine dependency patch with no direct exploit visible in the diff, but the commit message claims it is for 'improved security features.'

This commit is a code review and cleanup pass for the Avalanche (AVAX) app in the Keystone 3 hardware wallet firmware. It fixes typos in transaction type names, adds a few length checks before reading transaction bytes, replaces direct low-level signing with a safer helper, and consolidates signing code so AVAX, IOTA, and SUI share the same secure path. Most changes are defensive hardening and refactoring rather than a single obvious critical bug fix.

This commit is a defensive security hardening patch for the Keystone 3 hardware wallet firmware. It adds the `zeroize` Rust crate and explicitly clears sensitive memory buffers (mnemonics, seeds, passwords, RSA seeds, entropy, SLIP39 shares) after use. It also replaces many unsafe `strcpy`/`strcat`/`memcpy` calls with safer bounded versions, removes several `unwrap()` panic points in Rust FFI code, and tightens error handling in wallet creation and recovery flows. The changes reduce the risk that secret material remains in RAM after operations, and reduce the chance that malformed input crashes the device or leaks secrets through panic paths.

This commit only updates unit tests for the Avalanche transaction parser. It swaps test blockchain IDs from mainnet to testnet values, removes debug print statements, fixes an import order warning, and replaces placeholder assertions with real ones. There is no change to production code that handles user funds or device security.