Keystone 3 firmware

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 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 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 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.

This commit fixes a build error in the 'cyperpunk' firmware variant by replacing a likely-undefined variable `len` with `seedLen` in two function calls that handle Zcash cryptographic key derivation. The change appears to be a straightforward compile fix rather than a security patch, but the use of the wrong variable could theoretically have led to reading an incorrect seed length if `len` had a different meaning or value.

This commit cleans up two places where TON (The Open Network) checksums were being converted to hex strings by hand-written loops, replacing them with a single helper function `ByteArrayToHexStr`. It also adds a debug print statement showing whether the TON and BIP39 mnemonic comparisons succeeded during the 'forget TON' flow. The title 'fix ton forget' suggests the change is meant to fix a bug in the process of forgetting/removing a TON wallet, but the diff itself does not show an obvious security vulnerability or a clear behavioral fix beyond code simplification and extra logging.

This commit replaces a custom secure-wipe function with a standard one in code that handles secret key material during password-based key derivation. The change is likely a defensive hardening fix, but the diff alone does not prove an exploitable vulnerability existed.

This firmware update fixes a bug in how the Keystone 3 hardware wallet handles TON (The Open Network) wallet setup. The changes remove several safety checks and replace safer string/buffer functions with less safe ones, while also restructuring how TON entropy and seed generation errors are handled. The commit title says it fixes a TON wallet bug, but the diff itself mostly removes defensive coding patterns rather than adding them. Without more context, it is unclear whether the change fully resolves the underlying issue or introduces new risks.

This commit removes a function that filled public key info for all cryptocurrency chains and adds a null-password check in the RSA key-reading path. The stated goal is to fix a crash. The crash likely happened because RSA key generation/reading ran while the password cache was empty, causing GetAccountSeed to dereference a null password. Removing the broad chain-info filler may also prevent crashes from partially initialized state during wallet setup or account switching.

This commit fixes a mismatch in how the firmware stores a recovery phrase (mnemonic) in memory. Previously, the code allocated memory based on the actual phrase length but then copied the phrase using a fixed maximum size. The change makes both steps use the same, correct length. This is a defensive fix that prevents potential memory corruption or undefined behavior when handling the secret recovery phrase.

This commit reviews and hardens the fingerprint sensor subsystem in the Keystone 3 hardware wallet firmware. It removes a custom CRC implementation and several hard-coded encryption keys used for fingerprint communication, replacing them with zero-initialized keys that are later populated at runtime. It also refactors command timeout/retry logic and removes a direct fingerprint sensor system-reset command. The changes reduce the risk that an attacker could exploit predictable keys or a weak checksum to interfere with fingerprint enrollment, recognition, or deletion, but the patch is only partial: the code still calls a removed CRC function in one place and the overall security impact depends on how runtime keys are generated.

This commit is a security-focused code review and hardening pass on account and secret handling in the Keystone 3 hardware wallet firmware. It replaces unsafe string and memory functions (strcpy, sprintf, memcpy) with safer bounded versions, removes debug printf leaks of sensitive data, fixes a bug where a new-password cache overwrote the password cache, adds compile-time guards against shipping test keys in production, and hardens JSON parsing against malformed flash data. These are defensive improvements that reduce the risk of buffer overflows, information leaks, and accidental weakening of secure-element protections.

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 mostly a routine cleanup and test-addition patch for Zcash support in the Keystone 3 firmware. It adds many Rust unit tests for error handling, PCZT parsing, and data structures, fixes a Cardano test that had an empty expected value, removes a stray blank line, and refactors the Zcash signing UI flow to use a shared internal helper. There is no direct evidence in the diff of a security vulnerability being fixed.

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 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 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 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.