Fire and Forget Wardriving

My project consists of a wardriving platform based around the Raspberry Pi that requires no maintenance after an initial setup.

Similar projects worth following
The three critical components of my project are a Raspberry Pi, a BASH script, and a GPS module. The Raspberry Pi is attached to, or placed inside a vehicle. The bash script sets up Kismet and GPSD, and starts a Kismet server. After a user specified time period, the Kismet server is stopped, the network interface is restarted, and the RPi connects to the strongest open WiFi network (or a known encrypted one). Once a connection is successfully established a number of operations can be performed on the Kismet output file:

1. Uploaded to Wigle
2. Emailed to your address
3. Synced to remote machine using 'rsync'
4. Uploaded to FTP

Following the completion of any of these operations, the cycle begins again.

Result: a wardriving setup that never needs maintenance or human interaction, surreptitiously mapping any wireless networks you encounter and reports them to a central database, whether it be Wigle or your own server/remote machine where it is then visualized.

Here are some details:

Kismet outputs in NETXML, for visualization, the script can automatically convert the NETXML files to Google Earth compatible KML type using It was specifically designed for Kismet

"Sync" is handled via the Unix program 'rsync'. Wikipedia does a great job of explaining how it works to synchronize directories and files between two machines.

After the Kismet server is stopped, the RPi will search for the strongest open network and attempt to establish a connection, if it fails, it will proceed to the next strongest one. 

(It can also connect to an encrypted access point, like your home AP, as long as you specify the password)

Two scripts are responsible for this. You can find both in the external links section. 

1. PortalSmash written by Brendan O' Connor


If you are having trouble understanding this part, imagine the RPi has been wardriving for 24 hours, after that it stops the Kismet server and waits until the GPS reports the car/vehicle is stationery. Perhaps you get home from work, or stop at Starbucks for a coffee. The script will connect to the network, upload the day's output, and then begin collecting data again, automating the entire process. 

If it cannot connect to a network in a given amount of time, the operation will time out, and kismet_server will be restarted. The upload/sync will be postponed until next time. 

Much of the setup instruction is provided in the excellent SANS Institute whitepaper War Pi, it details installing prerequisites, editing configuration files for gpsd and Kismet and is basically just a less automated version of my project. It is by far the most detailed write up of creating a wardriving Raspberry Pi rig. 

  • 1 × TL-WN722N WiFi Adapter USB TP-Link wifi adapter with a 4dbi antenna
  • 1 × Raspberry Pi Model B
  • 1 × SD Card With operating system of choice, could be Kali or Raspbian
  • 1 × USB GPS Dongle Any one will do as long as it is compatible with the RPi

  • Visualization Platform is Ready!

    Alex Sikand09/20/2014 at 16:49 0 comments

    Hey everyone, the visualization part of my project is ready. It is hosted at my github site Right now it is just a KML file I created with Wigle's Android app. I need to figure out how to get my bash script to upload to Google Drive on a daily basis.

  • PortalSmash Integration Completed!

    Alex Sikand09/16/2014 at 05:10 0 comments

    After exhaustive troubleshooting and testing I was able to get PortalSmash to work with my code. After stopping the Kismet server to post the results of the collection, the bash script opens PortalSmash (a ruby script) in a new window. I modified the PortalSmash code to exit if it successfully establishes a connection over a known or open network. The bash script saves the PID of the newest bash process as soon as PortalSmash launches and so if the script doesn't close in a certain amount of time, my bash script can kill it and resume Kismet again. Brendan was really nice and eager to help me troubleshoot and I'm excited to share this project with him when it is closer to completion. 

    I have ordered a GPS receiver and it should be here tomorrow afternoon. I am using the GlobalSat BU-353-S4, the same receiver that was listed in the SANS Institute WarPi documentation. I considered using Adafruit's Ultimate GPS Breakout but decided to go with a plug and play solution. I also like the look of their GPS Antenna but it draws quite a bit of current and I don't know if I will need a gain boost yet.

  • Visualization

    Alex Sikand08/21/2014 at 16:28 0 comments

    Hey guys, wardriving isn't fun or useful without a way to visualize the data on a map. Instead of opening Google Earth on your personal computer and loading each KML file individually I have instead resorted to the Google Maps v3 Javascript API.

    There is going to be a large number of  KML files to be imported. I don't know if there is an option to load KML files in batches. I think a better solution would be merging all the KML files in a directory into a single one and then hosting it somewhere. That way the file can be updated with new information and new merged KML files but the name will remain the same, reside at the same address, and everytime the Javascript map runs it only has to load 1 file.

  • Just published the project

    Alex Sikand08/18/2014 at 21:30 0 comments

    Hey guys, I just published to project and submitted it to the THP contest as well as the Hackaday tip line. At this point the script checks for prerequisite programs and if they are not installed, installs them with apt. Then it prompts the user to set a number of variables like how long the RPi should continuously wardrive for, the IP address and port number to which the RPi will be sending the output files, and many others...

    The bash script then uses sed to edit config files based on user preference.

    The sync function has been completed, it is just an rsync command with a bunch of user defined variables as arguments. 

    I have decided I will be using the MUTT email client to send the logs via email. It is simple to do so, all you have to do is setup Mutt to use your gmail account and then all you have to do is call mutt, specify the recipient, subject, and the attachment file. What I am currently working on is how to make Mutt only send the most recently created output file. 

    Once I have stitched together all the different parts and have a working/tested rough draft of the code I will upload it to GitHub, watch for updates!

View all 4 project logs

Enjoy this project?



Tyler wrote 03/01/2021 at 06:07 point

An idea for you could be to tether a (if possible) burner phone with usb debugging enabled to the pi. The pi network manager will set up eth0 as Ethernet wired connection always. Never worry about connecting to the strongest open are the connection haha

  Are you sure? yes | no

turnkit wrote 10/18/2017 at 01:53 point

Please update.  Thanks for the work. 

  Are you sure? yes | no

beerone1 wrote 02/08/2017 at 11:15 point

This looks like an amazing project mate, I am very interested on how it pans out

  Are you sure? yes | no

Alex Sikand wrote 02/06/2017 at 21:21 point

Unfortunately the laptop with the code was stolen a couple years ago and I haven't had time to rewrite everything. I'll restart the project and post code to Github this summer, I'm in university and don't have a lot of time on my hands.

  Are you sure? yes | no

Birukun wrote 09/24/2016 at 23:40 point

I just came across your project - I did an update to the original Pi document you link to - I call it War Pi 2.0.

  Are you sure? yes | no

Justin Herman wrote 08/17/2016 at 23:31 point

Do you have this setup on github?

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates