World Wide War Drive and The WiFi Listening Device I Built

(Also with hints about what’s coming next)

For the past year I’ve been iterating and revising a WiFi listening device or devices to build a robust WarDrive rig. In doing so I could log and coordinate WiFi information in the airwaves around me to upload to the wigle.net database for Amazingly Useless Free Internet Points. The data is given to Wigle.net and the “points” are based on how much “New” WiFi is provided to them. There are a significant amount of users uploading data via their Wigle Android App and then you have rig building maniacs for WarDrive competitions and to amass the Free Internet Points and get on the scoreboard – https://wigle.net/stats . Wigle.net has a way to search and connect to find WiFi Names or BSSID details from their database that everyone uploads to and then gives a certain amount of stats based on what has been seen (WEP, WPA, WPA2 Etc details)
(I just recently broke the top 100 and I have set an ambitious goal for the balance of the year and beyond.)

This specific write up will be about where I ended up in a more final design and conclusion while referencing some of the iterative builds along the way.

Meet Ferris (Accompanied by Sloan and Cameron)

Parts List:

• 16 Alfa MediaTek ACM WiFi USB
• 1 Hak5 WiFi Coconut
• 3 StarTech 10 port 12v USB Hubs (Sourced Amazon)
• 2 ZIMA Board Single Board Computers (still on pre-order, availability limited)
  (With a SATA SSD each)
• 2 NUC-UPS Regulated and battery back up 12v UPS (Sourced Mini-Box)
  (1 for NUC and 1 for both ZIMA Boards)
• 1 Mini-Box 19v Regulated supply for the Intel NUC(Sourced Mini-Box)
• Fuse Break out box for power distribution (Sourced Amazon)
• 12v wide range input regulator for USB Hubs  (Sourced Amazon)
• 12v Temp Sensor Fan Controller (Sourced Amazon)
• CradlePoint IBR200 (Cellular Router) (eBay)
• Netgear 5 Port Gigabit Switch (random parts box box in garage)
• Mounted inside a clear hinged junction box from Amazon sized: 510x410x200mm
• USB GPS GM-3N
• 2 Yagi eBay 2.4Ghz Antennas (Sourced via eBay)
• (5) AccelTex (ATS-00-245-46-6RPTP-96) (Sourced via eBay)
  6 Element, 2.4-5.8 WiFi Antenna with RP-SMA and 96″ length cables.

Car “Upgrades”

• Optima Cell Battery – Yellow Top
• Automated Relay for Dual Charging/Cut Off of Second Battery
• LED Driving Lights

Software BoM:

• Ubuntu Server OS 22.04
• Kismet Wireless
• SuperVisord
• GPSD

The Discord Groups are Key to my success and their help and support is only how I got here. Links on their respective pages;
KismetWireless
RF Hackers Sanctuary

WiFi Channel Planning

In the 2.4Ghz range of WiFi, we have channels from 1-14 (globally) and mostly 1-11 used in the US. Channels 1,6,11 are the most commonly used and most separated without any overlap of each other give these channels the best availability for least interference.

The WiFi 5 and WiFi 6 are more difficult for me to articulate however the channel ranges and widths are much larger than that of the 2.4Ghz WiFi 4 and therefore we need to start breaking down the channels we will scan and sort out which adapters will do which and to then also sort out how Kismet Wirless will hop across them.

Here is a screen shot of a single Kismet Wireless Source where it provides all channels available:

When we move into the WarDrive Only Configuration of Kismet Wireless we can reduce these channels greatly;

This reduced level of channel management will be more manageable – because in WarDrive mode – we are only logging and capturing the Over The Air beacons of SSID /BSSID names being broadcast. This is a killer reduction of data management and processing and truly changes the game for lower powered devices like the RasPi – showing you can do a lot with a lot less now.

Now we review how many WiFi remote sensors we will have;

Knowing we have a breakdown of 38 channels of WiFi to monitor, with 16 WiFi radios and a Coconut – we can split all the 5Ghz channels against the 16 radios and then allow Kismet Wireless to load and manage all the 2.4Ghz channels via the Coconut. Check out the Kismet Wireless work the Hak5 Gang here in the docs.

The Hak5 WiFi Coconut under Kismet Wireless doesn’t show or give us information about the channels its covering – we know its doing 14 channels and allowing Kismet Wireless to handle the 14 until 1 adapter source – allows for better handled resources.

Configurations & Setup

In the previous WarDrive Rig– Kismet Wireless was running on the RasPi and doing ALL of the processing work – check that link for some of the configuration for GPSD and the Kismet Wireless installation. Learning about Kismet Wireless remote sources turned this whole performance and thought process in a 180.  Read about that here on the Kismet Wireless Docs Page. Thanks to Dragorn of https://twitter.com/KismetWireless / www.kismetwireless.com for beating that into me…

Kismet Wireless config on the primary PC – the Intel i7 NUC is located in the ‘kismet_site.conf’ file – https://github.com/busysignal/FerrisWarDrive-Configs.
This configuration file handles most of the override functionality. I still am not clear on which overrides which when dealing with the “WarDrive” override however I believe that when launching Kismet with the –override wardrive function, it will read the wardrive.conf file, and use those settings over the other settings in the kismet.conf and kismet_site.conf.

 

This configuration allows for the ZIMA Boards, to capture only the WiFi Traffic they can see, for their configured channels and SEND it to the NUC which has a more powerful CPU and more RAM and with a faster SSD. The examples on the Kismet Wireless page explain that process, however with 6 Wireless cards on each ZIMA Board an answer was needed to understand how to control 6 streams as a daemon process. The Kismet Wireless Discord came to the rescue and Zero_Chaos suggested supervisord.

We need to put two of these together, first we test the Kismet Wireless Source Capture and Forward command:

kismet_cap_linux_wifi –connect 192.168.10.250:2501 –user ferris –password wardrive –source=’wlxzzzzzzzzzz:name=sloan_wlan1,channels=”60,116″‘

This is incredibly well documented and broken down in the Kismet Wireless docs – just a quick overview we have the following items;

• kismet_cap_linux_wifi = actual command
• –connect 192.168.10.250:2501 = kismet server and port
• –user ferris –password wardrive = the User and Password for that Kismet Server (set in your config file, or set when you first log into the Kismet GUI)
• –source=’wlx00c0caae63b9:name=cameron_wlan1,channels=”60,116″‘ =
  • The Wireless Adapter Name the OS Sees,
  • The NAME you want the adapter to show up as the Kismet Wire Sources UI
  • The channels we want it to scan on
• (Again, this is all heavily and well documented on the Kismet Wireless Docs Page)

We will need 1 of these for each WiFi Source you have connected and want to send to the Kismet Server.

Combing the Kismet Capture source command line into something that can more easily be controlled with a system process is where SuperVisor comes in. The installation and process is on their site and I would rather NOT just re-document that – so after it is installed – we need to set up the Kismet Wireless Sources into a config file so SuperVisor will start and restart them as needed.

In the supervisord.conf I left most everything default;

[program:kismet01]
command=/usr/bin/sudo kismet_cap_linux_wifi –connect 192.168.10.250:2501 –user ferris –password wardrive –source=’wlxzzz:name=sloan_wlan1,channels=”60,116″‘
autostart=true
autorestart=true
startretries=9
numprocs=1
startsecs=5
process_name=%(program_name)s_%(process_num)02d
stderr_logfile=/var/log/supervisor/%(program_name)s_stderr.log
stderr_logfile_maxbytes=10MB
stdout_logfile=/var/log/supervisor/%(program_name)s_stdout.log
stdout_logfile_maxbytes=10MB

This is then repeated for as many more times as I had adapters, with each command being adjusted for the wireless adapter name.
Check out the full example file: https://github.com/busysignal/FerrisWarDrive-Configs

“The Question Isn’t,
‘What Are We Going To Do?’
The Question Is,
‘What Aren’t We Going To Do?'”
— Ferris.

The final breakdown results in the two ZIMA Boards running Kismet Wireless Remote Sources sending data upon start up via the supervisord system process where the Primary Kismet Server receives and breaks down the packets based on the configuration.

When just plain old WarDriving for Wigle Points – I am running the Primary Kismet Wireless process with the WarDrive override mode. This reduces wicked packet manipulating by dropping what it doesnt  need and keeping what it does need for the Wigle.net database.

The WarDrive rig contains a cellular router and this is for a few different tasks. It 1 allows for the individual computers to connect to their remote management server, get updates while I on the road if needed, provide local WiFi in the car for remote monitoring the systems via a tablet, while last but not least, uploading data, while on the road, during breaks and restarts to get data to Wigle.net to not have to do so later, or to get data into the wigle.net to not miss a cutoff like the end of a contest.

Shout out to @PanicAcid for their manipulation of a script from @elkentaro where you can automate this with the use of the Wigle.net Tokens and your account.
Check that script out here: https://github.com/panicacid/BabyDriver/blob/main/shutdown.sh .