Open Source French Drone Identification

Mon problème n’est pas le combat de l’open source.

Mon problème est purement lié au texte et à la loi, au fait qu’on ne doit pas pouvoir modifier les paramètres. Or si on est en possession du code source ou si on le met a disposition, on facilite cette possibilité. On pourrait être considéré comme complice de l’usage qui pourrait en être fait.
Je veux bien mettre à disposition gratuitement mon travail mais je n’ai pas envi de devoir payer 10 000€ d’avocat pour me défendre devant les tribunaux.

Concernant le problème de sécurité du code, il y a une différence fondamentale entre l’usage d’un logiciel à distance, un serveur WEB comme NginX par exemple et un système sur lequel on a un accès physique.

Quand je parle de sécurité du code, je jeux dire qu’il n’est pas possible de relire le firmware ou qu’il ne sera ni possible de le désassemblé ni de le modifier sans de très gros effort.
l’ESP8266 n’a aucune mesure de protection possible, l’ESP32 de dernière génération le peut (code signé et clé RSA pour encrypter le code).

Il n’y a pas de possibilité de changer les paramètres … il faut reprogrammer la carte entièrement … ce n’est pas la même chose.
Suivant ton raisonnement, un fabricant X de balises ne pourrait pas les utiliser pour sa flotte de drones, car il a accès au code source ? Ça n’a pas de sens… et bloquerait toutes possibilités de mise à jour sur les modules.
Si tu veux un parallèle, regarde au niveau des logiciels de facturation ou comptabilité. Il exite des versions open source et pourtant la loi impose l’inviolabilité des données rentrées !

Le principe de l’open source repose sur la notion de copy et non pas de vente. Je n’ai pas de relation avec une personne qui utilise le code que j’ai fourni, car il possède et utilise sa propre version. C’est tout le principe de l’open source. S’il n’y a pas de vente, les auteurs ne sont pas responsables de l’usage qui en est fait. Il n’y aurait pas d’open source si les auteurs étaient tenus responsables …

Tu parles de système de sécurité du marché spatiale et militaire la … dans le grand public tout est accessible et modifiable … et sur un module d’identification drone, ça n’a aucun intérêt … les seuls données à copier sont l’identifiant et l’identifiant de la puce wifi, les deux s’obtiennent avec une puce wifi en mode écoute …Si quelqu’un accès à la puce, tu as déjà un autre problème et dans ce cas tous les fabricant de module d’identification ont un problème … car justement ils fournissent des modules. Donc n’importe qui peut faire du retroingéniering dessus.
Et tu peux protéger le code sur les ESP… Prend contact avec Espressif (le fabricant) et voit avec lui pour utiliser le sdk complet et pas la version gratuite !

Autre exemple, Parrot a annoncé l’arrivée de l’émission de l’identification sur l’ANAFI donc c’est hors la loi parce que les développeurs ont accés au code source et à la machine ?

Vraiment, je ne comprend la relation entre avoir un accés au code et l’inviolabilité des paramètres. Lors que le module est en fonctionnement, il n’est pas possible de changer ce qui est émis. Donc c’est conforme. Si tu veux le mettre a jour quand tu n’es pas en vol, tu en as la possibilité.

1 Like

Certes, pour celui qui connait la programmation, il est possible de modifier le code et d’envoyer des informations “manipulées” (l’altitude divisée par 2 par exemple), mais dans ce cas, ce n’est plus Pierre, qui peut être mis en cause. Lui a créé un code répondant aux caractéristiques et critères demandés par le texte de loi. Idem pour Laurent et Fred qui ont modifiés le code de Pierre pour le porter sur d’autres modules et permettant d’utiliser le GPS d’un Naza ou un BN180/220.
Le code ne peut pas être remis en cause tant que l’on ne le modifie pas pour envoyer de fausses informations. Les seules choses que l’on modifie si l’on respecte les choses, ce sont le nom du Wifi créé et l’identifiant. Qui ne sont pas modifiables en vol, mais seulement au sol après reprogrammation. Et quel intérêt ?

N’oublions pas qu’en cas de contrôle avec des informations fausses, c’est le propriétaire qui est fautif et passible de l’amende et de la éventuelle confiscation du matériel, pas le fabricant de module. La différence avec un module du commerce ou un DIY, c’est l’identifiant (et le prix aussi !) Dans le cas d’un module du commerce, il est créé et fourni par le fabricant du module. Dans le cas du DIY, nous créons nous même cet identifiant. A nous de ne pas faire n’importe quoi. Perso, j’ai fait un tableau dans lequel j’ai listé tous mes modèles, groupe, catégories de poids, module amovible ou fixe. Il me restera plus qu’à créer des identifiants différents, sauf pour les modèles à modules amovibles du même groupe et dans la même catégorie de poids, puisqu’ils peuvent utiliser le même module avec le même identifiant. (je ne sais pas si AT averti lorsqu’un identifiant est déjà utilisé !)

Je pense que si tous les modélistes jouent le jeu et utilisent le code en ne modifiant que le nom du WiFi et l’identifiant, et ont un module envoyant les véritables informations en respectant les spécifications de la loi, ce que fait le code de Pierre, il n’y aura pas de problème. Nous passerons pour des personnes responsables et raisonnables, et nous pourrons continuer à utiliser nos modules DIY. Si par contre, on commence à faire n’importe quoi, à modifier le code pour envoyer de fausses informations, on sera sanctionné, pas que par des amendes et confiscation de matériel, mais aussi pourquoi pas par l’obligation d’utiliser exclusivement des modules du commerce, ou homologué par la DGAC.

La balle est dans notre camp. A nous de montrer l’exemple.
N’oublions pas que si il n’y avait pas eu tous ses vols illégaux au dessus des villes, des centrales nucléaires, et autres sites stratégiques, nous n’en serions vraisemblablement pas arrivé là.
Trop tard, les conneries ont été faites. Essayons de limiter la casse…

" mais aussi par l’obligation d’utiliser exclusivement des modules du commerce."
Ils ne peuvent pas faire ça sur la base d’un code ouvert… Ils devront imposer une certification du module et donc rendront invalide tous les modules actuel… Et dans le cas d’une certification attention a la hausse des tarifs !

Merci à tous pour vos réponses.

J’ai été particulièrement étonné qu’il n’y ait aucune certification. Finalement tant mieux, ça permet à vos projets d’exister.
Pour ma part, tous mes modules du même modèle ont exactement le même code. je ne régénère pas un code par module, ce serait une folie.
Tout est basé sur la mac adresse car le fabriquant du composant me garantie son unicité.

Je suis persuadé que le prix des DES va chuter drastiquement, (50, 70€) dans les mois à venir. Les prix actuelles sont simplement sans justification.

On va fermer ce débat pour que la technique reprenne ses droits

Je viens de recevoir mon trigramme pour mes modules à base d’ESP 32 GPS M8N LORAWAN 433Mhz :slight_smile:
je les avaient déclaré avant la date limite pour éviter le module d’ici la fin de l’année mais maintenant que c’est fait, je vais me faire un petit plaisir… :wink:
Sinon je confirme qu’avec Plateformeio c’est un vrai plaisir à programmer et à charger dans les modules via le port micro-USB

1 Like

Je ne suis pas certain qu’il soit possible d’avoir le même identifiant pour tous tes modèles, sauf si ils sont tous du même groupe et de la même catégorie de poids au décollage, puisque c’est le seul cas ou l’on puisse utiliser le même DES. C’est ce que j’avais expliqué dans ma réponse il y a quelques jours ( Open Source French Drone Identification - #244 by TigerWill )

Je pense qu’il te faudra obligatoirement un identifiant différent pour chacun de tes modèles. C’est en tout cas, ce que je vais faire, et ce que j’avais compris. En plus, ce n’est pas compliqué à faire. Il faut juste s’organiser un peu.
Il faut un identifiant à 30 caractères (les trois premiers pour le trigramme, 3 caractères, puis 24 caractères). Je n’ai pas encore défini le nom du Wifi, surement le nom du modèle et le type.
Pour te donner des idées, voici le système d’identifiant que j’ai prévu :

  • TTT-G3-4KG--------UAS-FR-XXXXX
    TTT : trigramme
    -G3 : Groupe du modèle ( hélicoptère / multirotors / convertible / combiné / paramoteur / autogire )
    -2KG : catégorie de poids du modèle
    -------- : remplissage pour arriver au 24 caractères (j’ai lu nulle part que ce devait être obligatoirement des 0)
    UAS-FR-XXXXX : numéro d’enregistrement Alpha Tango
    (identifiant pour un multirotor compris entre 2 et 4 kg)

  • TTT-G4-2KG--------UAS-FR-XXXXX
    TTT : trigramme
    -G4 : Groupe du modèle ( avion, aile, planeur motorisé )
    -2KG : catégorie de poids du modèle
    -------- : remplissage pour arriver au 24 caractères (j’ai lu nulle part que ce devait être obligatoirement des 0)
    UAS-FR-XXXXX : numéro d’enregistrement Alpha Tango
    (identifiant pour un avion compris entre 800 gr et 2 kg)

Mais, ce n’est qu’une idée :wink:

Je me suis mal exprimé. Ils ont le même firmware, pas le même identifiant!
l’identifiant unique est différent pour chaque DES, il est une composition de la mac adresse de l’ESP32.
Il est interdit d’avoir des DES avec le même identifiant Chap1 art 4 de l’arrêté du 27 décembre

Le système AlfaTango permet d’enregistrer le même module avec plusieurs appareils (même groupe de modèle, même catégorie de poids).

Caractères autorisés ALPHANUM uniquement (pas de signes–). Le caractère de remplissage est le Zéro (c’est écrit dans le document d’alfatango).

Mon approche:

XXX(constructeur)YYY(personnel)0000…0000ZZZZZZZ(utilisateur)Gx(groupe modèle)Cp(Cat poids)

Les variables sont le groupe modèle et la catégorie de poids. Je lie à des balises les modèles que j’utilise hors zone ENR-5.5. Entre les planeurs, les motoplaneurs et les multirotors, ça devient lourd.

1 Like

dans le mail reçu ce jour envoyé par la DGAC :

note: dans notre document (celui que vous mentionné) il est également bien précisé que les aéronefs doivent être enregistrés au nom du même propriétaire (ce qui semblerait être votre cas), mais aussi qu’ils appartiennent à la même plage de masse. Si l’ensemble des critères est respecté, il est possible d’utiliser un même dispositif de signalement amovible pour plusieurs aéronefs (encore une fois, du même propriétaire, de la même plage de masse et du même groupe).

J’avais pas fait attention au fait que c’était des caractères alphanumériques uniquement. Néanmoins, le terme Alphanumérique est vague. Si on parle d’alphanumérique pur, c’est effectivement lettres et chiffres, mais bien souvent, cela comprend aussi les caractères minuscules, accentués ainsi que la ponctuation.

Toujours est-il qu’AT a accepté mon codage :thinking:

Comment remplir les 3 champs? J’ai reçu mon trigramme. Mais aucune explication pou remplir les 3 champs?
Merci.
Julien

Salut,

J’ai téléversé ton programme dans ma carte ESP32. Mais impossible de se connecter au bluetooth.
L’appli serial bluetooth donne une erreur de connexion:
connection failed: gatt status 133 BT mode

Je viens de voir qu’il faut se connecter en Bluetooth classique et pas en BLE. Du coup ca marche! :slight_smile:
Julien

1 Like

Salut,

Non, c’est pas le cas des dongle USB wifi, ca marche nickel le décodage. On peut passer les clés wifi en mode monitor sans problème.

julien

Bonjour,

qui a réussi à faire marcher le soft de test de la gendarmerie?
J’ai cette erreur :
Traceback (most recent call last):
File “main.py”, line 20, in
from lib.sh.sh import airmon_ng, service
ImportError: cannot import name ‘airmon_ng’ from ‘lib.sh.sh’ (/data/windows/lib/sh/sh.py)

une idée? effectivement je n’ai pas trouvé airmon_ng dans lib/sh/*

Oui, ça fonctionne. Il faut installer correctement airmon-ng. Puis positionner la carte wifi en mode monitor, puis vérifier si la carte est bien en mode monitor avec iwconfig. Puis bien lancer le main.py en mode root. Perso j’ai tester avec un raspberry pi et une clé externe wifi.
Pour info une APK a été conçue pour la gendarmerie. Donc il est possible de mettre en mode moniteur le wifi d’un smartphone et de sniffer le beacon wifi d’un Android. A priori le gain de l’antenne interne d’un smartphone et la sensibilité du récepteur wifi suffiraient. Donc surement que les gendarmes contrôleront l’espace aérien avec un simple smartphone. Perso j’utilise un ESP32 avec le programme qui décode la trame en C (merci à l’auteur), puis j’ai modifié ce programme pour que ce récepteur puisse renvoyer la trame en BLE, donc plus besoin de câble OTG et pas besoin de mode classique du bluetooth. Puis une simple application sur Appinventor permet de recevoir les trames et de positionner son aéronef facilement et de réaliser d’autres traitements. Il a fallu modifier le MTU du BLE pour le passer de 23 bytes à 150 bytes pour lire la trame d’un seul coup.
Ca donne cette IHM. Ca marche impec.

2 Likes

Cette nouvelle possibilité est très intéressante, est-ce que tu vas partager les codes ?

Oui, bien sur. Merci pour ton code sur lequel je me suis appuyé pour ajouter la partie envoie d’une trame en BLE. Pour ton info, tu as une petite erreur dans le décodeur sur le nombre d’octets pour la partie heading que tu as mise à 1 byte au lieu de 2 bytes.


La partie appinventor permet de développer l’appli et de la modifier en mode blockly sur la partie smartphone et de l’adapter à ses besoins.
Julien.

Merci, j’ai effectué la correction :wink:
A mon bureau, sur mon sniffer, j’ai toujours 0 qui s’affiche mais cette fois c’est correct :joy:

Edit: Je découvre le MIT App Inventor qui se programme avec des blocs logiques en mode graphique, ça pique ma curiosité …

Pour ceux que cela intéresse un petit bouquin pour expliquer Appinventor pour la programmation d’un smartphone Android.