Trezor firmware

This commit makes two changes to Trezor's firmware. First, it removes the ability of the production-test tool ('prodtest') to erase a special memory area called 'backup RAM' when the device is built for real production use. Second, it replaces a secure-monitor call that only returned battery temperature min/max values with one that returns a broader 'telemetry data' structure. The commit title frames the change as preventing production prodtest from erasing backup RAM, which suggests a hardening measure rather than a reported vulnerability fix.

This commit simply deletes two old binary files used by the T3W1 hardware model's secure monitor. The commit message says they are 'no-longer compatible' and explicitly marks '[no changelog]', meaning it is treated as a routine cleanup rather than a security fix. There is no code change, patch, or explanation of any vulnerability.

This commit tightens access control on a special memory area called 'backup RAM' in Trezor's secure core. Previously, the kernel could potentially read or write any record in backup RAM through verified system calls. Now it is restricted to only two specific records: one related to power-management recovery and one related to Bluetooth settings. This reduces the damage if malicious or buggy kernel code tries to access sensitive records it should not touch.

This commit adds a new internal telemetry feature to the Trezor firmware that records the minimum and maximum battery temperature in a small, protected memory area (backup RAM). It only stores a float value for the coldest and hottest battery readings and does not send data anywhere. There is no obvious security bug in the code, but it is a new subsystem that touches low-level firmware components and could become relevant if future changes connect it to untrusted inputs or expose it externally.

This commit only changes test code. It adjusts how randomness is reseeded during automated UI tests so that screen recordings stay consistent, and updates the expected screenshot fingerprints (hashes) accordingly. There is no change to the actual Trezor firmware or wallet security behavior.

This is a one-character style fix that adds an empty message string to a compile-time assertion. It has no effect on the device's behavior, security, or stored secrets. It simply keeps the code compatible with stricter compiler settings.

This commit adds support for signing TRON smart-contract calls (like USDT/USDD transfers) on Trezor hardware wallets. Because the device cannot yet decode the actual token-transfer details, users are shown only the smart-contract address and raw data, meaning they are 'blind signing' the transaction. The commit message explicitly calls this out. There is also a fee-limit check to cap how much TRX can be burned, and a fix changing some timestamp/expiration fields from signed to unsigned integers.

This commit adds a new on-screen prompt that asks users to confirm they really want to cancel a transaction-signing flow. It is a user-experience and safety feature, not a security fix. There is no evidence of a vulnerability being patched.

This commit adds a 'swipe down to go back' feature to the Delizia user interface on Trezor hardware wallets. When reviewing a cryptocurrency transaction, a user can now swipe down on the amount screen to return to the address screen and double-check it. It is a usability improvement, not a fix for a vulnerability.

This commit is a straightforward internal code cleanup. It introduces a new type alias called StrPropertyType for UI properties that are always text strings (never raw bytes), and replaces some str(x) conversions with x or "" to handle possible None values more cleanly. There is no indication this fixes a security bug or changes user-visible behavior.

This commit removes a dedicated two-page 'confirm output with amount' screen and replaces it with two separate confirmation prompts for the address and the amount. It is a user-interface refactor, not a fix for a security vulnerability. The change does not introduce obvious security flaws, but it slightly alters how users review transaction details on newer Trezor layouts.

This commit adds a new optional 'back button' to a Trezor screen type called confirm_value. It is a user-interface feature for the upcoming Eckhart hardware model and does not fix or introduce any security vulnerability. The change simply lets callers request a back arrow instead of a cancel cross, and wires that through the Rust UI layer for all supported device layouts.

This commit is a routine user-interface feature addition. It lets certain 'property' display screens show an optional subtitle and gives callers a way to override the page title. There is no security-relevant change in the diff.

This commit is a routine code cleanup: it pulls a repeated user-interface loop into a shared helper function called confirm_linear_flow. There is no change to security behavior, no bug fix, and no indication of a vulnerability.

This commit only updates expected test result hashes (called 'fixtures') in a single JSON file used by the Trezor firmware UI test suite. There are no code changes, no firmware changes, and no user-facing behavior changes. It is a routine maintenance update to keep automated tests passing after unrelated visual or internal changes elsewhere in the project.

This commit is a straightforward code cleanup: it bundles several settings for confirmation screens into a single ConfirmActionOptions struct instead of passing them as separate function arguments. There is no change to user-facing behavior, no bug fix, and no security-related change.

This commit is a straightforward internal code cleanup in the Trezor firmware's user-interface layer. It replaces several individual settings inside a 'ConfirmValue' screen builder with a shared 'ConfirmActionOptions' object. There is no change to user-visible behavior or to security logic; it is purely a refactor to reduce duplicated code.

This commit changes how the Trezor firmware's vibration motor (haptic) driver reports and handles errors. Previously, some haptic functions returned simple true/false success values, and some callers ignored the result of initialization. Now those functions return a structured status code, callers capture the status (though mostly still ignore it), and one resume path actually halts on failure. A test-only haptic syscall was removed. The changes are defensive cleanups rather than a fix for a known exploitable bug, but they reduce the chance that a failing haptic device could leave the system in an inconsistent state.

This is a small fix to the Trezor hardware wallet's production-line testing tool for the vibration motor (haptic feedback). It renames a variable, updates the driver initialization and playback calls to use newer error-handling types, and switches from a fixed vibration pattern to a custom 100 Hz vibration lasting the user-specified duration. There is no indication this change fixes a security vulnerability or affects end-user device security.

This commit is a routine hardware-driver refactor for the vibration motor (haptic feedback) in Trezor devices. It renames the driver, adds support for a second chip model, fixes how closed-loop vs open-loop motor control is configured, and improves error handling. There is no direct evidence in the commit that this fixes an exploitable security vulnerability; it appears to be a product-quality and maintainability improvement.

This commit only adds a new automated test for the Trezor hardware wallet. The test checks that a user can cancel a Bitcoin transaction signing flow from the amount confirmation screen on newer device models. It does not change any firmware, wallet logic, or security behavior. There is no security issue here.

This commit only adds new expected screen-image fingerprints (called 'fixtures') for automated user-interface tests. It does not change any wallet code, transaction logic, or security behavior. There is no security issue here.

This is a tiny documentation-only change. A helper function's type hint was updated from 'bool or None' to just 'bool', and the docstring line saying it could return None when no translation blob exists was removed. No actual code behavior changed, and there is no security relevance.

This commit fixes a bug in the Python Trezor library's WebUSB communication code. Previously, if a USB read operation timed out but had already received some data, that partial data was silently thrown away. Now the code checks whether any data was received before the timeout and uses it if it is a valid full chunk. This could prevent communication failures or dropped messages when talking to a Trezor device over USB, especially under timing pressure.

This commit is a large internal refactor of the Trezor bootloader's event loop, moving it from C into Rust and changing how screens handle USB/Bluetooth communication. The title and message explicitly call it a refactor with '[no changelog]', and there is no vendor statement that this fixes a security bug. The diff shows substantial code movement but no obvious new vulnerability. Because it is a wide-reaching rewrite of security-critical boot-time code, it carries ordinary implementation risk, but the available materials do not demonstrate a concrete security issue.