Trezor firmware

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 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 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 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 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 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 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 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 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 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 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 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 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.

This commit simply adds one line to the GitHub pull request template, reminding developers to add QA notes if needed. It does not change any firmware code, build scripts, or security-sensitive files.

This commit only adds a new automated test to the Trezor firmware test suite. It checks that Cardano public keys and addresses stay the same before and after a firmware upgrade that migrates internal app storage from version 2 to the current version. There is no change to the actual firmware code, wallet logic, or security behavior.

This commit only updates expected test result hashes (called 'fixtures') in a single JSON file used for automated user-interface testing. There are no changes to the actual Trezor firmware code, so this cannot introduce a security vulnerability or fix one on its own.

This commit only updates Cardano unit tests to convert text seed phrases into binary format before passing them to a cryptographic function. It does not change any production wallet code, user-facing behavior, or security-sensitive logic. There is no indication this fixes or introduces a vulnerability.

This commit changes how Trezor stores wallet backup words (mnemonics) for Cardano support. It now keeps an extra binary copy of the mnemonic in device storage, separate from the encrypted text version. The change is described as a feature, not a security fix. It does not appear to introduce an obvious remote exploit, but it does add a new storage location holding sensitive seed material and includes a debug-only option that lets invalid mnemonics be loaded without raising an error.

This commit only adds new automated unit tests for an existing payment-request verification feature in the Trezor firmware. It does not change any production code, fix a bug, or alter device behavior. There is no security vulnerability present in this change.

This commit simply fills in a previously empty placeholder with the real production public key used to verify signed payment requests. By itself, it is a routine configuration/key-installation change, not an exploitable vulnerability. The only security-relevant observation is that before this commit, payment-request signatures using this key could not have been validated, so the feature would not have worked in production.