Global 7500 D-AGLO manipulated on ADSBex

[n5205e00421]

Hello all,

On 29-01-2025 adsb-exchange showed D-AGLO landing at 21:35z at AMS from LGW. Tracks look very normal but the real aircraft was nowhere to be found. On a replay it landed in between A20N OE-LSN and B38M PH-TFN . My own SBS-3 logged both airliners but not the GL7T… On liveATC both airliners can be heard getting their landing clearance on 118.28 but no aircraft in between.
On 30-01-2025 the GL7T still pinged in a hangar at Schiphol-east, while here it is flying LBG-CIA-LBG:
https://adsb.lol/?icao=3c5d8f&lat=48.96 ... 2025-01-30
Also FR24 shows an anonymous GL7T on that flight. (adsb.lol share most earlier flights with adsbexchange)

My own SBS logged this aircraft once at AMS this year, 21-08-2024, also using VDL-2, landing 0713z/0913lt rwy27 and departing 1137z/1337lt rwy22. On the Scramble forum it was announced before landing, but on adsb-exchange however, it flew HAJ-MAD-HAJ that day!

Assuming the picture’s date here is correct, here another mismatch, at LTN on 08-09-2024:
https://api.flickr.com/photos/rkc01/53981135345
On adsb-exchange it flew BRU-BCN-AMS (I doubt that).

And at DMK 20-11-2024 :
https://api.flickr.com/photos/193924955 ... 177194327/


Another interesting one; On the replay of AMS 21-07-204 at 18:01 D-AGLO can be seen taking off 36L into several landing aircraft on 18R !
https://globe.adsbexchange.com/?replay= ... &zoom=11.0
(the date in the URL jumps back one day on my system. Make sure it is set at 2024-07-21. I have to change it to 22 to get 21.)

And this one:
https://globe.adsbexchange.com/?icao=3c ... 1722113162

It landed on rwy24 at 20:41, and took of from rwy22 20:45 . It cannot have rolled out, taxied to 22 and prepare for departure in 4 minutes…
So it shows up on adsb-exchange were there is no real aircraft , and were the real aircraft is there is nothing on adsb-exchange (no other hexcode either) .

Any ideas what is going on?

L.


Also posted here:
https://adsbx.discourse.group/t/bogus-t ... 3c5d8f/848

[n5205e00421]

Three cases where D-AGLO "flew" the exact route that was flown by an airliner a few hours earlier...

2025-01-29 LGW-AMS G-EJCE EZY45XC/6371
https://globe.adsbexchange.com/?icao=3c ... 1-29&leg=2
https://globe.adsbexchange.com/?icao=40 ... 1-29&leg=3

2025-01-24 BCN-LGW OE-LKK EJU8062
https://globe.adsbexchange.com/?icao=3c ... 1-29&leg=1
https://globe.adsbexchange.com/?icao=44 ... 1-29&leg=1


2024-07-21 AMS-FLR PH-EXY KLM63V/1651
https://globe.adsbexchange.com/?icao=3c ... 7-21&leg=1
https://globe.adsbexchange.com/?icao=48 ... 7-21&leg=2

That day it was spotted at LTN and seen landing at LBG in the evening, with spotters already noting it wasn't visible on adsb-exchange.
https://www.flickr.com/photos/jcc140965/54226661810/

[n5205e00421]

After having arrived 2025-01-29 and without being seen by anyone, the virtual D-AGLO took off on adsb-exchange 2025-02-04 leaving AMS for BCN.

https://globe.adsbexchange.com/?replay= ... &zoom=12.0
(check date in url is 2025-02-04 ! On my system it jumps back one day so you might have to change it to -05)

In the replay D-AGLO takes off at 06:11z in between AUA3NA(OELBK) and LOT7LA(SP-LII) with only a runway-length seperation...way too little.

On LiveAtc again both airliners can be heard getting their take-off clearance but D-AGLO/KAY58 is missing. The file should be avialable for the next week or so: https://archive.liveatc.net/eham/EHAM-T ... -0600Z.mp3
(around 09:36 and 10:50)

The flight to BCN seems a manipulated copy of PH -BXO two days earlier:
https://globe.adsbexchange.com/?icao=3c ... rackLabels
https://globe.adsbexchange.com/?icao=48 ... rackLabels


Adsb.fi shares the flight with ADSB-exchange:
https://globe.adsb.fi/?icao=3c5d8f&lat= ... 2025-02-04

But on adsb.lol it can be seen flying LBG-MUC around that time!
https://adsb.lol/?icao=3c5d8f&lat=47&lo ... 2025-02-04
I heard through the grapevine MUC airport systems show it as 0831lt on blocks from LBG....

Airplanes.live seems to have received the real and the manipulated data:
https://globe.airplanes.live/?icao=3c5d ... 2025-02-04


Addition: The virtual aircraft "flew" a few days later to MUC, on 2025-02-08, showing BCN-MUC with a flightpath that seems copied from DLH96C/1809, A321 D-AISB 3C6664 a day earlier. Its cruise level FL336 doesn't make sense either.

https://globe.adsbexchange.com/?icao=3c ... rackLabels
https://globe.adsbexchange.com/?icao=3c ... rackLabels

[n5205e00421]

On 2025-2-11 D-AGLO flew MUC-BTS, both visible on adsb-exchange and adsb.lol ... audio of Bratislava on liveATC confirms its arrival so since a long time this seems like a flight that is normally visible on adsbEx. On 2025-2-13 adsbEx shows a flight from BTS overflying the Netherlands towards Mexico (Tulum?). My own SBS picked up this flight as well so this seems to be another real flight.

Then on 2025-2-15 Tulum - SXM. Arrival was visible on webcam.

[n5205e00421]

A new example of inserted fake data; on 2025-02-26 D-AGLO is slightly jumping around in the hangar at MUC :
https://globe.adsbexchange.com/?icao=3c ... rackLabels

..obscuring its flight from 1038utc - 1140utc from MUC to LBG. Visible here:
https://adsb.lol/?icao=3c5d8f&lat=49.08 ... 1740569992

FR24 also shows an anonymous GL7T depart at that time:
https://www.flightradar24.com/2025-02-2 ... 4,11.74/12

[Richard from Rotterdam]

Isnt there just some error in de ADSB exchange database?

[Key]

Thanks for the heads-up, was meaning to react much earlier but forgot.

What I think is happening is similar to FR24 (and ADSB-X, dunno who started it) having linked squawk 7700 to F-35 13-5067 at some point. This should not be of course, as 7700 is a general use code with a specific purpose. My impression is, squawk 1000 has been linked to D-AGLO.

Squawk 1000 (mode A) is generally used on European flights in combination with the airplane's mode S Flight ID (like for instance KAY58 by D-AGLO) to drastically reduce the number of unique codes required to otherwise positively identify flights in the cross-border ATC systems.
Any one flight in the complete system must have a unique (combination of) code(s) to avoid potentially dangerous mixups. The Flight ID sent together with squawk 1000 needs to be an exact match with the submitted flight plan too, so e.g. KLM0123 would not be identified pinging KLM123 and the crew would have to adjust the ID (which is a simple action).

I suppose regi D-AGLO has been linked to squawk 1000 somehow in the db, making it pop up on other flight's tracks. What exactly triggers this just for those flights I have no idea, perhaps you can find some similarity between the falsely linked flights. If anyone wants more info on modes A-C-S just let me know. And just to be clear: the above theory is purely my speculation.


Erik

[n5205e00421]

Hi,

I don't think the squawk has anything to do with this. Indeed several aircraft are squawking 1000 at the same time but for these websites only
the 24-bit ICAO Mode-S code is what identifies the aircraft. The squawk seems a relatively unimportant data-field for ADSBex.
The problem with "13-5067" is that also a Dutch F35 inadvertently uses that same Mode-S code, hex AF351F. Here they are both flying the same day:
https://globe.adsbexchange.com/?icao=af ... rackLabels
I believe it concerns F-009, which should use hex code 480508.

On 2024-07-21 AMS-FLR PH-EXY KLM63V/1651 and fake D-AGLO both squawked 1000. (post 2 above)

On 2024-08-21 the real flights of D-AGLO in and out of AMS squawked 1000. Both were not visible on ADSBex as there it was doing an interesting HAJ-MAD-HAJ flight:
Vacating runway 32R and then taking off from 36R 10 sec later! It does show squawk 1000 here as well:
https://globe.adsbexchange.com/?icao=3c ... 1724229593


But..
on 2025-01-29 LGW-AMS G-EJCE EZY45XC/6371 squawked 6326, fake D-AGLO 3142.

On 2025-01-29 BCN-LGW OE-LKK EJU8062 squawked 1043, fake D-AGLO 3125.

And a new fake flight today, 28-02-2025, MUC-LGW, seems to be squawking 1000 (while the real aircraft is probably in LBG:)
https://globe.adsbexchange.com/?icao=3c ... 1740748900

But it looks like a copy of G-EZGO, EZY63KR/8638 of 26-02-2025, which squawked 6662:
https://globe.adsbexchange.com/?icao=40 ... rackLabels

Exactly the same localizer-overshoot:
https://globe.adsbexchange.com/?icao=3c ... 1740748900
https://globe.adsbexchange.com/?icao=40 ... rackLabels
Altitude along the whole route seems the same. Groundspeed shows much higher but both flights took 1h30.


Of note might be that the 'previous' owner of this frame (then F-GVMA) was fed up with journalists and activists following his plane so he said he sold it:
https://www.euronews.com/green/2022/10/ ... ery-flight

At least a motive for hiring some whizzkid transmitting fake flights as a feeder...or for a very special ADSBex-subscription?
I don't care about the jet itself but we as enthousiasts need to know flights on "The world’s largest community of unfiltered data" can be incorrect.

[Key]

OK, thanks for all the explanations, very clear. Rules out the mode A theory indeed. The F-35 case may include a Japanese one as well, because of what you see in this link I shared a while ago.

Your last point is obvious to many I suppose, but what's going on here is something quite different than unconfirmed/wrong data linking. It raises two questions for me: if the Global's whereabouts are obscured this way, then why did Arnault still sell it? Or did he just say he did but actually still uses it, hiding from his stalkers? And is it technically possible to do this manipulation on the aircraft side, or can it only be something enforced onto ADSB-X? I am inclined to believe the latter.


Erik

[n5205e00421]

Well, it was 'sold' in 9/2022 from F-GVMA to D-AGLO, but assumed still used for the same owner. I am not sure when the flights on ADSBex started being hacked but probably somewhere in 2024. Quite smart not to block data but replace it with reasonable other flights.

I agree it must be manipulation of data within the ADSBex-system. ATC needs them to transmit correct data but all journalists, activists etc with a bit of knowledge look at ADSBex. My own SBS picked up correct data, adsb.lol seems correct, and FR24 shows a GL7T on the assumed real flights. But FR24 normally blocks the identity of most business jets anyway.

There always seems a fake flight, or ground-tracks in a hangar, during the times the real aircraft is flying, so I think they may have found out that when the real data starts coming in later it is assumed false by the ADSBex-servers and thus disregarded, but this is just an assumption.
I posed this question at https://adsbx.discourse.group/t/bogus-t ... glo-3c5d8f but no useful responses there..
Is adding a fake flight to an ADSBex-feeder enough? (is it accepted well outside the range of a feeder?) Is the hack "deeper" or would ADSBex know about it? To their defense; who has full access to their system wouldn't even have to transmit data during the real flight...

Edit: Another one: 01-03-2025 jumping around at a platform in LGW 0730-1030utc on ADSBex, obscuring the real flight LBG to CMF :
https://globe.adsbexchange.com/?icao=3c ... 1740824476
https://adsb.lol/?icao=3c5d8f&lat=47.18 ... 1740821054
https://www.flightradar24.com/2025-03-0 ... 76,5.81/10

[Richard from Rotterdam]

Do you see the same info on Flightradar and other tracking sights as well? Or is it an ADSB-Exchange-only occurrence?

[AK01]

Think it has something to do with flightsimulation games. I sometimes noted fake aircraft around Brussels airport, often using FYL**** callsign, and different registrations not related to the Flying Group.
I am not into FS, but found this one, could hat be something? : https://www.virtualradarserver.co.uk/Do ... creen.aspx
Pieter,