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:
Flying 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.
Working on controlling the drone using Frendy's script.
An unfinished draft of thesis:
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.
The result of an indoor test without GPS signal. We can confirm that the velocity drift is not related to the GPS signal and is likely related to the gyroscope or the magnitometer.
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:
The GPS trajectories when the drone flew to the east for 25 meters and then was landed and brought back by hand. The blue and orange "star" markers show the position where I landed the drone.
New Problems:
Read references: to new sites, links, papers, results, figures
10/23/20-10/29/20,
Problems we discussed last time:
Collaborate with Frendy on drone flying control via DroneKit and MAVLink.
Use a constant injection vector from the origin and see the result of the drone's movement.
Tasks conducted: test code XXX, link, results, figures
1. Static test
The following figures show the test result when the drone was on the ground. The spoofing GPS positions moved to 5 meters to the west of the origin in 10 seconds, and stay there for 60 seconds.
The positions with no speed are in light colors while the moving positions are in dark colors. What's interesting is that when the GPS position was static, the drone's position from velocity integral (gray points) was drifting to the northeast at a constant velocity.
2. Flying test
The following figures show the results when the drone was hovering and trying to keep its GPS position. The drone's position from velocity integral was moving irregularly after the GPS position offset appeared.
The drone's original position and final position are shown in the following picture. The distance is around 45 meters.
New Problems:
The way I used currently for reading drone status is via the low-level pymavlink functions but Frendy is using DroneKit to control the drone. And Dronekit only supports python 2 for now. I need to find a way to combine the two methods.
Haven't got Frendy's program to work in my Python environment due to some library errors.
Read references: to new sites, links, papers, results, figures
10/16/20-10/22/20,
Problems we discussed last time:
Send destination information and "go-to" command to the drone using Mavlink mission protocol or Drone kit.
Generate the GPS spoofing trajectory with position injection vectors. Send it through Windows shell command in the Python environment.
Synchronize the transmission of GPS spoofing signal and drone command.
Tasks conducted: test code XXX, link, results, figures
Drew drone positions by velocity integral.
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.
I repeated the test approximately 8-10 times on Thursday afternoon and observed the drone drifting to the ease 3 times. The figures of the GPS locations and status are shown below. Need to figure out a way to verify the drone's actual movement from the status readings.
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."
The indication of EKF Status value:
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?
New Problems:
The attacking range seems to be limited within approx. 3 meters even when the tx gain is maximum and the bias tee amplifier is used. This issue is probably caused by then power limitation of BladeRF.
The spoofed GPS position received by the drone varied from 16xx meters to 17xx meters in different tests. I have recorded these GPS coordinates and will analyze the precision problem.
Attack scheme:
I think the easiest attack method is to let the GPS position jump to somewhere else when the drone is hovering, and see if it will fly towards the opposite direction to maintain the GPS position.
Another way is to let the GPS position change gradually from the current location, and see if the drone drifts simultaneously. The attack is harder to be detected in this way.
The drone has MAVLINK access thru UDP port. Can we try to take advantage of the interface to do something?
Read references: to new sites, links, papers, results, figures
01/23/20-01/30/20,
Problems we discussed last time:
Assigned tasks for 2020 Spring semester: (1) Test the new BladeRF2.0, (2) Examine Ross's report about GNSS-SDR, (3) Help Tomas and Darius learn HackRF/BladeRF, (4) Move the previous GPS spoofing notes into the ROTC Cyber Security Research site (5) Examine HackRF video tutorials.
Tasks conducted: test code XXX, link, results, figures
Tested BladeRF 2.0 A4 and A9 and BT-100 for SDR GPS spoofing.
Put GPS notes to the ROTC site.
Viewed three hackRF videos.
New Problems:
So far, the BladeRF 2.0 didn't work for GPS spoofing. I need to examine what the differences are between BladeRF 1.0 and 2.0.
The tri-band antenna has three maxim gain frequencies at 930MHz, 1.83GHz, and 2.45GHz. Not sure how well it works at the GPS frequency (1575.42MHz)
==================================
YINGFEI: the second dip is which frequency?
Check with Dylan about the antenna he used.
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
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.
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.
New Problems:
The velocity shown in the NMEA messages is inaccurate compared to which is set in the generator(9km/h vs 20km/h). There might be something wrong with the usage of the SatGen Trajectory generation.
It is difficult to spoof if the GPS receiver is not in a status of "cold start."
Haven't figured out how to parse bitstream using GNSS-SDR.
Read references: to new sites, links, papers, results, figures
03/06/20-03/12/20,
Problems we discussed last time:
We need to conduct a successful quick GPS spoofing at the current time. The tentative procedure is:
Examine the satellite information of the current GPS status at the GPS receiver.
Find a (probably the most recent) ephemeris file which contains satellite information which matches the current status. E.g., the file has the satellites of current PRNs.
Generate bitstream using such ephemeris file and the current time, and transmit it using an SDR device.
Hopefully, we can obtain a quick GPS spoofing 3D fix.
Tasks conducted: test code XXX, link, results, figures
As to the wrong velocity issue last week, I regenerated the NMEA file and the bitstream, and it works properly.
Examined the source code of gps-sdr-sim and brdc file format, expecting to know how the program selects satellites when generating the bitstream. gps-sdr-sim works as follows:
Read the whole ephemerides from the brdc file.
Determine which ephemeris to use based on scenario start time.
Check the visibility of each satellite at the current time, and put the visible satellites into channels in the bitstream.
Conducted quick GPS spoofing using the most recent brdc file, current time, and a GPS position near the real position. The receiver can have a position fix within 20 seconds. See the page Quick GPS Spoofing
After reviewing the source code of gps-sdr-sim, it is confirmed that the generated bitstream is lack of almanac data. However, we can achieve quick and effective GPS spoofing by elaborate forging data with proper parameters.
New Problems:
Read references: to new sites, links, papers, results, figures
03/13/20-03/26/20,
Problems we discussed last time:
Tasks conducted: test code XXX, link, results, figures
Tried to spoof GPS using HackRF and GPS bitstream generated from the most recent ephemeris data, but had no success. The GPS receiver could show the spoofed satellites with low SNRs, and couldn't get a fix. According to the following discussion, the crystal on HackRF may have low stability. We may need a more precise external oscillator or to calibrate the internal clock.
Tried to calibrate the clock in HackRF using kalibrate-hackrf, which uses the GSM base station signal to calculate the local oscillator frequency offset. However, it was difficult to obtain the offset, and even by using the offset, there was no better result in GPS spoofing.
GPS Spoofing using another BladeRF at hand (BladeRF A4). Unfortunately, it didn't work, and the appearance was similar to which by using HackRF. It is probably due to the clock stability issue, i.e., different BladeRFs may have individual differences in clock precision.
New Problems:
Even when using the BladeRF A9, the test was not always successful. The failures include:
The ephemeris brdc file we can get is not new enough so that I cannot generate bitstream using the current time.
Runtime error of gps-sdr-sim (may be a bug)
The GPS receiver can recognize the SVs but cannot get a lock.
Read references: to new sites, links, papers, results, figures
kalibrate-hackrf: https://github.com/scateu/kalibrate-hackrf
Crystal Oscillator: https://www.digikey.com/product-detail/en/FOX924B-10.000/631-1067-1-ND/1024772
HackRF repo: https://github.com/mossmann/hackrf
03/27/20-04/2/20,
Problems we discussed last time:
Tasks conducted: test code XXX, link, results, figures
Updated the images and videos in the GPS spoofing notes.
New Problems:
Read references: to new sites, links, papers, results, figures
04/03/20-04/08/20,
Tasks conducted: test code XXX, link, results, figures
Tested the Sky Viper drones: I received two drones, V2450GPS and Journey. The latter has more advanced features and I used it for testing.
The Sky Viper Journey has a few operations/modes that rely on GPS data, and we may attempt to attack it by spoofing GPS data:
Position Hold: The drone used GPS data to maintain its position when hovering. We may continuously add offsets to force it to drive.
Return to Home or Fly to Waypoint: While returning to home or flying to a preset waypoint, we may send spoofing GPS signal to let the drone deviate from its route.
Follow me: In this mode, the drone follows the operator, in other words, the GPS location of the operator's cellphone. I think it is hard to attack the drone in this mode because if we send spoofing GPS signal, the GPS location of both the drone and the cellphone will be displaced simultaneously.
New Problems:
I found the drone is really not easy to manipulate. Even in the position hold mode by GPS, it is continuously drifting both vertically and horizontally. Hopefully recalibrating the drone can improve this matter.
YINGFEI 4/08/20: https://support.skyrocketon.com/hc/en-us/articles/115013506448-V2450-GPS-Troubleshooting
check GPS data is ok with the app:
"While the above shows 3D lock, it is not yet good enough for ArduPilot to use the GPS to fly in a GPS flight mode. For GPS to be good enough for flight it needs to meet the following conditions continuously for 10 seconds:
Speed accuracy below 1.0
number of satellites at least 6
Position Accuracy below 5.0
Height Accuracy below 7.5
The above shows an example where it has 8 satellites but is not yet good enough for GPS flight. The Speed Accuracy is good enough (it is below 1.0), but the position accuracy is too high (it is over 9 meters) and the height accuracy is also bad (at over 8 meters).
Note that while the Speed Accuracy is below 1.0, it is still not good. A really good speed accuracy is 0.3 or less."
I'm not sure about the GPS position accuracy the drone can achieve. When I was testing it, the drone failed to perform the "return to home" and flied to somewhere else. Further tests must be conducted.
Read references: to new sites, links, papers, results, figures
The following picture from the APP shows the GPS positions of the drone, the operator and the home.
Sky Viper support center: https://support.skyrocketon.com/hc/en-us/categories/115001355028-SkyViper