Whether it’s been a Python script running on a Linux box or an ESP8266, abusing using WiFi SSIDs to convey messages is hardly a new trick. But for DerbyCon 2019, [vgrsec] wanted to do put together something a little unique. Dare we say, even useful. Rather than broadcast out SSID obscenities or memes, this Raspberry Pi created fake WiFi networks that told everyone what talks were coming up.
The concept here is fairly simple: there’s a text file in /boot that contains the truncated names of all the talks and workshops in the schedule, one per line, and each line starts with the time that particular event is scheduled for. The script that [vgrsec] wrote opens this text file, searches for the lines beginning with the current time, and generates the appropriate SSIDs. With the number of tracks being run at DerbyCon, that meant there could be as many as five SSIDs generated at once.
Now in theory that would be enough to pull off this particular hack, but there’s a problem. The lack of an RTC on the Raspberry Pi means it can’t keep time very well, and the fact that the WiFi adapter would be busy pumping out SSIDs meant the chances of it being able to connect to the Internet and pull down the current time over NTP weren’t very good.
As the system was worthless without a reliable way of keeping time, [vgrsec] added an Adafruit PiRTC module to the mix. Once the time has been synchronized, the system could then run untethered via a USB battery bank. We might have put it into an enclosure so it looks a little less suspect, but then again, there were certainly far more unusual devices than this to be seen at DerbyCon.
Of course, if you’re OK with just dumping the entire schedule out at once and letting the user sift through the mountain of bogus SSIDs themselves, that’s even easier to accomplish.
A 2EUR ESP8266 wemos would be better. You can even get the original ESP01 (a pain to flash and to power) for 1EUR those days.
And no need of an internet dependency to get the time, a static list is fine. At least if your list of talks is not too long.
See also:
https://github.com/spacehuhn/esp8266_beaconSpam
Agree with the ESP8266, but perhaps the Pi has other tasks as well. There are handy ESP01 adaptors on Aliexpress etc.
NTP works like a PLL, there is no need for a continuous Internet connection to supply accurate time
Just something to keep in mind when abusing ssids like this. Wifi beacon frames are transmitted at the slowest supported rate so that they may be heard by the least capable of client devices. As a result, they consume a meaningful amount of the RF bandwidth. It’s probably a good idea to increase the beacon period to at least 1 second, especially when transmitting multiple ssids. Several dozen dummy ssids at 100ms could really bog down wifi performance for everyone on that channel.
Additionally, transmitting that many fake ESSIDs makes it difficult to for user choose the correct one…
But to be fair, this is DerbyCon, no wifi network is the correct one :P
Has anyone tried to see what would happen if SSIDs were broadcast at faster rates? (I recall 802.11n has a “greenfield” mode that throws legacy compatibility out the window.) Does it prevent even newer devices from seeing it?
Devices incapable of understanding the beacon due to incompatible rate/encoding will still “receive” the broadcast, but will simply interpret it as noise rather than anything meaningful. Devices that support the encoding should be able to decode it.
Where I can, I set my access points to 802.11n or AC only. Should give you a few % of bandwidth.
SSID transmission is at the lowest possible data rate and takes up valuable air time. This is poison for any high performance wireless network.
At the Chaos Communication Congress running wireless networks is discouraged.
would this cause a lot of RF noise?
A 100ms beacon period at 1Mbps 802.11b uses up maybe about 4% of the RF channel. It’s not noise in that receiving devices can decode it, but it is “noisy” in that it’s eating up bandwidth sending a very small amount of static data.