I

Debian Aerial Reconnaissance Quadcopter

(DARQ)

Project Report Spring Semester 2017

-Full Report-

by Ryan Lynch

William Jackson Jorden Ham

Department of Electrical and Computer Engineering

Colorado State University

Fort Collins, Colorado 80523

Project advisor: Sudeep Pasricha

Approved by: Sudeep Pasricha

II

ABSTRACT

The market for drones has existed for many years, but in recent years due to advancements in battery capacity technologies and the decreased cost for increased performance at smaller power budgets for processor and memory technologies, the price of manufacturing drones has fallen significantly. With these advancements, more companies have started to enter the drone market which has created competition. Market competition is good from the consumer point of view as this leads to relative price drops, increasing varieties of drones being created, and advancement of drone technologies as a whole. Lower prices have also resulted in the expansion of the hobbyist drone community, and decreased the notion that drones were these expensive machines that only corporations could have enough capital to afford. Hobbyists are now purchasing drones for activities like FPV racing, videography, and general enjoyment. Although these advancements are welcomed and needed, drones seem to still be suffering from one general problem. This problem is that most drones being developed are bounded by being very application specific. Due to the nature of providing software and hardware that is functional, but also cost efficient, not much has been done in the way of creating drone that can be considered general purpose in nature.

The approach our group has taken to address this problem was to research the state of the

current drone market in order to gain insight into developing a general purpose drone platform geared toward user programmability and application data networking convenience. Our research resulted in a strategy that leveraged existing hardware and software solutions with an emphasis on maximizing the inclusion of as much Open Source Software (OSS) and Open Source Hardware (OSH) as possible. In order to prove our concept, we developed an application that required our quadcopter to perform tasks that covered the full breadth of its abilities. This application was to investigate and experiment on physically remote wireless networks to gain information on general network information such as the reach, security, and identity of a network; and if given the opportunity, to probe networks for security vulnerabilities. Due to the possibility of this application seeming malicious in nature and current stigmas around network penetration testing or “hacking”, we have also dedicated a whole section of this report to discussing the ethical and legal implications of our actions. We further discuss our hardware and software research with conclusions on which softwares and hardwares we found to be optimal for our project. We produced a model for a reliable data transmission topology that leverages TCP to ensure data correctness. We then expand on the implementation of the application, including what softwares we used, as well as software integration and development. Finally, we cover what lessons we learned over the course of the project, provide thoughts on the project as a whole, and present some insight for future students who may want to continue with this project.

III

ACKNOWLEDGEMENTS

We would like acknowledge and sincerely thank our faculty advisor, Dr. Sudeep Pasricha, for his continued support and guidance throughout the course of our senior design project. From the start, he has been instrumental in leading our group through the daunting maze that is experimental research and proper project politics. We would also like to acknowledge and thank the spirit and immense kindness of the Open Source communities surrounding many of the projects we utilize for our project at no cost. It is this amazing exchange of ideas and helpful essence contained within these communities that have encouraged us to also make our work as transparent and available to the outside word as possible.

IV

TABLE OF CONTENTS Title I Abstract II Acknowledgements III Table of Contents IV Tables and Figures V 1. Introduction 1 2. Application Theory 3 3. Ethical and Legal Concerns 4 3.1 Ethical Hacking 4 3.2 FAA Drone Laws 5 4. General Research 7 4.1 Software Research 7 4.1.1 ArduPilot 7 4.1.2 APM Planner 7 4.1.3 Aircrack-ng and Kismet 8 4.1.4 The ‘D’ is for Debian 9 4.2 Hardware Research 10 4.2.1 Raspberry Pi 11 4.2.2 PXFmini 12 4.2.3 WiFi Card 12 4.3 Mechanical Research 12 5. Implementation 14 5.1 Configuring Network Interfaces 14 5.2 Network Mapping 14 5.3 Penetration Testing 15 5.4 Flight Data and Considerations 16 5.5 Data Transfer Topology 17 5.6 Software Intercompatibility 19 6. Conclusions and Future Work 21 6.1 Conclusions 21 6.2 Lessons Learned 21 6.3 Continuation Goals 22 References 24 Appendix A – Abbreviations A Appendix B – Budget B Appendix C – Project Plan Evolution C

V

TABLES AND FIGURES

Figure 1: Concept diagram of DARQ application 3 Figure 2: FAA Diagram 6 Figure 3: APM Interface 8 Figure 4: Kismet Interface 9 Figure 5: Assembled Quadcopter 13 Figure 6: Google Maps Network Mapping 15 Figure 7: Flight Testing 17 Figure 8: Diagram of Data Transmission Topology 17 Figure 9: Program Flow Diagram 18 Figure 10: Gpsd/Socat Diagram 20

1

Chapter 1: INTRODUCTION

The Federal Aviation Administration (FAA) releases an Aerospace Forecast annually, in the year 2010, they predicted the number of Unmanned Aerial Systems (UAS) in civilian hands by 2020 to be in the range of 15,000 units [9]. This prediction was off by more than a factor of 10 as the same report from 2016 forecasted this 2020 figure to be upwards of 540,000[9]. Mispredictions of the drone industry happened again in 2015 by Business Insider when they estimated the same consumer UAS market in 2020 to be in the range of $3 billion. Business Insider then released a report one year later stating that the 2020 market is projected to top $12 billion [10]. This exponential growth is driven by market competition, and results in cheaper prices for the consumer as well as rapid technological advances in both the manufacturing and quality of UAS’s. Where the FAA’s misprediction of the UAS forecasts were made during the infancy of drone technologies, it can be said that Business Insider’s misprediction was made during the toddler period of UAS technologies. These mispredictions elude to the fact that the drone industry is quickly growing and soon won’t need a diaper. This diaper is analogous to the regulations that resist the growth within this industry. Market trends like this do not go unnoticed and thus there exists a large force to develop and employ regulations that allow for an assortment of applications across a number of sectors.

As these regulations manifest and mature, the demand for general purpose platforms for the development of applications will grow as quickly as the market itself. Debian Aerial Reconnaissance Quadcopter (DARQ) is a project that is addressing an underlying issue that is the increase in demand for open source general purpose platforms with well-established data networking capabilities geared toward application development for the consumer and commercial sectors. In order to address this underlying issue, we have developed a cybersecurity application as a proof of concept. This application is to investigate and experiment on physically remote wireless networks to gain information on general network information such as the reach, security, and identity of a network, and if given the opportunity, to probe networks for security vulnerabilities. This application as well as our philosophies will be covered in more depth in chapter 2, Application Theory and DARQ. Our application theory resides in a gray area of legality and ethics and therefore we address this ambiguity in chapter 3, Ethical and Legal Concerns. Chapter 3 consists of a case study of Joffe v. Google Inc., an overview of pertinent legislation, a comprehensive ethical review and information on FAA licensing.

To achieve our goals of addressing both the underlying issue and proof of concept we needed to carefully deliberate what software and hardware components would satisfy our needs. The research in Chapter 4 focuses on the deliberation of these components while considering the individual functionality of the hardware and software as well as the joint performance of the two. Another key component of achieving these goals is the development of a well-established data network for quadcopter to base station communication. This network leverages TCP communication to ensure data reliability of the payload whether it be Aircrack-ng capture files or consumer application data. The process for the development is outlined in Chapter 5.

One of our main philosophies is to use as much open source software(OSS) and hardware as possible as well as contribute to the open source community through our research and implementations. Open source denotes that the source code is made freely available and anyone can modify or add to the code. In the context of hardware open source means that the schematics and all design information are available to the public. In our platform we are using various OSS, such as Aircrack-ng, Debian, and ArduPilot, as well as open source hardware such as the Raspberry

2

Pi 3 and PXFmini. The ethical disadvantages to using OSS in our proof of concept are outlined in Chapter 3.

3

Chapter 2: APPLICATION THEORY

As stated in Chapter 1, DARQ has a set of goals that are derived from the growth being exhibited in the drone industry today. Our main and underlying goal is to provide an open source platform with well-defined networking capabilities for future developers to place their applications on. Our application to place on this platform as a proof of concept is one within the cyber security domain, specifically, wireless network security. This application is to investigate and experiment on physically remote wireless networks to gain information on general network information such as the reach, security, and identity of a network, and if given the opportunity, to probe networks for security vulnerabilities. Figure 1 shows a concept diagram of these ideas.

Figure 1: Concept diagram of drone network security application. Figure 1 shows the concept diagram for the DARQ application. Red arrows indicate movement to the physically remote site. It can be observed that the obstacle is a fence surrounding the site. Blue arrow indicates data transmission for computational offloading and analysis. Blue waves below the drone indicate network monitoring.

This application is a sufficient proof of concept for the following reasons. First, it tests the mobility of our system by requiring the drone to travel over some obstacle to the physically remote site. Second, it tests the uptime of our system by forcing the quad to remain active while sniffing packets while on site. Third, it tests the data streaming capabilities of our network by requiring offloading of captured packets to a base station for analysis. Finally, all of this is done while also testing the ability for the network to maintain continuous contact with the quad in order to ensure it leaves the site.

The motivation for this application beside being a good proof of concept is that physically remote sites are usually also considered to be relatively physically secure sites, and companies that establish themselves on physically secure sites are usually also concerned with the security of their data. Therefore, an application that can provide them with information about the security and reach of their on-site wireless networks is possibly viable and potentially valuable.

4

Chapter 3: ETHICAL AND LEGAL CONCERNS 3.1 ETHICAL HACKING It should be addressed that the application of this project may be interpreted to some as malicious in intent. This is not the case, in fact, we classify ourselves to be within a group of ethical hackers coined white hat hackers. Like everything in life, the world of hacking is not classified in binary terms, rather there is a grayscale to describe the ethics that hackers rely upon when performing their trade. This hacking grayscale ranges from the malicious black hat to the benevolent white hat, with a neutral gray hat sitting somewhere in between. In order to specify how we will be wearing this metaphysical white hat, we will present a quick case study of a relevant situation Google is currently in and a brief overview of pertinent laws.

Google is in an ongoing dispute which arose from their Google Street View technology. The federal lawsuit began in 2010 and is titled Joffe v. Google. This case is relevant to our project because the lawsuit is concerning the interception and subsequent archiving of unencrypted packets that Google Street View accumulated between the years of 2007 and 2010. The intention of Street View cars being equipped with WiFi capabilities was to get information like the MAC address, SSID, signal strength and encryption status from surrounding networks. This information was then used to improve the quality of service Google services like Maps navigation and other services like local business lookups for Google’s users. However, it was discovered that unlike the encrypted packets that were discarded after being parsed for the information described above, unencrypted packets were parsed, but rather than being discarded, their data frames were archived. Over these three years, Google accumulated 600Gb of unencrypted data over 30 countries [4]. All of the courts that this case has appeared in have been in favor of Joffe, stating interpretations of laws from 1986 that I will cover in the coming paragraph. This case is still ongoing as Google has filed for multiple appeals and has most recently a supreme court appeal in 2014.

The laws that concern our group are the same that put Google in their precarious position. These laws are ones concerning packet sniffing, which is functionally tuning a device into a radio frequency and listening. This functional description of packet sniffing is a simplistic one, however, the description does elude to the reasons for some of the early laws that have been used to judge packet sniffing cases. These early laws are a part of the Electronic Communications Privacy Act of 1986 (ECPA), also known as the Wiretap Act. The Wiretap Act came into existence in part due to the lack of security consideration when the first cell phones were created. It was possible to literally tune a device into a radio frequency and pick up personal cell phone conversations. Unfortunately, this is to be a brief overview and we cannot dive into some of the results of the legislation, like the fact that wiretapping unencrypted landlines remained legal while wiretapping unencrypted cellphones signals was deemed illegal. What we will dive into is the interpretations that the United States Court of Appeals, Ninth Circuit had when reviewing an appeal of Joffe v. Google in 2013. Google asserts that their packet sniffing is legal because the ECPA states that it is lawful to intercept “electronic communications” that are “readily accessible to the general public” with respect to radio communications [6]. However, the Ninth District ruled that under the

5

1986 statute, the electronic communications in question encompasses only “traditional radio services”. These “traditional radio services” do not include WiFi, and therefore the court ruled against Google. As stated in the previous paragraph this ruling is again being appealed by Google, but this time to the supreme court. In 2015, another act that directly impacts the legality of our project was passed called the Cybersecurity Act of 2015. Fortunately for us the act has a passage, Section 104 (a) (1), that states that: “Notwithstanding any other provision of law, a private entity may, for cybersecurity purposes, monitor ... an information system of such private entity” [5]. Which means that despite the bleak outlook on the legality of packet sniffing that Joffe v. Google gives, with the correct test environment we can carry through with our application without any legal concerns.

Although, we have asserted that our application is legal, we still haven’t fully addressed the scope of its ethics. As has been stated, we wear the white hat, and only wish to use DARQ under legal circumstances where we are benefitting our customer to strengthen their cybersecurity. Therefore, we can say that we are acting lawfully and ethically for our use case. It is ethical to be lawful and have a beneficial application, which is a full ethical scope when one can express control over the use of one’s product. Unfortunately, as a result of our core values of staying open source we cannot express control over the end use of our product. It can be easily theorized that because of our proximity to the ethical boundaries that our end-users may be wearing the black hat. This is an unfortunate reality of keeping to our core values, and we will attempt combat this with the following actions. First, only presenting our project in the most benevolent of lights, so as to only attract those who have good intentions. Second, ensuring that our audience is aware of the thin legal ice that this project walks on. Finally, putting explicit documentation throughout saying that we don’t intend for an illegal use of DARQ. Without compromising our core values we think that these steps are noble and will give the correct impression of what DARQ should be used for. In summary, we would like to remind the reader that ethical hacking lies on a grayscale, and perspectives exist that our potential black hat end-user may add a gray hue to our white hat.

3.2 FAA DRONE LAWS Due to the dramatic rise of drone mishap reports in recent history, such as passenger aircraft near-collisions with drones near airports or people being injured by drones falling out of the sky, the FAA has recently published a set of laws to set a new standard for legal precedence and safe use of drones moving forward. Knowing how complicated some legality issues can be, this list of laws are actually pretty short and to the point.

The first thing to know about these laws is that it is based on drone weight, which we assume the FAA implies drone capability from this measure. There are three categories when it comes to the new FAA classifications and they are light hobbyist drones under 0.55 lbs that you do not need to register, medium hobbyist drones between 0.55 lbs and 55 lbs that you must register with the FAA, and heavy drones over 55 lbs which all must apply for a commercial license. Our project happens to be defined as a medium drone by this classification system which means that we had to register our drone with the FAA as a hobbyist drone.

6

Figure 2: As a hobbyist drone pilot, one must follow the simple rules defined in the following diagram which are also defined in federal FAA laws as “Small UAS Rule Part 107”.

7

Chapter 4: GENERAL RESEARCH 4.1 SOFTWARE RESEARCH

To begin research on our project, we needed to find a suitable drone control software in order to achieve flight with our drone. This control software would serve as the core of our project, in which all other project components would be based around. In addition to this, the chosen software would have to be open source to serve our project’s goal of staying as open source as possible to encourage community collaboration and free general use. Through the preliminary research conducted during the summer session, we determined that the software suite named “ArduPilot” was the best candidate for our project. Most of our other software decisions were based on our decision of flight control software, therefore we’d like to discuss ArduPilot, and proceed to cover the other softwares we used during this semester. 4.1.1 ARDUPILOT

ArduPilot, also known as APM for short, is an open source drone control software that has been under development for roughly the last five years and has had both individual and corporate collaborators in that time. What makes this software unique is that fact that it supports all common vehicle types that one could expect a drone to take the form of. From rovers, to boats, to helicopters, to planes; ArduPilot has native driver support to facilitate all these designs. On top of this, ArduPilot is well tested with a vast user base and active support community. This would ensure that if we ran into technical problems, we could likely find the help we needed within the user base. On the surface everything seemed perfect about this software suite, except for one problem it encountered late in the summer of 2016.

Originally under the “Dronecode” project, ArduPilot was the open source base application in which other more commercial flight stacks were based off of, such as the PX4 flight stack. During an internal management move during the aforementioned summer, senior collaborators of the Dronecode project such as Intel and Qualcomm motioned that the drone control software should be moved to be under their proprietary ownership. This did not bode well with the open source community surrounding the ArduPilot project and was viewed as “what can only be called a coup” [1]. Luckily, after a couple of weeks of uncertainty, the ArduPilot project was able to legally break away from the Dronecode project and retain its open source nature. This legal maneuver has allowed hobbyist and researchers, such as ourselves, to continue to have access to this vitally important software suite to continue the advancement of drone technology for the open source community at large. 4.1.2 APM PLANNER

APM Planner is the program our group has decided to use as the front end controller software for interfacing with the ArduPilot (APM) flight stack. Described on their website as “an open-source ground station application for MAVlink based autopilots including APM and PX4/Pixhawk” [2], this software will serve as an intuitive GUI control front end for our flight operations with our drone. Chosen from a list of other equally capable control software, the main reason why we chose to use this software is due to the fact that it is the most multi platformed of the list. This software stably runs on Windows, Mac, and Linux. This is very important to our group because we want our project to be as far reaching as it possibly can.

8

Figure 3: APM Interface

4.1.3 AIRCRACK-NG AND KISMET

Aircrack-ng is an open source, command line based, WiFi network security suite. The Aircrack suite is mainly intended for use on Linux operating systems but is also available for Windows and OS X. The software suite focuses on four main fields of network security; monitoring, attacking, and testing. To handle these different fields Aircrack implements many different tools, each providing resources for a specific area of security testing. The full list of these tools can be found on the Aircrack-ng website [3] but for the purposes of this paper we will cover only the ones that will provide useful in our application; Airbase-ng, Aircrack-ng, Airdecap-ng, Airdrop-ng, Airgraph-ng, Airmon-ng, and Airodump-ng.

The Airbase-ng tool is used for attacking clients themselves instead of the actual Access Point (AP). This tool can be used to create an AP and then encourage clients to connect to it for the purposes of a man-in-the-middle attack. In our implementation this tool could be used along with the Airdrop-ng tool to first deauthenticate a client and then attempt to bind them to our AP.

The Aircrack-ng tool is used for running bruteforce attacks on WPA/WPA2-PSK networks. This tool requires a captured four-way handshake as well as a dictionary containing strings to test during the bruteforce attempt. For the purposes of our project we will use this tool to ensure that a network has an adequate passphrase that is not sufficiently easy to bruteforce. For example, if a networks passphrase is simple like “password12345” then a bruteforce attack will easily provide access to the network, allowing decryption of packets over the network.

The Airdecap-ng tool is used for decryption of WPA/WPA2 capture files and stripping wireless headers from captured frames that are not encrypted. This tool requires a captured four-way handshake as well as the passphrase for the network in which the packets were captured from. In our implementation this could be used in the circumstances in which the passphrase for the AP was obtained using the Aircrack tool to see the contents of captured packets.

The Airdrop-ng tool is used for deauthentication of desired clients on a network. This tool allows the user to pass a rule-base file argument that contains rules such as MAC address and type

9

of hardware to specify which client to deauthenticate. For the purposes of our project this tool will be used to deauthenticate a user which will then trigger the sending of a four-way handshake that can be captured.

The Airgraph-ng tool can create graphs to show what clients are connected to a specified access point as well as graphs to show what APs were probed by clients. For our project this feature will prove useful for analyzing network activity and client connection patterns.

The Airmon-ng tool is used to easily enable monitor mode or return to managed mode on a WiFi card. This tool also provides functionality for killing processes that could interfere with switching to monitor mode. In our project we will use this tool to configure the desired WiFi card for monitoring.

The Airodump-ng tool is used for capturing raw WiFi frames and can also log GPS coordinates of APs found. For our purposes we will use Airodump to do a majority of network monitoring on a network as well as logging the GPS of the quadcopter when monitoring.

Kismet is an open source IEEE 802.11 security testing tool that implements a modular client/server architecture that is preferable for our implementation. This architecture allows us to spawn a client process on our Raspberry Pi 3 that then live forwards data to a server process on our base station. This data forwarding allows us to preserve resources and reduce power consumption on the drone. Another advantageous attribute of Kismet is its ability to incorporate GPS information in capture files which allows us to map network signal strength and location. Kismet displays information on a server UI that lets provides a feed of packet capture statistics, GPS information, and information about nearby networks such as SSID, security, and signal strength.

Figure 4: Kismet Interface

4.1.4 THE ‘D’ IS FOR DEBIAN

As the title of this chapter suggests, the ‘D’ is indeed for Debian. Debian is an open source operating system(OS) based on the Linux kernel. Debian is maintained by the Debian Project. The Debian Project is a group of distributed developers that have created a stable, consistent and stringent distribution system for their OS by enforcing a strict and organized structure for changes to the OS as well as for the packages they provide. Debian consists of a package manager with a

10

repository of over 43,000 approved packages [1]. Many derivatives of Debian exist, the most recognizable being Ubuntu, the derivative we are using is a Raspberry Pi optimized version called Raspbian. More specifically we are using a modified version of Raspbian distributed by Erle Robotics under the name Frambuesa meaning ‘Raspberry’ in Spanish. Frambuesa has three major aspects that make it the most suitable operating system for our platform, the first is that it uses a real time patched Linux kernel, the second is that it is a fork of Raspbian, the third is that it is developed for our FCU.

Virtually all modern kernels are some degree of real time. An example of this would be the common use case of a simple double-click of a folder on one’s desktop, on modern systems this task occurs within a timeframe that the user finds acceptable assuming the CPU has the average workload. This kind of real time is considered to be soft real time because the kernel considers process deadlines but the kernel is prioritizing other things like overall throughput. In the example given above, a soft real time kernel with a heavy workload may not complete the task of opening a folder for the user within the user’s acceptable timeframe. The default Linux kernel, being modern, is soft real time. However, for the purposes of controlling a quadcopter in flight, the kernel cannot allow non-essential processes to affect the completion of essential tasks without dire consequences. Therefore, our OS has a modified kernel that is patched to be preemptive, therefore hard real time. This preemptive patch changes the kernel such that tasks are scheduled with a priority hierarchy and any time a high priority task arrives lower priority tasks are paused until the high priority task finishes. The goal for real time kernels is to be predictable. Preemption-heavy scheduling algorithms tend to not have a high throughput, therefore if the kernel can predict incoming high-priority tasks then it can schedule tasks in such a way as to avoid preemption and maintain high throughput. The hard real time kernel keeps the quad in the air, but even with that property, the goals of our project could still be compromised as the operating system has the potential to lack the breadth of software available for the user to use on our platform.

Erle Robotics’ Frambuesa image is a fork of a well-known operating system known as Raspbian. Raspbian is a derivative of Debian which means that it bases its releases on Debian releases and follows the stringent structure that the Debian Project established for development of packages. Additionally, we get access to 35,000 of the packages that Debian provides and these packages are pre-compiled for the Raspberry Pi [2]. We also get to leverage the ever changing security and bug fixes that propagate down the chain of OS derivatives. The most important reason for using the Frambuesa image is the fact that it was specifically designed for both our hardware and software stack. In many software based implementations of hard real-time systems it is difficult to ensure real-time functionality due to possible software bugs, heavy task load, or inefficiencies between the hardware and software. Due to extensive testing by Erle Robotics on our exact hardware and software stack we can ensure that this real-time functionality is reliable. 4.2 HARDWARE RESEARCH When deciding on both what hardware and software was needed to construct the desired system we had to weigh many different factors, the most important being the flight-worthiness of our quadcopter. To ensure the quad is flight-worthy, flight controls and flight systems must be

11

hard real-time. In a majority of commercial drones these flight crucial real-time systems are handled by application specific integrated circuits (ASICs). For our purposes of creating a general computing platform we needed to include a general purpose processor so ASICs were not an option. After extensive research into many hardware-software combinations we eventually found that the Raspberry Pi 3 in combination with Erle Robotics’ PXFmini and Frambuesa would yield optimal functionality as explained in section 4.2.1 and 4.2.2.

4.2.1 RASPBERRY PI

When we were selecting a mobile computer to serve as our project’s computational nerve center, the number of choices seemed vast. We were in need of a computer that would satisfy the space requirements of the compact cavity that was available on the drone. We also needed this computer to have a good balance of energy efficiency and computational power. We ruled out computers whose components were distributed between multiple boards, therefore we quickly refined our search to an SCB (Single Board Computer). We knew that SBCs commonly provided a number of useful ports and interfaces for us to use. SBCs are also commonly more power efficient as their parts are chosen to work well together. With this specification in mind, we began our search for an SBC system that could fit our needs.

Even within the SBC system classification, the number of possible systems we could purchase still seemed high. There are SBCs that are made for parallel processing such as the “Parallella”, some that are wildly popular among SBC enthusiasts such as the “Raspberry Pi”, some that are made to use different CPU architectures such as “MIPS”, and yet still more that are made with other specific tasks in mind or to be slightly different from a competing SBC. What we had to do is define what we wanted out of our SBC to figure out which one we wanted. Deriving this list of attributes, we figured out that we wanted a system that could operate with as little power as possible, have enough processing power to handle the software tasks we give it, and have USB and Internet connectivity. Using this list of criteria, we ended up selecting to use a SBC from the Raspberry Pi Foundation.

The reasons why we selected to purchase an SBC from the Raspberry Pi Foundation is because their boards met our listed our criteria, their SBCs are known to be very reliable, their products are relatively cheap, and they have a massive user base that is excellent at answering technical difficulty questions. Within the Raspberry Pi Foundation’s lineup of products we were left with one last question; should we get a “Raspberry Pi Zero” or “Raspberry Pi 3”. Researching the internet, we found examples of people using both SBCs to make drones using ArduPilot, so we knew both would work with the flight control software. The main question was do we want to use the more power efficient single-core Raspberry Pi Zero, or the more computationally powerful quad-core Raspberry Pi 3. What we settled on was getting the Raspberry Pi 3 to ensure that our experiment programs would have ample processing power at their disposal, without getting interrupted by the processing demands of the ArduPilot flight control software.

With the selection of the Raspberry Pi 3, our group inherited fantastic functionality from this SBC system. First and foremost, this system functions as a general purpose computer. This is astronomically important to our group because one of the founding principles of our project was to design a drone that was capable of running general programs developed by users for user specific applications. The Raspberry Pi 3 can accomplish this by the fact that it can run most general purpose operating systems ported to work for the ARM processor it uses. Past this, it also sports an ARM 64-bit quad-core processor that can run at 1.2 GHz and contains 1 GB of LPDDR2 RAM. This is enough core system resources to support most resource light operating systems and to run

12

most general use programs. For connectivity the Raspberry Pi 3 comes with built in 802.11n WiFi and Bluetooth 4.1 which not always common among SBCs, Ethernet, 40-pin GPIO header, microSD card slot which serves as the devices main storage device, HDMI out, 3.5mm audio-video jack, 4 port USB 2.0 dock, Camera Serial Interface, and a Display Serial Interface. Our group has since found use for a fair number of the ports and have been very satisfied with the availability of connection options the Raspberry Pi 3 has to offer. Lastly, this SBC has been made open source hardware by the Raspberry Pi Foundation which serves our cause greatly. 4.2.2 PXFMINI

While our group was searching for a general purpose computer to run our project on, we were simultaneously searching for a flight control board that would be compatible with ArduPilot and whatever SBC we would select to use. Fortunately for us, right as we were settling upon the Raspberry Pi 3 as the SBC we would utilize, we found a flight control board that was made expressly for the Raspberry Pi’s standardized 40-pin GPIO port. This board is called the “PXFmini” and it is produced by a drone hobbyist company named “Erle Robotics” located in Spain. The PXFmini is a very compact and comparatively cheap flight control board that contains many of the sensors required by ArduPilot for correct drone flight such as an accelerometer, gyroscope, magnetometer, and digital barometer. For connectivity to the Raspberry Pi, this board utilizes the many functionalities contained within the 40-pin GPIO connect to communicate expressly with the ArduPilot flight control software running on the Raspberry Pi’s processor. Additionally, this board has RC input for optional radio controller input, PWM output for motor control, and 4 JST GH cable connectors with embedded functionalities such as I2C and UART communications for external devices such as a GPS module and Erle Robotics battery power adapter module. Lastly, this board has been made open source hardware by Erle Robotics which serves our cause greatly. 4.2.3 WIFI CARD

To achieve our proof of concept goals we needed two WiFi cards mounted on the quadcopter. One card to handle communication back to the base station and another card to monitor networks. The Raspberry Pi 3 has a built in WiFi card that we are using for base station communication and data transfer so for network monitoring we purchased a Panda PAU08 Wireless USB Adapter. We specifically purchased this card because it came with correct drivers to implement with Raspbian and it also has monitor mode capabilities. 4.3 MECHANICAL RESEARCH

The quadcopter community provides many resources for constructing quads from the ground up but given our budget and time constraints we decided that a kit would best suite our scenario. There is a large market for drone kits so there were many options to choose from. When deciding on a kit we had to consider many metrics, such as, weight, lift, size, mounting points, and maneuverability. To optimize our flight time, we wanted to minimize the weight to lift ratio of our quad so a lightweight frame with powerful, energy efficient motors was crucial. We also needed to consider the mounting of devices like GPS, Camera, Flight board, etc. so a moderate sized frame was needed. The kit that was decided on is the Quanum Venture FPV. This kit satisfies all of our metrics and was also within the budgeted price range. The kit included a sturdy H frame, 4 MT2213 MultiStar Motors, 4 x 8 inch propellers, 4 x 20A electronic speed controllers, a power distribution board, and professionally soldered and pre wired components.

13

Figure 5: Assembled Quadcopter

14

Chapter 5: IMPLEMENTATION Implementing our project to achieve our concept proved quite the challenge over the course of this project. We found that most of our difficulties came from debugging and cross integrating multiple existing technologies in order to harmonize properly for our needs. The following section depicts the major software and hardware integrations we implemented into our project in order to meet our network security application goals. 5.1 CONFIGURING NETWORK INTERFACES

One of the most important tasks to complete to implement our objectives was to correctly configure our wireless interfaces. Our network interfaces are key for both network monitoring and data retrieval but also for communication with the base station. To handle communication with the base station we created an access point from the built-in WiFi card on the Raspberry Pi from which our devices could connect. Being connected to this access point allows us to receive and send information to the Raspberry Pi via multiple laptops simultaneously. To implement network mapping and testing we configured a second external WiFi dongle to connect to the school WiFi until tools like Kismet and Aircrack-ng require access to it. These tools then put this interface into monitor mode from which it can both gather information and run penetration tests on networks. To configure these interfaces we had to edit both /etc/network/interfaces and /etc/wpa_supplicant/wpa_supplicant.conf. The interfaces file handles a majority of configuration, defining the IP and netmask for the access point while also pointing the second interface to the wpa-supplicant.conf file which handles connection to the school WiFi. 5.2 NETWORK MAPPING To provide information on the range and location of wireless networks we use Kismet to passively gather network information and associate GPS coordinates with the dump files. Our Kismet server retrieves the drone’s GPS information from the GPSD server being hosted on the Raspberry Pi. Kismet outputs five different dump files, alert, gpsxml, nettxt, netxml, and pcapdump. The gpsxml file contains information about the networks such as BSSID, ESSID, signal strength, GPS coordinates, and security protocol. We can then convert this gpsxml file into a csv file and import it into Google Maps to display it.

15

Figure 6: Google Maps Network Mapping

Network mapping is a fundamental part of our project as it is a large part of the service we can provide to a customer with regards giving them information about the reach and location of their networks. 5.3 PENETRATION TESTING

To ensure the security of wireless networks and access points we run multiple tests, depending on the security protocol and setup of the network. We immediately determine any network that is not using a variation of WPA2 to be insecure, as outdated protocols such as WEP and WPA can be cracked with relative ease. With correct implementation WPA2 is uncrackable for all practical purposes, with the exception of an attacker with access to supercomputing capabilities.

One way we can ensure the correct implementation of WPA2 is to test the strength of the passphrase by capturing and launching a dictionary (bruteforce) attack on the four-way handshake. To capture the four-way handshake we can either parse the feed of packets being sent to our base station from the drone or deauthenticate a device on a network using Airplay-ng, forcing the device to re authenticate with the access point. This authentication uses the aforementioned four-way handshake, which we can capture using Kismet or Airodump-ng. Once we have captured the handshake we can use Aircrack-ng to launch a dictionary attack with a specific dictionary file. If we are unable to crack the handshake with our dictionary files then we deem the network secure.

16

The next way to ensure the correct implementation of WPA2 is to test the security of the router itself. A common vulnerability in routers happens when users leave WiFi protected setup enabled. A unique PIN is required for each device to connect to a network via WiFi protected setup (WPS). In many cases a PIN label may be on the router itself, or generated and displayed on the device. The vulnerability in WPS lies in the fact that the eight-digit PIN can be brute forced in a matter of hours using tools like Reaver. To determine if nearby networks have WPS enabled we use Wash, a WPS scan tool. Wash the BSSID, ESSID, and version of WPS, in addition to if the WPS is enabled. We can then use this information as input arguments to Reaver and attempt to brute force the PIN, which in turn would give us the passphrase for the network.

With the information gained from our testing we can then make recommendations on how users can increase the security of their wireless networks. If we are able to crack the four-way handshake then we recommend that the user change the passphrase of the network to a more complicated variant that would not be in a dictionary file. If we are able to crack the WPS PIN we recommend that the user simply disable WPS when they are not using it. Implementing these changes to the users network will make it virtually uncrackable. 5.4 FLIGHT DATA and CONSIDERATIONS

Flight was important to us, however not as important as solid implementation of our application to prove our concept. Therefore, we did not train ourselves to fly the drone well, we just made sure we had legal right to and a remote that could give us some idea of if the drone could fly under optimal circumstances. We provisioned a high capacity battery in order to guarantee that we would have decent flight times. We also went into APM flight configuration settings and turned every control setting to its lowest sensitivity, therefore making this the easiest possible setting for flight. However, we were still having problems when it came to controlling the drone with the controller we have. On this controller, the yaw axis was broken, and therefore, for any manual flight attempt, the drone ended up spinning. Another consideration that we had is that because none of us are good at flying drones, we should be liberal with our flight until after we were required to show a full drone to a crowd of people at Engineering Days. Most of our flight testing occurred indoors and did not have much room for error. In order to successfully run flight tests, we disabled the yaw axis, and tried to hover the drone with only X and Y control, the drone flies very well under these circumstances and the control algorithms keep it in the air sufficiently. The APM software allows for multitudes of flight configurations, too many for us to explore and tune within our time frame. One test we look forward to running is the getting out of WiFi range test. We would like to learn what the APM protocol is for getting out of telemetry range. One final consideration that we made when it came to flight was the center of gravity. The frame gave mount spots for a battery at the center of the frame, but assumed a small flight board on top of that. Our Raspberry Pi and flight board setup is too spacious to utilize the space provided, therefore we had two possible mounting configurations. The first is to mount the battery at the center and then mount the MCU off-center. This was what we did initially, but decided that we could not keep this configuration as our flight software assumes that the sensors are centered and that there is a good center of mass. In order to achieve the most optimal center of mass, we slightly modified the flight case such that the battery could occupy a space below the main power board. This solution allowed us to mount the flight sensors very close to the center of the drone and gave us a good center of gravity.

17

Figure 7: Flight Testing

5.5 DATA TRANSFER TOPOLOGY

The mechanism in which our group chose to transfer application data to sync between our drone and our base station was through the use of a file monitoring system, a binary difference operation, and a MQTT message passing system. This activity occurs between two phases, an initialization processes and a main operation mode. Alongside this general application data flow, there are also a flight MavLink ROS stream, a flight forward facing video stream, and Mosh SSH streams. Pictured in figures 3 and 4 below is the topology and the general outline of how this system works.

18

Figure 8: Diagram of Data Transmission Topology

Figure 9: Program Flow Diagram

Starting with our initial software component, we use the python library “watchdog” to monitor a designated application folder for changes such as file creation, deletion, or modification. This program, once given a directory to watch, will perform these observations in a I/O blocking state for the designated directory and subdirectories of the designated directory. If an event is detected, the program will return from its I/O blocked state and execute code specified by the programmer for the specific detected event type. In our case, if we detect a file or folder creation or deletion, we generate an MQTT message stating the event type and the relative file system path of the object that triggered the event.

For file modification events, we chose to utilize a python binary difference library called “bsdiff4” identify the modifications that have occurred. Once the event has been triggered, a binary difference operation is executed on our drone between an application data output directory and a clone of the current state of our server application directory. This operation generates a difference patch file to send through MQTT to our server, along with the relative file system path to the file

19

that has just been differenced. Upon the server receiving this patch file, the server executes a binary patch operation on the relative file system path specified in the MQTT message. When this operation has completed, the server will then send back to the drone an “ACK” MQTT message, acknowledging that it has successfully received and patched the designated file system object. The drone will then perform the same patching operation on its copy of the server’s application folder, representing the latest version of the data the server has received. This representation of what data currently resides on the server can then be used for future difference operations.

As previously mentioned, the message passing protocol we chose to use for our project is called MQTT. The reason for this selection is due to MQTT happening to be one of the most lightweight messaging protocols for machine to machine networking applications and that it is very commonly used in IoT networking projects. This suited our project’s need for maximum power savings, ensuring less data transmission and processing power would be used as compared to other networking protocols. To utilize this protocol, we implemented our client and server in the python library “paho-mqtt”, and used the software called “mosquito” as our MQTT messaging broker. Our data transfer system works in two phases, initialization and main operation. The reason for need of an initialization phase is to guarantee the drone’s copy of the server’s application folder is matched before new file I/O operations take place. This can be done through a similar procedure of differences and file creation/deletion; but for the simplicity’s sake we chose to go for a purging of the current copy of the drone’s folder on the server, and resending the entire contents of the drone’s application folder to the server. During this time, no applications can be running. Once the sync is complete, the file system monitor can be started and applications may be allowed to make file I/O operations to the designated application folder. At this point, our system is considered to be in main operation and performs as described in the previous paragraphs. 5.6 SOFTWARE INTERCOMPATIBILITY

The essential software, APM and Kismet, worked fine by themselves, but once we attempted to integrate them, we found that we had a major issue with regards to sharing GPS data between the two programs. Our GPS signal exists on a serial teletype, specifically TTYS0, this serial port can be passed as an argument for a GPS signal to APM. Additionally, TTYS0 can be passed as a GPS serial signal to Kismet. In UNIX systems, devices aren’t quite files, but are file-like access points to hardware. One file like property they have are read and write access. Upon trying run both Kismet and APM with the same TTY device, we found that one or both of them were taking read/write privileges on the device and not sharing it with the other. Fortunately, Kismet allows for an alternative to the raw serial device as a GPS input that is GPSD. GPSD is a service daemon that monitors one or more GPS receivers and makes this data available to be queried on TCP port 2947. Unfortunately, APM is not as flexible as Kismet and does not allow for anything besides a dedicated serial port as a GPS input. This proved to be a major roadblock for proving our concept by dividing the whole concept into two modes. One mode would be when Kismet gets the GPS data and the quadcopter would only be able to fly manually through APM and log Kismet GPS data. The other mode would be when APM gets the GPS data the quad could

20

fly with APM flight plans, but the Kismet data gathered would not have locations. The solution that we found was to use two programs, the first a tool that comes with the GPSD package called gpspipe. Gpspipe connects to gpsd and pipes the information to stdout. The second is a low level UNIX networking call that can create multi-purpose relays. These multipurpose relays are in the form of a pseudo-teletype. Socat is an extremely powerful tool and is based off of a commonly used networking tool called netcat. The main features of socat that we leverage is its ability to create a virtual serial port that can forward a stdout pipe into a virtual TTY. Socat allows control over its encoding scheme, which for our purpose is raw, and baud rate, which for our purpose needs to match up to the GPS hardware’s baud rate.

Figure 10: Gpsd/Socat Diagram

21

Chapter 6: Conclusions and Future Work

6.1 CONCLUSIONS Over the course of this school year, we have proved our concept. We have produced an open source flying computer capable of testing the security of remote networks. A consequence of proving our concept is that we have outlined one way for a general purpose mobile computer to be implemented. In the first semester we conceptualized and prepared all of the ideas and materials we needed in order to prove our concept. In the second semester we achieved this concept by implementing, developing and configuring hardware and software. The most crucial aspect of proving our concept was successfully networking our base station and drone. In order to make our product as energy efficient as possible, we needed to use the lightest weight message passing protocols for our software development. To this end, the use of MQTT and the functionality of the Kismet Server/Drone relationship were vital. In order to have a viable product we also needed to express understanding of and equip our drone with softwares like Reaver and Aircrack-ng that are capable of penetration testing. We have taken an ethical position on the unethical potential of our project due to the nature of OSS. Our position ensures that no user sees us, the creators, as malicious entities. Things we could have improved upon this semester, and that could be implemented in future work are: pushing upstream to Kismet to add WPS scanning functionality to their UI, acquiring longer range telemetry radio, and purchasing a precision RF controller. In this paper we hope to have described the need for projects like DARQ that enable people to have less resistance in their own quadcopter endeavors. We want people to be able to build off of our work and explore the possible implementations of quadcopters, using an open source platform for general computation and communication. 6.2 LESSONS LEARNED Over the course of the year we came across many challenges, including technical, managerial, and bureaucratic. Through solving these challenges we have learned many lessons and applicable techniques that would have greatly aided our progress. The most important lesson learned was the importance of thorough planning and time allocation. Although we made multiple timelines that provided us with objectives and waypoints over the course of the year, unanticipated issues would push back deliverables frequently. A lesson we learned from this was that in the creation of these timelines we needed to allocate more time to specific tasks as well as delegate fewer, larger deliverables. This technique of timeline creation is admittedly only possible to implement if previous experience has driven it. However, we believe that had we adopted this technique we would have missed out on other lessons that we learned.

One category of these lesson is technical issues. One major goal of an engineering capstone project is to pursue an idea to the fullest degree possible and learn as much as possible along the way. Although, it would be optimal to have carried through with this project like a well-tuned business does with theirs, we think that we gained some valuable insight from making mistakes and following tangent ideas that never got integrated in our final product. To list a few of these ideas: ROS (Robot Operating System), Tensor Flow, 3D printing alternative parts, 4G cellular, image streaming. However, individual ideas are not the important part of this lesson. Learning how

22

to approach these technical issues and what resources do and do not work for finding a solution is a powerful skill that we will carry with us for the rest of our lives.

Another category of lessons learned would be that of managerial. Our initial mindset of allocating tasks among the team was one consisting of allocating broad and wide ranging goals to each member. Through project experience this mindset shifted toward a communal problem solving ideal that drastically increased team productivity. Instead of each team member focusing on a large element of the project and struggling to solve problems on their own we found a much more efficient technique was for the entire team to focus on one specific issue at a time until it was solved. We gained an appreciation for other perspectives on problems that we had individual investment in.

The last category of lessons learned is bureaucratic. Having little experience in the environment that is senior design we had to adapt the mentality of active record keeping and documentation. Long term projects in hardware and software domains require incremental documentation as later problems have a tendency to be reminiscent of past problems. Being a more software focused as a group, we learned this lesson rather quickly and carried through the whole project with concise and accurate documentation. A specific lesson we learned that improved our documentation abilities was printing out our code and comments to include in our senior design notebooks. Printing these out allowed us to easily go back and reference code during group meetings.

A high pressure extended group project was a useful experience for preparing us as individuals for the professional world. We learned about technical, managerial and bureaucratic pitfalls and successes, such as time management, task allocation, and documentation. We are grateful for the opportunity to gain these valuable lessons and are excited to have produced a relevant, and challenging general purpose flying computer. 6.3 CONTINUATION GOALS

If this project were to be continued, there are a number of suggestions our current group could give as areas to focus on to significantly improve this project. If the future group is able to successfully secure further funding for this project, listed below are some of the new research areas that this project would be very capable for pursuing in the future. Listed in order of least expensive to most expensive to pursue, these research investigations could yield massive capability improvements to our drone and really present what a general purpose drone could be capable to adapting itself to. Data Radio Investigation -

Upon completion of our networking goals over 802.11 (WiFi), this project should be pursuing other radio technologies with longer ranges to further test our drone’s range and capabilities. To implement long range communications we will need a larger battery and larger drone to support the heavier physical loads and increased power requirements. To achieve sufficient data transmission rates at longer ranges our drone’s mounted antennas will require more power than that of a simple WiFi card, cutting down on our total flight time. The implementation of a larger or more efficient drone structure and battery could counter this increased power consumption. Examples: 4G LTE cellular + Data Plan, Long Range Serial Data Radio, etc. Alternative Charging Techniques -

23

One of our main focuses for this project is maximizing total deployment time, allowing the expansion of data transmission rates. The longer our drone is deployed, the more information can be sent back to our base station. One potential way to optimize deployment time is to mount solar panels on our drone so it can be charged remotely. With the implementation of solar panels, our drone could land at a destination and relay information back to the base station while charging. Furthermore, implementation of a low power mode could be implemented to let our drone charge long enough until its flight batteries are fully recharged. Another potential optimization technique we could implement is inductive charging via a landing mat connected to wall power or another battery system. This would be ideal for drones that have periodic flight tasks that would rarely be turned off, such as delivery drones. Alternative Sensing Techniques -

Exploration into using other methods of sensing a drone’s environment to add application ability and situational awareness. This can be done through technologies such as Lidar range sensing, radar range sensing, infrared thermal/night vision sensing, and many others for application critical additions. One idea that we have in this area is to leverage photogrammetry concepts with a range sensor and a camera to give the drone the ability to develop a three dimensional understanding of its position through use of distributed computing to our base station. VR Drone Integration -

Implementation of a motorized gimbal that responds to the head tracking controls of a VR headset. This will include the research into maximizing flight times with high bandwidth wireless data streaming (due to high resolution video capture), gimbal motor power consumption, gimbal flight stabilization, and multi rotor flight stabilization (ie. are octocopters better for this task instead of quadcopters or helicopters).

24

REFERENCES

[1] "ArduPilot and DroneCode," ArduPilot Discourse, 2016. [Online]. Available: http://discuss.ardupilot.org/t/ardupilot-and-dronecode/11295. Accessed: Dec. 9, 2016.

[2] ArduPilot Dev Team, "APM planner 2 home — APM planner 2 documentation," 2016. [Online]. Available: http://ardupilot.org/planner2/. Accessed: Dec. 9, 2016.

[3] Aircrack-ng, "Aircrack-ng," 2016. [Online]. Available: https://www.aircrack-ng.org/index.html. Accessed: Dec. 9, 2016.

[4] S. L. Garfinkel and M. Mccarrin, "Can we sniff [Wi-Fi]? Implications of Joffe v. Google for security researchers and educators," 2014. [Online]. Available: http://simson.net/ref/2014/2014-02-18_Sniff.pdf. Accessed: Dec. 9, 2016.

[5] "DIVISION N—CYBERSECURITY," 2015. [Online]. Available: https://www.justsecurity.org/wp-content/uploads/2015/12/Cybersecurity-Act-of-2015.pdf. Accessed: Dec. 9, 2016.

[6] U. Gasser and P. Ohm, "Joffe v. Google, Inc," 2014. [Online]. Available: http://harvardlawreview.org/2014/04/joffe-v-google-inc/. Accessed: Dec. 9, 2016.

[7] 2016, "Debian -- about Debian," 1997. [Online]. Available: https://www.debian.org/intro/about. Accessed: Dec. 9, 2016.

[8] "Raspbian,". [Online]. Available: https://www.raspbian.org/. Accessed: Dec. 9, 2016.

[9] M. McNabb, "Comparing Drone Industry Forecasts," in Business and Finance, DRONELIFE, 2016. [Online]. Available: http://dronelife.com/2016/04/08/comparing-drone-industry-forecasts/. Accessed: Dec. 9, 2016.

[10] J. Camhi, "Here are the technologies that are making drones safer and accelerating adoption," in Business Insider, Business Insider, 2016. [Online]. Available: http://www.businessinsider.com/the-drones-report-market-forecasts-key-players-and-use-cases-and-regulatory-barriers-to-the-proliferation-of-drones-2016-3. Accessed: Dec. 9, 2016.

[11] "FAA Know Before You Fly,". [Online]. Available: https://static1.squarespace.com/static/5623e873e4b021dd85271590/t/56744cb54bf118e32477a158/1450462391241/?format=750w. Accessed: Dec. 9, 2016.

A

Appendix A - Abbreviations AP - Access Point ARM - Advanced RISC Machines (Implementation of RISC ISA) ASIC - Application Specific Integrated Circuit CPU - Central Processing Unit DRAM - Dynamic Random Access Memory ESC - Electronic Speed Control FAA - Federal Aviation Administration FCU - Flight Control Unit FPV - First Person View GPIO - General Purpose Input/Output ISA - Instruction Set Architecture LPDDR2 - Low Power Double Data Rate Generation 2 (Synchronous DRAM) MAC - Media Access Control MIPS - Microprocessor without Interlocked Pipeline Stages (Implementation of RISC

ISA) OS - Operating System OSH - Open Source Hardware OSS - Open Source Software PCB - Printed Circuit Board PSK - Pre-shared Key PWM - Pulse Width Modulation RC - Radio Control ROS - Robot Operating System RISC - Reduced Instruction Set Computing (Type of ISA) SCB - Single Board Computer SSID - Service Set Identifier TCP - Transmission Control Protocol UART - Universal Asynchronous Receiver/Transmitter UAS - Unmanned Aerial System WPA - WiFi Protected Access

B

Appendix B - Budget

C

Appendix C - Project Plan Evolution In order of Appearance: Initial Project Plan 9/15/16, Revised Project Plan 10/25/16, Spring Project Plan 12/16/16, Revised Project Plan 1/27/16. For better resolution images, please refer to our project website.