AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 35 Bitcoin

feat(core): implementation of nRF FW version readout via SMP commands for realiability increase e.g. for cases when the nRF FW application is broken from whatever reason and can't reply to Trezor's FW version check for possible nRF FW update. The alternative way of FW version readout uses the MCUboo

Public commit record

What the developer wrote

Authored by bleska

95/100 · Strong
feat(core): implementation of nRF FW version readout via SMP commands for realiability increase e.g. for cases when the nRF FW application is broken from whatever reason and can't reply to Trezor's FW version check for possible nRF FW update.
The alternative way of FW version readout uses the MCUboot SMP serial recovery feature which had already been enabled and used for nRF FW update in the field mainly. The version is returned as a structure of 4 uint fields representing major, minor, revision and build_num respectively (string received from nRF IC is decoded).
The development releases of nRF FW are to be built with: "./scripts/build_sign_flash.sh -b t3w1_revA_nrf52832/nrf52832 -c -d -s -f" command. '-d' is essential, with '-p' the build script generates and signs the image in a way that MCUboot can't verify that (it uses debug keys see hash_signer.py but the MCUboot expects the production key which has embedded inside "image_validate.c" file).

[no changelog]
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit adds a backup way for the Trezor device to check the version of the wireless nRF chip's firmware. If the normal app-to-app communication fails, the device can now ask the nRF chip's bootloader directly over a different channel. This is meant to make firmware update decisions more reliable, not to fix a known security bug. The change does not appear to introduce an obvious vulnerability, but it does add parsing of data received from the nRF chip and changes how the device decides whether to force an update.

Recommended action

Review the new CBOR parser for robustness against malformed or adversarial SMP responses, ensure all error paths release the SMP receiver, and verify that the version-comparison fallback cannot be abused to suppress or trigger an unwanted nRF firmware update. Treat this as a reliability/feature change rather than an urgent security patch unless further context emerges.

Security signals we found

01

New CBOR parser added for untrusted SMP response data

02

Parsing of version string from external nRF device influences update decision

03

SMP fallback path reboots nRF into bootloader and back during version check

04

Error path in `get_version_numbers()` releases receiver on send failure but not on response timeout

05

Force-update fallback remains after three failed attempts

Risk score

Why this scored 35/100

Our methodology →
Potential impact 8/30
Exploitability 7/25
Stealth signal 5/15
Affected reach 6/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.