Keystone 3 firmware

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 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 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 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 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 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 updates the TON (The Open Network) cell serialization code in the Keystone 3 firmware to use a newer version of the bitstream-io library. The changes are mostly mechanical renames of method calls (e.g., write/read becomes write_var/read_var) to match the new library's API. There is no explicit security fix described in the commit, and the diff alone does not show a patched vulnerability. It appears to be a dependency maintenance change.

This commit changes how the Keystone hardware wallet reports its firmware version when pairing with Zcash wallets. Previously it used a function that returned a display-formatted version string (with a flavor suffix). Now it formats the raw major/minor/build numbers directly. The goal is to make the pairing QR code's version string match the version bytes stamped by the PCZT signer, so wallets can use one consistent minimum-version check. There is no direct security vulnerability in the diff itself; it is a compatibility/consistency fix.

This commit fixes how Keystone 3 hardware wallets parse Avalanche (AVAX) transactions. Previously, the code only handled a single derivation path and a single sender address. The update supports multiple input addresses/paths, correctly matches displayed 'from' addresses to their derivation paths, and fixes a UI layout and memory cleanup issue. The main security risk is that a malformed or multi-input AVAX transaction could have been displayed misleadingly, potentially tricking a user into approving a transaction they did not intend to sign.

This commit is a routine regeneration of font glyph data for the device's user interface. It removes a few unused Chinese characters from the symbol lists and updates the corresponding bitmap tables and translation data. There is no indication of any security fix or vulnerability being addressed.

This is a one-line type-name correction in the Avalanche (AVAX) transaction display code. The developer changed a variable declaration from a TON (Telegram Open Network) transaction result type to the correct AVAX transaction result type. It appears to fix only a compiler warning and has no visible functional effect, because the underlying pointer types are likely identical in memory layout.

This commit fixes a merge conflict in a firmware file for the Keystone 3 hardware wallet. The change adds a missing memory cleanup function (FreeTrxMemory) and restores a missing user-interface entry for TRX swap transactions. Without the cleanup function, memory used during transaction review might not be released, which could contribute to memory leaks or instability over time. The missing UI entry could have caused the TRX swap screen to be absent or misaligned. There is no direct evidence in the commit of an exploitable security vulnerability such as theft of funds or bypass of confirmation.

This commit adds a new 'expiration' field to a Tron transaction data structure used inside the Keystone hardware wallet firmware. The change only initializes the field to an empty string in a few places and does not, by itself, appear to fix or introduce any security vulnerability. It looks like a routine data-structure update to support an expiration value that may be shown or used elsewhere.

This commit changes how a Keystone hardware wallet displays the destination asset for TRON (TRX) swap transactions. It adds a mapping from short/raw asset codes (like 'b' for BTC, 'e' for ETH) to human-readable names, normalizes case, strips suffixes, and handles chain/asset separators. The change is a UI/display fix for swap transaction memos, not a core cryptographic or signing change. There is no explicit security claim in the commit or supplied references.

This commit only reformats existing source code. It changes line breaks and indentation in a single Rust file so that a long expression and an if-statement are split across multiple lines. No logic, behavior, or security checks were changed.

This tiny code-quality patch addresses two minor issues found during a pull-request review: one removes an unnecessary `.clone()` call in Tron transaction handling, and the other adds a missing memory-field cleanup for a new Ethereum/Swapkit display field. Neither change is clearly a security fix, but the missing `free_str_ptr!(self.raw_value)` could in theory leave a small amount of heap memory unreleased when a struct is destroyed.

This commit moves a memory-freeing operation from one cryptocurrency display structure (Ethereum Swapkit) to another (Tron). It appears to fix a code review finding about a string pointer being freed in the wrong place, which could otherwise lead to a use-after-free or double-free memory bug. The actual security impact depends on whether the affected field is heap-allocated and how the structures are used after freeing.

This commit adds a new on-screen display for Tron cryptocurrency swaps that use a memo starting with '=:' (called 'SwapKit' style). It shows the user extra details such as the destination asset, destination address, raw amount, memo, and expiration time before signing. The change is mostly a UI feature, but it also parses and displays user-controlled memo text, which could be abused to mislead the user if the memo contains crafted text. There is no evidence in the commit that this is a security fix or that the vendor called it a vulnerability.

This commit only adds a new test assertion to existing Rust test code. It checks that the transaction memo matches the raw_data.data field in a Tron transaction test. There is no change to production code, no bug fix, and no security-relevant behavior change.

This commit only reformats a single Rust test file by splitting a long assert_eq! line into multiple lines. It does not change any executable code, logic, or security behavior.

This commit adds a new test case for parsing TRON swap transactions that include a memo field. It does not change any production code; it only verifies that an existing parser can correctly extract a memo from a specific transaction payload. There is no indication of a security fix or vulnerability.