Table of Contents Table of Contents ......................................................................................................................... 1 Table of Figures ............................................................................................................................ 2 Abstract ........................................................................................................................................ 4 Introduction .................................................................................................................................. 5 Ethics ............................................................................................................................................ 9 Research ..................................................................................................................................... 11 1.1 BCMON ....................................................................................................................... 11 1.2 IEEE 802.11 Standard .................................................................................................. 13 1.2.1 Data Frame .................................................................................................................. 13 1.2.2 Control Frames ............................................................................................................ 14 1.2.3 Management Frames .................................................................................................. 15 1.3 OSI (Open Systems Interconnection) Model .............................................................. 18 1.4 Android Operating System ......................................................................................... 20 1.4.1 System Architecture ..................................................................................................... 20 1.4.2 Android Rooting .......................................................................................................... 21 1.5 Android Studio ............................................................................................................ 22 1.6 Wi-Fi Adapter Modes ................................................................................................. 25 1.6.1 Managed Mode ........................................................................................................... 26 1.6.2 Monitor Mode ............................................................................................................. 26 1.6.3 Master .......................................................................................................................... 26 1.6.4 AD-HOC ........................................................................................................................ 27 1.7 Network Performance ................................................................................................ 28 1.7.1 Congestion ................................................................................................................... 28 1.7.2 Throughput .................................................................................................................. 30 1.7.3 RSSI .............................................................................................................................. 30 1.8 Challenges ................................................................................................................... 30 1.8.1 Obtaining Physical Layer Data .................................................................................... 31 1.8.2 Parsing and Displaying the Data ................................................................................. 31 1.8.3 Calculating the Performance Index ............................................................................. 32 Implementation .......................................................................................................................... 33 2.1 Rooting the Nexus 7 ................................................................................................... 33 2.2 Packet Capturing ........................................................................................................ 33 2.2.1 Tcpdump ...................................................................................................................... 33 2.2.2 Sockets ......................................................................................................................... 34 2.2.3 RadioTap Header ......................................................................................................... 35 2.3 Application Development .......................................................................................... 35 2.3.1 Android Application Layout ......................................................................................... 36 2.3.2 Android Application Code ............................................................................................ 38 2.4 Obstacles .................................................................................................................... 46 2.4.1 Opening a raw socket .................................................................................................. 46 2.4.2 Monitor Mode and Airodump-ng ................................................................................ 48 2.4.3 Memory Leak ............................................................................................................... 51 Results ........................................................................................................................................ 52 Conclusion .................................................................................................................................. 58 Recommendations ..................................................................................................................... 59 Appendices ................................................................................................................................. 61 4.1 Code A – Copy Assets ................................................................................................. 61 4.2 Code B – CSV Reader .................................................................................................. 62 4.3 Code C – Access Point Array Adapter getView function ........................................... 64 4.4 Code D – doInBackground Function ........................................................................... 66 4.5 Code E – content_ap_details ...................................................................................... 67 4.6 Code F – activity_ap_details ...................................................................................... 68 4.7 Code G – Android Manifest ........................................................................................ 69 4.8 Screenshots – O’Connell Street .................................................................................. 71 4.9 Screenshots – Stephens Green ................................................................................... 73 4.10 Screenshots – Georges Street .................................................................................... 75 Bibliography ............................................................................................................................... 76 Table of Figures Figure 1 - Project Overview ........................................................................................................... 7 Figure 2- Generic Data Frame [6] ................................................................................................ 13 Figure 3 - Control Frame Format [7] ........................................................................................... 14 Figure 4 - Management Frame Format [10] ................................................................................ 16 Figure 5 - Association and Authentication .................................................................................. 18 Figure 6 - OSI Model [12] ............................................................................................................ 19 Figure 7 - Android Architecture [13] ........................................................................................... 20 Figure 8 - Android Studio Layout [14] ......................................................................................... 23 Figure 9 - Android Building Blocks [16] ....................................................................................... 24 Figure 10 - NIC Demonstration of Modes [18] ............................................................................ 25 Figure 11 - AD-HOC network [19] ............................................................................................... 27 Figure 12 - Application Overview ................................................................................................ 36 Figure 13 - CSV Access Point Details ........................................................................................... 39 Figure 14 - CSV Client Details ...................................................................................................... 40 Figure 15 - Eclipse Memory Analyser .......................................................................................... 51 Figure 16 - Access Point List ........................................................................................................ 54 Figure 17 - Access Point Details .................................................................................................. 55 Figure 18 - Client List ................................................................................................................... 56 Figure 19 - Client Details ............................................................................................................. 57 DECLARATION I, the undersigned, declare that this report is entirely my own written work, except where otherwise accredited, and that it has not been submitted for a degree or other award to any other university or institution. Signed: _____________________________ Date: ________________ Abstract The purpose of this project is to develop an Android application using Android Studio that can analyse the Wi-Fi performance of multiple access points in order to better support hotspot selection. There are a few different modes that the Wi-Fi chip can operate in, which are: Managed, monitor, master and AD-HOC. The default mode of most Wi-Fi chips is managed mode. In managed mode all wireless packets that are not intended for that specific device are ignored. In monitor mode these packets are not ignored and can be used for analysis. This is commonly referred to as packet sniffing. The performance will be analysed by putting the Wi-Fi chip on an Android device into the monitor mode and capturing transmitted traffic using a packet capturing tool called airodump. The results from this traffic analysis will be used to determine which access point is the optimal one to connect to. This decision will be made using a weighted scoring system known as a performance index (PI). Multiple parameters such as signal strength, throughput and congestion that will be appropriately weighted based on their relative importance to the networks performance. The access points with the highest rated PI will be displayed at the top of the list in the application. The PI value will be colour coded to quickly and easily display to the user the performance levels that are offered by that access point. The colour will be green for the best performance, orange for average and red for poor. This value will be displayed next to the ESSID of the access point to indicate its level of performance. Due to this the application has been given the name WI-PI for Wireless Performance Index. Most applications similar to this only consider the Received Signal Strength Indicator (RSSI). This metric by itself is not a good enough indication for measuring the performance of a network. The reason for this is that a networks performance can be heavily reduced depending on the number of clients connected to it (congestion) and how much data they are transmitting/receiving (throughput). On account of these other factors, it would be more efficient to use an access point that has a lower signal strength but with little to no congestion or throughput. To develop the Android application Android Studio will be used. This is a powerful and intelligent code editor developed by Google that is used to develop android applications. XML coding will be used to design the layout of the application and Java will be used to add functionality to the program. Most Android devices wireless chipsets do not support the monitor mode. Fortunately, a team of developers have developed an Android application called BCMON which essentially reverse engineers the drivers of the BCM4329 and BCM4330 Broadcom chipsets. This project was developed based on the work done by this team. The Android application was developed using The Nexus 7 Android tablet. This was done as it uses the BCM4330 chipset. Introduction This project was developed based on the work done by the BCMON team. The BCMON application enables the monitor mode on the wireless chipset of certain Android devices. It also allows for the support of the aircrack-ng suite which contains the airodump-ng tool. This tool allows for wireless packets from surrounding wireless networks to be captured and stored in a file. The way the BCMON team implemented their library functions and tools in their application could be determined by analysing the BCMON applications source code. With this information this functionality could be implemented into the Wi-PI application. Now with the ability to execute an airodump, information regarding the various surrounding networks and their associated clients could be captured. This information could then be analysed to determine which network could offer the best performance. After the analysis has been completed all the information regarding the access points and their clients could then be displayed in an Android application. Generally most wireless devices, when searching for a wireless network to connect to, will just display a list of access points to the user that is sorted based on RSSI (Received Signal Strength Indicator) levels. However, when it comes to the performance of a network, the RSSI on its own is not a good indicator. Other factors such as congestion and data traffic play a part as well. This application hopes to create a performance index which takes into account all these factors and weight them against each other based on their relative importance. Their importance will depend on how much they affect the performance of a network. So if one factor has a significant impact on performance when compared to other factors, then this factor will be given a larger weighting in the performance index. This performance index will be applied to all the surrounding networks and they will then be sorted based on the highest performance index. The higher the score of the network, the better it will perform. The hope for this project is that it will replace the current method for how wireless devices choose which network to connect to. This application allowed for a burst mode where the monitor mode and the airodump tool would run continuously for 20 second intervals. When the airodump is enabled the previous data would be deleted and the cycle would continue again after 20 seconds. The purpose of this was to try and reduce battery consumption as the use of the monitor mode and the airodump tool is heavily impacted by this. There was also a manual mode where the Wi-Fi traffic could be continually captured and stored until the user cancelled the operation. This also allowed for the ability to enable and disable the monitor mode manually. An overview of the project can be seen in Figure 1 - Project Overview. cnri 5/30/16 10:17 AM Deleted: massive WI-FI Adapter in Monitor Mode WI-FI Packets User Airodump files Access Point 1 Access Point 2 WI-FI Packets Access Point 3 WI-FI Packets UserUser Read/Write Android Application AP1 PI: 100 AP2 PI: 90 AP1 PI: 80 Figure 1 - Project Overview The Android device’s WI-FI adapter is set to monitor mode so that it can capture all WI-FI packets and so that all the packets headers stay intact. The packet capturing will be performed using airodump and the data will be stored in multiple files for analysis. The files will be analysed so that a performance index for each of the surrounding access points can be developed. The details of the access points and their associated clients will be displayed in an Android application. Beside each of the access points names will be the performance index value. The importance of performance with regards to wireless networks is becoming increasingly more important. This is because people are becoming more dependent on wireless internet and the idea of being “always connected”. This has led to a rise in WiFi enabled devices, higher broadband speed, rise in content that is streamed online, etc. This increase in wireless dependence is leading to an “Internet of Things” (IoT) kind of society. The “Internet of Things” is a concept where nearly every object will be connected to the internet and to each other through a wireless connection. This will essentially create a network of networked devices. In 2020, it is expected that there will be over 20 billion connected devices [1]. This dramatic increase in connected devices will lead to a negative impact on a networks performance due to factors such as an increase in congestion, data traffic, decrease in available bandwidth, etc. To help combat these problems there needs to be a way to better manage how people connect to their surrounding networks. That is what is hoped to be achieved by this application. The usefulness of this application extends beyond just efficiently managing wireless networks. There has been an exponential growth in mobile data usage. Mobile Network Operators (MCO) are being forced to try and find alternative ways to offload some of this traffic. In America MCOs are expecting to offload 60% of their traffic onto Wi-Fi over the next four years [2]. What happens is the MCOs would pay local businesses and shops so that users can access their wireless network for free. The problem with this method is that there is no guarantee that the network will be able to continue providing a good quality and reliable service. This application could potentially be a useful tool in helping MCOs decide on which of the available networks can provide a reliable enough service if they were to offload some of their traffic. Due to this, surrounding cell towers will experience less congestion. This will result in less money will need to be spent on growing the mobile network infrastructure and more money can be spent on improving technologies. Ethics The IEEE computer society has developed a code of ethics governed by 8 principals in which software engineers are expected to follow. This code of ethics helps to set a standard that software engineers should try to meet. Without this code of ethics the standard of the software produced from software engineers would be much lower than what it is today. If this code of ethics was not followed by software engineers then there would be a great deal of software with bugs and vulnerabilities that could compromise the privacy and safety of the users. Due to this it is important that these guidelines are followed. Also, by following these codes of ethics a software engineer can earn respect in their profession. The 8 principals within the code of ethics for software engineers are as follows: 1. Public - Software engineers are expected to work in the interest of the public by only producing software that they believe to be safe and up to a good standard. Without this the public could be subjected to more malicious software or software that does not work so well. This could lead to their personal information being compromised. 2. Employer and client - They should show the same interest in their employers and clients as they do with the public. It would be unfair for a software engineer to only concentrate on the needs of the public and not the needs of their employers or clients. 3. Product – The product produced should be of a high professional standard that has been rigorously tested and debugged before being released. This would also lead to an increase of poor quality software that could diminish user experience if not followed. This poor quality software could also tarnish the company’s name. 4. Judgement – They should be able to give their own professional opinions in relation to software or documents that they are evaluating and not try to deceive others financially. Being able to give a professional opinion is important for when an employer, client or member of the public asks a question in relation to the software, the software engineer should be able to answer the question in some form. It is also important that they do not try and financially deceive their client or the public as this can also tarnish a company’s name and the software engineer’s name. 5. Management – Managers in software engineering should encourage the use of ethics in the work of the software engineers they are managing. This will help increase the amount of software engineers that take an ethical approach to their work. 6. Profession – Software engineers should not try to tarnish the reputation and integrity of the software engineering profession and should take responsibility for ensuring that the software works well before being released. By giving software engineering a bad name it affects every other software engineer. 7. Colleagues – Offer help and support to colleagues and give credit to the work of others where necessary. It is important not to plagiarise other people’s work and offer help to others leads to increased productivity. 8. Self – keep up to date on new technologies and ideas in their profession and perform their work with an ethical approach. New tools software tools to increase efficiency and productivity when designing software are being developed very often. Keeping up to date with these new technologies allows for software to be developed easily and efficiently [3][4]. While the code of ethics provides a good guideline for software engineers to follow it is not without its problems. A software engineer is not legally required to follow these rules although some areas are covered by law. For example, it is illegal to develop malicious software that will steal people’s personal information. However, it is not illegal to intentionally leave errors in a program that don’t affect its overall functionality. The standard of software produced would increase much more if engineers were legally required to follow the code of ethics. Research The topics that were researched in order to implement this project are covered in this section. The first topic that will be covered is the software. This will explain what software was used and why it was used. Next is an explanation of the IEEE 802.11 protocol that was developed for wireless packet transmission. The OSI (Open Systems Interconnect) model will then be covered. Following this will be an explanation of the Android Operating System. This is then followed by the different modes that are supported by the wireless chipset such as the monitor mode, is an integral part to this project. The factors that affect a networks performance will then be covered and then finishing with the challenges that were expected to be encountered. 1.1 BCMON The BCMON team developed the BCMON application for the purpose of being able to access a wireless network to which the user had forgotten the password for. They did not want the inconvenience of having to use a laptop and start running the aircrack-ng suite from there. For this reason they decided to try and find a way to make the aircrack-ng suite compatible with Android devices [5]. First when running iwconfig in a terminal emulator they noticed that the wireless interface specified eth0 as opposed to wlan0. This was unusual as it appeared to be that the wireless interface was acting as an Ethernet interface and the data frame had more of a similar format to that of an Ethernet data frame. This posed a problem for them as the aircrack-ng suite uses data obtained from the IEEE 802.11 Wi-Fi headers. This lead the team to the assumption that the frames were sent as Wi-Fi frames but where translated to Ethernet frames by either the Wi-Fi chipset or the Linux kernel [5]. They started with the Linux kernel as it is open source so it was easier to deal with. They were trying to find where in the code the kernel receives the frame from the cnri 5/30/16 10:22 AM Deleted: is wireless chipset. After finding this they realised that the translation had already been performed, meaning that the translation occurs in the wireless chipset. After some research they found that Wi-Fi chipsets either use a soft MAC approach or a full MAC approach. On soft MAC the device handles all packet manipulations and on full MAC the Wi-Fi chipset manages the packet manipulations. Their device appeared to use the full MAC approach which meant that they needed to enable the monitor mode on the Android devices wireless chipset to be able to run the aircrack-ng suite. The monitor mode is needed as in this mode the wireless chipset will not perform any manipulations on the packets. To do this they would need to reverse engineer the drivers [5]. Now the goal was to try and get the firmware and patch it so that it supports the monitor mode but first it had to be established if the firmware could be patched at all. They modified the firmware version string and recompiled the driver. This method worked as the firmware didn’t check for verification to see if it had been modified. Next they had to start looking for references to Wi-Fi frames. To do this they looked for LLC (Link Layer Control) headers which are only present in Wi-Fi frames. After finding these references they then found the function that translates the wireless frames to Ethernet. Finally all they had to do was bypass the translation. Now they had monitor mode support and could capture wireless packets. Packet injection support was then added so now they could send and receive raw Wi-Fi packets [5]. With the monitor mode support now added they tried to support different wireless chipsets. They were only able to support two different Broadcom chipsets as they were quite similar so similar methods could be used. Now the only problem was that the Kernel needed to be compiled while using this method and that takes a long time so they tried to find a simpler solution. This was done by encapsulating the Wi-Fi packet with an Ethernet header and transmitting it straight to Linux. Now the LD_PRELOAD feature could be used to run airodump with their own library functions [5]. 1.2 IEEE 802.11 Standard The IEEE 802.11 standard is a standard that is used for wireless networking developed by the IEEE (Institute of Electrical and Electronic Engineers). This standard is used to define which devices are compatible with IEEE 802.11 networks. The three most important frame types in this wireless networking standard are data frames, control frames and management frames. 1.2.1 Data Frame The data frame quite simply contains the data payload that is to be transmitted between network nodes. There are various types of data frames. There are three main parts to the data frame which are the MAC Header, Frame body and the checksum. Figure 1 – Generic Data Frame below shows an example of a general data frame. Depending on the type of data frame some of the fields may not be used. Figure 2- Generic Data Frame [6] 1.2.1.1 MAC (Medium Access Control) Header: The MAC protocol is a sub layer of the Data Link Layer and it defines how to access the wireless medium and the components of the Data Link Layer. The max size the MAC Header can be is 36 bytes as seen in Figure 2- Generic Data Frame [6]. The MAC Header contains information such as who the frame is destined for, who has transmitted the frame, filtering by access points and the distribution system, etc. For the purposes of this project the MAC header is the only part of the data frame that is required as this contains all the information about the network and the client. The information in particular that is of interest to this project would be RSSI, ESSID, BSSID, number of clients, etc. The RSSI gives an indicator of how strong the wireless signal is. The closer the client is to the access point, the stronger the signal will be. The range is usually around -30dBm to -100dBm with -30dBm indicating the strongest signal strength. The ESSID is the Extended Service Set Identifier, commonly known as SSID, refers to the name of the network. The BSSID is the Basic Service Set Identifier which is a MAC address used to identify individual access points under the same WLAN (Wireless Local Area Network). 1.2.2 Control Frames The control frame is used in conjunction with the data frame to help successfully deliver a wireless packet between nodes. There are three main types of control frames which are request to send, clear to send and acknowledgement. Figure 3 - Control Frame Format [7] below shows the generic format of a control frame. Figure 3 - Control Frame Format [7] 1.2.2.1 Request to Send (RTS): The RTS frame is an all header frame that that is used to ensure the successful transmission of large frames. An RTS frame does not have a frame body. This is used to prevent collisions from occurring as the network must perform an RTS/CTS exchange if it wants to transmit a frame. It is also used as a medium clearing mechanism that was introduced to try and deal with the “hidden node” problem. This is when two nodes within a cell can hear the access point but not each other [8][9]. 1.2.2.2 Clear to Send (CTS): The CTS responds by accepting or rejecting RTS frame. It is also involved with the medium clearing mechanism used to deal with the “Hidden node” problem and it also has no frame body [9]. 1.2.2.3 Acknowledgement (ACK): The ACK frame is used to indicate that the transmitted frame was correctly received, i.e. error free. If the ACK frame is not received then the transmitted frame is retransmitted [9]. 1.2.3 Management Frames There are multiple types of management frames that are used to establish, maintain and end communications. Figure 4 - Management Frame Format [10] shows a generic management frame. Figure 4 - Management Frame Format [10] 1.2.3.1 Beacons: A management frame that is used to indicate that an access point is available for clients to associate with. These beacon frames are regularly transmitted by an access point which allows for wireless client devices to find and identify the network. They contain information such as the SSID, supported transmission modes and rates, etc. Beacon frames also help to define the area in which the network can be accessed from. So if a device is not close enough to receive a beacon frame then it will not be able to connect with the network [9]. 1.2.3.2 Probe (Requests and Responses): Probe requests are management frames transmitted by a client in response to a beacon to determine if an IEEE 802.11 network is in range. The probe request will contain information such as the modulation schemes and the data rates that the client supports. For the client to join the network they must support all the data rates that are required by the network. If a network receives a probe request from a client and the client’s parameters match the networks, then a probe response frame will be sent to the client. Whichever network sent the previous beacon will be the one that has to respond to any probe requests from clients [9]. cnri 5/30/16 10:25 AM Deleted: ’ 1.2.3.3 Association (requests, responses and disassociation): After the client has received the probe response which specifies that the network and the client are compatible then the client will send an association request frame. Requests are a form of management frame sent from one station to another to allow for effective communication. The response will either be accepted or rejected. When two stations want to disconnect they send a disassociation frame [9]. 1.2.3.4 Reassociation (Request and Response) If a client leaves the service area covered by the network then they will be disassociated with the network. If the client returns shortly after then the client will be required to send a reassociation request frame to the network to regain access. This will also happen if the client moves between different access points within the same network. The only difference between an association and reassociation request is that the reassociation frame will contain the clients’ current access points address. This allows the clients previous access point to transfer the data to the new access point. The response from the access point is the same as the response for an association request except for the subtype field in the frame control field [9]. 1.2.3.5 Authentications (Authentication and De authentication): The authentication stage decides whether or not the client will be given access to the network. The client will send an authentication frame to the network. The network will respond with an authentication frame containing a challenge text. The client will then have to respond by sending an authentication frame with the encrypted key for the network. Once the network decrypts the key then the network will send an authentication frame to the client with the results of the authentication. De authentication will then occur if the network sends a de authentication frame to the client. This will terminate the connection between the client and the network even if authentication was previously valid [9]. The different stages of association and authentication can be seen in Figure 5 - Association and Authentication below. Figure 5 - Association and Authentication 1.3 OSI (Open Systems Interconnection) Model The OSI model is a model that is used to describe the steps taken to transmit data across a network from one device to another. It breaks down the different components of network communication into separate layers. • The application layer is closest to the user and serves as a window for the user access application services and processes. • The transmission layer uses TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) to transmit data without error. It also governs how data is combined into separate packets before transmission. • The network layer uses IP (Internet Protocol) to manage the addressing and routing of the packets. State 2 State 3 State 1 • The Data Link Layer is concerned with how devices are connected. This could be through a wired connection, such as Ethernet, or a wireless connection such as Wi-Fi. It either transmits packets, at the bit level, in the form of frames. When data is being received it is constructed into frames from the data received by the hardware. • The physical layer is the lowest layer in the IEEE 802.11 standard. This is because it is the closest layer to the hardware. It covers the hardware aspects such as cabling, voltages, pin diagrams, etc. here the data is transmitted/received in its most raw form through either a network cable or a wireless radio [11]. The IEEE 802.11 protocol is only concerned with the Physical Layer and Data Link Layer. When data is passed through each layer a header is either added or removed from the data depending on whether it is being transmitted or received. The stages for a packet that is being transmitted are as follows: • The application layer attaches the application header. • The transport layer attaches the TCP/UDP header. • The network layer attaches the IP header. • The data link layer attaches the Ethernet header from the packet. • The packet is transmitted by the physical layer as a raw bit stream of data. Figure 6 - OSI Model [12] 1.4 Android Operating System The Android OS is an operating system that is based upon the Linux kernel. The Android operating system is currently owned by Google and is an open source OS which means that it can be freely modified and distributed by anyone. 1.4.1 System Architecture The architecture of an Android OS can be seen in Figure 7 - Android Architecture [13] below. There are five layers in the Android architecture which are Kernel, Libraries, Android Runtime, Application Framework and Application. Figure 7 - Android Architecture [13] The Linux kernel is used as the hardware abstraction layer. This kernel provides a lot of core operating system infrastructures that are robust and reliable such as memory and process management, a security model, networking, etc. [13]. The next level up from the Kernel are the native Android Libraries. These are all written in C and C++ and they provide functionality such as composing different drawing surfaces onto the screen, managing databases, managing 2D and 3D graphics, etc. [13]. Next is the Android Runtime which contains the core libraries of the OS. The main component here is the Dalvik Virtual Machine. The Android Runtime was designed to be able to run an embedded environment where there are limited resources such as battery, CPU, storage, etc. The Dalvik Virtual Machine runs files with the extension of DEX. These files are the result of building JAR and CLASS files at runtime. The reason conversion is done is because it allows for a more efficient byte code which is useful for small processors [13]. The next layer up from Android Runtime is the Application Framework which is all written in Java. The Application Framework is the toolkit that all Android applications use. It is used to help manage the life cycles of applications, shared data between applications, location, resources, etc. [13]. The final layer in the Android architecture is the Application layer. This layer is the one that the user will have most interaction with. Within this layer will be all the Android applications that are installed on the device [13]. 1.4.2 Android Rooting Enabling root access on an Android device gives the user the ability to write to the root of the system partition. This allows the user to have a lot more control over the device than what was previously possible as they can enable super user access, the same as it is on other Linux operating systems such as Ubuntu. The root access is an integral part of this project as it is needed to: • Enable read/write permissions to certain files and folders. • Enable the monitor mode on the devices Wi-Fi chipset. • Run the airodump tool which is used for capturing raw IEEE 802.11 frames. Android manufacturers purposely restrict the user from having root privileges. This is done because having root privileges can lead to security concerns due to having the ability to modify the systems software code. Ideally this application would not require root privileges so that the installation processes would be much more user friendly, allowing for access to a wider user base. Due to costs and poor demand, Wi-Fi chipset manufacturers do not consider the monitor mode a worthwhile feature to implement on an Androids Wi-Fi chipset. As a result root privileges are required so that the firmware of the Wi-Fi chips driver can be modified to support monitor mode. With root access and monitor mode support, there are numerous tools that can be used to help monitor the performance and vulnerabilities of wireless networks. For the purposes of this project, the airodump tool from the aircrack-ng suite is the only tool that is required. 1.5 Android Studio Android Studio is the official software that is used for developing Android applications. It is based off of the IntelliJ Idea platform. This platform supports a powerful code editor along with a wide array of tools for developers to use. This software allows for the use of Android device emulation and supports a wide array of Android devices which can be used to run/debug any application that is being developed. Also supported are application templates to help get the developer started. Android Studio uses Gradle to build applications by using an array of tools that compress the necessary project files into an apk file. An apk file is the install file used to install an Android application on an Android device [14]. The layout of this program can be seen below in figure 8 – Android Studio Layout. Figure 8 - Android Studio Layout [14] 1. The toolbar contains helpful tools that allow for the developer to run, debug, save the application and much more. 2. The navigation bar is then displayed below the toolbar which show the current project path and allows for easy navigation. 3. The editor window is where the developer can write/read/modify the code to develop the android application. This window will display the currently selected java or XML file. 4. On the left is the tools window which allow the developer to view a more detailed view of the project than the navigation bar. 5. At the bottom of the screen is the status bar which will notify the developer of any warnings or errors and the status of the project [14]. There are four main building blocks within an Android Application which are an Activity, Broadcast Receiver, Service and Content Provider. An Activity is a single window in which UI elements are placed and users can interact with. This doesn’t have to be a full screen window it can also be a floating window. A Broadcast Receiver responds to system wide notifications or status changes. This will not be executed until something triggers it to execute. This can be used for changing activities, e.g., when an item in activity one is pressed execute an intent to switch to activity two. A Service is then a task that doesn’t have any UI elements and runs in the background. An example of this would be when running an airodump. The user would navigate to the button that executes the airodump and then the airodump would run in the background while the user can still navigate through the application. The final building block is then the Content Provider which allows the user to share data between applications [15]. Figure 9 - Android Building Blocks [16] A common mistake that people make when developing an Android application is that they block the main thread. The purpose of the main thread is to keep the user interface responsive. Generally, a user will consider anything below 24 frames per second with a delay that is bigger than 100ms to be choppy and non-responsive. Depending on what the application was designed for, this could render the application useless. One area where responsiveness would be very important would be games as they require quick responses from the user [17]. If an activity blocks the main thread for five seconds or a broadcast receiver blocks for ten seconds, then the application will become unresponsive and the user would be prompted to close the application or wait. This was such a big problem in earlier versions of Android that now later versions will not allow developers to make network calls on the main thread. The main thread can be blocked by network calls, bitmap loading, image processing, database querying and SD reading/writing [17]. By default, Android applications are set to run off of the main thread but any operation that takes a long time to perform should not be performed on the main thread. Instead a worker thread should be developed to handle the process. This helps to keep the UI running smoothly while the time consuming process runs in the background. 1.6 Wi-Fi Adapter Modes There are various different modes that the Network Interface Controller (NIC) can operate in, which are: managed, monitor, master and AD-HOC. The NIC can only operate in one mode at a time [18]. A brief overview of how NICs can communicate with each other, depending on the mode they are in, can be seen in Figure 10 – Demonstration of NIC Modes. Figure 10 - NIC Demonstration of Modes [18] 1.6.1 Managed Mode The default mode of most Wi-Fi interfaces is the managed mode, commonly known as client or station mode. NICs in this mode will only communicate with an access point. For a NIC to communicate with an access point it must first be associated with it. Association is explained in further detail in section IEEE 802.11 Standard – Management Frames. In the managed mode all wireless packets that are not meant for that specific client are ignored and there is no way of accessing the management and control frames. Only the data frames are accessible [18]. 1.6.2 Monitor Mode When the NIC is in the monitor all wireless traffic is captured and access is available to data, control and management frames. The packets can be captured without being connected to a specific access point, but only packets from a single wireless radio channel can be captured. A TCPDUMP can then be performed to store the captured packets so the data from the packets can be analysed. This will give information such as the packet size, transfer rate, MAC addresses of network users, signal strength, packet errors, etc. For the purpose of this project the NIC of the Android device will be put into the monitor mode so that this information can then be processed to determine which of the surrounding access points will be the optimal one to connect to [18]. 1.6.3 Master Mode When the NIC is in master mode, also known as access point mode, it acts as an access point. It transmits the SSID in its beacons so that it can be identified by clients and then connected to. In this mode the NIC can only communicate with clients [18]. 1.6.4 AD-HOC Mode With the NIC in AD-HOC mode each station simultaneously acts as both a client and an access point. These stations are then interconnected to make a peer to peer network. The Basic Service Set (BSS) is the service area offered by the access point. In this set up, the BSS of each station is combined and is referred to as an Independent Basic Service Set (IBSS). To have an IBSS system there must be more than one station. Figure 11 - AD-HOC network [19] With an IBSS network only stations that are within range of each other’s BSS may communicate with each other. Stations are not able to communicate through other stations thus this type of set up is quite restricted. For example, in Figure 11 – AD-HOC network station A cannot communicate with station D as it is not within its BSS, however station C can communicate with all stations but it cannot link station A to station D [19]. 1.7 Network Performance There are three main factors to consider when dealing with a networks performance and these are congestion, throughput and signal strength (RSSI). This section will discuss these three metrics. 1.7.1 Congestion Network congestion can be caused by having too many active users associated with the one access point. This limits the amount of available bandwidth. Congestion can also be caused by the amount of information that is being downloaded and uploaded by each individual user. Downlink is when the access point provides information to the user and uplink is when the user provides information to the access point. The rate at which this is done is known as throughput and is measured in Mbps. If a user has a high throughput, then they will be limiting the available bandwidth to other users. This is because the MAC mechanism used in the IEEE 802.11 standard is contention based where users must compete with one another for access to the medium in order to transmit their frames. The IEEE 802.11 protocol has two modes for communication which are Distributed Coordination Function (DCF) and Point Coordination Function (PCF). However, PCF is very rarely implemented and is of little importance to this project so it will not be discussed [20]. cnri 5/30/16 10:33 AM Deleted: points cnri 5/30/16 10:33 AM Deleted: 1.7.1.1 Distributed Coordination Function: This uses Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA). CSMA/CD is not used as it would increase costs and it is based on the assumption that not all access points will be able to hear each other. DCF uses CSMA/CA basic access mechanisms. These help deal with frame transmissions and collisions [20]. • Stations only transmit frames when no other station is currently transmitting. This is known as the contention period. When the wireless medium is free and the contention period has ended, then stations that are waiting to transmit will start transmitting. If the frame was successfully received by the receiving station, then it will transmit an acknowledgement frame to the sender. A possible cause of a collision could be hen there is no acknowledgement received. In this case the frame would be retransmitted after the next contention period [20]. • Collision can be reduced by using different types of guard times known as inter frame spaces (IFS). A channel is considered to be idle of there are no transmissions detected or if the Network Allocation Vector (NAV) is zero [20]. Another mechanism that DCF uses is Request to Send (RTS)/Clear to send (CTS). This method consists of a 4-way handshake (RTS, CTS, DATA, ACK). When the station wants to transmit a data frame it first transmits a RTS frame. The receiving station will then respond with a CTS frame if it is idle. If the transmitting station doesn’t receive the CTS frame, then it will again begin competing with other stations for the wireless medium. After receiving the CTS frame, the data frame is now free to be transmitted and when the receiving station receives the data frame, with no errors, it will respond with an acknowledgement frame [20]. 1.7.2 Throughput When it comes to a network’s performance throughput is one of the most important aspects. The throughput from an access point shows the amount of activity the network is experiencing. It is useful for trying to determine a network’s speed and efficiency. The higher the throughput, the lower the performance for a new client joining the network. Bandwidth is then the maximum amount of data that can be transmitted through the access point. The more bandwidth that is available, the better the performance of the network. Throughput is measured by the amount of bits per second of data that can be transmitted across a network. This can be calculated using the formula below. Throughput = # 𝑏𝑦𝑡𝑒𝑠 𝑠𝑒𝑛𝑡/𝑟𝑒𝑐𝑒𝑖𝑣𝑒𝑑𝑥 8 𝑏𝑖𝑡𝑠 𝑡𝑖𝑚𝑒 𝑡𝑎𝑘𝑒𝑛 𝑡𝑜 𝑠𝑒𝑛𝑑/𝑟𝑒𝑐𝑒𝑖𝑣𝑒 There are a few ways of addressing this problem, such as increasing the amount of available bandwidth, reducing the amount of congestion by reducing the amount of clients or by compressing the data that is being transferred. With the aid of these methods the networks performance can be better optimised [21]. 1.7.3 RSSI The RSSI levels are also an important factor when it comes to a networks performance. It may not be as important as the quantity of clients or the throughput levels but it is still important. The further away a device is from a network the slower the data rates will be as a consequence of the line rate adaptation mechanism employed at the physical layer to minimise the error rate on the link. 1.8 Project Challenges cnri 5/30/16 11:12 AM Deleted: After researching the project it, there was a few areas that appeared as though they would be challenging. These areas are explained in the following headings. 1.8.1 Obtaining Physical Layer Data Obtaining the physical layer data looked to be a challenging task as it involved needing to put the Android devices’ wireless chipset into the monitor mode. Also the ability to use the airodump tool was also required. To achieve both of these tasks it would mean that the methods the BCMON team used for achieving this would need to be found by sifting through the source code for their BCMON application. These methods would then need to be recreated in the Wi-PI application so that the same functionality could be achieved. To extract the source code from the BCMON application the files should be unzipped from the .apk file. Using the program called “dex2jar” the classes.dex file that was extracted from the apk file can be converted into .jar files. The .jar file can then be opened using a program called “jdgui”. The Java files of the apk will then be accessible. 1.8.2 Parsing and Displaying the Data After executing an airodump four files are created in which the data is stored. These files would need to be parsed so that the relevant data such as the network and client details, can be extracted. Once the data is extracted it would the need to be displayed in the Android application. 1.8.3 Calculating the Performance Index After extracting the data from the files, the data needs to be analysed so that a performance index can be developed. The performance index will be used to display to the user, which network can offer the best performance. This index will range from a scale of 0-100 and will take into account factors such as RSSI, throughput and the number of clients associated with the access point. These parameters will need to be weighted according to their relative importance and the score applied to the access point will also need to be displayed beside the access point’s name. The list of access points should be sorted according to the highest performance index. cnri 5/30/16 10:37 AM Deleted: will Implementation 2.1 Rooting the Nexus 7 The process of rooting the Nexus 7 was a fairly simple one. First the bootloader needed to be unlocked. To do this a program called “Wugs Nexus root toolkit” was downloaded. After installing this program the Nexus 7 was then connected to the computer with USB debugging enabled. In the device manager on the computer the Nexus 7 was selected and the “manually install drivers” option was selected. The directory of the Nexus toolkit program was located and the custom drivers were selected. This allows the computer to talk to the Nexus as if it was an ADB (Android Debugger) interface. Now the program that was downloaded earlier was launched. In this program the model of the device was selected and then the unlock button should be pressed. On the Nexus the user will be prompted to press either yes or no for if they want to unlock the bootloader. In this case “yes” was selected. The device restarted when it was finished. USB debugging needed to be enabled again as unlocking the bootloader performs a factory reset on the device. After completing this the “root” button in the Nexus root toolkit program was selected. This button rooted the device and when it restarted root access was available. 2.2 Packet Capturing 2.2.1 Tcpdump Tcpdump is a network tool used to capture and analyse Wi-Fi packets. These packets can be stored in a .pcap file to be analysed at a later date or on a different device. This information can also be displayed on screen. Using Tcpdump allowed for the ability to capture all packets being sent to the Nexus 7. To do this the Tcpdump binary was Nadya alabri 3/3/17 9:28 AM Formatted: Font:(Default) +Theme Headings, Font color: Accent 1 downloaded and stored on the root directory of the Nexus 7 tablet. An Android terminal emulator window was then opened. The terminal window above shows the sequence of events required to perform a Tcpdump and are as follows: 1. Super user access was granted using su. 2. The system folder was then mounted as rewritable 3. The tcpdump binary file was copied to the xbin folder within the system folder. 4. The directory was then changed to this location 5. The tcpdump binary file was given full permission using chmod 777. 6. Tcpdump was the run and saved to the SD Card. While tcpdump was running a few websites were accessed in order to capture packets. The Tcpdump capture was then stopped and the android terminal was then exited. After transferring the file to a laptop the .cap file could then be analysed using Wireshark. 2.2.2 Sockets Anything in UNIX that uses IO, uses a file descriptor (which is an integer associated with an open file). To get this file, a call is made to the socket () system routine. Send and receive socket calls are used to communicate through this file descriptor. The two types of sockets that will be encountered are SOCK_DGRAM (datagram socket) and SOCK_RAW (raw socket). With a datagram socket there is no need to maintain an open connection and are used in applications such as online gaming, streaming audio and video. In online gaming dropped packets are ignored. This results in a jitter in the game known as lag. TCP is good for reliability, e.g. chat messages and UDP is good for speed, e.g. gaming and streaming services [22]. Originally the physical layer information was going to be captured by performing a tcpdump whilst in monitor mode. The result of this was a cooked capture. A cooked capture is a pseudo-protocol used by libcap that when the native link layer header is cnri 5/30/16 10:41 AM Deleted: , cnri 5/30/16 10:40 AM Deleted: , unusable or unavailable. To perform a cooked capture, the data is read from a datagram socket rather than the raw socket. When using a datagram socket there is no access to the link layer header so a synthetic link layer is constructed by libcap. This header is constructed from the address that is supplied when recvfrom() is called on the socket. All the traffic that is received will be in the SLL format [22]. A raw socket is used to bypass the transport layer by going directly from the network interfaces driver directly to the application. Only the user with root access can create a raw socket. This prevents normal users from writing their own IP datagrams to the network. Port numbers are not involved with raw sockets. Using the function bind will set the source IP address of the datagrams that will be sent on the raw socket. If the datagram arrives in fragments, nothing is passed to a raw socket until all fragments have arrived and have been reassembled [22]. With the use of a raw socket, the data from the packet can be sent straight to the application completely unmodified. This means that all the headers will still be intact and can be examined or else modified using packet injection. This would be done through the use of programming languages such as C, C++ or python. 2.2.3 RadioTap Header Before the airodump tool was going to be used to get the physical layer information about the network a RadioTap header was to be used. This is a header that is injected onto the wireless packet after capturing. From this header information such as the RSSI can be determined. Although it was unsure as to whether or not this method would be able to provide all the required information in order to enable this application to succeed. For this reason attentions were focused elsewhere [23]. 2.3 Application Development cnri 5/30/16 10:42 AM Deleted: o The Android application for this project was developed in Android Studio. This section will cover the design of the application and how the functionality of the application was implemented. 2.3.1 Android Application Layout An overview of the application layout can be seen below in Figure 13 – Application Overview. The first screen is the main screen and it shows the list of activities along with their corresponding performance index value. The second screen will display the details of the user selected access point. The user can the select the client’s option at the bottom of this screen to be taken to the third page, a list of clients that are associated with that access point. When one of the clients are selected the user will be taken to the final page which displays the details of the selected client. Access Point 1 Access Point 2 Access Point X Un-associated Clients MAC First Time Seen …. BSSID MAC First Time Seen …. BSSID MAC First Time Seen …. BSSID Client 1 Client 2 Client 3 Clients 4 Client 1 Client 2 Client 3 Clients 4 BSSID First Time Seen …. Clients BSSID First Time Seen …. Clients MAC First Time Seen …. BSSID List of Access Points Access Point Details List of Clients Client Details Figure 12 - Application Overview cnri 5/30/16 10:42 AM Deleted: ’ Each user interface in the application is described using XML (Extensible Markup Language). There are two main types of XML files which are activity files and content files. The activity files will cover the general UI (User Interface) of the page whereas the content XML file will define specific UI element in the page. Examples of content XML files would be different views such as TextView or ImeageView which could be used to inflate a row in a ListView. The content that is to be displayed in the application will be displayed in these Views. The code for the content_ap_details can be seen in Appendices – Code E – content_ap_details. The root element of this XML file is the layout. The layout being used here is a linear layout. This allignal all of its children elements either horizontally or vertically. In this situation the child elements are needed to be horizontally orientated. This is because the headings and the details are displayed side by side. So in the first row heading one and detail one will be displayed. The child elements in this file are two TextViews. The activity XML file can include multiple content XML files. The code for the access point details activity can be seen in Appendices – Code F - activity_ap_details. The root element of this file is a coordinator layout. This is used to help coordinate between child views. The child elements that are defined within this are the app bar layout, the frame layout, the ListView and the floating action button. Then there is the android manifest file which is used to difine define each of the activities that are being used in the application. It is here where the main page will be set as the launcher page. The launcher page is the page that appears when the user first opens the application. The root element of the manifest file will be the manifest. In this element the application name and the application element will be defined. The application alement defines the activity elements. In this application there are four activities. In the activity element the name of the activity and its parent activity are defined. This is what gives the entire application its structure. This code can be seen in Appendices – Code G – Android Manifest. 2.3.2 Android Application Code This section will cover how the applications functionality was coded using Android Studio. 2.3.2.1 Creating the directories and setup files A directory needs to be programmatically created. This directory will store the files such as enable_BCMON, airodump-ng, success-01.cap, success-01.csv, success01.kismet.csv and success-01.kismet.netxml. The enable_BCMON file will be used to enable the monitor mode. The airodump-ng file will be used to execute the airodump. The success-01 files will be the output files generated by the airodump. A sample version of these files with generic data will be created initially and then overwritten each time an airodump is executed. The folder is created using the following code. if (!toolsDir.exists()) { toolsDir.mkdirs(); copyAssets("tools"); Shell.SU.run("chmod 777 " + toolsPath + "/enable_bcmon"); Shell.SU.run("chmod 777 " + toolsPath + "/airodump-ng"); } If the tools directory does not exist then it is created and the assets are copied into it. The assets are the files that were previously mentioned. Once the directory is created and the files have been copied into it then full read/write permissions are given to the monitor mode and airodump files. This is needed to prevent errors that can occur when accessing these files. One such error would be when the airodump is trying to create its output files. Here it will need write permissions to be able to create the files in this directory. The firmware files for reverse engineering the wireless chipsets drivers will also need to be created. A similar method to before will be used again. The code can be seen below. String fwPath = "/vendor/firmware"; File fwDir = new File(fwPath); copyAssets("fw"); The copyAssets function is passed a string called either tools or fw. This sets the mode of the function. In the tools mode all the files, except for the firmware files, are copied into the folder and in the firmware mode only the firmware files are copied into the folder. This code can be seen in Appendices – Code A – Copy Assets. 2.3.2.2 Reading in the data from the CSV (Comma Separated Values) file To read in the data from the CSV file, generated from the airodump, a class called CSVReader was created. In the CSV file there are 2 tables, one for the details about the access points and another for the details about the clients. Figure 14 – AP Details shows a 15x18 sized table and Figure 15 – Client Details shows a 7x8 sized table. Figure 13 - CSV Access Point Details Figure 14 - CSV Client Details Separate functions were developed for each of the tables, apRead and clientRead. The function apRead will return a List String array variable call apList and the function clientRead will return a List String array variable called clientList. Each line in the CSV file is split into a String array using the split (“,”) function. Each String array is added into a List String array. When the apRead function counts two blank lines it finished adding rows to the List and when the clientRead counts two blank lines then it starts adding lines to the list. The function finishes when a null is read while analysing the line. The code for this can be seen in appendix – Code B – CSV Reader. The two variables apList and clientList will be used anytime certain data about the access points or clients is needed. A class called CSVData is used to store any functions that are created to scan through these two variables. This was done to help keep the Android Studio project neat and organised. The data obtained from these functions was generally used to populate the ListViews within the Android application. 2.3.2.3 Performance Index Sorting The performance index was obtained by calculating a weighted sum of three different parameters. These parameters are the RSSI, throughput and number of clients. Each of the parameters were given a weighting factor depending on their relative importance to the performance of a network. The most important factor was throughput and this was given a weighting factor of 0.4. Next was the number of clients which was given a weighting factor of 0.35 and lastly was the RSSI with a factor of 0.25. There was no specific reason for the choice in values that are used here, other than to give more importance to specific parameters. Throughput = #Packets 𝐷𝑢𝑟𝑎𝑡𝑖𝑜𝑛 𝑎𝑐𝑐𝑒𝑠𝑠 𝑝𝑜𝑖𝑛𝑡 𝑤𝑎𝑠 𝑎𝑐𝑡𝑖𝑣𝑒 To calculate the throughput the above formula was used. The total amount of packets were read from the CSV file. The “#IV” section shows the amount of Initialisation Vectors. An IV is a random number that is defined before a packet is transmitted and is used to help with data encryption. Each packet contains an IV so this can be used for the packet count [24]. The number of packets can then be divided by the transmission time (the duration the access point was active for). The transmission time was obtained from the CSV file by subtracting the time the access point was first seen from the last time it was seen. The RSSI values could be read directly from the CSV file and the number of clients for each access point could also be obtained from the CSV file. This was done by scanning through each BSSID in the apList section of the CSV file and comparing it to the BSSID list in the client section. If there was a match then that client was associated with that access point. These three parameters were then scaled from 0-100%. The code below was then used to get the performance index value for each access point where aRSSI, aPR and aClients are the weighting factors. for (int j = 0; j apRead() { List resultList = new ArrayList<>(); // Read from inputStream BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream)); try { String csvLine; // Read through each line until null is reached or finish == 1 while((csvLine = reader.readLine()) != null && finish == 0) { // Segment the line at each comma and store in string array String[] row = csvLine.split(","); // If there is a blank line then count if (csvLine.length() <= 1 ) {count = count+1;} // If no blank line then add string array to resultList else {resultList.add(row);} // If a second blank line is reached then stop if (count == 2) {finish = 1;} } } catch(IOException ex) {throw new RuntimeException("Error in reading CSV file:" + ex);} finally { try{inputStream.close();} catch(IOException e) {throw new RuntimeException("Error while closing input stream: " + e);} } return resultList; } ////////////////////////////////////////////////////////////////////////////// ////////////////// /////////////////////////////////////////// Client Table /////////////////////////////////////// public List clientRead() { List resultList = new ArrayList(); BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream)); try { String csvLine; // Read until line is null while((csvLine = reader.readLine()) != null) { String[] row = csvLine.split(","); // If blank line then count if (csvLine.length() <= 1 ) {count = count+1;} // After two blank lines start adding data to resultList if ((count == 2) && (csvLine.length() >= 1)) {resultList.add(row);} } } catch(IOException ex) { throw new RuntimeException("Error in reading CSV file:" + ex); } finally { try{ inputStream.close(); } catch(IOException e) { throw new RuntimeException("Error while closing input stream: " + e); } } return resultList; } ////////////////////////////////////////////////////////////////////////////// ////////////////// } 4.3 Code C – Access Point Array Adapter getView function public static void clearData() { essidList.clear(); } @Override // Set up and Populate the Views public View getView(int position, View convertView, ViewGroup parent) { View row = convertView; ItemViewHolder viewHolder; if(row == null){ // Create a layout inflator LayoutInflater inflater = (LayoutInflater) this.getContext().getSystemService(Context.LAYOUT_INFLATER_SERVICE); // Inflate the row with the ap_List_content layout row = inflater.inflate(R.layout.ap_list_content, parent, false); // viewHolder object TextViews are set equal to the XML TextViews viewHolder = new ItemViewHolder(); viewHolder.ESSID = (TextView) row.findViewById(R.id.essid); viewHolder.Red = (TextView) row.findViewById(R.id.red); viewHolder.Orange = (TextView) row.findViewById(R.id.orange); viewHolder.Green = (TextView) row.findViewById(R.id.green); //Links the row with the viewHolder for referencing row.setTag(viewHolder); } else { // Reuse already created view viewHolder = (ItemViewHolder) row.getTag(); } // First column of data is the ESSID data String stat = essidList.get(position); viewHolder.ESSID.setText(stat); // Second column is the PI values if(position != 0 && position < CSVData.apList.size()-1) { stat = String.valueOf(performanceIndex.PI[position - 1]); // Text Colour Red if ((int)(performanceIndex.PI[position-1])<= 79) { viewHolder.Red.setText("PI Value: " +stat); viewHolder.Green.setText(""); viewHolder.Orange.setText(""); } // Text Colour Oranage if ((int) performanceIndex.PI[position-1]>= 80 && performanceIndex.PI[position-1] < 90) { viewHolder.Orange.setText("PI Value: " +stat); viewHolder.Green.setText(""); viewHolder.Red.setText(""); } // Text Colour green if ((int) performanceIndex.PI[position-1]>=90) { viewHolder.Green.setText("PI Value: " +stat); viewHolder.Red.setText(""); viewHolder.Orange.setText(""); } } else { viewHolder.Green.setText(""); viewHolder.Red.setText(""); viewHolder.Orange.setText(""); } return row; } 4.4 Code D – doInBackground Function // This function will run on a thread in the background protected Void doInBackground(String... params) { // Checj to see if root access is available suAvailable = Shell.SU.available(); // If so then check which condition was passed if (suAvailable && running ==true) { switch (params[0]) { // if airodump was passed then delete the current airodump files and execute an airodump case "airodump": String airodumpPath = "/data/data/com.example.jake.Wifi_Hotspot_Performance/tools"; File csv = new File(airodumpPath, "/success-01.csv");File cap = new File(airodumpPath, "/success-01.cap"); File kismetCSV = new File(airodumpPath, "/success01.kismet.csv");File kismetNetXML = new File(airodumpPath, "/success01.kismet.netxml"); csv.delete();cap.delete();kismetCSV.delete();kismetNetXML.delete(); Shell.SU.run(new String[]{"PATH=$PATH:/data/data/com.example.jake.Wifi_Hotspot_Performance/tool s" + " LD_LIBRARY_PATH=/data/data/com.example.jake.Wifi_Hotspot_Performance/tools;" + " cd /data/data/com.example.jake.Wifi_Hotspot_Performance/tools;" + " LD_PRELOAD=/data/data/com.example.jake.Wifi_Hotspot_Performance/tools/libfake_ driver.so airodump-ng -w success wlan0;"}); // If cancel is called then running will turn true, breaking the loop if (isCancelled()) running=false; break; // If enable bcmon is called then enable bcmon case "enable_bcmon": Shell.SU.run(new String("/data/data/com.example.jake.Wifi_Hotspot_Performance/tools/enable_bcmo n")); break; // If disable bcmon is called then disable bcmon case "disable_bcmon": Shell.SU.run(new String("ifconfig wlan0 down")); break; } } return null; } 4.5 Code E – content_ap_details 4.6 Code F – activity_ap_details 4.7 Code G – Android Manifest 4.8 Screenshots – O’Connell Street 4.9 Screenshots – Stephens Green 4.10 Screenshots – Georges Street Bibliography [1]"Gartner Says 6.4 Billion Connected", Gartner.com, 2016. [Online]. Available: http://www.gartner.com/newsroom/id/3165317. [Accessed: 28- May- 2016]. [2]"WiFi Offloading To Skyrocket", Network Computing, 2015. [Online]. Available: http://www.networkcomputing.com/wireless/wifi-offloading-skyrocket/1733513641. [Accessed: 28- May- 2016]. [3] Computer.org, "Computer Society and ACM Approve Software Engineering Code of Ethics", 2016. [Online]. Available: https://www.computer.org/cms/Computer.org/Publications/code-of-ethics.pdf. [Accessed: 28- May- 2016]. [4] D. Sinclair, "Professional ethics in computing", Google.ie, 2016. [Online]. Available: https://www.google.ie/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact= 8&ved=0ahUKEwj4pJ24xdLKAhWhjXIKHfvdDkYQFgglMAE&url=http%3A%2F%2Fwww.c omputing.dcu.ie%2F~davids%2FProfessional_Ethics_in_Computing.ppt&usg=AFQjCNFy XZmUfLk8rFLPm0uOzxTR6JySUQ&sig2=eim1fU8y2kHMLZPNr8ePdA&bvm=bv.1130346 60,d.bGQ. [Accessed: 28- May- 2016]. [5]O. Ilds, Y. Ofir and R. Feinstein, "Wardriving from Your Pocket", REcon, Montreal, Canada, 2013. [6]"CWAP – MAC Header : Frame Control", mrn-cciew, 2014. [Online]. Available: https://mrncciew.com/2014/09/27/cwap-mac-header-frame-control. [Accessed: 28- May- 2016]. [7]"CWAP – 802.11 Control Frame Types", mrn-cciew, 2014. [Online]. Available: https://mrncciew.com/2014/10/02/cwap-802-11-control-frame-types/. [Accessed: 28- May- 2016]. [8]"802.11 WLAN Packets and Protocols", Wildpackets.com, 2016. [Online]. Available: http://www.wildpackets.com/resources/compendium/wireless_lan/wlan_packets. [Accessed: 28- May- 2016]. [9]M. Gast, 802.11 wireless networks. Sebastopol, CA: O'Reilly, 2002. [10]"802.11 Frame Format", mrn-cciew, 2013. [Online]. Available: https://mrncciew.com/2013/04/24/802-11-frame-format/. [Accessed: 28- May- 2016]. [11]"What is OSI reference model (Open Systems Interconnection)? - Definition from WhatIs.com", SearchNetworking, 2016. [Online]. Available: http://searchnetworking.techtarget.com/definition/OSI. [Accessed: 28- May- 2016]. [12]"2.2 Dissecting a Network Packet", Books.gigatux.nl, 2016. [Online]. Available: http://books.gigatux.nl/mirror/snortids/0596006616/snortids-CHP-2-SECT-2.html. [Accessed: 28- May- 2016]. [13]S. John, "Android Architecture - EazyTutz", EazyTutz, 2015. [Online]. Available: http://www.eazytutz.com/android/android-architecture/. [Accessed: 28- May- 2016]. [14]M. Studio, "Meet Android Studio | Android Studio", Developer.android.com, 2016. [Online]. Available: https://developer.android.com/studio/intro/index.html. [Accessed: 28- May- 2016]. [15]"Application Fundamentals | Android Developers", Developer.android.com, 2016. [Online]. Available: https://developer.android.com/guide/components/fundamentals.html. [Accessed: 28- May- 2016]. [16]"Android Intents: Explicit and Implicit Intents | slidenerd", Slidenerd.com, 2016. [Online]. Available: http://slidenerd.com/2014/10/31/android-intents-explicit-andimplicit-intents/. [Accessed: 28- May- 2016]. [17] "Top 10 Most Common Mistakes That Android Developers Make: A Programming Tutorial", Toptal Engineering Blog, 2016. [Online]. Available: https://www.toptal.com/android/top-10-most-common-android-developmentmistakes. [Accessed: 28- May- 2016]. [18]"Wireless Networking - IEEE 802.11 Wireless Networks", Vias.org, 2016. [Online]. Available: http://www.vias.org/wirelessnetw/wndw_05_04.html. [Accessed: 28- May- 2016]. [19]"WiFi modes of operation (802.11 or Wi-Fi)", CCM, 2016. [Online]. Available: http://ccm.net/contents/804-wifi-modes-of-operation-802-11-or-wi-fi. [Accessed: 28- May- 2016]. [20]M. Renfors, "802.11", http://www.cs.tut.fi/, 2016. [Online]. Available: http://www.cs.tut.fi/kurssit/TLT-6556/Slides/Lecture2.pdf. [Accessed: 28- May- 2016]. [21]G. Kaiser, "Understanding Application Performance on the Network – Part II: Bandwidth and Congestion - about:performance”, 2014. [Online]. Available: http://apmblog.dynatrace.com/2014/06/19/understanding-application-performanceon-the-network-bandwidth-and-congestion/. [Accessed: 28- May- 2016]. [22]Beej's Guide to Network Programming - Using Internet Socket, 1st ed. Brian “Beej Jorgensen” Hall, 2012, pp. 4, 5. [23]"Wifi Nigel: What are RadioTap Headers?", Wifinigel.blogspot.ie, 2013. [Online]. Available: http://wifinigel.blogspot.ie/2013/11/what-are-radiotap-headers.html. [Accessed: 28- May- 2016]. [24]"What is initialization vector (IV)? - Definition from WhatIs.com", WhatIs.com, 2016. [Online]. Available: http://whatis.techtarget.com/definition/initialization-vectorIV. [Accessed: 28- May- 2016]. [25]R. Tułaza, "fafaldo/FABToolbar", GitHub, 2016. [Online]. Available: https://github.com/fafaldo/FABToolbar. [Accessed: 28- May- 2016]. [26]"Hack wifi - Top 10 Android and iPhone apps", Como Robar Wifi, 2015. [Online]. Available: http://comorobarwifi.org/hack-wifi-android-and-iphone-apps. [Accessed: 28- May- 2016]. [27]"CloudShark Integrators | CloudShark Appliance", Enterprise.cloudshark.org, 2016. [Online]. Available: https://enterprise.cloudshark.org/integrators/. [Accessed: 28- May- 2016]. [28]"Download WIFI PASSWORD 5.1.3 apk", Apk.land, 2016. [Online]. Available: http://apk.land/apk/wifi-password-513. [Accessed: 28- May- 2016]. [29]O. Ildis, "Monitor mode for Broadcom WiFi Chipsets", Bcmon.blogspot.ie, 2013. [Online]. Available: http://BCMON.blogspot.ie/. [Accessed: 28- May- 2016].