Jianqiu's Progress

Please write an update on your progress before we meet. I create a subpage in the following list for each of you. Please add a paragraph about your progress for what you charge for.

• 11/20/20-12/03/20

  • Problems we discussed last time:

    • Control the drone using Dronekit. Synchronize the transmission of the GPS signal and the drone control command using Python script. Then send a mission of point A to point B while transmitting a dynamic GPS spoofing signal. Collaborate with Frendy.

    • For the hovering test, send a larger GPS position shift, e.g. 10, 15 or 20 meters.

  • Tasks conducted: test code XXX, link, results, figures

    • Did a spoofing test with T.J. and Isaac on the big lawn behind Dean Hall. Used a python script to generate the GPS trajectory, which shifted westward for 5m at the speed of 1m/s.

      • Stationary test result:

• • • Did a test with Frendy on 12/3. We could synchronize the transmission of the GPS signal and the drone control command on a bare Linux. The drone took off after a delay after it was locked to the spoofing GPS signal. However, the drone couldn't receive the correct GPS position shift.

• • New Problems:

    • It is hard to let the drone locked to spoofing GPS signal at sometime in a day. It is hard to succeed from 11am to 1:30pm. From 3:30pm to 4pm, it is easy to spoof the drone. From 4pm to 4:30pm, we don't have an available brdc file for the current time. The test can resume after 4:30pm.

    • I cannot connect my laptop to the drone and control via Dronekit in a Windows environment.

    • Read references: to new sites, links, papers, results, figures

• 11/13/20-11/19/20,

  • Problems we discussed last time:

  • Tasks conducted: test code XXX, link, results, figures

    • Repeated the fixed-spoofing-position test with Isaac, and took a video.

• • New Problems:

    • Read references: to new sites, links, papers, results, figures

      • Frendy's report: https://sites.google.com/a/hawaii.edu/drone-security/home/00_progress_report_and_timesheet/frendy-s-reports

      • Frendy's github repo: https://github.com/frendylio/RedHill

• 11/6/20-11/12/20,

  • Problems we discussed last time:

    • The directional drift of velocity from GLOBAL_POSITION_INT

  • Tasks conducted: test code XXX, link, results, figures

    • A test with the drone receiving a real GPS signal. I turned the drone by 90 degrees every 30 seconds so the drone was facing north, east, south, and west in order. The results are shown below and it is obvious that the velocity drift direction is related to the heading.

• • New Problems:

    • Read references: to new sites, links, papers, results, figures

• 10/30/20-11/5/20,

  • Problems we discussed last time:

    • Examine Ardupilot source code for Skyviper to figure out the cause of the drifting velocity.

    • Experiment improvements to be made:

      • Collect data with real GPS signals to check if there are still velocity readings.

      • Limit the range to 35 meters to avoid weak GPS signals.

      • Mark the critical points in the drone trajectory with time stamps.

      • Redo the experiments multiple times to get perfect results.

  • Tasks conducted: test code XXX, link, results, figures

    • The GPS trajectories when the drone was hovering and holding its GPS position:

• • New Problems:

    • In the figures above, the green points (from global positions) and the blue points (from velocity (ground speed) integral) are both from the Mavlink message GLOBAL_POSITION_INT, but the green points are close to the positions (brown points) from GPS_RAW_INT, while the blue points roughly look like the real trajectory of the drone. I wonder how ArduPliot calculates the ground speed.

    • Shall we determine a tentative final exam date of the thesis? Probably we need an extension beyond Nov. 6.

    • Read references: to new sites, links, papers, results, figures

      • Mavlink mission protocol: https://mavlink.io/en/services/mission.html

      • Python Run Shell Command On Windows: https://www.simplifiedpython.net/python-run-shell-command-on-windows/

      • Subprocess: https://docs.python.org/2/library/subprocess.html

• 10/09/20-10/15/20,

  • Problems we discussed last time:

    • We can solve the drone's real position using the measurements of velocity.

  • Tasks conducted: test code XXX, link, results, figures

    • Collaborated with Tomas and Isaac on a GPS spoofing test on the lower campus

    • Collected four more sets of data of drone status. I will plot the drone's real position using velocity data soon.

  • New Problems:

    • 2 pm in HST is equivalent to 12 am, i.e. midnight in Greenwich time, when the BRDC (ephemeris) file for the new day is probably unavailable. So we have to avoid the period from 2 pm to 3:30 pm for GPS testing. The next BRDC file can be available after about 3:45 pm.

    • Read references: to new sites, links, papers, results, figures

• 10/02/20-10/08/20,

  • Problems we discussed last time:

  • Tasks conducted: test code XXX, link, results, figures

    • Conducted a spoofing test while the drone was flying on the lower campus. The test was not successful because of two obstacles: 1) The wind was strong so that the drone could not always hover stably. 2) I started to transmit the spoofing signal after the take-off, so the huge jumping of the drone's GPS location before or at the beginning after it got a 3D fix triggered its protection mechanism to land. The GPS trajectory is shown in the figure below.

    • I'm going to repeat the test, but start to send the spoofing signal before the drone takes off, so it can get a stable fixed GPS signal while hovering.

• • New Problems:

    • Read references: to new sites, links, papers, results, figures

• 09/25/20-10/01/20,

  • Problems we discussed last time:

    • We can read the drone position and velocity information from the following MAVLink messages: https://sites.google.com/a/hawaii.edu/uhm-rotc-cyber-security-research/home/group-2-sensor-attacks/project-2-spoofing-gps-with-srd-cards/mavlink-messages-for-reading-drone-position-and-velocity-status

  • Tasks conducted: test code XXX, link, results, figures

    • Did a spoofing test at Holmes Hall. The results are shown below:

• • New Problems:

    • Before sending a spoofing signal, the real GPS location of the drone was drifting over time for tens of meters in a few minutes.

    • The ground speed from GPS_RAW_INT ≈ The airspeed from HUD. The ground speed from GLOBAL_POSITION_INT ≈ the ground speed from HUD.

    • Read references: to new sites, links, papers, results, figures

      • Message definition in pymavlink code: https://pydoc.net/pymavlink/2.2.8/pymavlink.dialects.v20.ardupilotmega/

• 09/18/20-09/24/20,

  • Problems we discussed last time:

    • Test the Wifi strength in the test field on campus.

    • Also get the Vehicle.veloctiy, Vehicle.ekf_ok, Vehicle.atrspeed, and Vehicle.groundspeed when conducting the spoofing test.

  • Tasks conducted: test code XXX, link, results, figures

    • I tested the Wifi signal strength at different places indoor and outdoor. The results are shown below, which indicates that even though the Wifi strength varies at different locations, the effective transmission range cannot exceed 20m. An RSSI of -70 dB is the minimum signal strength for reliable packet delivery.

• • New Problems:

    • Should we switch to DroneKit for reading drone status? Currently, I'm reading from MAVLink messages.

      • The velocity information is available from:

        • CONTROL_SYSTEM_STATE ( #146 ): x_vel, y_vel, z_vel

      • The EKF status is available from:

        • ESTIMATOR_STATUS ( #230 ): flags

        • EKF_STATUS_REPORT: flags

      • Airspeed is available from:

        • VFR_HUD ( #74 ): airspeed

        • CONTROL_SYSTEM_STATE ( #146 ): airspeed

      • Groundspeed is available from:

        • GPS_RAW_INT ( #24 ): vel

        • GLOBAL_POSITION_INT ( #33 ): vx, vy, vz

        • VFR_HUD ( #74 ): groundspeed

    • When the drone was locked to the spoofing GPS signal, the altitude read from the drone were negative values, e.g. -10m to -30m.

    • Read references: to new sites, links, papers, results, figures

      • DroneKit Vehicle State and Parameters: https://dronekit-python.readthedocs.io/en/latest/guide/vehicle_state_and_parameters.html#vehicle-information

• 09/11/20-09/17/20,

  • Problems we discussed last time:

    • Conduct the GPS spoofing test on the lower campus

  • Tasks conducted: test code XXX, link, results, figures

    • Did a GPS spoofing test on the lower campus. More details can be found at https://sites.google.com/a/hawaii.edu/uhm-rotc-cyber-security-research/home/group-2-sensor-attacks/project-2-spoofing-gps-with-srd-cards/result-of-gps-spoofing-trajectory.

  • New Problems:

    • The drone test field at Kailua is closed at present.

    • The maximum Wifi range is only 10 to 20 meters, which is too short for our application.

    • Read references: to new sites, links, papers, results, figures

• 09/04/20-09/10/20,

  • Problems we discussed last time:

  • Tasks conducted: test code XXX, link, results, figures

    • Applied an external high precision TXCO as a reference clock to the bladeRF 2.0 xA4. Now the device is usable for GPS spoofing. https://sites.google.com/a/hawaii.edu/uhm-rotc-cyber-security-research/home/group-2-sensor-attacks/project-2-spoofing-gps-with-srd-cards/use-an-external-clock-on-bladerf

  • New Problems:

    • Read references: to new sites, links, papers, results, figures

      • TCXO Clock, High Precision External TCXO Clock PPM0.1 for HackRF One GPS Application. https://www.amazon.com/Precision-External-PPM0-1-HackRF-Application/dp/B07NXSFFLB/

      • Nuand forum: BladeRF 2.0 frequency stability. https://nuand.com/forums/viewtopic.php?t=4984

      • Frequently Asked Questions: How do I use a 10 MHz reference? https://www.nuand.com/frequently-asked-questions/#How_do_I_use_a_10_MHz_reference

      • bladerRF micro schematics. https://www.nuand.com/bladeRF-micro.pdf

• 05/08/20-05/14/20,

  • Problems we discussed last time:

    • The plan for the following week:

      • Refine the Python script for fetching GPS status: display EKF status; plot data using Python functions.

      • Spoof the drone with dynamic positions and see how the drone GPS display follows the positions we send.

      • Send fake GPS coordinates through GPS_INPUT messages in Mavlink.

  • Tasks conducted: test code XXX, link, results, figures

    • Plotted the chart in dynamic mode: YINGFEI: "dynamic mode?This is still on the ground, right? The Latitude reference is what we are sending, right? The latitude is the lat reading from the drone?

    • Please write your semester report by reviewing what you have done and learned this semester, and outline what can do next. Please add all details how you set up your tests such that cadets can do them later."

• • New Problems:

    • Read references: to new sites, links, papers, results, figures

      • MAVLINK Common Message Set# ESTIMATOR_STATUS_FLAGS: https://mavlink.io/en/messages/common.html#ESTIMATOR_STATUS_FLAGS

• 05/01/20-05/07/20,

  • Problems we discussed last time:

  • Tasks conducted: test code XXX, link, results, figures

    • Tried to use web scraper to fetch GPS data from the web interface of the drone. Unfortunately, the data is displayed using dynamic technology on that webpage, so it is not easy to scrape data with a simple web scraper.

    • So I switched to mavlink connection and use the following python script to fetch data, by which I can print the GPS coordinates and the accuracy.

import time

from pymavlink import mavutil

# Start a connection listening to a UDP port

the_connection = mavutil.mavlink_connection('udpin:192.168.99.2:14550')

while True:

the_connection.wait_heartbeat()

lat = the_connection.messages['GPS_RAW_INT'].lat

lon = the_connection.messages['GPS_RAW_INT'].lon

alt = the_connection.messages['GPS_RAW_INT'].alt

vel_acc = the_connection.messages['GPS_RAW_INT'].vel_acc

h_acc = the_connection.messages['GPS_RAW_INT'].h_acc

v_acc = the_connection.messages['GPS_RAW_INT'].v_acc

print(lat,',', lon,',', alt,',', vel_acc,',', h_acc,',', v_acc)

• • • Please see the charts plotted in Excel, which shows the trend of GPS positions in my spoofing test.

      • where the Lat. Ref./Lon. Ref. is the position we sent by BladeRF (21.28, -157.81) and the True Lat./True Lon. is the true GPS position received by the dedicated GPS receiver (21.2810517, -157.8263)

      • From the 19th second, we started to send spoofing signal and at the 137th second we stopped sending.

• • New Problems:

    • In the python script above, I have to use the IP address of my laptop (192.168.99.2) rather than the IP of the drone (192.168.99.1) to establish a valid connection.

    • Also I need to fetch the heartbeat in every loop iteration, otherwise, the GPS data doesn't update.

    • Read references: to new sites, links, papers, results, figures

      • Using Pymavlink Libraries (mavgen): https://mavlink.io/en/mavgen_python/

      • MAVLINK Common Message Set#GPS_RAW_INT: https://mavlink.io/en/messages/common.html#GPS_RAW_INT

• 04/24/20-04/30/20,

  • Problems we discussed last time:

  • Tasks conducted: test code XXX, link, results, figures

    • Compared GPS positioning on different devices: GPS receiver, iPhone, Drone. It is hard to say which one is more accurate.

• • • Working on reading GPS status from the drone web interface. I will update the progress later.

      • Design a web scraper using the Python libraries of urllib and BeautifulSoup

• • New Problems:

    • Read references: to new sites, links, papers, results, figures

      • Beginner’s guide to Web Scraping in Python using BeautifulSoup: https://www.analyticsvidhya.com/blog/2015/10/beginner-guide-web-scraping-beautiful-soup-python/

      • Web Scraping with Beautiful Soup: https://www.pluralsight.com/guides/web-scraping-with-beautiful-soup

• 04/17/20-04/23/20,

  • Problems we discussed last time:

    • The GSM antenna has a much greater transmission range of GPS signals (≥20m) than the GPS antenna does (2m). The GSM antenna has a gain of -5.5dB at 1575.42MHz, while The GPS antenna has 28dB of LNA gain. I'm not sure about what a positive gain means.

  • Tasks conducted: test code XXX, link, results, figures

    • Tested the accuracy and range of GPS spoofing indoors and outdoors. See the result in the following table:

      • The transmission range of BladeRF with the GSM antenna is beyond 20m, while the drone has a stable Wifi transmission range of ~10m. (Yingfei: not sure what you mean WiFi range here.)

      • "Error" means the distance from the preset spoofing position to the position shown by the drone (for a fake position), or from the real position to the GPS position shown by the drone (for a real position).

      • In most cases, the error was acceptable, which sometimes was a bit large. (YINGFEI: the distance to the antenna is a key factor?)

• • • Tried to send fixed spoofing GPS signal which the drone is hovering. The result is that if the spoofing position was miles away from the current position, the drone could detect the sudden change and safely landed. On Wednesday evening I did it three times. However, on Thursday morning, I failed to land the drone using the same method. (YINGFEI: can we read the status from the web interface?)

• • New Problems:

    • We can send GPS positions that are gradually changing from the current position to drive the drone away. (YINGFEI: have you tried yet?) However, a potential issue is that if the starting position or the midway position received by the drone is severely inaccurate (e.g. a few or tens of meters from the previous position: YINGFEI, we can see this from the web interface, right? Maybe we can write a script to read the web interface.), the drone may detect the glitch and recognize the attack.

    • Read references: to new sites, links, papers, results, figures

• 04/09/20-04/16/20,

  • Problems we discussed last time:

  • Tasks conducted: test code XXX, link, results, figures

    • Flew the Journey drone in the open air and tested the Position Hold and Returning to Home functions. It had a relatively good precision of about 2-3 meters. Yingfei: how many time did you tried?

    • Spoofed the drone using bladeRF in the open air when the drone is landed. Preliminary tests show that within the range of 1-2 meters between the drone and the antenna, we can spoof the drone with real-time generated bitstream (See the figures of GPS status and map in the APP below). However, at the range of approx 3 meters, it rarely succeeded due to loss of lock.

    • Yingfei: how far did you spoof the position and time?

• • • Ubuntu running on WSL cannot read USB devices, so we have to run BladeRF either on a virtual machine or a stand-alone Linux.

• • Read references: to new sites, links, papers, results, figures

    • https://www.nuand.com/product/bladeRF-xA4/

    • https://www.nuand.com/product/bladerf-xa9/

    • https://www.nuand.com/product/bt-100/

    • https://www.nuand.com/product/tri-band-antenna/

    • https://github.com/nuand/bladeRF/wiki#Expansion_Boards_and_Accessories

    • https://github.com/Nuand/bladeRF/wiki/Getting-Started%3A-Linux

    • https://github.com/Nuand/bladeRF/wiki/Getting-Started%3A-Verifying-Basic-Device-Operation#Loading_the_FPGA

• 01/31/20-02/13/20,

  • Problems we discussed last time:

    • The second dip of the tri-band antenna is at the frequency of 1442MHz with the gain of -12dB. And the gain at the GPS frequency of 1575.42MHz is -3dB (quite small).

    • The GSM antenna has a gain of -5.5dB at the GPS frequency.

    • The GPS antenna has 28dB of LNA gain.

    • Dylan got the GSM antenna works, and the tri-band antenna never works for him.

  • Tasks conducted: test code XXX, link, results, figures

    • Succeeded in GPS spoofing of static location using the GSM and GPS antenna. However, it takes a relatively long time (over 40s) for my iPhone to get the location fixed.

      • YINGFEI: We had the long delay with previous tests too. Dallas had the similar delay.

    • Helped Tomas conducting GPS spoofing with BladeRF: It works for my iPhone 5s but doesn't work for his Android phone, which can display multiple satellites but cannot get location fixed.

    • Analyzed the GPS bitstream generated by GNSS-SDR: It cannot get GPS satellites locked with the bitstream generated by gps-sdr-sim, while it can get the location fixed with a standard date file from CTTC.

  • New Problems:

    • The following forum post mentions that BladeRF v2.0 has poor clock stabilty comparing with v1.0. For GPS applications, we might need to use an external oscillator.

      • https://nuand.com/forums/viewtopic.php?t=4984

    • The unsuccessful or unsatisfactory GPS spoofing test may due to bitstream generated by gps-sdr-sim rather hardware problem.

  • Read references: to new sites, links, papers, results, figures

    • Adafruit GSM antenna: https://www.adafruit.com/product/1859

    • Adafruit GPS antenna: https://www.adafruit.com/product/960

    • QGP Supply GPS antenna: http://qgpsupply.com/index.php/2017/10/20/waterproof-gps-active-antenna-28db-gain/

    • GNSS-SDR: https://gnss-sdr.org/my-first-fix/

• 02/14/20-02/27/20,

  • Problems we discussed last time:

    • The issue of GNSS-SDR failing to decode the generated bitstream is possibly due to inappropriate parameter setting, as the length of time of the data file is parsed wrongly.

    • Try to use the GPS receiver to analyze the transmitted GPS signal.

  • Tasks conducted: test code XXX, link, results, figures

    • Used GPS receiver to analyze the GPS signal transmitted by BladeRF. By using the windows client GPS Info or VisualGPSView, we could get GPS location fixed within 50s, which is relatively easy. Also, we successfully spoofed Darius' android phone by using BladeRF for the first time.

    • Updated the notes of GPS tutorial and NMEA format. Added Position acquisition time and more NMEA message formats.

    • Add the tutorial GPS Spoofing with BladeRF v2.0 and Receiver

  • New Problems:

    • The output of the GPS receiver is NMEA messages rather than raw data.

    • In a "warm start" situation, sometimes it is hard to obtain a position fix in 2 minutes. This issue may be due to that if the receiver had some leftover almanac data, it would try to search for the satellites which were supposed to be overhead, rather than the ones in the spoofing signal.

    • If we want to use GNSS-SDR to analyze the GPS bitstream generated by gps-sdr-sim, it is essential to figure out how to adjust the parameters in the configuration file.

    • Still not sure if almanac data is contained in the generated bitstream and how it affects the success rate of GPS spoofing.

    • Read references: to new sites, links, papers, results, figures

      • BU-353S4 GPS receiver: https://www.globalsat.com.tw/en/product-199952/Cable-GPS-with-USB-interface-SiRF-Star-IV-BU-353S4.html

      • BU-353S4 GPS receiver downloads (USB driver and GPS Info tool):https://www.globalsat.com.tw/style/frame/m5/features.asp?content_set=color_2&lang=2&customer_id=909&name_id=10593

      • Visual GPS LLC: https://www.visualgps.net/

      • GNSS-SDR parameters: https://gnss-sdr.org/docs/sp-blocks/global-parameters/

    • 02/28/20-03/05/20,

      • Problems we discussed last time:

        • Use GNSS-SDR or GPS receiver to verify if the spoofing GPS bitstream is generated and transmitted correctly.

      • Tasks conducted: test code XXX, link, results, figures

        • Tested GPS spoofing in dynamic mode: Transmitted GPS bitstream of a route around the Holmes Hall at 20km/s, and recorded the received NMEA messages using the GPS receiver. The transmitted and received routes with coordinates are shown below. The maximum deviation is 3.6 meters.