TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

ESP32 Undocumented Bluetooth Commands: Clearing the Air

225 点作者 iamflimflam12 个月前

14 条评论

unsnap_biceps2 个月前
&gt; Espressif will document all Vendor-specific HCI commands to ensure transparancy of what functionality is available at the HCI layer<p>I&#x27;m very glad they&#x27;re going to be more transparent rather than try to lock things down more. I&#x27;ve been impressed with Espressif over the years and I&#x27;m glad they&#x27;re continuing to impress.
评论 #43330992 未加载
评论 #43331144 未加载
sschueller2 个月前
You should be switching off the bluetooth on your device if is not needed. CE also has some regulations regarding this.<p>I use the ESP32 in my product[1] I am glad they exist. Their per-certified modules save you quite a bit of money when you do your CE testing.<p>Espressif also offer free design review if you are using their chip in your commercial project&#x2F;product[2].<p>[1] <a href="https:&#x2F;&#x2F;www.stationdisplay.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.stationdisplay.com&#x2F;</a><p>[2] <a href="https:&#x2F;&#x2F;www.espressif.com&#x2F;en&#x2F;contact-us&#x2F;circuit-schematic-pcb-design-review" rel="nofollow">https:&#x2F;&#x2F;www.espressif.com&#x2F;en&#x2F;contact-us&#x2F;circuit-schematic-pc...</a>
评论 #43330721 未加载
评论 #43340004 未加载
rswail2 个月前
In other words, this was a beatup for internet points, not, in any way, an actual security issue.
评论 #43330447 未加载
评论 #43330910 未加载
评论 #43330551 未加载
评论 #43330984 未加载
评论 #43331289 未加载
评论 #43330526 未加载
评论 #43331270 未加载
评论 #43331156 未加载
dengjiuhong2 个月前
Yet, a significant number of stock investors still suffer heavy losses because the market gets rattled by these exaggerated, attention-grabbing headlines. While the consensus here rightly labels this a non-issue—debug commands, not a backdoor, with no remote exploit possible—the sensationalism still has real-world impact. It’s frustrating to see how security hype, often just for internet clout or CVEs as pointed out, can overshadow Espressif’s solid response and transparency efforts, leaving retail investors to bear the brunt of the volatility.
评论 #43330894 未加载
评论 #43330755 未加载
评论 #43331115 未加载
评论 #43331233 未加载
solarkraft2 个月前
&gt; Espressif will provide a fix that removes access to these HCI debug commands through a software patch for currently supported ESP-IDF versions<p>&gt; Espressif will document all Vendor-specific HCI commands to ensure transparancy of what functionality is available at the HCI layer<p>This is great. While this practice may be common and it may not be considered a backdoor, undocumented functionality is definitely a risk. I’m glad that people didn’t just take it as “well that’s how it’s done” but instead are pushing for a better way.
spaintech2 个月前
First and foremost, I have no affiliation with any of the authors previously mentioned. However, I would like to pose a question to the community:<p>Is it feasible to exploit these undocumented HCI commands to develop malicious firmware for the ESP32? Such firmware could potentially be designed to respond to over-the-air (OTA) signals, activating these hidden commands to perform unauthorized actions like memory manipulation or device impersonation.<p>However, considering that deploying malicious firmware already implies a significant level of system compromise, how does this scenario differ from traditional malware attacks targeting x86 architectures to gain low-level access to servers?
评论 #43330635 未加载
评论 #43330772 未加载
评论 #43330730 未加载
评论 #43332178 未加载
评论 #43331320 未加载
blinkingled2 个月前
Very clearly written article - didn&#x27;t feel like they were trying to sell you their viewpoint - just laid down the facts concisely.
nonrandomstring2 个月前
Storm in a teacup. But it raises an interesting question. Why are these HCI commands &quot;undocumented&quot;?<p>A phrase I hear around security nowadays is &quot;Shadow API&quot; [0, 1]<p>A shadow API is an undocumented one, and it tends to set-off massive alarm bells.<p>The researchers were clearly too keen to make a splash, and that reflects a sad state of wannabeism and hustling for crumbs these days.<p>What exacerbates it is <i>proprietary software</i> - stuff that&#x27;s hidden, obscured, opaque, deceptive, distributed as mysterious &quot;blobs&quot;.... this entire cluster of behaviour raises red flags and gets people looking for things. And when we go <i>looking for things</i> that aren&#x27;t there ... we find them (assume the worst).<p>That is to say, the researchers are reacting emotionally (but with good justification) to discovering undocumented features, aka a &quot;shadow API&quot;.<p>This could have been avoided if the device maker had just documented them. Why didn&#x27;t they?<p>[0] <a href="https:&#x2F;&#x2F;www.cybershow.uk&#x2F;episodes.php?id=39" rel="nofollow">https:&#x2F;&#x2F;www.cybershow.uk&#x2F;episodes.php?id=39</a><p>[1] <a href="https:&#x2F;&#x2F;www.cloudflare.com&#x2F;learning&#x2F;security&#x2F;api&#x2F;what-is-shadow-api&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.cloudflare.com&#x2F;learning&#x2F;security&#x2F;api&#x2F;what-is-sha...</a>
评论 #43331062 未加载
评论 #43330957 未加载
评论 #43331061 未加载
评论 #43330953 未加载
londonembedded2 个月前
This is an absolute non-issue, as others have commented. Even without domain-specific knowledge, we can see this is all nonsense: &#x27;Allow attackers to carry out impersonation attacks&#x27; - the same thing that can be done with any number of legitimate and useful applications designed for developing with BLE, available on Android marketplace :*)<p>On any embedded platform which allows low level access to a radio transciever of any kind, it is possible to exercise all functionality, which will include various possible attacks. The only thing which prevents this in the industry at present is obfuscation, which most manufacturers (other than Espressif) dont bother with.<p>Take Nordic for example, who make probably the best and most widely used&#x2F;respected BLE chipset: the full functionality of the transciever can be used via a relatively small set of registers, which are fully documented. Nordic supply a BLE stack, but you can perfectly well write your own instead, meaning that you can deliberately or accidentally abuse all aspects of the protocol. Even at physical level, one can easily conduct simple jamming attacks, by broadcasting full power carrier signal on the BLE advertising channels.<p>None of this naughtiness is a security flaw. BLE and other wireless protocols in common use are well designed to be resistant to jamming, and the physical implementation of the radios on various SoCs available currently are limited: you cant put out 10 watts of hash over 82 channels at once, because the silicon doesnt support it. You cant even &#x27;sniff&#x27; BLE traffic in a real sense, because the silicon on requires a significant number of bytes of &#x27;address&#x27; in order to capture any meaningful packet data from ambient noise.<p>Here is C code, as a fun example, to broadcast full power carrier on any channel, from Nordic NRF52. This is absolutely documented and useful for testing (for example emissions).<p>&#x2F;&#x2F; set channel to number between 0 and 100 int channel = 0;<p>nrf_radio_shorts_set(0); nrf_radio_int_disable(~0); nrf_radio_event_clear(NRF_RADIO_EVENT_DISABLED); nrf_radio_task_trigger(NRF_RADIO_TASK_DISABLE); while (!nrf_radio_event_check(NRF_RADIO_EVENT_DISABLED)) {} nrf_radio_event_clear(NRF_RADIO_EVENT_DISABLED);<p>nrf_radio_mode_set(RADIO_MODE_MODE_Ble_LR500Kbit); nrf_radio_shorts_enable(NRF_RADIO_SHORT_READY_START_MASK); nrf_radio_txpower_set(0); nrf_radio_frequency_set(2400 + channel); nrf_radio_task_trigger(NRF_RADIO_TASK_TXEN);
rfoo2 个月前
tl;dr whichever system using an ESP32 as a bluetooth adapter may also just run arbitrary code on the ESP32 itself over the same interface. Commands have to be issued from the host system, not from the air.<p>This sounds like... a good feature? There are indeed some scenarios where doing so poses a security risk. But most of the time I do want to be able to run arbitrary code on e.g. my WiFi dongle when I&#x27;m in control. I know FCC is not a fan of this idea though.
评论 #43330533 未加载
评论 #43330511 未加载
Jochim2 个月前
Related:<p>Undocumented backdoor found in Bluetooth chip used by a billion devices<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43301369">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43301369</a>
评论 #43330537 未加载
raphman2 个月前
Context: <a href="https:&#x2F;&#x2F;www.tarlogic.com&#x2F;news&#x2F;hidden-feature-esp32-chip-infect-ot-devices&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.tarlogic.com&#x2F;news&#x2F;hidden-feature-esp32-chip-infe...</a><p>Both HN discussion [1] and blogs [2] mentioned that it was a nothingburger.<p>tl;dr: there are undocumented debugging interfaces on the original ESP32 chip that can only be accessed by code running on the microcontroller or via another computer connected via the physical UART interface. No remote exploit possible. Espressif will now provide a patch to disable these debugging interfaces and document all yet-undocumented interfaces.<p>[1] <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43301369">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43301369</a><p>[2] <a href="https:&#x2F;&#x2F;darkmentor.com&#x2F;blog&#x2F;esp32_non-backdoor&#x2F;" rel="nofollow">https:&#x2F;&#x2F;darkmentor.com&#x2F;blog&#x2F;esp32_non-backdoor&#x2F;</a>
vbezhenar2 个月前
Those proprietary implementations should not exist. Bluetooth is open protocol and there&#x27;s no reason to not use open source implementations.
评论 #43331019 未加载
评论 #43331330 未加载
MasterYoda2 个月前
Which good alternatives to esp32 are there? Thinking most on functionality, dont care so much about the cost.
评论 #43347439 未加载