Trezor firmware

This commit removes Japan from a device menu screen that displays regulatory certification information. It is a routine product compliance change, not a security fix. There are no code changes that affect cryptography, authentication, or how the device protects funds or data.

This is a trivial code cleanup: a single unused import was removed from a Rust source file. It has no functional or security effect on the Trezor firmware.

This commit adds and updates automated user-interface tests for the PIN and wipe-code menus on the Trezor Safe 7 (Eckhart) hardware wallet. It also renames some Spanish translation strings for consistency. There is no change to the firmware's security logic, cryptography, or device behavior—only test code and translations are modified.

This commit fixes a bug where wiping a Trezor wallet did not reset all device settings. Previously, settings like haptic feedback, RGB LED, Bluetooth, and experimental features could remain enabled or disabled based on the old wallet's preferences instead of being reloaded from storage after a wipe. The fix makes sure these settings are reloaded when the wallet is reset, so the device behaves consistently with a fresh state.

This commit is a visual polish fix for the Trezor hardware wallet's newer 'Eckhart' screen layout. It changes how the entered PIN is displayed so the digits are centered and spaced out nicely. There is no security-relevant change here—only the on-screen appearance is adjusted, and the corresponding test snapshots are updated.

This commit is a simple rename of an internal function from stretch_pin() to mcu_pin_stretch(). No behavior, logic, or security properties of the code changed. It is a routine code cleanup to make the function's purpose clearer.

This commit is a straightforward code cleanup: it replaces several places that manually built an 8-byte zero-padded counter value with a single helper function called optiga_reset_counter(). The behavior is unchanged, and there is no indication of a security bug being fixed.

This change refactors how the Trezor hardware wallet tracks and clears temporary 'auto-state' sessions with the Optiga secure chip. Previously, the code manually cleared specific auto-states one by one. Now it keeps a list of all active auto-states and clears them all at once. The main security-relevant improvement is that the list is updated before sending the command to the chip, so if a communication error happens while receiving the response, the state is still recorded and can be cleaned up later. This reduces the risk of leaking or exhausting limited secure-chip session slots.

This commit only updates SHA-256 hashes in a test fixtures file (tests/ui_tests/fixtures.json). These hashes are used by automated UI tests to verify that screen outputs match expected snapshots. No firmware code, cryptographic logic, or user-facing behavior was changed. There is no security relevance in the diff itself.

This commit rewrites how the Trezor hardware wallet stores and verifies PINs when the Optiga secure chip is present. It replaces a single 'stretched PIN' slot with a chain of up to 10 slots (currently configured to 1, so behavior is unchanged for users). The goal is to make future brute-force and side-channel attacks against the PIN harder by adding more authorization steps and by separating the HMAC counter reset key from the main unlock path. Because the new code is complex and touches the PIN verification flow, any bug here could affect device security, but the commit itself is a defensive hardening feature rather than a fix for a known vulnerability.

This commit adds a build flag that disables a feature called 'tropic' in the legacy Trezor firmware build. On its own, the change is a straightforward build configuration tweak with no visible security bug fix. It may be a defensive hardening step or simply removing an unused feature, but the commit message gives no security context.

This commit adds support for using a second hardware security chip called Tropic to protect the device PIN, alongside the existing Optiga chip. It is a feature addition that strengthens PIN protection by adding another physical barrier against brute-force and chip-level attacks. There is no direct evidence in the commit that it fixes an existing security flaw; it appears to be a defensive hardening change.

This commit refactors how a Trezor hardware wallet establishes a secure communication channel with an optional Tropic cryptographic chip. It removes a 'PRODUCTION-only hotfix' that had been mixing Tropic-sourced randomness into the device's random number generator. It also restructures the pairing-key selection logic so the code tries privileged, then unprivileged, then factory keys in a clearer sequence. The change is described as a feature/refactor with no changelog, not as a security fix. There is no direct evidence in the diff of an exploitable vulnerability, but removing a hotfix and changing secure-channel initialization are security-adjacent changes that warrant review.

This commit changes how the Trezor hardware wallet generates random numbers used to protect PINs, wipe codes, and encrypted storage. It replaces direct calls to a basic random function with a stronger random-number wrapper for sensitive operations, and adds a weaker wrapper for less critical uses. The change suggests the developers want to enforce a stricter random source for security-critical material, but the commit itself does not explain whether the old function was actually weak or exploitable.

This commit changes how many times a device 'stretches' (repeats and strengthens) the user's PIN before checking it. On T3W1 devices, when a build-time flag called STRETCHED_PIN_COUNT is greater than 1, the code now reduces both Optiga hardware stretching and software PBKDF2 stretching to a single iteration. The stated goal is to make PIN verification faster. Reducing stretching weakens the protection against brute-force attacks if an attacker obtains the stored secrets, but the change is conditional on a build flag and does not by itself create a direct remote exploit. It is a security-relevant hardening reduction rather than an obvious vulnerability.

This commit fixes a bug in a low-level Trezor firmware function that writes data from the device. Previously, when a timeout was requested, the code only waited for the channel to become ready but then tried to write all data at once, ignoring that the hardware might only accept a portion. The fix loops, writing in chunks and waiting again until all data is sent or the timeout expires. This is a reliability/robustness fix that could prevent incomplete or failed writes in communication with the host.

This commit fixes a minor reliability issue in Trezor's production-test firmware (a factory diagnostic tool, not the main wallet firmware). The change adjusts how long the device waits when sending text over a USB virtual serial port, so it doesn't get stuck if no computer is listening. There is no direct evidence this is a security vulnerability or that it affects end-user devices.

This commit rewrites the USB virtual serial port (VCP) ring buffer code in Trezor's firmware. The old code tracked buffer space using simple read/write counters, which could become inconsistent when the USB data-out interrupt and the application read data at the same time. The new code uses a dedicated ring-buffer module that protects its state with interrupt locks and tracks how many bytes are actually used. It also stops requesting new USB packets when the buffer is nearly full, preventing overflow and lost data. The change is a hardening/bug-fix patch; the commit message does not call it a security fix, but race conditions in USB buffering can affect device reliability and, in the worst case, be abused to cause information leakage or denial of service.

This commit adds an optional text argument to the Trezor production-test firmware's 'ping' command. Previously, 'ping' always replied with just 'OK'. Now, if you type 'ping ABC', the device replies 'OK ABC'. It is a small feature change in a diagnostic/testing tool, not a security fix or vulnerability.

This commit changes how the Trezor hardware wallet displays and clears its PIN-entry keyboard during the boot screen. The title says it 'clears PIN keyboard in bootscreen,' suggesting the previous code may have left PIN-keyboard graphics or state visible when the device went to sleep or resumed. The patch adds a notification channel so the boot screen can be told when a suspend is happening, and it re-creates the lockscreen after suspend instead of continuing straight to PIN entry. There is no direct evidence in the diff of a security vulnerability such as PIN leakage, but a leftover PIN keyboard on screen could theoretically expose partial PIN-entry state or confuse the user interface.

This patch fixes a UI state issue in Trezor hardware wallets. If the device auto-locks while the user is in the middle of typing their PIN, the on-screen PIN keyboard could remain visible even though the device is now locked. The fix detects this situation and clears/restarts the workflow so the keyboard doesn't linger. It is primarily a user-interface consistency bug, but leaving an active PIN entry screen on a locked device could confuse users or create a minor information-leak signal (that a PIN was being entered).

This commit simply deletes an unused internal variable named _SCREENSAVER_IS_ON. There is no functional code change, no bug fix, and no security relevance.

This is a user-interface styling change for the Trezor hardware wallet's action bar. It adjusts how pagination buttons are sized and positioned on the new 'Eckhart' device layout, and updates the corresponding visual test snapshots. There is no indication this affects security, cryptography, or how transactions are approved.

This commit fixes a small coding mistake in the Trezor hardware wallet's startup code. The device was always trying to reset a power-management timer, even on models that don't have that feature. The fix adds a check so the reset only happens on models that actually support it. This is a defensive bug fix; the diff alone does not show a clear security vulnerability, but it could prevent a crash or unexpected behavior during boot on some device models.

This commit adds a user-facing Bluetooth on/off toggle in the device menu for the Trezor Safe 7 (T3W1). It stores the user's preference and only starts Bluetooth at boot if it was previously enabled. There is no direct evidence of a security vulnerability in the change, but it touches Bluetooth state management and storage, which are security-relevant areas.