Stage chez ISLOG

L’entreprise :

Nom de l’entreprise : ISLOG D3L

Date de création : 6 decembre 2005

Président : Moerel Lionel

Forme juridique : Société à responsabilité limité

Effectif : 7 employés

La Société ISLOG D3L est une jeune entreprise qui développe des solutions logiciels pour le cryptage et l’encodage de cartes RFID et NFC. Ils travaillent avec plusieurs grands groupes tels que les aéroports de France. Leurs differents logiciels sont codés en C++.


Projet de stage :

Sur les 5 semaines de stages mon responsable a prévu 3 projets. Dans un premier temps je vais devoir me familiariser avec le langage C++ que je ne connais pas.

Le premier projet va me permettre de découvrir la librairie de l’entreprise nommée liblogicalaccess (voir la lib sur github)


Déroulement du stage :

semaine 1 :

Lundi : Arrivée au bureau à 9h. Après une présentation de l’équipe de développement, j’installe l’IDE que me propose l’entreprise pour commencer à découvrir le C++ : Clion. Travaillant sur un environnement linux, je n’ai pas utilisé Visual Studio. La journée a été consacré à la découverte du C++

Mardi : Deuxième journée d’apprentissage du C++.

Mercredi : La lib sur laquelle je vais devoir travailler utilisant Cmake pour se compiler, cette journée m’a permis d’en apprendre plus sur Cmake.

Jeudi : Compilation de la liblogicalaccess avec Cmake en matinée. Ajout des différentes dépendances de celle-ci et installation de mon premier lecteur de carte sans contact avec libusb et pcsc-lite. Lecture d’une carte de type Mifare classic avec PCSC-lite.

Vendredi : Développement avec la liblogicalaccess d’un code ayant pour but d’écrire, protéger puis relire des informations sur une carte de type Mifare Classic. L’utilisation de la lib pour cette partie était détaillée dans un wiki mais celui-ci n’était plus à jour. J’ai donc apporté les modifications au wiki pour le rendre juste.

 

Semaine 2 :

Lundi : Développement avec la liblogicalaccess d’un code ayant pour but d’écrire, protéger puis relire des informations sur une carte de type Mifare DesFire EV1. Ce nouveau type de carte est complètement différent des cartes MiFare Classic et je n’ai donc pas utilisé le code de vendredi. L’utilisation de la lib pour cette partie était détaillée dans un wiki mais celui-ci n’était plus à jour. J’ai donc apporté les modifications au wiki pour le rendre juste.

Mardi : Finalisation du code permettant de lire et d’écrire une carte Mifare DesFire EV1.

Mercredi : Mise au point avec Maxime sur la première partie de mon stage. En effet l’encodage et la lecture des cartes via la lib à l’aide du wiki m’a permis d’être plus à l’aise avec le C++. Il me présente mon second projet : le développement d’une classe permettant de faire du brut-force sur les cartes ayant des données cachées. En effet sur les cartes DesFire simplement encodée, une simple commande permet de voir tous les emplacements ou des données sont stockées. Mais une option permet de cacher cette information ainsi que le nom des fichiers qui sont stockés. Mon code devra donc récupérer les applications utilisées, codées sur 6 caractères hexadécimales, ainsi les numéros de clé actifs.

Jeudi : Première journée de développement de mon code de brut force. Ce code se présente sous la forme d’un test pour les cartes DesFire. Dans un premier temps je me connecte donc à la carte.

Vendredi : Mise en place de la boucle pour effectuer le brut force. Cette boucle commence avec le numéro d’application 0x000000 et se finit avec le numéro d’application 0xffffff. Cela fait donc plus de 16 millions de possibilités. Avec une carte simple  sur laquelle je connais les applications actives, je fais un tableau récapitulatif des exceptions pour voir comment reconnaître si l’application est active ou non (n’ayant pas la clé AES pour les lire je suis forcement en erreur ce qui retourne une exception).

Semaine 3 :

Lundi : Mise en place d’un affichage en pourcentage de l’avancée du brutForce. Le lecteur de carte est beaucoup plus lent que l’ordinateur et ne permet pas de dépasser 250 lectures par secondes. Ce ralentissement est la cause principale dans le temps de lecture complet d’une carte qui est de 18h.

Mardi : Pendant les premiers tests de brut force, le lecteur bloquait de façon aléatoire. Quand celui-ci bloque, le code se met en attente d’une réponse de lecteur puis retourne une erreur. A ce stade il m’est impossible de dépasser les 3% de progression. Pour résoudre ce problème, j’ai essayé de ralentir le nombre de requêtes par seconde envoyées au lecteur pour éviter une surcharge de celui-ci mais aucun changement n’a été constaté.

Mercredi : Expliquant mon problème à Maxime, il me fournit un second lecteur. Celui-ci n’a plus de surcharge et après plusieurs optimisations d’affichages dans la console, je lance un test qui doit tourner toute la nuit pour vérifier que tout fonctionne.

Jeudi : A mon arrivée, le code lancé la veille s’était mis en erreur à 12%. Le lecteur a réagi comme le précédent en bloquant inexplicablement. Après plusieurs tests, je crée un nouvel enum à la classe exception de la lib pour me permettre de séparer l’erreur de surcharge du lecteur des autres. Quand le lecteur surcharge l’erreur affichée me permet maintenant de relancer le test sur l’application ayant bloquée puis de continuer le test. Je récupère maintenant les numéros de clé utilisée (non pas le numéro AES mais chaque application peut avoir plusieurs clés différentes numérotées à partir de 0) ainsi que les numéros de fichiers. Un nouveau test est lancé le soir.

Vendredi : A mon arrivée, le code a fonctionné et j’ai vérifié avec Maxime que les informations récupérées sur la carte étaient bien identiques à celles qu’il avait encodé. Tout était correct. J’ai ajouté au code la possibilité d’avoir un masque pour permettre d’accélérer le code. Après ce dernier ajout, je fais le point avec Maxime puis nous discutons du projet suivant. Leur librairie utilisant plusieurs types de cartes, les tests unitaires n’étaient pas automatisés et pour lancer ceux-ci ils nécessitaient une personne devant l’ordinateur prêt a changer la carte sur le lecteur en fonction de l’avancée des tests. Il me demande donc de concevoir un système robotisé permettant l’automatisation de ces tests. J’ai donc fait des recherches et ai proposé à Maxime 6 devis différents pour plusieurs systèmes avec pour chacun les avantages et inconvénients.

 

Semaine 4 :

Lundi : Maxime m’annonce le projet retenu parmi les 6 proposés. Je lui fais donc un devis complet pour le matériel et une première commande est faite en ligne. Après réflexion nous décidons de monter un premier banc de test avant de monter celui-ci définitivement.

Mardi : A mon arrivée le matin Lionel m’annonce que nous partons acheter les différents matériaux nécessaires. Nous avons passé la matinée à Leroy Merlin. L’après-midi j’ai monté le banc d’essai en attendant que les composants électroniques arrivent.

Mercredi : Les différents composants électroniques sont arrivés. La matinée a été consacrée au montage des moteurs et de la courroie sur le banc d’essai. L’après-midi j’installe le système d’exploitation de la raspberry Pi et soude les différents composants électroniques ajoutés à celle-ci. Avec une connexion SSH, je teste pour la première fois le moteur avec un code rapide en python.

Jeudi : Développement du serveur en python sur la raspberry. Celui-ci reçoit les informations en GET et renvoit en JSON les retours en cas d’erreurs.

Vendredi : Développement de la gestion des moteurs en python. J’ai volontairement rendu cette classe complètement indépendante de mon système robotisé. Cette classe ne gère que les moteurs. La distance à parcourir, la liste des autres moteurs en mouvement seront gérés par une classe liée à mon banc d’essai. Cette dernière a été en partie codée ce même jour.

 

Semaine 5 :

Lundi : Finalisation de la classe de gestion de mon banc d’essai. Après une erreur de branchement, j’ai endommagé un contrôleur de moteur (chaque carte en possède 2). La lenteur du moteur pose problème. Je cherche donc toute la journée une solution pour augmenter la vitesse de celui-ci.

Mardi : Après avoir réussi à augmenter la vitesse du moteur, je lance plusieurs tests pour vérifier que tout fonctionne bien. Après ces tests, certaines erreurs ne me paraissent pas très précis et je détaille donc d’avantage les retours d’erreurs.

Mercredi : Pour que cette application puisse être utilisable par la suite, je me lance dans la rédaction d’un fichier Readme complet en anglais. En rédigeant ce document je retrouve des petites erreurs au sein du code que je corrige. Le soir avant de partir je lance un test faisant faire des allées-retours au moteur pour tester la précision du retour au centre ainsi que la solidité de ma solution.

Jeudi : A mon arrivée, une vis est tombée avec les vibrations mais mon banc d’essai est resté intact est précis au millimètre. Je reprend le code en python pour compléter la documentation que j’ai rédigée au fur et à mesure. Je code aussi une application bash client permettant de ne plus me connecter en SSH à la raspberry et utilisant le serveur mis en place.

 Vendredi : Après un bilan sur mon système, Lionel et Maxime décident de concrétiser mon projet en achetant le matériel nécessaire pour mettre en série 4 lignes robotisées définitives. Après un devis les pièces électroniques sont commandées et une liste est faite pour les matériaux de construction.


Après le stage

A la suite de mon stage je suis retourné pendant mes vacances scolaires pour construire puis tester la version finale du projet maintenant nommé liblogicalaccess-robot. CI-dessous des photos du système fini.