Trezor firmware

This commit adds a new security permission called framebuffer_access that controls whether a small helper app (applet) running on the Trezor can read from or write to the device's screen memory. Previously, applets could access the framebuffer based only on memory location checks. Now they must also be explicitly granted the framebuffer_access privilege. The change is a hardening/feature addition, not a fix for an active exploit, and it removes an older privilege called assets_area_access that was apparently unused or being replaced.

This commit is a small internal code cleanup in the Trezor firmware's Rust UI layer. It changes how a layout object hands back its result to caller code: instead of returning a copy of the result, it now 'takes' the result away so the same value cannot be retrieved twice. The change was needed because the error type no longer supports being copied (Clone). There is no direct evidence in the commit that this fixes an exploitable security bug; it appears to be a refactoring to keep the code compiling and to make the API behavior clearer (subsequent calls return None).

This commit is a routine internal code cleanup in the Trezor firmware's Rust/MicroPython bridge. It introduces a dedicated tuple helper module so developers can write tuple conversions more naturally, and removes an older, less ergonomic helper. There is no indication it fixes a security bug or changes security-relevant behavior.

This commit adds build-time safety checks to prevent future Trezor firmware versions from accidentally setting anti-rollback version numbers too high for the hardware storage to handle. If a version were set above the storage limit, the device could either wrongly refuse to boot a valid update, or silently stop enforcing downgrade protection. The fix prevents that mistake at compile time, before any device is shipped. It does not fix an active bug today because all current models are well below the limit.

This commit changes a Trezor factory-testing tool (prodtest) so that PINs sent during NFC backup authentication and PIN setup are padded to a fixed length and encrypted with the Noise XXpsk3 protocol before being transmitted. Previously, the raw PIN was placed directly into the NFC APDU command. The change reduces the risk that someone sniffing NFC traffic could learn the PIN length or the PIN itself in plaintext. It is a defensive hardening improvement in a manufacturing/debug utility, not a fix for an active exploit in end-user firmware.

This commit adds several missing safety checks in low-level hardware code for the Trezor hardware wallet. It prevents reading past the end of a too-short firmware image, avoids odd behavior when asked to read or write zero SD card blocks, ensures a signature buffer is large enough before use, and fixes a debug-message routine that could truncate or mishandle strings. These are defensive fixes; the commit message does not call them security fixes, but missing length checks in embedded code can sometimes be exploited to crash the device or leak nearby memory.

This commit changes the Trezor Python library's collective signing (CoSi) helper so that, by default, it generates random nonces instead of deriving them deterministically from the private key and message. The old deterministic mode is kept only for publicly known development keys, because using it with real secret keys is dangerous: a malicious coordinator could trick the same key into signing the same message twice with different combined nonces, which would leak the private key. The patch itself is a security improvement, not an exploit, but it fixes a latent vulnerability in the library's API design.

This commit refactors how Trezor firmware recognizes external 'definitions' files (the data blobs that describe Ethereum networks and tokens). It splits the old 5-byte header 'trzd1' into a 4-byte magic 'trzd' plus a 1-byte version number. The change is framed by the authors as a necessary preparation for a future signature-quorum change, not as a fix for an active vulnerability. No currently reachable security flaw is present in the diff; the code still only accepts version '1', which keeps the existing 2-of-3 signature requirement.

This commit adds user-interface support for Tron smart-contract transactions that also move native TRX coins. Previously, the device screen did not show the native TRX amount when a smart contract was involved. Now it can display that amount so the user sees what they are really sending. The change is mostly UI wiring and test data; it does not appear to alter transaction validation or signing logic.

This commit is a small user-experience fix, not a security patch. Firefox's U2F support sends a special dummy registration request to check whether a security key is present. Trezor previously recognized two such dummy IDs, but Firefox's newer authenticator code uses a third one ('make.me.blink'). Without this change, Trezor would prompt the user to register the device, which is confusing. The fix makes Trezor show a simple 'not registered / already registered' message instead. It does not fix a vulnerability that lets an attacker steal funds or bypass protection.

This is a simple code cleanup: the developer removed a local alias named NOISE_TAG_SIZE_BYTES and replaced every use of it with the existing official constant NOISE_XXPSK3_TAG_SIZE. The numeric value and behavior of the code are unchanged, so there is no security impact.

This commit hardens the Noise protocol code used in Trezor firmware by adding size limits and nonce limits to prevent two cryptographic problems: encrypting or decrypting messages that are too large for the protocol, and reusing the same encryption nonce after the counter wraps around. Reusing a nonce with AES-GCM can destroy the confidentiality of messages and allow attackers to forge fake messages. The patch also wipes sensitive context data more thoroughly when errors occur, reducing the chance that leftover key material could leak.

This commit improves the Stellar signing experience on Trezor hardware wallets by letting users see which network (Mainnet, Testnet, or Futurenet) a transaction is for before approving it. Previously, the network was intentionally hidden from the main confirmation flow after a redesign, which could lead someone with accounts on both mainnet and testnet to accidentally approve a mainnet transaction they only intended for testnet. The fix adds the network name to an info menu on the final review screen for both regular Stellar transactions and Soroban authorizations. It also adds support for the Stellar Futurenet network passphrase. This is a security/usability improvement rather than a remote-exploitable vulnerability.

This commit changes the on-screen display component used by one user-interface helper from a short paragraph container to a long one, raising the maximum number of info lines that can be shown from 4 to 18. The commit message explicitly calls it a 'preparatory commit' and there is no indication of a security bug or fix.

This commit fixes a display bug in Trezor hardware wallets running the 'Caesar' user interface. In certain Ripple and Stellar transaction confirmation screens, a helpful description label (for example, explaining that a shown number is a fee limit or payment amount) was accidentally left off. The fix makes sure the description appears alongside the value, so users are less likely to misread what they are approving. It is a user-interface clarity issue rather than a direct theft-of-funds vulnerability, but it could contribute to a user approving a transaction they do not fully understand.

This commit is a straightforward internal cleanup of translation key names. It changes labels like 'words__continue_anyway' to 'buttons__continue_anyway' in code that displays on-screen buttons and menu items. The actual user-facing text shown on the device is unchanged; only the internal identifier used to look up that text was renamed. There is no security-relevant change.

This commit adds a new user-interface option for the Trezor Safe 5 (Delizia) that lets certain confirmation screens use a red 'danger' hold-to-confirm style instead of the normal green one. It is purely a visual/theming change and does not alter what the device signs, what it allows, or any security policy. The large diff is mostly updated test screenshot hashes caused by the changed colors/text.

This commit removes an unused cryptography helper module from the actual Trezor firmware and keeps it only in the test suite. There is no security bug being fixed here; it is a routine cleanup to avoid shipping dead code.

This is a cleanup change that stops generating unused bootloader hash files for newer Trezor models (D002, T3T2, T3W1). These models already verify the bootloader using a different mechanism (UCB with post-quantum signatures), so the old hash files were never actually used. The commit deletes the stale files and removes their #include references. There is no security vulnerability here.

This is a tiny command-line interface (CLI) fix for the Stellar-related commands in Trezor's Python library. Two different options were accidentally using the same short flag '-n': one for '--address' and one for '--network-passphrase'. The patch changes '--network-passphrase' to use '-p' instead, matching another Stellar command. This is mainly a usability bug, not a direct security vulnerability, because users could not reliably select the intended option by short flag.

This commit moves the public keys used to verify coin/token definitions from Python code into a new Rust module. It also makes development-signed definitions accepted on non-production builds, similar to an existing feature for translations. The change is a build/configuration refactor rather than a fix for an active security flaw. Production firmware still requires production signatures; dev keys are only accepted when the `dev_keys` feature is enabled, which is intended for development builds.

This update fixes a security flaw in Trezor's older hardware wallet firmware for Ethereum staking operations. Previously, when a user tried to 'unstake' or 'claim' staked ETH, the device did not reliably block ETH from being sent along with the transaction (msg.value), even though those smart-contract functions are not supposed to accept money. It also did not strictly check that the transaction was on the correct Ethereum network (chain ID), which could have allowed a malicious or accidental transaction on one network to be replayed on another. The fix enforces zero ETH value for unstake/claim and ties each allowed contract address to its proper network.

This update tightens the rules for two Ethereum staking operations—unstake and claim—on Trezor hardware wallets. Before the fix, the device did not verify that the user was on the correct Ethereum network (chain ID) and did not block ETH from being attached to unstake/claim transactions. Because those contract functions reject incoming ETH, any ETH sent with them would normally be lost. The patch now rejects such transactions before they can be signed, preventing accidental or malicious loss of funds and cross-chain replay attacks.

This commit adds an Indonesian language translation file (id.json) to the Trezor firmware. It is a localization-only change with no executable code, no security logic, and no functional behavior changes. There is no indication this introduces any security issue.

This commit fixes a user-interface detail on Trezor hardware wallets: when displaying an Ethereum public key on the device screen, it now also shows the derivation path (the sequence of numbers that identifies which account/key the public key belongs to). Previously only the public key was shown. This is a usability and transparency improvement, not a fix for a code vulnerability that could be exploited remotely.