==Phrack Inc.== Volume 0x0b, Issue 0x3f, Phile #0x11 of 0x14 |=------------[ Security Review Of Embedded Systems And Its ]------------=| |=------------[ Applications To Hacking Methodology ]------------=| |=-----------------------------------------------------------------------=| |=----[ Cawan: or ]----=| |=------------=[ Traduit par TboWan pour arsouyes.org ]=-----------------=| --=[ Contents 1. - Introduction 2. - Classification d'architectures 3. - Hacking avec les systèmes embarqués 4. - Hacking avec les Linux Embarqués 5. - "Hacking Machine" Implémentation en FPGA 6. - Quels sont les avantages d'utiliser le FPGA dans le hack ? 7. - D'autre magies que le linux embarqué permet ? 8. - Conclusion --[ 1. - Introduction Les systèmes embarqués ont pénétré la vie de tous les jours des humains. Dans les maisons résidentielles, le déploiement des systèmes "smarts" ont mené au terme "smart-home". Ceci concerne la sécurité de la maison, le contrôle et la surveillance des appareils électroniques, le divertissement basé sur l'audio/video, le réseau domestique, etc. Dans l'automatisation des batiments, les systèmes embarqués fournissent la possibilité d'utiliser le réseau (Lonwork, Bacnet, X10) dans des buts pratiques de contrôle et de surveillance. Pour la communication intra-batiment, les medias physiques pour le réseau incluent le courant porteur, RS485, la fibre optique, RJ45, IrDA [NDT : infrarouge], RF [NDT : la radio], etc. Dans ce cas, la media gateway joue un rôle d'interface entre medias pour le système. Pour les systèmes gérés à la main, les périphériques mobiles comme les téléphones portables/smartphones et PDA/XDA deviennent nécessaires dans la vie des gens. Cependant, la croissance de 3G n'est pas aussi bonne que planifiée initialement. La lente adoption de 3G est due à un manque de compatibilité directe avec TCP/IP. Comme résultat, 4G avec la technologie Winmax est semble mieux parti pour être développé par l'industrie de la communications grace à sa grande bande de fréquence sans fil avec OFDM. Évidement, la tendance de développement d'applications de systèmes embarqués sont en train de converger - en utilisant TCP/IP comme "colle entre protocoles" dans un but d'interfaces entre medias. Puisque le développement d'IPv6 va causer un dépassement irrésonable des coûts, le déploiement de produits IPv6 va prendre un peu plus de temps pour être négocié. IPv4 va donc continuer de dominer le monde du réseau, surtout dans les applications embarquées. Comme on le sait, le bon vieux IPv4 doit faire face à ses propres problèmes natifs de sécurité en terme de confidentialité, d'intégrité et d'authentification. Des modules addicitionnels pour ajouter de la valeur comme SSL et SSH serait la meilleure solution pour protéger contre la pluspart des attaques comme le déni de service, l'hijacking, spooling, sniffing, etc. Cependant, l'implémentation de ce genre de modules en système embarqué est optionnelle car ces environnement manquent de ressources hardware. Par exemple, il n'est pas raisonnable d'implémenter SSL dans SitePlayer[1] pour contrôler et surveiller du traffic web compliqué quand on considère la mémoire et la flash qui peut être utilisée. Pendant que IPv4 est en train de conquérir le monde du système embarqué, les caractéristiques natives de IPv4 et la structure réduite des systèmes embarqués vont générer des problèmes de sécurité. Tout ceci est probablement une bombe à retardement cachée qui n'attend que d'être exploitée. Par exemple, en effetuant simplement un scan de port avec une reconnaissance de pattern sur un interval d'adresses IP, tout les SC12 IPC@CHIP[2] qui fonctionnent seront identifiés et affichés. Une fois qu'une IP d'un SC12 est confirmée, il suffit d'envoyer cinq paquet ping de taille 65000 pour le faire crasher jusqu'au redémarrage. --[ 2. - Classification d'architectures Avec l'avancée de l'électronique pratique dans les années 1980, les outils digitaux ont commencé à proliférer dans le monde de la technologie et de l'industrie. Par sa nature digitale, le signal peut être représenté exactement et facilement, ce qui lui donne encore plus d'utilité. En terme de conception de systèmes digitaux, la logique programmable a un avantage certain sur les tableaux de portes logiques et les cellules standardes en rendant plus rapide le temps pour développer et des cycles de conception plus courts. En utilisant des logiciels, la conception digitale peut être programmée directement en logique programmable et permet de réviser la conception relativement vite. Les deux types majeurs de circuit logique programmables sont les "Field Programmable Logic Array" (FPGA) et les "Complex Programmable Logic Devices" (CPLD). Les FPGA offrent la plus grande densité de composants logiques, le plus de fonctionnalités, et les plus grandes performances. Ces périphériques avancés offrent aussi des fonctionnalités tels que les processeurs électroniques intégrés (comme le Power PC d'IBM), une bonne quantité de mémoire, un système de gestion de l'horloge, et un support pour la pluspart des technologie de signal très rapides périphériques à périphériques. Les FPGA sont utilisés pour une grande variété d'applications qui vont du traitement des données et du stockage, l'instrumentation, la télécommunication et le traitement du signal. Par contre, les CPLD offrent moins de composants logiques (à peu près 10 000 portes). Mais les CPLD offrent des caractéristiques temporelles plus prédictibles et sont donc idéales pour des applications de contrôle critiques. En plus, les CPLD requièrent vraiment très peu d'énergie et sont très peu cher. Bien, il est temps de parler du HDL (Hardware Description Language). HDL est un langage de programmation de logiciel utilisé pour modéliser les opérations d'un matériel. Il y a deux aspects de la description du matériel que le HDL facilite : la modélisation du comportement vraiment abstraite et la modélisation des structures matérielles. Le comportement du matériel peut être modélisé et représenté à divers niveaux d'abstraction pendant le processus de conception. Les plus hauts niveaux décrivent les opérations du matérielle de manière abstraite, alors que les niveaux les plus bas incluent plus de détail, comme des structures matérielles inférées. Il y a deux types de HDL : VHDL et Verilog-HDL. L'histoire du HDL commence dans les années 1980 quand le département de la défence américain (DoD) voulait rendre la conception de circuits auto-documentée, qu'elle suive une méthodologie commune et puisse être réutilisable avec les nouvelles technologies. Il devint claire qu'il fallait un langage de programmation standard pour décrire les fonctions et les structures des circuits digitaux pour la conception de circuits intégrés (IC - Integrated Circuit). Le DoD fonda un projet dans le programme de Circuits Intégrés à Très Haute Vitesse (VHSIC - Very High Speed Integrated Circuit) pour créer un langage de description de matériel standard. Il en résulta la créaction du langage de description de matériel VHSIC ou le VHDL comme on l'appele maintenant. L'histoire du Verilog-HDL a débuté en 1981, quand une compagnie de logiciel de CAE appellée Gateway Design Automation fu créée par Prabhu Goel. L'un des premiers employés de Gateway a été Phil Moorby, qui était l'auteur original de du langage de description matériel GenRad (GHDL) et du simulateur HILO. En 1983, Gateway publia le langage de description matériel Verilog ou simplement Verilog-HDL en même temps qu'un simulateur Verilog. À la fois VHDL et Verilog-HDL ont été revu et adopté par l'IEEE comme standard IEEE 1076 et 1364 respectivement. L'implémentation moderne de matériel ou de système ambarqué peut être divisé en deux catégories : le hardcore processing et le softcore processing. Le hardcore processing est une méthode d'applicquer des processeurs déjà existants comme ARM, MIPS, x86, etc comme unité de base du calcul avec des protocols de piles intégrées. Par exemple : SC12 avec x86, IP2022 avec Scenix RISC, eZ80, SitePlayer et Rabbit tombent dans la catégorie du hardcore processing. À l'opposé, le softcore processing utilise un coeur reconfigurable qui peut être réalisé par des éléments semi-conducteurs. Les éléments semi-conducteurs doivent être programmables comme le font les FPGA et les CPLD. Altera[3] et Xilinx[4] sont les seuls fabriquant de FPGA/CPLD sur le marché qui supportent les processuers sofcore. Altera fourni un processur NIOS qui peut être implémenté en SOPC Builder qui est réalisé par son FPGA Cyclone et stratix. Xilinx fourni deux types de softcore : Picoblaze, qui est réalisé en CPLD CoolRunner-2 ; et Microblaze, qui est réalisé en FPGA Spartan et Virtex. Dans les cas des FPGA avec du hardcore embarqué, par exemple le ARM-core dans stratix et MIPS-core dans Vitrex sont classifié en tant que hardcore processing. De l'autre côté, les FPGA avec du softcore embarqué comme NIOS-core dans Cyclone ou Stratix, et Microblaze-core dans Spartan ou Vitrex sont classifiés en softcore processing. D'un autre côté, les softcore embarqués peuvent être associés à d'autres périphériques reconfigurables comme le contrôleur DMA dans des buts de calculs avancés. En général, le point de vue classique à propos du hardcore processing est qu'il est toujours plus rapide que le softcore processing. Dans les faits, ce n'est pas le cas. Les performances processeur sont souvent limité par la vitesse des instructions et à la manière dont les données peuvent être pipelinées depuis les mémoires externes vers les unités d'exécution. Comme résultat, le hardcore processing est plus adapté à des applications d'ordre général mais le softcore processing est plus adapté dans un but d'application personnalisables avec des processeurs parallèles et DSP. Ils sont dédiés à des implémentations flexibles sur des plateformes adaptatives. --[ 3. - Hacking avec les systèmes embarqués Quand les avantages du softcore processing sont appliqué dans le hack, ils apportent des méthodes plus créatives d'attaques, la seule limitation étant l'imagination. Richard Clayton a montré une méthode d'extration d'une clef 3DES d'un IBM 4758 qui fait fonctionner une Architecture cryptographique commune (CCA - Common Cryptographic Architecture) [5]. L'IBM 4758 avec son logiciel CCA est très utilisé dans l'industrie banquaire pour garder les clefs de chiffrement sûrement. Le périphérique est extrêmement inaltérable et aucune attaque physique n'est connue pour pouvoir acceder à la clef. D'après Richard, à peu près de 20 minutes d'accès ininterrompu à l'IBM 4758 avec la permission Combine_Key_Parts sont suffisantes pour exporter les clefs DES et 3DES. Pour des raisons pratiques, il est plus probable d'implémenté un système embarqué avec une application personnalisable pour récupérer la cler en 20 minutes d'accès au périphérique. Une carte d'évaluation de Altera a été sélectionnée par Richard CLayton dans le but de l'extraction de clef et ajoute deux jours de cassage hors-ligne de la clef. En pratique, utilisant plusieurs NIOS-core avec des périphériques personnalisables fournirait de meilleurs performances dans le cassage hos-ligne de la clef. En fait, le calcul parallèle personnalisable est très adapté pour exploiter les clefs à la fois symmétriques et assymétriques. --[ 4. - Hacking avec les Linux Embarqués Pour le hacking basé sur les applications, comme les débordement de buffer et l'injection SQL, il est préférable d'avoit RTOS d'installé dans le système ambarqué. Dans un but de code réutilisable, le linux embarqué serait le meilleur choix de plateforme de hacking embarquée. L'exemple suivant montrera clairement les possibilités d'attaques sous des plateformes embarquées. La condition sur la plateforme ambarquée est qu'elle vienne avec NIOS-core dans Stratic et uClinux qui y est installé. En recompilant le code source de netcat et le faisant fonctionner, on obtien un couteau suisse et pret à faire une pénétration comme lisé ci-après : a) Un scan de port avec de la reconnaissance de patterns Une liste de sous-réseaux peut être définie initialement dans le système embarqué et vous pouvez l'apporter avec vous dans un batiment commercial. Branchez le système embarqué dans n'importe quelle prise RJ45 dans le batiment et pressez un bouton pour effectuer un scan de port avec de la reconnaissance de pattern et identifier un réseau de système embarqué vulnérable dans le batiment. Pressez un autre bouton pour lancer une attaque (Deni de service) vers le réseau de système(s) embarqué vulnérable. C'est un sérieux problème quand le réseau de systèmes embarqué concerne le système d'évacuation du batiment, le système de surveillance, et le système de sécurité. b) Attaque de Brute-Force Automatique Définissez l'adresse du serveur, le dictionnaire et le patron de brute-force dans le système embarqué. Une fois encore, branchez-le dans n'importe quelle prise RJ45 du batiment, pressez un bouton pour commencer la recherche de mot de passe. Tant que ce système embarqué reste dans sa petite boite, branché dans une prise bien cachée, il peut effectuer le travail du cracking sur plusieurs jours, alimenté par ses bateries. c) Hacking LAN En pré-identifiant l'adresse du serveur, les versions des patchs, le type de service, une attaque structurée peut être lancée au sein même de l'immeuble. Par exemple en définissant : http://192.168.1.1/show.php?id=1%20and%201=2%20union%20select%20 8,7,load_file(char(47,101,116,99,47,112,97,115,115,119,100)),5,4, 3,2,1 **char(47,101,116,99,47,112,97,115,115,119,100) = /etc/passwd initialement dans le système embarqué. Encore une fois, branchez le système embarqé dans une prise RJ45 (dans le LAN), pressez un bouton pour lancer l'injection SQL pour récupérer le fichier de mot de passes de la machine Unix (dans le LAN). Le mot de passe est alors stocké dans la mémoire flash et prete à être récupérée pour un crackage hors-ligne. Au lieu d'utiliser une injection SQL, on peut très bien utiliser des exploits dans le même but. d) Diffusion de Virus/Worm Le virus/worm peut être préchargé dans le système embarqué. On branche toujours le système sur une prise RJ45, pressons un boutons pour lancer l'exploit sur une machine vulnérable et y charger le virus/worm dans le LAN. e) Sniffer Embarqué Passez l'interface réseau du mode normal au mode promiscuous [NDT : mode de la carte dans lequel elle peut sniffer] et définissez les conditions du sniffing. Encore, on branche le système sur une prise RJ45, pressez un boutons pour lancer le sniffer. Pour être sur que le sniffing se déroule bien dans un LAN commuté [NDT : switching LAN], un sniffer ARP est recommandé. --[ 5. - "Hacking Machine" Implémentation en FPGA L'implémentation d'une "hacking machine" embarquée va être démontrée sur la carte de développement NIOS d'Altera avec le FPGA Stratix EP1S10. La carte fournis une carte réseau ethernet 10/100-base-T et un connecteur compact-flash. Deux ports RS-232 sont aussi fournis pour de l'interfacage série et dans un but de configuration, respectivements. En plus, on dispose de 1MB de SRAM, 16 MB de SDRAM et 8MB de mémoire flash pour l'installation d'un linux embarqué [6]. La version de linux que nous utiliseront est uClinux, de microtronix[7]. Ok, c'était les spécifications de la carte. Maintenant, nous pouvons commencer notre voyage dans la conceptions de la "hacking machine". Nous avons utilisé trois outils fournis par Altera pour implémenter notre conception "matérielle". Dans notre cas, le terme "matériel" signifie que c'est reprogrammable et sera conçu en Verilog-HDL. Les trois outils que nous avons utilisé sont les suivants : QuartusII (comme outil de synthèse), SPOC Builder (comme outil de conception du NIOS-core) et le compilateur C. D'autres outils de synthèse comme leonardo-spectrum de mentor graphic et sunplify de synplicity sont optionnels pour une utilisation dans un but spécial. Dans ce cas, la conception synthétisée en format edif est définie comme module externe. On doit charger le module à partir de QuartusII pour effectuer le "place-and-route" (PAR). La sortie du PAR est définie comme hardware-core [NDT : coeur matériel]. Pour les utilisateurs confirmés, on conseille grandement d'utiliser Modelsim de mentor graphic pour faire des simulation comportementales et des simulations post-PAR. Les simulations comportementales sont un type de vérification fonctionnelle de la conception du matériel digital. Les considérations de timing ne sont pas prises en compte dans cette étape. Par contre, la simulation post-PAR est un type de vérification dans des conditions réelles. Dans ce cas, tout les facteurs de l'utilisation réelle, comme la consomation d'énergie et les conditions de timing (au format sdf) sont prises en considération. [8,9,10,11,12] Une conception de référence est fournie par microtronix et il est très fortement recommandé de l'utilisé comme conception de base pour toute autre conception personnalisée avec des modifications appropriées [13]. Bien, pour nos considérations de conceptions de notre "hacking machine", la seule modification nécessaire est d'affecter les interruptions de quatres boutons poussoirs intégrés [14]. Donc, une fois que la conception de base est chargée dans QuartusII, SOPC Builder est près à commencer la conception du NIOS-core, la Boot-ROM, les interfaces SRAM et SDRAM, l'interface Ethernet, l'interface compact-flash, etc. Avant de générer le code synthétisable pour notre conception, il est crucial de vérifier que la check-box de "Micronix UClinux" sous les composants logiciels est sélectionnée (elle est dans la partie "More CPU Settings" du menu de configuration principal de SOPC Builder). En sélectionnant cette option, on permet de générer un noyau UClinux, la librairie uClibc et d'autres applications uClinux d'ordre général au moment de la génération du code synthétisable. Une fois prèt, générez la conception en tant que code synthétisable dans SOPC Builder en effectuant un PAR dans QuartusII pour obtenir le coeur matériel. En général, voici les deux formats des coeurs matériels : &) coeurs .sof : pour être téléchargé dans l'EP1S10 directement par JTAP et nécessitera un rechargement si la carte s'éteint ** (voyez le comme volatile) b) coeurs .pof : pour être téléchargé dans l'EPC16 (périphérique de configuration avancé) et sera automatiquement chargé dans le FPGA à chaque démarrage de la carte ** (voyez le comme non-volatile) Le fichier brut des fichiers .sof et .pof du coeur matériel est .hexout. En tant qu'hackers, on préfèrera travailler à la ligne de commande, nous utilisons donc l'outil hexout2flash pour convertir le coeur matériel du format .hexout vers le .flash et le relogeont à l'adresse de base OX600000 dans la flash. L'adresse 0X600000 est l'adresse du chargement du coeur de démarrage du EP1S10. Donc, une fois que le fichier .flash est créé, nous utilions la commande nios-run ou rn pour télécharger le coeur dans la mémoire flash comme suit : [Linux Developer] ...uClinux/: nios-run hackcore.hexout.flash Après que nios-run vous ai indiqué que le chargement s'est bien passé, redémarrez la carte. Le coeur chargé va maintenant démarrer le coeur par défaut à chaque fois que la carte redémarrera. Bien, la partie "matérielle" est finie. Maintenant, nous allons regarder dans la partie "lagicielle". On démarre par UClinux. Comme il a été dit, SOPC Builder a généré un cadre avec un noyau UClinux, la librairie uClibc, et certaines applications UClinux d'ordre général comme cat, mv, rm et autres. On commence par reconfigurer notre noyau en utilisant "make xconfig". [Linux Developer] ...uClinux/: cd linux [Linux Developer] ...uClinux/: make xconfig Dans xconfig, faites des personnalisations appropriées du noyau, utilisez ensuite "make clean" pour nettoyer l'arborescence des sources de tous les fichiers objets. [Linux Developer] ...linux/: make clean Pour commencer à construire un nouveau noyau, utiliser "make dep" et ensuite "make". [Linux Developer] ...linux/: make dep [Linux Developer] ...linux/: make Pour constuire le fichier linux.flash à uploader, utiliser "make linux.flash". [Linux Developer] ...uClinux/: make linux.flash Le fichier linux.flash est défini comme l'image du système d'exploitation. Comme on le sait, un système d'exploitation doit fonctionner avec un système de fichiers. Donc, nous avons aussi besoin de créer une image du système de fichier. D'abord, éditez le fichier de configuration dans userland/.config pour sélectionner quel package d'application doit être construit. Par exemple : #TITLE agetty CONFIG_AGETTY=y Si une variable correspondant à un package d'applications est mis à "n" (par exemple, CONFIG_AGETTY=n), alors, il ne sera pas construit ni copié vers le répertoire racine cible. Ensuite, construisez tous les packages d'applications spécifiés par le fichier userland/.config comme suit : [Linux Developer] ...userland/: make Maintenant, on copie le netcat précompilé dans le répertoire racine cible. Après, on utilise "make comfs" pour commencer à générer le système de fichier ou l'image du romdisk. [Linux Developer] ...uClinux/: make romfs Une fois fini, le fichier romdisk.flash résultant est près à être téléchargé vers la carte cible. D'abord, téléchargez l'image du système de fichier et ensuite l'image du système d'exploitation vers la mémoire flash. [Linux Developer] ...uClinux/: nios-run -x romdisk.flash [Linux Developer] ...uClinux/: nios-run linux.flash Bien, notre "hacking machine" sur FPGA est maintenant prète. Essayons-la avec une machine linux avec le fichier /etc/passwd activé. Nous admetrons que l'IP de la machine est 192.168.1.1 et que c'est un serveur web dans le LAN qui utilise une bse de donnée MySQL. Ensuite, nous savons que son show.php est vulnérable à l'injection sql. Nous admetrons aussi qu'il y a certaines protections pour filtrer les symboles dangereux, nous décidons donc d'utilier la méthode d'injection char(). Nous admetrons que le total de colonnes dans la tabel accédées par show.php est 8. Maintenant, on défini : char getpass[]="http://192.168.1.1/show.php?id=1%20and%201=2%20union %20select%208,7,load_file(char(47,101,116,99,47,112,97,115,115,119, 100)),5,4,3,2,1"; comme chaine d'attaque et nous stockons les données correpondantes (contenu de /etc/passwd) dans un fichier password.dat. En créant un pipeline vers netcat, et en même temps en nous assurant que la chaine d'attaque est toujours déclanchée par le bouton poussoir, notre "hacking machine" est alors prète. Branchez la "hacking machine" dans une prise RJ45 du LAN, et ensuite, en appuyant sur le bouton, lancez l'attaque contre 192.168.1.1. Après celà, débranchez la "hacking machine" et connectez-là au PC, télécharger le fichier password.dat, et commencez à le casser. En utilisant les avantages de l'architecture FPGA, un cracker matériel peut être ajouté pour avoir un processus de cassage embarqué. N'importe quel module optionnel peut-être conçu en Verilog-HDL et connecté au FPGA pour avoir un hacking "tout en un". Les avantages d'une implémentation FPGA sur un processeur hardcore conventionnel seront traités dans la section suivante, avec beaucoup d'études de cas, de comparaisons et de merveilleux examples. Trucs : ** Il est recommandé d'installer un serveur FTP dans la "hacking machine" pour deux raisons : 1) Toute mise à jours (troyens, exploits, vers, ...) vers la "hacking machine" peut être fait à travers le FTP (mises à jours en lignes). 2) Les informations récoltées (fichiers de mots de passe, de configurations, ...) peut être facilement récupérés. Notes : ** L'installation d'un serveur FTP sous uClinux est faite en éditant le fichier userland/.config pour activer le service ftpd. ** C'est juste une démonstration, il est quasiment impossible d'avoir une machine unix/linux qui n'utilise pas des permissions sur les fichiers et brouille le fichier de mots de passes. Le but de cet article est de montrer la migration de la méthodologie du piratage depuis les PC fixes vers les systèmes embarqués. --[ 6. - Quels sont les avantages d'utiliser le FPGA dans le hack ? Bien, c'est une bonne question venant de quelqu'un qui utilise 50 $ pour un module rabbit, une pile 9 volts et 20 lignes de C dynamique, alors qu'une simple "hacking machine" peut être implémentée en utilisant une carte de développement FPGA à 300 $ avec un processeur propriétaire embarqué pour 495 $. La réponse est que le FPGA fournis des fonctionnalités uniques basées sur son architecture reprogrammable. Comme on le sait, les FPGA sont des plateformes très connues pour la vérification d'algorithmes dans l'implémentation matérielle, surout dans les applications DSP. La demande en débit de données par l'industrie de la communication filaire et sans file a mené au développement d'interfaces à puces à plus haut débit et à moindre cout. Basé sur ces considérations, des demandes en cannaux et de scan de bande programmables doivent être digitalisées et reprogrammable. Un nouveau terme a été créé pour ce type de cadre : "software defined radio" ou SDR. Cependant, la lente adoption des SDR est due à la limitation des converteurs analogiques/digitaux [NDT : Analog-to-Digital Converter - ADC] pour digitaliser les unité de démodulation analogiques des modules émeteurs-récepteurs. Bien que les taux atteint des ADC les plus avancé n'ai pas atteint les spécificatin, ça arrivera bientôt. Dans ce cas, l'application de puces DSP conventionnelles comme TMS320C6200 (pour le calcul de point fixe) et TMS320C6700 (pour le calcul en point flottant) ont un peut plus dur à gérer ces taux de transfert extrêmes. Bien sûr, on peut dire que ces techniques de calcul parallèle peuvent résoudre le problème en utilisant les symboles suivant en langage assembleur linéaire [15]. Inst1 || Inst2 || Inst3 || Inst4 || Inst5 || Inst6 Inst7 Le symbole double-pipe (||) indique que les instructions sont parallèles avec l'instruction précédente. Inst2 à Inst6, ces cinq instructions sont en parralèle avec la première instruction, Inst1. Dans TMS320, jusqu'à 8 instructions peuvent être exécutées en parallèle. Cependant, ce n'est pas une vraie méthode parallèle, mais effectue une mise en pipeline de différents étapes de temps dans un seul cycle d'horloge. Au contraire, la calcul vraiment parallèle ne peut être implémenté qu'en utilisant différent ensembles de modules matériels. Donc, FPGA devrait être la seule solution pour implémenter une réelle architecture de calcul parallèle. Dans le cas où SDR est mentionné, c'est juste un exemple pour montrer les limitation du traitement de données en partage de structures et de ressources. Pendant ce temps, quand on considère l'implémentation d'un module de chiffrement, c'est le même cas que le traitement de données. La méthode de calcul parallèle vaut la peine pour améliorer le temps de cassage de clefs. Ensuite, il suffit de savoir que l'implémentation d'un module de chiffrement en FPGA est menée par le matériel [NDT : hardware-driven]. C'est totalement libre vis à vis des structures d'hardcore processing qui utilisent un seul pointeur d'instruction (ou compteur de programme) pour effectuer des opération d'empilement et de dépilement interractivement sur la pile en mémoire. Ces deux avantages, calcul vraiment parallèle et mené par matériel, clarifient donc bien la singularité de l'architecture FPGA pour les applications avancées. Pendant qu'on continue dans l'unicité de l'architecture FPGA, de plus en plus d'applications intéressantes peuvent être exposées. Pour des applications du hacking, nous nous focalisons et restont à exposer l'utilisation des possibilités du matériel reprogrammable de notre "hacking machine" en FPGA. Nous ignorons ici les possibilités de "logiciels reprogrammables" car ça peut être fait avec n'importe quel processeur à bas prix. En appliquant les caractéristiques du matériel reprogrammable, un segment de mémoire flash est réservé à l'image du matériel. Dans Nios, elle commence à 0x600000. Ce segment peut être mis à jours à travers l'interface réseau. Dans la communication mobile avancée, ette fonctionnalité commence à être utilisée pour des correction de bug matériels ainsi que des mises à jour de modules [16]. On le connait surtout en tant que technologie Over-The-Air (OTA). Au sujet du hacking, les caractéristiques du matériel reprogrammable ont rendu notre "hacking machine" générique. On peut y mettre un casseur de clef DES hardware-driven, et facilement échangeable avec un casseur de MD5 ou tout autre type de module hardware-driven. On peut aussi échanger ce casseur en proxy dans un deuxième temps. À ce stade, l'unicité de l'architecture FPGA est maintenant claire. Donc, il est temps de commencé à parler de la magie noire des caractéristiques du matériel reprogrammable plus en détail. En utilisant NIOS-core, nous explorons deux points : les instructions personnalisées et les périphériques utilisateurs. Une instruction personnalisée est hardware-driven et implémentée en logique personnalisée comme montré ci-après : |---->|-------------| | |Logique persp|-| | |-->|-------------| | | | | | | |-----------------|| A ---->| |-| | | Nios-ALU | |----> OUT B ---->| |-| |-----------------| En définissant une logique personnalisée parallèle connectée aux entrée du NIOS-ALU, une nouvelle instruction peut ainsi être créée. Avec SOPC-Builder, des logiques personnalisées peuvent être ajoutées et retirées, et il en va de même avec les instructions personnalisées. Nous allons maintenant créer une nouvelle instruction, soit nm_fpmult(). Nous appliquons le code suivant : float a, b, result_slow, result_fast; result_slow = a * b; //Utilise 2874 cycles d'horloge result_fast = nm_fpmult(a, b); //Utilise 19 cycles d'horloge À partir des résultats d'exécutions, l'opération de multiplication basé sur le matériel est tellement rapide qu'elle l'est toujours plus que la puce DSP. Dans un but de cassage, des ensembles d'instructions personnalisées peuvent être batis en fonction de la fréquence de leur utilisation. L'ensemble d'instruction peut être facilement ajouté et retiré pour différent types de chiffrement considérés. Les périphériques utilisateurs sont la deuxième magie noire du matériel reprogrammable. Comme nous le savons, NIOS-core est un soft-processor, on a donc besoin de spécification du bus pour communiquer avec d'autres périphériques comme la RAM, ROM, l'UART et l'horloge. NIOS-core utilise une spécification du bus propriétaire, connue sous le nom d'Avalon-bus, pour la communication périphérique-à-périphérique ou NIOS-core-à-périphérique. Donc, les périphériques utilisateurs comme l'IDE ou l'USB sont souvent conçu pour étendre l'utilisabilité des systèmes embarqués. Dans un but de hack, nous ignorons les périphériques IDE et USB car nous ne sommes pas intéressés par concevoir des périphériques utilisateurs pour de la synchronisation de canaux de communications personnalisés. Quand nous voulons pirater un système personnalisé comme l'automatisation d'un batiment, l'addressage publique, l'évacuation, la sécurité, etc, le principal obstacle est leur protocole de communication propriétaire [17, 18, 19, 20, 21, 22]. Dans ces cas, une interface réseau typique est quasiment impossible à synchroniser avec le canal de communication du système personnalisé. Par exemple, un système qui fonctionne à 50Mbps, des cartes 10Base-T ou 100Base-T peuvent très bien communiquer avec n'importe module dans le système. Cependant, en connaissant les spécifications techniques de ces sstèmes, un périphérique de communication personnalisé peut être créé en FPGA. Il permet ainsi à notre "hacking machine" de se synchroniser au canal de communication du système. À travers l'Avalon-bus, Nios-core est capable de manipuler les flux de données des systèmes personnalisés. Donc, le périphérique de communication personnalisé va être la passerelle perso de notre "hacking machine". Les bases théoriques des périphériques de communication personnalisée viennent des méchanismes de "clock data recovering" (CDR)]. Le CDR est une méthode pour permettre que la regénération de données est faites avec un circuit de désition qui échantillone les signaux de données au moment optimal indiqué par une horloge. L'horloge doit être synchronisée exactement sur la fréquence du débit de données, et alignée en phase vis à vis des donnéeS. La production de cette horloge sur le récepteur est le but du CDR. En général, la tâche du CDR est divisée en deux : l'acquisition de fréquence et l'alignement du timing. L'acquisition de fréquence est le processus qui bloque la fréquence d'horloge du récepteur sur celle des données transmises. L'alignement du timing est est l'alignement de phase de l'horloge pour que le circuit de décision échantillone les données aux instants optimaux. On l'appelle parfois la synchronisation au bits [NDT : bit synchronisation] ou bloquage de phase [NDT : phase locking]. La plupart des circuit d'alignement de timing peuvent effetuer un degré limité d'acquisition de fréquences, mais des matériels d'acquisition additionnels peuvent-être nécessaires. La méthode du suréchantillonage de données va être utilisée pour créer notre CDR pour notre "hacking machine". En utilisant la méthode du suréchantillonage de données, l'acquisition de fréquence on aura plus besoin de prendre en considération la conception de l'acquisition de fréquences. En s'assurant que la fréquence d'échantillonage est toujours N fois plus grande que le débit des données, le CDR peut fonctionner normalement. Pour se synchroniser sur plusieurs systèmes personnalisés, une unité de synthèse de fréquences comme PLL est recommandée pour être sur que la fréquence d'échantillonage est toujours N fois plus grande que le débit des données. Un cadre de CDR basé sur la méthode du suréchantillonage avec N=4 est montré ci-après en verilog-HDL. ** La fréquence d'échantillonage est de 48MHz (mclk), ce qui est 4 fois le débit des données (12MHz). //Définition des entrées et sorties input data_in; input mclk; input rst; output data_buf; //Détecteur de pont asynchrone [Edge] wire reset = (rst & ~(data_in ^ capture_buf)); //module de suréchantillonage reg capture_buf; always @ (posedge mclk or negedge rst) if (rst == 0) capture_buf <= 0; else capture_buf <= data_in; //module de détection de pont [edge] reg [1:0] mclk_divd; always @ (posedge mclk or negedge reset or posedge reset) if (reset == 0) mclk_divd <= 2'b00; else mclk_divd <= mclk_divd + 1; //capture la donnée et la met dans un buffer de 16-bits reg [15:0] data_buf; always @ (posedge mclk_divd[1] or negedge rst) if (rst == 0) data_buf <= 0; else data_buf <= {data_buf[14:0],capture_buf}; Une fois que le canal est synchronisé, les données peuvent être transférées vers le Nios-core à travers l'Avalon-bus pour un traitement et une interraction future. Ce cadre de CDR est moins bon pour de la synchronisation de canaux avec des canaux de communications personnalisés variés. Jean P. Nicolle a montré un autre type de CDR pour la synchronisation 10Base-T [23]. On pourrait demander si c'est l'approche la plus commune d'effectuer la synchronisation de cannaux dans la boucle de bloquage de phase [NDT : Phase-Lock Loop - PLL]. Oui, c'est un type d'approche analogique très connue, mais nous sommes plus intéressés par l'approche digitale, pour des raisons de matériel reprogrammable - notre magie noire du FPGA. Pour ceux qui sont intéressé de connaitre les avantages de l'approche de CDR digital sur l'approche de CDR analogique, allez voir [24]. De toutes façons, l'approche CDR analogiqueest la seule solution pour la conception d'une "hacking machine" hardware-based (Scenix, Rabbit, SC12, ...), et elle soufre des points suivants : 1. Une conception plus longue pour différent débits de données du lien de communication. Le PLL Lock-time pour prédéterminer la longueur, la conception de circuit "charge-dump", le "Voltage Controller Oscillator" (VCO) sont des points très critiques. 2. Conception d'une structure fixe. Tout changement d'une "application de hack" nécessitera une reconception du circuit lui-même et c'est assez ennuyeux. En conclusion, en récupérant les spécifications techniques détaillées d'un système personnalisé, les possibilités de hack ont toujours existé, surtout celles de lancer une attaque de Déni de Service. En désactivant le système d'évacuation, ou le système d'alarme incendie en cas d'urgence, c'est un problème encore plus sérieux qu'avant. Essayez d'imaginer, quand différents types de CDR sont implémentés dans un seul FPGA, et est capable d'effectuer des changements automatiques vers le bon CDR pour se synchronisé avec le canal. D'un autre côté, n'importe que module personnalisé est capable de se brancher au système lui-même est de communiquer librement à travers l'Avalon-bus. Ensuite, l'image du matériel généré peut être téléchargée en mémoire flash à travers tftp. Après un redémarrage matériel pour re-configurer le FPGA, la "hacking machine" est correctement mise à jours. Elle est donc prète pour pirater des systèmes personnalisés multiples en même temps. étude de cas : ** Le développement de la technologie OPC devient lentement plus populaire. D'après la fondation OPC, la technologie OPC peut éliminer les interfaces personnalisées onéreuses et les les drivers traditionnellements requis pour déplacer l'informations facilement à travers l'entreprise. Il promeut l'interropérabilité, s'incluant parmis différentes solutions de calcul et de plateformes à la fois horizontalement et verticalement dans l'entreprise [25]. --[ 7. - D'autre magies que le linux embarqué permet ? Nous connaissons donc les faiblesses des systèmes embarqués, et nous savons aussi comment utiliser ses avantages dans le piratage. Quelle sorte de magie pouvons-nous ensuite faire avec les systèmes embarqués ? C'est une bonne question. En se référants aux développement des applications réseaux, l'information ubiquitaire (ou pervasive [NDT : voir note en fin d'article] serait le dernier sujets. Les systèmes embarqués seront probablement les futurs cadres pour les firewalls embarqués, gateway/router ubiquitaires, IDS embarqués, serveur de sécurité de périphériques mobiles, etc. Pendant que les systèmes existants regardent vers le réseau, les systèmes embarqués ont établis une position unique pour sur un tel sujet. Un bon exemple est la migration de MySQL vers un Linux embarqué pour fournir un service de base-de-données-sur-puce en ligne (sur FPGA) pour un accès à un batiment avec des étiquettes RFID. Encore une fois, l'utilisation et le développement des systèmes embarqués n'a pas de limitation, la seule étant l'imagination. Trucs : ** Si un système embarqué fonctionne comme serveur (http, ftp, ...), il est en train de fournir des services tel que le contrôle web, la surveillance web, ... ** Si un système embarqué fonctionne comme client (http, ftp, telnet, ...), alors, il est plus probable que ça soit une "hacking machine" programmable. --[ 8. - Conclusion Les systèmes embarqués sont une technologie extrèmement utile, parce qu'on ne peut pas s'attendre à ce que chaque unité de calcul dans le monde soit un ordinateur personnel. Pendant que nous commencont à exploiter les avantages des systèmes embarqués, nous devons considérer tous les cas correctement, ou nous devrions les utilser et où nous ne devrions pas. La sécurité embarquée est trop jeune pour en discuter sérieusement maintenant mais elle existe toujours, et parfois candide. Ensuite,l'abus de système embarqués devrais causer plus de cas mystérieux dans le monde du hack. --=[ References [1] http://www.siteplayer.com/ [2] http://www.beck-ipc.com/ [3] http://www.altera.com/ [4] http://www.xilinx.com/ [5] http://www.cl.cam.ac.uk/users/rnc1/descrack/index.html [6] Nios Development Kit, Stratix Edition: Getting Started User Guide (Version 1.2) - July 2003 http://www.altera.com/literature/ug/ug_nios_gsg_stratix_1s10.pdf [7] http://www.microtronix.com/ [8] Nios Hardware Development Tutorial (Version 1.1) - July 2003 http://www.altera.com/literature/tt/tt_nios2_hardware_tutorial.pdf [9] Nios Software Development Tutorial (Version 1.3) - July 2003 http://www.altera.com/literature/tt/tt_nios_sw.pdf [10] Designing With The Nios (Part 1) - Second-Order, Closed-Loop Servo Control Circuit Cellar, #167, June 2004 [11] Designing With The Nios (Part 2) - System Enhancement Circuit Cellar, #168, July 2004 [12] Nios Tutorial (Version 1.1) February 2004 http://www.altera.com/literature/tt/tt_nios_hw_apex_20k200e.pdf [13] Microtronix Embedded Linux Development - Getting Started Guide: Document Revision 1.2 http://www.pldworld.com/_altera/html/_excalibur/niosldk/httpd/ getting_started_guide.pdf [14] Stratix EP1S10 Device: Pin Information February 2004 http://www.fulcrum.ru/Read/CDROMs/Altera/literature/lit-stx.html [15] TMS320C6000 Assembly Language Tools User's Guide http://www.tij.co.jp/jsc/docs/dsps/support/download/tools/ toolspdf6000/spru186i.pdf [16] Dynamic Spectrum Allocation In Composite Reconfigurable Wireless Networks IEEE Communications Magazine, May 2004. http://ieeexplore.ieee.org/iel5/35/28868/01299346.pdf?tp=&arnumber= 1299346&isnumber=28868 [17] TOA - VX-2000 (Digital Matrix System) http://www.toa-corp.co.uk/asp/catalogue/products.asp?prodcode=VX-2000 [18] Klotz Digital - Vadis (Audio Matrix), VariZone (Complex Digital PA System For Emergency Evacuation Applications) http://www.klotz-digital.de/products/pa.htm [19] Peavey - MediaMatrix System http://mediamatrix.peavey.com/home.cfm [20] Optimus - Optimus (Audio & Communication), Improve (Distributed Audio) http://www.optimus.es/eng/english.html [21] Simplex - TrueAlarm (Fire Alarm Systems) http://www.simplexgrinnell.com/ [22] Tyco - Fire Detection and Alarm, Integrated Security Systems, Health Care Communication Systems http://www.tycosafetyproducts-us.com [23] 10Base-T FPGA Interface - Ethernet Packets: Sending and Receiving http://www.fpga4fun.com/10BASE-T.html [24] Ethernet Receiver http://www.holmea.demon.co.uk/Ethernet/EthernetRx.htm [25] The OPC Foundation http://www.opcfoundation.org/ [26] www.ubicom.com (IP2022) [27] http://www.zilog.com/products/family.asp?fam=218 (eZ80) [29] http://www.fpga4fun.com/ [29] http://www.elektroda.pl/eboard --=[ Note du traducteur : Information ubiquitaire : Ubiquitous computing en anglais. Modèle de bureau ou l'informatique est omniprésente. De simples tâches implique plusieurs matériels informatique simultanément. Plus d'informations, par exemple, là bas : http://fr.wikipedia.org/wiki/Informatique_ubiquitaire |=[ EOF ]=---------------------------------------------------------------=|