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

fix(emulator): initialize mono counters before running bootemu

Public commit record

What the developer wrote

Authored by cepetr

62/100 · Adequate
fix(emulator): initialize mono counters before running bootemu

[no changelog]
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope! No meaningful explanatory body
The short version

What changed, and why it matters

This commit fixes how the Trezor emulator initializes its 'monotonic counters'—security counters that only ever increase and are used to prevent downgrades to older, possibly vulnerable firmware. Before this fix, the emulator did not explicitly initialize these counters before running the boot emulator, which could lead to uninitialized or incorrect counter values during emulator-based testing. The fix adds a dedicated initialization routine and calls it in every relevant firmware component. On real hardware the initialization is currently a no-op, so this primarily affects the Unix/emulator build used for development and testing.

Recommended action

Treat as a low-to-moderate hardening fix for the emulator/test environment. Verify that `monoctr_init()` is invoked in all new entry points added in future firmware components. Review whether the STM32 no-op implementations should eventually perform real initialization to match the emulator behavior. No urgent user action is indicated for production hardware based solely on this diff.

Security signals we found

01

Adds explicit initialization of anti-rollback monotonic counters before boot emulator runs

02

Prevents use of uninitialized monotonic counter state in emulator builds

03

Touches bootloader, kernel, secmon, and boardloader entry points—core trust-boundary code

04

Real hardware implementations are no-ops, limiting direct hardware impact

05

Includes a temporary workaround OTP block mapping for SECMON counter on Unix

Risk score

Why this scored 35/100

Our methodology →
Potential impact 8/30
Exploitability 6/25
Stealth signal 5/15
Affected reach 7/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.