Xeno Kovah / is on Nostr

Interested in reverse engineering, firmware, bluetooth, trusted computing, and training. Founder of @OpenSecurityTraining2 https://ost2.fyi

Last Notes

2025-04-21 00:26:28

Those "hacked" crosswalk buttons last week were most likely just things that hadn't changed the default password (from "1234"), and then someone used the Polara app to upload new audio (which is part of its core functionality.) Today I decompiled the Android app and added the UUIDs (pic1) to CLUES: https://github.com/darkmentorllc/CLUES_Schema
So now Blue2thprinting https://github.com/darkmentorllc/Blue2thprinting, and other tools that use CLUES, like WHAD https://github.com/whad-team/whad-client, can more easily identify Polara BLE-enabled crosswalks.
If the assumption is that the devices which were maliciously modified were not reconfigured away from default, then it would be reasonable to assume that devices which still have default names matching the patterns shown in pic2, are more likely to be vulnerable. And of course @nprofile…tzc7 shows plenty of hits for such devices. And indeed, I used WiGLE to go drive to an intersection one county over and confirm that the 4x default-looking devices there were indeed broadcasting the Polara UUIDs (since WiGLE doesn't report the UUIDs, which would be useful for confirmation.)
Thanks to Mike Ryan @nprofile…ghsl for pointing out a video from Deviant Ollam @nprofile…fyar from last year which made it more obvious what was going on. https://www.youtube.com/watch?v=mvvVSTlbqEI
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/373/089/789/846/035/original/0611152090b0943c.png
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/373/091/481/157/735/original/a090e277c04ab38d.png

2025-03-10 14:18:37

- reply

@nprofile…g90f @nprofile…dexn It is indeed possible that they continue to use HCI even in the single chip architecture. However, within Espressif’s response (https://www.espressif.com/en/news/response_esp32_bluetooth) is the statement “If ESP32 is used in a standalone application and not connected to a host chip that runs a BLE host, the aforementioned HCI commands are not exposed and there is no security threat.”. And my interpretation of that is that the ESP32 can also be used in 2-chip architectures in which HCI is the interface, per the Tarlogic researchers’ implied architecture.

2025-03-10 12:10:22

- reply

@nprofile…g90f @nprofile…dexn I was addressing the research in the context in which it was given. I’m aware that chips can have varying architectures (attached but non-animated examples from future class), and that a HCI-using architecture is not necessarily the most likely in the case of the ESP32. And indeed given that the research focused on IoT devices in the last few slides, it seems like the least likely place for HCI to matter in some sense. But I didn’t want to muddy the water with speculation, and I have no direct knowledge of population distribution of different architectures in the ESP32-specific ecosystem. So it’s basically “OK, if they want to talk about a vulnerability under the assumption of HCI, let’s talk about it under that assumption”.
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/138/062/641/271/846/original/1aa20ce978b89396.jpeg
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/138/062/662/751/130/original/5adbebf2e3fd0a14.jpeg
https://media.infosec.exchange/infosec.exchange/media_attachments/files/114/138/062/656/427/543/original/45066d990c86469e.jpeg

2025-03-10 12:10:22

- reply

2025-03-09 12:49:57

I’ve posted a detailed explanation of why the claimed ESP32 Bluetooth chip “backdoor” is not a backdoor. It’s just a poor security practice, which is found in other Bluetooth chips by vendors like Broadcom, Cypress, and Texas Instruments too. https://darkmentor.com/blog/esp32_non-backdoor/

2025-03-09 12:49:57