Trezor firmware

This is a user-interface layout tweak for the Trezor hardware wallet's new 'Eckhart' design. It makes the first menu button visually overlap the screen header when there is no subtitle, and adds logic so the header is drawn on top if its buttons are being pressed. There is no security-relevant change here.

This commit adds a new feature to read pre-stored digital certificates from the Tropic secure chip inside Trezor hardware wallets. It does not change how keys are generated or signed, and it does not appear to fix a known bug or vulnerability. The new code is mostly about safely reading fixed-size data slots from the chip and exposing them to Python applications.

This commit fixes how a Trezor hardware wallet selects cryptographic pairing keys when establishing a secure session with the Tropic secure chip. Previously the code always used a single fixed key slot (likely a factory/unprivileged key). After the change, it tries to use a privileged pairing key if available, and falls back to an unprivileged key if not. It also adds a small delay to avoid a 'chip busy' error from the Tropic chip. The change is security-relevant because using the wrong pairing key could weaken the secure channel or cause it to rely on a less trusted factory key, but the commit itself does not describe an active vulnerability or attack.

This commit updates the Trezor Python library's device-authentication code to support a new hardware security chip (Tropic) in addition to the existing Optiga chip. It adds Ed25519 signature verification, new root public keys for the T3W1 device, and a check that both chips' certificate chains are issued by the same root authority. The change is a feature addition rather than a fix for a known vulnerability, but it strengthens the authentication process by making it harder for a device with a valid certificate from one root to pass authentication using a mismatched certificate from another root.

This commit updates the Trezor hardware wallet's device-authentication feature so it can optionally use a second secure chip (Tropic) in addition to the existing Optiga chip. It refactors certificate parsing into a helper and renames the proof fields from generic names to optiga_* and tropic_*. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a feature addition enabling a new hardware variant.

This is a routine code cleanup that moves Tropic chip constants (like which key slot is used for what) into a shared header file so multiple parts of the firmware can use the same definitions. It also updates the Python binding for signing to use the correct Ed25519 signature size and exposes two key-slot constants to Python. There is no security vulnerability here.

This commit swaps out two pre-built binary firmware files for the T3W1 hardware model and updates the matching cryptographic hash values in a header file. The change is described as a routine chore with no changelog entry. There is no visible source code change, no security explanation, and no disclosed vulnerability.

This commit changes the bootloader's battery-charging LED behavior. When the battery is fully charged, the charging LED effect now turns off instead of continuing to show a charging animation. It also adds a small helper function for the Unix emulator build so it can compile. There is no security issue visible in this change.

This commit fixes a user-interface labeling bug where setting up a 'wipe code' (a special code that erases the device) was incorrectly shown using the same on-screen text and flow as setting up a regular PIN. The change renames the confirmation flow, adds a flag to distinguish wipe-code setup from PIN setup, and shows wipe-code-specific cancellation text on newer Trezor layouts. It is a UI clarity fix, not a cryptographic or access-control flaw.

This small change adjusts when a Trezor device shows that a 'wipe code' is set. Previously, the device menu would display the wipe-code status if the device was initialized, regardless of whether a PIN was set. After the change, the wipe-code status is only shown when both the device is initialized and a PIN is set. This is a UI/logic hardening change: it prevents a user from being misled into thinking a wipe code is active and usable when no PIN is set, because the wipe code feature depends on the PIN entry flow to trigger.

This commit tightens the rules between a Trezor device's PIN and its 'wipe code' (a special code that erases the device). Previously, it was possible to end up in an inconsistent state: for example, you could set a wipe code even when no PIN was set, or remove the PIN while the wipe code was still active. The patch blocks both situations and shows explanatory on-screen messages. It also replaces some internal 'assert False' statements with explicit error raises, which is a defensive cleanup. The change is a hardening fix rather than a remote exploit.

This commit updates the legal/regulatory information screen shown on a Trezor hardware wallet. It adds Japan to the list of regions, includes a new Japan icon, and adds the standard FCC compliance disclaimer text. There is no security-relevant change.

This commit simply moves two small power-management files from one folder to another and updates the build scripts and import paths accordingly. The actual code behavior is unchanged. There is no security fix or vulnerability here.

This commit is a code reorganization: it moves device locking, unlocking, homescreen selection, and suspend-related logic out of apps/base.py into a new module called apps/common/lock_manager.py. It also changes how the power button triggers suspend, using a new asynchronous notification mechanism (notify_suspend) instead of immediately locking the device. There is no direct evidence in the diff that this fixes a security vulnerability; it appears to be a feature/refactoring change.

This commit is a user-interface feature change for the Trezor hardware wallet. It splits the single 'auto-lock delay' setting in the device menu into two separate entries: one for when the device is on battery/wireless charger and one for when it is connected to USB. There is no indication in the commit that this fixes a security bug or changes any security-critical behavior; it is purely a UI/UX update.

This commit fixes a small inconsistency in the Trezor hardware wallet's startup screen. When a user had not set a PIN, the device's RGB LED (colored status light) was not being configured according to the user's preference. The change makes sure the LED setting is applied in that case too. There is no direct security vulnerability here; it is a user-experience and settings-consistency fix.

This small change moves where the screen backlight fade happens in the Trezor hardware wallet's lock/suspend logic. Previously, the screen dimmed only inside the suspend function. Now it also dims earlier when the device decides it should suspend but is still waiting for a background task (like signing a transaction) to finish. The goal is to avoid leaving the screen bright while the user is waiting for a long operation before the device can lock. This is a user-experience and minor privacy improvement, not a fix for a serious security flaw.

This commit swaps in two updated binary firmware files for the Trezor T3W1 hardware wallet (a QA bootloader and a Bluetooth development binary) and updates the corresponding cryptographic hash list. The actual code inside the binaries is not shown, and there is no description of why the binaries changed. On its own, the commit does not contain any visible security bug or fix.

This commit adds a new security feature to Trezor hardware wallets that checks whether the Bluetooth chip (nRF) is running authentic, manufacturer-approved firmware before the main wallet software starts up. In production builds, if the Bluetooth chip fails this authenticity check, the device now shuts down with an error instead of continuing to boot. The change also separates the authentication code from general Bluetooth support so it can be enabled independently.

This commit adds a notification system so the Trezor device can tell the connected computer when it becomes 'unlocked' (ready to accept commands) and 'locked' (hard-locked). It also exposes a way for the device's Python code to send these notifications. There is no obvious security bug in the change itself, but the new MicroPython binding does not validate that the event number is one of the defined values, so a bug or compromised app running inside the device could pass an out-of-range value to the underlying C notification function.

This commit simply renames two on-screen menu buttons in the bootloader user interface: 'Reboot' becomes 'Restart' and 'Power off' becomes 'Turn off'. There is no change to security logic, no bug fix, and no vulnerability addressed.

This commit adds a new tutorial screen to the Trezor hardware wallet's user interface that explains how to use the device's physical power button. It is a straightforward feature addition with no security relevance.

This commit adds a new device-to-host notification feature to Trezor hardware wallets. When the device boots (either in normal firmware or bootloader mode), it can now send a small BLE notification to a connected host announcing that it has started. The change introduces a new BLE characteristic for notifications and a small kernel module to format and send the message. There is no direct evidence in the commit that this fixes a security bug; it appears to be a feature addition. However, the new code path involves copying untrusted-length data into a fixed-size buffer and allocating/freeing memory in an embedded BLE stack, which are places where future bugs could hide.

This commit changes the Trezor firmware's embedded MicroPython configuration so that detailed error tracebacks are no longer stored in optimized (PYOPT=1) builds. The stated goal is to avoid allocating traceback data in release builds, which can save memory and reduce information exposure if an error occurs. There is no direct evidence in the commit that this fixes an active security vulnerability, but it is a defensive hardening measure.

This bootloader patch makes the device explicitly turn off its Bluetooth Low Energy (BLE) radio when the hardware receives a power-off command. Without this fix, the BLE chip might stay on during shutdown, which could waste battery, cause unexpected radio behavior, or keep the device discoverable longer than intended. The change is defensive and improves shutdown hygiene rather than fixing an obvious remote attack.