Sometimes the best hacks come from the most basic of questions. In this case, [CNLohr] was wondering what would happen if he started to reduce the clock speed of the ESP8266’s Baseband PLL (BBPLL) while still trying to communicate with it. You know, as one does. The results ended up being fairly surprising, and while it’s not immediately clear if there’s a practical application for this particular trick, it’s certainly worth some additional research.
The idea here is that the BBPLL is the reference clock for the entire system, including all of the peripherals. So underclocking it doesn’t just slow down code execution as you might expect, but it also slows down the chip’s interactions with the outside world. [CNLohr] demonstrates this concept in the video below, showing how the baud rate used to view the serial output from the ESP8266 needs to be adjusted to match the chip’s frequency or else you’ll only get garbage on the line.
But what happens to the WiFi? As [CNLohr] discovered, while the center frequency itself doesn’t change, the channel width gets narrower as the clock rate is lowered. When viewed on the waterfall display of a software defined radio (SDR), the transmission can be seen “compressing” in a step pattern as the clock rate is reduced. As one might expect, the 802.11 packets become indecipherable to a normal WiFi device running in monitor mode. The signal is still at the correct frequency, but the devices can no longer understand each other.
Now it was time for another of those basic questions. What would happen if you did the same thing to a second ESP8266? Much to his surprise, [CNLohr] discovered that the two devices could still communicate successfully as long as their BBPLL clock speed was the same. From an outsider’s perspective it looked like gibberish, but to the two ESPs which had been slowed by the same amount, everything worked as expected even though the 802.11 standards say it shouldn’t.
So what can you do with this? The most obvious application is a “stealth” WiFi connection between ESP8266s which wouldn’t show up to normal devices, a communications channel invisible to all but the most astute eavesdropper. [CNLohr] has made all the source code to pull this trick off public on GitHub, and it should be interesting to see what kind of applications (if any) hackers find for this standards-breaking behavior.
If your thing is devices being forced into operations they were never intended to by particularly twisted hackers, check out our recent coverage of the USB serial adapter turned SDR by [Ted Yapo].
[Thanks to BaldPower for the tip.]
Oooooh that’s fascinating. Use all the work that has gone into wifi development to make your own independent-ish stealth wireless network the easy way. I guess you could even have both of them vary their clock speed according to a pre-shared key or whatnot so they continuously vary their bandwidth and aren’t connectable to somebody who is trying to match their clock speed by trial and error. Or would that cause other issues with connectivity?
I think to make that work properly you’d need to keep a synced clock between them. It’d be doable but cause issues with drift and such.
Aren’t wireless (and serial) protocols usually designed with some form of clock recovery in mind? In that case you wouldn’t need to match them perfectly, just close enough for the clock recovery to pick up the slack.
There aren’t a ton of independent selectable PLL options, so you could scale through it, quickly, however, I don’t know of any existing consumer hardware that would be able to hear these packets.
Next up clock frequency hopping instead of channel hopping to keep them on their toes.
Will anyone care about this „misuse“ of the WiFi spectrum? From what I understand, the only thing required for the 2.4GHz band is staying below 20dBm ERP, right? And of course staying in the band itself, which the ESPs should do, since the channel got smaller and not larger?
Has anyone messed with the PLLs on the ESP32 yet?
Yeah, I feel like you might have a hard time prosecuting this even if it was found out. It’s consumer hardware, only the software modified, it stays in its allotted frequency band and under its power limit. Would it even interfere with other wifi? Other modems would just reject those malformed packets, right?
Sounds like it might be an easy way to get around the no encrypted radio rules. I’m still skeptical but such a thing would be really interesting.
2.4 Ghz is unregulated. You can cause interference with wifi all you want if it’s not intentional. Simply using a baby monitor that’s 2.4 GHz or a microwave is enough to cause it. This reclocking is 100% legal as it’s not intentional jamming, if it causes interference at all.
This is correct, I hadn’t considered that at the time of making this video, however, I was unable to clearly measure the channel density, so that keeps me nervous.
Your only risk is violating the Wi-Fi protocol standards, which breaks your compatibility and interoperability with other devices… which is intentional in this case. :) You’re not violating the actual RF spectrum use rules in any way.
You can try this with ESP32 today. In Arduino the APB clock changes are handled for the peripherals, so Serial and others will still work as expected. It is said that WiFi requires at least 80MHz, but there is nothing stoping you from dropping to 10MHz if you wish. API is here: https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/esp32-hal-cpu.h#L33-L38
That’s of little use on the ESP8266. Only if: the PLL’s on the ESP8266 are the same as on the ESP32 and then: someone will need to reverse engineer the code from this binary blob to see what it actually does.
Lower spectrum could lead to longer range and less power used. The spectrum used probably does not violate ISM usage,so the only violation could be branding this as WIFI.
Is this at the same speed, or does it have a slower bitrate? If it’s slower, does the range increase?
Due to how bandwidth works I’d assume the bitrate ceiling would have to be slower, but I’d love to know specifically how much and if that bottleneck really comes into play at all or if it’s already running below the physical maximum for that bandwidth for other unrelated reasons.
Obviously the bitrate directly depends on the PLL frequency. So if you lower the frequency by 10% the bitrate also decreases by 10%. If the range increases depends on how the hardware handles the narrower band. When the power in dBm/MHz stays constant I would expect the range to be the same because the total output power is reduced. If on the other hand the total output stays constant ( dBm/MHz increases) an increased range may be possible.
The symbol separation gets less because the channel gets narrower while the ability for the receiver to separate frequencies doesn’t get any better, so the SNR gets worse, so both speed and range suffer.
That’s about what I figured. But is an average wifi connection constantly and efficiently butting up against its limit, or does it usually have unused bandwidth to spare? I can’t claim expertise in that area myself, only curious.
I wonder what the minimum reduction of bandwidth is to make the packets become unrecognizable to all other wifi modems and thereby drop into stealth mode. I’m going to rewatch the video, maybe he mentions this.
Yes. There’s so much interference on the 2.4 GHz band that regular wifi regularly has trouble performing even up to 20% of the nominal speed.
Obviously the bitrate is lower, as the signal occupies less bandwidth. The bandwidth reduction is the direct result of slower signaling speed. Also, you won’t see any range increase as you don’t change the filters in the signal path. I’d expect a lower SNR due to less bandwidth occupied by the signal (less power in the channel) but the noise being still the same. At the same time, the transmission is more robust because lower signaling speed has lower SNR requirements, therefore I’d expect that the range you achieve is still the same.
You can do this with many WiFi cards in a very similar way. There are actually standardized 5 and 10MHz wide WiFi systems, although they are not commonly used for consumer things. This hack will likely be physical layer compatible with them (some application layer fields will likely be wrong, but you should be able to send and receive packets).
Be careful not to exceed the power spectral density limit if there is one in your country, as you are spreading the power over a narrower band.
the 5, 10, 20 and 40 mhz wide systems likely all use the same symbol spacing you are just reducing or increasing the number of symbols that can be transmitted for each tick of the radio clock.
This technique is compressing the radio bandwidth while still keeping the same number of symbols, making it incompatible with wifi looking for the symbols at the prescribed spacing. Neat hack to make a “stealth wifi” but probably increases error rate with the symbol spacing being shrunk.
Seen another hack of the ESPs where they were coded to run in a transmit only mode for testing range. apparently using a modified wifi stack. basically it would only transmit using proper wifi frames and a receiver on the other end with a highly direction antenna could pick up an otherwise unmodified esp from about 10km away. The ESP was transmitting a video stream that was capable of working in this transmit only mode, the video codec itself would just deal with any lost data as dropped frames or macroblocking.
https://www.youtube.com/watch?v=yCLb2eItDyE
The 5 and 10MHz modes actually reduce the PHY clock. There are still 64 carriers, but with a smaller spacing. The 40MHz mode does use more tones. This allows a receiver to cover 20/40MHz simultaneously, while the oddball 5 and 10 require exclusive configuration.
You can try it with an SDR, take the gnuradio 802.11 code and halve the sample rate. An ath9k card in half rate mode will receive the packet.
Probably the ESP8266 does not have a matching pll setting for 5 and 10MHz as it was not designed for it, so you will have some oddball bandwidths…
I wonder if you could get around the bitrate and range drop simply by overclocking rather than underclocking…
Sounds like someone needs to clone the repo and try to figure out what other BBPLL settings work.
Narrower band things *might* have more range, but only if the receiver also has a narrower bandwidth. Shannon gets into more detail, but conversationally, there’s x noise power “out there” in the band and in the RF amp per root hz bandwidth. If you can make the receiver narrower, it’ll see less noise power. If the transmitter also crams all its power into this narrower band, then the SNR at the receiver *in that band* is higher than it would be if both used more spectrum.
In other words, just reducing the transmit bandwidth usually won’t produce any range gain, or stated another way, bigger link budget. That’s happening at the other end of the link.
Since most wifi implementations have a receiver bandwidth of the entire band – more than even one whole channel (yes,, I know it’s actually more complex than that depending on the abcgnwxyz version) – unless you can change that, there’s no benefit to be had, really.
Until you get to coherent spread-spectrum stuff like LoRa or other older schemes that basically fold in the noise randomly, but add the signal linearly – so noise only goes up as the square root N while signal goes up as N…
Information theory is fun and can be profitable.
This isn’t really that unexpected. If you reduce the sample rate of the ADC and DAC in the WiFi you’re basically just changing the symbol rate and hence the subcarrier spacing in the OFDM scheme. It’s all the same frames, just played back slower. Same thing as playing music at half speed. You effectively halve the bandwidth.
Not unexpected. But a neat idea, especially tuning the two radios to each other.
“even though the 802.11 standards say it shouldn’t”
Except neither of the pair are complying to the standard… It’s pretty obvious that they’ll work together if symmetrically broken.
One of the perennial problems with developing to any sort of encode/decode standard.. btdt.
If you’ve reduced the bandwidth to 1/3, could you fit two more channels in, I wonder? Is it possible to adjust the center frequency on the esp8266?
I tried briefly but was not met with immediate success. Though the BBPLL functionality is very basic, it seems the RFPLL is at least slightly more complicated.
Can’t this be used to make the ESP8266 faster? I know someone did, but there is very little information about how. I do know WiFi won’t work (similar issue as described here), but how about setting it to “turbo boost” for short bursts when doing cpu intensive tasks and then reverting it to regain WiFi connectivity?
Nice job!!! Think to use ‘else if’ in your code instead of successive ‘if’ when you check that kind of cases ;)
This has usages for some of us hamradio operators :P Because we have licenses to be in part of the wifi band. And this could lower the bandwidth foot print. Paired with promiscuous mode and also raw frames thats a full ham radio system.
Any idea how to do it in esp8266 or esp32 Arduino SDK?
Any idea how to play with such things in Arduino SDK?
https://github.com/espressif/arduino-esp32/blob/master/cores/esp32/esp32-hal-cpu.h#L38
When you drop below 80MHz, you are switching the APB frequency down
But documentation says i need to put specific value there. Can i put arbitrary one?
A practical application for this would be using to esp8266’s for a point to point connection which is immune for so called wifi jammers, a (esp8266 based) device which will disconnect all clients from an AP by continuously sending deauth packets. Normally there’s nothing you can do to prevent yourself from an attack like this, but in this case it wouldn’t work any more :)
I wanted to do ofdm for a hd video signal, but it turns out we need to used an FPGA , ASIC or other DSP boards..
Since nodemcu performs ofdm , is it possible to get the OFDM modulated signal of the nodemcu module (which is wireless) before its transmission via the antenna ? Like through any of the pins or someway?