Connected ESP-32 device masquerades as a Jade in Sparrow / wallet software
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 25/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- c
- Domain
- embedded-iot, security
Research direction
Review the Jade API and the device-identification path that relies on USB vendor and product IDs. Check how normal ESP-32 devices and DIY Jades can be distinguished without breaking existing Jade detection, then define tests or device responses that demonstrate ordinary ESP-32 hardware is no longer treated as a Jade.
Written by the indexing model from the issue text.
Description
From https://github.com/sparrowwallet/sparrow/issues/1688:
Went to make a transaction with my hardware wallet and when I got to the signing process, I was surprised, and suspicious to discover there was (also) a Jade signer recognized by Sparrow. I don't own a Jade hardware wallet, and the error log that showed up when it automatically tried to sign the transaction contained a bunch of serial output related to Bitcoin mining. Took some time to realize that my ESP-32 devices running NerdMiner were to blame, but not before cancelling the transaction out of suspicion.
Pretty sure Jade is built on an ESP-32 board, but would it be possible to tighten up the device identification such that any old ESP-32 board doesn't get picked up as a Jade hardware wallet by Sparrow?
Obviously a strange developer-level corner case, but caused enough suspicion I'd been hacked to warrant report the condition.
And from @craigraw's response:
Identification is done through USB vendor and product IDs which are unchanged from the ESP32 default. In addition, there are DIY Jades which use ESP32 boards, so it's not even a Blockstream thing. The Jade API itself is not particularly robust either, so rejecting devices based on their initial response will probably do as much harm as good (see https://github.com/sparrowwallet/sparrow/issues/1616 for details).
I don't like it either, but I think this is a Jade problem without resolution at this level. It may be worth reporting to Blockstream.
Would it be possible to enhance the Jade API such that normal ESP-32 devices connected to a system aren't assumed to be Jades?
- Dominant language
- C
- Stars
- 497
- Forks
- 131
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Blockstream/Jade
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Blockstream/Jade#329 · 4 comments ·
-
Difficulty 1/5 Under an hour Newbie friendliness 78/100
Blockstream/Jade#317 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Blockstream/Jade#315 · 3 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Blockstream/Jade#313 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Blockstream/Jade#345 · 4 comments ·
All issues in Blockstream/Jade
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
level/task module/gcp type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
Difficulty 1/5 Under an hour Newbie friendliness 86/100
hapostgres/pg_auto_failover#1190 ·
-
docs
Difficulty 1/5 Under an hour Newbie friendliness 85/100
-
P3 sonic-vpp
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
sonic-net/sonic-buildimage#29662 ·