Trezor firmware

This commit moves a small 16-byte 'lock slot' region from the middle of a storage sector to the very end of that sector in the T3W1 hardware model's secret memory layout. The change is a single offset value. It is likely a defensive hardening measure to prevent the lock slot from being accidentally overwritten by other data placed earlier in the same sector, but the commit message gives no explicit security rationale.

This commit adds a new factory-testing command, tropic-keyfido-read, to the Trezor device's production-test firmware. The command lets an authorized tester read out the FIDO attestation public key stored on the Tropic secure chip. It is a read-only diagnostic feature and does not, by itself, expose private keys or change device state. The main security consideration is that it adds another surface in the already-privileged prodtest environment, but it appears consistent with existing read commands and uses the same masking/unmasking pattern.

This commit refactors how debug output is handled in Trezor firmware. It replaces direct USB virtual-serial and SWO debug output with a new 'debugging console' abstraction, adds optional read support, and exposes it to less-privileged application code through system calls. The change is described by the vendor as a refactor with no changelog entry. It does not by itself create a known exploit, but it widens the attack surface by making a debug channel readable and writable from user-space firmware, which could matter if the feature is enabled in production or combined with other bugs.

This commit adds a new build-time option called DBG_CONSOLE that lets developers choose how debug messages are output during firmware builds. It is a build-system change only—no actual device code is modified. By default it is empty/off, and in some non-production debug builds it automatically falls back to using the existing USB virtual COM port (VCP) for debug output. There is no direct security vulnerability in this change, but it makes debug-console support a configurable feature across bootloader, firmware, kernel, and other components.

This commit is a straightforward code reorganization: it moves the Segger SystemView debugging subsystem from one directory to another inside the Trezor firmware source tree. It does not change any security-sensitive behavior, fix a bug, or alter how the device protects secrets. The feature remains disabled by default and is only useful when a developer attaches a debugger.

This is a large internal refactoring of the Trezor firmware's USB driver layer. It replaces direct USB class-specific read/write APIs (for HID, VCP, and WebUSB) with a unified 'system handle' API, centralizes USB interface setup in a new configuration module, and adjusts memory layout for one model. The commit is tagged as a refactor with no changelog and makes no direct claim of fixing a security bug. While the change touches security-relevant code paths (USB communication between the device and host), the diff itself shows a restructuring rather than a clear vulnerability fix or introduction.

This commit fixes a Bluetooth pairing behavior in Trezor hardware wallets. Previously, if the device was left in 'pairing mode' (which advertises to and accepts new devices), a connection from an already-bonded/trusted device could keep it stuck in pairing mode instead of exiting it. The fix detects bonded connections and ends pairing mode when one connects. Staying in pairing mode longer than intended could let a nearby attacker pair with or interact with the device while the user thinks it is only reconnecting to a known device.

This commit adds a new read-only function that lets the device's MicroPython code ask the Bluetooth chip for the list of currently paired/bonded devices. It only exposes information that was already stored inside the device; it does not change pairings, bypass authentication, or alter any security behavior. By itself, this is a feature addition with very low security risk.

This is a minor code cleanup in the Trezor firmware's Bluetooth module. A developer moved a small chunk of repeated code—creating an empty Bluetooth address—into a reusable helper method. The behavior of the program is unchanged; it is purely a refactoring for readability and maintainability.

This commit swaps in new pre-built binary files for the T3W1 hardware model's bootloader and Bluetooth firmware, plus updates the matching hash table. The actual code inside those binaries is not shown, so we cannot tell from this diff alone whether the change fixes a bug, adds a feature, or is purely routine. There is no mention of security in the commit message.

This commit disables a request that tells nearby Bluetooth Low Energy devices to use a faster 2 Mbps radio mode ('2M PHY') right after a connection is established. The change is presented as a fix for Nordic hardware, but the commit message gives no security explanation. It may be a stability or compatibility workaround rather than a security patch.

This commit adds a new 'battery state of charge' (SoC) field to the device's Features message, which is the information a Trezor reports about itself when asked. It is a straightforward feature addition: the bootloader now reads the battery level from the power manager and includes it in the device description sent to connected computers and phones. There is no indication this change fixes or introduces a security vulnerability.

This commit is a routine build-system change for the Trezor hardware wallet firmware. It prepares the build scripts to include either a development or production Bluetooth (nRF) chip binary depending on whether a development bootloader is being used. No security vulnerability is visible in the code change itself.

This is a routine dependency update for the Nordic chip bootloader component (MCUboot) used in Trezor hardware wallets. The commit only changes one line: it points the build system to a newer commit hash of Trezor's fork of MCUboot. There is no description of any security issue, bug fix, or functional change in the commit message or diff. Without additional information about what changed between the two MCUboot revisions, this single-line manifest update by itself does not demonstrate any security problem.

This commit tidies up debug-related settings in the Nordic chip configuration files for a Trezor hardware wallet variant. It removes Segger RTT debug output and the UART console from the main board default configuration, while explicitly adding a console setting to several dedicated debug-only configuration files. The change appears to be a cleanup to keep debug features out of production board defaults and ensure debug builds still enable the console. There is no direct evidence in the commit that this fixes an active security vulnerability.

This commit adds a numeric model identifier for a specific Trezor hardware board (the T3W1 revision A with Nordic nRF52832 chip) into the firmware signing process as a protected custom TLV field. It is a feature addition that embeds device-model metadata into signed firmware images. There is no indication in the commit that it fixes a security bug or introduces a vulnerability.

This commit widens the preferred Bluetooth Low Energy connection interval range on Trezor's Nordic BLE firmware so that Apple/macOS devices will accept the request instead of ignoring it. It is a compatibility/bug fix rather than a security patch. There is no direct evidence in the commit or supplied references that this change addresses a security vulnerability.

This commit only updates the setup instructions in a README file. It tells users to initialize Git submodules before installing the trezorctl command-line tool. There is no code change and no security issue.

This commit fixes a user-interface timing issue in the Trezor bootloader. Previously, the firmware-installation progress bar could start moving before the user had actually confirmed the update on the device screen. The change makes the progress bar wait until the user explicitly confirms, so the on-screen feedback matches the real installation state. There is no direct evidence this is a security vulnerability, but it removes a small window where UI state could be misleading during a firmware update.

This commit is a routine version bump from 2.9.1 to 2.9.2 for the Trezor firmware. It only changes version numbers in one header file and in translation metadata, plus updates the signed translation package timestamp and hash. There are no code behavior changes, no bug fixes, and no security-related changes visible in the diff.

This commit tweaks how quickly a menu scrolls when the user swipes the touchscreen on a Trezor hardware wallet model, and adds a request to redraw the screen during scrolling. It is a user-interface polish change with no apparent security relevance.

This commit adds four pre-signed binary files called 'vendor headers' for a new Trezor hardware model (T3W1). These files are part of the device's firmware build and boot trust chain, but the commit itself only adds already-signed binaries. There is no code change, no evidence of a vulnerability, and no indication these files are malicious or improperly signed.

This commit removes placeholder/mock Bluetooth device names from the Trezor hardware wallet's on-device menu and makes the 'currently connected' indicator reflect the real Bluetooth state. It is a cleanup of fake test data, not a security fix in the usual sense, though leaving mock data in production could mislead users about which devices are paired.

This commit simply lowers the default screen brightness for the T3W1 hardware model of the Trezor hardware wallet from 150 to 85. It is a product tuning change, not a security fix or vulnerability. The change affects bootloader, production test, and UI theme code, and updates expected test screenshots (UI fixtures) accordingly.

This commit tunes the Bluetooth Low Energy settings on Trezor's Nordic BLE firmware. It asks for a faster connection interval, switches to the 2 Mbps physical layer, and adds suspend/resume functions that slow the connection when the device is idle. There is no direct security bug visible in the diff, but changing connection parameters can affect power, stability, and the attack surface for Bluetooth side-channel or denial-of-service attacks.