Team members:
This is the initial release of our drone detection device. Previous releases leading up to this have consisted of research, experiments and data visualization tools.
wifi_monitor.py
.Our method of detection relies on looking at mac addresses in the local area and checking if their OUI matches that of any drone manufacturers. As such, we are vulnerable to any mac address spoofing and risk the chance of having false positives for non-drone devices by these same manufacturers.
One possible solution that could address both of the above problems would be to use a model that can detect noise in the signal that is indicative of drone body vibration. This mechanism as well as experiments that can be used to move forward with this solution are outlined later in this document.
This aim of this project is to research and evaluate different methods for passively detecting the presence of drones by analyzing drone and controller Radio Frequency communications. As such, the documentation is divided into Setup (Hardware & Software) and Detection Methodologies.
If any of the detection methodologies are to be deployed in the future, they will need to be hosted on a Linux computer. GTRI provided us with several Nvidia Jetson TK1 development boards for prototyping.
This section describes how to get the Jetson Tegra TK1 up and running.
NEVER attempt to upgrade the distribution on the TK1, i.e. running sudo apt-get dist-upgrade
. This will overwrite important Jetson Tegra TK1 files and render the system inoperable. You will then have to reflash the system as described below. Always follow NVIDIA's directions for upgrading the system: We have had no issues running normal updates via sudo apt-get update
.
Use tmux
or screen
when running important commands over ssh, in case the connection is lost.
Secure Shell: By default, you can only connect to the TK1 using ssh password authentication from the local network. In order to connect remotely, you will have to use public key authentication.
Make sure to have a USB-RS232 serial adapter available with Null Modem adapter. This provides a more reliable method of communication with the device than SSH / HDMI when something goes awry. Also note that the serial console is unsecured by default.
Although the Jetson has a built-in HDMI video output, we had issues using it. It is best to connect to the Jetson over a serial or SSH connection.
Use a program such as screen or minicom from your Ubuntu desktop to connect over serial using a USB-RS232 serial adapter with Null Modem Adapter.
# Example using screen
sudo screen /dev/ttyUSB0 115200
While you may be able to flash using the Jetson Jetpack GUI, we found it more straightforward to reflash from the command line using Ubuntu. We found that using the official Jetson Jetpack GUI to flash does not work with Ubuntu 18.04+ -- it requires Ubuntu 16.04 and a newer Jetson model.
It is unclear if flashing using this method through a virtual machine is possible.
We highly recommend flashing from a Ubuntu 18.04 machine through the command line, as this is the method we had success with.
Flashing the TK1 may be necessary initially or if the system becomes corrupted. As of the writing of this document, R21.7 is the most recent release. The main page for the release can be found here.
Directions for flashing the device can be found in that page following the R21.7 Quick Start Guide link, but make sure to observe the notes above and the note below (in the likely event your Ubuntu computer is 64-bit).
Flashing from 64-bit Ubuntu 18.04
If on a 64-bit host, there is an issue you will need to address.
# Replace this line of Linux_for_Tegra/flash.sh: mkfs -t $4 ${loop_dev} > /dev/null 2>&1; # With this line mkfs -t $4 -O ^metadata_csum,^64bit ${loop_dev} > /dev/null 2>&1;
The original post describing this issue and fix can be found here on Nvidia's forum.
Again, make sure to have serial console access for troubleshooting.
Run the following commands on your Jetson to set the password for the ubuntu
user, activate the Ubuntu Universe repository, and install a few useful tools:
# Change default password for user ubuntu
# Make sure to make note of the new password.
sudo passwd ubuntu
# Enable the Universe repo and update
sudo add-apt-repository universe
sudo apt-get update
sudo apt-get upgrade
# You may want to install some useful programs at this point
sudo apt-get install -y tmux htop screen git bash-completion nano
You may want to change the name of the Jetson device. To do so, change 'tegra-ubuntu' to the desired new name in /etc/hostname
and /etc/hosts
.
For example:
sudo nano /etc/hostname
and hit ENTER
.CTRL-X
and the Y
to save.Repeat steps 1-3 for /etc/hosts
as well.
(This will not change until reboot, so you can either reboot (sudo reboot
) or run sudo hostname YOUR-NEW-HOSTNAME-HERE
to avoid rebooting.)
Although not necessary for our prototyping purposes, the following should be considered if deploying the Jetson in a production environment.
/etc/ssh/sshd_config
config file for the Jetson SSH server.ssh-copy-id -i your-key-here jetson-hostname-here
or manually.ufw
, as there is none active by default.hackrf_sweep
is a tool provided by the creators of the HackRF One that scans a given frequency range and outputs the measurements as a comma separated value (csv) file.
In order to use hackrf_sweep, we need to install the HackRF tools. These directions are the same whether you are installing them on the Jetson or your Ubuntu computer.
Follow directions on https://github.com/mossmann/hackrf/tree/master/host (This doesn't take very long to build, maybe a few minutes.)
You will also need to make sure that your user (ubuntu) is a member of the plugdev group. Simply enter sudo usermod -a -G plugdev ubuntu
. Then reboot the Jetson and type groups
to verify that ubuntu is a member of plugdev.
There is an issue with the HackRF on many distribution sin which computer will auto-suspend the USB by default, causing instability and the inability to get measurements from the HackRF. We want to disable this and reboot the tegra. Add the following line to /etc/rc.local
and then reboot (source):
echo -1 > /sys/module/usbcore/parameters/autosuspend
Finally, run the hackrf_info
command.
If everything installed correctly, you should see something like the following:
hackrf_info version: 2017.02.1
libhackrf version: 2017.02.1 (0.5)
Found HackRF
Index: 0
Serial number: 0000000000000000################
Board ID Number: 2 (HackRF One)
Firmware Version: 2017.02.1 (API:1.02)
Part ID Number: 0x######## 0x########
GNU Radio is an advanced tool used in our detection methodology as described in section 3.2.
From gnuradio.org:
GNU Radio is a free & open-source software development toolkit that provides signal processing blocks to implement software radios. It can be used with readily-available low-cost external RF hardware to create software-defined radios, or without hardware in a simulation-like environment. It is widely used in research, industry, academia, government, and hobbyist environments to support both wireless communications research and real-world radio systems.
We used GNU Radio on an Ubuntu 18.04 64-bit laptop to observe communications between a DJI Phantom II and its controller and to attempt to measure drone body vibrations using two HackRF One devices (see 3.2). It is also possible to install GNU Radio on the Jetson, although this proved to be unnecessary for our research.
Unless there is a compelling reason, you want to use the version of GNU Radio that comes in the Ubuntu 18.04 repositories.
sudo apt-get install gnuradio
Details for other distributions/OS's can be found on the GNU Radio Wiki
It is also possible to build and install GNU Radio from source, although the process is far more complicated and time intensive.
We attempted to make use of the data gathered using the HackRF sweep functionality on the 2.4GHz range to determine if any given activity was coming from a drone. This research experiment was designed to create data similar to that used in the research performed at Colorado.
With the experiment's data, we attempted to use a FFT see if there is any high frequency, low amplitude noise coming from the drone signal that could indicate body vibration caused by the propellers in motion. While we were not able to successfully recreate these visualizations or model this behavior in a way suitable for detection, we believe the data we collected could be further experimented with to do so.
Refer to Experiment 3
Runs hackrf_sweep
for 60 seconds and prompts the user for a filename to save the CSV data to. It uses the following parameters:
parameter | value |
---|---|
freq_min | 2400 (MHz) |
freq_max | 2500 (MHz) |
num_samples | 8192 |
bin_width | 600000 |
Details can be found in hackrf_sweep's documentation:
$ hackrf_sweep -h
Usage:
[-h] # this help
[-d serial_number] # Serial number of desired HackRF
[-a amp_enable] # RX RF amplifier 1=Enable, 0=Disable
[-f freq_min:freq_max] # minimum and maximum frequencies in MHz
[-p antenna_enable] # Antenna port power, 1=Enable, 0=Disable
[-l gain_db] # RX LNA (IF) gain, 0-40dB, 8dB steps
[-g gain_db] # RX VGA (baseband) gain, 0-62dB, 2dB steps
[-n num_samples] # Number of samples per frequency, 8192-4294967296
[-w bin_width] # FFT bin width (frequency resolution) in Hz
[-1] # one shot mode
[-B] # binary output
[-I] # binary inverse FFT output
-r filename # output file
Output fields:
date, time, hz_low, hz_high, hz_bin_width, num_samples, dB, dB, . . .
This Python script is used to process and visualize the data output from hackrf_sweep.
To install the requirements for Ubuntu 18.04:
sudo apt install python3 pip3
pip3 install --user pipenv
git clone git@github.com:tesorrells/RF-Drone-Detection.git
cd ./RF-Drone-Detection
To process the output data from the hackrf_sweep:
cd ./RF-Drone-Detection
pipenv shell # activate shell from Pipfile
python3 ./src/hackrf_sweep-process-data.py
Further details and documentation can be found in: src/hackrf_sweep-process-data.py
In an attempt to recreate an experiment described in section 2.3.2 of the previously mentioned paper, we made use of two simple GNU radio scripts and a HackRF attached to a drone.
The GNU Radio flow graph gnuradio-transmit-sinewave.grc was used to transmit a sine wave at 2.4 GHz from the HackRF attached to the drone. Its counterpart, gnuradio-receive-sinewave.grc, was used to receive the transmission.
This is another experiment used to collect data for body vibration and shifting pattern identification and would prove useful in creating a more generalize drone detection mechanism.
More details can be found in Experiment 1 and Experiment 2.
Using passive Wi-Fi monitoring, we were able to identify the presence of a drone by comparing the MAC address OUI prefix (the first 24 bits of a wireless card's MAC address) to a list of known drone manufacturers.
wifi_monitor.py uses airodump-ng to passively listen for Wi-Fi RF communication frames.
This was tested on a Ubuntu 18.04 laptop, but can also be used on the Jetson.
A very complete list of OUI prefixes compiled by the Wireshark team can be found here.
You will need to install python3 (likely already installed) and aircrack-ng on your Ubuntu 18.04 computer.
Enter the following into the terminal:
sudo apt-get install aircrack-ng python3
Directions for other operating systems and distributions available at https://www.aircrack-ng.org/doku.php?id=install_aircrack
Airodump-ng and Airmon-ng require that wifi_monitor.py be run with root permissions.
sudo python3 ./wifi_monitor.py
wifi_monitor.py will put the wireless card into monitor mode and begin listening for broadcasts that match one of the masks in oui_list
. Currently, it listens for MAC addresses that start with 62:60:1F
or 60:60:1F
(which belong to DJI) and notifies the user when a drone is detected though terminal output.
If there is only one Wi-Fi interface, wifi_monitor.py will automatically select and use it, so there is no need to pass it as an interface as an argument when run. This will suffice:
sudo python3 ./wifi_monitor.py
Otherwise, you can find the Wi-Fi interfaces with iw dev
, which will produce output something like:
$ iw dev
phy#0
Interface wlan0
ifindex 219
wdev 0x500000001
addr a0:f3:xx:xx:xx:xx
txpower 20.00 dBm
phy#1
Interface wlan1
ifindex 180
wdev 0x1c
addr b8:08:xx:xx:xx:xx
type managed
You will want use the Interface wlan0
portion, not the phy#0
. Note that in some distributions, the interface may be names differently (such as wlxa0f3c11e13c2
, for example).
If the wireless interface to be used is wlanx, you would enter the following:
sudo python3 ./wifi_monitor.py wlanx