Keystone 3 firmware

This commit is a pure code-style refactor in a Zcash transaction-checking function. It rewrites nested match statements into a flatter let-else and map_or pattern, but the commit message and diff show no change to the actual logic, error messages, or security behavior.

This commit is purely a code-style cleanup: it replaces repeated `alloc::format!` and `alloc::vec!` calls with a single `use` import at the top of the file. The commit message explicitly states there is no behavior change, and the diff confirms only import paths were shortened, with no logic, data flow, or security checks altered.

This commit is a code cleanup (refactor) in the Zcash PCZT handling code. It removes an unused internal check and an unused function parameter, renames a helper function, and changes its return type. The commit message explicitly states there is no behavior change, and the diff supports that: every caller already filtered by seed fingerprint before calling the helper, so the removed branch was unreachable. There is no security-relevant change evident from the diff.

This is a code cleanup change with no security impact. It replaces free-form text labels like "Orchard" and "Ironwood" with a fixed enum type when checking, parsing, and signing Zcash shielded transaction bundles. The actual behavior and error messages stay the same; only the internal code structure is improved.

This commit adds support for a new Zcash transaction format called Ironwood PCZT to the Keystone hardware wallet firmware. It also hardens the wallet against several real attack scenarios: legacy code paths now refuse to handle the new format (instead of mis-processing it), a bug where an attacker could make a payment to themselves look like the user's own change is now blocked, and malformed transaction bundles with contradictory value sums are rejected. The changes are mostly defensive and include many new regression tests.

This commit updates the Zcash-related Rust libraries inside the Keystone 3 firmware to newer versions. It also makes small code changes so the firmware keeps compiling with the new library APIs, removes some old tests that no longer work with the new wire format, and adjusts how transaction hashes are computed. The commit itself is described by its author as not building in isolation; the remaining matching changes are in the next commit. There is no direct evidence in the commit that this fixes or introduces a security vulnerability.

This commit is a pure internal code reorganization (refactor) for Zcash PCZT handling. It moves helper functions around, renames some UI rendering code, and adds a shared PCZT parsing helper, but the commit message and diff show no intentional behavior change. The original test suite is retained and reported to pass. There is no indication this fixes or introduces a security vulnerability.

This commit simply adds a new on-screen tutorial entry for a cryptocurrency wallet integration called 'Vizor'. It is a UI content addition with no security-relevant code changes.

This commit removes a single function call, FpCancelCurOperate(), from the lock screen's verification loading animation. The function likely cancels any ongoing fingerprint operation before showing a 'please wait' verification hint. Without additional context, it is unclear whether this change fixes a security bug or is simply a cleanup. The commit message gives no security explanation.

This commit fixes a race condition on the lock screen between password verification and fingerprint recognition. Previously, if a fingerprint scan result arrived while a password was being verified, the two flows could interfere with each other. The fix adds checks to ignore or delay fingerprint operations whenever a password verification loading screen is active, and cancels any ongoing fingerprint operation when that loading screen appears.

This commit simply adds a new wallet called 'Vizor' to the list of supported wallets in the Keystone 3 firmware's user interface. It includes a new icon image and registers the wallet name so users can select it. There is no indication of any security vulnerability or malicious change in the code shown.

This commit is a routine localization and asset update. It adds a Polish language translation, updates Korean font data to include one additional character, fixes minor code indentation, and reorders some translated strings. There is no evidence of any security fix or vulnerability being introduced.

This commit fixes several bugs in the firmware of the Keystone 3 hardware wallet, mainly around how Arweave (AR) cryptocurrency keys and RSA prime numbers are handled. It replaces direct array indexing with safer lookups, adds checks for missing or corrupted data, stores a hash of sensitive RSA primes in a secure chip, and erases that data when an account is deleted. The changes reduce the chance that a malformed or out-of-range value could cause the device to read the wrong key, crash, or leave sensitive key material behind after deletion.

This commit re-introduces Zcash-related firmware version reporting that had been temporarily reverted. It makes the device include its firmware version when generating Zcash wallet connection data and stamps the same version into every signed Zcash transaction response. The change also fixes two simulator-only stability issues: a crash when a text area is destroyed while keyboard events are still being processed, and a scheduling mismatch that made simulator background tasks run immediately instead of in order. There is no direct evidence in the commit that these changes fix an active security vulnerability; the Zcash additions are a feature/resumption, and the simulator fixes are development-environment hardening.

This commit is a straightforward revert that removes a recently-added Zcash firmware-version reporting feature. It strips out code that embedded the Keystone firmware version into Zcash PCZT (partially-created transaction) responses and into Zcash wallet-connection QR data. The change also reverts two simulator-only UI/framework tweaks that were apparently part of the same feature branch. There is no direct evidence in the commit of a security vulnerability being fixed; it reads like a product decision to back out a feature.

This commit fixes a simple C compiler error in the account manager. A variable named validCount and a loop counter i were used but never declared, and an indentation/whitespace mistake was corrected. There is no security-relevant change visible in the diff.

This commit changes two things in a cryptocurrency hardware wallet's firmware. First, it makes several low-level secure-chip operations crash or halt the device if the chip reports any unexpected failure, rather than returning the error to the caller. Second, it adds a startup check that tries to detect partially-written account data (for example, after a sudden power loss during a factory wipe) and erases the affected account. The commit title says only 'resolve the code review comments' and does not describe any security issue.

This commit updates the user interface and internal checks for generating wallet seed phrases using dice rolls as a source of randomness. It enforces a minimum number of dice rolls depending on the desired seed strength: at least 50 rolls for 12-word (BIP39) or 20-word (SLIP39) seeds, and at least 100 rolls for 24-word (BIP39) or 33-word (SLIP39) seeds. Previously, the firmware only required 50 rolls regardless of seed length. The change is a security hardening measure to ensure that higher-strength seeds receive enough physical entropy, but it is a partial patch because the dice-roll input itself is not fully validated and the entropy extraction method is not visible in this diff.

This firmware update changes how the Keystone hardware wallet stores and checks device passwords. Previously, the device kept a separate password hash page in its secure element (SE) storage. After this update, password verification is done by trying to decrypt the actual account secret using the password, and the old password hash pages are wiped. The change also removes hard assertions on SE operations so that failures return error codes instead of crashing, and it maps a specific secure-element authentication failure to a wrong-password error. The version number is bumped from 12.4.6 to 12.5.0.

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 only moves three existing UI source files into a different folder (the web3 build variant). The code itself is unchanged, so this is a build-system/organization fix rather than a security patch. It likely prevents the Babylon 'derive context hash' screen from being compiled into non-web3 firmware builds.

This commit only adds a new section to two changelog files describing version 2.4.6 and a new feature ('Support babylon derive context hash call'). No source code, configuration, or executable files were changed. There is no security-relevant content in the diff itself.

This commit removes an early 'return' statement in the Sui transaction-checking function on the Keystone 3 hardware wallet. Before the fix, the function would immediately return a blank 'success' result without validating the master fingerprint or inspecting the transaction. That means a malicious or malformed Sui transaction request could bypass the normal security checks the device is supposed to perform. The fix allows the intended validation code to run.

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 simply bumps two Rust library versions (ur-registry and ur-parse-lib from 1.0.3 to 1.0.4) and updates an unrelated image asset hash file. There is no visible security fix or vulnerability in the diff itself. Without knowing what changed in the updated dependencies, we cannot classify this as a security patch.