Trezor firmware

This commit adds a new GitHub Actions workflow that lets maintainers manually upload English translation source files to the Crowdin translation service. It is a routine CI/infrastructure change with no apparent security relevance.

This commit moves a function call (unit_properties_init) so it runs earlier during the startup of a special factory-testing program called prodtest, instead of only when Bluetooth support is enabled. The change is in a low-level embedded file used during hardware production testing, not the normal wallet firmware users run. The commit message says it is a fix but gives no details about any security impact, and no independent security references were provided.

This commit refactors the Trezor firmware's battery fuel-gauge code so it can support multiple battery types in the future. It replaces hard-coded battery model constants with a runtime-selected structure based on a battery_type value read from device OTP memory. There is no obvious security bug in the diff, but the change introduces a new hardware-derived input (battery_type) into power-management calculations. Currently only battery type 0 is handled, and any unknown type falls back to the same default model.

This commit is a routine code cleanup that renames battery-related constants and arrays in a Trezor firmware header file to include the specific battery model name (JYHPFL333838). No values were changed, no new functionality was added, and there is no indication of any security issue being fixed.

This commit adds a way for the Trezor device to tell the connected computer or phone when its power source changes (for example, when USB is plugged in or a wireless charger is placed nearby). It also exposes two new status flags, usb_connected and wireless_connected, in the device's feature report. There is no direct security fix here; it is a feature that improves real-time status reporting.

This commit only updates expected screenshot fingerprints used in automated UI tests for the Trezor hardware wallet. No actual device code, firmware logic, or user-facing behavior was changed. It is a routine test-maintenance change with no security relevance.

This commit adds a new developer/testing tool that creates a fake Bluetooth (BlueZ) interface on a developer's computer. It lets software talk to a Trezor emulator as if the emulator were a real Bluetooth device. It is not a fix for a security issue and does not change any production firmware, wallet, or device code. It is purely a testing/development helper.

This commit is a code cleanup that moves emulator-only UDP socket handling for the Trezor hardware wallet emulator into a shared helper module. It affects only the Unix emulator build, not real Trezor devices. The change does not appear to fix or introduce a security vulnerability; it is a refactoring to reduce duplicated code between USB and BLE emulation layers.

This commit adds a software-only Bluetooth Low Energy (BLE) emulator for Trezor hardware wallets. It is a testing/development feature that lets a desktop emulator simulate BLE connections over local UDP network sockets. It does not change real hardware behavior and is not a security fix or a disclosed vulnerability. The main risk is that any emulator-only code could, in theory, contain bugs that affect testing environments, but there is no direct evidence this introduces an exploitable flaw in production devices.

This is a routine user-interface code cleanup for the Trezor hardware wallet. It changes how on-screen navigation controls (page counters and action bars) are shown, hiding them when text fits on a single page. There is no indication this fixes a security bug or introduces a security risk.

This is a small internal code cleanup in the user-interface code for the Trezor hardware wallet's newer 'Eckhart' layout. It removes a special 'pagination hint' builder flag and instead lets callers pass an ordinary page-counter hint component. The visible behavior is meant to stay the same: a page counter appears only when content spans more than one page. There is no indication this change fixes a security bug or introduces a vulnerability.

This commit only updates expected hash values in a test data file. These hashes are used by automated tests to verify that the device's on-screen prompts match recorded snapshots. No actual product code was changed, so this cannot introduce a security vulnerability or fix one in the firmware itself.

This commit is a code-quality and accuracy improvement for how the Trezor firmware estimates how long PIN operations will take. It replaces a single coarse heuristic with finer-grained per-command timing estimates for the Optiga and Tropic secure chips, adds a helper that models the chip's security-event-counter throttling, and moves the estimate logic closer to the functions it describes. There is no direct security vulnerability being fixed; the change is about making progress-bar timing more accurate, which indirectly helps user experience and may make side-channel timing analysis slightly more predictable. The commit message says '[no changelog]' and does not claim to fix a security issue.

This commit changes how Trezor devices set a lifetime PIN-attempt counter in the secure Optiga chip. Previously the counter limit was stored as an 8-bit number (max 255), which was too small for the intended 600,000 stretching operations. The patch widens the limit field to 32 bits and correctly writes the full 600,000 value into the chip. Without this change, the counter could wrap or be capped at 255, potentially allowing more PIN attempts than designed or prematurely bricking the device. The change is a hardening fix, not an obvious remote exploit.

This commit rearranges where the Trezor firmware's security monitor (a small privileged component) keeps its private stack and data. Previously, that protected memory sat in a region that was not covered by the hardware's error-correcting RAM. The change moves it into ECC-protected SRAM and splits the non-secure RAM description into two separate chunks so the memory protection tables can cover the gap correctly. It is a hardening change rather than a fix for an active, exploitable bug, but it removes a reliability/integrity risk for sensitive security-monitor data.

This commit changes how the Trezor hardware wallet's earliest startup code (boardloader and bootloader) uses internal memory on the T3B1 model. It shifts small data and uninitialized-memory sections from one RAM bank (AUX1_RAM) to another (MAIN_RAM), and slightly adjusts the size and start addresses of those RAM regions. The title says this is to 'use ECC SRAM'—memory with built-in error-correction, which is a reliability/hardening improvement, not a vulnerability fix. There is no direct evidence in the commit of a security bug being patched.

This commit removes a special firmware memory section called ".confidential" that was meant to keep sensitive data (like cryptographic keys and seed-derived values) separate from ordinary memory. Previously, variables marked with a CONFIDENTIAL attribute were placed in this dedicated RAM region and copied from flash at startup. The patch deletes that whole mechanism across all Trezor models and instead marks sensitive local variables with a new LOCAL_CONFIDENTIAL macro. On the legacy build this still maps to the old behavior, but on the modern STM32 builds it effectively becomes a no-op, meaning those sensitive buffers now live in normal RAM/data sections. The change is presented as a cleanup, but it reduces a defense-in-depth isolation feature and could make it easier for a successful attacker to locate or extract secret material in memory.

This commit is a straightforward user-interface feature: it makes the Trezor T3W1 device show a special LED lighting effect while Bluetooth Low Energy (BLE) pairing is in progress. It refactors how the firmware tracks LED state so that the renderer can request either a static color or a hardware-driven effect (pairing/charging). There is no security-relevant change visible in the diff.

This commit adjusts the screen brightness numbers used by the Trezor T3W1 hardware wallet so that the actual perceived brightness stays the same after a change in how brightness is calculated. It is a display-calibration tweak, not a security fix or vulnerability. The only user-visible effect should be that brightness levels look the same as before.

This commit is a routine hardware driver improvement. It makes the screen backlight brightness curve adjustable per display panel by passing a gamma exponent into the backlight driver. There is no security-relevant change: no memory corruption, no cryptographic code, no privilege changes, and no user data handling.

This commit changes how the Trezor hardware wallet's screen backlight brightness is calculated. It replaces a simple linear mapping with a gamma correction curve so brightness levels appear smoother to the human eye. There is no indication this change fixes a security bug or introduces a security vulnerability; it is a display-quality feature.

This commit is a simple code cleanup: it removes a duplicate definition of the Bluetooth pairing limit (BLE_MAX_BONDS) from a Python file and exposes the existing Rust constant to Python instead. There is no security issue here.

This is a minor user-interface fix. After you successfully pair a new Bluetooth device with the Trezor hardware wallet, the menu now correctly returns to the main home screen instead of staying in the pairing menu. There is no direct security vulnerability here; it is a usability polish change.

This commit is a straightforward internal code cleanup for the T3W1 hardware wallet's on-device menu. It changes how menu choices are represented behind the scenes (from unique object tokens to plain integer codes) and reorganizes the Python handler code into smaller functions. There is no indication this fixes a security bug or introduces a new vulnerability.

This commit fixes a touch-screen driver bug in Trezor hardware wallets where a finger lift (TOUCH_END event) could be lost. The symptom was 'stuck hold-to-confirm buttons' on some models. In practice, a missing release event could make the device think a finger was still held on the screen, potentially causing an unintended confirmation action or leaving the UI in a confused state. The patch is small and defensive, adding a state-machine correction rather than changing large amounts of code.