[HN Gopher] Undocumented backdoor found in Bluetooth chip used b...
___________________________________________________________________
Undocumented backdoor found in Bluetooth chip used by a billion
devices
Author : el_duderino
Score : 287 points
Date : 2025-03-08 16:30 UTC (6 hours ago)
(HTM) web link (www.bleepingcomputer.com)
(TXT) w3m dump (www.bleepingcomputer.com)
| rurban wrote:
| Their slides in Spanish:
| https://www.documentcloud.org/documents/25554812-2025-rooted...
| asdfologist wrote:
| Someone on Reddit suspected this 3 years ago.
|
| https://www.reddit.com/r/embedded/comments/wopjw8/how_sure_a...
| MarkMarine wrote:
| Gotta say I expected this to be the wifi system. Most of the
| code on the ESP-32 is given as source, but the wifi driver is
| not.
|
| https://github.com/esp32-open-mac/esp32-open-mac
| Eduard wrote:
| the lower layers of both Wifi and Bluetooth on ESP32 family
| devices are closed as of this writing.
| Aurornis wrote:
| That doesn't match the article at all.
| jillyboel wrote:
| Anyone who has thought critically for a few seconds has
| suspected this. The question is whether you're right and if you
| can prove that.
| millerm wrote:
| Funny that I just pulled out an ESP32 dev kit a couple days ago
| and I honestly questioned myself with "how do you even know these
| things are secure at all?" Glad I know the answer now.
|
| I'm starting to miss the days of being disconnected more and more
| as time goes on. This constant churn of having to monitor and
| lockdown everything you own down is becoming a complete negative.
| ceejayoz wrote:
| The next world war seems like it'll be about five minutes long.
| Nukes won't be required to send us back to the Stone Age.
| onemoresoop wrote:
| You mean all our devices refusing to work for us at a switch of
| a button?
| 20after4 wrote:
| One of the best conspiracy theories I have heard recently is
| that the CCP can use one of their reconnaissance balloons to
| instantly switch every device that has a Chinese radio chip
| into DDOS mode. If that were to happen it could plausibly
| generate enough congestion to seriously degrade a significant
| portion of the public Internet. This would of course be
| coordinated with multiple underwater cable cuts.
|
| It seems all too plausible, based on my admittedly limited
| understanding of how these devices work.
| gruez wrote:
| >One of the best conspiracy theories I have heard recently is
| that the CCP can use one of their reconnaissance balloons to
| instantly switch every device that has a Chinese radio chip
| into DDOS mode.
|
| This is a terrible conspiracy theory. Given how much Chinese
| IOT devices active in the West right now, the CCP doesn't
| even need to fly a balloon into the US. They can just
| pressure its IOT vendors to push a firmware update that
| broadcasts the DDOS signal.
|
| >If that were to happen it could plausibly generate enough
| congestion to seriously degrade a significant portion of the
| public Internet.
|
| At best it'll take down 2.4ghz communications, not the entire
| internet, or even all wifi networks. 5 Ghz/cellular networks
| will be spared because cheap chinese IOT devices don't
| operate in those frequency ranges, or the band is too wide
| for devices to jam. Moreover any important
| systems/institutions would presumably have hardwired
| connections, which are completely immune.
| LoganDark wrote:
| This is hilarious. Is there any evidence that such a "DDOS
| mode" has ever existed in any device?
| 20after4 wrote:
| No, of course there is no evidence, that's why it's a
| conspiracy theory. I can't remember if I saw it on a
| YouTube comment or a Reddit thread. Both are only slightly
| better than 4chan.
| LoganDark wrote:
| It sounds like more of a conspiracy fantasy to me if I'm
| being honest. The most attractive conspiracy theories in
| the US right now have nothing really to do with China but
| rather Russia instead.
| Scotrix wrote:
| wasn't vo1d something which could potentially deliver in
| this?
| noodlesUK wrote:
| EDIT: My Spanish isn't very good, but reading the slides it
| doesn't sound like the vulnerability is likely to be remotely
| exploitable, it sounds like it's only an issue if the chip is in
| HCI mode and being used as a bluetooth adapter. If someone who
| speaks Spanish could confirm I would be very appreciative.
| stragies wrote:
| With ESP32, always regard the vendor firmware only as proof-of-
| electrical-functioning. The first thing you should do with any
| ESP32 device after basic function test, is install ESPHome on
| it. If that's not possible, buy something different, where you
| can replace vendor fw.
| noodlesUK wrote:
| Oh, I completely agree for IoT devices. When I was first
| reading the article I feared that the issue was something
| burned into the bluetooth radio binary blob, or something at
| the hardware level that would not have mattered whether you
| were running esphome or not. Upon a little deeper inspection,
| it doesn't sound like that's the case.
| Eduard wrote:
| Espressif chips such as the ESP32 family are used for so many
| more applications than just smart home devices, which ESPHome
| targets.
|
| e. g. it doesn't make sense to install ESPHome on an
| ESP32-based drone :)
| Palomides wrote:
| I'm confused, is it that the bluetooth stack has a few
| undocumented commands? if these are only accessible to the code
| already running on the device, I'm not sure I would call it a
| backdoor
| 20after4 wrote:
| > "Depending on how Bluetooth stacks handle HCI commands on the
| device, remote exploitation of the backdoor might be possible
| via malicious firmware or rogue Bluetooth connections."
|
| Yeah this does not sound like a RCE.
| haswell wrote:
| In what way is what you quoted not describing an RCE?
|
| Clearly there are unanswered questions like does this
| malicious firmware exist? and how likely is it that ESP32s in
| the wild were shipped with it?
|
| But they're still describing an RCE.
| iracigt wrote:
| Because it's not remote. This allows a computer with a
| Bluetooth adapter to debug and modify its own firmware.
| This is normal. The potential problem is the interface for
| this was not documented, and the commands are embedded in
| the HCI host-to-bluetooth-adapter protocol. Because it's
| undocumented, software developers on the host may not have
| considered this in their threat modeling. Firmware updates
| usually require kernel-level privileges, but HCI does not.
| haswell wrote:
| Are you saying that none of the undocumented commands are
| capable of putting the device into a remotely exploitable
| state?
|
| The fact that it might be necessary to execute these
| commands locally is separate from the effects of
| executing those commands and the potential implications
| for hardware in the wild.
|
| A simple example would be a supply chain attack that
| leverages these commands to compromise what will soon be
| consumer hardware.
| Purplish9893 wrote:
| If I run `nc -l 31337 | sh` that puts my system into a
| remotely exploitable state, but that doesn't mean that nc
| or sh have RCE vulnerabilities, or that operating systems
| which allow installing nc and sh have RCE
| vulnerabilities.
| haswell wrote:
| nc and sh are well known and documented tools. Their
| existence on a system and running state can be inspected
| and the implications of various configurations is well
| understood.
|
| If someone just discovered nc in the wild and up to that
| point it had been unknown, people would put that bit of
| software in a very different category than the one it
| exists in today.
| huang_chung wrote:
| > If I run `nc -l 31337 | sh` that puts my system into a
| remotely exploitable state
|
| Quick, before someone posts this to Mastodon and gives
| presentation at security conference with title:
|
| Living off the Land: the Hidden Threat Within
| unsnap_biceps wrote:
| If you need local access to enable remote access, it's
| not a RCE.
| iracigt wrote:
| The devices are sold as programmable. The supplier loads
| their own code and has complete control over it. This is
| an advertised feature. Espressif also releases code that
| makes it into a Bluetooth adapter with a standard
| interface. Anyone in the supply chain can change the
| firmware without these commands. The concern is these
| commands were undocumented and exposed over an interface
| usually accessible by applications. The host drvier
| probably didn't expect this interface could make
| permanent changes.
|
| ESP32 devices not using the Bluetooth adapter firmware
| are unaffected and already running custom closed source
| (possibly encrypted) code from the supplier.
| 20after4 wrote:
| They say "backdoor might be possible via malicious firmware
| or rogue Bluetooth connections."
|
| Malicious firmware is not a RCE. If you install a malicious
| firmware you can do all kinds of bad stuff without this
| undocumented behavior.
|
| And "rogue Bluetooth connections" is entirely theoretical.
| That MIGHT be a RCE, but it is not one. More of a
| hypothesis.
|
| The headline alludes to much more than they have actually
| demonstrated. I'll change my tune when they demo the
| exploit code.
| iracigt wrote:
| Agreed. This is pretty common and no worse than a firmware
| update. The potential catch is in-band debugging may not
| require the same privileges on the host you'd expect from a
| firmware update. So conceivably your userspace (or worse
| WebBLE, not sure) program could add some malicious payload
| that's persistent in the adapter. Tracking beacon that persists
| through a drive replacement is scary, but not an RCE
| realitysballs wrote:
| Is this vuln. fixable via firmware or is the vulnerability
| inherent in the chip architecture?
| iracigt wrote:
| I think the title is a bit misleading. If I'm reading correctly,
| the "backdoor" allows a computer to peek and poke memory and
| other low-level functions of _its own USB Bluetooth adapter_. I
| don 't this this is usable over the air?
|
| Undocumented debugging commands like this are common. I've worked
| with at least two chips, a WiFi adapter and a GPS receiver, that
| had similar functions. Neither was documented, but found by
| reverse engineering the chip firmware or vendor drivers. It's not
| exactly an impactful issue on its own. Anything that allows
| unsigned firmware is equally vulnerable.
|
| If I'm misunderstanding and this is usable from anything other
| than the host, that would be a very different story.
| haswell wrote:
| What I took away from this was that malicious actors using
| ESP32 chips in their products could potentially leverage these
| commands to deliver essentially a Trojan horse.
|
| "Buy this super cheap home automation product" turns into
| installing an APT in your network.
| huang_chung wrote:
| > "Buy this super cheap home automation product" turns into
| installing an APT in your network.
|
| If that was intention, no need to hide code in the Bluetooth,
| just write it in the firmware. The device itself it the
| trojan horse.
| stragies wrote:
| Only buy ESP32 products, where you can access the pins for
| reflashing with ESPHome.
| 20after4 wrote:
| 100% agree. ESPHome is by far the best use for ESP32s that
| I've found.
| Aurornis wrote:
| That's not an accurate interpretation. At best, they're
| saying that a device using an ESP32 radio could send
| arbitrary packets, change its MAC address, or read/write the
| memory and registers on the radio.
|
| > "Buy this super cheap home automation product" turns into
| installing an APT in your network.
|
| That doesn't make any sense. If you buy a device with a
| radio, it's reasonable to assume that a malicious firmware
| could send/receive arbitrary things. That doesn't mean they
| have control of your network.
|
| EDIT: It's like if you plugged an ethernet IoT device into
| your network and then someone told you the Ethernet chip on
| the device was capable of sending arbitrary packets or
| changing its MAC address if the device chooses to do so.
| seba_dos1 wrote:
| That's why the article is misleading, because what you took
| away doesn't make any slightest sense.
|
| If a malicious actor can leverage these commands, it means
| they already have control over your device and can use its
| Bluetooth radio however they want.
|
| The only security problem that this causes is when your
| firmware gives someone else ability to use ESP's Bluetooth
| via HCI over UART without validating their inputs, not
| expecting it to allow them to take over the device. This is a
| rather uncommon scenario though - the user of such interface
| would usually be still you, just from a different chip.
| haswell wrote:
| > _If a malicious actor can leverage these commands, it
| means they already have control_
|
| _Have_ control, or _had_ control at some point in the
| device's lifecycle?
|
| e.g. if an upstream supplier leverages these commands to
| put the device in a vulnerable state (either intentionally
| or because of a supply chain compromise) prior to
| incorporation into some product, is this not still an
| issue?
| seba_dos1 wrote:
| "Have control".
|
| These commands let you do what a ROM bootloader does as
| well. They just do so over an unexpected vector (HCI
| interface), which could be a problem if you exposed it
| outside while not exposing the bootloader.
|
| Are you actually trying to come up with a plausible case,
| or are just guessing without knowing what this "backdoor"
| is about?
|
| Just for the record, the researches themselves described
| these command in their talk's abstract in this way:
|
| > The tools will be complemented by the use of
| undocumented manufacturer commands on ESP32 devices that
| allow to increase the versatility of these devices when
| implementing attacks or conducting audits.
|
| Source: https://reg.rootedcon.com/cfp/schedule/talk/5
|
| The same could have been achieved by implementing an
| open-source replacement for the blob, by the way (just
| like it's already happening with ESP32's Wi-Fi
| peripheral: https://esp32-open-mac.be/).
| alt227 wrote:
| > "Buy this super cheap home automation product"
|
| Surely thats a risk with buying any of the cheap chinese IoT
| gadgets on amazon or alibaba and plugging them into your home
| network?
| excalibur wrote:
| > "Buy this super cheap home automation product" turns into
| installing an APT in your network.
|
| Were we not already assuming this was the case?
| iracigt wrote:
| Oh, and from the perspective of open hardware, these alarmist
| headlines are a real disservice. The natural reaction to
| debugging interfaces and firmware updates being "backdoors" and
| "security vulnerabilities" is to lock it all down.
|
| Espressif has been an almost unique level of open for this
| space. They've contributed to open source Rust toolchains for
| their chips. They've even publicly encouraged reverse
| engineering of their modem stack because it contains licensed
| code they can't release. I hate to see bad and damaging
| publicity be the reward for being just a little bit open.
| huang_chung wrote:
| After reading it really seems much ado about nothing.
|
| Wait until they learn you can rewrite disk drive firmware from
| inside OS with root access.
| 20after4 wrote:
| It sounds like it might be very useful for an attacker who
| already attained access via some other exploit.
|
| Imagine the ESP32 is being used as a wifi/bluetooth "modem" via
| a serial link to a host system (rather than the ESP32 used as a
| standalone SOC.)
|
| In theory, the attacker could then use the undocumented
| commands to scan, spoof, or otherwise attack any near by
| bluetooth devices. Perhaps this could even be achieved without
| gaining root on the device which is hosting the esp32.
| huang_chung wrote:
| > In theory, the attacker could then use the undocumented
| commands to scan, spoof, or otherwise attack any near by
| bluetooth devices.
|
| So? Device is 0wned. Did you think Bluetooth chip is magic
| protection device for rest of the network?
|
| How would you stop physical external actor? Do you have "No
| ESP32 permitted on this property" signs on windows?
| 20after4 wrote:
| I'm not arguing that this is a big f'in deal. Seems like
| it's not much of a deal at all actually.
| iracigt wrote:
| Yeah, the research is good. Software developers do not expect
| HCI to have this type of control. Because it's undocumented,
| it's not in their threat model and is unexpectedly available
| from userspace. "Backdoor" isn't wrong, but it is misleading.
| The threat here is persistence from context that wasn't
| expected to have this capability.
| seba_dos1 wrote:
| That's right, but... who exposes ESP32's HCI to external
| world (and not just to another trusted chip) in actual
| projects? This is the kind of feature you see popping up as
| a Hackaday article titled "Your ESP32 As A USB Bluetooth
| Dongle" - you say "neat" and then proceed to forget about
| it.
|
| If you find a device that does it in the wild, then I guess
| you now gained a nice jailbreaking vector - that is, if it
| needed jailbreaking at all. Otherwise, it's nothing.
| throwaway5574 wrote:
| > Yeah, the research is good. Software developers do not
| expect HCI to have this type of control. Because it's
| undocumented, it's not in their threat model and is
| unexpectedly available from userspace.
|
| This possibility should be obvious to any software
| developer that knows how modern IO peripheral stacks are
| constructed. There is little that can be done to defend
| against a poorly written OS driver that exposes functions
| like this, even unintentionally, and it is naive to assume
| that any class of device will lack them unless clearly
| documented otherwise. This has been of particular concern
| to developers of open source Linux kernel drivers for
| _decades_ at this point.
| gruez wrote:
| >In theory, the attacker could then use the undocumented
| commands to scan, spoof, or otherwise attack any near by
| bluetooth devices. Perhaps this could even be achieved
| without gaining root on the device which is hosting the
| esp32.
|
| How's this any different than a laptop getting pwned and
| attackers being able to run aircrack-ng or whatever on it?
| 20after4 wrote:
| It's not that different. It might be easier than your
| average "pwn" and might not require root access, but this
| is only my hypothesis based on what's written in TFA.
| sitkack wrote:
| If it is USB, you should be able to do it directly in JS
| via Chrome.
| iracigt wrote:
| WebUSB requires the device to opt in via it's USB
| descriptors. Otherwise any USB device with firmware
| updates would have this problem.
|
| Maybe an issue here is WebSerial, as HCI comes over a
| serial port device. I believe the OS should block access
| to the serial device once the host driver takes it as a
| Bluetooth adapter though.
| monocasa wrote:
| > WebUSB requires the device to opt in via it's USB
| descriptors.
|
| IIRC, that restriction was removed.
| gruez wrote:
| >It might be easier than your average "pwn" and might not
| require root access
|
| It's an IOT device. Everything's running as root.
| megadata wrote:
| > How's this any different
|
| It's undocumented.
| gruez wrote:
| My laptop came with a 10 page quick start guide that
| mentions nothing about this "vulnerability". The only way
| to figure out whether a wifi chip can enter promiscuous
| mode or inject packets is by checking a wiki page
| maintained by volunteers.
| usrusr wrote:
| What if the computer peeking and poking memory of its own
| Bluetooth adapter might be doing so with software running on
| top of the Web Bluetooth API? I sure hope that it isn't that
| bad, but if it was, it would still be eerily consistent with
| your description.
|
| But let's ignore that web API worst case. Imagine that you have
| some semi-trusted software and because you don't want to take
| any risks, you run in nested VMs three layers deep. The
| software has some plausible excuse to require access to the
| Bluetooth (perhaps it's a beacon demo?) so you grant an
| exception. You're not happy with the result (the beacon demo
| does not work as promised?), you remove the software and you
| also reset all three VM layers for good measure. Gone for good,
| nice. Unfortunately, the guest the malware installed on the ESP
| when it had access is still there...
|
| Yes, undocumented access to your own subdevices can be a really
| bad thing, in particular when persistence is in the picture.
| gruez wrote:
| >Imagine that you have some semi-trusted software and because
| you don't want to take any risks, you run in nested VMs three
| layers deep. The software has some plausible excuse to
| require access to the Bluetooth (perhaps it's a beacon demo?)
| so you grant an exception. You're not happy with the result
| (the beacon demo does not work as promised?), you remove the
| software and you also reset all three VM layers for good
| measure, nice. Unfortunately the guest the malware installed
| on the ESP when it has access is still there. Yes,
| undocumented access to your own subdevices can be a really
| bad thing, in particular when persistence is in the picture.
|
| There are approximately 0 people who have the type of setup
| you described. Moreover, the chipset in question is only used
| in IOT devices, so it can't even be used in the way you
| described. Finally, does the chipset even have writeable
| memory? Or is it an exploit that only persists until the next
| reset?
| usrusr wrote:
| Thanks. That thought "no PC uses an ESP as its wireless,
| ESP are used as devices that do their own wireless" was
| rummaging around in the back of my mind, but failed to
| really make itself heard.
|
| I'm one of those who think NRF when they hear Bluetooth
| chip and with Nordics it's actually not that uncommon: when
| you want to make a PC talk ANT+ (r.i.p.) the dongle you put
| inside a USB port is usually the same Nrf52 you'd also find
| in a standalone device, only with some of its GPIO
| connected to the USB pads.
| laurowyn wrote:
| > But let's ignore that web API worst case. Imagine that you
| have some semi-trusted software and because you don't want to
| take any risks, you run in nested VMs three layers deep. The
| software has some plausible excuse to require access to the
| Bluetooth (perhaps it's a beacon demo?) so you grant an
| exception. You're not happy with the result (the beacon demo
| does not work as promised?), you remove the software and you
| also reset all three VM layers for good measure. Gone for
| good, nice. Unfortunately, the guest the malware installed on
| the ESP when it had access is still there...
|
| You're hopping through 4 security boundaries and granting
| direct hardware access. If you don't understand the decisions
| you're making by doing that, all bets are off.
|
| Better to give a virtualised bluetooth device and let the
| hypervisor drive the real one. Will hit performance a little,
| but it's far more secure.
| vlovich123 wrote:
| You've misread then:
|
| > Armed with this new tool, which enables raw access to
| Bluetooth traffic, Targolic discovered hidden vendor-specific
| commands (Opcode 0x3F) in the ESP32 Bluetooth firmware that
| allow low-level control over Bluetooth functions.
|
| The exploit happens over bluetooth. They used a USBC driver to
| explore the potential attack surface.
|
| Shit like this is what happens when you don't have good
| separation between functionality you give QA for production
| firmware & commands for factory firmware bringup. Almost
| certainly this is because the vendor used the same image for
| factory bringup & shipping to end users.
| seba_dos1 wrote:
| Nothing you quoted implies that there's an exploit that
| happens over Bluetooth. It actually implies otherwise, so
| you'll have to find a better quote if that's actually true (I
| couldn't, FWIW).
| 2OEH8eoCRo0 wrote:
| So it can peek your Bluetooth crypto. How is it not a backdoor?
| RicoElectrico wrote:
| FWIW almost nobody uses ESP32 for Bluetooth alone. This is
| primarily a Wi-Fi SoC. "Billion devices" is a ridiculous claim if
| most of them don't use BT features anyway.
| Retr0id wrote:
| It's unclear to me what a practical vulnerability/attack scenario
| would look like here.
| lima wrote:
| The researchers found undocumented hardware functionality which
| allows _someone who already has code execution_ a greater-than-
| expected degree of low-level access to the ESP32 wifi stack.
|
| Calling this a "backdoor" is just pure clickbait.
| mmastrac wrote:
| In theory you probably should have low-level access to your
| attached BT radio itself, so this is just kind of expected, isn't
| it?
|
| I prefer when devices have these low-level interfaces. Perhaps
| the problem is the lack of documentation rather than existence?
|
| I used to use the memory read/write commands via USB on Qualcomm
| radios to unlock and otherwise take ownership of otherwise
| locked-down devices. Given that was a full OOB read/write I'd
| consider that maybe not great, but if this is only accessible
| from flashed code all the better.
| almosthere wrote:
| Anyone want to start a Faraday cage laptop case company
| fsflover wrote:
| Again, the hardware kill switch in my Librem 5 looks like a
| necessary feature.
| roger_ wrote:
| I hate sensational stories like this. Now Espressif is gonna feel
| pressured to be even more closed.
| megadata wrote:
| It'd never have been an issue if this was documented.
| ratg13 wrote:
| I feel like people that are concerned about this have never
| heard of a JTAG access port.
| janice1999 wrote:
| On most modern micro-controllers you can disable JTAG/SWD
| in production or gate access behind key verification. You
| can't disable undocumented commands. The issue here might
| be allowing persistent malware, like how some malware can
| hide in hard drive firmware. Unlikely, but still not good
| or indicative of good security practice.
| Aurornis wrote:
| TL;DR: They reverse engineered the firmware and found HCI
| commands to do things like read/write memory, send packets, and
| set the MAC address.
|
| Not really a backdoor. I don't know if they called it a backdoor
| (presentation is in Spanish), or if the journalists are calling
| it a backdoor to get more clicks.
|
| You'd need to have arbitrary access to send HCI commands to the
| device to use these commands. That means you're already
| controlling the device and how it operates. This isn't something
| that gets remotely exploited over the wireless link. Any exploits
| would already have to have full control of the device, at which
| point being able to change the MAC address or send packets isn't
| really a surprise anyway.
|
| Interesting research, but really groan-inducing to see it spun as
| a "backdoor". I don't know who's to blame for the wording,
| though. I'm guessing the journalists?
|
| EDIT: For an analogy that might be more familiar, imagine if
| someone discovered that the Ethernet controller on a common IOT
| chip could change its MAC address or send arbitrary packets if
| the firmware told it to. This is the same thing, but with
| Bluetooth.
| ramses0 wrote:
| Don't you see how a random device with an Ethernet cord being
| able to change its MAC address and send arbitrary packets is a
| wormable threat actor?
|
| ...and then let it do the same but without the Ethernet cord
| requirement?
|
| Drive around with a white van that says "Free Candy / BLE
| Persistent Threats"... pwn devices as you walk through the
| metal detectors on the way to China.
|
| Wireless, wormable, arbitrary packets, spoofing arbitrary
| devices and you don't see the issue?
| awwaiid wrote:
| It doesn't sound like it is wormable -- it doesn't allow any
| new attacks on external devices.
| ddtaylor wrote:
| No plausible attack described for a reason.
| abetancort wrote:
| garbage.
| slater wrote:
| Am I misremembering, or wasn't there some hubbub ca. 2010 where
| someone was going to do a presentation at CCC about how Bluetooth
| is basically swiss cheese in terms of security, and _someone_ got
| all huffy about it and it was all hush-hush 'd and the
| presentation cancelled?
| K0balt wrote:
| This is good research, but a bad headline. As an attack vector,
| this requires physical access and could already be done by other
| means in almost all cases. So, "undocumented commands found in
| common Bluetooth chip" would be a better headline.
| russellbeattie wrote:
| Can any app running on an Android device with an ESP32 save code
| permanently to flash memory? Would an app have that level of
| access to send arbitrary low-level commands to the hardware?
| raydiak wrote:
| So everyone's fine installing opaque binary blob drivers which
| run in kernel space on their desktops and laptops and not even
| having root access to their own cloud-controlled phones, but some
| undocumented low-level ESP32 commands which require the device to
| already be compromised are a news-worthy threat vector.
|
| Really wonder if something got lost in translation, here. In the
| past we would have just thought that was cool and looked for a
| way to turn it into a SDR.
___________________________________________________________________
(page generated 2025-03-08 23:01 UTC)