ESP32/ESP8266 Wi-Fi Attacks(github.com)
github.com
ESP32/ESP8266 Wi-Fi Attacks
https://github.com/Matheus-Garbelini/esp32_esp8266_attacks
150 comments
Uhh, their WiFi implementation is hacked-together old open source code distributed as statically linked binary blobs. And that is just the software part, there isn't much visibility into the silicon side..
Plus they are a Shanghai-based company and can be compelled by the Chinese government to place hardware back doors.
(They are great for makers though, very affordable, lots of features.)
(They are great for makers though, very affordable, lots of features.)
Every hardware manufacturer can be instructed/bribed/forced to add backdoors to their hardware by their own government, hence the necessary push for open drivers/firmware (Broadcom itself, just to name one, has had strong ties with the US govt for a long time).
I can imagine a meeting in which some high rank officer says "Here's our backdoor blob, you merge this to all your chipsets firmware, so when necessary we can selectively either shut off Ethernet chips or have them relay information elsewhere as instructed through magic packets, which of course won't be noticed because the leds won't blink and any other chipset seeing these packets will comply as well letting them pass through without allowing any form of sniffing or telling the system administrator (1)". I can't imagine any manufacturer risking their business by replying "nope, we won't comply"; they will jump when commanded to do so and if caught the standard reply will be "we were forced" or "they say it's for national security, you know, to catch those evil terrorists!".
(1) it may seem absurd, sort of sci-fi, but having access to the underlying hardware and its firmware would make it not that hard to do. In that case, the only way to safely analyze network traffic would require very fast logic analyzers that wouldn't use any dedicated network chipsets.
The point is: security through obscurity usually doesn't work well, unless the untrusted party is the hardware maker itself, or whoever decides what they put in the hardware; in that case security through obscurity becomes a lot more about obscurity than security, which makes it near 100% effective.
(1) it may seem absurd, sort of sci-fi, but having access to the underlying hardware and its firmware would make it not that hard to do. In that case, the only way to safely analyze network traffic would require very fast logic analyzers that wouldn't use any dedicated network chipsets.
The point is: security through obscurity usually doesn't work well, unless the untrusted party is the hardware maker itself, or whoever decides what they put in the hardware; in that case security through obscurity becomes a lot more about obscurity than security, which makes it near 100% effective.
> I can't imagine any manufacturer risking their business by replying "nope, we won't comply"
How about the risk to their business when a multinational corporation is X-raying their cores for backdoors (as one does) and finds the state backdoor, and then decides to no longer do business with the hardware manufacturer because of it—and also publicizes the existence of the backdoor, such that other multinationals pull out as well?
(I say "multinationals" because, presumably, purely-domestic corporations could be compelled by the state to accept the backdoor and say nothing about it.)
How about the risk to their business when a multinational corporation is X-raying their cores for backdoors (as one does) and finds the state backdoor, and then decides to no longer do business with the hardware manufacturer because of it—and also publicizes the existence of the backdoor, such that other multinationals pull out as well?
(I say "multinationals" because, presumably, purely-domestic corporations could be compelled by the state to accept the backdoor and say nothing about it.)
Has this happened?
Yes. The specific scenario GP described is about SuperMicro and Amazon if my memory is correct on the parties involved.
Edit: it was for sure SuperMicro and Amazon.
https://www.bloomberg.com/news/features/2018-10-04/the-big-h...
Edit: it was for sure SuperMicro and Amazon.
https://www.bloomberg.com/news/features/2018-10-04/the-big-h...
That story was widely debunked in followup stories. No one ever demonstrated any of the claims in that story.
I didn’t say it wasn’t debunked, I said that it is what GP was talking about. I didn’t think the “debunked” part was relevant to the question asked that I was responding to. I guess you think it is, so my apologies.
The question asked if it ever happened. That your story didn’t actually happen is most certainly relevant.
> Every hardware manufacturer can be instructed/bribed/forced to add backdoors to their hardware by their own government, hence the necessary
This is false. In most western countries governments cant force HW makers to add backdoor.
This is false. In most western countries governments cant force HW makers to add backdoor.
Portions of the US government have tried multiple times to make the addition of backdoors required via public force of law. They're still trying to promote it now. Short of that public requirement, they can ask & issue orders to not discuss the matter, tie it with defense orders, or imply the withholding of export or trade licenses, all contingent upon cooperation. In the end it looks pretty blurry between a request for cooperation and and order.
Even in China, they might not need to rely on explicit state security authority, just tie it up with state sponsored funding or other softer measures.
Even in China, they might not need to rely on explicit state security authority, just tie it up with state sponsored funding or other softer measures.
> they can ask & issue orders to not discuss the matter,
They can't do that.
They can't do that.
Why not in the form of a National Security letter?
https://en.wikipedia.org/wiki/National_security_letter
https://en.wikipedia.org/wiki/National_security_letter
No, a national security letter can't do this.
It can only compel the release of collected metadata to agencies.
It can only compel the release of collected metadata to agencies.
Are holes in security infrastructure required to collect metadata? Are keys, data that secures content - considered metadata? They're not content. Since you can't discuss the letters publicly, a claim could be that it is metadata, and compel keeping the request to collect it as such secret - similarly the fight from the silenced party, if there were any fight, could be out of public visibility.
No they aren't. Read the Wikipedia page you linked to.
It's great that you can make claims like this based on zero evidence or even allegations, but there is no basis in fact for it.
What's more the number of 3rd party people that have to be involved in something like this make it virtually impossible that the national security letter structure could keep them all silent, especially since there are numerous foreign nationals in the supply chains.
Go read the huge amount of ACLU coverage of these, or the many articles linked, or the congressional testimony. There are no allegations that this mechanism is being used to do what you say.
It's great that you can make claims like this based on zero evidence or even allegations, but there is no basis in fact for it.
What's more the number of 3rd party people that have to be involved in something like this make it virtually impossible that the national security letter structure could keep them all silent, especially since there are numerous foreign nationals in the supply chains.
Go read the huge amount of ACLU coverage of these, or the many articles linked, or the congressional testimony. There are no allegations that this mechanism is being used to do what you say.
Since when has the US government felt limited by its own laws? The naïveté here is incredible.
That doesn’t prove they have done it. But arguing they can’t is crazy.
That doesn’t prove they have done it. But arguing they can’t is crazy.
Citation needed?
You seem to be making specific, narrow arguments to cast doubt on a much wider claim.
Care to state your belief about the relations between the TLAs and the larger networking and communications firms in the US?
Care to state your belief about the relations between the TLAs and the larger networking and communications firms in the US?
You seem to be making specific, narrow arguments to cast doubt on a much wider claim.
Not the OP, but I think that addressing specific parts of the claim is extremely important.
We've seen this around the PRISM program, where the allegations of support by tech companies were confused by their support for lawful law enforcment warrants (as opposed to the NSA's dragnet surveillance via PRISM). This confusion has reached the point where I saw a lecturer claiming Google helped the NSA collect data as part of PRISM, where the NSA's own slides[1] show the opposite[2].
[1] The famous "smiley slide" https://arstechnica.com/tech-policy/2013/10/new-docs-show-ns... or https://slate.com/technology/2013/10/nsa-muscular-program-sp...
[2] https://arstechnica.com/information-technology/2013/11/googl...
Not the OP, but I think that addressing specific parts of the claim is extremely important.
We've seen this around the PRISM program, where the allegations of support by tech companies were confused by their support for lawful law enforcment warrants (as opposed to the NSA's dragnet surveillance via PRISM). This confusion has reached the point where I saw a lecturer claiming Google helped the NSA collect data as part of PRISM, where the NSA's own slides[1] show the opposite[2].
[1] The famous "smiley slide" https://arstechnica.com/tech-policy/2013/10/new-docs-show-ns... or https://slate.com/technology/2013/10/nsa-muscular-program-sp...
[2] https://arstechnica.com/information-technology/2013/11/googl...
I would be interested in a review of applicable law which would limit the effect of a US FISA court order.
I'm not aware of anything that would prevent the court from ordering a vendor to implement features to effectuate surveillance ordered by the court.
I'm not aware of anything that would prevent the court from ordering a vendor to implement features to effectuate surveillance ordered by the court.
FISC/FISCR don't order surveillance, they permits it; the only compulsory powers they have are to limit the scope and conditions of the surveillance permitted, and that's binding on the government under FISA, which criminalizes certain surveillance unless authorized by FISC/FISCR.
And that's a pretty weak compulsion, since the people who are bound are the people who would ordinarily prosecute any federal crime, and they probably aren't interested in prosecuting themselves.
And that's a pretty weak compulsion, since the people who are bound are the people who would ordinarily prosecute any federal crime, and they probably aren't interested in prosecuting themselves.
FISA courts issue warrants, which are court orders. All US courts have the power of the writ which means they can issue further orders to effectuate an order or ruling. So a court can order a company to assist the government in the execution of a warrant. This is pretty long-settled law.
The fact that some government agent applies for the warrant does not alter the fact that the warrant, once granted, is an order nor does it remove the power of the writ for further orders to effectuate the warrant.
The fact that some government agent applies for the warrant does not alter the fact that the warrant, once granted, is an order nor does it remove the power of the writ for further orders to effectuate the warrant.
9/11 changed everything.
Ive looked - a lot - to try and find a reasonable alternative. I haven't found any devices that are as inexpensive and convenient as the ESP chips. Microchip have some relatively inexpensive WiFi modules that need to be used with another MCU and Silabs have some modules including an ARM MCU (WGM160P). These still need blobs but I'm a little happier with a larger more established silicon vendor.
I think (at least a couple of years ago) you could get a dev kit for Microchips parts. The difficulty was then you're responsible for keeping the WiFi stack up to date.
> Plus they are a Shanghai-based company and can be compelled by the Chinese government to place hardware back doors.
Plus Broadcom is a US-based company and can be compelled by the US government to place hardware back doors.
Plus Broadcom is a US-based company and can be compelled by the US government to place hardware back doors.
hahaha, this is not a backdoor. It's just logical implementation flaws. If wifi products had good certification, this things wouldn't happen.
Parent didn't say this was a backdoor; just that they "can be compelled" to add one, if requested by the Chinese government in the future.
Sadly this isn't a tin foil hat possibility.
Sadly this isn't a tin foil hat possibility.
Not unique to Chinese firms either. Sprint resisted blanket surveillance, for a while, and were finally coerced into line. Do you imagine hardware vendors are immune to the same pressure, in the US, Japan, and Europe?
I was going to say...
Espressif have not released the sources of the WiFi implementation, just binaries. I would define that as "security through obscurity".
While it is true that the core WiFi code is not open source, the ESP-IDF is significantly more open than anything else on the market today.
This is not to say that Espressif is the bee's knees. I personally wouldn't use their hardware in production. But by making their product easily accessible, and much of the source code open, they have made it easier for white hats to raise security issues.
This is not to say that Espressif is the bee's knees. I personally wouldn't use their hardware in production. But by making their product easily accessible, and much of the source code open, they have made it easier for white hats to raise security issues.
"avoiding patent infringement lawsuits via opacity"
Has there been any successful patent infringement lawsuits over the last three years that targets a Chinese company that has infringed upon a US company? Isn't that part of the issue in the current trade deal talks with China?
Several years ago Scottish chip company FTDI took matters into their own hands by releasing a driver that would brick counterfeits of their USB to serial converter chip: https://en.wikipedia.org/wiki/FTDI#Driver_controversy
Not a US company being infringed, but Lego has gotten a Chinese court to order Lepin to stop making imitations of Lego products. [1] Since arrests have been made over Lepin not complying [2], it seems like the ruling has teeth.
[1] https://www.brothers-brick.com/2018/11/05/lepin-ordered-to-s...
[2] https://www.brothers-brick.com/2019/04/28/arrests-made-in-le...
[1] https://www.brothers-brick.com/2018/11/05/lepin-ordered-to-s...
[2] https://www.brothers-brick.com/2019/04/28/arrests-made-in-le...
Doesn't look like they've actually stopped.
https://lepinworld.com/
https://lepinworld.com/
At least they seem to be working on opening parts of the code and have already released the supplicant code for example.
https://github.com/espressif/esp32-wifi-lib/issues/2 https://github.com/espressif/esp-idf/commit/c1396830243b4c8f...
https://github.com/espressif/esp32-wifi-lib/issues/2 https://github.com/espressif/esp-idf/commit/c1396830243b4c8f...
And honestly it's a little harder than Broadcom's to reverse. Xtensa doesn't have nearly the same support in reversing tools as ARM and MIPS. On the plus side though you do get unstripped binaries since it's a static library.
I agree, it is for sure harder to reverse, on the other side without releasing the source, it is also much easier to hide in and keep secret vulnerabilities and or zero-days.
Vulnerabilities in Broadcom/Cypress wifi chips' firmware have been known for a while now:
https://blog.exodusintel.com/2017/07/26/broadpwn/
https://blog.exodusintel.com/2017/07/26/broadpwn/
yes. "Most of their competitors... prefer security through obscurity"
Count Texas Instruments ("TI") in this camp.
For example, Josh Wyatt of TI is proud of TI's "black box" approach to security, and even became a bit defensive about TI's closed source / "you don't need to know" aspects of its security for its CC3220 chips:
https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/...
Why the F would anyone use these chips, when you can use a garden variety MCU, use a good TLS stack like WolfSSL or BearSSL, and fully control / own what goes into your product?
Count Texas Instruments ("TI") in this camp.
For example, Josh Wyatt of TI is proud of TI's "black box" approach to security, and even became a bit defensive about TI's closed source / "you don't need to know" aspects of its security for its CC3220 chips:
https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/...
Why the F would anyone use these chips, when you can use a garden variety MCU, use a good TLS stack like WolfSSL or BearSSL, and fully control / own what goes into your product?
Their "Trusted Root Catalog" is a total fiasco as well. They were one of the AWS IoT launch partners and they apparently repeatedly failed to including AWS root authorities in their catalog. They were responsive in acknowledging, but typically took a month plus to actually update the SDK, (released quarterly,) to address it.
https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/...
They did finally provide a method to use a custom root CA for SSL a year later, https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/....
They seemingly failed to comprehend why anyone would not want to use TI's chain of trust, that is not manufacturer customizable, on proprietary IoT devices. This was explicitly an issue for code signing as well, as it required obtaining a third-party code signing certificate from any number of CA's instead of using our explicit root CA.
[edit] spelling, clarity
https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/...
They did finally provide a method to use a custom root CA for SSL a year later, https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/....
They seemingly failed to comprehend why anyone would not want to use TI's chain of trust, that is not manufacturer customizable, on proprietary IoT devices. This was explicitly an issue for code signing as well, as it required obtaining a third-party code signing certificate from any number of CA's instead of using our explicit root CA.
[edit] spelling, clarity
The fact that Wyatt & co. needed to question in the first place why the stack should be open is disturbing to say the least.
I hope no one seriously relies on any of these products in any secure application. Indeed, many of the vendors in that thread described how they are moving away from the chip due to TI's asinine stance on the issue.
I hope no one seriously relies on any of these products in any secure application. Indeed, many of the vendors in that thread described how they are moving away from the chip due to TI's asinine stance on the issue.
> Vendor SDKs are often best effort endeavors provided "as is" with no thought given to security or reliability.
Having worked for a while with the state of the art of microcontroller internet connectivity I can unfortunately second this. Some vendor SDKs are a mess of copied together source code (e.g. old versions of mbedtls and LWIP libraries), random modifications, no clear integration and often quite a few multithreading and memory issues right out of the box. And that's not even to mention that there are often exists exactly 0 unit-tests.
I really hope the state of this space improves in the future, e.g. through new higher quality stacks. Rust would be a great candidate for these things, since it prevents lots of the issues upfront by refusing to compile. But building better stacks takes a lot of time and effort, and someone would first need to start those invest this.
Having worked for a while with the state of the art of microcontroller internet connectivity I can unfortunately second this. Some vendor SDKs are a mess of copied together source code (e.g. old versions of mbedtls and LWIP libraries), random modifications, no clear integration and often quite a few multithreading and memory issues right out of the box. And that's not even to mention that there are often exists exactly 0 unit-tests.
I really hope the state of this space improves in the future, e.g. through new higher quality stacks. Rust would be a great candidate for these things, since it prevents lots of the issues upfront by refusing to compile. But building better stacks takes a lot of time and effort, and someone would first need to start those invest this.
I agree there is a huge problem with security in IoT and it could be a great startup business for the near future. I met somebody in Redwood City who was working on the security on a hardware level, but I guess they have not been very successful.
For those unfamiliar with the topic, these two chips are by and far the most common wifi chips for DIY and are also very common in IoT devices. Due to cheap price ($2—$5 depending on the model) and very low barrier to entry technically, these devices are both very popular as well as very wide spread in those two categories.
These chips are the first hits for searches such as "Arduino wifi module", "breadboard wifi", "IoT wifi module", and many, many more as they're the downright easiest way to add wifi to something that doesn't have it out of the box.
I'm not sure how applicable these attack vectors are in the real world, but they affect a very large number of devices for sure.
These chips are the first hits for searches such as "Arduino wifi module", "breadboard wifi", "IoT wifi module", and many, many more as they're the downright easiest way to add wifi to something that doesn't have it out of the box.
I'm not sure how applicable these attack vectors are in the real world, but they affect a very large number of devices for sure.
They are also really capable processors on their own with some nice I/O, and they can be integrated to be really low power so things can run on battery power for months to years.
For example: the ODROID Go is ESP32 based and emulates all major 8-bit platforms reasonably well; it's a niche favourite.
Can they really last that long (on their own)? I looked into this when the ESP8266 first became popular maybe 4 years ago as I wanted to build WiFi temperature and humidity sensors. My calculations were that a set of AAA rechargable batteries (~2000mAh) would last a few days at most, with the device in deep sleep most of the time and waking up every 10 mins to take a reading and send it over WiFi.
Right now I'm looking to create smart blinds. The motors don't use that much power, but the issue is the MCU listening for commands. The ESP32 support BLE, but it's power consumption is still rather high, so batteries would only last a few days at most.
Right now I'm looking to create smart blinds. The motors don't use that much power, but the issue is the MCU listening for commands. The ESP32 support BLE, but it's power consumption is still rather high, so batteries would only last a few days at most.
Personal experience: I have a ESP32 that runs as a sort of weather station. It has a ~2000mAh battery and lasts almost 2 months, getting a data point once every 30 minutes. That is using the ESPHome to program it.
Even at once every 10 minutes, it should manage almost 3 weeks without requiring a recharge.
Some options that definitely help is to quicken the Wifi reconnect. ESPHome has options to disable AP scanning and doing a fast-and-dirty connect&send. Using MQTT also helped a lot compared to using HTTP.
The most important part is to reduce the on-time as much as possible. 30 seconds is still way above the lower limit that I can do. If you halve it you can double the amount of data points without additional energy by reducing the sleep time.
I'm working on replacing the battery with a solar panel and supercap to power it from ambient shadow light entirely, the numbers to agree that it is possible in my case. Would help to keep it alive in cold weather.
Even at once every 10 minutes, it should manage almost 3 weeks without requiring a recharge.
Some options that definitely help is to quicken the Wifi reconnect. ESPHome has options to disable AP scanning and doing a fast-and-dirty connect&send. Using MQTT also helped a lot compared to using HTTP.
The most important part is to reduce the on-time as much as possible. 30 seconds is still way above the lower limit that I can do. If you halve it you can double the amount of data points without additional energy by reducing the sleep time.
I'm working on replacing the battery with a solar panel and supercap to power it from ambient shadow light entirely, the numbers to agree that it is possible in my case. Would help to keep it alive in cold weather.
Ah ha, that's good to know! Yeah in my case I had a small solar panel (a few quid of eBay, I guess around 1W) which was able to power it through a British winter (it did get direct sunlight though). I had some rechargable AAA batteries and just wired the solar panel in parallel with them.
After a few months it stopped working, I think some moisture got in and the DHT11 failed.
After a few months it stopped working, I think some moisture got in and the DHT11 failed.
I was able to power ESP-12E based humidity and temperature sensor for about 6 months from 18650 cell. I've used deep sleep and 15 minutes intervals between readings.
Yeah, although it's a bit more involved than just getting any NodeMCU board.
A bare chip makes it much easier, and you need to balance what comes online and how long it sleeps to still work in your use case.
It's not all that easy in some cases, but it can be done. I've used [1] as a resource before in my own projects.
[1] https://github.com/z2amiller/sensorboard/blob/master/PowerSa...
A bare chip makes it much easier, and you need to balance what comes online and how long it sleeps to still work in your use case.
It's not all that easy in some cases, but it can be done. I've used [1] as a resource before in my own projects.
[1] https://github.com/z2amiller/sensorboard/blob/master/PowerSa...
Not totally sure about the ESP8266. I used a WiFly RN131 in a sensor product that woke up every 15 minutes and sent a reading. AA batteries lasted probably 18 months.
Biggest problem we found was enterprise networks would randomly kick you off if you were using DHCP. I think because they would assume that if you hadn't transmitted in five to ten minutes it meant you'd gone away. Using static IP fixed that.
Edit: Friend of mine that mucks with ESP8266's uses the low power timer to reset and wake the device up out of deep sleep. (Via a simple hack I think just connecting a timer pin to the reset).
Biggest problem we found was enterprise networks would randomly kick you off if you were using DHCP. I think because they would assume that if you hadn't transmitted in five to ten minutes it meant you'd gone away. Using static IP fixed that.
Edit: Friend of mine that mucks with ESP8266's uses the low power timer to reset and wake the device up out of deep sleep. (Via a simple hack I think just connecting a timer pin to the reset).
Here's a cool project for farm telemetry: http://www.geekstips.com/two-esp8266-communication-talk-each...
Star-mesh topology, with batteries on the leaf nodes. Solar further in. Excerpt: "I’m expecting about 3 months at a 5min log interval using a 2000mAh lipo battery."
Star-mesh topology, with batteries on the leaf nodes. Solar further in. Excerpt: "I’m expecting about 3 months at a 5min log interval using a 2000mAh lipo battery."
Yep. Just looking at one commercial product that's using it, the Sonoff wifi switch was bought by a lot of people:
on Banggood they show that they sold 242338 of them:
https://www.banggood.com/SONOFF-Basic-10A-2200W-WIFI-Wireles...
on Amazon the 4 pack listing has 548 customer reviews and there are other listings with hundreds of reviews and probably lot more people bought it than the reviews.
https://www.amazon.com/Sonoff-Remote-Control-Compatible-Andr...
It's used mostly for lights, fan, AC, heating, so not that much critical, but still lot of devices.
on Banggood they show that they sold 242338 of them:
https://www.banggood.com/SONOFF-Basic-10A-2200W-WIFI-Wireles...
on Amazon the 4 pack listing has 548 customer reviews and there are other listings with hundreds of reviews and probably lot more people bought it than the reviews.
https://www.amazon.com/Sonoff-Remote-Control-Compatible-Andr...
It's used mostly for lights, fan, AC, heating, so not that much critical, but still lot of devices.
I have a bunch of these around the house and garage. I never would have expected them to be secure against an attack.
I'd say Espressif has a near monopoly due to first comer advantage.
There are way, way more moneyed companies in the wifi MCU game, but I have not seen a single competitor chip outside sales demos yet.
Redpine had big dotcoms backing, but it seems that even they dropped the ball on them in favour of Chinese chipmakers. Amazon and Google recently reached out for MXCHIP and Espressif, and their Redpine based solutions never went beyond the tech demo stage.
There are way, way more moneyed companies in the wifi MCU game, but I have not seen a single competitor chip outside sales demos yet.
Redpine had big dotcoms backing, but it seems that even they dropped the ball on them in favour of Chinese chipmakers. Amazon and Google recently reached out for MXCHIP and Espressif, and their Redpine based solutions never went beyond the tech demo stage.
Realtek has the RTL8710, which is a lot like the ESP8266 but with an ARM Cortex-M3 (while Espressif uses the rather obscure Xtensa architecture), which has the advantage of getting an LLVM toolchain for it, which means you can program it in Rust (while the ESPs are mostly limited to C).
The real advantage of the ESP8266 however is its raw popularity. It has an Arduino environment, tons of ready to run sketches, Basic, Javascript, Lua and Python interpreter environments and lots of interesting projects already done with it.
The ESP32 follows right in its foot steps with even more features, power and power saving features. Espressif really saw the market the DIY community means and did some minor tweaks to its policies to cater to it, which probably helped its popularity with commercial hardware makers as well.
The real advantage of the ESP8266 however is its raw popularity. It has an Arduino environment, tons of ready to run sketches, Basic, Javascript, Lua and Python interpreter environments and lots of interesting projects already done with it.
The ESP32 follows right in its foot steps with even more features, power and power saving features. Espressif really saw the market the DIY community means and did some minor tweaks to its policies to cater to it, which probably helped its popularity with commercial hardware makers as well.
There is now a branch of LLVM that supports XTensa. You can run Rust code on an ESP, but it’s awkward.
mrustc is a good option too.
Realtek has the RTL8710, which is a lot like the ESP8266 but with an ARM Cortex-M3 (while Espressif uses the rather obscure Xtensa architecture), which has the advantage of getting an LLVM toolchain for it, which means you can program it in Rust (while the ESPs are mostly limited to C).
Any recommendations for good, affordable dev boards (say under 20Euro/USD), that are easily available?
(I have been playing with RobotDyn Blue Pills and Rust, but no wireless or Bluetooth connectivity.)
Any recommendations for good, affordable dev boards (say under 20Euro/USD), that are easily available?
(I have been playing with RobotDyn Blue Pills and Rust, but no wireless or Bluetooth connectivity.)
I haven't tried it, but https://www.seeedstudio.com/RTL8710AF-WiFi-Board-p-2805.html looks like it might be what you're asking about.
>I'd say Espressif has a near monopoly due to first comer advantage.
No. Espressif is used because it is _cheap_ and has relatively good support libraries. Just the chips/modules from other vendors are usually 15 to 20€ in single quantities while you can get an ESP8266 minimum development board (almost all normal arduino boards are minimum development boards) for like 3€.
Unless other vendors reach that same level, they will always stay back.
No. Espressif is used because it is _cheap_ and has relatively good support libraries. Just the chips/modules from other vendors are usually 15 to 20€ in single quantities while you can get an ESP8266 minimum development board (almost all normal arduino boards are minimum development boards) for like 3€.
Unless other vendors reach that same level, they will always stay back.
First comer advantage is huge.
I work with a mid sized engineering consultancy.
We began switching to ESP as our primary platform just around 2 years ago, just as wifi gadgets were starting to boom.
To date, we got 500 megs of MCU project in our repo. Though most of code is repetitive, there is no chance we will part with such a huge codebase.
Being able to complete a $200k project in a few weeks through code reuse, instead of few months is huge, and imagine how it is for bigger companies with own hardware. No chance anybody switching now.
I work with a mid sized engineering consultancy.
We began switching to ESP as our primary platform just around 2 years ago, just as wifi gadgets were starting to boom.
To date, we got 500 megs of MCU project in our repo. Though most of code is repetitive, there is no chance we will part with such a huge codebase.
Being able to complete a $200k project in a few weeks through code reuse, instead of few months is huge, and imagine how it is for bigger companies with own hardware. No chance anybody switching now.
>First comer advantage is huge.
No. It was first comer advantage in affordable wifi MCUs since they existed just fine before but only as more expensive solutions as I mentioned. You can keep on claiming otherwise but the facts don't support you in claiming that there weren't wifi MCUs before.
No. It was first comer advantage in affordable wifi MCUs since they existed just fine before but only as more expensive solutions as I mentioned. You can keep on claiming otherwise but the facts don't support you in claiming that there weren't wifi MCUs before.
Why do you call it first mover advantage when there were wifi MCUs before it?
What was before were not MCUs as such, but a zoo of spi wifi + mcu "solutions" from rentier companies like broadcom.
Technically, and conceptually they were hopelessly behind an integrated WiFi MCU.
Technically, and conceptually they were hopelessly behind an integrated WiFi MCU.
You are wrong. There were many Wifi MCU solutions available before.
Espressif did not innovate in the technology space but in pricing and having enough documentation available that hackers could piece together an open source toolchain and libs for the chip.
Espressif did not innovate in the technology space but in pricing and having enough documentation available that hackers could piece together an open source toolchain and libs for the chip.
He's just wrong/in denial about it. Wifi MCUs existed just fine before ESP as you say, they just weren't affordable.
Well that sucks. I have probably 20 esp8266 chips around the house doing various things (when you can get an MCU for like $2, you find a lot more uses!), but I don't think any of them really need to worry about this aside from the DoS attacks taking them offline. I'll need to maybe look into some alerts when they start going offline, but not much.
I'm not familiar with the Enterprise WPA2 stuff. Is it widely used in high security environments or "enterprise" areas? and is the ability to gain control over a device on those networks a big deal?
Enterprise WPA2 always seemed crazy complex, and the fact that many devices can't even seem to do WPA2 Personal completely correctly, I never had a good feeling about the Enterprise stuff.
I'm not familiar with the Enterprise WPA2 stuff. Is it widely used in high security environments or "enterprise" areas? and is the ability to gain control over a device on those networks a big deal?
Enterprise WPA2 always seemed crazy complex, and the fact that many devices can't even seem to do WPA2 Personal completely correctly, I never had a good feeling about the Enterprise stuff.
I don't have any experience with Enterprise Wifi, but according to the article:
> This practically means that unpatched ESP devices are more secure by actually using just WPA2 Personal.
This is good for all of us DIY'ers that are only using Personal WPA2 - the worst we're exposed to is targeted DOS attacks.
> This practically means that unpatched ESP devices are more secure by actually using just WPA2 Personal.
This is good for all of us DIY'ers that are only using Personal WPA2 - the worst we're exposed to is targeted DOS attacks.
Wonder if WeWork is on WPA2 Enterprise? Although they probably have Broadcom chipsets doing the work.
> I have probably 20 esp8266 chips around the house doing various things
How do you power them all? 20 AC adaptors or battery/solar or something?
How do you power them all? 20 AC adaptors or battery/solar or something?
A few are powered by mains (I have a habit of using them to automate "dumb" appliances. So I put one in a cheap dehumidifier in place of the physical on switch), and the rest with repurposed small lithium ion rechargable batteries meant to be used with drones.
The battery powered ones need to be careful with how they sip power, but in most cases I can rig something up to get them to last. And the batteries I got off eBay all came with their own USB charger, so like 30 minutes of charging every few months and they are good.
I want to look into solar, but I just haven't had time to tinker with it yet.
The battery powered ones need to be careful with how they sip power, but in most cases I can rig something up to get them to last. And the batteries I got off eBay all came with their own USB charger, so like 30 minutes of charging every few months and they are good.
I want to look into solar, but I just haven't had time to tinker with it yet.
> I'm not familiar with the Enterprise WPA2 stuff.
WPA2 Enterprise doesn't use a preshared key, instead relying on something like RADIUS Authentication to validate usernames/passwords and then providing a custom key.
If you uses your Active Directory credentials to login to corporate WiFi then you're using WPA2 Enterprise.
WPA2 Enterprise doesn't use a preshared key, instead relying on something like RADIUS Authentication to validate usernames/passwords and then providing a custom key.
If you uses your Active Directory credentials to login to corporate WiFi then you're using WPA2 Enterprise.
yes, what was discovered is that no matter what master key was exchanged after the radius authentication, the attacker can still hijack the device.
Reading carefully the documents presented by the author Enterprise mode seems to be even less secure than the normal WiFi mode. Quite ironic I agree.
Enterprise requires everyone to use a different key while wireless communication in a group wants traffic to be possible between the clients directly and broadcasted. That’s conflicting.
That's like E-TLS. The enterprise version of TLS.
It feels somewhat irresponsible to not have some scare quotes or a disclaimer or something in there. There's probably some people who are just learning about "enterprise TLS" who don't know that it's hobbled: https://www.eff.org/deeplinks/2019/02/ets-isnt-tls-and-you-s...
This appears to be the relevant thread on the Arduino ESP8266 page: https://github.com/esp8266/Arduino/issues/6016
Looks like it was closed due to "lack of info". I wonder if that caused some bad blood?
Looks like it was closed due to "lack of info". I wonder if that caused some bad blood?
Looks like it was a question about where to report it, followed by a handful of suggestions and _then_ the close. I don't see any reason for bad blood from that, especially since there was a bit of follow-on discussion and by the look of it, a fix was released a couple of weeks back.
Yeah, on second read I agree with you. I'm just wondering why the public PoC disclosure before that team had more chance to fix. The arduino-esp8266 folks are super popular in the ESP community.
By my read, the fix is still open in that repo, tracked by the follow-up issue: https://github.com/esp8266/Arduino/issues/6436
By my read, the fix is still open in that repo, tracked by the follow-up issue: https://github.com/esp8266/Arduino/issues/6436
These discussions go back well beyond 90 days, which is more than enough time to wait for public disclosure.
Honestly most of the IOT consumer tech infrastructure does security via the "please don't look at me" approach.
Still don't know exactly why my home assistant can discover & control my wifi bulbs...never provided passwords or anything.
Still don't know exactly why my home assistant can discover & control my wifi bulbs...never provided passwords or anything.
Re: wifi bulbs: I think most of them just inherently trust WLAN and broadcast to / accept any connections or instructions from WLAN. Especially if they don't connect to cloud at all, it's a fairly simple solution (albeit with low-security too). Basically, your WiFi password is the password.
Oh, you must use an Amazon product, they sync wifi passwords across all your devices.
The fake beacon frame issue is the key one here - relatively few people are using Enterprise WPA2, but ESP8266 (or compatible - such as the Tuya TYWE3S) chips are in all kinds of random low cost IoT devices. I've got some smart plugs which use them, as well as a few of the dev boards connected up to various sensors, so looks like will have some patching to do...
I suppose "relatively few people" is true if you define people the way it would have been understood a century ago. Corporate and institutional systems will almost invariably do WPA2 Enterprise.
Without Enterprise, there's just one magic shared key "password" known to every user of the network.
The Enterprise mode outsources authentication of participants to a separate service using EAP and nearly always ends up leveraging TLS to actually make this secure one way or another.
This enables, for example, EduROAM in which academics and students use their "home" institution credentials to get network access in any participating educational network.
Without Enterprise, there's just one magic shared key "password" known to every user of the network.
The Enterprise mode outsources authentication of participants to a separate service using EAP and nearly always ends up leveraging TLS to actually make this secure one way or another.
This enables, for example, EduROAM in which academics and students use their "home" institution credentials to get network access in any participating educational network.
I was talking in terms of IoT devices using these chips - more of them are likely to be on home networks, using WPA2 Personal than in offices using the enterprise version. For offices, wired smart devices or higher end wireless devices are more common, which tend to use custom silicon, rather than COTS modules like the ESP ones. Hue bulbs, for example, don't use ESP derived chips (if only because they need Zigbee rather than WiFi), and not does Lutron kit (z-wave), although Lifx bulbs do.
Home automation on personal networks is certainly a large use case for these devices, but I think you underestimate the number of ESP8266/32 devices that are used in enterprise environments. The Industrial IoT space is pretty big, using small wifi chips like the ESPs for stuff like factory data collection or data center monitoring. I also have personally seen them used in medical device environments and security systems (think wireless door sensors and the like).
The "big boys" probably use custom made silicon (but even then I've seen custom-made silicon with an ESP8266 mounted onto it to abstract out the wifi connection part), but I wouldn't be surprised if the majority of IIoT startups use the ESPs as part of their products.
The "big boys" probably use custom made silicon (but even then I've seen custom-made silicon with an ESP8266 mounted onto it to abstract out the wifi connection part), but I wouldn't be surprised if the majority of IIoT startups use the ESPs as part of their products.
So if it's the norm to connect to unknown APs with SSID "eduroam" and submit your username and password, can I make a rogue AP that sniffs everyone's credentials? Or is this prevented under Enterprise, e.g. through a pre-shared certificate for the authentication server (which isn't run by the AP host)?
If the latter, can I make my own real eduroam AP?
If the latter, can I make my own real eduroam AP?
The AP needs to arrange (typically with a RADIUS server) to tunnel the authentication to a remote EAP at the users institution. The local RADIUS server will discover your username (often an email address) but the other credentials used are up to the institution and only delivered there. It will often be MSCHAPv2 which is designed to authenticate Windows passwords, but it could even do X.509 client certificates.
Since TLS ends up in the picture many institutions use the Web PKI, so a typical modern device already understands how to verify that this is the right server for [email protected] to authenticate against, it's the one with a Certificate for the DNS name example.com. But yes, they can do all this with custom certificates instead and I'm sure lots do that.
Yes, you can in principle make an EduROAM service. You should probably talk to whatever higher education or further education IT body exists in your country.
Notice that only academics and students get to access the network, so unless you're either of those things you'll need to also add an escape hatch for yourself and anybody else you want using it. Offering the service to others does not entitle you to any access, it would be only a courtesy to others.
Since TLS ends up in the picture many institutions use the Web PKI, so a typical modern device already understands how to verify that this is the right server for [email protected] to authenticate against, it's the one with a Certificate for the DNS name example.com. But yes, they can do all this with custom certificates instead and I'm sure lots do that.
Yes, you can in principle make an EduROAM service. You should probably talk to whatever higher education or further education IT body exists in your country.
Notice that only academics and students get to access the network, so unless you're either of those things you'll need to also add an escape hatch for yourself and anybody else you want using it. Offering the service to others does not entitle you to any access, it would be only a courtesy to others.
Great detailed answer, thanks!
Yeah, I've caused some of these crashes. The IDF needs a lot of work when it comes to some of the stacks.
I've been trying to bring the Bluetooth stack (which shares a common ancestor with the Android one) closer to the current Android Bluetooth stack, since that's well maintained (ish) and I'm extending it.
I've been trying to bring the Bluetooth stack (which shares a common ancestor with the Android one) closer to the current Android Bluetooth stack, since that's well maintained (ish) and I'm extending it.
Have you seen that the latest ESP-IDF includes Apache's NimBLE stack? I'm hoping that improves things a bit.
Maybe, I'll have to look into that. My application is an A2DP enhancement, and I think it would be at least a bit of work to implement an A2DP service in NimBLE; very cool nonetheless, thanks for bringing it up!
ESP8266 is a low-cost Wi-Fi microchip with full TCP/IP stack and microcontroller capability produced by Shanghai-based Chinese manufacturer, Espressif Systems.
ESP32 is a series of low cost, low power system on a chip microcontrollers with integrated Wi-Fi and dual-mode Bluetooth.
some kind of IoT chips? can't tell what the real world impact of this is.
edit: whoa, thanks for context folks! i'm surprised this wasn't obvious from wiki pages.
ESP32 is a series of low cost, low power system on a chip microcontrollers with integrated Wi-Fi and dual-mode Bluetooth.
some kind of IoT chips? can't tell what the real world impact of this is.
edit: whoa, thanks for context folks! i'm surprised this wasn't obvious from wiki pages.
These are really nice $5 chips with Wifi programmable with the Arduino toolset. Tons of IoT people use these to integrate various instrumentation and control into their houses or science projects. For instance, you can hook one up to a temperature sensor and a relay and control your heater. There are probably millions of these installed, hooked up to important hardware. So this makes wardriving fun again, I guess, if not destructive.
Just to give you some idea of how easy these are to use: In 20 mins with a small breadboard, a few Dupont wires, a Nodemcu ESP8266, a DHT22 with a pull up resister I've got a desk temperature sensor.
Add: https://esphome.io/
... and it talks MQTT and connects straight into Home Assistant.
Add: https://esphome.io/
... and it talks MQTT and connects straight into Home Assistant.
[deleted]
Hmm. Actually have all of that except the esp on hand
No soldering needed?
Yes, no soldering. Here's an example of the sort of thing that is sat on my desk:
https://lastminuteengineers.com/esp8266-dht11-dht22-web-serv...
If a NodeMCU board is too big for you then an ESP 01S is smaller and even cheaper. Less I/O options though but very useful. Needs a writer and wires to program. You can get one with a relay that is capable of switching 16A.
https://frenck.dev/diy-smart-doorbell-for-just-2-dollar/ - here's an example of a project. $2 is a bit ambitious I spend £7 for two of them on Amazon. That's two ESP-01S and two relays!
I don't do Arduino. esphome is a lot easier for me. You use pip to get the thing installed under your user account. Write a .yaml file which is largely copy and paste from examples and then install it through a USB cable the first time and then over the air after that.
https://lastminuteengineers.com/esp8266-dht11-dht22-web-serv...
If a NodeMCU board is too big for you then an ESP 01S is smaller and even cheaper. Less I/O options though but very useful. Needs a writer and wires to program. You can get one with a relay that is capable of switching 16A.
https://frenck.dev/diy-smart-doorbell-for-just-2-dollar/ - here's an example of a project. $2 is a bit ambitious I spend £7 for two of them on Amazon. That's two ESP-01S and two relays!
I don't do Arduino. esphome is a lot easier for me. You use pip to get the thing installed under your user account. Write a .yaml file which is largely copy and paste from examples and then install it through a USB cable the first time and then over the air after that.
Thank you, I've got software expertise but no hardware at all, I've been looking for something like this.
The ESP 01S is particularly good once you get to grips with writing to them because you can power them from any old phone charger that spits out 5V. You simply cut off the plug, look for the wire with the white stripe on it to determine polarity, strip the ends and screw into the relay block.
Be prepared to wave goodbye to your spare time and seriously consider a separate VLAN/SSID for these things.
Be prepared to wave goodbye to your spare time and seriously consider a separate VLAN/SSID for these things.
Heh, I came across your site last week, so thank you! (Oh, maybe it's not your site)
I got the DHT22 to work at 3.3V. But an old 1-Wire DS18B20 I have is very finicky. The pullup needs to be 500-800 ohms. Any experience with 1-wire at 3.3V? (Parasitic power mode). Worked great on a 5V nano.
I got the DHT22 to work at 3.3V. But an old 1-Wire DS18B20 I have is very finicky. The pullup needs to be 500-800 ohms. Any experience with 1-wire at 3.3V? (Parasitic power mode). Worked great on a 5V nano.
How do you power them conveniently though?
I can wrap my head around doing the soldering.
But power means either power adapter or battery?
If I’m doing power I might as well use a raspberry.
I can wrap my head around doing the soldering.
But power means either power adapter or battery?
If I’m doing power I might as well use a raspberry.
I tend to power my devices via a simple USB phone-charger.
Like the parent I have a few temperature/humidity sensors dotted around the house. Using a PI would be overkill and I'd have to keep the system packages up to date, worry about failing storage-device, etc.
Like the parent I have a few temperature/humidity sensors dotted around the house. Using a PI would be overkill and I'd have to keep the system packages up to date, worry about failing storage-device, etc.
Yep. Most have a micro-USB connector which supplies power, and handles uploading/logging. So when you're done debugging, you just need a phone charger with a long enough cable.
>simple USB phone-charger.
Damn. Was hoping that isn't the answer.
Phone chargers everywhere are ugly & in the way
>I'd have to keep the system packages up to date, worry about failing storage-device, etc.
Fair point
Damn. Was hoping that isn't the answer.
Phone chargers everywhere are ugly & in the way
>I'd have to keep the system packages up to date, worry about failing storage-device, etc.
Fair point
It is a WiFi enabled microcontroller locally designed and produced in china with a "100 million units sold" target. It is widely used by the makers community and by many new "smart" products. I would say that this has a really large scale impact and a lot of people will need to update the firmware.
Anything. From things like nanny cams in a teddy bear that can be remotely hacked. (although more likely that they just had an easy to guess password if they had one at all or other more common vulnerabilities) to smart traffic lights. p.s. regarding the nanny cams: I wish I was making this up: https://www.forbes.com/sites/thomasbrewster/2018/02/21/50000...
> some kind of IoT chips? can't tell what the real world impact of this is.
This is what virtually every WiFi toaster around uses now. If you see a wifi device below $20, it is almost certain that it will be Esp32 inside
This is what virtually every WiFi toaster around uses now. If you see a wifi device below $20, it is almost certain that it will be Esp32 inside
The single most popular IoT chips / network connected microcontrollers (at least among hobbyists).
AFAIK they are largely used in home-automation systems, especially home-made ones due to their low price, good enough specs and availability on resellers like AliExpress
Rain Bird uses them in their WiFi enabled Sprinkler Control Systems.
Looks like the pool on the roof might have a leak.
I have some sort of Espessif wifi controller in a smart bulb.
They are used everywhere in IOT.
So is there any way to mitigate these vulnerabilities, or does it require replacing the hardware?
The silicon vendor Espressif has already patched the last firmware (SDK) of such devices. However, other products that uses this chips with still have to patch against it.
The beautiful part of IoT is how there's billions of devices out in the wild with no upgrade plan.
The ESP chips are OTA capable with example code provided, but that still means vendors have to incorporate the function, provide a way for the device to check for updates, care enough to produce updates, and secure the upgrade mechanism enough that it's not a worse vulnerability than an unpatched device.
The ESP chips are OTA capable with example code provided, but that still means vendors have to incorporate the function, provide a way for the device to check for updates, care enough to produce updates, and secure the upgrade mechanism enough that it's not a worse vulnerability than an unpatched device.
Oh crud, all my lighting runs off these things. I wish more smart controller/switches used powerline networking rather than WiFi.
But then your neighbors house can become an attack vector for your house.
https://m.youtube.com/watch?v=6rxu4NwnUqA
https://m.youtube.com/watch?v=6rxu4NwnUqA
This is interesting for screwing up badges at Defcon, but I wouldn't lose too much sleep over it. They're neat devices but not really used for anything critical. I'm also not sure they're being used for a lot of consumer devices. If you war drived a major hackerspace you might reset an led light art project.
They're a lot more ubiquitous than some burner's art projects. While I wouldn't necessarily fret over a light switch crashing, expressif chips are popping up in home security products like SimpliSafe. Likely safe in a home from the WPA2 Enterprise hijack, simply crashing SimpliSafe base stations might lead to fun times.
> They're neat devices but not really used for anything critical.
Well, they have to be used _somewhere_. It's not like Espressif is achieving the economy of scale for a 3$ module by selling to hobbyists...
Well, they have to be used _somewhere_. It's not like Espressif is achieving the economy of scale for a 3$ module by selling to hobbyists...
The “Joule” immersion circulator uses an ESP8266. (I discovered this while looking at the firmware update files.)
In addition to products mentioned by others, Espressif parts are used in a few of the new LIFX devices.
I'd like to see a writeup how they discovered these weaknesses.
It's fine to say we want everything as secure as possible. But what about the tradeoff between a system being easy to connect/use and making it so difficult to connect that hobbyist users can't get the device to work.
If you are doing mission critical or life-safety related work with $3 devices, you are doing it wrong. Spend a little more and use something else.
In my case, I am monitoring room temperatures in my house with several ESP8266 devices so I want easy-to-connect features. I don't care about security in this application.
If you are doing mission critical or life-safety related work with $3 devices, you are doing it wrong. Spend a little more and use something else.
In my case, I am monitoring room temperatures in my house with several ESP8266 devices so I want easy-to-connect features. I don't care about security in this application.
Actually I think it's easier to make cheap, mass produced device secure because you have loads of eyes to check the code.
I wasn't arguing against open source. I agree with you on that subject.
But there is a point where you make a device so secure that it can be very difficult to connect with anything.
But there is a point where you make a device so secure that it can be very difficult to connect with anything.
Are there any open-source hardware/software ESP clones. Similar to what Arduino did in the micro-controller space?
I have been eyeing the Pine64 PADI, but I haven't bought any yet to try out.
It would be really hard to "clone" a SOC. Since its not a board that you can print for a buck these days, it actually requires a fab to print chips ... which is not something that is common to open source yet.
Oh I guess I didn't mean "clone" literally. Just an as-or-more-easy-to-use WiFi SOC.
That's why I keep them in my network only
The title of this submission made it sound like those are aeroplane models.
That being said, the status quo is completely untenable. Connectivity has become the norm in the hardware space, and it is built on a shoddy software foundation. Vendor SDKs are often best effort endeavors provided "as is" with no thought given to security or reliability. The results are clear: "the S in IOT stands for security" has become a trope, and connected cameras, locks, washing machines, and many more are getting owned on a weekly basis.
This will change, and whoever cracks this nut will be very successful indeed.