Dossier : Spoofing GPS – Usurpation GPS | Théorie, mise en pratique & contre-mesures [Niveau avancé]

Spoofing GPS : Préambule & découverte du cadre de l’expérimentation

Pour commencer cet article, petit « disclaimer » sur ce sujet sensible, rédigé dans le but d’informer sur les risques inhérents des attaques par Spoofing GPS / GNSS, et d’en promouvoir de bonnes pratiques & usages en matière de sécurité, se devant d’évoluer et de s’adapter aux nouvelles tendances dopées par des IA exceptionnellement performantes. Le spoofing GPS consiste à tromper un récepteur de navigation par satellite afin qu’il calcule une position différente de sa position réelle. Contrairement au brouillage, qui empêche la réception, le Spoofing fournit au système une information de localisation falsifiée mais potentiellement cohérente. Il convient de préciser que dans cet article, nous allons découvrir toute la chaîne logicielle permettant de générer et traiter un scénario GNSS simulé (Spoofing).

À la manière du dossier traitant les attaques par désauthentification des caméras Wi-Fi et de leur protocole Wi-Fi WPA2, le schéma ici, se présente de manière identique avec une vulnérabilité native sur une technologie quasi ancestrale (GNSS – GPS L1 C/A) et non intrinsèquement liée au matériel, ayant juste la malchance de s’appuyer sur cette technologie ! Les essais et démonstrations évoqués dans cet article ont été réalisés uniquement en environnement simulé, afin d’exclure tout risque d’interférence avec des systèmes extérieurs ou des services critiques. Aucune procédure, configuration technique ou méthodologie complète (uniquement partiel sous Kali Linux) permettant de reproduire les attaques par usurpation de position de type « Spoofing GPS – usurpation GPS » ne sera fournie dans ce contenu. Attention toutefois, il faudra être patient pour venir à bout de l’article !

Aujourd’hui, notons que les attaques par Spoofing GPS sont factuellement possibles, mais restent plus complexes et plus difficiles à mettre en œuvre, en raison de certaines contres-mesures présentes. En effet, la plupart des alarmes, caméras de vidéosurveillance & environnements de domotique sont dépendants au smartphone pour les services de géolocalisation/Geofencer, mais bénéficient de facto, d’une meilleure résilience grâce à la fusion des différentes sources de localisation (GNSS, Wi-Fi, réseaux cellulaires et capteurs) sous l’appellation « Core Location » pour Apple et « Fused Location Provider » pour Android, complexifiant ainsi les attaques.

Toutefois, subsistent encore des environnements GPS classiques, excluant toute notion de fusion concordante avec d’autres signaux, comme un Tracker de véhicule, un bracelet/tag GPS, un GPS embarqué d’avion ou de voiture, qui présentent à eux seuls, une grande perméabilité à ce type d’attaque avec un taux élevé de réussite… Ce vecteur d’attaque est presque banal et fait également partie de l’arsenal des guerres modernes, permettant de perturber, des vols commerciaux, de détourner des drones civils, de faire entrer dans des zones interdites aéronefs & bateaux ou encore, de faire tourner frénétiquement en rond des navires à quai…

Spoofing GPS : de la vulnérabilité théorique à la généralisation des attaques GNSS/GPS depuis le début des années 2010.

À noter que depuis les années 2013/2018 environ, les attaques Spoofing GPS – Leurrage GPS ont connu une croissance exponentielle, au point « d’exploser » depuis les conflits modernes que nous connaissons (mer Noire / Russie / Moyen-Orient), et même de se généraliser au sein du grand public avec la guerre en Ukraine qui a déployé massivement des compétences/appétence de GPS Spoofing pour le détournement des drones Shahed-136 de fabrication iranienne… Apparenté à un outil à part entière en environnement de guerre électronique, le Spoofing GPS / GNSS est un moyen de désinformation et un levier de contrôle de l’espace électromagnétique…

Toutefois, les attaques par Spoofing restent encore peu documentées, car encore très récentes… Historiquement, soulignons le cas du M/V Manukai dans la région de Shanghai, qui a contribué dès 2018 à mettre en évidence des anomalies de positionnement GPS/AIS particulièrement spectaculaires. ». Pour les plus curieux, citons des sources fiables comme l’OPSGROUP documentant parfaitement ce type d’attaque… Côté chiffres, l’étude « d’Ops Group », réalisée pendant l’été 2024, permettait d’y découvrir une hausse de 500 % des attaques par Spoofing GPS / GNSS dans le domaine de l’aviation, avec une moyenne de 1500 vols perturbés chaque jour… Si l’on se réfère à des chiffres plus récents, soulignons 978 000 incidents de GPS Jamming/brouillage relevés dans le monde au premier trimestre 2026… Source : Windward. La messe est dite…

On constate que les différents vecteurs de cette croissance des attaques résident dans la banalisation de la radio par logicielle (SDR) (dont j’épilogue très régulièrement sur le Blog puisque je suis équipé d’un HackRF One SDR depuis déjà plusieurs années), mais également certaines caractéristiques historiques des signaux GNSS civils, notamment l’absence d’authentification sur certains signaux, comme nous le verrons plus loin. »

Notons que le leurrage GPS / GNSS – Spoofing GPS est rendu possible via plusieurs leviers :

Ces différentes variables font qu’aujourd’hui, les attaques par Spoofing GPS se sont totalement généralisées en environnement civil et militaire (guerre électronique s’appuyant parfois sur des drones civils) comme nous allons le découvrir dans ce billet de blog qui devrait se montrer riche en rebondissements et qui, je l’espère, vous plaira.

Spoofing GPS | Au cinéma : l’encodeur culte de « Demain ne meurt jamais » pour les attaques des satellites GPS 4-1D

Si l’on repart dépoussiérer nos souvenirs d’il y a 30 ans, soulignons « Demain ne meurt jamais réalisé en 1997 » qui à mes yeux, a été le film le plus éloquent sur la manière de traiter et de faire découvrir au grand public l’usurpation de signaux GPS avec, une attaque par Spoofing GPS « meaconing » dans le film visant à un envoi de fausses coordonnées GPS vers la frégate britannique HMS Devonshire, depuis un encodeur militaire GPS tenu par Henry Gupta (Ricky Jay). Convaincu d’être en eaux internationales, le navire pénètre donc illégitimement dans les eaux territoriales chinoises de la mer de Chine méridionale, loin de son trajet initial déclenchant dès lors une guerre… Toutefois à la différence de notre époque actuelle, cette attaque s’appuyait fictivement sur du matériel militaire très loin des équipements actuels permettant au quidam, de découvrir et manipuler les ondes radio… Comme souvent dans le domaine cinématographique et encore plus avec les James Bond, quelques anecdotes subsistent : Notons la citation suivante lors du début de l’attaque par Spoofing GPS : « That looks like an American encoder. They use it to control navigation satellites: The GPS system. », que l’on peut traduire littéralement par : « Ça ressemble à un encodeur américain. Ils l’utilisent pour contrôler les satellites de navigation. », parlant de l’encodeur GPS que l’on peut découvrir en début de film. Cela nous permet d’apporter une belle transition vers le fonctionnement des satellites qui émettent leurs signaux de navigation vers les utilisateurs/équipements… Un récepteur GPS, comme celui du navire, reçoit donc les signaux émanant des satellites GPS et calcule sa position de référence. Le scénario du film ensorcèle quelque peu le fameux « encodeur GPS » comme capable de pirater les satellites GPS 4-1D. Fictive, cette possibilité est irréaliste et finalement, s’éloigne d’un vrai Spoofing GPS attaquant le récepteur (le GPS du navire) et non directement les satellites… Moins cinématographiquement sensationnel, de toute évidence !

Spoofing GPS | Comprendre le fonctionnement & principes du GPS/GNSS : Constellation et limites de la technologie…

Lancé en 1978 dans le cadre du programme GPS/NAVSTAR de l’armée américaine, le premier satellite GPS a marqué le début du déploiement de la constellation GPS, conçue autour d’une architecture nominale de 24 satellites. Depuis, le nombre de satellites opérationnels en orbite est régulièrement supérieur à cette configuration, afin notamment d’améliorer la disponibilité et la couverture du système. Chacun de ces satellites émet vers la terre des ondes radio à 1575,42 MHz (notamment le signal civil GPS L1 C/A). Le récepteur GPS au sol (GPS embarqué dans le maritime, aérien, automobile, smartphone pour la gestion des caméras, alarme et système de domotique ou Tracker GPS…) reçoit donc plusieurs signaux de satellites et utilise leur temps de propagation ainsi que différentes variables pour déterminer la position quasi-exacte. Le récepteur GPS doit également recevoir au minimum quatre mesures provenant de quatre satellites distincts afin de résoudre les trois composantes de position ainsi que le biais d’horloge du récepteur. Notons à titre d’information que le GNSS (Global Navigation Satellite System) désigne l’ensemble des systèmes mondiaux de navigation par satellites. Il regroupe notamment le GPS américain, Galileo européen, GLONASS russe et BeiDou chinois. Ces différentes constellations permettent de déterminer avec précision la position, la vitesse et le temps. Pour vulgariser le schéma de fonctionnement, voici les quatre variables nécessaires :

En date historique et pour clore cette parenthèse sur le système GPS / GNSS, soulignons la guerre du Golfe (1991) qui a permis de passer du statut de technologie militaire expérimentale à un outil opérationnel décisif, largement médiatisé et totalement rentré dans notre quotidien… Le GPS reste aujourd’hui l’un des systèmes de positionnement les plus utilisés au monde et continue d’évoluer. De nouveaux signaux et de nouvelles fonctionnalités ont été introduits afin d’améliorer ses performances, sa disponibilité et sa robustesse.

La véritable problématique n’est donc pas tant l’obsolescence du GPS mais plutôt, cette dépendance aveugle de certains systèmes à une unique source de positionnement dont l’information doit être considérée avec prudence lorsqu’elle est utilisée seule… Autrement dit : le problème n’est pas nécessairement le GPS lui-même, mais la confiance aveugle qu’un équipement pourrait accorder à la position qu’il en déduit, à défaut des smartphones qui s’appuient sur plusieurs variables pour garantir une localisation de qualité, comme nous le verrons plus tard…

Spoofing GPS : comprendre l’usurpation des coordonnées de position et les vulnérabilités intrinsèques des signaux GNSS

Non trivial, les attaques par usurpation de position « Spoofing GPS » sont devenues en effet légions, au point d’en devenir accessibles avec une certaine democratisation de la radio logicielle (SDR Software-Defined Radio), dont l’utilisation s’est largement démocratisée au cours de la dernière décennie… Existant depuis les années 90 et plus principalement dans le domaine militaire, la SDR a totalement été bouleversée au cours des années 2010 avec l’explosion des SDR « abordables » et accessibles au grand public : RTL-SDR, HackRF, BladeRF, LimeSDR, etc. Il faut toutefois distinguer que cette technologie de « radio logicielle » a permis l’élaboration de cet article de blog, rendant l’expérience des signaux GNSS incomparablement plus accessible qu’avec d’anciennes technologies… Je n’ai d’ailleurs que connu la SDR de par ma génération (1986).

À titre d’information, on constate que que les attaques par usurpation de position « Spoofing GPS » sont loin d’être nouvelles. En février 1995, Ed L. Key publiait pour la MITRE Corporation un rapport intitulé « Techniques to Counter GPS Spoofing », consacré aux méthodologies permettant de détecter ou de contrer le Spoofing GPS. Dès le milieu des années 1990, la problématique était donc déjà identifiée et documentée : un récepteur GPS civil pouvait potentiellement être trompé en réceptionnant des signaux suffisamment cohérents pour être interprétés comme provenant de satellites légitimes…

Quelques années plus tard (2001), le rapport de Volpe « Vulnerability Assessment of the Transportation Infrastructure Relying on the Global Positioning System » mettait lui aussi en évidence les risques inhérents liés à la dépendance croissante des infrastructures civiles au GPS. Le document soulignait notamment qu’à mesure que le GPS s’intégrait dans des applications toujours plus nombreuses, sa vulnérabilité native devenait un enjeu de sécurité à part entière… « L’idée n’est pas simplement de rendre le GPS impossible à perturber, ce qui est considéré comme irréaliste, mais de faire en sorte qu’une infrastructure critique puisse continuer à fonctionner lorsque le GPS disparaît ». 1995, 2001, 2026. Autant dire, les vulnérabilités sont connues et entièrement documentées, très loin d’un esprit « Zéro Day »…

Pourquoi les signaux GPS civils sont-ils vulnérables au Spoofing GPS ? Absence d’authentification, forte atténuation, suivi du signal et falsification des données de positionnement…

Pour en revenir au GPS civil, l’un des points historiquement problématiques du GPS civil réside dans l’absence d’un mécanisme d’authentification cryptographique directement exploitable par le récepteur pour vérifier l’authenticité du signal reçu, simplifiant de facto, les attaques par Spoofing GPS. Cela ne signifie évidemment pas qu’un récepteur acceptera automatiquement n’importe quel signal puisque pour être exploitable, un signal falsifié doit présenter des caractéristiques radio et temporelles suffisamment cohérentes avec celles attendues par le récepteur (GPS auto, Smartphone, GPS cible…). Une condition sine qua non, nécessaire au bon fonctionnement des mécanismes de suivi. Notons que Le Spoofing GPS cherche à introduire un signal suffisamment similaire pour que cette fenêtre de suivi se déplace progressivement du véritable signal vers le signal falsifié. Le récepteur peut alors rester verrouillé et continuer à fournir une position, mais cette position repose désormais sur des coordonnées falsifiées créées à l’occasion ou, tout simplement rejouées après capture des signaux.

Dans ce cas, Il s’agit donc d’attaques par rejeux/replay « Meaconing » s’appuyant sur la réception/retransmission d’un signal avec notamment, un décalage temporel progressif… Dernier point simplifiant les attaques par Spoofing GPS à défaut d’autres attaques manipulant les ondes radio, étant la provenance des signaux émanant des satellites arrivant au sol avec, une puissance extrêmement faible. Évoluant à environ 20 200 km d’altitude, les signaux GPS sont fortement atténués lors de leur propagation jusqu’à la surface terrestre. Cette faible puissance reçue constitue l’une des raisons pour lesquelles les signaux GNSS sont particulièrement sensibles aux perturbations radioélectriques et de facto, aux attaques par Spoofing GPS facilitant les attaques en apportant depuis de la SDR, des signaux nettement moins atténués…

Spoofing GPS : Contre-mesures pour protéger les systèmes connectés ? Incohérences & fusion des sources de localisation…

Disclaimer : j’en profite : si jamais un Boeing EA-18G Growler spécialisé dans la guerre électronique souhaite venir tester les limites de mon alarme Ajax, je lui laisse volontiers la main, no soucy ! Pour rebondir sur ce fabricant, quasi sans transition, Il convient de préciser qu’Ajax indique clairement qu’il n’utilise guère le géorepérage en tant que fonction de rappel pour notifier l’utilisateur (d’armer ou de désarmer son système), dès lors qu’un périmètre prédéfini est franchi par l’utilisateur. Le risque est donc totalement exclu d’une conséquence suite à une attaque par Spoofing GPS. Toutefois, une fois la notification envoyée à l’utilisateur, l’informant qu’il s’approche du périmètre proche de sa maison, la simple ouverture de cette notification apporte l’action de désarmer l’alarme, ce qui peut parfois générer des risques inhérents liés au facteur humain maladroit (j’en fais parfois partie !).

Parenthèse faite, notons que la fonction de « géolocalisation » s’appuie exclusivement sur le smartphone. L’application Ajax n’a donc pas accès aux données de géolocalisation de l’utilisateur et ne peut absolument pas s’appuyer sur d’autres variables pour définir un positionnement précis. Ce schéma est également présent sur la Visonic PowerMaster, qui se contente de notifier dès lors que nous rentrons dans une zone « Geofence » définie, en se basant exclusivement sur les capacités GPS / GNSS du smartphone. Notons que la partie géolocalisation est pleinement confiée au smartphone, étant mobile et surtout nativement mieux sécurisé et résilient en matière de géopositionnement. Au lieu de s’appuyer exclusivement sur une unique source GPS, le smartphone s’appuie sur une API de géolocalisation qui va combiner les signaux Wi-Fi, cellulaires (Cell ID) et GPS pour déterminer la position de l’utilisateur.

Cette fusion de plusieurs sources de localisation peut permettre de détecter une incohérence entre la position GNSS annoncée et les informations de connectivité disponibles, garantissant ainsi une meilleure fiabilité qu’une confiance aveugle accordée aux seuls signaux GNSS / GPS. Ces différentes variables de « vérification » fiabilisent la qualité de géolocalisation en optimisant la précision et la rapidité, mais elles ne constituent pas, à elles seules, une authentification cryptographique du positionnement. À noter les subtilités liées aux environnements : dans une zone urbaine fortement maillée en réseaux Wi-Fi, la géolocalisation pourra potentiellement être fiabilisée grâce à la présence de nombreuses sources complémentaires.

Un service de géolocalisation sur Smartphone nettement plus fiable en environnement urbain, fortement maillé en réseaux Wi-Fi & connectivités LTE proche…

À l’inverse, une zone rurale disposant potentiellement de moins de sources complémentaires apporte moins de possibilités de vérifications de la cohérence du positionnement. Attention, je reviens sur la partie Wi-Fi, qui peut être surprenante… Quand un smartphone utilise le Wi-Fi pour améliorer sa localisation, il ne s’agit pas uniquement du réseau Wi-Fi du propriétaire, mais également des réseaux Wi-Fi environnants, même si le smartphone n’est pas connecté à ces réseaux. En effet, la simple détection de ces réseaux peut constituer l’une des variables utilisées pour améliorer l’estimation de la position et apporter une information supplémentaire de localisation. En lotissement fortement peuplé, à défaut d’un village de quelques âmes, la présence d’un plus grand nombre de points d’accès Wi-Fi connus peut fournir davantage d’informations utiles à l’estimation de la position.

Dans ce cas de figure lié à l’alarme, une attaque par Spoofing GPS/GNSS dirigée contre le smartphone peut être plus difficile à exploiter lorsque plusieurs sources de localisation sont disponibles, comme nous l’avons vu. À proximité du réseau Wi-Fi toutefois, le scénario change totalement, avec une possibilité d’attaque par Spoofing qui se montre parfaitement efficace, car proche… Dans notre cas, j’ai envoyé une position au smartphone d’entrée/sortie du périmètre, avec la Wi-Fi à proximité. Résultat, Home Assistant a interprété la position transmise comme une entrée ou une sortie légitime du périmètre. Ce résultat illustre une vulnérabilité potentielle du geofencing, mais ne permet pas à lui seul de généraliser le comportement de l’ensemble des smartphones et systèmes de domotique.

Pour clore ce chapitre, découvrons l’étude du Southwest Research Institute, qui a testé une attaque par Spoofing GPS en rediffusant un signal GPS légèrement modifié. En décalant la position perçue d’environ 10 mètres, le véhicule autonome (marque/modèle inconnu…) visé, corrigeait sa trajectoire dans le sens opposé… Un très faible décalage de position peut donc suffire à provoquer une correction de trajectoire significative, avec toutes les conséquences que cela peut entraîner sur un système autonome… La capacité du système à vérifier la cohérence de la position reçue avec d’autres sources de localisation est un exemple de parfaite résilience, étant de nos jours indispensable.

Spoofing GPS (Usurpation) vs Jamming/Brouillage GPS/GNSS : deux attaques aux conséquences diamétralement opposées…

Pour remettre les choses dans leur contexte et bien cerner ces deux surfaces d’attaque diamétralement opposées, Il convient de préciser qu’à la différence du Spoofing GPS – Leurrage GPS, qui usurpe des positions GPS, il existe aussi le jamming GPS / GNSS (déni de service), qui n’est ni plus ni moins qu’une attaque par brouillage ciblée dont j’ai de nombreuses fois épiloguée dans mes articles de blog dédiés au brouillage des systèmes d’alarmes. Le jamming (brouillage), et plus précisément le GNSS-specific jamming, qui touche uniquement les environnements GPS, est une technique très courante dans le domaine de l’aéronautique et le militaire qui vise à brouiller les signaux issus des satellites (GPS/GNSS) en empêchant le récepteur de recevoir les informations, ayant pour conséquence : la perte de l’instrumentation/navigation, annihilant de facto la possibilité de tenir un « Waypoint » ou même de faire un retour automatique dans le cas d’un drone, par exemple…

Soulignons qu’à titre d’exemple, bien que nous nous éloignions du sujet initial, que le jamming sur la partie GPS ne « cassera pas » le lien sur la partie contrôle au-delà de la ligne de vue (BLOS) d’un drone s’appuyant sur le lien SatCom, qui est la partie « liaison » du pilotage sur parfois des milliers de kilomètres… Excluant la partie GPS, ce type de liaison s’appuie sur une bande différente avec surtout des signaux plus robustes, parfois chiffrés ou utilisant des sauts de fréquence comme dans nos chers systèmes d’alarme, les rendant certes sensibles au Jamming, mais beaucoup moins au Spoofing GPS… Dans le cas de cet article de blog, je resterai concentré sur les attaques par Spoofing GPS – usurpation GPS, étant d’ailleurs plus insidieuse et nettement intéressante pour cette approche que le « simple » GPS jamming/brouillage.

Spoofing GPS : Expérimentation et simulation d’une véritable attaque GPS en environnement contrôlé sous GPS-SDR-SIM / GNSS-SDR

L’ensemble de cette attaque a été réalisé sous la distribution Kali Linux, avec GPS-SDR-SIM pour la génération des signaux GPS L1 C/A simulés à partir de trois positions distinctes (qui jouent le rôle du ciel GPS), et GNSS-SDR pour jouer le rôle du récepteur GPS logiciel (smartphone, tracker, etc.) et analyser le fichier I/Q .bin reçu de tout là-haut ! (signal GPS)… Pour vulgariser, nous allons fabriquer un ciel GPS virtuel et demander à un récepteur GPS logiciel : « Où suis-je ? ». Nous allons donc également pouvoir observer la réaction du récepteur prêt à recevoir plusieurs signaux GPS synthétiques correspondant à des positions géographiques prédéfinies. Pour ce test, il s’agira d’un envoi de chacune des positions simulées pendant 30 secondes. Le récepteur logiciel GNSS-SDR devra ensuite produire une solution PVT stable (le résultat final du calcul du récepteur GPS) pour chacune des trois positions, en l’occurrence Nantes, Quimper, Paris.

Par la suite, nous allons observer plusieurs comportements : verrouillage sur le faux signal, calcul d’une position erronée, éventuelle détection d’anomalie, etc. Le tout dans un cadre 100 % maîtrisé et légal, puisqu’aucune émission radioélectrique n’a lieu à aucun moment. Nous allons donc découvrir l’attaque sur l’ensemble de la chaîne de traitement d’un récepteur GNSS/GPS, avec la création de nos 3 positions de départ usurpées pour générer un scénario satellitaire, la transformation de ce scénario en échantillons I/Q, puis l’envoi au récepteur des échantillons I/Q GPS, qui détecte les satellites, décode leurs données de navigation et calcule finalement une position plutôt précise… Vous allez rapidement comprendre que l’envoi de signaux GPS simulés ne se résume pas à transmettre de simples coordonnées : il s’agit en réalité de plusieurs couches d’informations nécessaires au récepteur pour parvenir à calculer une position. Cette attaque est donc une réelle attaque par Spoofing GPS, excluant simplement une transmission hertzienne par notre fidèle Hack RF One qui reste dans son écrin…

1. Attaque par Spoofing GPS | Définition de la position cible de référence.

La première étape de l’attaque par Spoofing GPS consiste à définir plusieurs positions géographiques qui serviront comme scénarios de référence tout au long de notre attaque. Pour celle-ci, j’ai choisi trois positions distinctes :

Notons que l’objectif de l’attaque ne consiste pas à inscrire directement ces coordonnées dans un signal GPS que l’on transmettrait vulgairement. Ça aurait été trop facile, hélas, comme nous allons le voir au cours de l’attaque. Ce point de départ nous permet de créer une constellation satellitaire complète.

2. Obtention des données d’éphémérides GPS nécessaires à l’attaque Spoofing.

Avant de pouvoir simuler correctement les satellites et l’envoi de nos signaux émanant de nos 3 positions (Quimper, Nantes, Paris), GPS-SDR-SIM (logiciel qui utilise les données de navigation/éphémérides pour calculer les positions des satellites et générer le signal GNSS simulé), a besoin de connaître les états orbitaux de ces derniers pour l’ensemble de la période simulée. L’ensemble des informations nécessaires sont contenues dans les données de navigation GPS, récupérées sous forme de fichiers d’éphémérides. Dans mon cas, j’ai récupéré ces dernières sur le site de la NASA. Les données utilisées peuvent provenir de fichiers au format RINEX, universel, normalisé et utilisé pour stocker et échanger les données brutes des systèmes de navigation par satellite (GNSS). Notons que les fichiers d’éphémérides sont des compilations de tous les messages de navigation diffusés en temps réel par les satellites GNSS (comme le GPS) et captés par un réseau mondial de stations permanentes au cours d’une journée complète (de 00:00 à 23:59 UTC), avec un historique jusqu’à 1992 quand même !

Ils contiennent de nombreuses informations qui seront décisives pour notre attaque, puisqu’elles permettent de reconstruire mathématiquement la trajectoire du satellite pendant la durée de la simulation, en l’occurrence nos signaux GPS usurpés ! À titre d’exemple : les paramètres de l’orbite du satellite pour calculer sa position dans l’espace, le temps de référence de l’éphéméride, soit l’instant auquel les paramètres orbitaux sont valables, les paramètres décrivant la position du satellite sur son orbite et bien d’autres données (l’excentricité de l’orbite indiquant à quel point l’orbite s’écarte d’un cercle parfait, l’inclinaison orbitale, des corrections orbitales, les paramètres d’horloge du satellite, etc.). Bref, quelques dizaines de Mo de plaisirs, qui peuvent paraître très compliqués techniquement, mais qui pourtant seront grandement facilités par les différents logiciels que nous allons découvrir tout au long de cette attaque.

2.1 Découvrons globalement un fichier de navigation GNSS multi-constellations au format RINEX 4.00 – 2026

Un fichier RINEX de navigation contient les informations permettant de calculer la position des satellites et de gérer leur référence temporelle.

🟢 Vert : principaux paramètres orbitaux du satellite.

🟡 Jaune : paramètres liés à l’horloge du satellite.

🔵 Bleu : paramètres liés à la référence temporelle entre systèmes GNSS.

Ces données sont utilisées par le simulateur pour reproduire mathématiquement le comportement des satellites. Le signal obtenu peut ensuite être analysé par GNSS-SDR.

À retenir : un fichier RINEX ne contient pas directement la position du satellite en latitude/longitude. Il contient les paramètres permettant de calculer cette position.

3. Préparation du scénario GPS et génération des données d’attaque.

Une fois les données orbitales disponibles, GPS-SDR-SIM peut construire le scénario de simulation d’attaque par Spoofing, wow, nous y venons enfin ! Pour la parenthèse, rappellons que GPS-SDR-SIM est un simulateur logiciel open source qui permet de générer des flux de données de signaux GPS pour de la SDR (dans notre cas justement, on l’utilise sans SDR (le fameux HackRF One pour ceux qui ont suivi..). Développé initialement par Takuji Ebinuma (osqzss), GPS-SDR-SIM est massivement utilisé en environnement cybersécurité, en recherche et en ingénierie pour tester la résilience des récepteurs GPS face au spoofing ou, pour simuler des positions en laboratoire comme dans notre cas.

Pour en revenir à nos moutons, nous allons donc devoir définir la position du récepteur, l’altitude, la date et l’heure de simulation, la durée de la simulation ainsi que les données orbitales utilisées. À vrai dire, GPS-SDR-SIM nous mâche totalement le travail (soyons honnêtes !) qui serait d’ailleurs titanesque sinon… Après lui avoir fourni les données orbitales, les coordonnées du récepteur virtuel et la durée de simulation, GPS-SDR-SIM effectue automatiquement les calculs mathématiques nécessaires à la modélisation de la constellation. Il détermine notamment la position des satellites au cours du temps, leur géométrie par rapport au récepteur simulé, les temps de propagation et les décalages Doppler. Ces calculs servent ensuite à générer le signal GPS simulé sous forme « d’échantillons I/Q »… Nous approchons du but…

GPS-SDR-SIM utilise alors le scénario obtenu pour générer numériquement les signaux GPS et notre fichier tant attendu ! Dans notre cas, rappelons que c’est avec le signal civil GPS L1 C/A sur la fréquence 1575,42 MHz que cette simulation a lieu. Elle ne concerne pas les signaux GPS militaires ou protégés tels que P(Y) ou M-code, bien évidemment… À noter que chaque satellite GPS utilise un code PRN spécifique.

4. Génération numérique du signal GPS simulé et création du fichier I/Q.

Ces codes permettent au récepteur de distinguer les différents satellites, même lorsque leurs signaux utilisent la même fréquence porteuse (ce qui est notre cas ici). Dans cette démonstration, nous pouvons voir que les 14 satellites utilisés sont les PRN 04, 05, 11, 12, 16, 18, 20, 21, 25, 26, 28, 29, 31 et 32, s’appuyant bien sûr, sur la même fréquence porteuse L1 à 1575,42 MHz… GPS-SDR-SIM génère donc simultanément les contributions des différents satellites visibles dans le scénario. Nous nous retrouvons donc avec un fichier généré « test30.bin » aux spécificités généreuses.

Ça représente environ 10,3 Mo/s de données pendant les 30 secondes de Spoofing ! Ce fichier est enregistré sous forme d’échantillons I/Q. I/Q signifie pour information : I = In-phase et Q = Quadrature, deux composantes qui permettent de représenter numériquement l’amplitude et la phase du signal radio. Le résultat est donc, comme nous l’avons vu, un fichier binaire contenant une très grande quantité d’échantillons. Ce fichier contient donc la représentation numérique du signal radio GPS qui sera observé par le récepteur dans le scénario défini. Encore plus simple, il s’agit de nos signaux GPS « illégitimes » qui vont indiquer à tous les récepteurs environnants la position à prendre, soit Quimper, Nantes, Paris !

4.1 Note importante ! Le fichier d’échantillons I/Q ne contient pas directement les positions GPS « Nantes/Paris/Quimper »…

C’est un point que je souhaite détailler pour mieux cerner la méthodologie d’une attaque par Spoofing. D’ailleurs, avant de faire cet article, je pensais très naïvement que dans ce fichier I/Q que nous allons jouer, je trouverais les coordonnées GPS de Nantes préalablement définies (Latitude = 47.2185 Longitude = -1.5536). Toute la subtilité est là, avec ces dites coordonnées qui n’auront servi qu’en amont pour calculer les caractéristiques du scénario devant être joué. Factuellement, GPS-SDR-SIM va traduire ces positions (Quimper, Paris, Nantes) en caractéristiques physiques du signal : positionnement et géométrie satellite/récepteur, délais de propagation des signaux, Doppler, codes PRN permettant d’identifier les satellites et données de navigation.

L’ensemble est ensuite enregistré sous forme d’échantillons I/Q dans le fichier test30.bin comme nous l’avons vu. Lorsque GNSS-SDR analysera ce fichier, il ne lira donc pas « Nantes » avec les coordonnées GPS. Il va plutôt mesurer les caractéristiques des signaux des différents satellites inclus au fichier I/Q et convertira mathématiquement l’ensemble des données pour calculer à son tour une position. Spoiler : dans notre expérience, cette position finale entièrement calculée se situe autour de 47,21846° N et -1,55352° E, soit à Nantes, contre (Latitude = 47.2184 Longitude = -1.5536) initialement indiqué. Ce volet est finalement un peu contre-intuitif à assimiler, toutefois, une fois compris, la méthodologie devient plus limpide…

5. Réception et analyse du fichier I/Q avec le logiciel « GNSS-SDR ».

L’article est long, mais l’envoi des signaux GPS et de leur lecture par le récepteur est instantané ! Notre fichier IQ simulé est donc fourni à GNSS-SDR, qui simule parfaitement un récepteur GPS entièrement logiciel. Pour vulgariser, on peut le voir comme notre GPS de voiture qui reçoit les signaux en provenance du ciel… GNSS-SDR fonctionne ici comme un récepteur GPS entièrement logiciel, recevant les échantillons numériques et effectuant strictement les mêmes étapes qu’effectuerait un récepteur GNSS conventionnel. La première grande étape réalisée par GNSS-SDR est l’acquisition, en recherchant les PRN GPS dans le signal qui sont ni plus ni moins les différents satellites identifiés comme vu précédemment… Dès lors que les satellites sont identifiés, on voit apparaître dans les logs des messages du type : « Tracking of GPS L1 C/A signal started ».

Dans notre expérience, plusieurs PRN ont été détectés et donc validés. Tous toutefois ne restent pas nécessairement verrouillés en permanence… Pourquoi donc certains satellites passent et d’autres non ? C’est surtout lié à la géométrie de la constellation au moment de la simulation et à la qualité de réception simulée. Il peut y avoir des variables comme le placement par rapport au récepteur sur Terre, un positionnement par rapport inférieur à la ligne d’horizon, un problème de visibilité à l’instant T ou une détection, mais pas suffisamment stable pour que le GPS se verrouille dessus, comme dans la parfaite réalité…

Dans le cas de cette attaque par Spoofing GPS, le rapport temps était défavorable puisque j’ai joué une séquence de 30 secondes maximum, ce qui ne permet pas de profiter pleinement de toutes les trajectoires de satellites… Dans notre cas, des pertes de verrouillage récurrentes (« Loss of lock ») suivies de ré-acquisitions sont visibles, étant un comportement normal d’un récepteur logiciel sur fichier statique… Le récepteur GPS essaie toutefois de conserver la synchronisation avec chaque satellite détecté. Il suit notamment le code et la porteuse du signal. Le récepteur a donc réussi à décoder des messages de navigation complets (subframes 1, 2, 3) pour plusieurs satellites, avec des valeurs de CN0 (rapport porteuse/bruit) qui varient entre 34 et 65 dB-Hz selon les satellites…

6. Mesure des pseudo-distances et calcul de la position PVT.

Le récepteur peut ensuite exploiter les signaux provenant des différents satellites pour déterminer leurs temps de propagation apparents comme nous l’avons vu dans les premières étapes. Le principe est basé sur le temps nécessaire au signal pour parcourir la distance entre le satellite et le récepteur. Le récepteur compare les informations temporelles et détermine ainsi des mesures appelées pseudo-distances (pseudoranges). Le terme « pseudo » est important car ces mesures contiennent notamment des erreurs liées à l’horloge du récepteur et à différents phénomènes de propagation que je ne saurais expliquer. Le récepteur combine ensuite les mesures provenant de plusieurs satellites (PRN1 / PR2…) et va être capable de résoudre le problème de positionnement GPS. GNSS-SDR produit notamment une solution appelée PVT :

La position du récepteur est donc calculée à partir des signaux reçus et des informations de navigation. Dans notre expérience, GNSS-SDR a généré des fichiers de résultats tels que : PVT_260830_105827.geojson /PVT_260830_105827.gpx / PVT_260830_105827.kml. Le fichier GeoJSON contient notamment des coordonnées telles que : Longitude : -1,55352° Latitude : 47,21846°. Ces coordonnées correspondent à une position située à Nantes, très proche de la position utilisée pour construire le scénario. On peut donc vérifier expérimentalement que la chaîne de simulation et de réception fonctionne parfaitement et que notre expérimentation de Spoofing GPS, qui peut paraître complexe présentée ainsi, s’est parfaitement déroulée et reste accessible… C’est déjà fini !

7. Où intervient le HackRF One et le SDR dans cette expérimentation de Spoofing GPS ?

Dans cette phase de l’expérience d’une attaque par Spoofing GPS, le HackRF One n’était pas indispensable et surtout, pas vraiment le bienvenu. Même en étant déployé dans une cage de Faraday, les risques étaient trop grands. J’ai donc travaillé entièrement dans le domaine numérique. Le HackRF One SDR intervient lorsqu’on souhaite ajouter une interface radio matérielle capable de convertir les données numériques I/Q en signal RF, ou inversement, et de jouer véritablement des signaux GPS dans un but précis, très probablement malveillant. Ce n’était pas mon cas évidemment. Pour cette démonstration, je n’avais pas de possibilité de bénéficier d’un environnement contrôlé et autorisé afin d’éviter toute émission GPS susceptible d’affecter des récepteurs réels…

Le problème du spoofing GNSS n’est pas nécessairement d’avoir un émetteur extrêmement puissant ; c’est notamment le fait que les signaux satellitaires arrivent déjà au sol à un niveau extrêmement faible, de l’ordre de −130 dBm. Le C/N₀, lui, est généralement exprimé en dB-Hz et peut être de l’ordre de 40 dB-Hz dans de bonnes conditions de réception. Difficile donc de quantifier l’impact réel en cas d’attaque avec du matériel finalement accessible comme un HackRF One… Si vous avez à ce sujet des explications & indices, je suis preneur pour ma culture, car de mémoire, les HackRF One SDR et autres radios logicielles SDR sont très déployés en zone de guerre, surtout sur le sol ukrainien…

Débriefing du scénario | Remerciement à OpenAI & Anthropic, Les difficultés rencontrées & brèves de comptoir…

Notons que Claude & ChatGPT ont été d’une aide précieuse pour le débug tout au long de la réalisation de cette attaque, suite à de nombreux problèmes que nous allons passer en revue. Le premier et il s’agit du plus pénalisant au niveau du timing, a été de vouloir réaliser en une seule attaque, l’évolution des positions du récepteur entre Nantes, Quimper et Paris sur un laps de temps très court. C’est à ce moment que j’ai eu un enchaînement de problématiques, car cela imposait au récepteur simulé des vitesses irréalistes de l’ordre de plusieurs milliers de kilomètres par heure… Certains penseront que ça reste simulé… Et bien non ! N’oublions pas que cette attaque de Spoofing GPS exclut juste l’émetteur SDR Hack RF One pour des raisons de légalité, mais que tout le reste est identique…

Dès lors, notre récepteur GPS applique les mêmes lois physiques du signal GPS simulé. La position Paris/Nantes/Quimper a été irréalistement réalisée trop vite. Même si le récepteur n’a évidemment pas bougé physiquement, car il s’agit de la partie logicielle, le signal I/Q qu’on lui fournit représente mathématiquement ce déplacement, car s’appuyant sur de vraies données satellitaires (nos éphémérides) … Très premier degré dans l’âme, GNSS-SDR lui, ne sait pas que c’est « juste une simulation »… Il analyse le signal comme s’il provenait réellement d’un récepteur en mouvement, apportant aussi de facto ce côté extrêmement réaliste à l’attaque… D’autres problèmes sont survenus, mais mineur, comme la VM Virtual Box avec Kali Linux s’appuyant sur un espace de stockage des fichiers temporaires /tmp bien trop petit pour ce genre de simulation, résultant d’un aboutissement partiel des attaques…

Conclusion : Spoofing GPS, vulnérabilités, détection et contre-mesures face aux attaques par usurpation de position

Dans cet article, nous avons pu découvrir de manière semi-vulgarisée, les principes fondamentaux des attaques par Spoofing et surtout, que ces différentes attaques ne sont pas liées spécifiquement à un modèle ou une marque de GPS. L’usurpation de signaux GPS exploite avant tout une faiblesse inhérente liée à certaines architectures de positionnement reposant sur des signaux GPS dont l’authenticité n’est pas historiquement garantie de manière cryptographique… L’envoi de nos signaux falsifiés sont donc parfaitement visibles, comme nous l’avons vu, et entièrement traités et validés par notre récepteur qui heureusement, aurait pu s’appuyer sur d’autres variables de contrôle apportant une certaine résilience (fusion de capteurs, contrôle de cohérence, analyse temporelle, comparaison avec des sources indépendantes…), dans le cas d’un Smartphone comme vue précédemment par exemple.

Toutefois, comme nous l’avons vu, certains équipements (GPS auto, traceur de géolocalisation, GPS maritime/aérien) utilisent naïvement des positions usurpées avec une confiance aveugle, démontrant tous les dangers liés intimement à la géolocalisation. Nous avons vu tout au long de cet article que les contre-mesures basées qu’utilisent les smartphones apportent une certaine robustesse sécuritaire, réduisant le risque mais ne l’annulant pas, subtilité importante ! Comme nous le voyons, à technologie identique, c’est précisément le côté de confiance aveugle d’un équipement envers les GPS qui le transforme en surface d’attaque.

Pour résumer, tromper juste le GPS = abordable, mais détecté par le Wi-Fi/LTE environnant dans le cas d’un smartphone. Tromper aussi le Wi-Fi/GSM pour que rien ne soit détecté est possible, mais uniquement en théorie… Une théorie nécessitant une vraie logistique et qui sortira largement du budget/matériel d’un attaquant isolé, relevant dès lors plutôt d’un environnement de guerre électronique/étatique (je démissionne sur ce volet, salut !)… Pour clore cet article que l’innovation est une course sans fin entre briser et sécuriser… Un adage que l’IA avec le sulfureux Mythos ne pourra guère contester…