2015

PiFi Analyser

MASON MCCALLUM, NATHAN VAZ AND TIMOTHY LY

NORTHERN SYDNEY INSTITUTE | Meadowbank Executive summary Wireless networks have become more prevalent in contemporary society, as such it is important to accurately study the impact that wireless networking can have on personal security and privacy. The PiFi Analyser project outlines the methods behind passively recording wireless networks and mapping the recorded data with associated GPS location data. The ensuing report confirms the methodologies and technologies proposed can operate to scopes that could be used to significant effect.

1 | P a g e

Contents Executive summary ...... 1

Introduction ...... 4

Literature Review ...... 5

Objectives ...... 7

Method ...... 9

Building the Device ...... 9

Testing device ...... 9

Map plotting ...... 10

Choosing test Locations ...... 10

Location Monitoring ...... 10

Rationale behind time and location choices ...... 11

Mason McCallum ...... 11

Nathan Vaz ...... 11

Timothy Ly ...... 11

Hardware List ...... 12

Raspberry Pi 2 Model B ...... 12

GPS Receiver BU353S4 ...... 12

High gain Wi-Fi Alfa AWUS051NH...... 12

USB Battery Pack ...... 12

Micro-SD card ...... 12

Budget ...... 13

Software Tools List ...... 14

airmon-ng ...... 14

airodump-ng ...... 14

ntpd ...... 14

...... 14

cgps ...... 15

2 | P a g e

Google Earth ...... 16

giskismet ...... 17

Workable Procedure ...... 18

Setting up the Raspberry Pi ...... 19

Converting netxml files to kml ...... 23

Ethical Considerations ...... 24

Results ...... 25

Discussion...... 26

Observations ...... 27

Conclusion ...... 31

References ...... 32

3 | P a g e

Introduction The use of the internet in Australia is one of the largest per capita growth sectors among developed nations. With broadband connections at home increasing to 81% from 74% over the course of one year (June 2013 to June 2014) (ACMA pg 35), as well as a higher percentage of users accessing the internet from a mobile device; 70% from 62% over the same time period, the use of wireless networks by Australians will likely continue to rise, especially when the same report shows that “approximately half of all Australian homes had more than five devices connected to the internet via a home network of all devices connected to a home network, 82 per cent were connected via Wi-Fi, while only 14% used wired technology only.” (ACMA pg 40).

From these Australian consumer trends, we can extrapolate that the general population’s desire for internet access regardless if they are connecting to a trusted network or not i.e. public Wi-Fi. This practice could lead to potential digital harm such as contracting malware, identity theft and impacted performance among others. However the issue that this project aims to identify is the physical security associated with owning a mobile device. As mobile device (smartphones, laptops and tablets) ownership among adults nears saturation in Australia, it is safe to assume that the physical presence of an individual can be linked to the physical presence of their devices. This project will endeavour to show just how vulnerable the wider community is to detection, simply through connecting to a .

The potential abilities of our project could impact the way public networks are monitored by third parties as well as the security auditing capabilities available through measuring the security levels and traffic of various wireless networks over time.

4 | P a g e

Literature Review The inspiration for the project methodology came from a practice called Wardriving, whereby individuals would drive around in cars and scan wireless networks passing by. A persistent notion about the original process which irked us was the requirement for a laptop with a Wi-Fi antenna really made the operation a little too conspicuous, as well as the need to conduct the scanning from a car. The idea for a more portable scanning apparatus was founded from the necessity to scan areas that a car might not be able to reach i.e. a shopping centre, range-restrictive apartment blocks, stadiums etc.

Upon further research, we came across a project conducted by Sophos which had implemented aspects of our project idea, even using a raspberry pi hardware platform, they presented a corporate-quality level project called Warbiking (Sophos.com, 2015). The central focus of the Sophos feature involves their Raspberry Pi-based device attached to a bicycle and ridden around various cities gathering wireless network information and presenting their findings. These findings include the levels of security implemented throughout their bicycle scanning paths such as whether WEP, WPA or WPA2 types of encryption are being utilised.

The most helpful source of research into this sort of project has been a white paper published by the SANS Institute in which a similar project featuring a Raspberry Pi-based Wardriving device was developed (Christie, 2013). The project is called War Pi and contains extensive technical annotations attached throughout the various processes. The War Pi paper, namely the technical specifications will aid us greatly in developing the necessary processes for recording our wireless data. Among the more valuable solutions within the War Pi is the method for mapping the collected data to a Google Maps API (Christie, 2013). The SANS institute is a respectable organisation in the field of IT security, thus we believe it to be a reliable wealth of knowledge for out project. Our project may differ from the SANS project due to the wireless traffic analyser we intend to use, the aircrack-ng suite instead of .

The collection of such data is also available in an open shared platform called WiGLE (Wireless Geographic Logging Engine). At this site, users who have engaged in their own war-driving upload information about wireless networks including: GPS coordinates SSIDs and MAC addresses and collated into an interactive map. WiGLE also features statistics based on the collective results of carious scans, statistics such as; network numbers over time, encryptions used over time, SSID frequency among other parameters. Although our project is embarking on a significantly smaller geological scale, we aim to include significantly more complex data in the form of individual user devices connected to wireless access points as well as a more determined time scale in between

5 | P a g e measurements. Where our project aims to differ is the multiple measurements of the same areas over a predetermined time period to record any estimated changes. The ensuing data analysis should hopefully provide some insight into the security trends of local wireless networking users

Additional ideas that inspired this project were the capabilities of wireless control systems such as the kind used by Cisco with their Wireless LAN Controllers (Cisco, 2006). Cisco’s Wireless Control System (WCS) contains features that can monitor network activity taking place through a Wireless LAN Controller. The levels of wireless activity monitored can be helpful in determining solutions for that particular wireless network such as whether or not additional wireless access points need to be installed for areas with poor coverage. The concept of wireless network measurements being used to influence physical decisions appealed to the aims of our project, even though we will be operating from ‘the other side of the looking-glass’.

Our project might be considered unique in that we are using wireless network data in a manner similar to sociological research. Through our data collection and analysis goals, we hope to develop a method for plotting wireless usage activity over a period of time in a given area depending on our research method. As far as we know, that method of customised scanning wireless networks for customised analysis has not been undertaken yet.

6 | P a g e

Objectives Primary Objectives

To design, create and document:

 A portable device capable of passively collecting information on surrounding wireless networks and record this wireless information in conjunction with with GPS location and time of detection  A system where by gathered wireless information can be stored  A system in which gathered information can be plotted on geographical mapping software in a useful manner

Secondary Objectives

 To gain a greater understanding of the current state of wireless networks within public and residential areas in regards to security and availability.  To understand the functions and capabilities of passive wireless connectivity and GPS mapping through a developer board platform i.e. raspberry pi.  To utilise statistical analysis skills to collate data on a geographical map.  To extrapolate significant usage patterns and trends derived from statistical analysis.  Exploring the various contemporary risks and vulnerabilities associated with unsecured public networks and possible solutions to minimize these risks.

These objectives listed are indicative of the desired outputs of our various tests conducted with the PiFi Analyser. The types of outputs we would want to have, involve an interaction between the wireless network data collected and the plotted points of collection on a map.

Plotting wireless networks onto mapping software would be the most appropriate way to interact with the collected data since a person’s knowledge of exact GPS coordinates in relation to a real point would not be applicable in any raw output formats.

What makes this project unique is our goal of differentiating plotted points by time. For example, if we were to collect data from a shopping centre on a Tuesday and then the same place on a Thursday, we would want to able to filter the results by ‘time collected’. This would be beneficial in data collection in the context of identifying differences between the presences of wireless networks, namely the use of personal hotspots would apply to this methodology.

7 | P a g e

This project also endeavours to collect and collate wireless client information associated with wireless networks. By reviewing some of the technologies appropriate to our project, we came across the aircrack-ng suite which features the airodump-ng that displays wireless clients associated with wireless networks. If we could somehow implement this extra data in the outputs onto a mapped format, it would add a wider scope to the repeated readings that we would conduct. That is to say, the repeated readings at the shopping centre could also reveal differences in the number of clients that use public Wi-Fi.

The ability to analyse wireless clients would enable a level of monitoring to an individual user scale. It would be easy enough to infer the presence of an individual based on the presence of their wireless devices from the information we intend to be able to gather.

8 | P a g e

Method This project has been planned in such a way that each member will have their own hardware platform to work on. This will mean that all group members will be participating in hands-on usage & scripting as well as experience in the use of developer boards.

Building the Device When constructing the Wireless analysis device each team member will be expected to configure the software on the SD card required to run. Team members will of course assist each other in this process.

The to be used will be Raspbian without a GUI as it is one of the most supported and fully featured Raspberry Pi operating systems. Team members will then need to configure the GPS receiver for use in Linux and ensure that the Wireless adapter appears and works as intended.

Once the hardware is tested to be working within the Linux operating system, software such as the aircrack-ng suite will be required to passively scan for Wi-Fi broadcasts, a script will need to be written to utilize the outputs of airodump-ng from the aircrack-ng suite and the GPS receiver to log the networks and devices seen to a SQLite database.

Once the outputs from the wireless monitoring software and GPS are correctly being logged, the data will need to then be fed into Google Earth via a kml file to have the logged information plotted on a map.

Testing device Testing the device will occur throughout all stages of the project before proceeding to the next stage.

 GPS receiver needs to be tested for a functional output.  Wi-Fi antenna needs to be tested for functional compatibility with airmon-ng  Script to log airodump-ng and GPS output needs to be tested using different outputs from the devices and programs  The time set by the GPS must be checked for accuracy  Kml file must be tested by loading it into Google Earth

9 | P a g e

Map plotting For the map plotting section of this project, Google Earth will be used to display the logged information. Google Earth will be provided a kml file, which will have been extracted from giskismet’s SQL database, which will in turn have been populated by the netxml files created by airodump-ng.

Choosing test Locations Test locations to be chosen will ideally have a high density of users or have a high density of Wi-Fi networks over a given area. These Wireless networks must also be accessible from a public location such as a storefront or the footpath. Each member will need to choose at least two different locations to monitor and justify their choices of location and their chosen monitoring times.

Location Monitoring When performing the location analysis team members will need to pass through their chosen test locations at their selected analysis times to plot the usage in these areas. Or the device may be left in a static location to survey the wireless usage in a given area over a longer period of time.

10 | P a g e

Rationale behind time and location choices

Mason McCallum The Location to be surveyed by Mason will be the streets and surrounding area of Berowra. This location has been chosen, primarily due to the close proximity and convenience, however this location is ideal for testing the equipment for many reasons

 Medium to low network density ensures minimal interference from competing networks  Close proximity of many streets means there will likely be overlaps in surveyed networks  Predictable wireless environment where wireless activity will likely be minimal during the day, however in the evenings when most people are at home from work or school the wireless activity is expected to dramatically increase  GPS positioning will likely be more accurate as there are very few obstructions to the sky from buildings (trees may prove to be an issue, however)

Nathan Vaz To determine the location of an individual wireless device on two separate occasions based on whether or not the MAC address is present or not. One recording will take place in a Sydney CBD food court (or other location) on a Tuesday at 12:20pm and again on a Thursday at 12:30pm to try and determine how many of the same individual devices return to the same place at two different times.

Timothy Ly Macquarie Shopping Center Food Court is a suitable for our monitoring because of its location and the amount of networks in the area. These include the public WiFi, retail shops WiFi, possibly mobile hotspots and laptop connections.

We will be monitoring around 2:30pm on a Thursday. The reasons for this is, that’s the time when most office employees are on their lunch break and students from university and high school in that area finish around that time so they will tend to visit the shopping center.

We will compare this to a day on Monday and at 10am. The reasons for this is that there are not as many people but the networks are still active since all the shops are open, but there will be very little amount of activity.

11 | P a g e

Hardware List

Raspberry Pi 2 Model B The Raspberry Pi is to be used as a computational platform to power this Wi-Fi analysis device. The RPi requires very little power which means it can be powered by a USB battery pack designed to provide current to charge a phone.

GPS Receiver BU353S4 This GPS receiver has full Linux compatibility and has been successfully used in a previous Raspberry Pi war driving projects such as the following http://www.sans.org/reading-room/whitepapers/networkdevs/war-pi-34435

The GPS receiver is also a direct upgrade over BU353

High gain Wi-Fi Alfa AWUS051NH This USB Wi-Fi NIC and antenna package has been chosen as it is the highest gain <$50 wireless NIC which also has a replaceable antenna. The Adapter supports a/b/g/n as well as both 2.4 GHz and 5 GHz frequencies. The adapter is capable of packet injection; however this is not necessary for the project.

USB Battery Pack An appropriate battery pack has yet to be determined as the RPI can potentially draw up to 2 AMPs depending on what devices are connected. Fortunately as the GPS adapter only draws 15mA @5V and the Wi-Fi adapter can at most only draw 500mA it is likely that a 1A USB power supply will suffice. Should we encounter problems with power requirements, the clock speed of the Raspberry Pi can be reduced to minimise power draw

Micro-SD card The Micro SD card will be used as a boot device for the Raspberry Pi. The SD card must be capable of storing the Operating system, Applications and be able to have enough room to store the database created using the Output of airodump-ng and the GPS co-ordinates

12 | P a g e

Budget Item Price URL Raspberry Pi 2 Model B $65- http://www.ebay.com.au/itm/RASPBERRY-PI-2-Model-B-1GB-RAM-Quad- $77 Core-Case-Heatsinkx3-AU-Power-Supply- /231471264112?pt=LH_DefaultDomain_15&hash=item35e4c33170 Globalsat BU353 S4 USB $54 http://www.ebay.com.au/itm/NEW-Globalsat-BU-353-BU353-S4-USB-GPS- GPS Receiver Receiver-for-Laptop-NB-Free-Shipping- /230620688565?pt=LH_DefaultDomain_15&hash=item35b21070b5 ALFA AWUS051NH USB $50 http://www.ebay.com.au/itm/Alfa-AWUS051NH-v2-Dual-Band-802-11a-b-g- 1000mW WLAN G n-WiFi-Wireless-USB-Adapter-2-4-5-GHz- /130869408263?pt=LH_DefaultDomain_0&hash=item1e786cb207 Adapter Micro SD card (8gb $10- N/A minimum) $30 USB Battery pack $5-40 N/A Total ~$200

13 | P a g e

Software Tools List airmon-ng The program airmon-ng is a tool included in the aircrack-ng suite. The software allows a given wireless adapter to be used as a wireless monitoring device on the 2.4ghz frequency (5ghz is currently unsupported, and unavailable on the wireless network adapter chosen for this project).

The software works by placing the wireless network adapter in a monitoring mode and creating a virtual monitoring adapter named mon# (# will be replaced by a number starting at 0 but increasing if more monitoring interfaces are needed) that can be used by other programs for packet analysis such as and airodump-ng.

The command to start this process is sudo airmon-ng start wlan0 airodump-ng The program airodump-ng is designed to work in conjunction with airmon-ng to utilize the monitoring interface it creates. Airodump-ng will capture the wireless packets provided by airmon- ng and record them with GPS location data provided by gpsd and system time information as dictated by ntpd. Airodump-ng will then record this information in one of many output formats including , ivs, csv, gps, kismet & netxml. For this project we have selected netxml as the XML structured document is easier to interpret for human eyes while debugging. The netxml file format is also easily converted to kml for use with Google Earth

The terminal command to start this process is sudo airodump-ng mon0 ntpd Ntpd is a background process (also known as a ) found within almost all Linux systems designed to set the system time based on other authenticated servers. However this daemon can utilise other sources such as the GPS receiver used for this project. This is a critical part of the device as the Raspberry Pi does not include a real-time clock and therefore cannot store accurate time by itself, having correct timing while recording is essential to accurate data logging. gpsd Gpsd is another background process or daemon, designed to provide a layer of compatibility for the GPS receiver. Gpsd will communicate with the GPS receiver and interpret the output from the GPS into a standard output format able to be used by many different programs within the Linux operating system. For our purposes, we will be using GPSD to provide current location information to airodump-ng to be included in the CSV logs.

14 | P a g e cgps The program cgps is not directly used in this project, but it does provide a testing method to ensure that the GPS receiver is working correctly. Cgps will connect to gpsd’s output and interpret the data so that location information may be presented in a terminal window. This program is included in the gpsd-clients package and has been used primarily as a debugging tool to verify that the GPS receiver is sending correct information to gpsd. Currently we have been experiencing problems with our receivers which we believe are due to reception issues, and not a fault with communication between gpsd and the programs which utilize the information formatted by gpsd.

As can be seen in this screenshot, the GPS receiver is not providing accurate information at this time

15 | P a g e

Google Earth Google Earth is the program which will be used to present the information logged by our network analysis device. The program is designed to allow the user to view the world in a 3d perspective by using combined satellite images and plot information either by within Google Earth, or via files generated by external programs containing metadata including GPS coordinates. When an external file is loaded such as the kml (keyhole mark-up language) files we are using in this project, Google Earth will overlay the information on its maps at the specified locations.

The following is an example of the data Google Earth will display

16 | P a g e giskismet Giskismet is a program which will take the netxml files generated from airodump-ng and convert the information into an SQLite3 database, giskismet can then use the data stored in its database to generate kml files to be used by Google Earth based on a query provided to giskismet. By storing the information in a database it allows flexibility on how the stored data can be manipulated. For example, if multiple Raspberry Pis are performing scans giskismet can combine the information into a single database file. Giskismet can also provide specific kml files based on a query, for example a kml file containing only wireless access points where client information has been collected.

The following images are displaying samples from giskismet’s clients and wireless database tables

17 | P a g e

Workable Procedure The following flowchart outlays the data flow within the Raspberry Pi and our project from both active sensors to the displayed information within Google Earth

18 | P a g e

Setting up the Raspberry Pi

1) Install Raspbian on Raspberry Pi, either via NOOBS installer or by flashing the Raspbian image to a micro SD card

2) To finalise the Raspbian setup, use the following command then navigate the menu provided sudo raspi-config

a) Expand the file system so that all of the SD card’s space is available

b) Change user password

) Under Advanced options, it is highly recommended to enable SSH so that configuration changes may be made without connecting the Raspberry Pi to a monitor and keyboard

3) Ensure that the Raspberry pi is connected to the internet via a Ethernet cable, as well as connected to both the wireless adapter and the GPS receiver

4) Perform system update using the command sudo apt-get update && sudo apt-get upgrade –y && sudo apt-get dist-upgrade –y

5) Install aircrack-ng suite from source a) First install appropriate dependencies sudo apt-get -y install libssl-dev libnl-3-dev iw

b) Then install aircrack-ng using the following commands wget http://download.aircrack-ng.org/aircrack-ng-1.2-beta1.tar.gz tar -zxvf aircrack-ng-1.2-beta1.tar.gz cd aircrack-ng-1.2-beta1 make sudo make install sudo airodump-ng-oui-update

19 | P a g e

c) It is advisable to test that the airmon-ng suite has been correctly installed, this can be done by the following commands in order sudo airmon-ng start wlan0 This will put the wireless card in a monitoring mode ifconfig If airmon-ng is working correctly, you will now see a new interface called mon0 sudo airodump-ng mon0 Will display any wireless packets captured by the wireless network adapter in monitoring mode

6) Install gpsd to interface with the GPS receiver a) The following command will download the necessary packages sudo apt-get install gpsd gpsd-clients

b) To determine the path to the GPS receiver use the command dmesg | grep tty and look in the printout for “ttyUSB0” or something similar, this is the location of our GPS receiver

c) Gpsd can now be configured using sudo dpkg-reconfigure gpsd. During the reconfiguration of gpsd several questions are presented and may need to be changed from their defaults i) Start gpsd automatically? Yes

ii) Should gpsd handle attached USB GPS receivers automatically? Yes

iii) Device the GPS receiver is attached to: (This is the path displayed in step 6b) /dev/ttyUSB0

iv) Options to gpsd: /dev/ttyUSB0 (Leave as default)

v) Gpsd control socket path: /var/run/gpsd.sock (leave default)

vi) Reboot Raspberry Pi using sudo reboot

20 | P a g e

vii) Gpsd can be tested using the following command cgps It should be noted that the first time use of a GPS receiver requires that the device be updated with the most current almanac from the satellites; this process can take 10-20 minutes in ideal conditions with a clear line of sight to the sky.

7) Now that both the aircrack-ng suite and gpsd are installed, configured & tested they can be tested in conjunction with each other a) Place the wireless card in monitoring mode using sudo airmon-ng start wlan0

b) The following command will start monitoring the wireless activity in the area and record the current location to a file called test.netxml located in /root sudo airodump-ng -w test --output-format netxml --gpsd mon0

8) In order to configure the time, we must generate a script which will synchronise the NTPD time to the time information collected by the GPS receiver. a) First, we create a new shell script by the following command nano /home/pi/dateset.sh

b) We then fill the file with the following code to be executed upon boot date -s '01/01/2014 00:01' pkill ntpd sleep 10 GPSDATE=`gpspipe -w | head -10 | grep TPV | sed -r 's/.*"time":"([^"]*)".*/\1/' | head -1` echo $GPSDATE date -s "$GPSDATE" The finished file should look something like this

21 | P a g e

a) When finished editing with nano, press ctrl X to exit (respond yes, when asked if you want to save)

9) The following commands must be added to /etc/rc.local so that they are automatically run when the device boots up. a) Firstly to edit the rc.local file type the following command sudo nano /etc/rc.local

b) Then enter the following lines at the end of the file, but before the last line containing exit 0 sh /home/pi/dateset.sh sleep 10 sudo wpa_cli -i wlan0 terminate sleep 10; sudo airmon-ng start wlan0 sleep 10; sudo airodump-ng -w $(date +%Y.%m.%d-%H.%M) --output-format netxml --gpsd mon0

When done correctly the file should appear as follows

10) To test that the device is operating as intended what needs to be done is for the raspberry pi to be connected to the Wi-Fi, GPS, Ethernet and power. After allowing time for the device to boot, you must SSH into the raspberry pi again, and check that .netxml files are being created in the root directory an example filename could be “2015.05.28-18.00-01.netxml”

22 | P a g e

Converting netxml files to kml To convert the netxml files to the kml format used by Google Earth a program called giskismet will be used. However the remainder of these instructions are not intended to be executed on the Raspberry Pi, but instead on an end user’s Linux computer. For our example we have used . 1) Firstly if giskismet is not installed install it by the following command

sudo apt-get install giskismet

2) If the netxml files from the raspberry pi wireless analysis have not been copied from the SD card, do this now. This can be done via either SCP, SFTP or by simply powering off the Raspberry pi and plugging the SD card into the Linux computer

3) Now that giskismet is installed and the netxml files are collected we will use giskismet to import the files into giskismet’s sqlite3 database. We can do this using the following command giskismet -x [name of the netxml file]

If it is necessary, multiple netxml files can be imported into a single database, for example several Raspberry Pis have been used for surveys simultaneously.

4) To export the wireless and client information from giskismet’s database we will need to execute the following command giskismet -q "select * from wireless" --ignore-gps -o outputfilename.kml

It is important to note that the name of the output kml file should be changed accordingly. 5) This kml file can now be opened in Google Earth to view the route, recorded wireless networks, and any client information that has also been recorded

23 | P a g e

Ethical Considerations Since our project features wireless network monitoring in public areas, there is certain legislation that must be considered in order to operate ethically and remain on the right side of the law. The legislation that we will focus on The Privacy Act (1988).

The Privacy Act (1988) is an Australian Law which generally oversees the use of an individual’s personal information. When monitoring wireless networks we will follow the Australian Privacy Principle (APP), derived from The Privacy Act to ensure that we are following the law.

The APPs that we are mainly following are:

- Australian Privacy Principle 6: use or disclosure of personal information - Australian Privacy Principle 11: security of personal information - Australian Privacy Principle 12: access to personal information

The Australian Privacy Principle 6 states that “If an APP entity holds personal information about an individual that was collected for a particular purpose (the primary purpose), the entity must not use or disclose the information for another purpose (the secondary purpose)”. This means that we as a group are not allowed to use that information for anything that is not disclosed. For example, since we are monitoring wireless networks, we may be able to infer someone’s home address. By law we are not to use that person’s home address for any other purpose.

The Australian Privacy Principle 11 states that “If an APP entity holds personal information, the entity must take such steps as are reasonable in the circumstances to protect the information”. This means that any information that we gather must be protected from being misused, interference or lost. As a group if we find someone’s personal information, we must take necessary steps to protect their information from being misused, tampered with or lost. Also, if we hold someone’s personal information and we no longer need it for our project, then we must take reasonable steps to destroy the information or de-identify it.

The Australian Privacy Principle 12 states that “If an APP entity holds personal information about an individual, the entity must, on request by the individual, give the individual access to the information”. This means that if we find someone’s personal information we must give the individual access to the information, but only if they request it. However if nobody requests any sort of information we must follow APP 11.

24 | P a g e

Results Over the course of the project, we were able to complete the primary objectives. We were able to develop a system which can monitor wireless activity for networks and their clients, we were able to store this information inside an SQL database and we were able to then extract the recorded data and convert it into a format capable of being displayed on Google Earth. However due to the unreliability of the GPS units, we were unable to complete a set of accurate scans. Mason’s GPS receiver was never able to acquire an adequate fix with the GPS signals and after some testing it was determined to be a faulty unit. Nathan’s and Tim’s GPS receivers were unreliable at best; they would lose their signal constantly which means incomplete & un-mappable data.

Despite these issues the system worked, despite the lack of fully functional GPS units. From this project our team gained a greater understanding of the capabilities and limitations of wireless monitoring, Wardriving and GPS receivers. However due to the lack of complete data we were unable to analyse the recorded data for trends of users attached to any given wireless network.

We found that despite using a high gain omnidirectional antenna, the number of wireless clients collected that were associated with a wireless network was exceptionally low. This may have been caused by the fact that when a wireless client connects to an access point the wireless NIC inside the client device will determine the maximum power required to establish a strong signal and lower its transmit signal strength accordingly so as not to waste power. This in effect reduces the radius that client data can be collected. One possibility to fix this may have been to use a high gain directional or yagi antenna to focus monitoring in a specific area. However this solution negates one of the purposes of the project where the device must be passive as a directional antenna must be “aimed” in the direction that the signal should be collected from.

25 | P a g e

Discussion In Tim’s scan, many of the wireless networks recorded did not have attached GPS data. This was most likely due to the location of Tim’s scans taking place in an enclosed building with poor reception, but also attributable to the unreliable nature of the GPS receiver. This may have been solved by using the device in a more open area to allow the GPS receiver to acquire a strong signal.

Nathan’s scans produced more consistent GPS data in the context of the existence of GPS logging attached to each wireless network however many of the networks were associated with the same GPS coordinates. This would either imply that the PiFi analyser was stationary or the more likely scenario GPS data was incorrect.

The outputs of the PiFi Analyser more often than not did not display GPS data associated with the wireless networks scanned. We believe that this was caused by the GPS receivers failing to acquire a signal lock. This problem also had the knock on effect that the time from the scans was inaccurate, often recording times 20 years in the past as this was the most accurate information the GPS receivers were aware of.

While the inaccurate/incomplete GPS data may have been resolved by using different GPS receivers, the best resolution to fix the inaccurate time issue would have been to install and configure a Real time clock module designed for the Raspberrry Pi.

Had the hardware problems not arisen we believe that we would have been able to perform enough scans to demonstrate how the recorded data can be used to monitor wireless activity more accurately. We would have also been able to better ascertain the limitations of scanning wireless networks for attached clients.

26 | P a g e

Observations Over the course of the project we encountered many changes to our desired trajectory that ranged from procurement problems, to core technology adjustments and even to faulty hardware. The impacts of each of these changes were all not necessarily negative, with few changes that facilitated the data collation process and enabling a wider scope of data representation.

The first obstacle that the project as a whole faced was difficulties surrounding the procurement of the necessary hardware; the Raspberry Pi, the wireless scanner and the GPS receiver. Since these parts were ordered online, the delivery times of each of these components varied between the projects participants. The impact of the procurement difficulties mainly affected the timeline of our project, as it took longer than initially anticipated for all the hardware to arrive, the delay affected how we could test the configurations that we planned.

During our initial planning phase, we strongly considered using kismet to conduct our wireless scanning since it is what was used in the WarPi documentation (Christie 2013) and would be easy enough to emulate in our own configuration. Upon further research, we came across the aircrack-ng suite and the capabilities of some of it’s’ modules, namely the airodump-ng component for its ease of use and ability to output wireless clients attached to scanned networks and the airmon-ng component for its ability to monitor un-associated wireless clients independent of network connectivity. Airodump-ng became our primary software tool for combining data from the wireless receiver and GPS receiver then outputting into a workable format. Airodump-ng still had all the features that we needed from kismet but was much easier to use and could format outputs into kismet netxml files or CSV files.

CSV was our choice the output format from the PiFi Analyser at first, though we changed the format back to the kismet netxml format since there was better support available should difficulties arise. During any sort of troubleshooting when viewing the raw output, we found it much easier to interact with a netxml file than a CSV file. This became especially helpful when dealing with problems that arose and confirming whether or not certain data was being recorded properly such as GPS data or if we had to identify at what point a corrupted output was damaged.

Throughout our testing phases we found an issue arose surrounding the Raspberry Pi’s lack of an internal real-time clock (RTC). The first time we encountered this problem was during a test of the airodump-ng outputs, where we found the timestamp gathered from the system time would be inaccurate. The solution we arrived at was to apply the time used by the GPS receiver to the airodump-ng timestamp, since the GPS clock should be relatively accurate in order to provide location data.

27 | P a g e

This leads us to the source of most of the problems associated with the project, the GPS receiver. As previously mentioned, we configured airodump-ng to use the GPS receiver’s clock for a timestamp with the expectation that it would consistently provide the correct time for our scans. The GPS receiver hardly ever gave the correct time, often outputting a timestamp in either 1992, 1995 and rarely in the correct 2015. Since we had configured airodump-ng to assign filenames based on the timestamp, the lack of an accurate clock impacted our netxml filenames to greatly vary between date and times making it very difficult to navigate between files and determine which scan is which. We would strongly recommend implementing an RTC module into future projects of this nature just to mitigate timestamp issues.

Another issue we that we came across with the GPS receiver was its general unreliability. Out of the three PiFi Analysers that we constructed, only one of the GPS receivers worked consistently enough to be of any use. During the testing phase of the project, the GPS receiver had to configure itself by gaining a satellite lock and writing a specialised file called an almanac which is crucial to the receiver being able to give accurate locations. This required the GPS receiver to initially run in an open area for an extended period of time to build the almanac data derived from the satellites. Mason’s GPS receiver could not build an almanac and never showed any location output, thus his PiFi analyser was rendered obsolete in the scope of what the project is trying to achieve. Tim’s GPS receiver only occasionally delivered location data, though initially displaying similar errors to Mason’s receiver. Nathan’s GPS receiver managed to build an almanac and display relatively accurate location data during the testing phase of the project, however other problems arose during the field operation phase of the project.

For many of the field scans the output revealed errors in the GPS information attached to wireless networks recorded and associated clients of those networks. The errors ranged from showing no GPS data to showing the same GPS data for multiple networks regardless of the actual location. This was considered a failure in the scope of the project in terms of being able to accurately map data from our portable PiFi Analyser from different locations. We conceded the lack of GPS data for wireless clients as rather irrelevant considering the logic behind a wireless client connected to a network therefore must be within the physical range of the wireless networks antennae, in our view this was not discernible enough to warrant extra concern. These faults were somewhat mitigated in the context of gathering wireless network information by not moving the pifi analyser during operation, basically operating from a stationary position and hopefully recording an accurate location.

28 | P a g e

A rather unorthodox feature of the PiFi analyser was the operation procedure in the context of powering on and off. In this project the Pifi analyser was turned on by simply plugging in a power source, whether it was a power adapter during testing phases or a battery pack during operation. The problems surrounded the method we used to turn off the PiFi Analyser during the operation phase, in that it was done by removing the power source. This became more problematic considering the way that our airodump-ng script was written, namely that the airodump-ng would start writing an output of wireless network information and GPS data with no set stop function; so when the power was removed from the pifi analyser, the script would immediately stop, regardless of what point it was up to. This resulted in many netxml outputs with partially written data at the end of the file as well as many file corruptions. This could be mitigated in future iterations of the project by incorporating a switch mechanism to power on and power off the device in a graceful manner, so that partial files are not written and potentially corrupted.

This leads to the final complication we encountered during the operation phase (and testing to some extent), that the outputs could only be viewed once the airodump-ng script stopped running. Many oversights arose from the assumptions that the hardware and software would function without significant error. During the PiFi Analysers operation, it was impossible to tell if the script was running properly, recording significant wireless network/client data and/or writing appropriate GPS location data. There were indication light on both the wireless receiver and the GPS receiver however they were often hidden from view and were still an unreliable indication of whether the data recorded would be significant. The only method we had of viewing the output files stored on the SD card, determining whether or not a scan was successful or not, was to SSH into the PiFi Analyser at a later stage after the operational session was well finished and powered off. Therefore our recommendation for future versions of the project would be to implement some sort of display or custom indication LEDs so that the user can determine in the field whether or not they are gathering useable data, their GPS location to determine if it is accurate and/or how many wireless networks are currently in range.

The analysis of the collected data provided the basis for many of the previously mentioned changes that we implemented in the name of facilitating configuration and outputs. Since we were using the netxml format for our outputs, we needed a method of transferring that data onto a geographical map through Google Earth. However, netxml is not compatible with Google Earth as an input format and needed to be changed to a format that is. We considered using netxml2kml.py, which is a python script that would perform the conversion to a more agreeable kml file for Google Earth.

29 | P a g e

However this script would encounter errors at the first sign of missing, incomplete and/or corrupted data on the netxml files. As mentioned previously, many of our netxml files were corrupted in this manner, so netxml2kml.py would not be beneficial. We eventually found a program call giskismet which would continue converting the netxml file regardless of missing, incomplete and/or corrupted results. Giskismet would add the data collected in the netxml to a sqlite3 database. This was beneficial in its own right since the ability to manipulate the data collected is much easier from a SQL database by submitting various queries through gisksimet which parses to sqlite3 to retrieve the specified data. Giskismet is then able to extract the information on the giskismet database into a kml, which is compatible with Google Earth.

The decision to use Google Earth over the originally intended Google Maps was largely based on the ease of use involving inputting kml files into an existing platform rather than writing a specific web application into a custom web page, which has to be hosted on a separate web server. This would also require additional security measures if we intended to publish our scans which includes private network and location data, in violation of the privacy policy we are implementing. Google earth also offers a better user interface when it comes to viewing the plotted information, the associated networks and 3D view support.

30 | P a g e

Conclusion Over the course of this project we have ascertained the ubiquity wireless network communications between wireless access points and wireless clients. The project also addresses the concept of using wireless monitoring as a means of physical reconnaissance with the assumption that the presence of an individual’s personal wireless devices can indicate the presence of the individual. Through building and configuring the PiFi Analyser device, we explored the technologies available to exploit the open nature of wireless communications as well as less explored configurations that might enable a greater scope of access. The airodump-ng tool showed us that wireless clients associated with wireless networks could be passively recorded and as a proof of concept we had shown that it is possible to plot that recorded data in conjunction with GPS location data. Although we did encounter errors when using the PiFi Analyser in the projects operational field scanning, primarily caused by faults associated with the GPS receiver component, data gathered and collated onto a map revealed the efficacy of the underlying procedures.

The premise combined with the objectives achieved over the course of the project should hopefully complement one’s understanding about the state of wireless communications and the associated risks surrounding them.

31 | P a g e

References Commonwealth of Australia (Australian Communications and Media Authority), (2014).Communications Report 2013-14. Canberra: Commonwealth of Australia (Australian Communications and Media Authority), pp.34-49.

Sophos.com, (2015). Wardriving and Warbiking | World of Warbiking | Sophos. [online] Available at: https://www.sophos.com/en-us/security-news-trends/security-trends/bottom-line/project- warbike.aspx [Accessed 10 Mar. 2015].

Wigle.net, (2015). WiGLE: Wireless Network Mapping. [online] Available at: https://wigle.net/ [Accessed 10 Mar. 2015].

Christie, S. (2013). War Pi. [online] Sans.org. Available at: http://www.sans.org/reading- room/whitepapers/networkdevs/war-pi-34435 [Accessed 10 Mar. 2015].

Wigle.net, (2015). WiGLE Stats. [online] Available at: https://wigle.net/stats [Accessed 17 Mar. 2015].

Catb.org, (2015). GPSd — Put your GPS on the net!. [online] Available at: http://www.catb.org/gpsd/#documentation [Accessed 24 May 2015].

Aircrack-ng.org, (2015). Main [Aircrack-ng]. [online] Available at: http://www.aircrack- ng.org/doku.php [Accessed 24 May 2015].

Commonwealth of Australia (Office of the Australian Information Commissioner), (2014).Privacy fact sheet 17 - Australian Privacy Principles. Canberra: Commonwealth of Australia. Available at: http://www.oaic.gov.au/images/documents/privacy/privacy-resources/privacy-fact-sheets/privacy- fact-sheet-17-australian-privacy-principles_2.pdf [Accessed 22 May 2015].

Migrate to the Cisco Unified Network. (2007). [online] Available at: http://www.cisco.com/c/dam/en/us/products/collateral/collaboration-endpoints/unified-ip-phone- 7900-series/product_at_a_glance0900aecd805df476.pdf [Accessed 20 May 2015].

32 | P a g e