https://projets-ima.plil.fr/mediawiki/api.php?action=feedcontributions&feedformat=atom&user=Mcreteur 2026-05-13T20:53:37Z Contributions de l’utilisateur MediaWiki 1.29.2 https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79860 2019-12-17T19:48:51Z

<p>Mcreteur : /* Décompilation */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur USB - TTL pour l'exploitation de pins de communication série<br /> * Segger JLink pour l'exploitation de pins de Serial Wire Debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * [https://ghidra-sre.org/ Ghidra]<br /> * [https://rada.re/n/ Radare2]<br /> * [https://github.com/ReFirmLabs/binwalk Binwalk]<br /> * [https://github.com/craigz28/firmwalker Firmwalker]<br /> * [https://ibotpeaches.github.io/Apktool/ Apktool]<br /> * [https://github.com/pxb1988/dex2jar dex2jar]<br /> * [https://java-decompiler.github.io/ JDGUI]<br /> * [https://www.benf.org/other/cfr/ CFR decompiler]<br /> * [https://www.zaproxy.org/ OWASP ZAP]<br /> * [https://developer.android.com/studio/command-line/adb Android Debug Bridge]<br /> * [https://github.com/nelenkov/android-backup-extractor Android backup extractor]<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> ===Exploitation des pins présent sur le circuit===<br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom. Afin de vérifier que rien n'était envoyé par l'objet sur les Rx et Tx, j'ai utilisé un oscilloscope. La différence de potentielle observée entre les pins Tx et GND était trop faible pour qu'une quelconque information ne soit envoyée via l'UART de l'objet.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> ===Ecoute de la communication entre l'application mobile étudiée et le serveur distant===<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. <br /> Malheureusement, ce fichier d'extension .des semble être un fichier encrypté. Une mesure de l'entropie du fichier sur binvis.io me l'a confirmé. 'des' étant l'acronyme pour Data Encryption Standard, une méthode ancienne de cryptage de données, j'ai cherché un moyen de décrypter le fichier par bruteforce. Je n'ai malheureusement trouvé aucun programme permettant cela.<br /> <br /> ===Analyse d'un firmware===<br /> N'ayant pas pu exploiter le fichier récupéré de l'API Terraillon, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> ===Ecoute de la communication application mobile - objet connecté===<br /> <br /> La dernière piste pour récupérer le firmware de l'objet est l'écoute de la communication bluetooth ayant lieue entre l'objet connecté et l'application mobile pour le transfert de données ou de mise à jour. Ayant commencé à explorer cette piste en tout fin de projet, j'ai du faire avec le matériel disponible, un LimeSDR qui est un radio logiciel. La recherche d'un programme compatible avec le LimeSDR permettant de capturer les communications bluetooth n'a pas été très fructueuse puisque je n'ai trouvé qu'un seul outil sous forme de projet sur github, [https://github.com/jocover/BLESDR blesdr]. Après 3 tentatives, ce programme ne m'a permis de récupérer que les paquets d'advertising.<br /> Après quelques recherches il semblerait qu'un development kit nRF52 ou 51 ou un Adafruit Bluefruit programmés avec le nRF sniffer permettraient de réaliser l'action souhaitée et de manière beaucoup plus simple.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> ===Décompilation===<br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Les deux outils présentés précédemment ne permettent que de transformer les fichiers Dalvik Executable de l'APK en fichiers java. Afin de pouvoir exploiter les fichiers comme le AndroidManifest.xml accompagnant toute application Android ou les ressources qui lui sont associées, on peut utiliser apktool : <br /> <br /> apktool decode application.apk<br /> <br /> ===Analyse du code source===<br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ===Exploitation===<br /> En analysant le manifeste android de l'application, j'ai pu localiser la présence d'une propriété très interessante :<br /> <br /> android:allowBackup=&quot;true&quot;<br /> <br /> Cette propriété, mise à &quot;true&quot; par défaut, permet de réaliser une récupération des données de l'application via les outils Android. J'ai donc tenté de récupérer les différentes informations que stocke l'application étudiée dans le téléphone. Pour cela j'ai utilisé l'outil Android Debug Bridge, un outil android en ligne de commande qui permet de réaliser différentes opérations sur un téléphone android. Après avoir activé le mode développeur sur le smartphone utilisé, étape nécessaire pour réaliser la récupération, je l'ai connecté à mon ordinateur. La commande <br /> adb devices -l <br /> permet lister les périphériques détectés. Mon smartphone étant bien reconnu, j'ai cherché le nom du package android lié à l'application étudiée afin de ne lancer la récupération que pour cette application. Pour cela, la commande <br /> adb shell pm list packages<br /> permet de lister tous les packages présents dans le téléphone. Une fois en possession du nom de package désiré, j'ai pu lancé la récupération des données avec la commande :<br /> adb backup -f {nom_du_fichier_backup} {nom_du_package_cible}<br /> Après avoir accepté l'opération de récupération sur le smartphone en précisant ou non un mot de passe pour encrypter les données, un fichier d'extension .ab apparaît à l'emplacement spécifié. Afin de pouvoir exploiter les données contenues dans ce fichier, j'ai utilisé l'outil Android backup extractor permettant de convertir un fichier android backup en une archive compressée : <br /> java -jar abe.jar unpack {fichier_a_convertir.ab} {nom_de_l'archive.tar} {mot_de_passe}<br /> J'ai enfin pu décompresser l'archive obtenue avec la commande précédente et visualiser les données de l'application. J'ai pu y trouver le fichier utilisé par le mécanisme de SharedPreferences Android que j'avais localisé dans le code contenant entre autres mon login ou encore mon mot de passe en clair. J'ai aussi pu y trouver le fichier de base de données utilisé par l'application avec les données enregistrées. <br /> <br /> Au cours de l'analyse du code source, j'ai pu remarquer que certaines informations étaient loggées. Android Debug Bridge m'a alors été encore utile puisqu'il m'a permis de suivre les logs de l'application avec logcat via la commande : <br /> adb logcat {nom_package_cible}<br /> Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application.<br /> <br /> ==Automatisation==<br /> <br /> ===Outil développé===<br /> <br /> Le but final de ce projet étant d’essayer d’automatiser les méthodes et outils proposés, j’ai développé un script permettant d’avoir une première impression sur le code d’une application mobile à partir de son APK. Ce script gère le processus de décompilation et de décodage avec les outils dex2jar, CFR et apktool avant de réaliser une analyse statique du code obtenu.<br /> Ayant besoin d’un fichier APK et des outils cités précédemment, ce script s’utilise de la façon suivante : <br /> $ apk_analysis.sh {application.apk} {chemin_vers_dossier_dex2jar} {chemin_vers_CFR.jar} {chemin_vers_apktool}<br /> Si le nombre d’arguments qui lui sont présentés n’est pas correct, un rappel d’utilisation est affiché à l’utilisateur. <br /> Une fois la décompilation et le décodage réalisé, une analyse est lancée afin de trouver dans le code : <br /> *Les permissions requises par l’application<br /> *Les features Android utilisées<br /> *La présence des propriétés android:allowBackup et android:debuggable<br /> *La présence d’URL<br /> *La présence d’appel HTTP<br /> *La présence de log Android<br /> *La base de données utilisée par l’application<br /> *La présence de requête SQL<br /> *La présence de hash MD5<br /> *La présence des mots clés “login=”, “admin=”, “password=”, “passwd=”, “apikey=”, “secret=”, “token=”, “firmware” ou encore “url=”<br /> <br /> Ces recherches sont réalisées à l’aide de la commande grep et d’expressions régulières. Le résultat de l’analyse est enregistré dans le fichier {nom_de_l’application}_analysis.txt créé dans le répertoire courant. Un dossier contenant la décompilation et le décodage de l’APK est créé aussi à cet endroit avec pour nom le nom de l’application analysée, ce dernier étant extrait du nom du fichier APK.<br /> J’ai développé ce script non pas uniquement pour repérer des failles de sécurité dans l’application mais plutôt afin d’avoir une idée grossière de comment l’application étudiée fonctionne en me basant sur l’étude que j’ai réalisé manuellement dans ce projet tout en essayant de rendre l’analyse pertinente à n’importe quelle application Android. <br /> La décompilation d’une application ne décompilant pas uniquement le code produit par les développeurs mais aussi toutes les ressources utilisées, la difficulté dans le travail effectué a été de savoir dans quel(s) dossier(s) effectuer chaque partie de l’analyse afin de ne récupérer que ce qu’il nous intéresse vraiment. Par exemple, pour l’analyse des appels aux fonctions de log Android, j’ai remarqué que de nombreuses ressources/dépendances faisaient des appels à ces fonctions et cela ne nous intéresse pas du tout de savoir quels sont ces logs. Afin d’éviter cela, j’ai extrait le nom du package écrit dans le fichier AndroidManifest afin de le transformer en chemin. C’est généralement dans ce package que se trouve tout le code nous intéressant. J’ai cependant dû modifier le comportement de mon script lorsque je me suis rendu compte qu’après décompilation de certaines applications, le package écrit dans le manifeste Android n’existe pas. J’ai donc dû mettre en place une recherche de ce package avant toute analyse afin de vérifier son existence. Si il n’existe pas, il n’y a pas d’autres choix que d’élargir la recherche à tout le code excepté quelques dossiers que l’on retrouve régulièrement comme android ou androidx.<br /> En revanche, pour la recherche de mots clés ou de requêtes SQL par exemple, il va être intéressant de réaliser l’analyse dans l’intégralité du code puisque je me suis rendu compte qu’assez souvent, on trouvait certains mots clés ou requêtes SQL dans le code smali que l’on ne retrouvait pas dans le code java, faute de décompilation ou autre. <br /> L’utilisateur se verra alors parasité avec quelques résultats ne l’intéressant pas mais je n’ai pas trouvé de meilleure solution pour être plus précis dans les recherches. Dans tous les cas, le tri manuel par l’utilisateur des résultats obtenus restera beaucoup plus rapide qu’une analyse manuelle fichier par fichier.<br /> <br /> <br /> ===Tests===<br /> <br /> Afin de tester la pertinence et l'efficacité de l'outil développé, je l'ai essayé sur plusieurs applications mobiles Android d'IoT plus ou moins connues. Les résultats ont été plutôt satisfaisant puisque pour les 4 applications analysées j'ai pu récupérer l'adresse de l'API utilisée ainsi que le type de base de données. L'analyse de certaines applications a révélé l'utilisation des fonctions de log Android ainsi que des appels HTTP. Dans les 4 applications, des occurrences au mot clé firmware ont été trouvées. J'ai pu récupéré aussi un grand nombre de requête SQL. Je me suis rendu compte que les 4 applications testées présentaient des parties de code obfusquées, ce qui n'avait pas été le cas pour l'application étudiée dans ce projet. L’outil développé remplit donc son rôle, à savoir, décompiler et décoder une application ainsi que présenter à l’utilisateur des morceaux de code qui vont lui permettre de comprendre de façon générale le fonctionnement de l’application et de lui donner des pistes pour une analyse plus profonde. Les morceaux de code recherchés par l’outil ont été défini à partir de l’analyse manuelle que j’ai pu réaliser sur l’application étudiée et ne sont donc peut-être pas pertinents pour tout le monde. L’outil conçu n’est pas fait pour être figé, l’analyse peut être modifiée rapidement selon les préférences de l’utilisateur, le plus gros du travail étant déjà réalisé.<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git<br /> <br /> Ayant convenu avec les encadrants de ne mettre aucun des résultats obtenus dans ce wiki public en raison des effets que cela pourrait provoquer vis à vis de la société commercialisant l'objet étudié, le rapport de ce projet n'a été communiqué que par mail aux encadrants.</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79859 2019-12-17T19:45:39Z

<p>Mcreteur : /* Automatisation */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur USB - TTL pour l'exploitation de pins de communication série<br /> * Segger JLink pour l'exploitation de pins de Serial Wire Debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * [https://ghidra-sre.org/ Ghidra]<br /> * [https://rada.re/n/ Radare2]<br /> * [https://github.com/ReFirmLabs/binwalk Binwalk]<br /> * [https://github.com/craigz28/firmwalker Firmwalker]<br /> * [https://ibotpeaches.github.io/Apktool/ Apktool]<br /> * [https://github.com/pxb1988/dex2jar dex2jar]<br /> * [https://java-decompiler.github.io/ JDGUI]<br /> * [https://www.benf.org/other/cfr/ CFR decompiler]<br /> * [https://www.zaproxy.org/ OWASP ZAP]<br /> * [https://developer.android.com/studio/command-line/adb Android Debug Bridge]<br /> * [https://github.com/nelenkov/android-backup-extractor Android backup extractor]<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> ===Exploitation des pins présent sur le circuit===<br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom. Afin de vérifier que rien n'était envoyé par l'objet sur les Rx et Tx, j'ai utilisé un oscilloscope. La différence de potentielle observée entre les pins Tx et GND était trop faible pour qu'une quelconque information ne soit envoyée via l'UART de l'objet.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> ===Ecoute de la communication entre l'application mobile étudiée et le serveur distant===<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. <br /> Malheureusement, ce fichier d'extension .des semble être un fichier encrypté. Une mesure de l'entropie du fichier sur binvis.io me l'a confirmé. 'des' étant l'acronyme pour Data Encryption Standard, une méthode ancienne de cryptage de données, j'ai cherché un moyen de décrypter le fichier par bruteforce. Je n'ai malheureusement trouvé aucun programme permettant cela.<br /> <br /> ===Analyse d'un firmware===<br /> N'ayant pas pu exploiter le fichier récupéré de l'API Terraillon, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> ===Ecoute de la communication application mobile - objet connecté===<br /> <br /> La dernière piste pour récupérer le firmware de l'objet est l'écoute de la communication bluetooth ayant lieue entre l'objet connecté et l'application mobile pour le transfert de données ou de mise à jour. Ayant commencé à explorer cette piste en tout fin de projet, j'ai du faire avec le matériel disponible, un LimeSDR qui est un radio logiciel. La recherche d'un programme compatible avec le LimeSDR permettant de capturer les communications bluetooth n'a pas été très fructueuse puisque je n'ai trouvé qu'un seul outil sous forme de projet sur github, [https://github.com/jocover/BLESDR blesdr]. Après 3 tentatives, ce programme ne m'a permis de récupérer que les paquets d'advertising.<br /> Après quelques recherches il semblerait qu'un development kit nRF52 ou 51 ou un Adafruit Bluefruit programmés avec le nRF sniffer permettraient de réaliser l'action souhaitée et de manière beaucoup plus simple.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> ===Décompilation===<br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> ===Analyse du code source===<br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ===Exploitation===<br /> En analysant le manifeste android de l'application, j'ai pu localiser la présence d'une propriété très interessante :<br /> <br /> android:allowBackup=&quot;true&quot;<br /> <br /> Cette propriété, mise à &quot;true&quot; par défaut, permet de réaliser une récupération des données de l'application via les outils Android. J'ai donc tenté de récupérer les différentes informations que stocke l'application étudiée dans le téléphone. Pour cela j'ai utilisé l'outil Android Debug Bridge, un outil android en ligne de commande qui permet de réaliser différentes opérations sur un téléphone android. Après avoir activé le mode développeur sur le smartphone utilisé, étape nécessaire pour réaliser la récupération, je l'ai connecté à mon ordinateur. La commande <br /> adb devices -l <br /> permet lister les périphériques détectés. Mon smartphone étant bien reconnu, j'ai cherché le nom du package android lié à l'application étudiée afin de ne lancer la récupération que pour cette application. Pour cela, la commande <br /> adb shell pm list packages<br /> permet de lister tous les packages présents dans le téléphone. Une fois en possession du nom de package désiré, j'ai pu lancé la récupération des données avec la commande :<br /> adb backup -f {nom_du_fichier_backup} {nom_du_package_cible}<br /> Après avoir accepté l'opération de récupération sur le smartphone en précisant ou non un mot de passe pour encrypter les données, un fichier d'extension .ab apparaît à l'emplacement spécifié. Afin de pouvoir exploiter les données contenues dans ce fichier, j'ai utilisé l'outil Android backup extractor permettant de convertir un fichier android backup en une archive compressée : <br /> java -jar abe.jar unpack {fichier_a_convertir.ab} {nom_de_l'archive.tar} {mot_de_passe}<br /> J'ai enfin pu décompresser l'archive obtenue avec la commande précédente et visualiser les données de l'application. J'ai pu y trouver le fichier utilisé par le mécanisme de SharedPreferences Android que j'avais localisé dans le code contenant entre autres mon login ou encore mon mot de passe en clair. J'ai aussi pu y trouver le fichier de base de données utilisé par l'application avec les données enregistrées. <br /> <br /> Au cours de l'analyse du code source, j'ai pu remarquer que certaines informations étaient loggées. Android Debug Bridge m'a alors été encore utile puisqu'il m'a permis de suivre les logs de l'application avec logcat via la commande : <br /> adb logcat {nom_package_cible}<br /> Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application.<br /> <br /> ==Automatisation==<br /> <br /> ===Outil développé===<br /> <br /> Le but final de ce projet étant d’essayer d’automatiser les méthodes et outils proposés, j’ai développé un script permettant d’avoir une première impression sur le code d’une application mobile à partir de son APK. Ce script gère le processus de décompilation et de décodage avec les outils dex2jar, CFR et apktool avant de réaliser une analyse statique du code obtenu.<br /> Ayant besoin d’un fichier APK et des outils cités précédemment, ce script s’utilise de la façon suivante : <br /> $ apk_analysis.sh {application.apk} {chemin_vers_dossier_dex2jar} {chemin_vers_CFR.jar} {chemin_vers_apktool}<br /> Si le nombre d’arguments qui lui sont présentés n’est pas correct, un rappel d’utilisation est affiché à l’utilisateur. <br /> Une fois la décompilation et le décodage réalisé, une analyse est lancée afin de trouver dans le code : <br /> *Les permissions requises par l’application<br /> *Les features Android utilisées<br /> *La présence des propriétés android:allowBackup et android:debuggable<br /> *La présence d’URL<br /> *La présence d’appel HTTP<br /> *La présence de log Android<br /> *La base de données utilisée par l’application<br /> *La présence de requête SQL<br /> *La présence de hash MD5<br /> *La présence des mots clés “login=”, “admin=”, “password=”, “passwd=”, “apikey=”, “secret=”, “token=”, “firmware” ou encore “url=”<br /> <br /> Ces recherches sont réalisées à l’aide de la commande grep et d’expressions régulières. Le résultat de l’analyse est enregistré dans le fichier {nom_de_l’application}_analysis.txt créé dans le répertoire courant. Un dossier contenant la décompilation et le décodage de l’APK est créé aussi à cet endroit avec pour nom le nom de l’application analysée, ce dernier étant extrait du nom du fichier APK.<br /> J’ai développé ce script non pas uniquement pour repérer des failles de sécurité dans l’application mais plutôt afin d’avoir une idée grossière de comment l’application étudiée fonctionne en me basant sur l’étude que j’ai réalisé manuellement dans ce projet tout en essayant de rendre l’analyse pertinente à n’importe quelle application Android. <br /> La décompilation d’une application ne décompilant pas uniquement le code produit par les développeurs mais aussi toutes les ressources utilisées, la difficulté dans le travail effectué a été de savoir dans quel(s) dossier(s) effectuer chaque partie de l’analyse afin de ne récupérer que ce qu’il nous intéresse vraiment. Par exemple, pour l’analyse des appels aux fonctions de log Android, j’ai remarqué que de nombreuses ressources/dépendances faisaient des appels à ces fonctions et cela ne nous intéresse pas du tout de savoir quels sont ces logs. Afin d’éviter cela, j’ai extrait le nom du package écrit dans le fichier AndroidManifest afin de le transformer en chemin. C’est généralement dans ce package que se trouve tout le code nous intéressant. J’ai cependant dû modifier le comportement de mon script lorsque je me suis rendu compte qu’après décompilation de certaines applications, le package écrit dans le manifeste Android n’existe pas. J’ai donc dû mettre en place une recherche de ce package avant toute analyse afin de vérifier son existence. Si il n’existe pas, il n’y a pas d’autres choix que d’élargir la recherche à tout le code excepté quelques dossiers que l’on retrouve régulièrement comme android ou androidx.<br /> En revanche, pour la recherche de mots clés ou de requêtes SQL par exemple, il va être intéressant de réaliser l’analyse dans l’intégralité du code puisque je me suis rendu compte qu’assez souvent, on trouvait certains mots clés ou requêtes SQL dans le code smali que l’on ne retrouvait pas dans le code java, faute de décompilation ou autre. <br /> L’utilisateur se verra alors parasité avec quelques résultats ne l’intéressant pas mais je n’ai pas trouvé de meilleure solution pour être plus précis dans les recherches. Dans tous les cas, le tri manuel par l’utilisateur des résultats obtenus restera beaucoup plus rapide qu’une analyse manuelle fichier par fichier.<br /> <br /> <br /> ===Tests===<br /> <br /> Afin de tester la pertinence et l'efficacité de l'outil développé, je l'ai essayé sur plusieurs applications mobiles Android d'IoT plus ou moins connues. Les résultats ont été plutôt satisfaisant puisque pour les 4 applications analysées j'ai pu récupérer l'adresse de l'API utilisée ainsi que le type de base de données. L'analyse de certaines applications a révélé l'utilisation des fonctions de log Android ainsi que des appels HTTP. Dans les 4 applications, des occurrences au mot clé firmware ont été trouvées. J'ai pu récupéré aussi un grand nombre de requête SQL. Je me suis rendu compte que les 4 applications testées présentaient des parties de code obfusquées, ce qui n'avait pas été le cas pour l'application étudiée dans ce projet. L’outil développé remplit donc son rôle, à savoir, décompiler et décoder une application ainsi que présenter à l’utilisateur des morceaux de code qui vont lui permettre de comprendre de façon générale le fonctionnement de l’application et de lui donner des pistes pour une analyse plus profonde. Les morceaux de code recherchés par l’outil ont été défini à partir de l’analyse manuelle que j’ai pu réaliser sur l’application étudiée et ne sont donc peut-être pas pertinents pour tout le monde. L’outil conçu n’est pas fait pour être figé, l’analyse peut être modifiée rapidement selon les préférences de l’utilisateur, le plus gros du travail étant déjà réalisé.<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git<br /> <br /> Ayant convenu avec les encadrants de ne mettre aucun des résultats obtenus dans ce wiki public en raison des effets que cela pourrait provoquer vis à vis de la société commercialisant l'objet étudié, le rapport de ce projet n'a été communiqué que par mail aux encadrants.</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79858 2019-12-17T19:35:28Z

<p>Mcreteur : /* Automatisation */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur USB - TTL pour l'exploitation de pins de communication série<br /> * Segger JLink pour l'exploitation de pins de Serial Wire Debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * [https://ghidra-sre.org/ Ghidra]<br /> * [https://rada.re/n/ Radare2]<br /> * [https://github.com/ReFirmLabs/binwalk Binwalk]<br /> * [https://github.com/craigz28/firmwalker Firmwalker]<br /> * [https://ibotpeaches.github.io/Apktool/ Apktool]<br /> * [https://github.com/pxb1988/dex2jar dex2jar]<br /> * [https://java-decompiler.github.io/ JDGUI]<br /> * [https://www.benf.org/other/cfr/ CFR decompiler]<br /> * [https://www.zaproxy.org/ OWASP ZAP]<br /> * [https://developer.android.com/studio/command-line/adb Android Debug Bridge]<br /> * [https://github.com/nelenkov/android-backup-extractor Android backup extractor]<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> ===Exploitation des pins présent sur le circuit===<br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom. Afin de vérifier que rien n'était envoyé par l'objet sur les Rx et Tx, j'ai utilisé un oscilloscope. La différence de potentielle observée entre les pins Tx et GND était trop faible pour qu'une quelconque information ne soit envoyée via l'UART de l'objet.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> ===Ecoute de la communication entre l'application mobile étudiée et le serveur distant===<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. <br /> Malheureusement, ce fichier d'extension .des semble être un fichier encrypté. Une mesure de l'entropie du fichier sur binvis.io me l'a confirmé. 'des' étant l'acronyme pour Data Encryption Standard, une méthode ancienne de cryptage de données, j'ai cherché un moyen de décrypter le fichier par bruteforce. Je n'ai malheureusement trouvé aucun programme permettant cela.<br /> <br /> ===Analyse d'un firmware===<br /> N'ayant pas pu exploiter le fichier récupéré de l'API Terraillon, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> ===Ecoute de la communication application mobile - objet connecté===<br /> <br /> La dernière piste pour récupérer le firmware de l'objet est l'écoute de la communication bluetooth ayant lieue entre l'objet connecté et l'application mobile pour le transfert de données ou de mise à jour. Ayant commencé à explorer cette piste en tout fin de projet, j'ai du faire avec le matériel disponible, un LimeSDR qui est un radio logiciel. La recherche d'un programme compatible avec le LimeSDR permettant de capturer les communications bluetooth n'a pas été très fructueuse puisque je n'ai trouvé qu'un seul outil sous forme de projet sur github, [https://github.com/jocover/BLESDR blesdr]. Après 3 tentatives, ce programme ne m'a permis de récupérer que les paquets d'advertising.<br /> Après quelques recherches il semblerait qu'un development kit nRF52 ou 51 ou un Adafruit Bluefruit programmés avec le nRF sniffer permettraient de réaliser l'action souhaitée et de manière beaucoup plus simple.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> ===Décompilation===<br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> ===Analyse du code source===<br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ===Exploitation===<br /> En analysant le manifeste android de l'application, j'ai pu localiser la présence d'une propriété très interessante :<br /> <br /> android:allowBackup=&quot;true&quot;<br /> <br /> Cette propriété, mise à &quot;true&quot; par défaut, permet de réaliser une récupération des données de l'application via les outils Android. J'ai donc tenté de récupérer les différentes informations que stocke l'application étudiée dans le téléphone. Pour cela j'ai utilisé l'outil Android Debug Bridge, un outil android en ligne de commande qui permet de réaliser différentes opérations sur un téléphone android. Après avoir activé le mode développeur sur le smartphone utilisé, étape nécessaire pour réaliser la récupération, je l'ai connecté à mon ordinateur. La commande <br /> adb devices -l <br /> permet lister les périphériques détectés. Mon smartphone étant bien reconnu, j'ai cherché le nom du package android lié à l'application étudiée afin de ne lancer la récupération que pour cette application. Pour cela, la commande <br /> adb shell pm list packages<br /> permet de lister tous les packages présents dans le téléphone. Une fois en possession du nom de package désiré, j'ai pu lancé la récupération des données avec la commande :<br /> adb backup -f {nom_du_fichier_backup} {nom_du_package_cible}<br /> Après avoir accepté l'opération de récupération sur le smartphone en précisant ou non un mot de passe pour encrypter les données, un fichier d'extension .ab apparaît à l'emplacement spécifié. Afin de pouvoir exploiter les données contenues dans ce fichier, j'ai utilisé l'outil Android backup extractor permettant de convertir un fichier android backup en une archive compressée : <br /> java -jar abe.jar unpack {fichier_a_convertir.ab} {nom_de_l'archive.tar} {mot_de_passe}<br /> J'ai enfin pu décompresser l'archive obtenue avec la commande précédente et visualiser les données de l'application. J'ai pu y trouver le fichier utilisé par le mécanisme de SharedPreferences Android que j'avais localisé dans le code contenant entre autres mon login ou encore mon mot de passe en clair. J'ai aussi pu y trouver le fichier de base de données utilisé par l'application avec les données enregistrées. <br /> <br /> Au cours de l'analyse du code source, j'ai pu remarquer que certaines informations étaient loggées. Android Debug Bridge m'a alors été encore utile puisqu'il m'a permis de suivre les logs de l'application avec logcat via la commande : <br /> adb logcat {nom_package_cible}<br /> Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application.<br /> <br /> ==Automatisation==<br /> <br /> ===Outil développé===<br /> <br /> Le but final de ce projet étant d’essayer d’automatiser les méthodes et outils proposés, j’ai développé un script permettant d’avoir une première impression sur le code d’une application mobile à partir de son APK. Ce script gère le processus de décompilation et de décodage avec les outils dex2jar, CFR et apktool avant de réaliser une analyse statique du code obtenu.<br /> Ayant besoin d’un fichier APK et des outils cités précédemment, ce script s’utilise de la façon suivante : <br /> $ apk_analysis.sh {application.apk} {chemin_vers_dossier_dex2jar} {chemin_vers_CFR.jar} {chemin_vers_apktool}<br /> Si le nombre d’arguments qui lui sont présentés n’est pas correct, un rappel d’utilisation est affiché à l’utilisateur. <br /> Une fois la décompilation et le décodage réalisé, une analyse est lancée afin de trouver dans le code : <br /> *Les permissions requises par l’application<br /> *Les features Android utilisées<br /> *La présence des propriétés android:allowBackup et android:debuggable<br /> *La présence d’URL<br /> *La présence d’appel HTTP<br /> *La présence de log Android<br /> *La base de données utilisée par l’application<br /> *La présence de requête SQL<br /> *La présence de hash MD5<br /> *La présence des mots clés “login=”, “admin=”, “password=”, “passwd=”, “apikey=”, “secret=”, “token=”, “firmware” ou encore “url=”<br /> <br /> Ces recherches sont réalisées à l’aide de la commande grep et d’expressions régulières. Le résultat de l’analyse est enregistré dans le fichier {nom_de_l’application}_analysis.txt créé dans le répertoire courant. Un dossier contenant la décompilation et le décodage de l’APK est créé aussi à cet endroit avec pour nom le nom de l’application analysée, ce dernier étant extrait du nom du fichier APK.<br /> J’ai développé ce script non pas uniquement pour repérer des failles de sécurité dans l’application mais plutôt afin d’avoir une idée grossière de comment l’application étudiée fonctionne en me basant sur l’étude que j’ai réalisé manuellement dans ce projet tout en essayant de rendre l’analyse pertinente à n’importe quelle application Android. <br /> La décompilation d’une application ne décompilant pas uniquement le code produit par les développeurs mais aussi toutes les ressources utilisées, la difficulté dans le travail effectué a été de savoir dans quel(s) dossier(s) effectuer chaque partie de l’analyse afin de ne récupérer que ce qu’il nous intéresse vraiment. Par exemple, pour l’analyse des appels aux fonctions de log Android, j’ai remarqué que de nombreuses ressources/dépendances faisaient des appels à ces fonctions et cela ne nous intéresse pas du tout de savoir quels sont ces logs. Afin d’éviter cela, j’ai extrait le nom du package écrit dans le fichier AndroidManifest afin de le transformer en chemin. C’est généralement dans ce package que se trouve tout le code nous intéressant. J’ai cependant dû modifier le comportement de mon script lorsque je me suis rendu compte qu’après décompilation de certaines applications, le package écrit dans le manifeste Android n’existe pas. J’ai donc dû mettre en place une recherche de ce package avant toute analyse afin de vérifier son existence. Si il n’existe pas, il n’y a pas d’autres choix que d’élargir la recherche à tout le code excepté quelques dossiers que l’on retrouve régulièrement comme android ou androidx.<br /> En revanche, pour la recherche de mots clés ou de requêtes SQL par exemple, il va être intéressant de réaliser l’analyse dans l’intégralité du code puisque je me suis rendu compte qu’assez souvent, on trouvait certains mots clés ou requêtes SQL dans le code smali que l’on ne retrouvait pas dans le code java, faute de décompilation ou autre. <br /> L’utilisateur se verra alors parasité avec quelques résultats ne l’intéressant pas mais je n’ai pas trouvé de meilleure solution pour être plus précis dans les recherches. Dans tous les cas, le tri manuel par l’utilisateur des résultats obtenus restera beaucoup plus rapide qu’une analyse manuelle fichier par fichier.<br /> <br /> <br /> <br /> ===Tests===<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git<br /> <br /> Ayant convenu avec les encadrants de ne mettre aucun des résultats obtenus dans ce wiki public en raison des effets que cela pourrait provoquer vis à vis de la société commercialisant l'objet étudié, le rapport de ce projet n'a été communiqué que par mail aux encadrants.</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79857 2019-12-17T18:46:19Z

<p>Mcreteur : /* Automatisation du processus */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur USB - TTL pour l'exploitation de pins de communication série<br /> * Segger JLink pour l'exploitation de pins de Serial Wire Debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * [https://ghidra-sre.org/ Ghidra]<br /> * [https://rada.re/n/ Radare2]<br /> * [https://github.com/ReFirmLabs/binwalk Binwalk]<br /> * [https://github.com/craigz28/firmwalker Firmwalker]<br /> * [https://ibotpeaches.github.io/Apktool/ Apktool]<br /> * [https://github.com/pxb1988/dex2jar dex2jar]<br /> * [https://java-decompiler.github.io/ JDGUI]<br /> * [https://www.benf.org/other/cfr/ CFR decompiler]<br /> * [https://www.zaproxy.org/ OWASP ZAP]<br /> * [https://developer.android.com/studio/command-line/adb Android Debug Bridge]<br /> * [https://github.com/nelenkov/android-backup-extractor Android backup extractor]<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> ===Exploitation des pins présent sur le circuit===<br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom. Afin de vérifier que rien n'était envoyé par l'objet sur les Rx et Tx, j'ai utilisé un oscilloscope. La différence de potentielle observée entre les pins Tx et GND était trop faible pour qu'une quelconque information ne soit envoyée via l'UART de l'objet.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> ===Ecoute de la communication entre l'application mobile étudiée et le serveur distant===<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. <br /> Malheureusement, ce fichier d'extension .des semble être un fichier encrypté. Une mesure de l'entropie du fichier sur binvis.io me l'a confirmé. 'des' étant l'acronyme pour Data Encryption Standard, une méthode ancienne de cryptage de données, j'ai cherché un moyen de décrypter le fichier par bruteforce. Je n'ai malheureusement trouvé aucun programme permettant cela.<br /> <br /> ===Analyse d'un firmware===<br /> N'ayant pas pu exploiter le fichier récupéré de l'API Terraillon, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> ===Ecoute de la communication application mobile - objet connecté===<br /> <br /> La dernière piste pour récupérer le firmware de l'objet est l'écoute de la communication bluetooth ayant lieue entre l'objet connecté et l'application mobile pour le transfert de données ou de mise à jour. Ayant commencé à explorer cette piste en tout fin de projet, j'ai du faire avec le matériel disponible, un LimeSDR qui est un radio logiciel. La recherche d'un programme compatible avec le LimeSDR permettant de capturer les communications bluetooth n'a pas été très fructueuse puisque je n'ai trouvé qu'un seul outil sous forme de projet sur github, [https://github.com/jocover/BLESDR blesdr]. Après 3 tentatives, ce programme ne m'a permis de récupérer que les paquets d'advertising.<br /> Après quelques recherches il semblerait qu'un development kit nRF52 ou 51 ou un Adafruit Bluefruit programmés avec le nRF sniffer permettraient de réaliser l'action souhaitée et de manière beaucoup plus simple.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> ===Décompilation===<br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> ===Analyse du code source===<br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ===Exploitation===<br /> En analysant le manifeste android de l'application, j'ai pu localiser la présence d'une propriété très interessante :<br /> <br /> android:allowBackup=&quot;true&quot;<br /> <br /> Cette propriété, mise à &quot;true&quot; par défaut, permet de réaliser une récupération des données de l'application via les outils Android. J'ai donc tenté de récupérer les différentes informations que stocke l'application étudiée dans le téléphone. Pour cela j'ai utilisé l'outil Android Debug Bridge, un outil android en ligne de commande qui permet de réaliser différentes opérations sur un téléphone android. Après avoir activé le mode développeur sur le smartphone utilisé, étape nécessaire pour réaliser la récupération, je l'ai connecté à mon ordinateur. La commande <br /> adb devices -l <br /> permet lister les périphériques détectés. Mon smartphone étant bien reconnu, j'ai cherché le nom du package android lié à l'application étudiée afin de ne lancer la récupération que pour cette application. Pour cela, la commande <br /> adb shell pm list packages<br /> permet de lister tous les packages présents dans le téléphone. Une fois en possession du nom de package désiré, j'ai pu lancé la récupération des données avec la commande :<br /> adb backup -f {nom_du_fichier_backup} {nom_du_package_cible}<br /> Après avoir accepté l'opération de récupération sur le smartphone en précisant ou non un mot de passe pour encrypter les données, un fichier d'extension .ab apparaît à l'emplacement spécifié. Afin de pouvoir exploiter les données contenues dans ce fichier, j'ai utilisé l'outil Android backup extractor permettant de convertir un fichier android backup en une archive compressée : <br /> java -jar abe.jar unpack {fichier_a_convertir.ab} {nom_de_l'archive.tar} {mot_de_passe}<br /> J'ai enfin pu décompresser l'archive obtenue avec la commande précédente et visualiser les données de l'application. J'ai pu y trouver le fichier utilisé par le mécanisme de SharedPreferences Android que j'avais localisé dans le code contenant entre autres mon login ou encore mon mot de passe en clair. J'ai aussi pu y trouver le fichier de base de données utilisé par l'application avec les données enregistrées. <br /> <br /> Au cours de l'analyse du code source, j'ai pu remarquer que certaines informations étaient loggées. Android Debug Bridge m'a alors été encore utile puisqu'il m'a permis de suivre les logs de l'application avec logcat via la commande : <br /> adb logcat {nom_package_cible}<br /> Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application.<br /> <br /> ==Automatisation==<br /> <br /> ===Outil développé===<br /> <br /> ===Tests===<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git<br /> <br /> Ayant convenu avec les encadrants de ne mettre aucun des résultats obtenus dans ce wiki public en raison des effets que cela pourrait provoquer vis à vis de la société commercialisant l'objet étudié, le rapport de ce projet n'a été communiqué que par mail aux encadrants.</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79856 2019-12-17T18:46:01Z

<p>Mcreteur : /* Automatisation du processus */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur USB - TTL pour l'exploitation de pins de communication série<br /> * Segger JLink pour l'exploitation de pins de Serial Wire Debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * [https://ghidra-sre.org/ Ghidra]<br /> * [https://rada.re/n/ Radare2]<br /> * [https://github.com/ReFirmLabs/binwalk Binwalk]<br /> * [https://github.com/craigz28/firmwalker Firmwalker]<br /> * [https://ibotpeaches.github.io/Apktool/ Apktool]<br /> * [https://github.com/pxb1988/dex2jar dex2jar]<br /> * [https://java-decompiler.github.io/ JDGUI]<br /> * [https://www.benf.org/other/cfr/ CFR decompiler]<br /> * [https://www.zaproxy.org/ OWASP ZAP]<br /> * [https://developer.android.com/studio/command-line/adb Android Debug Bridge]<br /> * [https://github.com/nelenkov/android-backup-extractor Android backup extractor]<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> ===Exploitation des pins présent sur le circuit===<br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom. Afin de vérifier que rien n'était envoyé par l'objet sur les Rx et Tx, j'ai utilisé un oscilloscope. La différence de potentielle observée entre les pins Tx et GND était trop faible pour qu'une quelconque information ne soit envoyée via l'UART de l'objet.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> ===Ecoute de la communication entre l'application mobile étudiée et le serveur distant===<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. <br /> Malheureusement, ce fichier d'extension .des semble être un fichier encrypté. Une mesure de l'entropie du fichier sur binvis.io me l'a confirmé. 'des' étant l'acronyme pour Data Encryption Standard, une méthode ancienne de cryptage de données, j'ai cherché un moyen de décrypter le fichier par bruteforce. Je n'ai malheureusement trouvé aucun programme permettant cela.<br /> <br /> ===Analyse d'un firmware===<br /> N'ayant pas pu exploiter le fichier récupéré de l'API Terraillon, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> ===Ecoute de la communication application mobile - objet connecté===<br /> <br /> La dernière piste pour récupérer le firmware de l'objet est l'écoute de la communication bluetooth ayant lieue entre l'objet connecté et l'application mobile pour le transfert de données ou de mise à jour. Ayant commencé à explorer cette piste en tout fin de projet, j'ai du faire avec le matériel disponible, un LimeSDR qui est un radio logiciel. La recherche d'un programme compatible avec le LimeSDR permettant de capturer les communications bluetooth n'a pas été très fructueuse puisque je n'ai trouvé qu'un seul outil sous forme de projet sur github, [https://github.com/jocover/BLESDR blesdr]. Après 3 tentatives, ce programme ne m'a permis de récupérer que les paquets d'advertising.<br /> Après quelques recherches il semblerait qu'un development kit nRF52 ou 51 ou un Adafruit Bluefruit programmés avec le nRF sniffer permettraient de réaliser l'action souhaitée et de manière beaucoup plus simple.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> ===Décompilation===<br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> ===Analyse du code source===<br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ===Exploitation===<br /> En analysant le manifeste android de l'application, j'ai pu localiser la présence d'une propriété très interessante :<br /> <br /> android:allowBackup=&quot;true&quot;<br /> <br /> Cette propriété, mise à &quot;true&quot; par défaut, permet de réaliser une récupération des données de l'application via les outils Android. J'ai donc tenté de récupérer les différentes informations que stocke l'application étudiée dans le téléphone. Pour cela j'ai utilisé l'outil Android Debug Bridge, un outil android en ligne de commande qui permet de réaliser différentes opérations sur un téléphone android. Après avoir activé le mode développeur sur le smartphone utilisé, étape nécessaire pour réaliser la récupération, je l'ai connecté à mon ordinateur. La commande <br /> adb devices -l <br /> permet lister les périphériques détectés. Mon smartphone étant bien reconnu, j'ai cherché le nom du package android lié à l'application étudiée afin de ne lancer la récupération que pour cette application. Pour cela, la commande <br /> adb shell pm list packages<br /> permet de lister tous les packages présents dans le téléphone. Une fois en possession du nom de package désiré, j'ai pu lancé la récupération des données avec la commande :<br /> adb backup -f {nom_du_fichier_backup} {nom_du_package_cible}<br /> Après avoir accepté l'opération de récupération sur le smartphone en précisant ou non un mot de passe pour encrypter les données, un fichier d'extension .ab apparaît à l'emplacement spécifié. Afin de pouvoir exploiter les données contenues dans ce fichier, j'ai utilisé l'outil Android backup extractor permettant de convertir un fichier android backup en une archive compressée : <br /> java -jar abe.jar unpack {fichier_a_convertir.ab} {nom_de_l'archive.tar} {mot_de_passe}<br /> J'ai enfin pu décompresser l'archive obtenue avec la commande précédente et visualiser les données de l'application. J'ai pu y trouver le fichier utilisé par le mécanisme de SharedPreferences Android que j'avais localisé dans le code contenant entre autres mon login ou encore mon mot de passe en clair. J'ai aussi pu y trouver le fichier de base de données utilisé par l'application avec les données enregistrées. <br /> <br /> Au cours de l'analyse du code source, j'ai pu remarquer que certaines informations étaient loggées. Android Debug Bridge m'a alors été encore utile puisqu'il m'a permis de suivre les logs de l'application avec logcat via la commande : <br /> adb logcat {nom_package_cible}<br /> Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application.<br /> <br /> ==Automatisation du processus==<br /> <br /> ===Outil développé===<br /> <br /> ===Tests===<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git<br /> <br /> Ayant convenu avec les encadrants de ne mettre aucun des résultats obtenus dans ce wiki public en raison des effets que cela pourrait provoquer vis à vis de la société commercialisant l'objet étudié, le rapport de ce projet n'a été communiqué que par mail aux encadrants.</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79855 2019-12-17T18:45:33Z

<p>Mcreteur : /* Documents Rendus */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur USB - TTL pour l'exploitation de pins de communication série<br /> * Segger JLink pour l'exploitation de pins de Serial Wire Debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * [https://ghidra-sre.org/ Ghidra]<br /> * [https://rada.re/n/ Radare2]<br /> * [https://github.com/ReFirmLabs/binwalk Binwalk]<br /> * [https://github.com/craigz28/firmwalker Firmwalker]<br /> * [https://ibotpeaches.github.io/Apktool/ Apktool]<br /> * [https://github.com/pxb1988/dex2jar dex2jar]<br /> * [https://java-decompiler.github.io/ JDGUI]<br /> * [https://www.benf.org/other/cfr/ CFR decompiler]<br /> * [https://www.zaproxy.org/ OWASP ZAP]<br /> * [https://developer.android.com/studio/command-line/adb Android Debug Bridge]<br /> * [https://github.com/nelenkov/android-backup-extractor Android backup extractor]<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> ===Exploitation des pins présent sur le circuit===<br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom. Afin de vérifier que rien n'était envoyé par l'objet sur les Rx et Tx, j'ai utilisé un oscilloscope. La différence de potentielle observée entre les pins Tx et GND était trop faible pour qu'une quelconque information ne soit envoyée via l'UART de l'objet.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> ===Ecoute de la communication entre l'application mobile étudiée et le serveur distant===<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. <br /> Malheureusement, ce fichier d'extension .des semble être un fichier encrypté. Une mesure de l'entropie du fichier sur binvis.io me l'a confirmé. 'des' étant l'acronyme pour Data Encryption Standard, une méthode ancienne de cryptage de données, j'ai cherché un moyen de décrypter le fichier par bruteforce. Je n'ai malheureusement trouvé aucun programme permettant cela.<br /> <br /> ===Analyse d'un firmware===<br /> N'ayant pas pu exploiter le fichier récupéré de l'API Terraillon, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> ===Ecoute de la communication application mobile - objet connecté===<br /> <br /> La dernière piste pour récupérer le firmware de l'objet est l'écoute de la communication bluetooth ayant lieue entre l'objet connecté et l'application mobile pour le transfert de données ou de mise à jour. Ayant commencé à explorer cette piste en tout fin de projet, j'ai du faire avec le matériel disponible, un LimeSDR qui est un radio logiciel. La recherche d'un programme compatible avec le LimeSDR permettant de capturer les communications bluetooth n'a pas été très fructueuse puisque je n'ai trouvé qu'un seul outil sous forme de projet sur github, [https://github.com/jocover/BLESDR blesdr]. Après 3 tentatives, ce programme ne m'a permis de récupérer que les paquets d'advertising.<br /> Après quelques recherches il semblerait qu'un development kit nRF52 ou 51 ou un Adafruit Bluefruit programmés avec le nRF sniffer permettraient de réaliser l'action souhaitée et de manière beaucoup plus simple.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> ===Décompilation===<br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> ===Analyse du code source===<br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ===Exploitation===<br /> En analysant le manifeste android de l'application, j'ai pu localiser la présence d'une propriété très interessante :<br /> <br /> android:allowBackup=&quot;true&quot;<br /> <br /> Cette propriété, mise à &quot;true&quot; par défaut, permet de réaliser une récupération des données de l'application via les outils Android. J'ai donc tenté de récupérer les différentes informations que stocke l'application étudiée dans le téléphone. Pour cela j'ai utilisé l'outil Android Debug Bridge, un outil android en ligne de commande qui permet de réaliser différentes opérations sur un téléphone android. Après avoir activé le mode développeur sur le smartphone utilisé, étape nécessaire pour réaliser la récupération, je l'ai connecté à mon ordinateur. La commande <br /> adb devices -l <br /> permet lister les périphériques détectés. Mon smartphone étant bien reconnu, j'ai cherché le nom du package android lié à l'application étudiée afin de ne lancer la récupération que pour cette application. Pour cela, la commande <br /> adb shell pm list packages<br /> permet de lister tous les packages présents dans le téléphone. Une fois en possession du nom de package désiré, j'ai pu lancé la récupération des données avec la commande :<br /> adb backup -f {nom_du_fichier_backup} {nom_du_package_cible}<br /> Après avoir accepté l'opération de récupération sur le smartphone en précisant ou non un mot de passe pour encrypter les données, un fichier d'extension .ab apparaît à l'emplacement spécifié. Afin de pouvoir exploiter les données contenues dans ce fichier, j'ai utilisé l'outil Android backup extractor permettant de convertir un fichier android backup en une archive compressée : <br /> java -jar abe.jar unpack {fichier_a_convertir.ab} {nom_de_l'archive.tar} {mot_de_passe}<br /> J'ai enfin pu décompresser l'archive obtenue avec la commande précédente et visualiser les données de l'application. J'ai pu y trouver le fichier utilisé par le mécanisme de SharedPreferences Android que j'avais localisé dans le code contenant entre autres mon login ou encore mon mot de passe en clair. J'ai aussi pu y trouver le fichier de base de données utilisé par l'application avec les données enregistrées. <br /> <br /> Au cours de l'analyse du code source, j'ai pu remarquer que certaines informations étaient loggées. Android Debug Bridge m'a alors été encore utile puisqu'il m'a permis de suivre les logs de l'application avec logcat via la commande : <br /> adb logcat {nom_package_cible}<br /> Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git<br /> <br /> Ayant convenu avec les encadrants de ne mettre aucun des résultats obtenus dans ce wiki public en raison des effets que cela pourrait provoquer vis à vis de la société commercialisant l'objet étudié, le rapport de ce projet n'a été communiqué que par mail aux encadrants.</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79854 2019-12-17T18:40:13Z

<p>Mcreteur : /* Ecoute de la communication application mobile - objet connecté */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur USB - TTL pour l'exploitation de pins de communication série<br /> * Segger JLink pour l'exploitation de pins de Serial Wire Debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * [https://ghidra-sre.org/ Ghidra]<br /> * [https://rada.re/n/ Radare2]<br /> * [https://github.com/ReFirmLabs/binwalk Binwalk]<br /> * [https://github.com/craigz28/firmwalker Firmwalker]<br /> * [https://ibotpeaches.github.io/Apktool/ Apktool]<br /> * [https://github.com/pxb1988/dex2jar dex2jar]<br /> * [https://java-decompiler.github.io/ JDGUI]<br /> * [https://www.benf.org/other/cfr/ CFR decompiler]<br /> * [https://www.zaproxy.org/ OWASP ZAP]<br /> * [https://developer.android.com/studio/command-line/adb Android Debug Bridge]<br /> * [https://github.com/nelenkov/android-backup-extractor Android backup extractor]<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> ===Exploitation des pins présent sur le circuit===<br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom. Afin de vérifier que rien n'était envoyé par l'objet sur les Rx et Tx, j'ai utilisé un oscilloscope. La différence de potentielle observée entre les pins Tx et GND était trop faible pour qu'une quelconque information ne soit envoyée via l'UART de l'objet.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> ===Ecoute de la communication entre l'application mobile étudiée et le serveur distant===<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. <br /> Malheureusement, ce fichier d'extension .des semble être un fichier encrypté. Une mesure de l'entropie du fichier sur binvis.io me l'a confirmé. 'des' étant l'acronyme pour Data Encryption Standard, une méthode ancienne de cryptage de données, j'ai cherché un moyen de décrypter le fichier par bruteforce. Je n'ai malheureusement trouvé aucun programme permettant cela.<br /> <br /> ===Analyse d'un firmware===<br /> N'ayant pas pu exploiter le fichier récupéré de l'API Terraillon, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> ===Ecoute de la communication application mobile - objet connecté===<br /> <br /> La dernière piste pour récupérer le firmware de l'objet est l'écoute de la communication bluetooth ayant lieue entre l'objet connecté et l'application mobile pour le transfert de données ou de mise à jour. Ayant commencé à explorer cette piste en tout fin de projet, j'ai du faire avec le matériel disponible, un LimeSDR qui est un radio logiciel. La recherche d'un programme compatible avec le LimeSDR permettant de capturer les communications bluetooth n'a pas été très fructueuse puisque je n'ai trouvé qu'un seul outil sous forme de projet sur github, [https://github.com/jocover/BLESDR blesdr]. Après 3 tentatives, ce programme ne m'a permis de récupérer que les paquets d'advertising.<br /> Après quelques recherches il semblerait qu'un development kit nRF52 ou 51 ou un Adafruit Bluefruit programmés avec le nRF sniffer permettraient de réaliser l'action souhaitée et de manière beaucoup plus simple.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> ===Décompilation===<br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> ===Analyse du code source===<br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ===Exploitation===<br /> En analysant le manifeste android de l'application, j'ai pu localiser la présence d'une propriété très interessante :<br /> <br /> android:allowBackup=&quot;true&quot;<br /> <br /> Cette propriété, mise à &quot;true&quot; par défaut, permet de réaliser une récupération des données de l'application via les outils Android. J'ai donc tenté de récupérer les différentes informations que stocke l'application étudiée dans le téléphone. Pour cela j'ai utilisé l'outil Android Debug Bridge, un outil android en ligne de commande qui permet de réaliser différentes opérations sur un téléphone android. Après avoir activé le mode développeur sur le smartphone utilisé, étape nécessaire pour réaliser la récupération, je l'ai connecté à mon ordinateur. La commande <br /> adb devices -l <br /> permet lister les périphériques détectés. Mon smartphone étant bien reconnu, j'ai cherché le nom du package android lié à l'application étudiée afin de ne lancer la récupération que pour cette application. Pour cela, la commande <br /> adb shell pm list packages<br /> permet de lister tous les packages présents dans le téléphone. Une fois en possession du nom de package désiré, j'ai pu lancé la récupération des données avec la commande :<br /> adb backup -f {nom_du_fichier_backup} {nom_du_package_cible}<br /> Après avoir accepté l'opération de récupération sur le smartphone en précisant ou non un mot de passe pour encrypter les données, un fichier d'extension .ab apparaît à l'emplacement spécifié. Afin de pouvoir exploiter les données contenues dans ce fichier, j'ai utilisé l'outil Android backup extractor permettant de convertir un fichier android backup en une archive compressée : <br /> java -jar abe.jar unpack {fichier_a_convertir.ab} {nom_de_l'archive.tar} {mot_de_passe}<br /> J'ai enfin pu décompresser l'archive obtenue avec la commande précédente et visualiser les données de l'application. J'ai pu y trouver le fichier utilisé par le mécanisme de SharedPreferences Android que j'avais localisé dans le code contenant entre autres mon login ou encore mon mot de passe en clair. J'ai aussi pu y trouver le fichier de base de données utilisé par l'application avec les données enregistrées. <br /> <br /> Au cours de l'analyse du code source, j'ai pu remarquer que certaines informations étaient loggées. Android Debug Bridge m'a alors été encore utile puisqu'il m'a permis de suivre les logs de l'application avec logcat via la commande : <br /> adb logcat {nom_package_cible}<br /> Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79853 2019-12-17T18:29:41Z

<p>Mcreteur : /* Reverse engineering sur l'application mobile associée à l'objet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur USB - TTL pour l'exploitation de pins de communication série<br /> * Segger JLink pour l'exploitation de pins de Serial Wire Debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * [https://ghidra-sre.org/ Ghidra]<br /> * [https://rada.re/n/ Radare2]<br /> * [https://github.com/ReFirmLabs/binwalk Binwalk]<br /> * [https://github.com/craigz28/firmwalker Firmwalker]<br /> * [https://ibotpeaches.github.io/Apktool/ Apktool]<br /> * [https://github.com/pxb1988/dex2jar dex2jar]<br /> * [https://java-decompiler.github.io/ JDGUI]<br /> * [https://www.benf.org/other/cfr/ CFR decompiler]<br /> * [https://www.zaproxy.org/ OWASP ZAP]<br /> * [https://developer.android.com/studio/command-line/adb Android Debug Bridge]<br /> * [https://github.com/nelenkov/android-backup-extractor Android backup extractor]<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> ===Exploitation des pins présent sur le circuit===<br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom. Afin de vérifier que rien n'était envoyé par l'objet sur les Rx et Tx, j'ai utilisé un oscilloscope. La différence de potentielle observée entre les pins Tx et GND était trop faible pour qu'une quelconque information ne soit envoyée via l'UART de l'objet.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> ===Ecoute de la communication entre l'application mobile étudiée et le serveur distant===<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. <br /> Malheureusement, ce fichier d'extension .des semble être un fichier encrypté. Une mesure de l'entropie du fichier sur binvis.io me l'a confirmé. 'des' étant l'acronyme pour Data Encryption Standard, une méthode ancienne de cryptage de données, j'ai cherché un moyen de décrypter le fichier par bruteforce. Je n'ai malheureusement trouvé aucun programme permettant cela.<br /> <br /> ===Analyse d'un firmware===<br /> N'ayant pas pu exploiter le fichier récupéré de l'API Terraillon, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> ===Ecoute de la communication application mobile - objet connecté===<br /> <br /> <br /> Des captures d'écran illustrant les résultats sont visibles sur le wiki du projet Gitlab.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> ===Décompilation===<br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> ===Analyse du code source===<br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ===Exploitation===<br /> En analysant le manifeste android de l'application, j'ai pu localiser la présence d'une propriété très interessante :<br /> <br /> android:allowBackup=&quot;true&quot;<br /> <br /> Cette propriété, mise à &quot;true&quot; par défaut, permet de réaliser une récupération des données de l'application via les outils Android. J'ai donc tenté de récupérer les différentes informations que stocke l'application étudiée dans le téléphone. Pour cela j'ai utilisé l'outil Android Debug Bridge, un outil android en ligne de commande qui permet de réaliser différentes opérations sur un téléphone android. Après avoir activé le mode développeur sur le smartphone utilisé, étape nécessaire pour réaliser la récupération, je l'ai connecté à mon ordinateur. La commande <br /> adb devices -l <br /> permet lister les périphériques détectés. Mon smartphone étant bien reconnu, j'ai cherché le nom du package android lié à l'application étudiée afin de ne lancer la récupération que pour cette application. Pour cela, la commande <br /> adb shell pm list packages<br /> permet de lister tous les packages présents dans le téléphone. Une fois en possession du nom de package désiré, j'ai pu lancé la récupération des données avec la commande :<br /> adb backup -f {nom_du_fichier_backup} {nom_du_package_cible}<br /> Après avoir accepté l'opération de récupération sur le smartphone en précisant ou non un mot de passe pour encrypter les données, un fichier d'extension .ab apparaît à l'emplacement spécifié. Afin de pouvoir exploiter les données contenues dans ce fichier, j'ai utilisé l'outil Android backup extractor permettant de convertir un fichier android backup en une archive compressée : <br /> java -jar abe.jar unpack {fichier_a_convertir.ab} {nom_de_l'archive.tar} {mot_de_passe}<br /> J'ai enfin pu décompresser l'archive obtenue avec la commande précédente et visualiser les données de l'application. J'ai pu y trouver le fichier utilisé par le mécanisme de SharedPreferences Android que j'avais localisé dans le code contenant entre autres mon login ou encore mon mot de passe en clair. J'ai aussi pu y trouver le fichier de base de données utilisé par l'application avec les données enregistrées. <br /> <br /> Au cours de l'analyse du code source, j'ai pu remarquer que certaines informations étaient loggées. Android Debug Bridge m'a alors été encore utile puisqu'il m'a permis de suivre les logs de l'application avec logcat via la commande : <br /> adb logcat {nom_package_cible}<br /> Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79852 2019-12-17T18:27:23Z

<p>Mcreteur : /* Récupération de données utilisateur et firmware d'un objet connecté */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur USB - TTL pour l'exploitation de pins de communication série<br /> * Segger JLink pour l'exploitation de pins de Serial Wire Debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * [https://ghidra-sre.org/ Ghidra]<br /> * [https://rada.re/n/ Radare2]<br /> * [https://github.com/ReFirmLabs/binwalk Binwalk]<br /> * [https://github.com/craigz28/firmwalker Firmwalker]<br /> * [https://ibotpeaches.github.io/Apktool/ Apktool]<br /> * [https://github.com/pxb1988/dex2jar dex2jar]<br /> * [https://java-decompiler.github.io/ JDGUI]<br /> * [https://www.benf.org/other/cfr/ CFR decompiler]<br /> * [https://www.zaproxy.org/ OWASP ZAP]<br /> * [https://developer.android.com/studio/command-line/adb Android Debug Bridge]<br /> * [https://github.com/nelenkov/android-backup-extractor Android backup extractor]<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> ===Exploitation des pins présent sur le circuit===<br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom. Afin de vérifier que rien n'était envoyé par l'objet sur les Rx et Tx, j'ai utilisé un oscilloscope. La différence de potentielle observée entre les pins Tx et GND était trop faible pour qu'une quelconque information ne soit envoyée via l'UART de l'objet.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> ===Ecoute de la communication entre l'application mobile étudiée et le serveur distant===<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. <br /> Malheureusement, ce fichier d'extension .des semble être un fichier encrypté. Une mesure de l'entropie du fichier sur binvis.io me l'a confirmé. 'des' étant l'acronyme pour Data Encryption Standard, une méthode ancienne de cryptage de données, j'ai cherché un moyen de décrypter le fichier par bruteforce. Je n'ai malheureusement trouvé aucun programme permettant cela.<br /> <br /> ===Analyse d'un firmware===<br /> N'ayant pas pu exploiter le fichier récupéré de l'API Terraillon, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> ===Ecoute de la communication application mobile - objet connecté===<br /> <br /> <br /> Des captures d'écran illustrant les résultats sont visibles sur le wiki du projet Gitlab.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. <br /> <br /> En analysant le manifeste android de l'application, j'ai pu localiser la présence d'une propriété très interessante :<br /> <br /> android:allowBackup=&quot;true&quot;<br /> <br /> Cette propriété, mise à &quot;true&quot; par défaut, permet de réaliser une récupération des données de l'application via les outils Android. J'ai donc tenté de récupérer les différentes informations que stocke l'application étudiée dans le téléphone. Pour cela j'ai utilisé l'outil Android Debug Bridge, un outil android en ligne de commande qui permet de réaliser différentes opérations sur un téléphone android. Après avoir activé le mode développeur sur le smartphone utilisé, étape nécessaire pour réaliser la récupération, je l'ai connecté à mon ordinateur. La commande <br /> adb devices -l <br /> permet lister les périphériques détectés. Mon smartphone étant bien reconnu, j'ai cherché le nom du package android lié à l'application étudiée afin de ne lancer la récupération que pour cette application. Pour cela, la commande <br /> adb shell pm list packages<br /> permet de lister tous les packages présents dans le téléphone. Une fois en possession du nom de package désiré, j'ai pu lancé la récupération des données avec la commande :<br /> adb backup -f {nom_du_fichier_backup} {nom_du_package_cible}<br /> Après avoir accepté l'opération de récupération sur le smartphone en précisant ou non un mot de passe pour encrypter les données, un fichier d'extension .ab apparaît à l'emplacement spécifié. Afin de pouvoir exploiter les données contenues dans ce fichier, j'ai utilisé l'outil Android backup extractor permettant de convertir un fichier android backup en une archive compressée : <br /> java -jar abe.jar unpack {fichier_a_convertir.ab} {nom_de_l'archive.tar} {mot_de_passe}<br /> J'ai enfin pu décompresser l'archive obtenue avec la commande précédente et visualiser les données de l'application. J'ai pu y trouver le fichier utilisé par le mécanisme de SharedPreferences Android que j'avais localisé dans le code contenant entre autres mon login ou encore mon mot de passe en clair. J'ai aussi pu y trouver le fichier de base de données utilisé par l'application avec les données enregistrées. <br /> <br /> Au cours de l'analyse du code source, j'ai pu remarquer que certaines informations étaient loggées. Android Debug Bridge m'a alors été encore utile puisqu'il m'a permis de suivre les logs de l'application avec logcat via la commande : <br /> adb logcat {nom_package_cible}<br /> Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79851 2019-12-17T18:11:03Z

<p>Mcreteur : /* Choix techniques : matériel et logiciel */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur USB - TTL pour l'exploitation de pins de communication série<br /> * Segger JLink pour l'exploitation de pins de Serial Wire Debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * [https://ghidra-sre.org/ Ghidra]<br /> * [https://rada.re/n/ Radare2]<br /> * [https://github.com/ReFirmLabs/binwalk Binwalk]<br /> * [https://github.com/craigz28/firmwalker Firmwalker]<br /> * [https://ibotpeaches.github.io/Apktool/ Apktool]<br /> * [https://github.com/pxb1988/dex2jar dex2jar]<br /> * [https://java-decompiler.github.io/ JDGUI]<br /> * [https://www.benf.org/other/cfr/ CFR decompiler]<br /> * [https://www.zaproxy.org/ OWASP ZAP]<br /> * [https://developer.android.com/studio/command-line/adb Android Debug Bridge]<br /> * [https://github.com/nelenkov/android-backup-extractor Android backup extractor]<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. Malheureusement, ce fichier d'extension .des semble être un fichier encrypté.<br /> <br /> Le sujet de ce projet ne portant pas en particulier sur l'objet utilisé pour les expérimentations et ne voulant pas perdre de temps, je n'ai pas poursuivi de recherche visant à trouver comment exploiter ce fichier. En revanche, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> <br /> Des captures d'écran illustrant les résultats sont visibles sur le wiki du projet Gitlab.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. <br /> <br /> En analysant le manifeste android de l'application, j'ai pu localiser la présence d'une propriété très interessante :<br /> <br /> android:allowBackup=&quot;true&quot;<br /> <br /> Cette propriété, mise à &quot;true&quot; par défaut, permet de réaliser une récupération des données de l'application via les outils Android. J'ai donc tenté de récupérer les différentes informations que stocke l'application étudiée dans le téléphone. Pour cela j'ai utilisé l'outil Android Debug Bridge, un outil android en ligne de commande qui permet de réaliser différentes opérations sur un téléphone android. Après avoir activé le mode développeur sur le smartphone utilisé, étape nécessaire pour réaliser la récupération, je l'ai connecté à mon ordinateur. La commande <br /> adb devices -l <br /> permet lister les périphériques détectés. Mon smartphone étant bien reconnu, j'ai cherché le nom du package android lié à l'application étudiée afin de ne lancer la récupération que pour cette application. Pour cela, la commande <br /> adb shell pm list packages<br /> permet de lister tous les packages présents dans le téléphone. Une fois en possession du nom de package désiré, j'ai pu lancé la récupération des données avec la commande :<br /> adb backup -f {nom_du_fichier_backup} {nom_du_package_cible}<br /> Après avoir accepté l'opération de récupération sur le smartphone en précisant ou non un mot de passe pour encrypter les données, un fichier d'extension .ab apparaît à l'emplacement spécifié. Afin de pouvoir exploiter les données contenues dans ce fichier, j'ai utilisé l'outil Android backup extractor permettant de convertir un fichier android backup en une archive compressée : <br /> java -jar abe.jar unpack {fichier_a_convertir.ab} {nom_de_l'archive.tar} {mot_de_passe}<br /> J'ai enfin pu décompresser l'archive obtenue avec la commande précédente et visualiser les données de l'application. J'ai pu y trouver le fichier utilisé par le mécanisme de SharedPreferences Android que j'avais localisé dans le code contenant entre autres mon login ou encore mon mot de passe en clair. J'ai aussi pu y trouver le fichier de base de données utilisé par l'application avec les données enregistrées. <br /> <br /> Au cours de l'analyse du code source, j'ai pu remarquer que certaines informations étaient loggées. Android Debug Bridge m'a alors été encore utile puisqu'il m'a permis de suivre les logs de l'application avec logcat via la commande : <br /> adb logcat {nom_package_cible}<br /> Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79713 2019-12-12T15:48:00Z

<p>Mcreteur : /* Reverse engineering sur l'application mobile associée à l'objet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur série -&gt; USB pour l'exploitation de pins de communication série<br /> * Debugger pour l'exploitation de pins de debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Firmwalker<br /> * Apktool<br /> * dex2jar<br /> * JDGUI<br /> * CFR decompiler<br /> * OWASP ZAP<br /> * Android Debug Bridge<br /> * Android backup extractor<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. Malheureusement, ce fichier d'extension .des semble être un fichier encrypté.<br /> <br /> Le sujet de ce projet ne portant pas en particulier sur l'objet utilisé pour les expérimentations et ne voulant pas perdre de temps, je n'ai pas poursuivi de recherche visant à trouver comment exploiter ce fichier. En revanche, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> <br /> Des captures d'écran illustrant les résultats sont visibles sur le wiki du projet Gitlab.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. <br /> <br /> En analysant le manifeste android de l'application, j'ai pu localiser la présence d'une propriété très interessante :<br /> <br /> android:allowBackup=&quot;true&quot;<br /> <br /> Cette propriété, mise à &quot;true&quot; par défaut, permet de réaliser une récupération des données de l'application via les outils Android. J'ai donc tenté de récupérer les différentes informations que stocke l'application étudiée dans le téléphone. Pour cela j'ai utilisé l'outil Android Debug Bridge, un outil android en ligne de commande qui permet de réaliser différentes opérations sur un téléphone android. Après avoir activé le mode développeur sur le smartphone utilisé, étape nécessaire pour réaliser la récupération, je l'ai connecté à mon ordinateur. La commande <br /> adb devices -l <br /> permet lister les périphériques détectés. Mon smartphone étant bien reconnu, j'ai cherché le nom du package android lié à l'application étudiée afin de ne lancer la récupération que pour cette application. Pour cela, la commande <br /> adb shell pm list packages<br /> permet de lister tous les packages présents dans le téléphone. Une fois en possession du nom de package désiré, j'ai pu lancé la récupération des données avec la commande :<br /> adb backup -f {nom_du_fichier_backup} {nom_du_package_cible}<br /> Après avoir accepté l'opération de récupération sur le smartphone en précisant ou non un mot de passe pour encrypter les données, un fichier d'extension .ab apparaît à l'emplacement spécifié. Afin de pouvoir exploiter les données contenues dans ce fichier, j'ai utilisé l'outil Android backup extractor permettant de convertir un fichier android backup en une archive compressée : <br /> java -jar abe.jar unpack {fichier_a_convertir.ab} {nom_de_l'archive.tar} {mot_de_passe}<br /> J'ai enfin pu décompresser l'archive obtenue avec la commande précédente et visualiser les données de l'application. J'ai pu y trouver le fichier utilisé par le mécanisme de SharedPreferences Android que j'avais localisé dans le code contenant entre autres mon login ou encore mon mot de passe en clair. J'ai aussi pu y trouver le fichier de base de données utilisé par l'application avec les données enregistrées. <br /> <br /> Au cours de l'analyse du code source, j'ai pu remarquer que certaines informations étaient loggées. Android Debug Bridge m'a alors été encore utile puisqu'il m'a permis de suivre les logs de l'application avec logcat via la commande : <br /> adb logcat {nom_package_cible}<br /> Malheureusement je n'ai pas pu tirer d'informations importantes des logs de l'application. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79709 2019-12-12T15:04:57Z

<p>Mcreteur : /* Choix techniques : matériel et logiciel */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur série -&gt; USB pour l'exploitation de pins de communication série<br /> * Debugger pour l'exploitation de pins de debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Firmwalker<br /> * Apktool<br /> * dex2jar<br /> * JDGUI<br /> * CFR decompiler<br /> * OWASP ZAP<br /> * Android Debug Bridge<br /> * Android backup extractor<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. Malheureusement, ce fichier d'extension .des semble être un fichier encrypté.<br /> <br /> Le sujet de ce projet ne portant pas en particulier sur l'objet utilisé pour les expérimentations et ne voulant pas perdre de temps, je n'ai pas poursuivi de recherche visant à trouver comment exploiter ce fichier. En revanche, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> <br /> Des captures d'écran illustrant les résultats sont visibles sur le wiki du projet Gitlab.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. Avec un peu de recherche, on se rend compte que ce fichier peut être accessible via un simple explorateur de fichiers sur un téléphone rooté. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79707 2019-12-12T15:04:28Z

<p>Mcreteur : /* Choix techniques : matériel et logiciel */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur série -&gt; USB pour l'exploitation de pins de communication série<br /> * Debugger pour l'exploitation de pins de debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Firmwalker<br /> * Apktool<br /> * dex2jar<br /> * JDGUI<br /> * OWASP ZAP<br /> * Android Debug Bridge<br /> * Android backup extractor<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. Malheureusement, ce fichier d'extension .des semble être un fichier encrypté.<br /> <br /> Le sujet de ce projet ne portant pas en particulier sur l'objet utilisé pour les expérimentations et ne voulant pas perdre de temps, je n'ai pas poursuivi de recherche visant à trouver comment exploiter ce fichier. En revanche, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> <br /> Des captures d'écran illustrant les résultats sont visibles sur le wiki du projet Gitlab.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. Avec un peu de recherche, on se rend compte que ce fichier peut être accessible via un simple explorateur de fichiers sur un téléphone rooté. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79415 2019-11-27T15:54:00Z

<p>Mcreteur : /* Récupération de données utilisateur et firmware d'un objet connecté */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur série -&gt; USB pour l'exploitation de pins de communication série<br /> * Debugger pour l'exploitation de pins de debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Firmwalker<br /> * Apktool<br /> * dex2jar<br /> * JDGUI<br /> * OWASP ZAP<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. Malheureusement, ce fichier d'extension .des semble être un fichier encrypté.<br /> <br /> Le sujet de ce projet ne portant pas en particulier sur l'objet utilisé pour les expérimentations et ne voulant pas perdre de temps, je n'ai pas poursuivi de recherche visant à trouver comment exploiter ce fichier. En revanche, j'ai utilisé le &quot;Damn Vulnerable Router Firmware&quot; qui est un firmware dédié à l'expérimentation afin de tester les différents logiciels existants pour l'analyse d'un firmware. <br /> <br /> Après avoir récupéré le binaire du firmware, j'ai utilisé Binwalk. Binwalk est un outil d'analyse de firmware qui permet de scanner la signature d'un binaire, d'analyser les différents fichiers y étant présents, d'en réaliser une extraction ou encore de mesurer l'entropie du binaire afin de savoir si le firmware est encrypté ou non. <br /> <br /> [[Fichier:analyse_binwalk.png]]<br /> <br /> Nous pouvons voir ici que l'analyse avec Binwalk pour le firmware étudié a détecté un système de fichier squashfs ainsi qu'une partie de données compressées nommée &quot;piggy&quot;.<br /> <br /> On peut alors procéder à l'extraction avec la commande : <br /> <br /> binwalk -e binaireàExtraire.bin<br /> <br /> L’exécution de la commande précédente fait apparaître un dossier contenant le fichier de données &quot;piggy&quot; ainsi que le système de fichier du firmware extrait : <br /> <br /> [[Fichier:firmware_extrait.png]]<br /> <br /> Le travail de rétro ingénierie peut ensuite commencer dans le but de trouver de potentielles failles de sécurité. Pour cela, il existe Firmwalker qui est un outil qui va mettre en valeur certains fichiers, scripts ou chaînes de caractères trouvés dans le système de fichier extrait du firmware qui sont susceptibles de compromettre la sécurité de l'objet dans lequel est installé le firmware : <br /> <br /> [[Fichier:firmwalker.png]]<br /> <br /> L'outil parcourt le système de fichier pour y trouver tout ce qui est relatif à :<br /> * fichiers etc/shadow et etc/passwd<br /> * répertoire etc/ssl <br /> * fichiers relatifs au protocole SSL<br /> * fichiers de configuration<br /> * scripts<br /> * fichiers d'extension .bin<br /> * mots clés comme &quot;admin&quot;, &quot;password&quot;, etc<br /> * présence de serveur web courants dans l'IoT<br /> * présence de binaires courants comme ssh, tftp, telnet, etc<br /> * URLs, adresses mail et adresses IP <br /> <br /> Le résultat est sauvegardé dans un fichier .txt. <br /> <br /> Cet outil permet un gain de temps conséquent et est semblable à ce que nous avions prévu de réaliser dans la partie automatisation pour l'analyse du code source d'applications mobiles. <br /> <br /> <br /> Des captures d'écran illustrant les résultats sont visibles sur le wiki du projet Gitlab.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. Avec un peu de recherche, on se rend compte que ce fichier peut être accessible via un simple explorateur de fichiers sur un téléphone rooté. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:Firmwalker.png&diff=79414 2019-11-27T15:37:14Z

<p>Mcreteur : </p> <hr /> <div></div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:Firmware_extrait.png&diff=79413 2019-11-27T15:20:36Z

<p>Mcreteur : </p> <hr /> <div></div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:Analyse_binwalk.png&diff=79412 2019-11-27T15:11:53Z

<p>Mcreteur : </p> <hr /> <div></div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79411 2019-11-27T09:50:45Z

<p>Mcreteur : /* Récupération de données utilisateur et firmware d'un objet connecté */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur série -&gt; USB pour l'exploitation de pins de communication série<br /> * Debugger pour l'exploitation de pins de debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Firmwalker<br /> * Apktool<br /> * dex2jar<br /> * JDGUI<br /> * OWASP ZAP<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Après avoir récupéré mon token, j'ai tenté de réaliser un appel API via Postman. Cela a fonctionné et nous pouvons donc de cette façon, récupérer les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. Malheureusement, ce fichier d'extension .des semble être un fichier encrypté.<br /> <br /> Des captures d'écran illustrant les résultats sont visibles sur le wiki du projet Gitlab.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. Avec un peu de recherche, on se rend compte que ce fichier peut être accessible via un simple explorateur de fichiers sur un téléphone rooté. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=79410 2019-11-27T09:48:13Z

<p>Mcreteur : /* Choix techniques : matériel et logiciel */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants, dont le nom et les résultats obtenus sur ce dernier ne seront pas explicités ici<br /> * Convertisseur série -&gt; USB pour l'exploitation de pins de communication série<br /> * Debugger pour l'exploitation de pins de debug<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Firmwalker<br /> * Apktool<br /> * dex2jar<br /> * JDGUI<br /> * OWASP ZAP<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Dès lors, il semblerait qu'il soit possible de réaliser à notre guise des appels API au serveur distant à la main après avoir récupéré un token sur le logiciel. De cette façon, nous pouvons récupéré les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. Malheureusement, ce fichier d'extension .des semble être un fichier encrypté.<br /> <br /> Des captures d'écran illustrant les résultats sont visibles sur le wiki du projet Gitlab.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. Avec un peu de recherche, on se rend compte que ce fichier peut être accessible via un simple explorateur de fichiers sur un téléphone rooté. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78829 2019-11-05T11:59:39Z

<p>Mcreteur : /* Récupération de données utilisateur et firmware d'un objet connecté */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Dès lors, il semblerait qu'il soit possible de réaliser à notre guise des appels API au serveur distant à la main après avoir récupéré un token sur le logiciel. De cette façon, nous pouvons récupéré les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. Malheureusement, ce fichier d'extension .des semble être un fichier encrypté.<br /> <br /> Des captures d'écran illustrant les résultats sont visibles sur le wiki du projet Gitlab.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. Avec un peu de recherche, on se rend compte que ce fichier peut être accessible via un simple explorateur de fichiers sur un téléphone rooté. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78828 2019-11-05T11:58:00Z

<p>Mcreteur : </p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> J'ai alors été confronté à une protection empêchant la lecture des données. Après quelques recherches, le seul moyen d'enlever cette protection serait d'effacer le contenu du micro-contrôleur et de le reprogrammer. Cela n'est pas envisageable puisque ceux sont les données actuellement présentes dans l'objet que je souhaite récupérer.<br /> <br /> Suite à ces deux impasses, j'ai du me tourner vers la dernière piste pour la récupération des données de l'objet, à savoir, exploiter le fait que l'objet puisse être mis à jour à partir de l'application mobile associée. <br /> <br /> Afin de mettre à jour l'objet connecté, après appairage, l'application mobile réalise des appels API sur un serveur distant afin de vérifier si l'objet est à jour ou non et récupérer la dernière version du firmware. J'ai donc décidé d'observer ces communications afin de voir si il y avait quelque chose à exploiter à ce niveau. Pour cela, j'ai utilisé le logiciel OWASP ZAP qui est un proxy présentant de nombreuses fonctionnalités de pentest. Après avoir installé ce proxy sur mon ordinateur. J'ai configuré un smartphone android pour utiliser ce dernier. Dès lors, toutes les requêtes HTTP passent par l'OWASP ZAP avant d'atteindre leur cible. Le logiciel permet alors de visualiser toutes les requêtes réalisées à partir du smartphone avec les différents paramètres envoyées ainsi que les réponses reçues. Une fois le proxy mis en place, j'ai pu visualiser les différents échanges réalisées entre l'application mobile associée à l'objet connecté à son lancement et le serveur distant. Un premier appel de login est réalisé au lancement de l'application. J'ai pu retrouver en clair sur le logiciel servant de proxy, les paramètres associées à cet appel, à savoir, mon adresse email servant de login ainsi que mon mot de passe. Les identifiants étant corrects, le serveur distant envoie en réponse un token nécessaire à tous les autres appels API. Ce token est aussi lisible sur le logiciel. Dès lors, il semblerait qu'il soit possible de réaliser à notre guise des appels API au serveur distant à la main après avoir récupéré un token sur le logiciel. De cette façon, nous pouvons récupéré les données stockées sur le serveur distant. <br /> <br /> Après ce premier appel de login, un appel de vérification de la version du firmware est réalisé. L'objet en ma possession n'étant pas à jour, il s'en est suivi un autre appel afin de récupérer la mise à jour à appliquer sur l'objet. La mise à jour a alors été téléchargé sur le smartphone. Après avoir installé un explorateur de fichiers sur ce dernier, j'ai rapidement retrouvé le fichier de mise à jour téléchargé. Malheureusement, ce fichier d'extension .des semble être un fichier encrypté.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. Avec un peu de recherche, on se rend compte que ce fichier peut être accessible via un simple explorateur de fichiers sur un téléphone rooté. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78623 2019-10-17T10:33:59Z

<p>Mcreteur : /* Récupération de données utilisateur et firmware d'un objet connecté */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> <br /> En ouvrant l'objet connecté étudié, nous nous sommes rendus compte de la présence de pins de debug RX, TX, CLK, IO, VCC, GND. Avec l'aide de Thierry Flamen, nous avons soudé des fils de connexion sur chacun de ces pins afin de pouvoir les exploiter. <br /> <br /> Dans un premier temps, j'ai utilisé un convertisseur série -&gt; USB afin d'exploiter les pins TX et RX. Je n'ai eu aucun résultat avec minicom.<br /> <br /> Dans un second temps, j'ai utilisé un JLink SEGGER debugger, dispositif permettant de debugger des micro-controleurs dont celui présent dans l'objet étudié. Le constructeur du micro-controleur en question met à disposition un outil en ligne de commande permettant entre autres de programmer la puce ou de lire son contenu par l'intermédiaire du JLink. J'ai alors connecté ce dernier à l'objet avec les pins de Serial Wire Debug CLK et IO présents sur le circuit puis tenté de récupérer le firmware : <br /> <br /> [[Fichier:dump_nrfjprog.png]]<br /> <br /> Malheureusement, cela n'a pas abouti puisque le mécanisme de &quot;Read Out Protection&quot; est activé sur la puce, empêchant la lecture des données.<br /> <br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. Avec un peu de recherche, on se rend compte que ce fichier peut être accessible via un simple explorateur de fichiers sur un téléphone rooté. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:Dump_nrfjprog.png&diff=78622 2019-10-17T10:32:54Z

<p>Mcreteur : </p> <hr /> <div></div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78621 2019-10-17T09:38:25Z

<p>Mcreteur : </p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur et firmware d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. Avec un peu de recherche, on se rend compte que ce fichier peut être accessible via un simple explorateur de fichiers sur un téléphone rooté. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78475 2019-10-08T14:42:49Z

<p>Mcreteur : /* Reverse engineering sur l'application mobile associée à l'objet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> J'ai aussi pu me rendre compte que lorsque l'on quitte l'application en y étant connecté, on l'est toujours en relançant l'application. Le login et le mot de passe doivent donc être stockés quelque part. L'analyse du code m'a permis de découvrir que ces données sensibles sont bien stockées sur le téléphone grâce au système de préférences d'application Android. Les données sont stockées en clair au format clé-valeur dans un fichier qui n'est supposé être accessible que par l'application. Avec un peu de recherche, on se rend compte que ce fichier peut être accessible via un simple explorateur de fichiers sur un téléphone rooté. <br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78466 2019-10-07T11:30:49Z

<p>Mcreteur : /* Reverse engineering sur l'application mobile associée à l'objet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur différentes périodes selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet. Elle joue aussi un rôle de cache.<br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78465 2019-10-07T11:26:12Z

<p>Mcreteur : /* Reverse engineering sur l'application mobile associée à l'objet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées dans la base de données si présentes sinon, sur le serveur distant par appel API. Elles peuvent être récupérées sur les trente derniers jours ou plus selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet.<br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78464 2019-10-07T10:58:39Z

<p>Mcreteur : </p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> <br /> [[Fichier:decompilation_ghidra.png|1100px|center]]<br /> <br /> <br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées sur le serveur distant par appel API. Elles peuvent être récupérées sur les trente derniers jours ou plus selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet.<br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:Decompilation_ghidra.png&diff=78463 2019-10-07T10:56:32Z

<p>Mcreteur : </p> <hr /> <div></div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78462 2019-10-07T10:43:03Z

<p>Mcreteur : /* Documents Rendus */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> [capture d'écran à venir]<br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées sur le serveur distant par appel API. Elles peuvent être récupérées sur les trente derniers jours ou plus selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet.<br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=<br /> <br /> https://archives.plil.fr/mcreteur/Plateforme_cyber.git</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78461 2019-10-07T09:30:43Z

<p>Mcreteur : /* Reverse engineering sur l'application mobile associée à l'objet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> [capture d'écran à venir]<br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les différentes mesures pouvant être prises avec l'objet associé mais aussi avec deux autres, l'application étant commune à trois différents proposés par le constructeur. <br /> <br /> Après avoir découvert cela, j'ai creusé un peu plus afin de savoir comment était synchronisé l'ensemble des données entre l'objet, la base de données sur le téléphone ainsi que l'API. <br /> <br /> A son inscription, l'utilisateur fournit des données sur lui même l'identifiant et aidant à analyser les données récupérées par l'objet. Ces données utilisateur sont envoyées directement sur le serveur distant grâce à un certain endpoint de l'API. L'utilisateur peut alors ensuite se connecter sur l'application avec le login et le mot de passe entrés lors de son inscription. La vérification de son identité est faite par un appel API qui, si l'utilisateur est reconnu par le serveur, fournit un token qui permettra d'identifier l'utilisateur pour les appels API concernant les actions sur les données récupérées par l'objet. <br /> <br /> Une fois connecté, l'utilisateur peut appairer son objet à l'application via bluetooth puis synchroniser les données mesurées par l'objet. Toutes les données présentes sur l'objet sont alors récupérées sur l'application via le bluetooth et celles qui ne sont pas présentes en base de données (la vérification est faite en comparant la date des mesures) sont stockées en base de données sur le téléphone avec un certain champ indiquant que ces données n'ont pas encore été téléchargé sur l'API. Si le téléphone mobile est connecté à internet, toutes les données de la base dont le champ en question est dans l'état &quot;non téléchargé&quot; sont envoyées sur le serveur distant à travers l'API grâce au token d'identification de l'utilisateur récupéré à sa connexion. L'état des données uploadées est alors modifié pour ne pas qu'elles soient envoyées une deuxième fois sur le serveur distant.<br /> <br /> Lorsque l'utilisateur consulte la page d'analyse des données sur son application, les données à analyser sont récupérées sur le serveur distant par appel API. Elles peuvent être récupérées sur les trente derniers jours ou plus selon la page consultée sur l'application. Lorsque les données sont récupérées pour les trente derniers jours, les données de la base sur le téléphone sont effacées et remplacées par les données récupérées grâce à l'API. La base de données ne sert donc qu'à stocker temporairement les données afin de pouvoir répondre aux demandes de l'utilisateur dans le cas ou son téléphone n'est pas connecté à internet.<br /> <br /> En dehors de cet aspect stockage de données, j'ai pu voir dans le code qu'il y avait une fonctionnalité de mise à jour du firmware de l'objet connecté via l'application avec notamment de nombreuses mentions à la norme de transmission OTA, &quot;over the air&quot;. Cela constitue une piste pour la partie récupération de firmware de l'objet connecté.<br /> <br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78460 2019-10-07T09:00:58Z

<p>Mcreteur : /* Reverse engineering sur l'application mobile associée à l'objet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> [capture d'écran à venir]<br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser.<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les données suivantes :<br /> <br /> <br /> A COMPLETER<br /> <br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78459 2019-10-07T08:59:55Z

<p>Mcreteur : /* Reverse engineering sur l'application mobile associée à l'objet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> [capture d'écran à venir]<br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié qui est proposé avec une application mobile associée. Cette application permet d'analyser les données récupérées par l'objet après synchronisation. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh application.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser :<br /> <br /> [screenshot]<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API du constructeur ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer les données mesurées par le capteur de différentes façons ou encore de télécharger des mises à jour de firmware. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les données suivantes :<br /> <br /> <br /> A COMPLETER<br /> <br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78303 2019-10-02T21:18:56Z

<p>Mcreteur : /* Reverse engineering sur l'application mobile associée à l'objet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> [capture d'écran à venir]<br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> <br /> Les objets connectés ne pouvant pas embarquer une grande quantité de mémoire du fait de leur petite taille, les données mesurées sont la plupart du temps envoyés et stockés sur un serveur distant. Généralement, il est alors proposé une application mobile associée à l'objet permettant de synchroniser les nouvelles données mesurées et les visualiser. <br /> <br /> C'est le cas pour l'objet connecté étudié, le Teraillon Dot qui est proposé avec l'application mobile associée Wellness Coach - Sleep. Cette application permet d'analyser le sommeil de l'utilisateur après une nuit ainsi que d'avoir des détails sur les différents cycles de sommeil à partir des données mesurées par le Teraillon Dot. Pour cela, l'application doit interagir avec l'objet mais aussi le serveur distant sur lequel vont être stockées les données. Le code de l'application peut donc potentiellement contenir des informations pouvant compromettre la solution. <br /> <br /> Après avoir téléchargé le fichier APK de l'application, j'ai utilisé différents outils pour décompiler le code afin de pouvoir l'analyser.<br /> <br /> Dans un premier temps, j'ai utilisé l'outil dex2jar afin de convertir le fichier APK en un JAR : <br /> <br /> d2j-dex2jar.sh WellnessCoachSleep_v1.3.1.apk<br /> <br /> J'ai ensuite utilisé JD-GUI pour décompiler le JAR et visualiser le code source. Il m'a fallu ajouter des droits d’exécution et de lecture sur le JAR afin d'éviter une erreur peu explicite lors de l'import du JAR sur l'outil. Le code récupéré n'étant pas offusqué, j'ai pu l'analyser :<br /> <br /> [screenshot]<br /> <br /> Je suis assez vite tombé sur un fichier de constantes contenant l'adresse de l'API Teraillon ainsi que ses différents endpoints utilisées afin d'agir sur les données utilisateurs. Cette API permet par exemple de récupérer les informations de profil utilisateur, de les éditer, de récupérer des données de sommeil au jour ou à la semaine, ou encore d'uploader des données de sommeil. <br /> <br /> L'application utilise une base de données fichier SQLite stockée sur le téléphone de l'utilisateur composée d'une table regroupant les données suivantes :<br /> <br /> &lt;p align=&quot;center&quot;&gt;<br /> {| class=&quot;wikitable&quot;<br /> |-<br /> ! Champ !! Type<br /> |-<br /> | id<br /> | integer NOT NULL<br /> |-<br /> | email<br /> | varchar(50) NOT NULL<br /> |-<br /> | date<br /> | varchar(6) NOT NULL<br /> |-<br /> | deviceName<br /> | varchar(6) NOT NULL<br /> |-<br /> | startTime<br /> | int<br /> |-<br /> | timeZone <br /> | int<br /> |-<br /> | score <br /> | int<br /> |-<br /> | aWakeDuration <br /> | int<br /> |-<br /> | lightSleepDuration <br /> | int<br /> |-<br /> | midSleepDuration <br /> | int<br /> |-<br /> | deepSleepDuration <br /> | int<br /> |-<br /> | badTime <br /> | int<br /> |-<br /> | totalSleepTime <br /> | int<br /> |-<br /> | wakeUpTime <br /> | int<br /> |-<br /> | sleepCycle <br /> | text<br /> |-<br /> | bodyMovement <br /> | text<br /> |-<br /> | heartRate<br /> | text<br /> |-<br /> | respiratoryRate <br /> | text<br /> |-<br /> | SleepStatus <br /> | text<br /> |-<br /> | SleepStatusValue <br /> | text<br /> |-<br /> | EnvironmentTime <br /> | int<br /> |-<br /> | Temperature <br /> | text<br /> |-<br /> | Sound<br /> | text<br /> |-<br /> | Brightness <br /> | text<br /> |-<br /> | Humidity<br /> | text<br /> |-<br /> | status <br /> | int <br /> |-<br /> | Amendment<br /> | int<br /> |-<br /> | MdHeartHignDecreaseScale <br /> | int<br /> |-<br /> | MdHeartLowDecreaseScale <br /> | int <br /> |-<br /> | MdBreathHignDecreaseScale <br /> | int<br /> |-<br /> | MdBreathLowDecreaseScale<br /> | int<br /> |-<br /> | MdHeartStopDecreaseScale <br /> | int<br /> |-<br /> | MdHeartStopDecreaseScale <br /> | int<br /> |-<br /> | MdBreathStopDecreaseScale <br /> | int<br /> |-<br /> | MdSleepTimeDecreaseScaleLong <br /> | int<br /> |-<br /> | MdSleepTimeDecreaseScaleShort <br /> | int<br /> |-<br /> | MdLeaveBedDecreaseScale <br /> | int<br /> |-<br /> | MdWakeCntDecreaseScale <br /> | int<br /> |-<br /> | MdBodyMoveDecreaseScale <br /> | int<br /> |-<br /> | MdPercDeepDecreaseScale <br /> | int<br /> |-<br /> | MdFallAsleepTimeDecreaseScale <br /> | int<br /> |-<br /> | MdStartTimeDecreaseScale <br /> | int<br /> |-<br /> | MdPercEffectiveSleepDecreaseScale <br /> | int<br /> |-<br /> | BeginSleepLow <br /> | int<br /> |-<br /> | SleepaceEfficientLow <br /> | int<br /> |-<br /> | BodyMoveLow <br /> | int<br /> |-<br /> | MdWakeAllTimes <br /> | int<br /> |-<br /> | MdBreathStopCnt <br /> | int<br /> |-<br /> | MdHeartRateLowAllTime <br /> | int<br /> |-<br /> | MdHeartRateHighAllTime <br /> | int<br /> |-<br /> | MdLeaveBedCnt <br /> | int<br /> |-<br /> | MdBreathRateHighAllTime <br /> | int<br /> |-<br /> | MdBreathRateLowAllTime <br /> | int<br /> |-<br /> | MdHeartStopCnt <br /> | int<br /> |}<br /> &lt;/p&gt;<br /> <br /> A COMPLETER<br /> <br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78153 2019-09-25T12:56:21Z

<p>Mcreteur : /* Récupération du code d'une carte Arduino Uno */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> <br /> Afin de pouvoir me familiariser avec le sujet, les différents logiciels disponibles et en attendant d'avoir l'objet sur lequel travailler, j'ai utilisé une carte Arduino Uno. Après y avoir téléversé un des programmes proposés en exemple sur l'IDE Arduino qui allume puis éteint la LED chaque seconde, j'ai tenté de le récupérer via le port série.<br /> Pour cela j'ai utilisé l'utilitaire avrdude qui permet de réaliser des actions sur la mémoire d'un microcontroleur AVR comme présent sur l'arduino.<br /> <br /> J'ai alors pu extraire de la mémoire flash de l’Arduino un fichier Intel Hex avec la commande suivante :<br /> <br /> avrdude -c arduino -P /dev/ttyACM0 -p m328p -b 115200 -U flash:r:blink.hex:i'''<br /> <br /> Une fois en possession de ce fichier, j'ai utilisé l'outil Ghidra, outil de reverse engineering développé par la NSA, afin de pouvoir analyser le contenu du fichier dans une forme plus compréhensible :<br /> <br /> [capture d'écran à venir]<br /> <br /> L’outil nous permet alors, de visualiser le contenu du fichier sous forme de code assembleur mais aussi sa transposition en code C. <br /> <br /> Sur la partie gauche, l’outil nous présente toutes les fonctions qu’il a pu reconstruire à partir du fichier. Il est cependant impossible de retrouver les noms de fonctions ou variables personnalisées utilisées dans le code qui a été téléversé sur l’Arduino. Les fonctions sont alors nommées FUN_code_xxxxxx. <br /> Le code C obtenu est très bas niveau avec de la manipulation d’adresses mémoire, de registres etc. Sachant ici à quoi le code d’origine ressemble, on retrouve très vite que le void loop() du programme d’origine correspond ici au do { … } while (true) de la fonction FUN_code_000160 que l’on peut voir sur la capture d’écran ci-dessus. La fonction FUN_code_000070 correspond à la fonction digitalWrite() du programme d’origine et la fonction FUN_code_0000de correspond à la fonction delay. <br /> <br /> Etant donné que Ghidra n’est pas capable de retrouver les librairies C utilisées à partir du fichier Intel Hex donné (contrairement à lorsqu’on lui donne un fichier ELF), il devient très vite compliqué de s’y retrouver lorsque le code d’origine utilise de nombreuses fonctions importées. <br /> <br /> J’ai aussi pu tester le framework Radare2 qui a la même finalité que Ghidra. Il s’avère plus compliqué à prendre en main et moins ergonomique. Lors de l’analyse du fichier obtenu précédemment, Radare2 donne en résultat qu’une unique fonction en langage assembleur et ne permet pas de la transposer en code C. L’utilisation de Ghidra sera donc très certainement préférée pour ce projet.<br /> <br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=78143 2019-09-24T11:59:11Z

<p>Mcreteur : </p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno==<br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=77996 2019-09-17T14:18:22Z

<p>Mcreteur : /* Réalisation du Projet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno et analyse==<br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=77995 2019-09-17T14:17:10Z

<p>Mcreteur : /* Calendrier prévisionnel */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> <br /> <br /> [[Fichier:planningPFE20.png|1300px|center]]<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno et analyse==<br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:PlanningPFE20.png&diff=77994 2019-09-17T14:14:20Z

<p>Mcreteur : </p> <hr /> <div></div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=77974 2019-09-17T12:07:05Z

<p>Mcreteur : /* Calendrier prévisionnel */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> A ajouter<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno et analyse==<br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=77973 2019-09-17T12:06:33Z

<p>Mcreteur : </p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno et analyse==<br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=77972 2019-09-17T12:05:31Z

<p>Mcreteur : /* Réalisation du Projet */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> =Etat de l'art=<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Récupération du code d'une carte Arduino Uno et analyse==<br /> ==Récupération de données utilisateur d'un objet connecté==<br /> ==Reverse engineering sur le firmware de l'objet connecté==<br /> ==Reverse engineering sur l'application mobile associée à l'objet==<br /> ==Automatisation du processus==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=77971 2019-09-17T11:59:07Z

<p>Mcreteur : </p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> <br /> Pour la partie matérielle, ce projet nécessite : <br /> <br /> * Un objet connecté à exploiter à définir avec les encadrants<br /> * Du matériel permettant de connecter un ordinateur à l'objet via USB, JTAG, UART, JPIO, I2C ou SPI à voir selon le matériel déjà disponible<br /> <br /> Pour la partie logicielle, de nombreux outils pourraient être utiles à ce projet et seront à investiguer : <br /> <br /> * Ghidra<br /> * IDA<br /> * Radare2<br /> * Binwalk<br /> * Apktool<br /> * dex2jar<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> =Etat de l'art=<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Semaine 1==<br /> ==Semaine 2==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=77970 2019-09-17T10:41:46Z

<p>Mcreteur : /* Liste des tâches à effectuer */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> ==Liste des tâches à effectuer==<br /> <br /> Ce projet se découpe en 4 tâches principales : <br /> <br /> * Récupération des données utilisateur de l'objet<br /> * Récupération du firmware de l'objet et analyse dans le but de trouver des failles de sécurité<br /> * Analyse du code source de l'application mobile associée à l'objet dans le but de trouver des failles de sécurité<br /> * Automatisation d'une partie des trois premières tâches<br /> <br /> ==Calendrier prévisionnel==<br /> <br /> =Etat de l'art=<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Semaine 1==<br /> ==Semaine 2==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=77969 2019-09-17T10:31:14Z

<p>Mcreteur : /* Présentation générale */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Les objets connectés commencent à se démocratiser dans les habitations (thermostats connectés, caméras connectés, serrures connectées, ...) et dans l'industrie (remontée de données, supervision, ...). Le marché de l'IOT (Internet Of Things) est très concurrentiel et les produits doivent être mis sur le marché rapidement à bas coût. Les problématiques de sécurités sont donc très souvent délaissées. De plus, les faibles performances et les tailles de mémoires limitées empêchent d’implémenter les méthodes classiques du monde Internet (anti-virus, pare-feux, mise à jour, certificats ,...).<br /> <br /> Ce projet propose de concevoir et réaliser les briques de base d'une plateforme d'évaluation de la sécurité d'objets connectés :<br /> <br /> * Une partie logicielle permettant la récupération de code embarqué, la décompilation, la compilation, ...<br /> * Une partie matérielle permettant d'accéder aux données d'un objet (récupération du firmware) et l'injection de signaux ;<br /> * Une éventuelle base de données permettant de sauvegarder les résultats et les failles trouvées.<br /> <br /> <br /> ==Objectifs==<br /> <br /> Dans un premier temps, l'objectif sera d'être capable de récupérer les données utilisateur d'un objet connecté puis son firmware dans le but d'y trouver de potentielles failles de sécurité. Le code source de l'application mobile associée à l'objet pouvant lui aussi être source de failles de sécurité, sera de même à analyser.<br /> <br /> Dans un second temps, le but ultime de ce projet serait d'automatiser une partie de ce processus et de le rendre utilisable pour un grand nombre d'objets connectés divers et variés.<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> ==Liste des tâches à effectuer==<br /> ==Calendrier prévisionnel==<br /> <br /> =Etat de l'art=<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Semaine 1==<br /> ==Semaine 2==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA5_2019/2020_P20&diff=77968 2019-09-16T09:24:54Z

<p>Mcreteur : Page créée avec « __TOC__ &lt;br style=&quot;clear: both;&quot;/&gt; =Présentation générale= ==Description== ==Objectifs== =Préparation du projet= ==Cahier des charges== ==Choix techniques : matér... »</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> ==Objectifs==<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> ==Choix techniques : matériel et logiciel==<br /> ==Liste des tâches à effectuer==<br /> ==Calendrier prévisionnel==<br /> <br /> =Etat de l'art=<br /> <br /> =Réalisation du Projet=<br /> <br /> ==Semaine 1==<br /> ==Semaine 2==<br /> <br /> =Documents Rendus=</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P2&diff=64839 2018-12-20T12:17:55Z

<p>Mcreteur : /* Documents Rendus */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> ='''NumWorks et robot'''=<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Le projet consiste à commander un robot classique par une calculatrice NumWorks avec un programme Python. Après avoir conçu un robot classique à base d'Arduino, moteurs, sonar ultrason et suiveurs de lignes, il faudra modifier le logiciel d'une calculatrice NumWorks afin que cette dernière soit capable de communiquer avec le robot. Une fois la communication établie, nous développerons une API afin de contrôler le robot. Finalement, nous écrirons un programme python utilisant l'API pour transformer le robot en un robot suiveur de ligne avec arrêt en cas d'obstacle et redémarrage automatique lors de la disparition de l'obstacle.<br /> <br /> <br /> L’intérêt de ce projet serait de permettre l'initiation à la robotique aux lycéens à moindre coût. Les lycéens ayant tous à acheter eux-mêmes une calculatrice, en leur imposant la Numworks, il n'y aurait que les robots à acheter pour un peu moins de 50 euros. Ils pourraient alors découvrir le monde de la programmation robotique en utilisant l'API développée sur la Numworks qui permet la programmation Python.<br /> <br /> ==Objectifs==<br /> <br /> * Conception d'un robot classique<br /> * Modification du logiciel d'une calculatrice NumWorks pour établir une communication entre le robot et la calculatrice<br /> * Développer une API permettant le contrôle du robot<br /> * Développer un programme Python transformant le robot en un robot suiveur de ligne avec arrêt en cas d'obstacle et redémarrage automatique lors de la disparition de l'obstacle<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> <br /> ''' Robot :'''<br /> * Concevoir un robot mobile à partir d'un Arduino Uno, capable de détecter des obstacles grâce à un capteur de distance à ultrason et de suivre une ligne grâce à des capteurs suiveurs de ligne<br /> <br /> ''' Communication :'''<br /> * Établir une communication entre le robot et la calculatrice NumWorks en tentant de passer le micro-contrôleur en hôte USB et en utilisant le FTDI de l'Arduino<br /> <br /> ''' API :'''<br /> * Développer une API permettant de contrôler le robot :<br /> ** fonctions pour contrôler les moteurs<br /> ** fonctions pour lire la distance du sonar<br /> ** fonctions pour lire l'information des suiveurs de ligne<br /> <br /> ''' Programme Python :'''<br /> * Développer un programme Python se servant de l'API pour transformer le robot en un suiveur de ligne. Il doit permettre au robot de s'arrêter en cas d'obstacle et redémarrer lorsque l'obstacle disparaît<br /> <br /> ==Choix techniques : matériel et logiciel==<br /> <br /> ''' - Robot : '''<br /> * Chassis : [https://www.gotronic.fr/art-chassis-magic-dg007-17268.htm Kit à assembler Magician chassis dg007]<br /> * [https://store.arduino.cc/arduino-uno-rev3 Arduino Uno]<br /> * Capteur de distance : [https://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm HC SR04]<br /> * Capteur optique suiveur de ligne : [https://fr.rs-online.com/web/p/capteurs-optiques-reflechissants/7613984/ QRE1113GR] x3<br /> * Contrôleur de moteur : [https://www.mouser.fr/ProductDetail/?qs=rsevcuukUAy2UalRuv4E%2fQ%3d%3d Toshiba TB6612FNG,C,8,EL] <br /> <br /> ''' - [https://www.numworks.com/fr/ Calculatrice NumWorks]'''<br /> <br /> ''' - Shield pour Arduino :''' Réalisation sur Eagle<br /> <br /> ''' - Communication :''' Modification de [https://github.com/numworks/epsilon l'OS Numworks] en C++ / C<br /> <br /> ''' - API et programme suivi de ligne : ''' Développés en Python<br /> <br /> <br /> &lt;gallery mode=&quot;nolines&quot; widths=300px heights=200px&gt;<br /> File:DG007.jpg| Magician chassis DG007<br /> <br /> File:TB6612FNGC8EL.jpg|Contrôleur de moteur TB6612FNG,C,8,EL<br /> <br /> File:Hc-sr04-ultrasonic-range-finder-2.png|Capteur de distance HC SR04<br /> <br /> File:QRE1113GR.jpg| Capteur optique QRE1113GR <br /> <br /> &lt;/gallery&gt;<br /> <br /> &lt;gallery mode=&quot;nolines&quot; widths=300px heights=200px center&gt;<br /> File:Arduino-uno-rev3-smd.jpg|Arduino Uno<br /> <br /> File:Numworks.jpg|Calculatrice Numworks<br /> &lt;/gallery&gt;<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> * Assembler le robot<br /> * Réaliser un shield pour l'Arduino<br /> * Modifier le logiciel de la calculatrice NumWorks pour établir la communication<br /> * Développer l'API<br /> * Développer le programme Python<br /> <br /> <br /> =Réalisation du Projet=<br /> ==Feuille d'heures==<br /> <br /> {| class=&quot;wikitable&quot;<br /> !Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Heures S12 !! Heures S13 !!Total<br /> |-<br /> | Analyse du projet <br /> | 5H<br /> | <br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> | 5H+<br /> |-<br /> | Recherches / documentation<br /> | <br /> | 12H<br /> | 6H<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> | 18H+<br /> |-<br /> | Conception du robot<br /> | <br /> | <br /> |<br /> |<br /> |<br /> |<br /> | 30min<br /> |<br /> |<br /> |<br /> | 1H<br /> |<br /> |<br /> | 3H<br /> | 4H30<br /> |-<br /> | Réalisation du shield <br /> | <br /> | <br /> |<br /> |<br /> |<br /> |<br /> | 16H30<br /> | 2H30<br /> | 7H<br /> | 2H<br /> | 2H<br /> | 8H<br /> | 4H<br /> |<br /> | 42H<br /> |-<br /> | Établissement de la communication<br /> | <br /> | <br /> | 3H<br /> | 6H<br /> | 6H<br /> | 9H<br /> | <br /> | 3H<br /> | 8H<br /> |<br /> | <br /> |<br /> | 3H30<br /> | 1H30<br /> | 40H<br /> |-<br /> | Développement de l'API<br /> | <br /> | <br /> |<br /> |<br /> |<br /> |<br /> |<br /> | <br /> |<br /> | 11H<br /> | 15H<br /> | 10H<br /> | 4H<br /> | 3H<br /> | 43H<br /> |-<br /> | Développement du programme Python<br /> | <br /> | <br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> | 2H<br /> | 24H<br /> | 26H<br /> |}<br /> <br /> ==Prologue==<br /> ==Semaine 1==<br /> <br /> *''' Acquisition du matériel : '''<br /> <br /> Le matériel nécessaire à la conception du robot était déjà disponible. Récupération d'un kit à assembler pour construire un robot à deux roues, d'un Arduino Uno, d'un sonar ultrason, d'un contrôleur de moteur ainsi que de trois suiveurs de ligne. <br /> <br /> *''' Installation du SDK NumWorks : '''<br /> <br /> Ayant à modifier le logiciel de la calculatrice NumWorks afin de transformer la calculatrice en un périphérique USB hôte pour pouvoir contrôler le robot, j'ai installé le SDK fourni par l'éditeur qui offre un simulateur.<br /> <br /> On récupère dans un premier temps le code :<br /> <br /> git clone https://github.com/numworks/epsilon.git<br /> <br /> <br /> Avant de pouvoir lancer le simulateur, il faut installer de nombreuses dépendances :<br /> <br /> apt-get install bison build-essential dfu-util flex gcc-arm-none-eabi git libfltk1.3-dev libfreetype6-dev libpng12-dev<br /> <br /> Une fois les dépendances installées, on peut compiler :<br /> <br /> make PLATFORM=simulator clean<br /> make PLATFORM=simulator<br /> <br /> Puis on lance le simulateur par la commande :<br /> <br /> ./epsilon.elf<br /> <br /> [[Fichier:SimulateurNumWorks.png|center|vignette|300px|Simulateur NumWorks]]<br /> <br /> <br /> *''' Recherches / Documentation ''' :<br /> <br /> L'USB On-The-Go (OTG) est une spécification qui permet à un périphérique USB de se comporter comme un hôte ou un esclave selon la situation. Par exemple, cela permet à une tablette (qui est de base un périphérique esclave) de pouvoir communiquer avec un autre périphérique USB tel qu'une souris, un clavier en agissant comme périphérique hôte puis d'être esclave lorsque connecté à un ordinateur. Cette spécification OTG introduit un 5ème pin, le pin &quot;ID&quot;. Lorsque ce dernier est connecté à la masse, le périphérique est défini comme hôte par défaut. Si le pin n'est pas connecté, le périphérique est esclave par défaut.<br /> <br /> Le port USB de la calculatrice NumWorks n'étant censé être utilisé que pour recharger la calculatrice ou la mettre à jour, la calculatrice est un périphérique esclave. Cela est confirmé par le Schematics de la calculatrice sur lequel on voit que le pin ID de l'USB n'est pas connecté :<br /> <br /> <br /> [[Fichier:SchematicsUSB.png|center|vignette|700px| Schematics du port USB de la NumWorks]]<br /> <br /> <br /> Le micro-contrôleur STM32F412VGT6 utilisé est cependant compatible avec l'OTG d'après sa Datasheet et l'acronyme &quot;OTG&quot; apparaît à de nombreuses reprises dans le code du logiciel de la calculatrice NumWorks. Il faudra donc creuser dans ce sens pour faire de la calculatrice un hôte USB.<br /> <br /> ==Semaine 2==<br /> <br /> <br /> *''' Recherches / Documentation ''' :<br /> Recherche et lecture de documentation pouvant aider à l'établissement de la communication entre la calculatrice et le robot. On retiendra trois documents qui pourront nous aider:<br /> <br /> - [https://www.st.com/resource/en/user_manual/dm00105256.pdf Manuel d'utilisation de la librairie USB host du logiciel de développement des STM32 STM32Cube]<br /> <br /> - [https://www.st.com/resource/en/user_manual/cd00289278.pdf Manuel d'utilisation de la librairie USB On-The-Go des STM32F]<br /> <br /> - [https://www.st.com/resource/en/reference_manual/dm00180369.pdf Manuel de référence du STM32F412]<br /> <br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> Début de modification du logiciel de la calculatrice NumWorks afin d'en faire un hôte USB pour pouvoir contrôler le robot. Pour cela, le [https://www.st.com/resource/en/reference_manual/dm00180369.pdf manuel de référence du STM32F412] est une aide précieuse.<br /> <br /> Dans un premier temps, nous modifions les différents registres d'initialisation de l'USB OTG du micro-contrôleur. Cela se passe dans la fonction '''initOTG()''' du fichier '''/ion/src/device/usb.cpp'''.<br /> |<br /> |<br /> |<br /> Dans ce fichier, on s'aperçoit d'une ligne qui force l'USB à agir en tant qu'esclave :<br /> OTG.GUSBCFG()-&gt;setFDMOD(true);<br /> <br /> Pour forcer la calculatrice à apparaître comme un hôte USB, on modifie la ligne de la façon suivante :<br /> OTG.GUSBCFG()-&gt;setFHMOD(true);<br /> <br /> Le [https://www.st.com/resource/en/reference_manual/dm00180369.pdf manuel de référence du STM32F412] nous propose une démarche pour initialiser l'USB de la calculatrice en tant qu'hôte, nous la suivons donc. <br /> <br /> <br /> Il faut dans un premier temps initialiser le cœur. On active différents masques et interruptions à travers différents registres ainsi que les modes :<br /> <br /> - '''Host negotiation protocol (HNP)''' qui permet au cœur de changer dynamiquement son rôle de périphérique A-Host en A-esclave et inversement ou B-host en B-esclave.<br /> <br /> - '''Session request protocol (SRP)''' qui permet, lorsque la calculatrice est un hôte USB, d'économiser de l'énergie en éteignant le Vbus power si la session USB est suspendue <br /> <br /> <br /> On procède ensuite à l'initialisation du mode hôte. On active le port de contrôle et le registre de statut, on sélectionne le mode de vitesse supportée. Si un périphérique USB est détecté, on active le processus de reset sur le périphérique, on se règle sur sa vitesse et on configure la taille des queues FIFO pour l'échange des données.<br /> <br /> <br /> Il faudra ensuite procéder à l'initialisation d'un canal de communication pour que la calculatrice puisse échanger avec le robot.<br /> <br /> ==Semaine 3==<br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> <br /> Initialisation des channels : afin de pouvoir communiquer avec les périphériques connectés à l'hôte, en l’occurrence ici, l'Arduino à la calculatrice, il faut initialiser des canaux de communication. Pour cela, on active les canaux voulus à travers les registres, on active certaines interruptions et masques. Il faut finalement donner une taille au canal en fonction des paquets attendus ainsi que donner les caractéristiques du endpoint que l'Arduino présentera. <br /> <br /> Maintenant que l'initialisation a été modifié pour que la calculatrice apparaisse comme un hôte USB, il faut adapter les fonctions de communication. J'ai alors passé pas mal de temps à essayer de comprendre l'architecture du logiciel en terme de communication USB et chercher ce qu'il y a à modifier.<br /> <br /> ==Semaine 4==<br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> <br /> Après avoir passé du temps à essayer de trouver les modifications à apporter aux fonctions de communication USB du logiciel Numworks, j'ai découvert que STMicroelectronics propose des [https://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-mcu-packages/stm32cubef4.html bibliothèques] pour aider à la programmation de leurs microcontrôleurs. On trouve dans ces dernières des fonctions toutes faites pour la configuration de l'USB pour un mode hôte ou esclave. En plus de proposer des fonctions réalisant l'initialisation du core, du mode hôte et des canaux de communication comme j'ai pu le faire au cours des deux dernières semaines, ils proposent des fonctions de communication ainsi qu'une interface d'abstraction matérielle permettant de faciliter la portabilité. J'ai donc choisi d'utiliser ces bibliothèques plutôt que de continuer à réaliser les fonctions moi-même et de risquer de faire des erreurs qui seraient sûrement difficiles à trouver au moment des tests. Cela me permettra aussi probablement de gagner du temps. <br /> <br /> Après avoir programmé le logiciel Numworks pour utiliser la fonction d'initialisation de l'USB fournie par les bibliothèques STM, je suis confronté à un problème d'intégration au vu des erreurs apparaissant à la compilation.<br /> <br /> ==Semaine 5==<br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> <br /> - Résolution du problème de la semaine 4. La semaine dernière, en voulant intégrer les bibliothèques que propose STMicroelectronics j'ai été confronté à un problème à la compilation. Après avoir utilisé un type défini par les bibliothèques intégrées dans le code du logiciel Numworks afin de faire de la calculatrice un hôte USB, j'avais une erreur à la compilation qui m'indiquait que le type utilisé n'était pas défini bien que le fichier .h était lié. J'ai alors, dans un premier temps, pensé qu'il s'agissait d'un problème au niveau des makefile suite à l'ajout des bibliothèques. Finalement, en examinant le code des .h des bibliothèques STM, je me suis rendu compte qu'ils contenaient presque tous le code suivant :<br /> <br /> #if defined(STM32F405xx) || defined(STM32F415xx) || defined(STM32F407xx) || defined(STM32F417xx) || \<br /> defined(STM32F427xx) || defined(STM32F437xx) || defined(STM32F429xx) || defined(STM32F439xx) || \<br /> defined(STM32F401xC) || defined(STM32F401xE) || defined(STM32F411xE) || defined(STM32F446xx) || \<br /> defined(STM32F469xx) || defined(STM32F479xx) || defined(STM32F412Zx) || defined(STM32F412Vx) || \<br /> defined(STM32F412Rx) || defined(STM32F412Cx) || defined(STM32F413xx) || defined(STM32F423xx)<br /> <br /> Les bibliothèques proposées par STMicroelectronics sont communes à chacun de leurs microcontrôleurs. Cependant, ces derniers étant tous différents, il existe des différences au niveau des registres. Afin de pouvoir utiliser les bibliothèques, il faut donc définir le modèle de microcontrôleur utilisé dans un .h bien particulier. Sans cela, le '''if defined''' étant présent en tête de fichier et ne se fermant qu'à la fin, tout le contenu était ignoré. Après avoir défini l'utilisation du STM32F412VGT6 dans le .h adéquat, le problème de typage non reconnu à la compilation a été résolu.<br /> <br /> Après avoir inclus les nombreux .h différents nécessaires pour l'utilisation des fonctions d'initialisation du périphérique USB, j'ai été confronté à un autre problème :<br /> <br /> <br /> [[Fichier:Collisions.png|center|vignette|800px|Compilation suite à l'ajout des bibliothèques STM]]<br /> <br /> <br /> De nombreuses variables sont définies sous le même nom dans le logiciel Numworks et dans les bibliothèques STM mais sont utilisées différemment et dans deux langages (C++ pour Numworks, C pour bibliothèques STM). Des problèmes de collision apparaissent donc parmi d'autres à la compilation. Les variables en question étant utilisées dans de nombreux fichiers différents dont le code n'est pas forcément simple à comprendre sans l'étudier et y passer du temps, réadapter le code des bibliothèques à celui du logiciel demanderait beaucoup de temps. J'ai donc choisi de revenir sur la solution de départ et de réaliser les fonctions nécessaires moi-même en prenant appui sur ces bibliothèques.<br /> <br /> - J'ai donc dans un second temps, repris les fonctions d'initialisation créées au cours des semaines dernières pour les réutiliser et je les ai ajusté en fonction de l'implémentation que STMicroelectronics propose dans ses bibliothèques.<br /> <br /> ==Semaine 6==<br /> <br /> *''' Conception du robot ''' : <br /> <br /> Après avoir passé pas mal de temps sur l'établissement de la communication, j'ai décidé de laisser cela de côté pour cette semaine, j'y reviendrai plus tard. J'ai dans un premier temps assemblé le châssis du robot, chose relativement simple et rapide avec la notice fournie au kit. <br /> <br /> <br /> [[Fichier:Chassisassemble.jpg|center|thumb|500px|Châssis assemblé]]<br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Afin de réaliser un travail propre et qu'il n'y ait pas de fils dans tous les sens, il a été demandé de réaliser un shield pour l'arduino en y intégrant les différents composants utilisés. On intégrera à ce shield : <br /> <br /> - [https://www.pololu.com/file/0J86/TB6612FNG.pdf Le contrôleur de moteur TB6612FNG]<br /> <br /> - Des headers permettant de connecter les deux moteurs au contrôleur<br /> <br /> - [https://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm Le capteur de distance HC SR04]<br /> <br /> La batterie sera connectée au robot par le shield avec des fils. <br /> <br /> Les capteurs optiques suiveurs de lignes devant se trouver sous le robot pour être utiles, nous réaliserons un autre PCB pour ces derniers.<br /> <br /> <br /> J'ai décidé de réaliser ces cartes électroniques avec le logiciel [https://www.autodesk.com/products/eagle/overview Eagle], notamment parce qu'il est disponible sous Linux contrairement à Altium. Après avoir procédé à l'installation du logiciel, j'ai recherché des librairies Eagle proposant les composants dont j'ai besoin : <br /> <br /> - Librairie [https://github.com/sparkfun/SparkFun-Eagle-Libraries SparkFun-Boards] pour le template de shield Arduino Uno<br /> <br /> - Librairie [http://www.diymodules.org/eagle-show-object?type=dm&amp;file=diy-modules.lbr&amp;device=ULTRASONIC-HC-SR04 diy-modules] pour le capteur de distance HC SR04<br /> <br /> - Librairie [https://www.snapeda.com/parts/TB6612FNG,C,8,EL/Toshiba/view-part/ TB6612FNG,C,8,EL] pour le contrôleur de moteur TB6612FNG<br /> <br /> - Librairie [https://github.com/chiengineer/Eagle-Libraries/tree/master/Connectors con-headers-jp] pour les headers femelles<br /> <br /> - Librairie [https://github.com/sparkfun/SparkFun-Eagle-Libraries SparkFun-PowerSymbols] pour le 5V et la masse<br /> <br /> <br /> &lt;gallery mode=&quot;nolines&quot; widths=300px heights=200px&gt;<br /> File:Shieldtemplate.png|Template shield Arduino Uno<br /> <br /> File:HCSR04.png|Capteur de distance HC SR04<br /> <br /> File:Controleurmoteurv2.png|Contrôleur de moteur TB6612FNG<br /> &lt;/gallery&gt;<br /> <br /> <br /> J'ai ensuite cherché à savoir comment connecter les différents composants entre eux puis procédé à la réalisation du schematics et du PCB associé : <br /> <br /> <br /> [[Fichier:Schematicsshield2.png|center|thumb|800px|Schematic du shield]]<br /> <br /> <br /> [[Fichier:PCBShield2.png|center|thumb|2000px|PCB du shield]]<br /> <br /> ==Semaine 7==<br /> <br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Les capteurs de ligne devant se trouver en dessous du robot pour être utilisables, j'ai réalisé une seconde carte électronique afin de minimiser le nombre de fils de connexion sur le robot. Cette carte ne comporte que des capteurs suiveurs de ligne ainsi qu'un header pour lier cette dernière au shield.<br /> <br /> Pour réaliser cette carte, j'ai utilisé la librairie [https://www.snapeda.com/parts/QRE1113GR/Fairchild%20Semiconductor/view-part/ QRE1113GR] qui fourni la footprint du capteur optique QRE1113GR utilisé :<br /> <br /> <br /> [[Fichier:QRE1113GRfootprint.png|center|thumb|800px|Footprint du capteur optique QRE1113GR]]<br /> <br /> <br /> Le schematic de la carte est le suivant : <br /> <br /> [[Fichier:SchematicCapteurs.png|center|thumb|800px|Schematic de la carte de capteurs optiques pour le suivi de ligne]]<br /> <br /> <br /> Finalement, le PCB associé : <br /> <br /> <br /> [[Fichier:PCBCapteurs.png|center|thumb|800px|PCB de la carte de capteurs optiques pour le suivi de ligne]]<br /> <br /> <br /> <br /> <br /> *''' Retour de soutenance intermédiaire ''' :<br /> <br /> Suite à la soutenance intermédiaire, les objectifs du projet ont évolué. La modification du logiciel de la calculatrice Numworks étant possible mais demandant beaucoup de temps, cette tâche est abandonnée. A la place, nous utiliserons une solution déjà existante de communication en pur série avec l'Arduino : https://zardam.github.io/post/numworks-uart-over-usb/<br /> <br /> Les objectifs sont donc désormais les suivants : <br /> <br /> - Robot comme demandé initialement<br /> <br /> - Mettre en place un protocole de communication série pour que la calculatrice puisse<br /> utiliser les capteurs et les actionneurs du robot<br /> <br /> - Réaliser un câble propre pour la connexion entre la calculatrice NumWorks (port micro USB) et l'Arduino (E/S 0 et 1, masse)<br /> <br /> - Développer une API python simple pour qu'un lycéen puisse utiliser le robot<br /> <br /> - Développer un exemple de programme python sur la NumWorks pour utiliser le robot comme un suiveur de ligne avec arrêt en présence d'obstacles (sujet original)<br /> <br /> - Réaliser un démonstrateur de programmation de l'Arduino par la NumWorks : Ajout d'un capteur de température DHT22 sur le robot, saisie de codes assembleur ATMega328p (hexa) sur la Numworks pour la gestion du capteur (un code d'initialisation et un code de récupération de valeur), envoi des deux codes par série sur l'Arduino puis utilisation de ceux-ci.<br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> <br /> La communication entre la calculatrice Numworks et l'Arduino doit donc désormais se faire en série grâce à la solution https://zardam.github.io/post/numworks-uart-over-usb/<br /> <br /> L'auteur de cette solution a mappé un UART sur les ports D+ et D- de l'USB en modifiant le logiciel Numworks. La communication série est ainsi possible en utilisant le port USB de la calculatrice.<br /> <br /> ==Semaine 8==<br /> <br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Suite à l'évolution des objectifs, j'ai été amené à réaliser quelques modifications sur le PCB. Le capteur de température DHT22 a été ajouté, une réorganisation des connexions a été mené afin de permettre un routage plus simple et plus propre et enfin, étant donné que deux digital pins étaient libres sur l'Arduino, deux LEDs ont été ajouté et pourront notamment servir au débogage.<br /> <br /> Étant donné que le capteur de température est plus une option qu'autre chose sur le robot, plutôt que d'utiliser directement sa footprint et le souder par la suite, nous utiliserons un header. Ainsi, il pourra être enlevé et remis à souhait.<br /> <br /> Le nouveau schématic est le suivant : <br /> <br /> <br /> [[Fichier:SchShieldfinalmcreteur.png|center|thumb|1200px|Schematic final du shield Arduino]]<br /> <br /> <br /> Le PCB associé :<br /> <br /> [[Fichier:Shieldv2PCB.png|center|thumb|1200px|PCB du shield Arduino]]<br /> <br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> <br /> Afin que la calculatrice et l'Arduino puissent se comprendre lors de l'échange des messages, il faut définir un protocole de communication. La calculatrice doit pouvoir faire comprendre à l'Arduino les différentes commandes qu'elle veut faire exécuter, par exemple, ordonner au robot de tourner sur la gauche. Dans l'autre sens, la calculatrice doit pouvoir comprendre et interpréter les valeurs des capteurs que l'Arduino lui enverra. <br /> <br /> Nous pensons définir un message comme suit :<br /> <br /> - Caractère de début de message<br /> <br /> - Taille du message <br /> <br /> - Commande représentée par un chiffre (Par exemple, lorsque l'on enverra 1, le robot devra avancer tout droit). OU chiffre signifiant réponse de capteur<br /> <br /> - Paramètre de commande si nécessaire OU valeur de capteur<br /> <br /> - Checksum pour vérifier la bonne réception du message<br /> <br /> La taille d'un message et le type de données échangées n'a pas encore été décidé. D'ailleurs, concernant le type de données échangées, une API de communication série Python a été développé par l'auteur de la modification du logiciel Numworks. Cette dernière propose deux fonctions pour l'envoi et la réception qui ont été implémenté comme suit : <br /> <br /> mp_obj_t writeLine(mp_obj_t a) {<br /> Ion::Console::writeLine(mp_obj_str_get_str(a));<br /> return mp_const_none;<br /> }<br /> <br /> mp_obj_t readLine() {<br /> Ion::Console::readLine(line, 64);<br /> return mp_obj_new_str(line, strlen(line), false);<br /> }<br /> <br /> Ces deux dernières ayant été implémenté pour réaliser un tchat entre deux calculatrices Numworks, elles travaillent avec des String. Nous verrons si nous décidons d'utiliser ces dernières ou si il est plus judicieux de modifier les types utilisés.<br /> <br /> ==Semaine 9==<br /> <br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Modifications sur les cartes compte tenue des remarques des encadrants. Principalement : <br /> <br /> - Connexion des AO1/AO1, BO1/BO1, AO2/AO2, BO2/BO2 du contrôleur moteur afin de limiter le courant dans chacune des broches du circuit<br /> <br /> - Ajout d'un plan de masse sur chacune des cartes (améliorant le routage)<br /> <br /> - Déplacement/rotation de certains composants<br /> <br /> - Élargissement des pistes<br /> <br /> [[Fichier:PCBShieldfinalmcreteur.png|center|thumb|1200px|PCB final du shield Arduino]]<br /> <br /> <br /> [[Fichier:PCBAnnexefinalmcreteur.png|center|thumb|1200px|PCB final de la carte de suiveurs de ligne]]<br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> <br /> La communication entre la calculatrice et le robot se fera par échange de string. Une trame se composera comme suit : <br /> <br /> {| class=&quot;wikitable&quot; style=&quot;width:100%;text-align:center&quot;<br /> ! style=&quot;padding: 5px;&quot;| <br /> Information<br /> | Char de début de trame<br /> | Commande<br /> | Paramètres<br /> | Checksum<br /> | Char de fin de trame<br /> |-<br /> ! style=&quot;padding: 5px;&quot; | <br /> Nombre de Char<br /> | 1<br /> | 2<br /> | 3<br /> | 3<br /> | 1<br /> |-<br /> |}<br /> <br /> Cette trame a plutôt été pensé pour l'envoi de commande de la calculatrice vers l'Arduino (implémentée cette semaine), nous nous préoccuperons de la réponse lors de la semaine 10. Le champ paramètre n'est là qu'au cas ou et sera peut-être amené à disparaître pour l'envoi de commande. Pour la réponse, nous pourrions préciser le type de capteur à la place dans le champs Commande et la valeur du capteur en question dans le champs Paramètre ou alors constituer une trame contenant la valeur de tous les capteurs (à réfléchir).<br /> <br /> <br /> Une commande sera donc représentée par deux Char. La liste des commandes avec l'expression en Char est la suivante : <br /> <br /> - LED1 : &quot;01&quot; (Allumer la LED1)<br /> <br /> - LED2 : &quot;02&quot; (Allumer la LED2)<br /> <br /> - MOVE_FORWARD : &quot;10&quot; (Avancer)<br /> <br /> - MOVE_BACKWARD : &quot;11&quot; (Reculer)<br /> <br /> - MOVE_RIGHT : &quot;12&quot; (Tourner à droite)<br /> <br /> - MOVE_LEFT : &quot;13&quot; (Tourner à gauche)<br /> <br /> - STOP : &quot;05&quot; (Arrêter le robot)<br /> <br /> - GET_DISTANCE : &quot;06&quot; (Demander la valeur indiquée par le capteur de distance)<br /> <br /> - GET_LINEFOLLOWER : &quot;07&quot; (Demander les valeurs indiquées par les capteurs optiques)<br /> <br /> - GET_TEMP : &quot;08&quot; (Demander la valeur indiquée par le capteur de température)<br /> <br /> <br /> <br /> *''' Développement de l'API ''' :<br /> <br /> La calculatrice permet le développement Python grâce à MicroPython qui est une version de Python pour l'embarqué. Le développement d'une API se fait directement dans le code source MicroPython en C/C++. En plus d'écrire l'API dans un fichier .c ou .cpp comme on le fait traditionnellement, il faut modifier différents fichiers afin que MicroPython puisse reconnaître l'API et les différentes fonctions implémentées ainsi que permettre l'import du module développé. <br /> <br /> <br /> J'ai choisi de nommer l'API &quot;robot&quot;. Il faut écrire un fichier .c définissant la structure du nouveau module : <br /> <br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(led1_obj, led1);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(led2_obj, led2);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(moveForward_obj, moveForward);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(moveBackward_obj, moveBackward);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(moveLeft_obj, moveLeft);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(moveRight_obj, moveRight);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(stop_obj, stop);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(getDistanceSensorValue_obj, getDistanceSensorValue);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(getTemperatureSensorValue_obj, getTemperatureSensorValue);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(getLineFollowerSensor1Value_obj, getLineFollowerSensor1Value);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(getLineFollowerSensor2Value_obj, getLineFollowerSensor2Value);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(getLineFollowerSensor3Value_obj, getLineFollowerSensor3Value);<br /> <br /> STATIC const mp_rom_map_elem_t robot_module_globals_table[] = {<br /> { MP_ROM_QSTR(MP_QSTR___name__), MP_ROM_QSTR(MP_QSTR_robot) },<br /> { MP_ROM_QSTR(MP_QSTR_led1), (mp_obj_t)&amp;led1_obj },<br /> { MP_ROM_QSTR(MP_QSTR_led2), (mp_obj_t)&amp;led2_obj },<br /> { MP_ROM_QSTR(MP_QSTR_moveForward), (mp_obj_t)&amp;moveForward_obj },<br /> { MP_ROM_QSTR(MP_QSTR_moveBackward), (mp_obj_t)&amp;moveBackward_obj },<br /> { MP_ROM_QSTR(MP_QSTR_moveLeft), (mp_obj_t)&amp;moveLeft_obj },<br /> { MP_ROM_QSTR(MP_QSTR_moveRight), (mp_obj_t)&amp;moveRight_obj },<br /> { MP_ROM_QSTR(MP_QSTR_stop), (mp_obj_t)&amp;stop_obj },<br /> { MP_ROM_QSTR(MP_QSTR_getDistanceSensorValue), (mp_obj_t)&amp;getDistanceSensorValue_obj },<br /> { MP_ROM_QSTR(MP_QSTR_getTemperatureSensorValue), (mp_obj_t)&amp;getTemperatureSensorValue_obj },<br /> { MP_ROM_QSTR(MP_QSTR_getLineFollowerSensor1Value), (mp_obj_t)&amp;getLineFollowerSensor1Value_obj },<br /> { MP_ROM_QSTR(MP_QSTR_getLineFollowerSensor2Value), (mp_obj_t)&amp;getLineFollowerSensor2Value_obj },<br /> { MP_ROM_QSTR(MP_QSTR_getLineFollowerSensor3Value), (mp_obj_t)&amp;getLineFollowerSensor3Value_obj }<br /> };<br /> <br /> STATIC MP_DEFINE_CONST_DICT(robot_module_globals, robot_module_globals_table);<br /> const mp_obj_module_t robot_module = {<br /> .base = { &amp;mp_type_module },<br /> .globals = (mp_obj_dict_t*)&amp;robot_module_globals,<br /> };<br /> <br /> <br /> Ce fichier permet de définir le module MicroPython à travers une structure de type '''mp_obj_module_t'''. On définit d'abord les différentes fonctions du module sous forme d'objet. On remplit ensuite un dictionnaire avec les différentes fonctions implémentées. Finalement, on initialise les différents champs de la structure qui représentera l'API en lui précisant notamment le dictionnaire contenant les objets de fonction créés.<br /> <br /> Afin de permettre l'import de l'API dans un futur code d'utilisation Python, on modifie le fichier '''mpconfigport.h''' en y ajoutant la ligne suivante dans la définition des '''MICROPY_PORT_BUILTIN_MODULES''' : <br /> { MP_ROM_QSTR(MP_QSTR_robot), MP_ROM_PTR(&amp;robot_module) }<br /> <br /> Afin d'ajouter la reconnaissance par MicroPython des fonctions implémentées dans notre API et de son nom, il faut modifier le fichier '''qstrdefsport.h'''. Dans notre cas, on y ajoute les lignes suivantes :<br /> Q(robot)<br /> Q(led1)<br /> Q(led2)<br /> Q(moveForward)<br /> Q(moveBackward)<br /> Q(moveLeft)<br /> Q(moveRight)<br /> Q(stop)<br /> Q(getDistanceSensorValue)<br /> Q(getTemperatureSensorValue)<br /> Q(getLineFollowerSensor1Value)<br /> Q(getLineFollowerSensor2Value)<br /> Q(getLineFollowerSensor3Value)<br /> <br /> MicroPython sera alors capable de reconnaître par exemple que led1 correspond à une fonction définie.<br /> <br /> Finalement, on implémente l'API dans un fichier .cpp ou .c comme on le fait traditionnellement. <br /> <br /> Cette semaine, j'ai écrit une fonction pour le calcul du checksum qui réalise la somme de tous les chars de la trame. Le checksum sera représenté par 3 chars. <br /> <br /> J'ai ensuite écrit une fonction de formation de la trame à envoyer. Cette dernière prend en paramètre la string de deux chars représentant la commande à réaliser ainsi qu'une string de 3 chars représentant les paramètres de commande à associer. Elle réalise alors une string en plaçant en première position un 'S' indiquant le début de trame, en plaçant ensuite la commande, les paramètres, le checksum en faisant appel à la fonction de calcul de checksum puis termine par le caractère de fin de trame 'E'.<br /> <br /> J'ai finalement défini les fonctions de commande '''led1(), led2(), moveForward(), moveBackward(), moveRight(), moveLeft() et stop()''' qui font appel à la fonction de construction de trame en précisant la commande associée et écrivent sur le port série grâce à la fonction '''writeLine(mp_objet_t objet)''' implémentée par Zardam.<br /> <br /> Ainsi, pour demander au robot d'avancer, la string envoyée sera la suivante : '''S13000417E'''<br /> <br /> <br /> Lors de l'écriture des différentes fonctions, j'ai été confronté à un des principaux enjeux de l'embarqué : l'optimisation des ressources. La calculatrice présentant un stockage disponible assez faible, les fonctions des librairies standards du langage C non utilisées ont été supprimé afin de d'occuper le moins d'espace possible. Par exemple, la fonction '''strcat''' de la librairie '''&lt;string.h&gt;''' n'est pas disponible, j'ai alors dû trouver des alternatives.<br /> <br /> ==Semaine 10==<br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Les cartes n'ont pas pu être gravées cette semaine. J'ai eu un retour de Monsieur Flamen vendredi qui m'a indiqué qu'il était impossible de les graver du fait d'une isolation trop faible des pistes par rapport au plan de masse. Si elles avaient été gravé, il y aurait eu des courts circuits partout. J'ai alors modifié ces dernières et j'ai fixé l'isolation des pistes par rapport au plan de masse à 12 mil qui est le minimum à respecter. J'ai été confronté à un problème suite à cette modification sur la carte du shield. Avec une isolation de 12 mil, le plan de masse ne peut pas recouvrir toute la carte et certaines zones de masse sont des zones &quot;orphelines&quot; c'est à dire, non reliées au reste du plan de masse. Ne voyant pas d'autre solution et avec les conseils de Monsieur Flamen, j'ai ajouté des vias pour réaliser la connexion entre les différentes zones de masse. Une fois la carte gravée, ces zones seront alors connectées par un fil sur la face top. <br /> <br /> <br /> *''' Conception du robot''' : <br /> <br /> Ayant avancé sur la partie programmation de la calculatrice et de l'Arduino, il me fallait réaliser le câble de connexion pour relier les deux afin de pouvoir réaliser des tests et voir si la programmation réalisée est fonctionnelle ou non. Utilisant une communication série, il me fallait un câble qui puisse être branché d'un côté sur le port micro-USB de la Numworks et de l'autre, sur le port série de l'Arduino. Ce type de câble n'existant pas à ma connaissance, j'ai pris un câble USB - micro-USB dont j'ai coupé la partie USB puis j'ai extrait les quatre fils (GND, VCC, Data+ et Data-) en dénudant.<br /> <br /> <br /> [[Fichier:USBwire.png|center|thumb|1200px|Fils d'un câble USB]]<br /> <br /> <br /> J'ai ensuite soudé un fil de connexion mâle-mâle sur chacun des fils afin de pouvoir les connecter à l'Arduino plus aisément. Enfin, j'ai ajouté de la gaine thermorétractable afin d'avoir un rendu plus propre et plus solide. Je peux désormais établir une connexion série entre la Numworks et l'Arduino avec ce câble en connectant :<br /> <br /> - Le fil vert D- sur Tx<br /> <br /> - Le fil blanc D+ sur Rx<br /> <br /> - Le fil noir GND sur GND<br /> <br /> Le fil rouge Vcc ne sera pas utilisé car la calculatrice ne nécessite pas d'alimentation.<br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot / Développement de l'API''' :<br /> <br /> Ayant écrit les fonctions de l'API Numworks permettant de contrôler les leds et les moteurs la semaine dernière, je me suis occupé cette semaine de la partie Arduino afin de pouvoir commencer à réaliser des tests et voir si l'on arrive bien à communiquer entre l'Arduino et la calculatrice. <br /> <br /> - Setup() : Indication Output ou Input pour chaque pin selon le schematic du shield. Baudrate à 115200 car c'est celui utilisé par la Numworks. <br /> <br /> - Réalisation d'une fonction de lecture de trame reçue. Tant que l'on reçoit des caractères et que l'on a pas lu le caractère de fin de trame 'E', on les stocke dans un tableau de Char.<br /> <br /> - Écriture d'une fonction de découpage de la trame. Afin de faciliter son implémentation, j'ai modifié le format des trames en ajoutant un caractère de séparation '-' entre chaque type de donnée. Les trames sont désormais de la forme : '''S-01-000-573-E'''. On utilise alors la fonction strtok pour stocker la commande reçue (dans la trame précedente : &quot;01&quot;), les paramètres (&quot;000&quot;) et le checksum (&quot;573&quot;) en ayant pris soin de vérifier que le premier caractère de la trame est bien 'S'.<br /> <br /> - Écriture d'une fonction de vérification du checksum. On renvoie True ou False selon que la somme des caractères de la trame (sans le checksum) est égale au checksum de la trame ou non<br /> <br /> - Écriture d'une fonction de traitement de la commande reçue. Si le checksum de la trame est correct, on exécute la commande associée à l'ordre reçu.<br /> <br /> - Écriture de la fonction principale loop(). On lit la trame, on la découpe et on exécute la commande demandée.<br /> <br /> <br /> Une fois le programme Arduino écrit, j'ai ajouté un script de test dans la Numworks pour ne pas avoir à le réécrire à chaque fois. Pour cela, il y a plusieurs fichiers de l'OS epsilon à modifier. <br /> <br /> On définit le script dans le fichier '''epsilon/apps/code/script_template.cpp''' :<br /> <br /> const ScriptTemplate * ScriptTemplate::TestRobot() {<br /> return &amp;testRobotScriptTemplate;<br /> }<br /> <br /> constexpr ScriptTemplate testRobotScriptTemplate(&quot;test_robot.py&quot;, R&quot;(import robot<br /> def test1():<br /> robot.led1()&quot;);<br /> <br /> Dans ce script de test, on exécute la fonction led1() qui envoie à l'Arduino une demande d'allumage de la LED déjà présente sur l'Arduino (Pin 13), en utilisant la nouvelle API 'robot'.<br /> <br /> On ajoute alors un attribut à la classe '''ScriptTemplate''' du fichier '''epsilon/apps/code/script_template.h''' :<br /> <br /> static const ScriptTemplate * TestRobot();<br /> <br /> Enfin, on rend accessible le script grâce à la fonction addScriptFromTemplate dans le fichier '''epsilon/apps/code/script_store.cpp'''<br /> <br /> addScriptFromTemplate(ScriptTemplate::TestRobot());<br /> <br /> Le script de test est désormais disponible dans l'application Python de la Numworks sous le nom : '''test_robot.py'''. Il n'y a plus qu'a exécuter le script et appeler la fonction définie dans ce dernier.<br /> <br /> <br /> Après cela, j'ai pu tester la communication entre la Numworks et l'Arduino. Dans un premier temps, l’exécution du script sur la calculatrice provoquait un arrêt de celle-ci qu'elle soit connectée ou non à l'Arduino. La seule solution pour récupérer le contrôle de la calculatrice était alors le bouton reset. J'ai alors pensé à un problème mémoire. Utilisant des mallocs dans l'implémentation de l'API, j'ai vérifié s'il n'y avait pas de fuite mémoire grâce à Valgrind. Ce n'était pas le cas, l'utilitaire n'indiquait aucun problème. Finalement, le problème venait d'une mauvaise utilisation des types MicroPython lors de l'écriture sur le port série grâce à la fonction WriteLine(mp_objet_t objet). Après avoir corrigé ce problème, j'ai pu vérifier le bon fonctionnement de la communication. Lors de l'exécution du script, la LED de l'Arduino s'allume bien.<br /> <br /> ==Semaine 11==<br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Les cartes ont été gravées. Tous les composants ont été soudé. J'ai passé pas mal de temps sur la soudure des headers qui ne prenait pas. Je remercie d'ailleurs M Flamen pour l'aide ainsi que la solution qu'il m'a apporté. Après avoir essayé lui même, il s'est résolu à apporter de l'ancien étain de chez lui qui a été beaucoup plus efficace et a finalement permis de souder les composants traversants.<br /> <br /> <br /> &lt;gallery mode=&quot;packed&quot; widths=300px heights=300px&gt;<br /> <br /> File:Shieldmcreteur.png|Shield après soudures<br /> <br /> File:SuiveurLignemcreteur.png|Carte de suiveurs de ligne après soudures<br /> <br /> &lt;/gallery&gt;<br /> <br /> <br /> Une fois les soudures réalisées, j'ai pu tester les deux cartes. <br /> <br /> Le shield ne semble pas fonctionner, lors de l'ajout de ce dernier à l'Arduino, il n'est plus possible de téléverser de programme, l'Arduino ne répond plus : <br /> <br /> <br /> [[Fichier:ErreurShield.png|center|thumb|600px|Arduino ne répondant plus après ajout du shield]]<br /> <br /> <br /> Cela provient probablement d'un court-circuit sur le shield apparu lors des soudures. La résolution de ce problème sera l'objectif principal de la semaine prochaine.<br /> <br /> Quant à la carte de suiveurs de lignes, elle est fonctionnelle en la connectant directement à l'Arduino, je suis capable de récupérer les valeurs renvoyées par les différents capteurs.<br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot / Développement de l'API''' :<br /> <br /> Cette semaine, je me suis occupé de la partie échange de valeurs des capteurs. Je garde au final le même format de trame pour la réponse, la valeur du capteur en question occupera le champs &quot;paramètre&quot; qui ne servait pas jusqu'à maintenant. Dans un premier temps, du côté de l'Arduino, j'ai ajouté : <br /> <br /> - Une fonction de formation de la trame de réponse qui est sensiblement la même que celle écrite pour l'envoi de commande sur la Numworks. La différence notable est qu'elle prend ici en paramètre la valeur du capteur à envoyer.<br /> <br /> - Une fonction de calcul de checksum qui est la même que celle utilisée pour l'envoi de commande sur la Numworks<br /> <br /> - Une fonction pour les suiveurs de ligne qui récupère la valeur du capteur, la donne à la fonction de formation de réponse puis envoie la réponse sur le port série. La récupération de la valeur du capteur se fait juste par lecture du pin analogique associé au capteur suiveur de ligne voulu.<br /> <br /> - Une fonction pour le capteur de distance qui récupère la valeur du capteur, la donne à la fonction de formation de réponse puis envoie la réponse sur le port série. Pour récupérer la valeur du capteur de distance, il faut d'abord envoyer une pulsation sur TRIGGER pour lancer une mesure. Un ultrason est alors lancé et est réfléchit par l'obstacle si il y en a un avant de revenir au capteur. La valeur lue sur le pin ECHO est alors le temps mis par l'onde pour aller jusqu'à l'obstacle puis revenir. On divise donc cette valeur par deux puis on utilise la relation d = v*t pour finalement avoir la distance séparant le robot de l'obstacle.<br /> <br /> - Ajout de la prise en compte des demandes de valeur du capteur de distance ou des suiveurs de ligne dans la fonction de traitement de la commande reçue.<br /> <br /> Les fonctions citées précédemment permettent bien d'envoyer une réponse valide sur le port série. Il faudra par contre vérifier si la lecture des capteurs est correcte une fois que le shield sera utilisable.<br /> <br /> Dans un second temps, j'ai ajouté sur la Numworks : <br /> <br /> - Une fonction de lecture de trame. Pour lire sur le port série, on utilise la fonction implémentée par Zardam readLine(). On définit alors une variable globale pour le stockage de la trame que l'on remplit en récupérant la chaîne de caractères qui arrive sur le port série '''mp_obj_str_get_str(readLine())'''<br /> <br /> - Une fonction de découpage de la réponse reçue. Contrairement à la fonction de parsing implémentée sur l'Arduino, je n'ai pas pu utiliser '''strtok''' pour le découpage, cette fonction n'étant pas présente dans epsilon. La fonction '''strchr''' est par contre disponible et c'est cette dernière qui m'a permis de réaliser le parsing. En localisant les caractères de délimitation ''' '-' ''' par '''strchr''', je peux déplacer le pointeur sur le caractère suivant et ainsi récupérer les caractères qui m'intéressent avec '''strlcpy'''.<br /> <br /> - Une fonction de récupération de la valeur du capteur de distance. Dans un premier temps, on envoie à l'Arduino la trame demandant la valeur du capteur de distance grâce aux fonctions implémentées lors des semaines précédentes. Une fois la demande envoyée, on utilise la fonction de lecture puis de parsing pour récupérer la valeur demandée. La valeur récupérée étant sous forme de string, on utilise la fonction '''atoi''' pour obtenir la valeur en int. Finalement, on renvoi la valeur sous forme d'entier MicroPython : '''return mp_obj_new_int(value);'''<br /> <br /> - Une fonction de récupération pour chaque capteur suiveur de ligne qui fonctionne exactement de la même façon que la fonction pour le capteur de distance.<br /> <br /> Il faudra ajouter à la lecture des réponses une fonction de vérification du checksum. <br /> <br /> Après avoir implémenté toutes les fonctions citées précédemment, j'ai pu les tester en définissant moi-même une valeur de capteur. La demande est bien envoyée à l'Arduino qui répond correctement suivant le capteur voulu. La Numworks est bien capable d'isoler la valeur désirée dans la trame reçue est de la renvoyer.<br /> <br /> J'ai passé pas mal de temps sur l'écriture des fonctions du coté de la Numworks par rapport à l'utilisation rigoureuse des types MicroPython et à la difficulté de réaliser des tests ainsi que de débugger.<br /> <br /> ==Semaine 12==<br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Le problème du shield a été résolu. Un court-circuit se trouvait sur Rx ce qui expliquait la non communication entre l'Arduino et le PC ou la Numworks après l'ajout du shield. Le shield fonctionne désormais correctement.<br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot / Développement de l'API''' :<br /> <br /> J'ai ajouté le contrôle du checksum lorsqu'une réponse est reçue sur la Numworks. L'algorithme est le même que sur l'Arduino, on somme tous les caractères de la trame reçue excepté le checksum puis on vérifie si c'est égal au checksum contenu dans la trame reçue. <br /> <br /> <br /> Maintenant que le shield est fonctionnel, j'ai pu tester si les différents composants fonctionnaient correctement ainsi que les fonctions implémentées de traitement des données des capteurs. J'ai alors été confronté à un problème lors de l'utilisation du capteur de distance. Lorsque j'utilisais la fonction implémentée en demandant une lecture de capteur de distance à partir de la calculatrice, j'obtenais tout le temps une valeur nulle. En revanche, lorsque j'utilisais la fonction implémentée dans un programme à part sur l'Arduino, les valeurs reçues étaient correctes. Après avoir passé quelques heures à chercher la cause du problème, je me suis rendu compte qu'il était causé par une double utilisation de la fonction pinMode dans deux modes différents pour un des pins du capteur de distance.<br /> <br /> <br /> Une fois que l'utilisation de chacun des composants du robot était fonctionnelle, j'ai tenté de réaliser plusieurs échanges à la suite entre l'Arduino et la Numworks dans l'optique de développer le programme de suivi de lignes. Par exemple, en écrivant un script Python demandant au robot d'avancer puis de s'arrêter lorsqu'il se trouve à moins de 100 mm d'un obstacle :<br /> <br /> import robot<br /> def test():<br /> robot.moveForward()<br /> while(1):<br /> if (robot.getDistanceSensorValue() &lt;= 100):<br /> robot.stop() <br /> break<br /> <br /> Je me suis alors rendu compte qu'il était impossible d'effectuer deux échanges à la suite entre l'Arduino et la Numworks, avant même que l'Arduino n'avait traité la première commande, la Numworks avait déjà envoyé la suivante ce qui provoquait une incompréhension entre les deux. Pour résoudre ce problème, j'ai décidé de mettre en place une validation du traitement d'une commande reçue. Sur l'Arduino, lorsqu'une commande à effectuer ne nécessite pas de réponse pour la Numworks, par exemple, la commande de moteurs ou de led, l'Arduino envoie désormais &quot;OK&quot; à la Numworks lorsque la commande a été traité. Du côté de la Numworks, lorsque l'on demande à l'Arduino de réaliser une action ne nécessitant pas de réponse, on attend d'avoir reçu la validation &quot;OK&quot; par l'Arduino avant de retourner. Ainsi, la Numworks attend désormais que l'Arduino ait traité la commande avant d'en envoyer une autre, il n'y a plus de problème de synchronisation. <br /> <br /> <br /> <br /> *''' Développement du programme Python ''' :<br /> <br /> Une fois qu'il eut été possible de chaîner les échanges, j'ai tenté d'établir le programme exemple de suivi de lignes avec arrêt en cas d'obstacle. Avant même d'arriver bien loin dans l'implémentation de ce dernier, je me suis rendu compte que le temps de traitement des échanges allait être un problème pour le suivi de ligne. J'ai alors modifié les fonctions moteurs sur l'Arduino pour que le robot se déplace lentement et ainsi avoir plus de temps pour traiter les informations échangées. Cependant, cela risque de ne pas suffire, en utilisant le script mentionné plus haut pour la détection d'obstacle, le robot qui est censé s'arrêter lorsqu'un obstacle se trouve à 10cm de lui, ne s'arrête qu'à 2 ou 3 cm de l'obstacle.<br /> <br /> ==Semaine 13==<br /> <br /> *''' Conception du robot''' :<br /> <br /> Réalisation manuelle d'un support en bois pour la calculatrice afin de pouvoir la poser sur le robot : <br /> <br /> [[Fichier:supportNumworks.jpg|center|thumb|500px|Support pour la Numworks]]<br /> <br /> <br /> Il s'avère cependant que le support réalisé est assez lourd et gêne le déplacement du robot par son poids.<br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot / Développement de l'API''' :<br /> <br /> Suite au problème rencontré de la lenteur des échanges d'information entre la calculatrice et le robot, j'ai revu la façon de récupérer les valeurs des capteurs. On envoyait jusqu'à présent une trame par capteur. Afin de réduire un peu les échanges, j'ai implémenté une nouvelle commande qui demande la valeur de tous les capteurs. L'Arduino renvoie alors la valeur du capteur de distance et des trois suiveurs de ligne dans une seule trame de réponse constituée comme suit : <br /> <br /> {| class=&quot;wikitable&quot; style=&quot;width:100%;text-align:center&quot;<br /> ! style=&quot;padding: 5px;&quot;| <br /> Information<br /> | Char de début de trame<br /> | Capteur de distance<br /> | Suiveur de ligne gauche<br /> | Suiveur de ligne centre<br /> | Suiveur de ligne droit<br /> | Checksum<br /> | Char de fin de trame<br /> |-<br /> ! style=&quot;padding: 5px;&quot; | <br /> Nombre de Char<br /> | 1<br /> | 3<br /> | 3<br /> | 3<br /> | 3<br /> | 4<br /> | 1<br /> |-<br /> |}<br /> <br /> <br /> Après test, je me suis rendu compte que cela n'améliorait pas énormément le temps mis par la calculatrice et le robot pour s'échanger des données. J'ai alors cherché à trouver la source du problème. En laissant la Numworks de côté et en envoyant les trames à la main sur le port série à partir du PC, le temps mis pour récupérer la trame de réponse envoyée par l'Arduino était le même qu'en envoyant la trame par la Numworks. Le problème ne venait donc pas de la formation des trames. Il s'agissait en faite de la fonction de lecture de trame implémentée sur l'Arduino : <br /> <br /> void lireTrame() {<br /> if (Serial.find(&quot;S-&quot;)) {<br /> Serial.readBytes(serialBuffer,14);<br /> strcpy(trame, &quot;S-&quot;);<br /> strlcpy(trame + strlen(trame), serialBuffer, strlen(serialBuffer)+1);<br /> trame[15] = '\0';<br /> }<br /> }<br /> <br /> Après l'avoir remplacé par la suivante : <br /> <br /> void lireTrame() {<br /> int nbCharLus = 0;<br /> while (Serial.available() &gt; 0 &amp;&amp; nbCharLus &lt;= 14) {<br /> trame[nbCharLus] = Serial.read();<br /> nbCharLus++;<br /> delay(5);<br /> }<br /> trame[nbCharLus] = '\0';<br /> }<br /> <br /> Le temps d'échange est devenu nettement plus court et m'a redonné de l'espoir vis à vis du suivi de ligne.<br /> <br /> <br /> <br /> *''' Développement du programme Python''' :<br /> <br /> Dans un premier temps, j'ai décidé de développer le suiveur de ligne sur l'Arduino seule afin d'avoir un programme dont je suis sûr du fonctionnement et d'éviter certains problèmes. Je me suis vite rendu compte qu'un simple algorithme comme : <br /> <br /> Tant que 1 : <br /> Si obstacle : <br /> s'arrêter<br /> Sinon si capteur centre sur la ligne : <br /> avancer tout droit<br /> Sinon si capteur gauche sur la ligne :<br /> tourner à gauche<br /> Sinon si capteur droit sur la ligne : <br /> tourner à droite<br /> Fin tant que<br /> <br /> Ne me permettrait pas de passer les angles droits. J'ai alors abouti sur l'algorithme suivant :<br /> <br /> Tant que 1 : <br /> Si obstacle : <br /> s'arrêter<br /> Sinon si capteur centre sur la ligne ET capteur G et D pas sur la ligne : <br /> avancer tout droit<br /> Sinon si capteur G sur la ligne ET capteur D pas sur la ligne :<br /> tourner à gauche<br /> derniereAction &lt;- gauche<br /> Sinon si capteur D sur la ligne ET capteur G pas sur la ligne: <br /> tourner à droite<br /> derniereAction &lt;- droite<br /> Sinon si capteur G ET capteur D sur la ligne : <br /> Si derniereAction == droite :<br /> Tourner à gauche<br /> derniereAction &lt;- gauche<br /> Sinon si derniereAction == gauche :<br /> Tourner à droite<br /> derniereAction &lt;- droite<br /> Sinon si capteur G et D et C pas sur la ligne : <br /> Si derniereAction == droite :<br /> Tourner à droite<br /> Sinon si derniereAction == gauche :<br /> Tourner à gauche<br /> Fin tant que<br /> <br /> <br /> Une fois l'algorithme fonctionnel, j'ai tenté de le porter sur la Numworks. J'ai alors passé de nombreuses heures sur un problème qui, au final, s'avèrait assez bête. Lorsque j'utilisais la batterie sur l'Arduino pour le suivi de ligne sans la Numworks, il n'y avait aucun problème. En revanche, en utilisant la Numworks, le capteur de distance renvoyait toujours des valeurs fausses et le robot s'arrêtait alors qu'il n'y avait pas d'obstacle devant lui. Lorsque l'Arduino était alimentée en série par le pc, il n'y avait plus de problème. Après m'être cassé la tête sur le problème et avoir tout tenté, je me suis résolu à changer les piles... ce qui a résolu le problème. <br /> Après quelques ajustements, le suivi de ligne avec arrêt lors de la rencontre d'un obstacle est fonctionnel en commandant le robot par la Numworks.<br /> <br /> =Documents Rendus=<br /> <br /> - Gitlab du projet : https://archives.plil.fr/mcreteur/NumworksEtRobot.git<br /> <br /> - Code version zip : [[Media:NumworksEtRobot.zip|NumworksEtRobot]]<br /> <br /> - Schematics, routage et fichiers Gerber des cartes réalisées : [[Media:CartesElectroniquesmcreteur.zip|Fichiers cartes électroniques]]<br /> <br /> - [[Media:Rapport_Numworks&amp;Robot.pdf|Rapport de projet]]<br /> <br /> =Bibliographie=<br /> <br /> - https://zardam.github.io/post/numworks-uart-over-usb/<br /> <br /> - https://github.com/zardam/epsilon/tree/uart_over_usb<br /> <br /> - https://github.com/numworks/epsilon<br /> <br /> - https://www.numworks.com/<br /> <br /> - https://www.st.com/content/ccc/resource/technical/document/user_manual/b8/5a/28/c2/cf/b6/47/d6/DM00105256.pdf/files/DM00105256.pdf/jcr:content/translations/en.DM00105256.pdf<br /> <br /> - https://www.st.com/content/ccc/resource/technical/document/user_manual/1c/6b/06/e6/19/6c/46/bf/CD00289278.pdf/files/CD00289278.pdf/jcr:content/translations/en.CD00289278.pdf<br /> <br /> - https://www.st.com/content/ccc/resource/technical/document/reference_manual/group0/4f/7b/2b/bd/04/b3/49/25/DM00180369/files/DM00180369.pdf/jcr:content/translations/en.DM00180369.pdf<br /> <br /> - https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018<br /> <br /> - http://aaroneiche.com/2010/06/24/a-beginners-guide-to-making-an-arduino-shield-pcb/<br /> <br /> - https://www.open-electronics.org/how-to-make-an-arduino-shield-with-eagle-cad-tutorial/<br /> <br /> - https://docs-emea.rs-online.com/webdocs/10e2/0900766b810e25b7.pdf<br /> <br /> - https://www.sparkfun.com/datasheets/Robotics/TB6612FNG.pdf<br /> <br /> - https://forum.micropython.org/viewtopic.php?t=776<br /> <br /> - https://micropython-dev-docs.readthedocs.io/en/latest/adding-module.html<br /> <br /> - https://www.snapeda.com/parts/QRE1113GR/Fairchild%20Semiconductor/view-part/<br /> <br /> - https://www.snapeda.com/parts/POLOLU-713/Pololu/view-part/<br /> <br /> - http://www.diymodules.org/eagle-show-object?type=dm&amp;file=diy-modules.lbr&amp;device=ULTRASONIC-HC-SR04<br /> <br /> - https://odpf.org/images/archives_docs/17eme/memoires/gr-5/memoire.pdf<br /> <br /> - https://www.techiedelight.com/implement-itoa-function-in-c/</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:NumworksEtRobot.zip&diff=64838 2018-12-20T12:17:01Z

<p>Mcreteur : </p> <hr /> <div></div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P2&diff=64793 2018-12-20T02:59:33Z

<p>Mcreteur : /* Documents Rendus */</p> <hr /> <div>__TOC__<br /> &lt;br style=&quot;clear: both;&quot;/&gt;<br /> <br /> ='''NumWorks et robot'''=<br /> <br /> =Présentation générale=<br /> <br /> ==Description==<br /> <br /> Le projet consiste à commander un robot classique par une calculatrice NumWorks avec un programme Python. Après avoir conçu un robot classique à base d'Arduino, moteurs, sonar ultrason et suiveurs de lignes, il faudra modifier le logiciel d'une calculatrice NumWorks afin que cette dernière soit capable de communiquer avec le robot. Une fois la communication établie, nous développerons une API afin de contrôler le robot. Finalement, nous écrirons un programme python utilisant l'API pour transformer le robot en un robot suiveur de ligne avec arrêt en cas d'obstacle et redémarrage automatique lors de la disparition de l'obstacle.<br /> <br /> <br /> L’intérêt de ce projet serait de permettre l'initiation à la robotique aux lycéens à moindre coût. Les lycéens ayant tous à acheter eux-mêmes une calculatrice, en leur imposant la Numworks, il n'y aurait que les robots à acheter pour un peu moins de 50 euros. Ils pourraient alors découvrir le monde de la programmation robotique en utilisant l'API développée sur la Numworks qui permet la programmation Python.<br /> <br /> ==Objectifs==<br /> <br /> * Conception d'un robot classique<br /> * Modification du logiciel d'une calculatrice NumWorks pour établir une communication entre le robot et la calculatrice<br /> * Développer une API permettant le contrôle du robot<br /> * Développer un programme Python transformant le robot en un robot suiveur de ligne avec arrêt en cas d'obstacle et redémarrage automatique lors de la disparition de l'obstacle<br /> <br /> =Préparation du projet=<br /> <br /> ==Cahier des charges==<br /> <br /> ''' Robot :'''<br /> * Concevoir un robot mobile à partir d'un Arduino Uno, capable de détecter des obstacles grâce à un capteur de distance à ultrason et de suivre une ligne grâce à des capteurs suiveurs de ligne<br /> <br /> ''' Communication :'''<br /> * Établir une communication entre le robot et la calculatrice NumWorks en tentant de passer le micro-contrôleur en hôte USB et en utilisant le FTDI de l'Arduino<br /> <br /> ''' API :'''<br /> * Développer une API permettant de contrôler le robot :<br /> ** fonctions pour contrôler les moteurs<br /> ** fonctions pour lire la distance du sonar<br /> ** fonctions pour lire l'information des suiveurs de ligne<br /> <br /> ''' Programme Python :'''<br /> * Développer un programme Python se servant de l'API pour transformer le robot en un suiveur de ligne. Il doit permettre au robot de s'arrêter en cas d'obstacle et redémarrer lorsque l'obstacle disparaît<br /> <br /> ==Choix techniques : matériel et logiciel==<br /> <br /> ''' - Robot : '''<br /> * Chassis : [https://www.gotronic.fr/art-chassis-magic-dg007-17268.htm Kit à assembler Magician chassis dg007]<br /> * [https://store.arduino.cc/arduino-uno-rev3 Arduino Uno]<br /> * Capteur de distance : [https://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm HC SR04]<br /> * Capteur optique suiveur de ligne : [https://fr.rs-online.com/web/p/capteurs-optiques-reflechissants/7613984/ QRE1113GR] x3<br /> * Contrôleur de moteur : [https://www.mouser.fr/ProductDetail/?qs=rsevcuukUAy2UalRuv4E%2fQ%3d%3d Toshiba TB6612FNG,C,8,EL] <br /> <br /> ''' - [https://www.numworks.com/fr/ Calculatrice NumWorks]'''<br /> <br /> ''' - Shield pour Arduino :''' Réalisation sur Eagle<br /> <br /> ''' - Communication :''' Modification de [https://github.com/numworks/epsilon l'OS Numworks] en C++ / C<br /> <br /> ''' - API et programme suivi de ligne : ''' Développés en Python<br /> <br /> <br /> &lt;gallery mode=&quot;nolines&quot; widths=300px heights=200px&gt;<br /> File:DG007.jpg| Magician chassis DG007<br /> <br /> File:TB6612FNGC8EL.jpg|Contrôleur de moteur TB6612FNG,C,8,EL<br /> <br /> File:Hc-sr04-ultrasonic-range-finder-2.png|Capteur de distance HC SR04<br /> <br /> File:QRE1113GR.jpg| Capteur optique QRE1113GR <br /> <br /> &lt;/gallery&gt;<br /> <br /> &lt;gallery mode=&quot;nolines&quot; widths=300px heights=200px center&gt;<br /> File:Arduino-uno-rev3-smd.jpg|Arduino Uno<br /> <br /> File:Numworks.jpg|Calculatrice Numworks<br /> &lt;/gallery&gt;<br /> <br /> ==Liste des tâches à effectuer==<br /> <br /> * Assembler le robot<br /> * Réaliser un shield pour l'Arduino<br /> * Modifier le logiciel de la calculatrice NumWorks pour établir la communication<br /> * Développer l'API<br /> * Développer le programme Python<br /> <br /> <br /> =Réalisation du Projet=<br /> ==Feuille d'heures==<br /> <br /> {| class=&quot;wikitable&quot;<br /> !Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Heures S12 !! Heures S13 !!Total<br /> |-<br /> | Analyse du projet <br /> | 5H<br /> | <br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> | 5H+<br /> |-<br /> | Recherches / documentation<br /> | <br /> | 12H<br /> | 6H<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> | 18H+<br /> |-<br /> | Conception du robot<br /> | <br /> | <br /> |<br /> |<br /> |<br /> |<br /> | 30min<br /> |<br /> |<br /> |<br /> | 1H<br /> |<br /> |<br /> | 3H<br /> | 4H30<br /> |-<br /> | Réalisation du shield <br /> | <br /> | <br /> |<br /> |<br /> |<br /> |<br /> | 16H30<br /> | 2H30<br /> | 7H<br /> | 2H<br /> | 2H<br /> | 8H<br /> | 4H<br /> |<br /> | 42H<br /> |-<br /> | Établissement de la communication<br /> | <br /> | <br /> | 3H<br /> | 6H<br /> | 6H<br /> | 9H<br /> | <br /> | 3H<br /> | 8H<br /> |<br /> | <br /> |<br /> | 3H30<br /> | 1H30<br /> | 40H<br /> |-<br /> | Développement de l'API<br /> | <br /> | <br /> |<br /> |<br /> |<br /> |<br /> |<br /> | <br /> |<br /> | 11H<br /> | 15H<br /> | 10H<br /> | 4H<br /> | 3H<br /> | 43H<br /> |-<br /> | Développement du programme Python<br /> | <br /> | <br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> |<br /> | 2H<br /> | 24H<br /> | 26H<br /> |}<br /> <br /> ==Prologue==<br /> ==Semaine 1==<br /> <br /> *''' Acquisition du matériel : '''<br /> <br /> Le matériel nécessaire à la conception du robot était déjà disponible. Récupération d'un kit à assembler pour construire un robot à deux roues, d'un Arduino Uno, d'un sonar ultrason, d'un contrôleur de moteur ainsi que de trois suiveurs de ligne. <br /> <br /> *''' Installation du SDK NumWorks : '''<br /> <br /> Ayant à modifier le logiciel de la calculatrice NumWorks afin de transformer la calculatrice en un périphérique USB hôte pour pouvoir contrôler le robot, j'ai installé le SDK fourni par l'éditeur qui offre un simulateur.<br /> <br /> On récupère dans un premier temps le code :<br /> <br /> git clone https://github.com/numworks/epsilon.git<br /> <br /> <br /> Avant de pouvoir lancer le simulateur, il faut installer de nombreuses dépendances :<br /> <br /> apt-get install bison build-essential dfu-util flex gcc-arm-none-eabi git libfltk1.3-dev libfreetype6-dev libpng12-dev<br /> <br /> Une fois les dépendances installées, on peut compiler :<br /> <br /> make PLATFORM=simulator clean<br /> make PLATFORM=simulator<br /> <br /> Puis on lance le simulateur par la commande :<br /> <br /> ./epsilon.elf<br /> <br /> [[Fichier:SimulateurNumWorks.png|center|vignette|300px|Simulateur NumWorks]]<br /> <br /> <br /> *''' Recherches / Documentation ''' :<br /> <br /> L'USB On-The-Go (OTG) est une spécification qui permet à un périphérique USB de se comporter comme un hôte ou un esclave selon la situation. Par exemple, cela permet à une tablette (qui est de base un périphérique esclave) de pouvoir communiquer avec un autre périphérique USB tel qu'une souris, un clavier en agissant comme périphérique hôte puis d'être esclave lorsque connecté à un ordinateur. Cette spécification OTG introduit un 5ème pin, le pin &quot;ID&quot;. Lorsque ce dernier est connecté à la masse, le périphérique est défini comme hôte par défaut. Si le pin n'est pas connecté, le périphérique est esclave par défaut.<br /> <br /> Le port USB de la calculatrice NumWorks n'étant censé être utilisé que pour recharger la calculatrice ou la mettre à jour, la calculatrice est un périphérique esclave. Cela est confirmé par le Schematics de la calculatrice sur lequel on voit que le pin ID de l'USB n'est pas connecté :<br /> <br /> <br /> [[Fichier:SchematicsUSB.png|center|vignette|700px| Schematics du port USB de la NumWorks]]<br /> <br /> <br /> Le micro-contrôleur STM32F412VGT6 utilisé est cependant compatible avec l'OTG d'après sa Datasheet et l'acronyme &quot;OTG&quot; apparaît à de nombreuses reprises dans le code du logiciel de la calculatrice NumWorks. Il faudra donc creuser dans ce sens pour faire de la calculatrice un hôte USB.<br /> <br /> ==Semaine 2==<br /> <br /> <br /> *''' Recherches / Documentation ''' :<br /> Recherche et lecture de documentation pouvant aider à l'établissement de la communication entre la calculatrice et le robot. On retiendra trois documents qui pourront nous aider:<br /> <br /> - [https://www.st.com/resource/en/user_manual/dm00105256.pdf Manuel d'utilisation de la librairie USB host du logiciel de développement des STM32 STM32Cube]<br /> <br /> - [https://www.st.com/resource/en/user_manual/cd00289278.pdf Manuel d'utilisation de la librairie USB On-The-Go des STM32F]<br /> <br /> - [https://www.st.com/resource/en/reference_manual/dm00180369.pdf Manuel de référence du STM32F412]<br /> <br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> Début de modification du logiciel de la calculatrice NumWorks afin d'en faire un hôte USB pour pouvoir contrôler le robot. Pour cela, le [https://www.st.com/resource/en/reference_manual/dm00180369.pdf manuel de référence du STM32F412] est une aide précieuse.<br /> <br /> Dans un premier temps, nous modifions les différents registres d'initialisation de l'USB OTG du micro-contrôleur. Cela se passe dans la fonction '''initOTG()''' du fichier '''/ion/src/device/usb.cpp'''.<br /> |<br /> |<br /> |<br /> Dans ce fichier, on s'aperçoit d'une ligne qui force l'USB à agir en tant qu'esclave :<br /> OTG.GUSBCFG()-&gt;setFDMOD(true);<br /> <br /> Pour forcer la calculatrice à apparaître comme un hôte USB, on modifie la ligne de la façon suivante :<br /> OTG.GUSBCFG()-&gt;setFHMOD(true);<br /> <br /> Le [https://www.st.com/resource/en/reference_manual/dm00180369.pdf manuel de référence du STM32F412] nous propose une démarche pour initialiser l'USB de la calculatrice en tant qu'hôte, nous la suivons donc. <br /> <br /> <br /> Il faut dans un premier temps initialiser le cœur. On active différents masques et interruptions à travers différents registres ainsi que les modes :<br /> <br /> - '''Host negotiation protocol (HNP)''' qui permet au cœur de changer dynamiquement son rôle de périphérique A-Host en A-esclave et inversement ou B-host en B-esclave.<br /> <br /> - '''Session request protocol (SRP)''' qui permet, lorsque la calculatrice est un hôte USB, d'économiser de l'énergie en éteignant le Vbus power si la session USB est suspendue <br /> <br /> <br /> On procède ensuite à l'initialisation du mode hôte. On active le port de contrôle et le registre de statut, on sélectionne le mode de vitesse supportée. Si un périphérique USB est détecté, on active le processus de reset sur le périphérique, on se règle sur sa vitesse et on configure la taille des queues FIFO pour l'échange des données.<br /> <br /> <br /> Il faudra ensuite procéder à l'initialisation d'un canal de communication pour que la calculatrice puisse échanger avec le robot.<br /> <br /> ==Semaine 3==<br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> <br /> Initialisation des channels : afin de pouvoir communiquer avec les périphériques connectés à l'hôte, en l’occurrence ici, l'Arduino à la calculatrice, il faut initialiser des canaux de communication. Pour cela, on active les canaux voulus à travers les registres, on active certaines interruptions et masques. Il faut finalement donner une taille au canal en fonction des paquets attendus ainsi que donner les caractéristiques du endpoint que l'Arduino présentera. <br /> <br /> Maintenant que l'initialisation a été modifié pour que la calculatrice apparaisse comme un hôte USB, il faut adapter les fonctions de communication. J'ai alors passé pas mal de temps à essayer de comprendre l'architecture du logiciel en terme de communication USB et chercher ce qu'il y a à modifier.<br /> <br /> ==Semaine 4==<br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> <br /> Après avoir passé du temps à essayer de trouver les modifications à apporter aux fonctions de communication USB du logiciel Numworks, j'ai découvert que STMicroelectronics propose des [https://www.st.com/content/st_com/en/products/embedded-software/mcus-embedded-software/stm32-embedded-software/stm32cube-mcu-packages/stm32cubef4.html bibliothèques] pour aider à la programmation de leurs microcontrôleurs. On trouve dans ces dernières des fonctions toutes faites pour la configuration de l'USB pour un mode hôte ou esclave. En plus de proposer des fonctions réalisant l'initialisation du core, du mode hôte et des canaux de communication comme j'ai pu le faire au cours des deux dernières semaines, ils proposent des fonctions de communication ainsi qu'une interface d'abstraction matérielle permettant de faciliter la portabilité. J'ai donc choisi d'utiliser ces bibliothèques plutôt que de continuer à réaliser les fonctions moi-même et de risquer de faire des erreurs qui seraient sûrement difficiles à trouver au moment des tests. Cela me permettra aussi probablement de gagner du temps. <br /> <br /> Après avoir programmé le logiciel Numworks pour utiliser la fonction d'initialisation de l'USB fournie par les bibliothèques STM, je suis confronté à un problème d'intégration au vu des erreurs apparaissant à la compilation.<br /> <br /> ==Semaine 5==<br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> <br /> - Résolution du problème de la semaine 4. La semaine dernière, en voulant intégrer les bibliothèques que propose STMicroelectronics j'ai été confronté à un problème à la compilation. Après avoir utilisé un type défini par les bibliothèques intégrées dans le code du logiciel Numworks afin de faire de la calculatrice un hôte USB, j'avais une erreur à la compilation qui m'indiquait que le type utilisé n'était pas défini bien que le fichier .h était lié. J'ai alors, dans un premier temps, pensé qu'il s'agissait d'un problème au niveau des makefile suite à l'ajout des bibliothèques. Finalement, en examinant le code des .h des bibliothèques STM, je me suis rendu compte qu'ils contenaient presque tous le code suivant :<br /> <br /> #if defined(STM32F405xx) || defined(STM32F415xx) || defined(STM32F407xx) || defined(STM32F417xx) || \<br /> defined(STM32F427xx) || defined(STM32F437xx) || defined(STM32F429xx) || defined(STM32F439xx) || \<br /> defined(STM32F401xC) || defined(STM32F401xE) || defined(STM32F411xE) || defined(STM32F446xx) || \<br /> defined(STM32F469xx) || defined(STM32F479xx) || defined(STM32F412Zx) || defined(STM32F412Vx) || \<br /> defined(STM32F412Rx) || defined(STM32F412Cx) || defined(STM32F413xx) || defined(STM32F423xx)<br /> <br /> Les bibliothèques proposées par STMicroelectronics sont communes à chacun de leurs microcontrôleurs. Cependant, ces derniers étant tous différents, il existe des différences au niveau des registres. Afin de pouvoir utiliser les bibliothèques, il faut donc définir le modèle de microcontrôleur utilisé dans un .h bien particulier. Sans cela, le '''if defined''' étant présent en tête de fichier et ne se fermant qu'à la fin, tout le contenu était ignoré. Après avoir défini l'utilisation du STM32F412VGT6 dans le .h adéquat, le problème de typage non reconnu à la compilation a été résolu.<br /> <br /> Après avoir inclus les nombreux .h différents nécessaires pour l'utilisation des fonctions d'initialisation du périphérique USB, j'ai été confronté à un autre problème :<br /> <br /> <br /> [[Fichier:Collisions.png|center|vignette|800px|Compilation suite à l'ajout des bibliothèques STM]]<br /> <br /> <br /> De nombreuses variables sont définies sous le même nom dans le logiciel Numworks et dans les bibliothèques STM mais sont utilisées différemment et dans deux langages (C++ pour Numworks, C pour bibliothèques STM). Des problèmes de collision apparaissent donc parmi d'autres à la compilation. Les variables en question étant utilisées dans de nombreux fichiers différents dont le code n'est pas forcément simple à comprendre sans l'étudier et y passer du temps, réadapter le code des bibliothèques à celui du logiciel demanderait beaucoup de temps. J'ai donc choisi de revenir sur la solution de départ et de réaliser les fonctions nécessaires moi-même en prenant appui sur ces bibliothèques.<br /> <br /> - J'ai donc dans un second temps, repris les fonctions d'initialisation créées au cours des semaines dernières pour les réutiliser et je les ai ajusté en fonction de l'implémentation que STMicroelectronics propose dans ses bibliothèques.<br /> <br /> ==Semaine 6==<br /> <br /> *''' Conception du robot ''' : <br /> <br /> Après avoir passé pas mal de temps sur l'établissement de la communication, j'ai décidé de laisser cela de côté pour cette semaine, j'y reviendrai plus tard. J'ai dans un premier temps assemblé le châssis du robot, chose relativement simple et rapide avec la notice fournie au kit. <br /> <br /> <br /> [[Fichier:Chassisassemble.jpg|center|thumb|500px|Châssis assemblé]]<br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Afin de réaliser un travail propre et qu'il n'y ait pas de fils dans tous les sens, il a été demandé de réaliser un shield pour l'arduino en y intégrant les différents composants utilisés. On intégrera à ce shield : <br /> <br /> - [https://www.pololu.com/file/0J86/TB6612FNG.pdf Le contrôleur de moteur TB6612FNG]<br /> <br /> - Des headers permettant de connecter les deux moteurs au contrôleur<br /> <br /> - [https://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm Le capteur de distance HC SR04]<br /> <br /> La batterie sera connectée au robot par le shield avec des fils. <br /> <br /> Les capteurs optiques suiveurs de lignes devant se trouver sous le robot pour être utiles, nous réaliserons un autre PCB pour ces derniers.<br /> <br /> <br /> J'ai décidé de réaliser ces cartes électroniques avec le logiciel [https://www.autodesk.com/products/eagle/overview Eagle], notamment parce qu'il est disponible sous Linux contrairement à Altium. Après avoir procédé à l'installation du logiciel, j'ai recherché des librairies Eagle proposant les composants dont j'ai besoin : <br /> <br /> - Librairie [https://github.com/sparkfun/SparkFun-Eagle-Libraries SparkFun-Boards] pour le template de shield Arduino Uno<br /> <br /> - Librairie [http://www.diymodules.org/eagle-show-object?type=dm&amp;file=diy-modules.lbr&amp;device=ULTRASONIC-HC-SR04 diy-modules] pour le capteur de distance HC SR04<br /> <br /> - Librairie [https://www.snapeda.com/parts/TB6612FNG,C,8,EL/Toshiba/view-part/ TB6612FNG,C,8,EL] pour le contrôleur de moteur TB6612FNG<br /> <br /> - Librairie [https://github.com/chiengineer/Eagle-Libraries/tree/master/Connectors con-headers-jp] pour les headers femelles<br /> <br /> - Librairie [https://github.com/sparkfun/SparkFun-Eagle-Libraries SparkFun-PowerSymbols] pour le 5V et la masse<br /> <br /> <br /> &lt;gallery mode=&quot;nolines&quot; widths=300px heights=200px&gt;<br /> File:Shieldtemplate.png|Template shield Arduino Uno<br /> <br /> File:HCSR04.png|Capteur de distance HC SR04<br /> <br /> File:Controleurmoteurv2.png|Contrôleur de moteur TB6612FNG<br /> &lt;/gallery&gt;<br /> <br /> <br /> J'ai ensuite cherché à savoir comment connecter les différents composants entre eux puis procédé à la réalisation du schematics et du PCB associé : <br /> <br /> <br /> [[Fichier:Schematicsshield2.png|center|thumb|800px|Schematic du shield]]<br /> <br /> <br /> [[Fichier:PCBShield2.png|center|thumb|2000px|PCB du shield]]<br /> <br /> ==Semaine 7==<br /> <br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Les capteurs de ligne devant se trouver en dessous du robot pour être utilisables, j'ai réalisé une seconde carte électronique afin de minimiser le nombre de fils de connexion sur le robot. Cette carte ne comporte que des capteurs suiveurs de ligne ainsi qu'un header pour lier cette dernière au shield.<br /> <br /> Pour réaliser cette carte, j'ai utilisé la librairie [https://www.snapeda.com/parts/QRE1113GR/Fairchild%20Semiconductor/view-part/ QRE1113GR] qui fourni la footprint du capteur optique QRE1113GR utilisé :<br /> <br /> <br /> [[Fichier:QRE1113GRfootprint.png|center|thumb|800px|Footprint du capteur optique QRE1113GR]]<br /> <br /> <br /> Le schematic de la carte est le suivant : <br /> <br /> [[Fichier:SchematicCapteurs.png|center|thumb|800px|Schematic de la carte de capteurs optiques pour le suivi de ligne]]<br /> <br /> <br /> Finalement, le PCB associé : <br /> <br /> <br /> [[Fichier:PCBCapteurs.png|center|thumb|800px|PCB de la carte de capteurs optiques pour le suivi de ligne]]<br /> <br /> <br /> <br /> <br /> *''' Retour de soutenance intermédiaire ''' :<br /> <br /> Suite à la soutenance intermédiaire, les objectifs du projet ont évolué. La modification du logiciel de la calculatrice Numworks étant possible mais demandant beaucoup de temps, cette tâche est abandonnée. A la place, nous utiliserons une solution déjà existante de communication en pur série avec l'Arduino : https://zardam.github.io/post/numworks-uart-over-usb/<br /> <br /> Les objectifs sont donc désormais les suivants : <br /> <br /> - Robot comme demandé initialement<br /> <br /> - Mettre en place un protocole de communication série pour que la calculatrice puisse<br /> utiliser les capteurs et les actionneurs du robot<br /> <br /> - Réaliser un câble propre pour la connexion entre la calculatrice NumWorks (port micro USB) et l'Arduino (E/S 0 et 1, masse)<br /> <br /> - Développer une API python simple pour qu'un lycéen puisse utiliser le robot<br /> <br /> - Développer un exemple de programme python sur la NumWorks pour utiliser le robot comme un suiveur de ligne avec arrêt en présence d'obstacles (sujet original)<br /> <br /> - Réaliser un démonstrateur de programmation de l'Arduino par la NumWorks : Ajout d'un capteur de température DHT22 sur le robot, saisie de codes assembleur ATMega328p (hexa) sur la Numworks pour la gestion du capteur (un code d'initialisation et un code de récupération de valeur), envoi des deux codes par série sur l'Arduino puis utilisation de ceux-ci.<br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> <br /> La communication entre la calculatrice Numworks et l'Arduino doit donc désormais se faire en série grâce à la solution https://zardam.github.io/post/numworks-uart-over-usb/<br /> <br /> L'auteur de cette solution a mappé un UART sur les ports D+ et D- de l'USB en modifiant le logiciel Numworks. La communication série est ainsi possible en utilisant le port USB de la calculatrice.<br /> <br /> ==Semaine 8==<br /> <br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Suite à l'évolution des objectifs, j'ai été amené à réaliser quelques modifications sur le PCB. Le capteur de température DHT22 a été ajouté, une réorganisation des connexions a été mené afin de permettre un routage plus simple et plus propre et enfin, étant donné que deux digital pins étaient libres sur l'Arduino, deux LEDs ont été ajouté et pourront notamment servir au débogage.<br /> <br /> Étant donné que le capteur de température est plus une option qu'autre chose sur le robot, plutôt que d'utiliser directement sa footprint et le souder par la suite, nous utiliserons un header. Ainsi, il pourra être enlevé et remis à souhait.<br /> <br /> Le nouveau schématic est le suivant : <br /> <br /> <br /> [[Fichier:SchShieldfinalmcreteur.png|center|thumb|1200px|Schematic final du shield Arduino]]<br /> <br /> <br /> Le PCB associé :<br /> <br /> [[Fichier:Shieldv2PCB.png|center|thumb|1200px|PCB du shield Arduino]]<br /> <br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> <br /> Afin que la calculatrice et l'Arduino puissent se comprendre lors de l'échange des messages, il faut définir un protocole de communication. La calculatrice doit pouvoir faire comprendre à l'Arduino les différentes commandes qu'elle veut faire exécuter, par exemple, ordonner au robot de tourner sur la gauche. Dans l'autre sens, la calculatrice doit pouvoir comprendre et interpréter les valeurs des capteurs que l'Arduino lui enverra. <br /> <br /> Nous pensons définir un message comme suit :<br /> <br /> - Caractère de début de message<br /> <br /> - Taille du message <br /> <br /> - Commande représentée par un chiffre (Par exemple, lorsque l'on enverra 1, le robot devra avancer tout droit). OU chiffre signifiant réponse de capteur<br /> <br /> - Paramètre de commande si nécessaire OU valeur de capteur<br /> <br /> - Checksum pour vérifier la bonne réception du message<br /> <br /> La taille d'un message et le type de données échangées n'a pas encore été décidé. D'ailleurs, concernant le type de données échangées, une API de communication série Python a été développé par l'auteur de la modification du logiciel Numworks. Cette dernière propose deux fonctions pour l'envoi et la réception qui ont été implémenté comme suit : <br /> <br /> mp_obj_t writeLine(mp_obj_t a) {<br /> Ion::Console::writeLine(mp_obj_str_get_str(a));<br /> return mp_const_none;<br /> }<br /> <br /> mp_obj_t readLine() {<br /> Ion::Console::readLine(line, 64);<br /> return mp_obj_new_str(line, strlen(line), false);<br /> }<br /> <br /> Ces deux dernières ayant été implémenté pour réaliser un tchat entre deux calculatrices Numworks, elles travaillent avec des String. Nous verrons si nous décidons d'utiliser ces dernières ou si il est plus judicieux de modifier les types utilisés.<br /> <br /> ==Semaine 9==<br /> <br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Modifications sur les cartes compte tenue des remarques des encadrants. Principalement : <br /> <br /> - Connexion des AO1/AO1, BO1/BO1, AO2/AO2, BO2/BO2 du contrôleur moteur afin de limiter le courant dans chacune des broches du circuit<br /> <br /> - Ajout d'un plan de masse sur chacune des cartes (améliorant le routage)<br /> <br /> - Déplacement/rotation de certains composants<br /> <br /> - Élargissement des pistes<br /> <br /> [[Fichier:PCBShieldfinalmcreteur.png|center|thumb|1200px|PCB final du shield Arduino]]<br /> <br /> <br /> [[Fichier:PCBAnnexefinalmcreteur.png|center|thumb|1200px|PCB final de la carte de suiveurs de ligne]]<br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot''' :<br /> <br /> La communication entre la calculatrice et le robot se fera par échange de string. Une trame se composera comme suit : <br /> <br /> {| class=&quot;wikitable&quot; style=&quot;width:100%;text-align:center&quot;<br /> ! style=&quot;padding: 5px;&quot;| <br /> Information<br /> | Char de début de trame<br /> | Commande<br /> | Paramètres<br /> | Checksum<br /> | Char de fin de trame<br /> |-<br /> ! style=&quot;padding: 5px;&quot; | <br /> Nombre de Char<br /> | 1<br /> | 2<br /> | 3<br /> | 3<br /> | 1<br /> |-<br /> |}<br /> <br /> Cette trame a plutôt été pensé pour l'envoi de commande de la calculatrice vers l'Arduino (implémentée cette semaine), nous nous préoccuperons de la réponse lors de la semaine 10. Le champ paramètre n'est là qu'au cas ou et sera peut-être amené à disparaître pour l'envoi de commande. Pour la réponse, nous pourrions préciser le type de capteur à la place dans le champs Commande et la valeur du capteur en question dans le champs Paramètre ou alors constituer une trame contenant la valeur de tous les capteurs (à réfléchir).<br /> <br /> <br /> Une commande sera donc représentée par deux Char. La liste des commandes avec l'expression en Char est la suivante : <br /> <br /> - LED1 : &quot;01&quot; (Allumer la LED1)<br /> <br /> - LED2 : &quot;02&quot; (Allumer la LED2)<br /> <br /> - MOVE_FORWARD : &quot;10&quot; (Avancer)<br /> <br /> - MOVE_BACKWARD : &quot;11&quot; (Reculer)<br /> <br /> - MOVE_RIGHT : &quot;12&quot; (Tourner à droite)<br /> <br /> - MOVE_LEFT : &quot;13&quot; (Tourner à gauche)<br /> <br /> - STOP : &quot;05&quot; (Arrêter le robot)<br /> <br /> - GET_DISTANCE : &quot;06&quot; (Demander la valeur indiquée par le capteur de distance)<br /> <br /> - GET_LINEFOLLOWER : &quot;07&quot; (Demander les valeurs indiquées par les capteurs optiques)<br /> <br /> - GET_TEMP : &quot;08&quot; (Demander la valeur indiquée par le capteur de température)<br /> <br /> <br /> <br /> *''' Développement de l'API ''' :<br /> <br /> La calculatrice permet le développement Python grâce à MicroPython qui est une version de Python pour l'embarqué. Le développement d'une API se fait directement dans le code source MicroPython en C/C++. En plus d'écrire l'API dans un fichier .c ou .cpp comme on le fait traditionnellement, il faut modifier différents fichiers afin que MicroPython puisse reconnaître l'API et les différentes fonctions implémentées ainsi que permettre l'import du module développé. <br /> <br /> <br /> J'ai choisi de nommer l'API &quot;robot&quot;. Il faut écrire un fichier .c définissant la structure du nouveau module : <br /> <br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(led1_obj, led1);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(led2_obj, led2);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(moveForward_obj, moveForward);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(moveBackward_obj, moveBackward);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(moveLeft_obj, moveLeft);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(moveRight_obj, moveRight);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(stop_obj, stop);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(getDistanceSensorValue_obj, getDistanceSensorValue);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(getTemperatureSensorValue_obj, getTemperatureSensorValue);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(getLineFollowerSensor1Value_obj, getLineFollowerSensor1Value);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(getLineFollowerSensor2Value_obj, getLineFollowerSensor2Value);<br /> STATIC MP_DEFINE_CONST_FUN_OBJ_0(getLineFollowerSensor3Value_obj, getLineFollowerSensor3Value);<br /> <br /> STATIC const mp_rom_map_elem_t robot_module_globals_table[] = {<br /> { MP_ROM_QSTR(MP_QSTR___name__), MP_ROM_QSTR(MP_QSTR_robot) },<br /> { MP_ROM_QSTR(MP_QSTR_led1), (mp_obj_t)&amp;led1_obj },<br /> { MP_ROM_QSTR(MP_QSTR_led2), (mp_obj_t)&amp;led2_obj },<br /> { MP_ROM_QSTR(MP_QSTR_moveForward), (mp_obj_t)&amp;moveForward_obj },<br /> { MP_ROM_QSTR(MP_QSTR_moveBackward), (mp_obj_t)&amp;moveBackward_obj },<br /> { MP_ROM_QSTR(MP_QSTR_moveLeft), (mp_obj_t)&amp;moveLeft_obj },<br /> { MP_ROM_QSTR(MP_QSTR_moveRight), (mp_obj_t)&amp;moveRight_obj },<br /> { MP_ROM_QSTR(MP_QSTR_stop), (mp_obj_t)&amp;stop_obj },<br /> { MP_ROM_QSTR(MP_QSTR_getDistanceSensorValue), (mp_obj_t)&amp;getDistanceSensorValue_obj },<br /> { MP_ROM_QSTR(MP_QSTR_getTemperatureSensorValue), (mp_obj_t)&amp;getTemperatureSensorValue_obj },<br /> { MP_ROM_QSTR(MP_QSTR_getLineFollowerSensor1Value), (mp_obj_t)&amp;getLineFollowerSensor1Value_obj },<br /> { MP_ROM_QSTR(MP_QSTR_getLineFollowerSensor2Value), (mp_obj_t)&amp;getLineFollowerSensor2Value_obj },<br /> { MP_ROM_QSTR(MP_QSTR_getLineFollowerSensor3Value), (mp_obj_t)&amp;getLineFollowerSensor3Value_obj }<br /> };<br /> <br /> STATIC MP_DEFINE_CONST_DICT(robot_module_globals, robot_module_globals_table);<br /> const mp_obj_module_t robot_module = {<br /> .base = { &amp;mp_type_module },<br /> .globals = (mp_obj_dict_t*)&amp;robot_module_globals,<br /> };<br /> <br /> <br /> Ce fichier permet de définir le module MicroPython à travers une structure de type '''mp_obj_module_t'''. On définit d'abord les différentes fonctions du module sous forme d'objet. On remplit ensuite un dictionnaire avec les différentes fonctions implémentées. Finalement, on initialise les différents champs de la structure qui représentera l'API en lui précisant notamment le dictionnaire contenant les objets de fonction créés.<br /> <br /> Afin de permettre l'import de l'API dans un futur code d'utilisation Python, on modifie le fichier '''mpconfigport.h''' en y ajoutant la ligne suivante dans la définition des '''MICROPY_PORT_BUILTIN_MODULES''' : <br /> { MP_ROM_QSTR(MP_QSTR_robot), MP_ROM_PTR(&amp;robot_module) }<br /> <br /> Afin d'ajouter la reconnaissance par MicroPython des fonctions implémentées dans notre API et de son nom, il faut modifier le fichier '''qstrdefsport.h'''. Dans notre cas, on y ajoute les lignes suivantes :<br /> Q(robot)<br /> Q(led1)<br /> Q(led2)<br /> Q(moveForward)<br /> Q(moveBackward)<br /> Q(moveLeft)<br /> Q(moveRight)<br /> Q(stop)<br /> Q(getDistanceSensorValue)<br /> Q(getTemperatureSensorValue)<br /> Q(getLineFollowerSensor1Value)<br /> Q(getLineFollowerSensor2Value)<br /> Q(getLineFollowerSensor3Value)<br /> <br /> MicroPython sera alors capable de reconnaître par exemple que led1 correspond à une fonction définie.<br /> <br /> Finalement, on implémente l'API dans un fichier .cpp ou .c comme on le fait traditionnellement. <br /> <br /> Cette semaine, j'ai écrit une fonction pour le calcul du checksum qui réalise la somme de tous les chars de la trame. Le checksum sera représenté par 3 chars. <br /> <br /> J'ai ensuite écrit une fonction de formation de la trame à envoyer. Cette dernière prend en paramètre la string de deux chars représentant la commande à réaliser ainsi qu'une string de 3 chars représentant les paramètres de commande à associer. Elle réalise alors une string en plaçant en première position un 'S' indiquant le début de trame, en plaçant ensuite la commande, les paramètres, le checksum en faisant appel à la fonction de calcul de checksum puis termine par le caractère de fin de trame 'E'.<br /> <br /> J'ai finalement défini les fonctions de commande '''led1(), led2(), moveForward(), moveBackward(), moveRight(), moveLeft() et stop()''' qui font appel à la fonction de construction de trame en précisant la commande associée et écrivent sur le port série grâce à la fonction '''writeLine(mp_objet_t objet)''' implémentée par Zardam.<br /> <br /> Ainsi, pour demander au robot d'avancer, la string envoyée sera la suivante : '''S13000417E'''<br /> <br /> <br /> Lors de l'écriture des différentes fonctions, j'ai été confronté à un des principaux enjeux de l'embarqué : l'optimisation des ressources. La calculatrice présentant un stockage disponible assez faible, les fonctions des librairies standards du langage C non utilisées ont été supprimé afin de d'occuper le moins d'espace possible. Par exemple, la fonction '''strcat''' de la librairie '''&lt;string.h&gt;''' n'est pas disponible, j'ai alors dû trouver des alternatives.<br /> <br /> ==Semaine 10==<br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Les cartes n'ont pas pu être gravées cette semaine. J'ai eu un retour de Monsieur Flamen vendredi qui m'a indiqué qu'il était impossible de les graver du fait d'une isolation trop faible des pistes par rapport au plan de masse. Si elles avaient été gravé, il y aurait eu des courts circuits partout. J'ai alors modifié ces dernières et j'ai fixé l'isolation des pistes par rapport au plan de masse à 12 mil qui est le minimum à respecter. J'ai été confronté à un problème suite à cette modification sur la carte du shield. Avec une isolation de 12 mil, le plan de masse ne peut pas recouvrir toute la carte et certaines zones de masse sont des zones &quot;orphelines&quot; c'est à dire, non reliées au reste du plan de masse. Ne voyant pas d'autre solution et avec les conseils de Monsieur Flamen, j'ai ajouté des vias pour réaliser la connexion entre les différentes zones de masse. Une fois la carte gravée, ces zones seront alors connectées par un fil sur la face top. <br /> <br /> <br /> *''' Conception du robot''' : <br /> <br /> Ayant avancé sur la partie programmation de la calculatrice et de l'Arduino, il me fallait réaliser le câble de connexion pour relier les deux afin de pouvoir réaliser des tests et voir si la programmation réalisée est fonctionnelle ou non. Utilisant une communication série, il me fallait un câble qui puisse être branché d'un côté sur le port micro-USB de la Numworks et de l'autre, sur le port série de l'Arduino. Ce type de câble n'existant pas à ma connaissance, j'ai pris un câble USB - micro-USB dont j'ai coupé la partie USB puis j'ai extrait les quatre fils (GND, VCC, Data+ et Data-) en dénudant.<br /> <br /> <br /> [[Fichier:USBwire.png|center|thumb|1200px|Fils d'un câble USB]]<br /> <br /> <br /> J'ai ensuite soudé un fil de connexion mâle-mâle sur chacun des fils afin de pouvoir les connecter à l'Arduino plus aisément. Enfin, j'ai ajouté de la gaine thermorétractable afin d'avoir un rendu plus propre et plus solide. Je peux désormais établir une connexion série entre la Numworks et l'Arduino avec ce câble en connectant :<br /> <br /> - Le fil vert D- sur Tx<br /> <br /> - Le fil blanc D+ sur Rx<br /> <br /> - Le fil noir GND sur GND<br /> <br /> Le fil rouge Vcc ne sera pas utilisé car la calculatrice ne nécessite pas d'alimentation.<br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot / Développement de l'API''' :<br /> <br /> Ayant écrit les fonctions de l'API Numworks permettant de contrôler les leds et les moteurs la semaine dernière, je me suis occupé cette semaine de la partie Arduino afin de pouvoir commencer à réaliser des tests et voir si l'on arrive bien à communiquer entre l'Arduino et la calculatrice. <br /> <br /> - Setup() : Indication Output ou Input pour chaque pin selon le schematic du shield. Baudrate à 115200 car c'est celui utilisé par la Numworks. <br /> <br /> - Réalisation d'une fonction de lecture de trame reçue. Tant que l'on reçoit des caractères et que l'on a pas lu le caractère de fin de trame 'E', on les stocke dans un tableau de Char.<br /> <br /> - Écriture d'une fonction de découpage de la trame. Afin de faciliter son implémentation, j'ai modifié le format des trames en ajoutant un caractère de séparation '-' entre chaque type de donnée. Les trames sont désormais de la forme : '''S-01-000-573-E'''. On utilise alors la fonction strtok pour stocker la commande reçue (dans la trame précedente : &quot;01&quot;), les paramètres (&quot;000&quot;) et le checksum (&quot;573&quot;) en ayant pris soin de vérifier que le premier caractère de la trame est bien 'S'.<br /> <br /> - Écriture d'une fonction de vérification du checksum. On renvoie True ou False selon que la somme des caractères de la trame (sans le checksum) est égale au checksum de la trame ou non<br /> <br /> - Écriture d'une fonction de traitement de la commande reçue. Si le checksum de la trame est correct, on exécute la commande associée à l'ordre reçu.<br /> <br /> - Écriture de la fonction principale loop(). On lit la trame, on la découpe et on exécute la commande demandée.<br /> <br /> <br /> Une fois le programme Arduino écrit, j'ai ajouté un script de test dans la Numworks pour ne pas avoir à le réécrire à chaque fois. Pour cela, il y a plusieurs fichiers de l'OS epsilon à modifier. <br /> <br /> On définit le script dans le fichier '''epsilon/apps/code/script_template.cpp''' :<br /> <br /> const ScriptTemplate * ScriptTemplate::TestRobot() {<br /> return &amp;testRobotScriptTemplate;<br /> }<br /> <br /> constexpr ScriptTemplate testRobotScriptTemplate(&quot;test_robot.py&quot;, R&quot;(import robot<br /> def test1():<br /> robot.led1()&quot;);<br /> <br /> Dans ce script de test, on exécute la fonction led1() qui envoie à l'Arduino une demande d'allumage de la LED déjà présente sur l'Arduino (Pin 13), en utilisant la nouvelle API 'robot'.<br /> <br /> On ajoute alors un attribut à la classe '''ScriptTemplate''' du fichier '''epsilon/apps/code/script_template.h''' :<br /> <br /> static const ScriptTemplate * TestRobot();<br /> <br /> Enfin, on rend accessible le script grâce à la fonction addScriptFromTemplate dans le fichier '''epsilon/apps/code/script_store.cpp'''<br /> <br /> addScriptFromTemplate(ScriptTemplate::TestRobot());<br /> <br /> Le script de test est désormais disponible dans l'application Python de la Numworks sous le nom : '''test_robot.py'''. Il n'y a plus qu'a exécuter le script et appeler la fonction définie dans ce dernier.<br /> <br /> <br /> Après cela, j'ai pu tester la communication entre la Numworks et l'Arduino. Dans un premier temps, l’exécution du script sur la calculatrice provoquait un arrêt de celle-ci qu'elle soit connectée ou non à l'Arduino. La seule solution pour récupérer le contrôle de la calculatrice était alors le bouton reset. J'ai alors pensé à un problème mémoire. Utilisant des mallocs dans l'implémentation de l'API, j'ai vérifié s'il n'y avait pas de fuite mémoire grâce à Valgrind. Ce n'était pas le cas, l'utilitaire n'indiquait aucun problème. Finalement, le problème venait d'une mauvaise utilisation des types MicroPython lors de l'écriture sur le port série grâce à la fonction WriteLine(mp_objet_t objet). Après avoir corrigé ce problème, j'ai pu vérifier le bon fonctionnement de la communication. Lors de l'exécution du script, la LED de l'Arduino s'allume bien.<br /> <br /> ==Semaine 11==<br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Les cartes ont été gravées. Tous les composants ont été soudé. J'ai passé pas mal de temps sur la soudure des headers qui ne prenait pas. Je remercie d'ailleurs M Flamen pour l'aide ainsi que la solution qu'il m'a apporté. Après avoir essayé lui même, il s'est résolu à apporter de l'ancien étain de chez lui qui a été beaucoup plus efficace et a finalement permis de souder les composants traversants.<br /> <br /> <br /> &lt;gallery mode=&quot;packed&quot; widths=300px heights=300px&gt;<br /> <br /> File:Shieldmcreteur.png|Shield après soudures<br /> <br /> File:SuiveurLignemcreteur.png|Carte de suiveurs de ligne après soudures<br /> <br /> &lt;/gallery&gt;<br /> <br /> <br /> Une fois les soudures réalisées, j'ai pu tester les deux cartes. <br /> <br /> Le shield ne semble pas fonctionner, lors de l'ajout de ce dernier à l'Arduino, il n'est plus possible de téléverser de programme, l'Arduino ne répond plus : <br /> <br /> <br /> [[Fichier:ErreurShield.png|center|thumb|600px|Arduino ne répondant plus après ajout du shield]]<br /> <br /> <br /> Cela provient probablement d'un court-circuit sur le shield apparu lors des soudures. La résolution de ce problème sera l'objectif principal de la semaine prochaine.<br /> <br /> Quant à la carte de suiveurs de lignes, elle est fonctionnelle en la connectant directement à l'Arduino, je suis capable de récupérer les valeurs renvoyées par les différents capteurs.<br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot / Développement de l'API''' :<br /> <br /> Cette semaine, je me suis occupé de la partie échange de valeurs des capteurs. Je garde au final le même format de trame pour la réponse, la valeur du capteur en question occupera le champs &quot;paramètre&quot; qui ne servait pas jusqu'à maintenant. Dans un premier temps, du côté de l'Arduino, j'ai ajouté : <br /> <br /> - Une fonction de formation de la trame de réponse qui est sensiblement la même que celle écrite pour l'envoi de commande sur la Numworks. La différence notable est qu'elle prend ici en paramètre la valeur du capteur à envoyer.<br /> <br /> - Une fonction de calcul de checksum qui est la même que celle utilisée pour l'envoi de commande sur la Numworks<br /> <br /> - Une fonction pour les suiveurs de ligne qui récupère la valeur du capteur, la donne à la fonction de formation de réponse puis envoie la réponse sur le port série. La récupération de la valeur du capteur se fait juste par lecture du pin analogique associé au capteur suiveur de ligne voulu.<br /> <br /> - Une fonction pour le capteur de distance qui récupère la valeur du capteur, la donne à la fonction de formation de réponse puis envoie la réponse sur le port série. Pour récupérer la valeur du capteur de distance, il faut d'abord envoyer une pulsation sur TRIGGER pour lancer une mesure. Un ultrason est alors lancé et est réfléchit par l'obstacle si il y en a un avant de revenir au capteur. La valeur lue sur le pin ECHO est alors le temps mis par l'onde pour aller jusqu'à l'obstacle puis revenir. On divise donc cette valeur par deux puis on utilise la relation d = v*t pour finalement avoir la distance séparant le robot de l'obstacle.<br /> <br /> - Ajout de la prise en compte des demandes de valeur du capteur de distance ou des suiveurs de ligne dans la fonction de traitement de la commande reçue.<br /> <br /> Les fonctions citées précédemment permettent bien d'envoyer une réponse valide sur le port série. Il faudra par contre vérifier si la lecture des capteurs est correcte une fois que le shield sera utilisable.<br /> <br /> Dans un second temps, j'ai ajouté sur la Numworks : <br /> <br /> - Une fonction de lecture de trame. Pour lire sur le port série, on utilise la fonction implémentée par Zardam readLine(). On définit alors une variable globale pour le stockage de la trame que l'on remplit en récupérant la chaîne de caractères qui arrive sur le port série '''mp_obj_str_get_str(readLine())'''<br /> <br /> - Une fonction de découpage de la réponse reçue. Contrairement à la fonction de parsing implémentée sur l'Arduino, je n'ai pas pu utiliser '''strtok''' pour le découpage, cette fonction n'étant pas présente dans epsilon. La fonction '''strchr''' est par contre disponible et c'est cette dernière qui m'a permis de réaliser le parsing. En localisant les caractères de délimitation ''' '-' ''' par '''strchr''', je peux déplacer le pointeur sur le caractère suivant et ainsi récupérer les caractères qui m'intéressent avec '''strlcpy'''.<br /> <br /> - Une fonction de récupération de la valeur du capteur de distance. Dans un premier temps, on envoie à l'Arduino la trame demandant la valeur du capteur de distance grâce aux fonctions implémentées lors des semaines précédentes. Une fois la demande envoyée, on utilise la fonction de lecture puis de parsing pour récupérer la valeur demandée. La valeur récupérée étant sous forme de string, on utilise la fonction '''atoi''' pour obtenir la valeur en int. Finalement, on renvoi la valeur sous forme d'entier MicroPython : '''return mp_obj_new_int(value);'''<br /> <br /> - Une fonction de récupération pour chaque capteur suiveur de ligne qui fonctionne exactement de la même façon que la fonction pour le capteur de distance.<br /> <br /> Il faudra ajouter à la lecture des réponses une fonction de vérification du checksum. <br /> <br /> Après avoir implémenté toutes les fonctions citées précédemment, j'ai pu les tester en définissant moi-même une valeur de capteur. La demande est bien envoyée à l'Arduino qui répond correctement suivant le capteur voulu. La Numworks est bien capable d'isoler la valeur désirée dans la trame reçue est de la renvoyer.<br /> <br /> J'ai passé pas mal de temps sur l'écriture des fonctions du coté de la Numworks par rapport à l'utilisation rigoureuse des types MicroPython et à la difficulté de réaliser des tests ainsi que de débugger.<br /> <br /> ==Semaine 12==<br /> <br /> *''' Réalisation du shield''' :<br /> <br /> Le problème du shield a été résolu. Un court-circuit se trouvait sur Rx ce qui expliquait la non communication entre l'Arduino et le PC ou la Numworks après l'ajout du shield. Le shield fonctionne désormais correctement.<br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot / Développement de l'API''' :<br /> <br /> J'ai ajouté le contrôle du checksum lorsqu'une réponse est reçue sur la Numworks. L'algorithme est le même que sur l'Arduino, on somme tous les caractères de la trame reçue excepté le checksum puis on vérifie si c'est égal au checksum contenu dans la trame reçue. <br /> <br /> <br /> Maintenant que le shield est fonctionnel, j'ai pu tester si les différents composants fonctionnaient correctement ainsi que les fonctions implémentées de traitement des données des capteurs. J'ai alors été confronté à un problème lors de l'utilisation du capteur de distance. Lorsque j'utilisais la fonction implémentée en demandant une lecture de capteur de distance à partir de la calculatrice, j'obtenais tout le temps une valeur nulle. En revanche, lorsque j'utilisais la fonction implémentée dans un programme à part sur l'Arduino, les valeurs reçues étaient correctes. Après avoir passé quelques heures à chercher la cause du problème, je me suis rendu compte qu'il était causé par une double utilisation de la fonction pinMode dans deux modes différents pour un des pins du capteur de distance.<br /> <br /> <br /> Une fois que l'utilisation de chacun des composants du robot était fonctionnelle, j'ai tenté de réaliser plusieurs échanges à la suite entre l'Arduino et la Numworks dans l'optique de développer le programme de suivi de lignes. Par exemple, en écrivant un script Python demandant au robot d'avancer puis de s'arrêter lorsqu'il se trouve à moins de 100 mm d'un obstacle :<br /> <br /> import robot<br /> def test():<br /> robot.moveForward()<br /> while(1):<br /> if (robot.getDistanceSensorValue() &lt;= 100):<br /> robot.stop() <br /> break<br /> <br /> Je me suis alors rendu compte qu'il était impossible d'effectuer deux échanges à la suite entre l'Arduino et la Numworks, avant même que l'Arduino n'avait traité la première commande, la Numworks avait déjà envoyé la suivante ce qui provoquait une incompréhension entre les deux. Pour résoudre ce problème, j'ai décidé de mettre en place une validation du traitement d'une commande reçue. Sur l'Arduino, lorsqu'une commande à effectuer ne nécessite pas de réponse pour la Numworks, par exemple, la commande de moteurs ou de led, l'Arduino envoie désormais &quot;OK&quot; à la Numworks lorsque la commande a été traité. Du côté de la Numworks, lorsque l'on demande à l'Arduino de réaliser une action ne nécessitant pas de réponse, on attend d'avoir reçu la validation &quot;OK&quot; par l'Arduino avant de retourner. Ainsi, la Numworks attend désormais que l'Arduino ait traité la commande avant d'en envoyer une autre, il n'y a plus de problème de synchronisation. <br /> <br /> <br /> <br /> *''' Développement du programme Python ''' :<br /> <br /> Une fois qu'il eut été possible de chaîner les échanges, j'ai tenté d'établir le programme exemple de suivi de lignes avec arrêt en cas d'obstacle. Avant même d'arriver bien loin dans l'implémentation de ce dernier, je me suis rendu compte que le temps de traitement des échanges allait être un problème pour le suivi de ligne. J'ai alors modifié les fonctions moteurs sur l'Arduino pour que le robot se déplace lentement et ainsi avoir plus de temps pour traiter les informations échangées. Cependant, cela risque de ne pas suffire, en utilisant le script mentionné plus haut pour la détection d'obstacle, le robot qui est censé s'arrêter lorsqu'un obstacle se trouve à 10cm de lui, ne s'arrête qu'à 2 ou 3 cm de l'obstacle.<br /> <br /> ==Semaine 13==<br /> <br /> *''' Conception du robot''' :<br /> <br /> Réalisation manuelle d'un support en bois pour la calculatrice afin de pouvoir la poser sur le robot : <br /> <br /> [[Fichier:supportNumworks.jpg|center|thumb|500px|Support pour la Numworks]]<br /> <br /> <br /> Il s'avère cependant que le support réalisé est assez lourd et gêne le déplacement du robot par son poids.<br /> <br /> <br /> *''' Établissement de la communication entre la calculatrice et le robot / Développement de l'API''' :<br /> <br /> Suite au problème rencontré de la lenteur des échanges d'information entre la calculatrice et le robot, j'ai revu la façon de récupérer les valeurs des capteurs. On envoyait jusqu'à présent une trame par capteur. Afin de réduire un peu les échanges, j'ai implémenté une nouvelle commande qui demande la valeur de tous les capteurs. L'Arduino renvoie alors la valeur du capteur de distance et des trois suiveurs de ligne dans une seule trame de réponse constituée comme suit : <br /> <br /> {| class=&quot;wikitable&quot; style=&quot;width:100%;text-align:center&quot;<br /> ! style=&quot;padding: 5px;&quot;| <br /> Information<br /> | Char de début de trame<br /> | Capteur de distance<br /> | Suiveur de ligne gauche<br /> | Suiveur de ligne centre<br /> | Suiveur de ligne droit<br /> | Checksum<br /> | Char de fin de trame<br /> |-<br /> ! style=&quot;padding: 5px;&quot; | <br /> Nombre de Char<br /> | 1<br /> | 3<br /> | 3<br /> | 3<br /> | 3<br /> | 4<br /> | 1<br /> |-<br /> |}<br /> <br /> <br /> Après test, je me suis rendu compte que cela n'améliorait pas énormément le temps mis par la calculatrice et le robot pour s'échanger des données. J'ai alors cherché à trouver la source du problème. En laissant la Numworks de côté et en envoyant les trames à la main sur le port série à partir du PC, le temps mis pour récupérer la trame de réponse envoyée par l'Arduino était le même qu'en envoyant la trame par la Numworks. Le problème ne venait donc pas de la formation des trames. Il s'agissait en faite de la fonction de lecture de trame implémentée sur l'Arduino : <br /> <br /> void lireTrame() {<br /> if (Serial.find(&quot;S-&quot;)) {<br /> Serial.readBytes(serialBuffer,14);<br /> strcpy(trame, &quot;S-&quot;);<br /> strlcpy(trame + strlen(trame), serialBuffer, strlen(serialBuffer)+1);<br /> trame[15] = '\0';<br /> }<br /> }<br /> <br /> Après l'avoir remplacé par la suivante : <br /> <br /> void lireTrame() {<br /> int nbCharLus = 0;<br /> while (Serial.available() &gt; 0 &amp;&amp; nbCharLus &lt;= 14) {<br /> trame[nbCharLus] = Serial.read();<br /> nbCharLus++;<br /> delay(5);<br /> }<br /> trame[nbCharLus] = '\0';<br /> }<br /> <br /> Le temps d'échange est devenu nettement plus court et m'a redonné de l'espoir vis à vis du suivi de ligne.<br /> <br /> <br /> <br /> *''' Développement du programme Python''' :<br /> <br /> Dans un premier temps, j'ai décidé de développer le suiveur de ligne sur l'Arduino seule afin d'avoir un programme dont je suis sûr du fonctionnement et d'éviter certains problèmes. Je me suis vite rendu compte qu'un simple algorithme comme : <br /> <br /> Tant que 1 : <br /> Si obstacle : <br /> s'arrêter<br /> Sinon si capteur centre sur la ligne : <br /> avancer tout droit<br /> Sinon si capteur gauche sur la ligne :<br /> tourner à gauche<br /> Sinon si capteur droit sur la ligne : <br /> tourner à droite<br /> Fin tant que<br /> <br /> Ne me permettrait pas de passer les angles droits. J'ai alors abouti sur l'algorithme suivant :<br /> <br /> Tant que 1 : <br /> Si obstacle : <br /> s'arrêter<br /> Sinon si capteur centre sur la ligne ET capteur G et D pas sur la ligne : <br /> avancer tout droit<br /> Sinon si capteur G sur la ligne ET capteur D pas sur la ligne :<br /> tourner à gauche<br /> derniereAction &lt;- gauche<br /> Sinon si capteur D sur la ligne ET capteur G pas sur la ligne: <br /> tourner à droite<br /> derniereAction &lt;- droite<br /> Sinon si capteur G ET capteur D sur la ligne : <br /> Si derniereAction == droite :<br /> Tourner à gauche<br /> derniereAction &lt;- gauche<br /> Sinon si derniereAction == gauche :<br /> Tourner à droite<br /> derniereAction &lt;- droite<br /> Sinon si capteur G et D et C pas sur la ligne : <br /> Si derniereAction == droite :<br /> Tourner à droite<br /> Sinon si derniereAction == gauche :<br /> Tourner à gauche<br /> Fin tant que<br /> <br /> <br /> Une fois l'algorithme fonctionnel, j'ai tenté de le porter sur la Numworks. J'ai alors passé de nombreuses heures sur un problème qui, au final, s'avèrait assez bête. Lorsque j'utilisais la batterie sur l'Arduino pour le suivi de ligne sans la Numworks, il n'y avait aucun problème. En revanche, en utilisant la Numworks, le capteur de distance renvoyait toujours des valeurs fausses et le robot s'arrêtait alors qu'il n'y avait pas d'obstacle devant lui. Lorsque l'Arduino était alimentée en série par le pc, il n'y avait plus de problème. Après m'être cassé la tête sur le problème et avoir tout tenté, je me suis résolu à changer les piles... ce qui a résolu le problème. <br /> Après quelques ajustements, le suivi de ligne avec arrêt lors de la rencontre d'un obstacle est fonctionnel en commandant le robot par la Numworks.<br /> <br /> =Documents Rendus=<br /> <br /> - Gitlab du projet : https://archives.plil.fr/mcreteur/NumworksEtRobot.git<br /> <br /> - Schematics, routage et fichiers Gerber des cartes réalisées : [[Media:CartesElectroniquesmcreteur.zip|Fichiers cartes électroniques]]<br /> <br /> - [[Media:Rapport_Numworks&amp;Robot.pdf|Rapport de projet]]<br /> <br /> =Bibliographie=<br /> <br /> - https://zardam.github.io/post/numworks-uart-over-usb/<br /> <br /> - https://github.com/zardam/epsilon/tree/uart_over_usb<br /> <br /> - https://github.com/numworks/epsilon<br /> <br /> - https://www.numworks.com/<br /> <br /> - https://www.st.com/content/ccc/resource/technical/document/user_manual/b8/5a/28/c2/cf/b6/47/d6/DM00105256.pdf/files/DM00105256.pdf/jcr:content/translations/en.DM00105256.pdf<br /> <br /> - https://www.st.com/content/ccc/resource/technical/document/user_manual/1c/6b/06/e6/19/6c/46/bf/CD00289278.pdf/files/CD00289278.pdf/jcr:content/translations/en.CD00289278.pdf<br /> <br /> - https://www.st.com/content/ccc/resource/technical/document/reference_manual/group0/4f/7b/2b/bd/04/b3/49/25/DM00180369/files/DM00180369.pdf/jcr:content/translations/en.DM00180369.pdf<br /> <br /> - https://peip-ima.plil.fr/mediawiki/index.php/BE_2017-2018<br /> <br /> - http://aaroneiche.com/2010/06/24/a-beginners-guide-to-making-an-arduino-shield-pcb/<br /> <br /> - https://www.open-electronics.org/how-to-make-an-arduino-shield-with-eagle-cad-tutorial/<br /> <br /> - https://docs-emea.rs-online.com/webdocs/10e2/0900766b810e25b7.pdf<br /> <br /> - https://www.sparkfun.com/datasheets/Robotics/TB6612FNG.pdf<br /> <br /> - https://forum.micropython.org/viewtopic.php?t=776<br /> <br /> - https://micropython-dev-docs.readthedocs.io/en/latest/adding-module.html<br /> <br /> - https://www.snapeda.com/parts/QRE1113GR/Fairchild%20Semiconductor/view-part/<br /> <br /> - https://www.snapeda.com/parts/POLOLU-713/Pololu/view-part/<br /> <br /> - http://www.diymodules.org/eagle-show-object?type=dm&amp;file=diy-modules.lbr&amp;device=ULTRASONIC-HC-SR04<br /> <br /> - https://odpf.org/images/archives_docs/17eme/memoires/gr-5/memoire.pdf<br /> <br /> - https://www.techiedelight.com/implement-itoa-function-in-c/</div>

Mcreteur https://projets-ima.plil.fr/mediawiki/index.php?title=Fichier:Rapport_Numworks%26Robot.pdf&diff=64792 2018-12-20T02:58:15Z

<p>Mcreteur : </p> <hr /> <div></div>

Mcreteur