this post was submitted on 11 Mar 2025
17 points (100.0% liked)

Hardware

399 readers
69 users here now

A community for news and discussion about the hardware side of technology.


Rules

1. English onlyTitle and associated content has to be in English.
2. Use original linkPost URL should be the original link to the article (even if paywalled) and archived copies left in the body. It allows avoiding duplicate posts when cross-posting.
3. Respectful communicationAll communication has to be respectful of differing opinions, viewpoints, and experiences.
4. InclusivityEveryone is welcome here regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
5. Ad hominem attacksAny kind of personal attacks are expressly forbidden. If you can't argue your position without attacking a person's character, you already lost the argument.
6. Off-topic tangentsStay on topic. Keep it relevant.


If someone is interested in moderating this community, message @brikox@lemmy.zip.

founded 8 months ago
MODERATORS
top 4 comments
sorted by: hot top controversial new old
[–] 0x01@lemmy.ml 1 points 4 weeks ago (3 children)

Did we ever validate the esp32 Bluetooth backdoor?

[–] BigMikeInAustin@lemmy.world 1 points 4 weeks ago

For an extra $50, your CO monitor can also run wifi in promiscuous mode!

[–] ulterno@programming.dev 1 points 4 weeks ago* (last edited 4 weeks ago)

Seemed more like, the hardware developer didn't document some useful features and forgot to remove some debugging features.

I would have considered it a backdoor, if the features made it possible to run code via a bluetooth packet without having the firmware enable such a thing.
The article seemed to conclude that there could be attacks done after overwriting the firmware (which would have to be done using technologically legitimate means, like accessing the hardware), which, from what I see, won't really need to depend upon extra undocumented functionality to create a Trojan.
The only case in which it would be a problem is if there were some firewall rules relying upon the inability of ESP32 to execute said functions.