The next talk will be about liberating Wi-Fi on the ESP32. Who of you likes Rust?
Who of you likes reverse engineering? Then please give a round of applause for Simon and Jasper.
They both like writing code in Rust and they love and enjoy reverse engineering. Hi.
So today we will be talking about liberating Wi-Fi on the ESP32. So this is who we are.
I'm Jasper. I'm from Belgium. And I mainly do embedded and security. Yeah. And I'm Simon.
I'm from Germany. My nickname is Rusty314159.
And I do reverse engineering and like Rust development. I also work a lot with...
With Wi-Fi and if you have any questions, there's my deck number.
You can also reach us at the site on the bottom of the slides.
So now I'll talk a bit about why we want to do this reverse engineering.
So we want to follow the original hacker ethos of making hardware do things it was not supposed to.
Because the Wi-Fi hardware on the ESP32 appears to be very flexible.
And there are a lot of use cases that are possible but not covered with the official expressive SDK.
For example... There is mesh networking in the ESP32 SDK.
But it's not interoperable with other mesh networks and it only supports a tree topology.
So we can do proper 802.11s mesh networking. But the SDK does not have that.
Simon here is also working on implementing Apple wireless direct link.
And someone even recently joined the chat and told us they are working on reverse engineering the Nintendo DSI PictoChat implementation.
Which is pretty funny. Using the ESP32. And then another reason. Security auditability.
The Wi-Fi stack has a very large attack surface. But the binary blob is not really auditable.
And then a final reason to reverse engineer this hardware is to allow using the Wi-Fi on other programming languages or other real-time OSes than the C slash pre-ethos that the ESP32 SDK ships with.
So this gives us... This gives us a lot more flexibility.
So now I'll talk a bit about what the ESP32 is. It's a very low cost Wi-Fi microcontroller.
It was made by Espressif in 2016.
But it's actually like a series of microcontrollers with a lot of different variants.
And these are indicated with the suffixes that follow after the ESP32.
So it's a bit like the STM32 ecosystem. There's not a single STM32.
But there are a lot of different variants. For example, there's like this RISC-V variant.
That's a lot of different variants. That also supports the 5 gigahertz Wi-Fi, the ESP32 C5.
But confusingly enough, there's also an ESP32 variant without a suffix.
And that was the first one to be released. And that's what we'll be talking about today.
So our work really only covers this one specific variant.
The radio hardware is pretty similar on other ESP32s we saw. But we don't support them yet.
And they're very popular amongst makers and engineers because of their low cost, but also because of their very good SDK quality.
And there are a lot of examples as well.
And the entire SDK is open source, except for the Wi-Fi and Bluetooth blobs.
So it's pretty nice to work with. Okay. So now I'll quickly get into what is Wi-Fi.
Wi-Fi is just the marketing term for wireless local network technology specified in IEEE 8.2.11.
It's very widely used. And probably everyone in this room has a device that's currently using it.
Topology-wise, it's very similar. Similar to Ethernet.
It's actually from the same family of standards, so the IEEE 8.2 standards.
And Ethernet is specified in 8.2.3. And just like Ethernet, Wi-Fi specifies layer 1 and 2.
However, unlike Ethernet, Wi-Fi does not use wires for communication.
It instead uses radio communications. And therefore also uses a shared medium.
Also it operates on frames like Ethernet.
So blocks of data that are transferred between the different devices. In this case, over radio.
I'll just advance this. How Wi-Fi works on the ESP32. This is a diagram I made.
It's just the hardware of the ESP32.
And on the left, you have the antenna, which is connected to the RF front end.
Which does all of the high-frequency stuff and converts the digital signal that arrives from the baseband to an analog signal and in reverse for receive.
And you have the Wi-Fi baseband, which is labeled 8.2.11 baseband. And the Bluetooth signal.
And the Bluetooth baseband, which then generate the modulated signal in a digital way.
And these again interface with the medium access control for the specific protocol which handles the lowest layer of that protocol.
So it also does time-sensitive tasks.
So for Wi-Fi you have acknowledgments which need to be transmitted in 10 microseconds.
And that's just not something you can do in software, at least with that microcontroller.
But that's just the way it works. Bluetooth is just listed here for completeness.
We have not reverse engineered anything with Bluetooth yet.
Although Antonio Vasquez is actually working on that.
So we may see something for that in the future.
And the current situation on the ESP32 is Espressif ships a closed source Wi-Fi stack.
The upper parts of it, so they actually implement the protocol, are taken from FreeBSD.
And Espressif ships binaries licensed under Apache.
So these are just static libraries that are precompiled.
And an API to those binaries is exposed in a public header file, which is well documented.
And the stack really works well. We have to give that to them.
And they license the hardware from Riviera waves, which is now known as Sava waves as far as we know.
Which is also a hypothesis why they cannot publish any of this, because they're likely bound by an NDA from Riviera and therefore can't publish any of the code.
But apparently, they can publish. They can publish.
They can publish the libraries under Apache, which means that we can legally reverse engineer it.
And they actually confirmed this to us. And yeah. Yeah.
So now I'll talk a bit about our reverse engineering work.
So for this, we used basically two methods, static analysis and dynamic analysis.
Static analysis is where you have the code and you decompile it.
So you look at the decompiled code.
And dynamic analysis is where you run the code and then see what it does.
So what registers it tries to do. And then the dynamic analysis. We split it up into two parts.
We can do this both on the hardware, so on the real ESP32, as in an emulator.
And you'll see later why we would want to do that.
So I'll first give a bit of an introduction to hardware reverse engineering.
So how does the CPU interact with the Wi-Fi hardware on the ESP32?
Well, this happens via memory maps I.O.
So certain ranges of the address space on the ESP32 are not backed by RAM or ROM, but are instead used to interact with all the peripherals.
Okay.
So, for example, by writing to a certain address, you can set the MAC address that the ESP32 will receive packets for.
And the memory map of the ESP32 is published in the data sheet.
But there are some entries there that are just marked as reserved.
So they don't tell us what's in it.
But it's likely that some of these are used for the Wi-Fi hardware.
And we will call such memory addresses hardware registers.
And our goal is to figure out what each hardware... . ...to implement a Wi-Fi stack.
So for static analysis, we used Ghidra. This is an open source tool released by the NSA.
And it disassembles the assembly that is shipped in the binary blob to sort of pseudo-SA code so it's easier to read.
And you can see on the slides there an example of what the code disassembles to.
I know it's still not really readable, but it's a lot better than looking at the assembly.
Also, Ghidra now has mainline support for... ...which is the instruction sets.
And this was not the case when we started the project... ...then you had to install some obscure plug-in.
But now it's a lot easier to get started.
And also, Espressif did not strip the function names which is real nice of them.
Because now we have a very sort of basic description of what each function does.
And based on that, we can deduce what the hardware registers do. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
And based on that, we can deduce what the hardware registers do. . .
. A second approach, we happy different primary or secondary.
have is dynamic analysis, now we'll do that on real hardware, so we compile some code,
for example, it connects to an access point, and then we can place break points in the
interesting functions we discovered while static reverse engineering and see what values
get passed to them, what pointers get passed to them, for example, and we can then also
call these functions ourselves and see what the hardware does.
For example, we can use the JTAG debugger, we can set break points in functions, and
that gives us an inside look of how the functions work.
The problem is we can use Wi-Fi dongle and monitor modes to receive the packets in the
area, even packets that are not Nuzen for the Wi-Fi dongle by putting it in monitor mode.
The problem with that, in a big city, there are other покet that are not doesn't...
lot of other Wi-Fi devices nearby, so you receive all of those packets as well, and
that's really annoying because then you don't know if you maybe sent one packet on the ESP32,
but there are tens of thousands of other packets. You don't know if your ESP32 sent something
or not. And for this, I built a Faraday cage. The problem is, yeah, so this Faraday cage
insulates all the signals from the outside from the signals from the inside. Many people
suggested just put it in a microwave and don't turn it on. Very important. The problem
with that is it's actually very leaky. If you put your phone in a microwave and you
call it, it still goes through. If you ping it over Wi-Fi, it still goes through. So this
microwave approach really does not work. So I built a Faraday cage myself. It's an outer
wooden protective shell, and then on the inside, it's a wooden cube covered in conductive fabric.
And you can see on the door there's conductive fabric as well, so it goes against each other
and then it seals perfectly. The problem is then that you don't have any communication
to the inside, and you can't use wires because the RF will couple into the wires and then
get into the inside. So I solved that with using a fiber optic cable and then converters
on the inside. And then the second problem is how do you get power inside? For that, you can use a
very expensive
RF filter. They use it in hospital MRI rooms to get power in. But the problem is even second
hand, these are very expensive. So I just put a big car battery inside, and that works
as well. And the total cost is only 300 euros. So if you compare it to Faraday cages of this
size you can buy off the shelf, it's like ten times less expensive. And then we also
did dynamic analysis in an emulator. Because the dynamic analysis is very expensive, we
did dynamic analysis on the device, it works, but it has some drawbacks. For example, you
can only place two breakpoints, and it's hard to follow the entire execution of the binary.
So if we would want to get a trace of what values get written to what hardware registers,
we would have to single step the entire device, and that would be very slow. But luckily for
us, Espressif has, which is a popular open source emulator, and they added support for
the ESP32, but not for the Wi-Fi hardware. And then, luckily, it worked. And then we
again, for us, there was a fork of that fork that added some very basic Wi-Fi functionality,
just enough so that the emulated ESP32 could connect to virtual access points. So we worked
further on that, and we added some logging, so for every access to a Wi-Fi peripheral,
it gets logged to a file. And then I also implemented execution tracing, so every time
it writes to a Wi-Fi hardware register, it stops the emulator, and then it gets logged
to a file. It saves the entire call stack also to a file. So you can see from which
functions which hardware registers got accessed. This was not trivial to implement, because
the Extensa instruction set has windowed registers, so the call winding is a bit hard
to do, but luckily I could peek at the Linux kernel for this. And then, as you can see
in this table, every method has its tradeoffs. For example, the emulated hardware is not guaranteed
to be correct, because it's just based on what assumptions that we made for the hardware
that it would do. Now I'll talk a bit about the results that came from it. So in general,
the hardware does a lot of the work for us. We only basically have to configure the hardware,
and then it will handle the entire RF part for us. So in the next slide, I'll give some
examples of that. So if you want to transmit a Wi-Fi packet,
you save the packet contents to memory. You write some data about how you want the packet
to be sent. So, for example, how long your packet is and at what rate, so what modulation
you want it to use. You also write that to a hardware register. And then you write the
address of where you saved the packet to a hardware register, and you say to the hardware,
okay, now you can transmit it, and then the hardware will wait for a transmit opportunity
for you, so you don't have to busy loop for that. The hardware will just handle it. And
it will also wait for an ACK packet. It receives back, and then it will give you an interrupt,
so you don't have to keep pulling. It's just very async. And then receiving packets is
also very asynchronous. You set up a linked list, and every node points to the next node,
and every node also has a pointer to a buffer where the packet can be received in. And
then you can say to the hardware, okay, now you can start receiving. And every time you
receive the packet, it will save it in the head of the linked list, and it will throw
an interrupt. And then from that interrupt, you can signal your Mac task that it can process
the packet, and the Mac task can do it at its own tempo, because the WiFi hardware
will just write to the next entry in the linked list for the next packet it receives.
And it's very important that after the Mac task is done, processing a single packet,
that it then recycles the buffer. Otherwise, if you would keep mallocking and freeing,
a buffer each time, it would put a lot of pressure on your memory allocator.
And then another thing is that the standard mandates that if you receive a packet, you
send an ACK packet back in a very narrow time frame. I think this is like 10 microseconds.
So it's almost mandatory that the hardware does this instead of the software. Luckily
for us, the hardware does it instead of the software. Because the WiFi interface has
received filters. So the problem is also if you have to process every packet.
On the air, that you will get a lot of interrupts, and you will waste a lot of CPU time handling
packets that you're not even interested in. So the hardware allows us to set receive filters
based on the Mac addresses in the packets. And then the hardware will only pass packets
to software that matches those receive filters. It also automatically sends back an ACK to
the transmitter address of the frame. So you don't even have to do that. And in the past
week, we also began reverse engineering the cryptography acceleration that is used in
protected networks, so for example, WPA networks. The hardware also does that for us because
every packet needs to be encrypted and decrypted. So you basically have to store the key that
you want to encrypt the packet with, the algorithm that is used, any Mac address, and
then the key index in a key slot. And then when transmitting, you can just tell the hardware,
okay, use this key slot, and it will encrypt the packet.
For you before sending it. And this is nice, because then we don't have to implement this
part of the cryptography stack. And then when receiving, it will match the Mac address that
you saved in the key slot. It will look for a key slot that matches that Mac address,
and it will then automatically decrypt the content of the packet before you receive it
in user space. So as a summary, the hardware interface to software seems very well designed,
and it's very suited for the user.
Okay. So now that we know how the hardware works, we need a Mac stack. So the upper part
that handles the more complex protocols of Wi-Fi-like encryption. And the obvious choice
would be look for an existing implementation. However, there are not really any portable
stacks. They are always bound to their host environment. And the stack is adapted from FreeBSD.
So we could
go and use the one from FreeBSD, or the one from the Linux kernel, Mac 802.11. But those
would be hard to port and are more geared towards host environment with a bit more resources
than 520 kilobytes of RAM. But writing our own Mac stack would be a ton of work. So that's
what we did.
And this is Ferris on Air. It's an asynchronous IEEE 802.11 stack written in Rust. It's open
source. You can find it in the GitHub organization of ESP32 OpenMAC under the name FOA, which is
just the short term I will use for now. And it only supports the ESP32 for now, because
we have not reverse engineered any other chips yet. And it uses a modular interface design,
which allows us to implement the different operating modes like access point, station,
mesh, independently from lower parts of the stack. For now, we only have a station interface.
But we have more to come. So the ones that we listed in the talk announcement, we know
those are possible on the hardware. And we have already started on AWDL. But AWDL is
not yet usable directly.
And in the OSI model, FOA lives sort of on layer 2.5. So at layer 1, you have the hardware,
which is the Mac and Baseband peripheral, which generate the RF signal and do some parts
of layer 2. And
Directly on layer 2, you have the Wi-Fi hardware driver, which I also wrote in Asynchronous
Rust. It has a rather simple API. You can just tell it to transmit a frame, give it
certain parameters, and it will just go and do that and wait for a knock. And for receiving,
there is also a similar API. And above that, on layer 2.5, there would be FOA, which then
directly talks to the hardware driver and handles certain tasks of the upper Mac. And
the different interfaces.
The different interfaces will then usually talk to an IP stack, so the station interface,
more commonly known as client. And in this case, this would be a small TCP or as it's
wrapped, EmbassyNet.
And the architecture of FOA looks like this. It looks quite complicated, but I promise
it's not that bad. It's mirrored down the middle because the hardware has two sets of
these receive filters. So it can wait for... It can look for... It can look for...
It can look for frames from two addresses. So we basically have two virtual interfaces.
And in the background, we have the Mac task that's always running. And it will receive
every frame the hardware receives. And then take a look, is it for interface zero or interface
one? If it's for interface zero, it will go to the interface input of interface zero,
otherwise to interface one. And the interface input then takes a look at the frame again
and says, is this a data frame for a network that I'm currently connected to? If so, we
will just route it to a higher layer and that's where the story of that frame ends.
If it's for a user operation like the user set connect to this network over there, then
we route all the frames to the user queue so that user control can process it.
If it's something for background operations, so the background task says, hey, the RSI
of this network is bad, I will look for another access point from the same network which has
better signal strength, then we put it in the background queue, so it can be processed
by the interface task. Okay.
at the bottom means that the user control influences the interface task, so if the user
says connect to this network and it succeeds, then the user control will tell the interface
task that that operation was successful and we are now connected.
And the dotted red line from the higher layers to interface task basically means if the higher
layers want to transmit a packet, so an outbound packet, it will arrive at the interface task
which will then wrap it into the data frame and then pass it on to the hardware.
And a large part of FOA that's generic between all interfaces, the lower MAC, or short term
LMAC, the term is directly stolen from the proprietary stack because it's thrown around
in there a lot, and its job is to divide access to the medium between the interfaces.
The issue is that we have only one RF chain, so we can only be on one channel at a time,
even though we have two interfaces, which would maybe like to have a single RF channel.
We would like to operate on different channels, so maybe an access point on channel 2 and
a station on channel 11, which just wouldn't work, so it has to mediate that in a way.
And it's basically just a thin layer between hardware driver and upper MAC, some functions
are even just pass-throughs, and it just implements some nice features that make implementing
interface easier.
And the way it controls access to the channel is through channel locking, so the idea is
if interface 0 comes first...
Hey, LMAC, could you please lock the channel to number 1, I would like to operate on that
channel, and then the LMAC will check, is the channel already locked or not?
And if it isn't locked, then it will go, yep, here's the lock, the channel is now
locked to interface 1...
The channel is now locked to 1 by you, and the LMAC will mark it that way in its internal
state, and if interface 1 now comes around and says, hey, LMAC, please lock the channel
to number 2, the LMAC will say, no, it's already locked to channel number 1 by the
other interface. Sorry, we can't do that right now.
And then interface 0, if it disconnects at some point, it can then unlock the channel
and the other interface could use it again.
If both interfaces try to lock it to the same channel, then they can also operate on
the same channel and will both have lock on that, so they can coexist in that way. And yeah.
So for now, we've only implemented a station interface.
This means you could connect to an open access point, and here's what it can currently do.
We can connect to networks, we can disconnect from them again and process disconnects, and
we can do user data TX and RX, so if the user gives us data, so in this case this would
be the layer 3, then we will pass it on to the access point, and if we receive data,
we will pass it on to the upper layer.
And compared to the proprietary stack, what we can't do yet. It's a bit.
We can't do rate selection, for example.
Which means that we will always transmit at the same rate.
Currently it's fixed at 9 megabits per second, because rate selection algorithms are actually
quite the rabbit hole, and we might port over the minstrel HT algorithm, which is used
by the Linux kernel, and all of these features that are listed here are also some that the
proprietary stack supports, but we don't yet.
This long range mode is actually expressive specific, so this is a certain modulation
they came up with. We think it's OFDM.
That allows transmissions to distances of up to one kilometre, which is respectable.
And yeah, so future work.
Implement the features that were missing from that were listed on that slide.
Implement access point mode, and AWDL, which is the link layer for AirDrop and AirPlay.
I gave a lightning talk about that last year, and then maybe you could use an ESP32 for AirDrop.
That would be pretty cool.
And implement mesh operation, which was the reason this project was started, and it can
also be used with FTM, so fine-timing measurement, to do indoor navigation.
Maybe that's interesting for the C3NAV people.
Because we could go and put ESP32s around the CCH here, and they will then act as an
FTM responder.
And if a device can then do FTM with multiple of these other ESPs, we can then, using the
timing difference we calculate, calculate the approximate distance.
This is actually accurate to one or two metres, which is surprising.
And we can then triangulate where the client actually is.
This is a bit better than using the RSSI, which C3NAV already did.
But that would be really cool to have. So hopefully we'll have that next year.
And also, generally, apart from the Mac stack, look at other chips.
Ishwar Mudaraya already looked at the C3, so that's a RISC-V-based chip.
And the hardware always follows the same general principle, although the addresses were changed
and some new things were added.
But it should generally be doable to port a lot of this work to different chips.
Which would definitely be interesting. And yeah, we would like to thank some people.
I would like to thank SysVP, which is my hackerspace, and I would also like to thank Austin Conn.
He got the extensa merged into the NSA's Ghidra tool.
And I would like to thank everyone at the Nordangang, which is my hackerspace.
I have the big logo on the back.
And they listened to me yap about this for a while, and were just generally really great
support also in making this talk.
And I would also like to thank the Embassy and ESPHalt projects, which Embassy is an
embedded async framework for Rust. It's really, really awesome.
And the ESPHalt project, which basically ports support for the ESP32 to Rust, which
without them, I couldn't have written the driver or the upper stack.
And they were also kind enough to merge the patches we wrote for the hardware description.
So actually, we can do the entire driver. On mainline ESPHalt, which is really cool of them.
And last but not least, we would like to thank Espressif for not suing us in the first place
and just generally being really cool about this, because other companies would have already
sued us into oblivion.
And Espressif actually confirmed to us that what we are doing is legal, which is really,
really nice of them. So thanks a lot to them. And that would be thanks for listening.
Thank you so much. Suing someone into oblivion would be the perfect band name, I guess.
But we have now time for questions. But before that, another round of applause. Thank you.
This was great, all. We have now 10 minutes for questions.
I would like to start with a question from the internet, dear Signal Angel.
Yeah, the internet really liked your work. Very awesome.
I'll start with a more technical question.
Someone noted that some ESP32 models have headers for an antenna.
And whether it would have been possible to use some kind of antenna cable instead of
the Faraday cable. Yes. I actually wrote a blog post about that. I tried it out.
I used the EPEX connector on the ESP32, and I connected it with an attenuator in between,
so a 60 decibel attenuator, and then to the Wi-Fi monitor mode dongle.
But the problem is that enough RF leaks in that you still receive outside packets.
So, even if you directly connect it via a coax cable, it still leaks in, so it's not enough.
It's also, the blog post is also on the site. So, thank you. Please microphone one. Yeah.
You talked about the hardware having RX filters, so you can set which packets you're interested
in. How much of that is actually FPGA? Is it programmable? Is there microcode for it?
How much of that is actual hardware, and how much of that is reprogrammable in its own right?
Yeah. As far as we know, this is entirely in hardware, so it's not reprogrammable.
So you just get the filters you get, and then you have to make do with those.
We think they actually tested the design originally on FPGA, because in one of the static libraries,
I think it's libfi.a. Inside there, there are references to something about an FPGA.
But the Wi-Fi peripheral is actually just everything is there in silicon, and the filters
are just configurable with addresses, and that's all we can configure about them.
Next question would be number two. Yeah. Hello. Thank you again for the great work.
So, I just wanted to know, there's another project that does ESP32 hosted or running
Linux on ESP32, right? Yeah.
So, when these people do that, they get the free Linux TCP IP MAC stack, right?
So how does this effort contribute, like, how does it compare to that effort if somebody
is able to run some, let's say, Linux or lightweight Linux on ESP32, they would also
get this entire stack, right? As far as I know, the Linux was...
It was only run on the ESP32 S3, so not on the regular ESP32 yet. Correct.
So you would basically have to write a Linux driver for the Wi-Fi, and then you get the
stack for free, but the problem is that running Linux on ESP32, it's actually really not designed
for that. You can do it technically, but I don't think it's the best way to tackle the problem.
Yeah, and it still uses the proprietary stack as far as I'm aware.
And I'm not sure how much RAM you would have left over after that, because having Linux
in there would just already consume a lot of RAM, and running 4 in the default configuration
with one station interface consumes 40 kilobytes of RAM, roughly, which is a lot less than
what you could manage with Linux, but it's also... It has a lot less features for a worker. Yeah.
Thank you. Thank you for your question. I hand over to microphone three. Thank you for the talk.
Since Espressif seem to be such nice and agreeable guys, have you tried to ask nicely
for the source code? So reverse engineering through social engineering?
Yes, there was an issue opened in 2016, and they said they would eventually open source
parts of it, but as far as I see, not a lot has been open sourced yet. Yeah. Okay.
Number four, your question. How long did the whole process take you to get this far?
So I don't know. When did you start with the reverse? About a year ago. Yeah. Okay.
Because the thing is, I found the project, like, one year ago, where Jasper had already
reversed TX and RX, and since then I've been tagging along roughly.
But yeah, I think one year was... So you started with the hardware part, and then... Yeah.
And then you came along with the software, right? Yeah. Oh, cool. Thanks.
But this is not a year of full-time work, of course, because I have other things going
on in my life, unfortunately. Do we have another question from the internet? Absolutely.
Several people were wondering whether there's some kind of hardware calibration going on,
and for example, some kind of binary blob. And if so...
So how can this be done in an open source way? Yeah.
So RF in it is currently done by the proprietary blob, because the RF front end needs to be
initialized like PLL calibration and correcting phase imbalances and all of that.
That's incredibly complicated. It takes, I think, 40,000 DMA accesses, MMO accesses, roughly.
And we currently let the hardware...
The blob do that, but that is, of course, an interesting field for reverse engineering
in the future. Yeah. I can add to that.
There's this ref.ng project, which allows binary mechanical translation back to C. It's
not very mature yet, but we hope that in the future it will be possible to do part-by-part
mechanical translation back to C, and then we can use that cleanup code. Okay.
Then I would say number four again. Yeah. Thank you for the great talk.
I wanted to ask if you were able to debug the hardware Wi-Fi system or only the CPU part? Yes.
With JTAG, you can only debug the CPU, but that's already enough, because, well, it's
useful because then you can look at what registers get written to, but you don't have access
to the Wi-Fi hardware itself. Okay. Thanks. Thank you. Number three, please. Your question. Yes.
Is your hardware stack compatible with open Wi-Fi, which is an SDR-based open Wi-Fi implementation?
Yeah. I did my thesis on open Wi-Fi.
Open Wi-Fi is basically an FPGA project where they implement the Wi-Fi stack, and then for
the Mac stack, they use the 802.11 stack from Linux. So is that project compatible?
I'd say not really.
As in, there's not really an interface between the two, but the Wi-Fi part is compatible.
So the air interface works? Yeah. Number two, your question, please. Hi.
So since you were doing your work on the original ESP32, do you know if the other ESP32 chips
are using the same hardware?
And would your work be applicable to the other chips that are out there? Okay.
And the second question is, would this also then work on the RISC-V line ESP has, like
the C3 and the C6?
So it's not exactly the same hardware, but we have reason to believe that it's licensed
from the same company, and we know it follows the same design pattern with the transmission
slots, the received DMA lists. All of that is pretty similar.
It's just the C6, for example, supports Wi-Fi 6. And we, of course, don't know.
We, of course, then need to set parameters for that, and so it got extended in that way.
But it should generally be possible to at least transfer the basic functionality just over.
So that should... So do you also plan then to add a working solution for those kind of chips like
they had in your ones? In the future, definitely. Yeah. Okay. Great. Thank you.
Are there any questions from cyberspace? Yes. Please excuse me if I butchered this.
So I'll quote this very briefly. It's very verbatim.
Is the FOA bound to free RTOS, or would it also work without that? What was the first part?
Is the FOA bound to free RTOS? So it's actually not running on free RTOS.
It's running inside of Embassy.
It's more Rust-specific because we had to decide at a certain point how are we going
to make a Mac stack for this, and we decided against using C.
Because for C, we had to make a Mac stack.
C, the proprietary stack exists, and most people are just going to use that since it's
Wi-Fi-certified and all of that, and so instead I went and wrote it in Rust also because I
really like the Rust ecosystem on ESP32, and it is currently bound to Embassy because
it just uses Async, and it turned out that that was a really, really nice way of designing
a stack because with Async, you can do things so much more easily that would otherwise be
callback hell, so it's currently bound to that, yeah. We have time for one last question.
Number four. Yes. Hello.
Have there been approaches to open a chip and use die shots to find any more information?
There have been die shots, but I don't think we would get a lot of usable information from
the die shots. I think we get a lot more information from reverse engineering. Yeah.
I don't think we would really be able to use the die shots.
Thank you so much for your talk and also for your time to answer all of these questions.
Another warm round of applause for you both. Thank you. Thank you. Thank you. Thank you.