Did we ever validate the esp32 Bluetooth backdoor?
Hardware
A community for news and discussion about the hardware side of technology.
Rules
1. English only
Title and associated content has to be in English.
2. Use original link
Post 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 communication
All communication has to be respectful of differing opinions, viewpoints, and experiences.
4. Inclusivity
Everyone 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 attacks
Any 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 tangents
Stay on topic. Keep it relevant.
If someone is interested in moderating this community, message @brikox@lemmy.zip.
For an extra $50, your CO monitor can also run wifi in promiscuous mode!
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.