Advertise Your Conference Schedule Via SSID

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.

11 thoughts on “Advertise Your Conference Schedule Via SSID

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

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

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

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

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

Leave a Reply

