A sonde with rogue GPS

[eben80]

Hi all,
Have you ever seen this?
https://sondehub.org/#!mt=Mapnik&mz=10&qm=3h&mc=49.02706,20.41328&f=R5020799

It looks like a GPS issue on the sonde or?
Both my receivers are getting this location.
SVS count dropped, timestamp had issues and then it jumped to a different location....

Other auto_rx receivers report the same 😆

[dl9rdz]

Interesting. Multiple stations SP8NCG, SQ2DEF,
Reporting T0340269 and R5020799 at exactly the same location, moving fast (12m/s) at constant 40m altitude.

Don't thing a hardware issue. Software issue also unlikely. Probably intentional? A lot of work in software, maybe just a simple fake transmitter?

[eben80]

Yeah it just corrected now again after the svs count went up... but it never went below 4.... strange 😄

[eben80]

Oh I didn't notice T0340269..... that's very weird...

[eben80]

You mean like a fake transmitter transmitting those two serials and coordinates? The meteo telemetry still looked good for the one I'm following R5020799...

[eben80]

Nothing weird about it 🤣

[dl9rdz]

So I guess GPS spoofing it was...

[eben80]

That's what I just thought... So would that be done by ground equipment or satellite? It happened at slightly different times for the Polish and Slovak sondes. Almost like it would happen if it was a non-geostationary satellite. [R5020799.xlsx](https://github.com/dl9rdz/rdz_ttgo_sonde/files/7269297/R5020799.xlsx) [T0340269.xlsx](https://github.com/dl9rdz/rdz_ttgo_sonde/files/7269296/T0340269.xlsx)

…

On Fri, 1 Oct 2021, 17:02 dl9rdz, ***@***.***> wrote: So I guess GPS spoofing it was... — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATNONFGUWJAW2VSWO6FJCLUEXEQ7ANCNFSM5FETQYXQ> .

[sp9skp]

I don't think that this is GPS spoofing, or this is very good spoofing :)
Few thigs:

• this affects 2 radiosondes 400km between them
• for such an attack I can't even imagine what the power of the transmitter from the ground would have to be
• for transmitting fake gps signal from satellite, position both of them should be more differen't.

But it happened at the same time.
I also can attach my logs for both radiosondes, but I must format them to be readable. But I see that there are almost the same.
One more thing. This is probably the second time it has happened. Maybe 2 -3 months before, but I ignored it.

[eben80]

What would your theory be? The paths were not exactly the same. The Polish one for example went lower than sea level 😂 So I guess its more like gps poisoning.. It never dropped below 5 sats for both sonde. I'm curious to see what the GPS Navcenter will come back with, and I wonder if any other GPS devices were affected. It lasted quite a few minutes...

…

On Sat, 2 Oct 2021, 09:59 sp9skp, ***@***.***> wrote: I don't think that this is GPS spoofing, or this is very good spoofing :) Few thigs: - this affects 2 radiosondes 400km between them - for such an attack I can't even imagine what the power of the transmitter from the ground would have to be - for transmitting fake gps signal from satellite, position both of them should be more differen't. But it happened at the same time. I also can attach my logs for both radiosondes, but I must format them to be readable. But I see that there are nera the same — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATNONDOJWLGFYIXHDV5VW3UE23XLANCNFSM5FETQYXQ> .

[sp9skp]

Yes, not that same, but difference is to small in lat/lon.

[dl9rdz]

Yes, the distance between the two is interesting. But what are the alternative explanations?

I am sure the two sondes really transmitted the wrong positions

• If we had a or some "malicious" ground stations intentionally feeding wrong data, we would have seen a mixture of "good" and "bad" data. Also, I have direct trustworthy reports from several stations that received the sonde signal themselves.
• Also, data was feed to aprs.fi, radiosondy.info, sondehub.org from different stations, with different software, so I would also exclude a systematic software bug in the receiving station.

So why would a radiosonde transmit "wrong" GPS data (position and timestamp also was a few seconds off), while all other meteo data remained plausible?

• It could also be a hardware or software defect in a radiosonde itself. If it had been just a single one, I might have accepted that. But now two completely independent sondes (but no others) have been affected, at exactly the same time, and both were basically thinking they were in the same position.

Here are some pictures from aprs.fi. My most likely explanation still is that for the "noisy" path (the few dots widely scattered around), the GPS chip just used a combination of real and spoofed signals in the calculation, and then for the path over Belarus (second picture), where both were in exact sync, both GPS chips had a full sync to the spoofed signal.

[sp9skp]

Yes, we also came to these conclusions, and this is very strange for us.
If it was a SGM, it could be explained somehow, but this is SGP and SG.

[eben80]

I'm actually going to watch them launch the 12z balloon in ganovce this afternoon. I'm gonna ask them if they also noticed the issues yesterday. I also don't believe it's a software or hardware issue on the sondes for the reasons you mentioned. I was actually watching the telemetry as it happened. Sat counts dropped... The gps timestamp from the sonde became corrupt(for some reason I don't see those in the SondeHub logs) and then the position changed. If I get anything back from my NAVCEN report I'll let you know. For now there were no other anomalies reported yesterday. https://www.navcen.uscg.gov/?Do=GPSReportStatus

…

On Sat, 2 Oct 2021, 10:17 dl9rdz, ***@***.***> wrote: Yes, the distance between the two is interesting. But what are the alternative explanations? I am sure the two sondes really transmitted the wrong positions - If we had a or some "malicious" ground stations intentionally feeding wrong data, we would have seen a mixture of "good" and "bad" data. Also, I have direct trustworthy reports from several stations that received the sonde signal themselves. - Also, data was feed to aprs.fi, radiosondy.info, sondehub.org from different stations, with different software, so I would also exclude a systematic software bug in the receiving station. So why would a radiosonde transmit "wrong" GPS data (position and timestamp also was a few seconds off), while all other meteo data remained plausible? - It could also be a hardware or software defect in a radiosonde itself. If it had been just a single one, I might have accepted that. But now two completely independent sondes (but no others) have been affected, at exactly the same time, and both were basically thinking they were in the same position. Here are some pictures from aprs.fi. My most likely explanation still is that for the "noisy" path (the few dots widely scattered around), the GPS chip just used a combination of real and spoofed signals in the calculation, and then for the path over Belarus (second picture), where both were in exact sync, both GPS chips had a full sync to the spoofed signal. [image: Screenshot 2021-10-02 at 10 10 49] <https://user-images.githubusercontent.com/6459112/135708891-f8e19858-9478-4c47-9bb6-9453167f90cf.png> [image: Screenshot 2021-10-02 at 10 10 35] <https://user-images.githubusercontent.com/6459112/135708976-81e01a1c-ef32-4c55-9a2d-111ebf369a1e.png> — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#204 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AATNONAE3MGMZMJ7KGR5VIDUE25X7ANCNFSM5FETQYXQ> .

[dl9rdz]

The gps timestamp from the sonde became corrupt(for some reason I don't see those in the SondeHub logs)

You see the time shift on SondeHub. Actually there are two distinct phases
Normal case: time_received is datetime - 17s (GPS-time/UTC offset -18s, plus 1s processing delay)
Early phase (starting 12:35): offset is now -31s (i.e. GPS time is 14s off) - only T0340269 has wrong positions, R5020799 has wrong GPS time, but position is "frozen")
Around 12:39, R502799 briefly recovered (correct GPS time with -17s offset, sats again up at 9)
Later phase (starting +-12:42): offset is now -23s (i.e. GPS time is 6s off)

[dl9rdz]

* for such an attack I can't even imagine what the power of the transmitter from the ground would have to be

I am not an expert on this but lets try to calculate

According to Wiki, GPS sats transmit at

• 46dBm + 12dB antenna gain, 58dBm EIRP
• Path loss for 20000km distance of the sat at 1550 MHz is 182dB, so expect a -124dBm real signal at the probe
• Assume you want a spoofed signal at 10dB more, i.e. -114dBm, from a transmitter about in the middle between the sondes
• Path loss for 200km distance at 1550MHz is 142dB, so you need an effective transmit power of 28dBm.

So lets assume a omnidirectional 3dBi antenna, and maybe 5dB more instead of 10dB more would be good enough, then a simple 20dBm transmitter (100mW) would be fine. Thats more than you get form a simple hobby SDR transmitter like a Adalm Pluto (5dBm out), but not out of reach even for hobbyist. Not to speak of entities with higher capabilities.

Let me know if I am way off reality, I am not an expert in this...

ublox advertises the newer ublox 8 for their sophisticated anti-spoofing mechanisms, so I guess such mechanisms are absent in the older ublox 6 chips...

[sp9skp]

All ok, but to move 2 probes to the same place, there in my opinion there must be two independent transmitters. Maby Putin and friends try to demonstrate that it is posiible - why not?
But first I try to find if there is some other possibility.
I can try to affect prostejov on descend, pluto onboard, GPS anntenna from RS92 too, only 100km ;) but not today ;)

[eben80]

The staff at Ganovce also noticed the gps dropout I they didn't of course know about the issues in Poland.

[pavolgaj]

Doesn't someone have the raw data from any of these two flights? Maybe decoding GPS part of sonde telemetry with rs41 (https://github.com/rs1729/RS) with a parameter --sat could tell something more. Unfortunately, I couldn't listen to radiosonde on Friday.

Here is an example of GPS telemetry:

[ 1677] (R5020987) Fri 2021-10-01 23:20:41.999
iTOW: 0x1EC22D0F week: 0x0881
minPR: 19884616
SV: 25 # prMes: 19884616.1 doMes: 169.4
SV: 2 # prMes: 21945786.4 doMes: -469.3
SV: 31 # prMes: 23398352.9 doMes: 2536.5
SV: 32 # prMes: 23149253.5 doMes: -2425.4
SV: 6 # prMes: 22949406.2 doMes: -2450.8
SV: 11 # prMes: 21781219.3 doMes: -66.8
SV: 29 # prMes: 21802378.1 doMes: 2185.2
SV: 12 # prMes: 20251421.5 doMes: -1829.5
SV: 24 # prMes: 23240039.8 doMes: -4242.7
lat: 49.04677 lon: 20.35455 alt: 2398.65 vH: 10.3 D: 60.5 vV: 7.8
ECEF-POS: (392844424,145742912,479578094)
ECEF-VEL: (-190,885,922)
numSatsFix: 8 sAcc: 0.3 pDOP: 1.8

[eben80]

So I got an update from USCG Navigation Center (Bold added by me on the interesting part):

Good day,

In order to confirm this is not a problem caused by some activity in the GPS constellation of satellites or with the GPS broadcast signals, NAVCEN contacted the GPS Operations Center and after a review USAF GPS Constellation remains healthy, stable and robust. Position Error in the Area of Interest was negligible. The constellation's space and ground systems are healthy and functioning as designed. There are no system indications that would result in the issues you are experiencing. Space Weather was reviewed and found to be unlikely to have impacted GPS performance. There were no GPS jamming tests in the vicinity of the outage.

We also contacted the U.S. Federal Aviation Administration, the U.S. Federal Communications Commission Operations Center, and U.S. Department of Homeland Security National Coordinating Center for Communications. There were no other reports that correlate with this event from other agencies or users during this time.

Continue to report local disruptions to radio frequency signals, including GPS, to your country's communications authority.

Thank you for your report of GPS interference. We always recommend you ensure your equipment software is up-to-date, refer to your equipment manual, or contact your software manufacturer for further assistance. Since there were no issues with the GPS constellation or any other reports from users determining the cause of an intermittent issue is very difficult. We cannot confirm the cause of this event, but reviewing the data you provided it looks to be similar to other documented GPS interference events that have occurred around the region. During these events the actual GPS coordinates were incorrect and the new GPS position was at or near an airport. Please reply to this email with any additional information or questions you may have.

Very Respectfully,

USCG Navigation Center
Navigation Information Service
NAVCEN MS 7310
7323 Telegraph Road
Alexandria, VA 20598-7310
703-313-5900
https://www.navcen.uscg.gov/

[eben80]

Really? The path and data on Sondehub looks quite normal.
https://sondehub.org/#!mt=Mapnik&mz=10&qm=3h&mc=52.50494,21.31732&f=T0330724&q=T0330724

What happened?

[eben80]

Probably. During that time the flight in Slovakia was normal as well.

[eben80]

Those 3 minutes are not visible on sondehub either. They might be filtered out because altitude is too low.

[dl9rdz]

The interruption is visible on aprs.fi from 14:07:12 to 14:10:15. No stable fake path, just various random locations.
Radiosondy.info filters out all position outliers.
Not sure about internal filtering on sondehub.

[LukePrior]

We have quite a bit of filtering on SondeHub so we probably just discarded the bad frames.

[pavolgaj]

Same problem today with S2911549: https://sondehub.org/card/S2911549. Any raw data?

And also https://sondehub.org/card/T1240374 and https://sondehub.org/card/T1540520.

[pavolgaj]

Part of data uploaded to Sondehub from 3 problematic sondes:
S2911549.xlsx
T1240374.xlsx
T1540520.xlsx

If someone has raw hex data from any of this sonde during this interval, please, let me know.