Im uncomfortable with what I read that every company of significant size in China automatically requires CCP party members to be involved in the company at a high level.
So Im very happy to hear people such as these guys are looking deep at this.
Ofcourse since Espressif controls the hardware, so they can do anything eventually. My itch will always be there and Im going to switch once I find something made in preferably the EU when I find something comparable to esp32. Maybe Nordic Semiconductors will make some nice risk-v chips and dev-boards soon.
It also seems that Espressif has bought their wifi IP, so their contracts and licensing terms with the IP vendor likely prevent any sharing.
But FCC is the reason for closed binary blob firmware for all wifi radios out there these days.
This is why open firmware can be really handy for the security community.
GSM->5G modems are a lot harder to debug... maybe now in recent years with cheaper SDRs, but a lot harder then wifi.
And not sure why you'd be afraid of CCP, we saw the wikileaks, USA does a lot of similiarly bad stuff too and even got caught doing it... and if you live in a "western" country, USA has much easier access to you than China.
If the IoT ecosystem has any weak spots, it is the Tuya software stack. It would be much easier, much more useful layer to put a back door into that.
I find little solace in this whataboutism.
Learn more about Espressif's founder. And I think the CCP party cannot impact Espressif.
------- Singapore’s bilingual education gave the engineer an adequate command of Chinese; he played translator for his Chinese and non-Chinese speaking staff in meetings during Espressif’s early days.
And the time he spent in national service with the Singapore Armed Forces taught him the importance of being in the front line, of knowing the ground well.
The CEO believes that entrepreneurship cannot be taught. One needs to have a head for risk-taking, creativity, a big-picture perspective, and to be prepared to fail.
And passion, of course.
He has a nugget of wisdom for those who have yet to find theirs: “There are two things that drive people... One is passion, the other is fear... If you lose that fear, you might find your passion.”
So I'm not sure that framing your paranoia in terms of "the Chinese" is productive - you might just want to update that thought with "any state actor who operates covert torture sites and violates human rights at immense scale", in which case your set of actually hostile actors becomes a little more realistic.
The biggest threat to your freedom and human rights, as an American, is your own government.
Yes, except the China also 'infiltrate' Chinese companies themselves, and can perhaps order them to put in backdoors.
The NSA generally does not order US companies around, as evidenced by the fact it's been documented that they intercept shipments and compromise the systems on their own:
* https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa...
If the NSA had an 'in' into Cisco (or Juniper, or Aruba, etc), they wouldn't need to clandestinely have their own 'compromise factories'.
Yes, both the Chinese and NSA do cyber stuff, but so does every country. At the very least the odds of getting a 'clean' product from an American supplier compared to a Chinese one are higher: the links between Chinese companies and government are often murky.
Or more subtly they could insert (or just not fix) a bug which allows packet descriptors to be overwritten on reception of a certain malformed WiFi packet, e.g. too short or long, which makes it possible to overwrite regions of the device's memory and thus compromise it. A SDR might be required to transmit the malformed packet(s).
By the way, I wonder if modern Realtek switch chips might still support RRCP, and an undocumented EEPROM bit or strapping resistor might re-enable it?
1. https://en.wikipedia.org/wiki/Realtek_Remote_Control_Protoco...
You can write these registers via the management interface or via the EEPROM. It will not respond to discovery packets, but get and set packets work fine.
This chip also has a 8051 core that can access the internal bus and can tx/rx network packets. To use it you either attach external SPI flash (large program) or write the program into the internal RAM in the chip (small program).
All documented stuff, no secret details.
That's fair but Espressif is wayyyyyyy more open than ANY Western chip maker. The entire framework and toolchains are open-source for one thing. You get listings and sometimes pseudo-code for the internal ROMs (though no code). You get full access to datasheets, technical reference, and sdk documentation. Everything in their SDK is documented. You even get help on github. All of that accessible to anyone anywhere at any time.
Contrast that to the last time I worked with Nordic in a professional manner, I had to sign NDAs to get the full documentation and toolchain. Their toolchain contained binary blobs that when inquired about you get told "don't worry about it ;)" which is shockingly frustrating when a crash occurs in them and you're left trying to work around it. And if you're not a professional you're basically SOL and left with half-baked community toolchains, when they exist for a particular chip.
They are, not as CPU necessarily but for exactly those auxiliary functions: https://blog.nordicsemi.com/getconnected/why-nordic-is-getti...
Do you know about this
https://www.swisscommunity.org/en/news-media/swiss-review/ar... https://www.reuters.com/technology/cybersecurity/governments...
So... you are basing your fears on just that, hunches and yet presumably your own government is spying on others and maybe you but that doesnt bother you because USA /five eyes are the "good guys"
Espressif has also launched a new ESP32C3 based on RISC-V, with modules priced at around $2.
cant wait until they can make a dual-core risc-v but p.happy on the -s3
It consists of a high-performance (HP) 32-bit RISC-V processor, which can be clocked up to 160 MHz, and a low-power (LP) 32-bit RISC-V processor, which can be clocked up to 20 MHz. It has a 320KB ROM, a 512KB SRAM, and works with external flash. It comes with 30 (QFN40) or 22 (QFN32) programmable GPIOs, with support for SPI, UART, I2C, I2S, RMT, TWAI, PWM, SDIO, Motor Control PWM. It also packs a 12-bit ADC and a temperature sensor.
https://www.espressif.com/en/products/socs/esp32-c6
[The High Performance] CPU . . . has 4-stage, in-order, scalar pipeline optimized for area, power and performance. CPU core complex has a debug module (DM), interrupt-controller (INTC), core local interrupts (CLINT) and system bus (SYS BUS) interfaces for memory and peripheral access.
The ESP32-C6 Low-Power CPU (LP CPU) . . . features ultra-low power consumption and has a 2 stage, in-order, and scalar pipeline. [It has same features but lacks core local interrupts (CLINT)].
https://www.espressif.com/sites/default/files/documentation/...
There is a bunch of hand wavy information on building faraday cages online, some people suggesting to utilize a microwave oven, since they operate at the same frequency.
There are even wifi faraday cages for sale on amazon.
However I can't really find much actual benchmark data online about how well these various approaches actually attenuate signals.
Less about protocol development and more fear of 5G and wifi.
The prices of this things can be quite high. Which is why I bought my small one as used surplus.
One can find a great amount of models from various manufacturers here: https://www.everythingrf.com/search/shielded-test-enclosures
And none of them look cheap. But more "please call for quote"-type of things.
I'm surprised their paint can only gave them a 10 dB difference. I've found simply wrapping things in aluminum foil is good for about 40 dB when it comes to Wi-Fi.
Out of random interest I tested the "put a phone in it and call it" and it didn't work (as did wifi) that's mentioned in [2].
[1] https://www.hea.de/fachwissen/mikrowellen/sicherheit
[2] https://www.sfu.ca/phys/346/121/resources/physics_of_microwa...
https://www.mattblaze.org/blog/faraday
It's a few years old, but seems pretty thorough.
Anyone have a recommendation on conducting fabric for RF isolation as briefly mentioned in the article or resources on the subject of rf isolation/Faraday cages for microcontrollers?
Charles@turnsys.com
I have quite a collection of research material on RF cages / testing .
This doesn’t really answer your question, but it feels like it’s worth mentioning.
There are also 'premium' devkits with smaller and nicer packaging e.g. I like m5 devkits that are inch-by-inch-by-halfinch blocks at $7.5 for https://docs.m5stack.com/en/core/AtomS3%20Lite or with an integrated screen for $15.5 https://shop.m5stack.com/products/atoms3-dev-kit-w-0-85-inch... is useful for visual feedback.
If you use a bare module then you need a basic 3.3V serial adapter and maybe a jumper wire to ground pin 0 to enter programming mode.
You can also do stuff with JTAG, which will let you use a debugger, but that's not mandatory. Espressif sells a dirt cheap one. I think maybe you can use your jlink for that with some fiddling but I'm not certain.
Worth noting that this includes JTAG over USB.
For the Bouffalo Lab and Beken WiFi SoCs we already have SVD files[1] for the WiFi MAC (and likely the PHY too). Thus we have nearly complete documentation for all chip registers and their bitfields. Both SoCs are based on CEVA RivieraWaves WiFi IP.
Also you might be able to use it as a SDR for the 2.4GHz band, there appears to be registers to send ADC data to on-chip SRAM. And USB 2.0 High Speed device functionality on some of the Bouffalo chips.
I was thinking of hacking it to use as a cheap uplink to the QO-100 amateur radio satellite, which uplinks in the 2.4GHz band. I think 100mW of power might be just enough for CW or some very narrowband PSK mode.
By the way, on the Bouffalo devices, watch out for the eFuse registers, they're not fully lockable and write protectable, one wrong register write and the whole chip itself can be bricked and stuck permanently in secure boot mode. It happened to me, and I'm going to try and work around it by glitching the clock input on boot, just at the right time, to disrupt the eFuse reading, just for the fun of it.
1. https://github.com/bouffalolab/bl_iot_sdk/blob/master/compon...
Wow, that's a lot. If OP could upload somewhere the list of accesses together with a stack trace for each, I think we could crowd source a rewrite of each function - I'd be willing to bet the vast majority of those are repetitive patterns - ie. 'run this transmission test 1000 times while increasing the power levels each time until the received power = some set value'.
I have no idea what my first project should be. Any ideas?
You can even run Python on microcontrollers these days. See Adafruit's https://circuitpython.org for which they publish modules for many (almost all?) of the sensors they sell. The modern microcontroller frameworks hide much of the complexity of Wi-Fi, Bluetooth, filesystems, etc. so you can do complicated things with minimal effort. You can really cobble something together in an afternoon.
The "hello world" of microcontrollers is making an LED blink. Then figuring out how to print a message out over serial (print debugging is invaluable). Then maybe figure out how to make a Wi-Fi connection and an HTTP request. Then go on a shopping spree on Adafruit or SparkFun for $9 sensors that spark your imagination and figure out how to talk to them; Adafruit publishes zillions of tutorials you can copy from: https://learn.adafruit.com
Then, connect an RGB LED and experiment with PWM signal generation.
Then, experiment with network programming, accepting a UDP packet to the ESP32 that sets the color of the RGB LED.
I wrote lots of easy to follow tutorials there.
It depends a lot on the sensors you have. That said, even without any (or few) sensor(s) you can still have fun with network related applications like a Telegram bot.
Have you tried just replaying those 50,000 accesses and seeing if things work? Obviously some things might not be correctly calibrated, but merely knowing that a simple replay works tells you that there are no complex hardware/software handshakes (ie. Take random token from here and write it to there). It also tells you that the process is probably fairly timing independent.
Admittedly, this is a non-issue for hobby scale projects, but is potentially a blocker for commercial applications.
I wouldn't say it's necessarily a bad thing, but worth discussion.
MAC is at OSI Layer 2. FCC concerns about radio power occur at the PHY layer, OSI Layer 1:
> On the ESP32, the PHY layer is implemented in hardware; most of the MAC layer is implemented in the proprietary blob. One notable exception to this separation is sending acknowlegement frame: if a device receives a frame, it should send a packet back to acknowledge that this packet was received correctly. This ACK packet needs to be sent within ~10 microseconds; it would be hard to get this timing correct in software.
* https://pics.zeus.gent/vYXyQm2t9pJCzpDdWFvq9oWR2DACoUJoTsYf8...
But the closed radio parts are indeed horrible. Qualcomm (US Intelligence) and Broadcom (Chinese intelligence) controlling the physical layer underneath is as disturbing as the various Intel, AMD, ARM backdoors in their pre-OS layers.
(sprite_tm works at Espressif)
https://docs.espressif.com/projects/esp-idf/en/v4.3/esp32/ap...
I'd be very surprised if there's not an exploit that will get the CPU to barf up the full ROM contents. That's if there isn't a more direct way to read it.
Even in the extremely unlikely case that it can't be read programmatically, you can always physically decode it with a microscope and a working eyeball.
From there, it's "just" a matter of decompiling the machine code into something readable. It's not trivial, but it can be done by a single person in a reasonable timeframe.
How long did it take you to get the environment and tools set up, so you could start digging in?
Is time or money a more valuable investment at this stage? If it's not too forward, how much would be useful to your organisation? (I can email if preferred.)
