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

Move SmartEEPROM into HAL EEPROM

Public commit record

What the developer wrote

Authored by Niklas Dusenlund

78/100 · Adequate
Move SmartEEPROM into HAL EEPROM

Add a dedicated Eeprom trait to bitbox-hal and implement it for both the device HAL and the Rust test HAL.

Use the new trait for setup, init, disable, and unlock-attempt persistence so those responsibilities no longer sit in Memory or System.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit is a code reorganization: it moves SmartEEPROM handling (a flash-backed memory feature) out of the general Memory and System modules into a new dedicated Eeprom trait in the hardware abstraction layer. The same underlying functions are still called, and the unlock-attempt counter behavior is preserved. There is no obvious security bug introduced, but the change touches code that protects device reset and unlock-attempt limits, so it deserves careful review to confirm no behavior was accidentally dropped.

Recommended action

Review the refactor for accidental behavioral changes, especially: (1) confirm that all previous SmartEEPROM setup/init calls are still invoked at the correct boot stage on BitBox02; (2) verify that unlock-attempt increment/get/reset semantics match the prior Memory-based implementation, including any maximum-attempt enforcement; (3) ensure the new BitBox03 Eeprom implementation's saturating_add matches the intended security policy; (4) run the relevant unit and simulator tests; (5) consider whether the removed bitbox02/src/smarteeprom.rs simulator-graphical functions need replacement calls elsewhere.

Security signals we found

01

Refactor of unlock-attempt counter persistence from Memory trait to new Eeprom trait

02

Refactor of SmartEEPROM disable from System trait to new Eeprom trait

03

BitBox02 implementation still calls same unsafe C SmartEEPROM functions as before

04

BitBox03 implementation uses saturating_add for unlock attempts, replacing previous todo!() stubs

05

Testing implementation uses simple u8 counter without explicit max-bound enforcement

Risk score

Why this scored 17/100

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