Wardrive of 250 KM with Raspberry Pi and a Phone

A while back, I had to attend a family function, for which I had to travel ~1000 KM (~620 mi). I came up with the plan of doing a drive along the way.

If you don't know, I particularly like wardrive. There's no reason for it. I just like it. Previously, I've managed to build a technique of incorporating a Raspberry Pi and a Phone for Wardrive. I agree that apps like Wigle allow users to drive just with their phones, but having control over the code gives you flexibility in what you want to do with data.

Backstory

I had to attend a family function that was to be held in the national capital of India, New Delhi, and I live in the state of Muzaffarpur, Bihar (India). It was planned that I would go from Muzaffarpur to Patna by car and then from there to New Delhi by train (yeah, we have trains here more than flights). The overall route was expected to be ~1000 KM (perhaps more; ~620+ mi).

The idea of doing wardrive appeared in my mind randomly a few days before travel. Previously, I had written a blog on doing a wardrive with a Raspberry Pi and a mobile phone, so I was sure that I would be doing that again. But this time, I wanted to do something different.

The idea was to incorporate NodeMCUs (ESP8266) as WiFi login workers. Basically, it meant that these NodeMCUs would try to log into WiFi networks with common a password, i.e. 12345678. (the handshake capture attack could also be done, but it would require me to stop and let the handshake be captured). I had read about some similar stuff in the past, so I wanted to recreate it. Perhaps this is the article I read: War-Driving Technique Allows Wi-Fi Password-Cracking at Scale.

This meant that I had to get several NodeMCUs. At that time, I had two. So, I ordered one more from Amazon.

Now, came the task to design an algorithm for this.

The new algorithm

Since I already had the software to map all WiFi APs to the map, I needed the software that would attempt to log into those networks. I decided not to use the Raspberry Pi to attempt to log into those networks because I also wanted to monitor the status of what was going on. Using RPi as a login worker would mean that I could lose wireless access to RPi if it always kept switching between WiFi networks (I could connect to it through ethernet, but I wouldn't have that during travel).

Now, it was time to find a way to integrate the RPi and NodeMCUs. Here also, I had two options

• With NodeMCU, try to log in to a network and get the status (true or false if the password was successful). If true, connect to the Raspberry Pi's WiFi network and then send the status through HTTP/Plain TCP/some other protocol

• With NodeMCU, try to log in to a network and get the status (true or false if the password was successful). If true, transmit the data over a serial connection (i.e., through a wire)

Out of the two, the second one seems more logical as I could save a few seconds on the transmission of data, which is crucial when in a fast-moving vehicle.

I also added a function to blink the onboard LED of NodeMCU whenever it tried to log into a network. This allowed me to know that it's working without SSHing into the RPi.

In total, I had 2 NodeMCUs then. When I did some simple calculations, I found that this was very slow. So, I ordered another NodeMCU. Though the calculations suggested these weren't enough, I still decided to go for it. I also wrote a LinkedIn post for it.

The Failed Attempt

Now, it was time to go for the trip. I did some basic testing from inside my home to check if it cracked the networks or not, and it worked fine. I packed everything in my bag and went on wardrive.

Over 100 KM passed, and everything seemed fine. When I SSHed into the RPi to see what data had been logged, I found that it did log WiFi networks, but there was no run log for the login worker. This was the major failure in my wardrive. The major change in this attempt was this component, and it failed.

I wasn't able to do a proper investigation as I had to reset the RPi for some other project, but the issue I assume is that the NodeMCUs went out of range of the network in a fast-moving vehicle, and it didn't get enough time to capture the response.

Plotting the available data

Though the login worker component failed, I did have the GPS and WiFi data available. So, I followed the steps that were mentioned in one of my previous articles.

I failed another issue in this dataset. When I ran the code to merge the GPS and WiFi data, I found that I didn't have GPS coordinates for a few WiFi networks. The reason for this is that I didn't start the GPS tracker when I started the wardrive code. Unfortunately, I had to remove them completely from the final dataset. After fixing this issue, the KML file was finally generated.

When I generated the KML file to upload to Google My Maps, it showed me that the file was either too large or incorrectly formatted. I tried to fix the 'file too large error'. To do so, I used the split command to split the main file into several chunks

split -b 700k wifi-ap.kml chunk_

After running this command, I manually adjusted the XML format by including the header and footer and adjusting the block for each network. I got the same error again, so I repeated the process again to make it even smaller.

After it didn't work, I decided to check out the XML format. I ran the following command to check the formatting of XML

xmllint --recover wifi-ap.kml -o fixed_wifi-ap.kml

This time, I got a few errors in the file. I found that the ampersand (&) caused issues. So, I replaced it with (&) to make sure that it is parsed correctly.

I uploaded the file to Google My Maps, and I successfully completed my longest wardrive.

I hope that you would've enjoyed reading about this experience. You can now read about how to build this setup on this article 👇