Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unveiling secrets of the ESP32: creating an open-source MAC layer

zeus.ugent.be

Post reply on HN
Print view View original

131–140 of 157 posts

Re: Unveiling secrets of the ESP32: creating an open-source MAC layer

#131

Post by gh02t »

seba_dos1 wrote: post #56
gh02t wrote: post #50

Earlier quoted context omitted.

They have a built in serial bootloader. Most dev boards don't need anything, they come with a USB-to-serial adapter. Some of the new ones even have the USB part integrated on chip. 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 s…

> Some of the new ones even have the USB part integrated on chip. Worth noting that this includes JTAG over USB.

I haven't tried the newer ones with USB support since I have a literal stack of older ESP32s to get through for projects, how's support for JTAG/debugging over USB in the common environments like ESP-IDF/Arduino/Platformio/etc? If it's not a hassle to get it set up then I might have to pick one up to develop on.

Re: Unveiling secrets of the ESP32: creating an open-source MAC layer

#132

Post by PeterisP »

zlg_codes wrote: post #43
PeterisP wrote: post #34

Earlier quoted context omitted.

We're talking lighter than minihttp and shizaru - instead of a separate process on an OS, you'd use library that allows your firmware to respond to http requests, but that still allows you to run all the relatively complex UI/UX code on the user's computer or phone, with the microcontroller only handling the physical functionality; and reduces the need to have and manage more physical buttons/lights/screens/etc on th…

Oh, that's pretty neat. Basically trimming the server down to the routing itself. 1. accept HTTP 2. check for valid endpoint 3. if yes, do thing and exit 4. if no, 'error' Client side has fancy UI for essentially templating per-HTTP request or command sent to the device. I guess the only issue I see is you'd need some sort of firewalling or security. Otherwise any rando could fire HTTP requests at the thing and make…

You generally don't structure it as having a webserver, you'd structure it as an app (you run a single app on the device, there's no separate OS involved) that can react to HTTP requests - i.e. my mental model is that you don't run a webserver on the device, but instead that the device becomes a webserver.

You can structure the on-device app as 'slaved' to the web requests, where it simply waits for requests in a loop and only does stuff in response to a request - for example, take a measurement from some sensors and send them back with some surrounding HTML.

Authentication/authorization is an issue, but it has all the same issues and solutions as webapps - login+session cookies; or whitelisting IP ranges; or TLS client certificates; etc.

Re: Unveiling secrets of the ESP32: creating an open-source MAC layer

#133

Post by helpfulContrib »

lannisterstark wrote: post #85
mardifoufs wrote: post #72

Earlier quoted context omitted.

How are the two not equivalent? If anything, for anyone living in the west it's probably less of an issue to have China spy on them than a western government. Sure, at a state security level it's not but for regular individuals I sure would rather have China spy on me since they can't do anything to me directly.

You have at least some civil rights in those countries, you don't in China. Be careful of a layover.

[dead]

Re: Unveiling secrets of the ESP32: creating an open-source MAC layer

#134

Post by 127361 »

I think Espressif have or at least used to have their own in-house developed MAC and PHY, which is not publicly documented.

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...

Re: Unveiling secrets of the ESP32: creating an open-source MAC layer

#135

Post by 127361 »

finnjohnsen2 wrote: post #13

I wasnt aware of this wifi blob. This feeds a tiny paranoia I have at the back of my head when dealing with esp32/espressif. I have dozens of esp32s around and I love them, but Espressif is 100% Chinese. 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…

Some old Realtek switch chips featured a protocol called RRCP[1] where you could write to the hardware registers using a specific type of Ethernet frame. So I guess a CCP-designed backdoor would probably detect a specially encrypted WiFi packet and allow then internal memory of the device to be written/read over the air. The key would be hardwired into the chip, part of the random logic - so there will be no visible block to identify on visual inspection of the die.

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...

Re: Unveiling secrets of the ESP32: creating an open-source MAC layer

#137

Post by 127361 »

jcalvinowens wrote: post #11
icpmacdo wrote: post #5

I can attest to the challenges of the section on Dynamic analysis on real hardware and the struggles of attenuating signal interference on the ESP. 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?

Based only on my own anecdotal experience... I think the hole the cables go through is the biggest problem in OPs setup. I'd solder the shields to the cage circumferentially around the hole. Shielded USB cables aren't too hard to find, it wouldn't be as good as something optical but it's a lot easier.

Feed through capacitors for power and use fiber for the rest?

Re: Unveiling secrets of the ESP32: creating an open-source MAC layer

#138

Post by PeterisP »

PeterisP wrote: post #127
AlotOfReading wrote: post #24

Earlier quoted context omitted.

A microwave oven is an excellent (30-40dB) attenuator specifically around 2.4GHz. The legal requirements essentially mandate 30dB + manufacturing safety margin. Your mileage will vary for other frequencies, as they're not actually faraday cages, so it's usually easier to simply use aluminum foil or a copper mesh/PVC box depending on your needs.

Thing is, 30-40dB is not sufficient to properly block wireless connections, they can still work with 40dB attenuation.

To add on to this - I just tested with my home microwave - I get 35-38dB attenuation, but I can still quite reliably get wifi packets to/from an ESP32 in that microwave.

Re: Unveiling secrets of the ESP32: creating an open-source MAC layer

#139

Post by jcalvinowens »

127361 wrote: post #137
jcalvinowens wrote: post #11

Earlier quoted context omitted.

Based only on my own anecdotal experience... I think the hole the cables go through is the biggest problem in OPs setup. I'd solder the shields to the cage circumferentially around the hole. Shielded USB cables aren't too hard to find, it wouldn't be as good as something optical but it's a lot easier.

Feed through capacitors for power and use fiber for the rest?

If power was really the problem I'd just use a battery inside the cage.

Related, this is a neat experiment which powers a galvanically isolated circuit optically using LEDs and a solar cell: https://youtu.be/9JinSfCKuNQ?t=823&si=kBwesUsVgAGBVVwq

He didn't need to block RF though, the interface seems mechanically challenging to build into a cage.

Post reply on HN