Keystone 3 firmware

This commit refactors how TON (The Open Network) transactions are displayed on the Keystone 3 hardware wallet. Previously, the code assumed every transaction had exactly one message. Now it supports multiple messages, showing each one separately on screen. The change also fixes a small bug where a proof-result pointer was incorrectly cleared, and adds a safety check when parsing contract data JSON. There is no direct evidence in the commit of a security vulnerability being fixed, but supporting multi-message transactions is a meaningful hardening improvement because a malicious or unusual transaction with several messages could previously have been misrepresented or mishandled.

This commit adds a new feature to the Keystone 3 hardware wallet that lets approved Bitcoin apps (like Babylon) request a special cryptographic hash derived from the wallet's seed. The wallet shows the user the connected Bitcoin address and, after approval, returns a 32-byte hash. The code includes checks to limit which apps can ask, which Bitcoin networks are accepted, and which derivation paths can be used. It also adds a testnet display toggle for Bitcoin receive addresses. There is no direct evidence in the commit that this fixes a known security vulnerability; it appears to be a feature addition.

This commit removes support for the 'Leap' wallet from the Keystone 3 firmware. It deletes the Leap wallet icon and asset, removes Leap-related text strings from Chinese, Japanese, and Korean font files, and updates the Rust dependency versions for the UR (Uniform Resources) parsing libraries used by the firmware. There is no indication of a security fix or vulnerability being patched.

This commit adds a safety check for the Keystone 3 hardware wallet's Zcash account setup. If the stored Zcash public key information is missing or not a valid hex string, the wallet now regenerates it. This prevents the wallet from trying to use corrupted or incomplete Zcash key data, which could cause errors or display wrong addresses. It is a defensive fix, not a clear exploit patch.

This commit changes the default backup seed phrase length for the standard firmware from 33 words to 20 words. SLIP39 seed phrases can use different word counts, and 20 words still provides substantial entropy. There is no direct evidence in the commit or supplied references that this change fixes a security vulnerability; it appears to be a product/usability change.

This firmware update fixes two categories of bugs in a cryptocurrency hardware wallet's background task system and web-authentication code display. First, it adds a flag so the background task knows whether it allocated a memory buffer itself (and must free it) or was given a pointer by the caller (which it must not free). Before this fix, the task could free memory it did not own, leading to crashes or corrupted memory. Second, it hardens the web-authentication code calculation by checking whether memory allocation succeeded, clearing the private RSA key from memory after use, and correctly freeing the generated auth code string. It also removes two lines that incorrectly set freed pointers to NULL inside a cleanup function. The changes are defensive and reduce the risk of memory corruption and sensitive key material lingering in RAM, but the commit message frames them as generic fixes rather than as a security advisory.

This commit changes how the Keystone hardware wallet enables Zcash for SLIP 39 wallets. Previously, Zcash was completely disabled for all SLIP 39 wallets. Now it is allowed when the SLIP 39 shares are 33 words long (256-bit entropy), but still disabled for 20-word shares (128-bit entropy). The change is driven by a cryptographic requirement: Zcash's security analysis assumes the wallet seed has at least 256 bits of entropy. The patch also fixes a small UI bug where the 'manage' option for Zcash was missing entirely for non-BIP39 mnemonics, instead of being shown as disabled.

This commit changes the default Shamir backup share length from 20 words to 33 words and adds on-screen explanations about which cryptocurrencies each option supports. It is a usability and compatibility improvement, not a security fix or vulnerability. The code also tightens a few display routines so the word count is shown correctly regardless of the selected value.

This commit fixes a small but meaningful bug in the Keystone 3 hardware wallet's account information output. Previously, when showing details for Monero (XMR), the 'manage' field was completely left out if the wallet's mnemonic type was not BIP 39. Now it is always included and set to false in that case. The change makes the JSON response predictable and consistent, which can help companion apps or users avoid misinterpreting whether the coin can be managed. It is a defensive fix rather than an obvious exploit, but omitting a boolean field could lead a connected app to make unsafe assumptions.

This commit is a straightforward build fix for a firmware configuration file. It adds conditional preprocessor definitions so that different product build variants (Web3, BTC-only, Cypherpunk) each define a required constant, LEGACY_USB_PAD_LEN, with values of either 1 or 2. Without this change, some build configurations would fail because the constant was missing. There is no security-relevant change in behavior visible in the diff.

This is a one-line build fix that changes a default padding length constant from 1 to 2 in a legacy USB web-update feature. There is no indication of a security problem, and the change itself does not introduce or fix any vulnerability visible in the diff.