转载原文地址：
http://edwardkeeble.com/2014/02/passive-wifi-tracking/
Passive WiFi Tracking
Posted February 26, 2014 by Edward
In the last year or so, there have been quite a few stories on the use of passive WiFi tracking by advertisers, retailers, and analytics startups. Most of these articles focus on the significant privacy and security concerns associated with this practice, but few of them get into the details of how the technology works. Having built a similar system for my project, Casual Encounters, I think I can explain some of the inner workings of these systems, how to avoid being tracked, and how, for research purposes or to determine their own level of exposure, someone could build such a system. I will state that I am by no means an expert on wireless networks, signal analysis, or anything of the sort, but I have conducted a fair bit of research and trial and error, and it works for me. Your mileage may vary; don’t try this at home; etc, etc.
Probe Requests
When a WiFi client (phone, laptop, etc) is looking to connect to a known network, there are two approaches it can take. The first technique, which is used by laptops and most non-smartphone devices, involves scanning for Beacon Frames (packets broadcast by WiFi routers in order to advertise their presence), waiting for a network that the client has previously connected to, and initiating a connection with it. The second technique, which is used primarily by smartphones, involves periodically broadcasting packets called Probe Requests, which contain the unique MAC address of the client and (sometimes) the name of a network to which it has previously connected. The advantage of the second technique is that by actively scanning for nearby routers, a phone can initiate a wireless connection faster than if it waits for the router to send out a Beacon Frame. While this certainly makes it more convenient to hop on a network, it also makes it possible to indiscriminately gather up this data and use it to track people.
Monitor Mode
There are six modes in which a WiFi device can operate. Routers generally operate in Master mode, while clients operate in Managed mode. In order to pick up all nearby traffic, a device needs to be operating in Monitor mode. Once set to Monitor mode, the device no longer advertises its presence, so, barring any physical indicators, it can be difficult to determine if such a device is running nearby.
Protection
Avoiding being tracked by these kinds of systems is fairly simple, in theory. As long as you turn the WiFi radio off on your phone whenever you don’t explicitly need it (generally, when you’re away from home, work, or anywhere you have a trusted network), the phone will stop transmitting probe requests and you will be untrackable (at least through this technique). Obviously, from a practical perspective, manually turning WiFi off every time you leave your house could become quite annoying.
If you use an Android device, there are a number of apps available which can simplify the process.AVG PrivacyFix, for example, allows you to set a group of trusted networks, around which your WiFi radio will be enabled. Once you leave the vicinity of these networks, the app automatically disables your radio. There are a number of similar paid and free apps available for Android. I have not personally used any of them, so I can’t speak to their efficacy.
If you use an iOS device, your options are much more limited. Unless you have jailbroken your device, Apple’s sandboxing of third-party apps makes it impossible to build a utility to automatically disable WiFi. That being said, iOS 7 introduced a swipe up menu which provides quick access to a number of settings, including WiFi. It still requires manual intervention every time you leave your house, but it beats wading through the settings.
Building a WiFi Tracker
Building a device to track smartphones is reasonably straightforward. You can, in fact, just use your MacBook. I could probably end this tutorial there, with some quick instructions on installing Wireshark and filtering for probe requests, but that wouldn’t be very interesting, and it wouldn’t really answer the question of how to build a network of tracking devices to deploy around a city or retail environment, as mentioned in the articles at the top of this post.
If you were building a network of these trackers, it would be prohibitively expensive (and logistically difficult) to deploy a laptop for each tracking node. Since the computing needs of the tracker are quite low, you can get away with using something as simple and cheap as a Raspberry Pi with a wireless adapter or (my preferred option) a small travel router like the TP-LINK TR-3020, loaded with open firmware. Both approaches are inexpensive, offer a small form factor, and can be run off a 5V battery, making them ideal for this sort of project.
The setup process for a Pi is actually quite a bit easier than the MR-3020, since most of the filesystem setup is taken care of for you, but I prefer the router, as it offers a cheap, standalone solution. For that reason, I will be detailing the process for the router here, but if you choose to go with a Raspberry Pi, keep the following things in mind:
- You can likely skip ahead to Setting up Monitor Mode, since the earlier steps are just meant to get the router’s filesystem and swap space set up.
- The two devices run different versions of Linux, so certain configuration files will be in different locations and you will use a different package manager than
opkg. - More powerful radios, such as the AWUS036H, may require a powered USB hub, since they draw more current than the Pi can supply through its USB ports.
Setting up your router
Before we proceed, you will need:
- A TP-LINK MR-3020 router ($34.99 on Amazon. Similar routers, such as the TP-LINK TL-WR703N should work, although I haven’t tried them.
- A USB flash drive (2-4 GB should be plenty, although more is always better)
- An ethernet cable
The decision to use an MR-3020 came from my experience building a PirateBox (a wonderful project devised by David Darts, which has been adapted to run on a range of devices). The initial setup steps for this project and for a PirateBox are identical, and since David did such a fine job explaining them, I thought I would simply link to his instructions ((http://daviddarts.com/piratebox-diy-openwrt/), rather than copy them all out again. You should follow these instructions up to (but not including) the section titled “Install PirateBox”.
Setting up your USB drive
If you followed the instructions in the previous section, you should now have SSH access to your router and the router should have access to the Internet. We will now configure our USB drive to extend the filesystem on the router and provide additional memory.
- Format your USB drive into two partitions: a primary Ext4 partition and a swap partition. The swap partition should be between 256 and 512MB.
- SSH into the router.
- Install packages to support the Ext4 filesystem:
[email protected]:~# opkg update [email protected]:~# opkg install block-mount kmod-fs-ext4 - Plug the USB drive into the router.
- Check that the drive and partitions are being detected:
[email protected]:~# ls /dev | grep sda sda sda1 sda2
Setting up the filesystem
Now we will setup sda1 as a pivot overlay on the root file system, as described here:http://wiki.openwrt.org/doc/howto/extroot#openwrt.
[email protected]:~# mkdir /mnt/sda1
[email protected]:~# mount /dev/sda1 /mnt/sda1
Check that the drive mounted successfully (should return /dev/sda1 on /mnt/sda1 type ext4):
[email protected]:~# mount | grep sda1
Copy files from the router’s flash storage to the usb drive. This will ensure that all of the necessary configuration files are available when we reboot with the USB drive replacing the root file system, so that the network interfaces come up as expected.
[email protected]:~# tar -C /overlay -cvf - . | tar -C /mnt/sda1 -xf -
Edit /etc/config/fstab to automount /dev/sda1.
[email protected]:~# vi /etc/config/fstab
Use the following configuration.
config global automount
option from_fstab 1
option anon_mount 1
config global autoswap
option from_fstab 1
option anon_swap 0
config mount
option target /overlay
option device /dev/sda1
option fstype ext4
option options rw,sync
option enabled 1
option enabled_fsck 0
config swap
option device /dev/sda2
option enabled 0
Now reboot the router:
[email protected]:~# reboot
Once all of the lights on the router have come back on, SSH into the router again and check that the USB drive mounted properly.
[email protected]:~# mount | grep sda1
/dev/sda1 on /overlay type ext4 (rw,sync,relatime,user_xattr,barrier=1,data=ordered)
If you can’t SSH into the router, something might have gone wrong with copying the configuration files over to the USB drive. Unplug the USB drive from the router and restart the router by unplugging its power cable then plugging it back in. Leave the USB drive unplugged so it doesn’t mount. Once the router has restarted and you can SSH into it, plug the USB drive back in and go back through the previous steps to make sure you did them correctly.
Setting up the swap partition
The router does not have very much on-board memory, so if we try to execute any long-running processes, it will likely run out of memory and reboot itself. To check the available memory on the router, enter:
[email protected]:~# free
You will notice that Swap has zeros across the board. We can use the swap partition we created earlier to ensure we have plenty of memory available. First, make sure the partition can function as swap:
[email protected]:~# mkswap /dev/sda2
Then turn activate the swap space:
[email protected]:~# swapon /dev/sda2
Now run free again to make sure the space was allocated:
[email protected]:~# free
total used free shared buffers
Mem: 29212 19160 10052 0 1972
-/+ buffers: 17188 12024
Swap: 475644 0 475644
This is great, but it won’t stay active if we reboot the system, so we need to let the system know that it should activate swap every time it starts up. You may have noticed a swap section in our fstab file from earlier. In my experience, this doesn’t always activate properly, so I have chosen to ignore it and create a separate startup script to turn on the swap space. This has the added benefit of introducing us to startup scripts, in case we want to create one later to ensure our scanning script restarts when the system resets.
Swap Startup Script
We will start by creating the startup script:
[email protected]:~# vi /etc/init.d/swapon
Enter the following into the file, then save it:
#!/bin/ash /etc/rc.common
START=109
STOP=151
start() {
echo "start swap"
swapon /dev/sda2
}
stop(){
echo "stop"
}
Make the script executable:
[email protected]:~# chmod +x /etc/init.d/swapon
Now we need to make a symlink from /etc/rc.d to our script to make the system run it on startup:
[email protected]:~# ln -s /etc/init.d/swapon /etc/rc.d/S109swapon
If you’re curious, the S109 part of the link name tells the system in which order the script should be run. If you list the files in /etc/rc.d, you will see that they all start with S##. S109 should put our swap script at the end of the list, so it will run after all of the system scripts.
Now reboot the system, SSH back in, and check if the swap space has been activated:
[email protected]:~# free
total used free shared buffers
Mem: 29212 19276 9936 0 2152
-/+ buffers: 17124 12088
Swap: 475644 0 475644
If the swap didn’t activate, double check that you set the swapon script to executable.
Set up Monitor Mode
Now that the system is (mostly) set up, we can get to the fun stuff. We will need to modify the router’s wireless config in order to activate it and set it to monitor mode:
[email protected]:~# vi /etc/config/wireless
Comment out the line that disables wifi:
#option disabled 1
Use the following settings for wifi-iface:
config wifi-iface
option device radio0
option network lan
option mode monitor
option hidden 1
Then restart the wifi interface:
[email protected]:~# wifi down; wifi up
You may see some error messages, like the ones below, but the wireless should still activate properly.
ifconfig: SIOCSIFHWADDR: Invalid argument
command failed: Device or resource busy (-16)
Check that wireless is up and in monitor mode:
[email protected]:~# iwconfig
lo no wireless extensions.
wlan0 IEEE 802.11bgn Mode:Monitor Frequency:2.412 GHz Tx-Power=15 dBm
RTS thr:off Fragment thr:off
Power Management:on
eth0 no wireless extensions.
br-lan no wireless extensions.
Install required packages
Now we will install all of the packages and libraries required by our scanning script:
[email protected]:~# opkg update
[email protected]:~# opkg upgrade tar wget
[email protected]:~# opkg install python tcpdump unzip
[email protected]:~# wget http://www.secdev.org/projects/scapy/files/scapy-latest.tar.gz
[email protected]:~# tar -xvf scapy-latest.tar.gz
[email protected]:~# cd scapy*
[email protected]:~# python setup.py install
[email protected]:~# cd ..; rm -rf scapy*
Test the scanning script
Edit The default git package on busybox seems to have trouble with https, but you can download the source code as a zip file instead.
We will need to clone the scanning script from git:
[email protected]:~# mkdir /overlay/scripts; cd /overlay/scripts
[email protected]:/overlay/scripts# wget http://bitbucket.org/edkeeble/wifi-scan/get/e2a08627f05d.zip --no-check-certificate -O wifiscan.zip
[email protected]:/overlay/scripts# unzip wifiscan.zip
[email protected]:/overlay/scripts# mv edkeeble-wifi-scan-e2a08627f05d wifi-scan
Because we’re responsible humans, we aren’t actually going to indiscriminately grab everyone’s probe requests. We’ll set up a whitelist, so we only print out requests from our own phones. Open the script in vi and edit WHITELIST to include your phone’s MAC address:
[email protected]:/overlay/scripts# cd wifi-scan
[email protected]:/overlay/scripts/wifi-scan# vi wifiscan.py
WHITELIST = [‘00:00:00:00:00:00’,] # Replace this with your phone’s MAC address
Now test the script:
[email protected]:/overlay/scripts/wifi-scan# python wifiscan.py wlan0
With the script running, get your phone out. While it will still send probe requests if it is connected to a network, it seems to send them more frequently if it isn’t already connected. Go to your settings and disconnect from your current network, but leave wifi turned on. You should start to see probe requests show up in the terminal. You may notice that some of the requests have an SSID while others do not. Probe requests without an SSID are considered broadcasts, designed to elicit responses from all access points in range.
Press CTRL-c to stop the scanning script. If it doesn’t stop right away, hold down CTRL-c until you get back to the terminal prompt.
Wrapup
There you go. You now have a portable router which can track nearby smartphones through WiFi packets. Of course, our current script doesn’t do very much and could be improved immensely. It could, for example, be modified to hop channels and pick up more data, start logging data, tracking devices between multiple areas, etc.
Thanks for reading. I hope this article was helpful and shed some light on the specifics of how these tracking systems work. If you would like to reach me, you can find me on twitter @edkeeble.