Trezor firmware

This commit is a straightforward code reorganization: it moves the emulator's profile-handling code from one directory to another and updates the build files and include paths accordingly. There is no change to what the code does, no bug fix, and no security-related change.

This commit is a cleanup of how the word 'const' is used in the Trezor firmware's ed25519 cryptographic code. Previously, the code defined a custom 'CONST' macro that meant 'const' on newer compilers and nothing on older GCC versions. The commit removes that macro and uses plain 'const' everywhere. It also adjusts a Rust build script comment and compiler flag. There is no indication in the commit that this fixes a security vulnerability or changes runtime behavior.

This commit is a code cleanup in Trezor's Ethereum transaction handling. It replaces a hand-rolled method of reading Ethereum vault transaction data with a shared, more structured parsing system called DisplayFormat. There is no indication this fixes a security bug; it appears to be a refactoring change with no functional security relevance stated by the vendor.

This commit updates the Trezor firmware build system and emulator code to use SDL3 instead of the older SDL2 library. It is a routine dependency migration affecting only emulator builds (software simulations of the hardware wallet), not the real device firmware. The changes rename functions and constants to match SDL3's API, adjust build scripts, and add a couple of small safety checks. There is no indication this fixes a known security vulnerability.

This commit refactors a build script for Nordic hardware so that several hard-coded numbers (memory addresses, slot size, device model tag) are instead read from the project's generated device tree and configuration files. There is no change to runtime code, no new user-facing behavior, and no indication of a security fix or vulnerability.

This commit is a routine cleanup of the Nordic board configuration and Bluetooth Low Energy firmware for a Trezor hardware wallet. It removes the generic Nordic 'DK buttons and LEDs' driver and replaces it with direct GPIO (general-purpose input/output) definitions tied to the actual Trezor board pins. It also fixes a typo in the board name and renames some device-tree labels for clarity. There is no security-relevant change visible in the diff.

This is a build-system refactor for Trezor's Nordic Bluetooth chip firmware. It removes manually maintained flash partition files and switches to Zephyr's standard device-tree partition definitions. The change also fixes a build-time signing script bug where a duplicate image header could be inserted, which would cause the device to crash immediately on boot. There is no direct evidence this is a security vulnerability patch, but it prevents a real boot failure in the manufacturing/development workflow.

This commit fixes a logic error in the build scripts that decide whether to use development or production signing keys when preparing Trezor firmware images. Before the fix, the condition was accidentally inverted, so production builds may have used development keys and development builds may have used production keys. Using the wrong keys could make firmware signatures invalid or cause devices to reject genuine firmware, but the commit itself does not show an exploitable runtime vulnerability in shipped code.

This patch fixes several integer-handling bugs in the Trezor bootloader's USB message decoder. The changes prevent small or maliciously crafted message sizes from causing arithmetic overflows or underflows when the device calculates how many USB packets to read. Such flaws could potentially let an attacker confuse the bootloader into reading memory out of bounds or behaving unpredictably during a firmware update.

This commit fixes an out-of-bounds memory read bug in the Trezor bootloader's firmware header parser. The read_vendor_header function previously trusted size values inside a firmware file without first checking whether those sizes fit within the actual data buffer. A malformed firmware update or a corrupted on-device firmware image could have caused the bootloader to read memory beyond the allowed region. The patch adds size checks so the parser rejects too-small or oversized headers before using their contents.

This commit renames and restructures how Trezor firmware selects cryptographic signing keys for bootloaders. Previously, non-production builds automatically used weaker development/QA keys. Now, a dedicated BOOTLOADER_DEVEL flag controls that, while a separate FORCE_BOOTLOADER_UPGRADE flag controls whether the firmware should forcibly update the bootloader. The change also prevents combining PRODUCTION=1 with BOOTLOADER_DEVEL=1. This is primarily a build-hardening and internal workflow cleanup; it does not by itself fix a remotely exploitable bug in shipped devices.

This commit fixes a bug in the Trezor hardware wallet's NFC driver where calling the NFC shutdown function more than once could crash the device. The fix adds a simple check to skip re-deinitializing the SPI hardware if it has already been shut down. It is a defensive hardening fix rather than a clear exploitable vulnerability.

This commit adds a new backup and recovery method called N4W1 to Trezor firmware. It is a feature addition that lets users back up and restore their wallet seed using a near-field wireless tag instead of typing words on the device screen. The change is mostly about adding new code paths and tests; it does not appear to fix a known security bug, nor does the vendor describe it as a security patch.

This commit is a simple code cleanup in the Ethereum clear-signing module. It pulls out a repeated snippet of code that reads variable-length data into a new helper function, then replaces two copies of that snippet with calls to the helper. No behavior changes are visible in the diff.

This commit fixes an off-by-one-style bounds check in the Ethereum clear-signing code on Trezor hardware wallets. The old check only verified that the starting position was inside the data, but did not verify that the code was about to read 32 bytes from that position. As a result, a malformed Ethereum transaction or message could trick the device into reading past the end of a buffer while decoding human-readable fields. The fix now checks that offset plus 32 bytes does not exceed the data length before reading.

This commit adds a length check to a function that parses arrays of 256-bit unsigned integers in Ethereum transaction data. Previously, if the raw data was not a multiple of 32 bytes, the function would silently ignore leftover bytes at the end. The fix now raises an error instead. This could matter for 'clear signing' displays on a Trezor hardware wallet, where malformed data might otherwise be shown or processed in a misleading way. The commit message does not describe this as a security fix, and no exploit is demonstrated.

This commit tightens validation in Trezor's Ethereum 'clear signing' feature. It now rejects cases where a host computer tells the device to parse a variable-length type (like a string or byte blob) as if it were a fixed 32-byte value, or vice versa. This reduces the chance that a malicious or buggy host could trick the device into misreading transaction data, but the commit itself does not claim to fix a specific known attack.

This commit replaces runtime computation of two Ethereum function signatures with hard-coded byte values, then adds debug-only assertions to verify those values still match the original computation. It is a minor code cleanup with no apparent security impact. The change does not alter what the device signs, displays, or accepts.

This commit adds a safety check to a function that verifies unused data is zeroed. Before the change, if a caller passed an invalid 'used_bytes' value (for example, a negative number or one larger than 32), the function could read memory outside the intended 32-byte window or behave unexpectedly. The patch now rejects such invalid values immediately. The commit message calls it a routine cleanup ('chore') and does not claim it fixes a security vulnerability.

This commit replaces several 'assert' checks in the Ethereum 'clear signing' code with proper error handling. In production firmware, asserts can be stripped out or behave differently than expected, so replacing them with explicit error raises makes the code more robust against malformed or malicious transaction data. The change is defensive hardening rather than a clear fix for an active exploit.

This commit adds support for a new 'To' container path in Trezor's Ethereum clear-signing feature. It lets the device reference the transaction recipient when formatting token amounts, which is useful for displaying ERC-20 transfers and approvals correctly. The change is a feature addition, not a clear security fix, and there is no evidence of a disclosed vulnerability.

This commit adds a new feature to Trezor's Ethereum signing flow: the device can now ask the host computer mid-transaction for extra token or display-format definitions. The main production code change is small and appears to fix a token-resolution bug in clear signing by preferring a token returned from the parsed field data over the one looked up from the static definitions. Most of the diff is new and updated test code exercising the new request/response mechanism and renaming helpers from 'erc7730' to the more generic 'display format'.

This commit adds a new feature to Trezor Ethereum signing that lets the device ask the connected computer or phone for extra token/contract display information during a transaction. It is a feature addition (not a direct bug fix), so it mainly changes how the wallet and device talk to each other. There is no clear security vulnerability visible in the diff, but any new request/response protocol introduces places where a malicious or buggy host could supply misleading data, and the device must carefully validate what it receives. The commit does not itself describe a security issue or credit a researcher.

This commit tightens a security rule in Trezor's Ethereum signing code: payment requests can now only be used with plain ERC-20 token transfers. Previously, the code may have allowed payment requests with other smart-contract calls, which could let a malicious app or service trick a user into approving a different transaction than expected while still showing a familiar payment-request screen.

This commit changes how Trezor displays Ethereum token-approval amounts that exceed a safety threshold. Previously, the code returned 'None' for such large amounts, and the user interface fell back to a generic 'Unlimited amount' warning. Now the formatter explicitly returns a special 'AboveThreshold' marker carrying the text 'Unlimited', and each device UI layout uses that marker to show the same warning and display text. The change is a user-interface refinement, not a fix for a cryptographic bug or a remote exploit. It does, however, make the 'unlimited' signal explicit rather than implicit, which slightly reduces the chance that a future UI change would accidentally treat a huge allowance as an ordinary amount.