Private Investigator Idea - Vehicle WiFi Antennas for tracking

[0phoi5]

Hi all,

I was recently talking with someone regarding Private Investigator work, and the discussion included ways in which one could tell which direction a tailed vehicle/person had turned when you get to a junction and are not certain whether they turned left or right etc.

This has given me an idea regarding using the Station MAC of their mobile phone to determine which direction they went. Kind of like a poor-mans GSM Directional Finder, but using the target's WiFi signal instead of the actual phone signal.

I would like your thoughts on the following, whether you think this would be feasible, and possible best methods if it is.

• Minimum 2 x directional WiFi antennas in the PI vehicle, one facing forwards and left, one facing forwards and right.
• Beam widths set so that they are close to each other, but not actually crossing, at the front of the vehicle.
• A device (RPi / laptop) with both antennas connected.
• Both antennas in Monitor Mode, using airodump-ng to monitor nearby Station MACs.
• A script created on the device to read which antenna is picking up a Station MAC with a higher signal strength than the other, and then output this to a screen / phone.

Now, presuming the PI is able to get the mobile phone Station MAC of the person being investigated (not massively difficult) and the target has their phone WiFi on (happens often), in theory this method could make following them easier, as even without obvious sight of the vehicle/person ahead, the PI could have at least a rough idea of which direction they are in, in relation to their current position. It could perhaps also be possible to add more antennas, such as in each corner of the vehicle.

Would this work? I'm tempted to have a play.

Thanks.

Edited May 8, 2017 by haze1434

[0phoi5]

On a side note - airodump-ng could be great for PI work in other situations. You could tell when a target was home, even if you don't actually eyeball them.

Edited May 8, 2017 by haze1434

[esa]

15 minutes ago, haze1434 said:

Hi all,

I was recently talking with someone regarding Private Investigator work, and the discussion included ways in which one could tell which direction a tailed vehicle/person had turned when you get to a junction and are not certain whether they turned left or right etc.

This has given me an idea regarding using the Station MAC of their mobile phone to determine which direction they went. Kind of like a poor-mans GSM Directional Finder, but using the target's WiFi signal instead of the actual phone signal.

I would like your thoughts on the following, whether you think this would be feasible, and possible best methods if it is.

• Minimum 2 x directional WiFi antennas in the PI vehicle, one facing forwards and left, one facing forwards and right.
• Beam widths set so that they are close to each other, but not actually crossing, at the front of the vehicle.
• A device (RPi / laptop) with both antennas connected.
• Both antennas in Monitor Mode, using airodump-ng to monitor nearby Station MACs.
• A script created on the device to read which antenna is picking up a Station MAC with a higher signal strength than the other, and then output this to a screen / phone.

Now, presuming the PI is able to get the mobile phone Station MAC of the person being investigated (not massively difficult) and the target has their phone WiFi on (happens often), in theory this method could make following them easier, as even without obvious sight of the vehicle/person ahead, the PI could have at least a rough idea of which direction they are in, in relation to their current position. It could perhaps also be possible to add more antennas, such as in each corner of the vehicle.

Would this work? I'm tempted to have a play.

Thanks.

#!/usr/bin/python

import os
import time
import datetime
import argparse
import netaddr
import sys
import logging
from scapy.all import *
from pprint import pprint
from logging.handlers import RotatingFileHandler
from collections import OrderedDict


NAME = 'probemon'
DESCRIPTION = "a command line tool for logging 802.11 probe request frames"

DEBUG = False

myDict = {}

def packet_callback(packet):
	
	if not packet.haslayer(Dot11):
		return
		# we are looking for management frames with a probe subtype
		# if neither match we are done here
	if packet.type != 0 or packet.subtype != 0x04:
		return

		# list of output fields
	fields = []

		# append the mac address itself
	fields.append(packet.addr2)

		# parse mac address and look up the organization from the vendor octets
		#if mac_info:
		#	try:
		#		parsed_mac = netaddr.EUI(packet.addr2)
		#		fields.append(parsed_mac.oui.registration().org)
		#	except netaddr.core.NotRegisteredError, e:
		#		fields.append('UNKNOWN')

		# include the SSID in the probe frame
		#if ssid:
	fields.append(packet.info)		
	delimiter='\t'	
	textkey = delimiter.join(fields)
		
		#if rssi:
	rssi_val = -(256-ord(packet.notdecoded[-2:-1]))
	fields.append(str(rssi_val))
		
		# determine preferred time format 
	log_time = str(int(time.time()))
		#if time_fmt == 'iso':
	log_time = datetime.datetime.now().isoformat()

	fields.append(log_time)

#	logger.info(delimiter.join(fields))

	clear = lambda : os.system('tput reset')
	clear()

	myDict[textkey] = rssi_val, datetime.datetime.now().strftime('%Y-%m-%d %H:%M:%S'), int(ord(packet[Dot11Elt:3].info))
	mySortedDict = OrderedDict(sorted(myDict.items(), key=lambda t: t[0]))
	for i in mySortedDict:
		print myDict[i][0], myDict[i][1], myDict[i][2], i 
		
		#sys.stdout.write('%s\n' % textkey)
		#sys.stdout.flush()
		

def main():
	parser = argparse.ArgumentParser(description=DESCRIPTION)
	parser.add_argument('-i', '--interface', help="capture interface")
	parser.add_argument('-t', '--time', default='iso', help="output time format (unix, iso)")
	parser.add_argument('-o', '--output', default='probemon.log', help="logging output location")
	parser.add_argument('-b', '--max-bytes', default=5000000, help="maximum log size in bytes before rotating")
	parser.add_argument('-c', '--max-backups', default=99999, help="maximum number of log files to keep")
	parser.add_argument('-d', '--delimiter', default='\t', help="output field delimiter")
	parser.add_argument('-f', '--mac-info', action='store_true', help="include MAC address manufacturer")
	parser.add_argument('-s', '--ssid', action='store_true', help="include probe SSID in output")
	parser.add_argument('-r', '--rssi', action='store_true', help="include rssi in output")
	parser.add_argument('-D', '--debug', action='store_true', help="enable debug output")
	parser.add_argument('-l', '--log', action='store_true', help="enable scrolling live view of the logfile")
	args = parser.parse_args()

	if not args.interface:
		print "error: capture interface not given, try --help"
		sys.exit(-1)
	
	DEBUG = args.debug


	# setup our rotating logger
	logger = logging.getLogger(NAME)
	logger.setLevel(logging.INFO)
	handler = RotatingFileHandler(args.output, maxBytes=args.max_bytes, backupCount=args.max_backups)
	logger.addHandler(handler)
	if args.log:
		logger.addHandler(logging.StreamHandler(sys.stdout))
	#while True:
	#	for channel in range(1, 14, 1):
	#		os.system("iwconfig " + args.interface + " channel " + str(channel))
	#		print "[+] Sniffing on channel " + str(channel)
	sniff(iface=args.interface, prn=packet_callback, store=0)

if __name__ == '__main__':
	main()

might be useful. 

[esa]

Please experiment, maybe you have better luck than me.

My conclusion is that relying on WiFi probes from client device is not reliable and does not work for all cases. 

Some challenges would be: 

1) interference in signal resulting is fluctuating signal strength

2) Wifi probe times differs between devices & OS, the target might be long gone before his/her device tx again

3) IOS mac address randomisation & some Android OS/Phones

4) Power saving mode which turns off Wifi tx when screen is off

5) We are assuming the Wifi module is turned on

[0phoi5]

24 minutes ago, esa said:

Please experiment, maybe you have better luck than me.

My conclusion is that relying on WiFi probes from client device is not reliable and does not work for all cases. 

Some challenges would be: 

1) interference in signal resulting is fluctuating signal strength

2) Wifi probe times differs between devices & OS, the target might be long gone before his/her device tx again

3) IOS mac address randomisation & some Android OS/Phones

4) Power saving mode which turns off Wifi tx when screen is off

5) We are assuming the Wifi module is turned on

 

Thanks :) All very good points. Thanks for the script also.

May I ask what kind of set up you had? I currently have 2 x 7dBi Panel Antennas I was thinking of using with an RPi, to experiment.

 

A couple of questions regarding your points, if you don't mind;

1) Would the interference cause much of an issue? I feel that, if the beam widths did not cross, the strength of the signal from one direction or the other shouldn't be affected too much by 'bouncing' signals. The antenna pointing towards the actual target should still get a stronger signal than the antenna picking up 'bounced' packets?

3) I wasn't aware of this, thanks. How often do they tend to change the MAC? If it's daily, this could be an issue for the PI to use this method. If it's weekly or monthly, probably not a massive issue.

4) Damn, wasn't aware of this either. Do a lot of phones do this?

 

I do agree though. this is going to be a 'will work under certain circumstances' thing, where it could be highly useful in one situation and unusable in another. But options are always nice!

Perhaps I could add in some warning messages. Based on the input MAC address, the script could advise the user of any possible issues with that product type and advise on feasibility.

 

Thanks.

Edited May 8, 2017 by haze1434

[esa]

I am using a default Nano setup. 

1) Interference caused by external environment at time of scan is beyond our control.

http://packetworks.net/blog/common-causes-of-wifi-interference

3) On iOS, tx probe changes very frequently within mins (no exact value). The only time it reveals it actual MAC is when it is connected to a AP.

4) Once again i do not have the stats, but you should expect to see this behaviour on most modern phones. Try it on Nexus or iPhone

 

another i forgotten to mention, I am also not certain if phones tx at consistence power. Too many factors. 

Edited May 8, 2017 by esa

[esa]

Btw is the 2 x 7dBi Panel Antennas worth it ? Thinking of a upgrade too. How effective is it for you ?

[0phoi5]

2 hours ago, esa said:

Btw is the 2 x 7dBi Panel Antennas worth it ? Thinking of a upgrade too. How effective is it for you ?

They're not bad, I can get around 100m with a good strength signal, with line-of-sight. Not the best at penetration through walls/glass.

You can get them from Alfa on Amazon for around £7.00 here, so I'd say they're more than worth it at that price.

[0phoi5]

2 hours ago, esa said:

3) On iOS, tx probe changes very frequently within mins (no exact value). The only time it reveals it actual MAC is when it is connected to a AP.

If a PI were to run airodump-ng to see whether someone was at home then, it would work if they were connected to their home Wi-Fi, but if they weren't, then the station MAC would change every few minutes?

So, for example;

1. Joe Bloggs is at home with his iOS device and connected to his Wi-Fi.
2. PI Dave collects Joe's device MAC address using airodump-ng
3. Joe Bloggs goes for a drive with his iOS device, with it's Wi-Fi still turned on, but no longer in range of his home Wi-Fi, so it's not associated.
4. PI Dave follows, with airodump-ng still collecting MACs

In this scenario, would PI Dave's airodump still pick up Joe's iOS MAC, or would the MAC change within minutes and therefore not be recognised as the same device by airodump?

Edited May 8, 2017 by haze1434

[esa]

10 minutes ago, haze1434 said:

If a PI were to run airodump-ng to see whether someone was at home then, it would work if they were connected to their home Wi-Fi, but if they weren't, then the station MAC would change every few minutes?

So, for example;

1. Joe Bloggs is at home with his iOS device and connected to his Wi-Fi.
2. PI Dave collects Joe's device MAC address using airodump-ng
3. Joe Bloggs goes for a drive with his iOS device, with it's Wi-Fi still turned on, but no longer in range of his home Wi-Fi, so it's not associated.
4. PI Dave follows, with airodump-ng still collecting MACs

In this scenario, would PI Dave's airodump still pick up Joe's iOS MAC, or would the MAC change within minutes and therefore not be recognised as the same device by airodump?

MAC address should change to a spoofed one as soon as it is disconnected from the real Wi-Fi network.

On the timing of the change, it seems randomised, there is no fixed interval that i observed. 

 

More info. 

 

There are also some articles which suggest that iOS MAC randomization could be defeated. But the catch is that you need to know his real MAC to begin with. 

https://arxiv.org/pdf/1703.02874v1.pdf

[0phoi5]

Thank you :)

I'm attempting to put together a simple script to test feasibility.

If one uses airodump-ng to start collecting data, is there a way to see which access points a mobile device has previously connected to?

I can see under the 'Probes' header that there are some devices showing SSIDs and some are simply showing 'unassociated'. Are the SSIDs shown under here the access points that a device has previously connected to? Does this work even when they are out of range of the SSID?

I'm thinking that, if the PI could work out which Access Point belongs to the target's home, then the script could monitor for any MACs that are probing for this SSID. Then, even if the MAC changes every few minutes, airodump-ng could still tell which mobile device is related to the target?

[esa]

8 hours ago, haze1434 said:

Thank you :)

I'm attempting to put together a simple script to test feasibility.

If one uses airodump-ng to start collecting data, is there a way to see which access points a mobile device has previously connected to?

I can see under the 'Probes' header that there are some devices showing SSIDs and some are simply showing 'unassociated'. Are the SSIDs shown under here the access points that a device has previously connected to? Does this work even when they are out of range of the SSID?

I'm thinking that, if the PI could work out which Access Point belongs to the target's home, then the script could monitor for any MACs that are probing for this SSID. Then, even if the MAC changes every few minutes, airodump-ng could still tell which mobile device is related to the target?

It is not a complete solution but it should work on a portion of your targets. 

Yes ssid probe request is based on previous connected ssid and it works even when the real AP is not nearby. 

You should get an iPhone and a cheap android phone to experiment with. 

Do share your script if you have it. 

[esa]

Added SSID tracking. Could just use this module. 

https://github.com/esa101/ReconPlus-nano/tree/version3.0

[0phoi5]

On ‎10‎/‎05‎/‎2017 at 7:38 AM, esa said:

Added SSID tracking. Could just use this module. 

https://github.com/esa101/ReconPlus-nano/tree/version3.0

Thanks, nice idea!