==Phrack Inc.==
Volume 0x0b, Issue 0x3f, Phile #0x11 of 0x14
|=------------[ Security Review Of Embedded Systems And Its ]------------=|
|=------------[ Applications To Hacking Methodology ]------------=|
|=-----------------------------------------------------------------------=|
|=----[ Cawan: <chuiyewleong[at]hotmail.com> or <cawan[at]ieee.org> ]----=|
|=------------=[ 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 ]=---------------------------------------------------------------=|