Forums d'entraide informatique - Astuces - Conseils

Le protocole FireWire est bien connu quand il s'agit de connecter des appareils vidéo numériques ou des disques durs externes à des ordinateurs. Mais on ignore le plus souvent qu'il permet de lire et d'écrire des données dans la mémoire physique des appareils connectés, et ce, sans intermédiaire logiciel (technologie DMA, ou Direct Memory Access). Cet article évoque les aspects du protocole qui permettent l'accès à la mémoire. Il montre, en outre, comment utiliser en pratique ces spécifications pour par exemple écraser la mémoire vidéo. Le protocole prévoit néanmoins les moyens d'empêcher cet accès, lesquels sont désormais mis en oeuvre par les systèmes d'exploitation. Sur un serveur, il peut cependant être intéressant de permettre l'accès. Il devient ainsi possible, dans le cas où l'ordinateur serait compromis, d'obtenir une image complète de la mémoire centrale, et ce, sans modifier l'état du serveur (analyse post-mortem).
Contexte technique
Les possibilités décrites plus loin reposent sur la norme OHCI [i], 1394 Open Host Controller Interface, une implémentation du protocole de la couche liaison du bus série IEEE-1394. L'IEEE1394 se décline en trois versions : IEEE-1394 (1995), IEEI394a (2000) et IEEE-1394b (2002), chacune ayant permis de décupler la vitesse de transfert.
Le bus assure un débit de données de 800 Mb/s et permet d'établir des connexions directes entre les périphériques sans passer par un ordinateur hôte, contrairement à l'USB. Il est possible de relier 1023 ponts (reliant plusieurs bus entre eux), chacun pouvant recevoir 63 noeuds.
Parallèlement au mode de transfert asynchrone, il fonctionne également en mode isochrone, ce qui lui permet d'utiliser une bande passante large, si bien que cette interface est devenue courante dans le secteur de la vidéo numérique. Appelées i.Link par Sony et FireWire par Apple, ces implémentations par les deux constructeurs de la norme IEEE-1394 sont parfaitement compatibles. Mais on désigne globalement par le terme FireWire autant la norme OHCI que l'une des trois versions de la norme 1394.
Les appareils FireWire sont identifiés par un numéro GUID (Global Unique ID), qui est en fait un nombre codé en clair sur 64 bits. 24 bits sont réservés aux paramètres du fabricant et 40 bits à la puce d'identification.
La mémoire est alors répartie en « quadlets », soient 4 octets, selon l'appellation de l'IEEE. Pour profiter des possibilités décrites ci-après, seules deux commandes du mode de transfert asynchrone sont nécessaires, à savoir « quadlet read request » et « quadlet write request ». La requête « write » a la structure suivante figure I.
Les champs présentant un intérêt dans le paquet sont destinationTD, destinationOffset et quadlet data. destinationID combine l'ID du bus sur 10 bits et l'ID du périphérique sur 6 bits. quaniet data comprend les données de l'instruction d'écriture, qui sont écrites sur l'adresse .:1s1 iiationDffset de 48 bits. L'adresse mémoire du périphérique est répartie comme suit :
Le paramètre « low address space » est intéressant puisqu'il représente la mémoire physique de l'appareil. La limite supérieure de la plage mémoire est déterminée en fonction du registre optionnel physicallipperBound décrit dans la norme OHCI. Elle est fixée à 4 Go lors de l'initialisation de l'appareil. Elle peut cependant être réduite si le registre optionnel est implémenté par l'équipement. L'espace de stockage, réparti sur les 48 bits de l'adressage, peut s'étendre jusqu'à 256 téraoctets, mais cela ne présente pas d'intérêt.
Ces quelques connaissances préalables permettent de mettre en avant les caractéristiques intéressantes de l'OHCI :
Norme OHCI - extrait I
« Low Address Space is from 48'hO up to physicalUpperBound. Asynchronous read and write requests into this range can be handled by the Physical RequestlPhysical Response units, providing an efficient mechanism for moving osynchronous data. »
(Traduction : "Le Low Address Space se situe entre 48'hO (0000_0000_0000) et physicalUpperBound. Les unités Physical RequestlPhysical Response exécutent les requêtes de lecture et d'écriture asynchrones contenues dans cette plage et permettent
ainsi de déplacer efficacement des données asynchrones.»)
Les unités Physical RequestlPhysical Response sont des unités fonctionnelles se trouvant sur la carte qui traitent les flux logiques à travers l'interface OHCI, et qu'on désigne par Physical Requests. (Leurs caractéristiques sont détaillées dans un chapitre de la norme).
Norme OHCI - extrait 2
« When a block or quadlet read request or quodlet write request is received, the 1394 Open HCI chip handles the operation automatically without involving software if the offset address in the request packet header meets a specific set of criteria. »
(Traduction : «Quand un bloc, une requête de lecture ou une requête d'écriture est reçue, la puce 1394 Open HO exécute l'opération automatiquement sans passer par un mécanisme logiciel, si l'offset de l'adresse contenu dans l'en-tête du paquet satisfait certains critères spécifiques».)
Cela signifie donc que, si certaines conditions sont remplies, des requêtes d'écriture et de lecture sont exécutées directement par le matériel FireWire sans intervention du pilote. Lors d'une requête, un paramètre doit se situer dans les limites du Physical Range (voir Fig. 2), c'est-à-dire précisément dans les 4 Go de la mémoire centrale. Avant de répondre, le périphérique FireWire commence par vérifier si les bits requis sont correctement placés dans les deux registres qui permettent de filtrer les requêtes. Le pilote aurait pu faire varier ce second critère s'il avait écrit dans les registres en question. Pour plus de détails sur ce point, consultez la partie « Filtre OHCI » située plus bas. On suppose en plus que les registres contiennent les valeurs correctes, rendant ainsi possible la lecture et l'écriture.
Exploitation des possibilités
Un ordinateur met entièrement sa mémoire principale (en lecture et écriture) à disposition de tous les appareils FireWire auxquels il est connecté. Cela fonctionne indépendamment du processus auquel appartient la mémoire et des droits d'accès locaux. La mémoire centrale de la carte graphique, en général, se fond à la mémoire principale de l'ordinateur, ce qui permet
d'accéder au contenu de l'écran, comme cela est expliqué ci- après. La mémoire centrale d'un ordinateur offre de nombreux points d'attaque potentiels. Elle permet par exemple de faire une recherche parmi des chaînes de caractères, lesquelles chaînes peuvent représenter des mots de passe qui auraient été gardés en mémoire par un gestionnaire de mots de passe. Une telle tentative, comme la recherche d'une clé privée d'un système de cryptographie à clé publique, est décrite en référence [2].
On peut retrouver efficacement une telle clé dans un grand volume de données, si on connaît la clé publique. Si la clé privée venait à se retrouver dans la mémoire pour une raison quelle qu'elle soit, elle pourrait être compromise. Il est en principe possible de récupérer de nombreuses informations via le système ; elles doivent cependant être correctement interprétées dans l'ordre physique incohérent de la mémoire.
Il est aisé d'écraser l'ensemble de la mémoire et de faire planter le système en écrivant directement dans les pages mémoire. Il est néanmoins plus intéressant de bloquer seulement un processus isolé ou d'écrire dans la mémoire vidéo. L'injection du code dans certains processus ou la production de nouveaux processus pourraient nuire au système en exploitant de manière plus ambitieuse certaines possibilités du FireWire.
Comment utiliser concrètement les informations précédentes ? Pour réaliser une programmation via le FireWire, il est possible de faire appel aux multiples fonctions des APIs, dont on utilisera uniquement les fonctions de base en lecture et écriture, pour exécuter un quadlet read ou quadlet write. Les lignes de code les plus importantes lors de l'écriture ressemblent à ceci :
Macg§
10CreatePlugininterfaceForService(self->aDevice,kICF1reWireLibTypeiC, klOCFPluglnInterfacelD, &cfPlugIninterface, &theScore); (*cfPluglnInterface)->QuerylnterfacelcfPlugInInterface, CFBUIDGetUU10Bytes(kI0Fir eWireDeviceInterfacelD), (void **)&fwIntf);
(*fwIntf)->Open(fwIntf);
(*fwIntf1->Write(fwIntf, self->aDevice, &fwaddr, (void    buffer, &bufsize, false,
g);
Linux Ilibraw1394 :
handle = raw1394_new_handle0;
raw1394_set port(handle, 0);
raw1394_write(handle, node_id • fwaddr, bufsize, (quadlet_t *) buf
Ces quelques lignes prouvent donc que l'accès au Physical Range (Fig. 2) est possible sans intervention logicielle et étayent nos déclarations antérieures. Pour s'en rendre compte, dans le noyau Linux, le paramètre Debug doit cependant être activé pour le support FireWire (Excessive debugging output ou CONFIG IEEE1 3 94 V E RBOSEDEBUG). Cette option permet en particulier d'écrire les entêtes de chaque paquet reçu dans Syslog. En essayant différentes adresses mémoire situées en dessous et au-dessus du registre PhysicalUpperBound (et/ou 4 Go), on peut voir que toutes les demandes situées en dessous de Pnysical UpperBound ne seront pas journalisées. Elles sont donc directement prises en charge par le matériel FireWire.
es codes ci-dessus permettant l'accès au bus FireWire ont été écrits avec l'environnement nécessaire à l'intérieur d'un module C sous Python. On peut considérer qu'ils sont facilement utilisables sous Linux et MacOS, si on fait abstraction des nombreuses étapes indispensables à la programmation sous C et l'exécution de scripts sous Python. Python offre les fonctions read et write pour lire et écrire des données, ainsi que la fonction scanbus qui permet de faire une liste de tous les appareils connectés au bus FireWire. Le module et des exemples de scripts sont développés dans [3]. Les informations qui suivent vous donnent une idée de la manière dont on peut lire et écrire directement sur la mémoire. Les codes donnés en exemple sont écrits en Python et utilisent le module Python.
Suppression du contenu d'un écran
La mémoire vive de la carte graphique va généralement être combinée à la mémoire centrale de l'ordinateur et permettre ainsi son accès direct. L'intérêt principal de cet accès est d'offrir la possibilité de pouvoir modifier l'affichage à l'écran. Pour un résultat immédiatement visible, il est possible de supprimer le contenu d'écran d'un autre ordinateur via le bus FireWire. Cela fonctionne avec le programme suivant :
addrs    OxdOc002@c2cf801'    (0)(0800[30UL, 14011, 1050, 21 }
devices = fw.scanbus()
for device in devices:
if device.guid in addrs:
base, ores, yres, bpp = addrs[device.guid]
pos = base + (xres*bpp)
ahile pos < base + (yres*xres*bpp):
print device.write(pos, "10"*(xres*bpp*4)), pos    xres*bpp*4
Les ordinateurs sont facilement identifiables par leur GUID. On peut ainsi assigner manuellement les valeurs importantes qui définissent la position et la taille de la mémoire vidéo. Le GUID du matériel FireWire se trouve facilement sous Linux, par exemple via Syslog, lorsqu'un appareil est connecté à l'ordinateur, et sur un Mac, dans la rubrique À propos de ce Mac -> Plus d'infos. Le GUID présente un intérêt, dans la mesure où il est possible de paramétrer l'adresse à laquelle la mémoire vive de la carte va se trouver. Sous Linux, elle sera écrite et pourra être récupérée par exemple dans le fichier log du serveur X. Il est important de remarquer également que l'adresse ne dépend pas directement du matériel mais bien du système d'exploitation. Il suffit alors d'écraser la mémoire en écrivant des zéros. Cela se traduit par un écran devenant noir.
Lecture de la mémoire
Pour passer de l'écriture à la lecture sur la mémoire vidéo, il n'y a qu'un pas. Toutefois, nous avons un peu simplifié la procédure d'écriture : l'écran est simplement devenu noir. Mais lorsque l'on veut convertir la mémoire en images, il est alors indispensable de connaître avec précision l'organisation physique de la mémoire vidéo. Malheureusement, il s'avère que l'organisation de la mémoire vidéo ne dépend pas uniquement du matériel utilisé mais bien du système d'exploitation et du mode vidéo utilisé par l'interface graphique. En mode texte, sous FreeBSD, vous trouverez par exemple un caractère tous les 8 octets. Il est
possible de lire la mémoire vidéo du mode texte grâce à une boucle simple
data    device,read(addrs[device.guid], 80*25*8)
data = data[::81
print "+%s+" % ("2*SO) chue data:
print "I%s]" % data[:80] data r data[M]
print '+%.s+' % ("-"*80)
Les modes graphiques sont en revanche considérablement plus difficiles. On termine généralement le processus par une combinaison en bits dans Python et une étape de post-processing via ImageMagick.
Obtention des droits root dans un processus
Lorsqu'on peut écrire dans la mémoire, il est également possible de s'octroyer les droits mot. En principe, bien sûr. Notre premier « Proof of Concept » a été de « dumper » le contenu complet de la mémoire d'un iBook dans un fichier. À l'aide d'un éditeur hexadécimal, nous avons ensuite recherché l'identifiant de l'utilisateur connecté à l'intérieur du fichier, pour retrouver ensuite les adresses correspondant à cet utilisateur. Nous avons alors programmé un script pour mettre la valeur de ces adresses à zéro. Cette tentative a immédiatement porté ses fruits : l'identifiant de l'utilisateur valant zéro, l'utilisateur obtenait alors les droits root sur la machine. Mais cela ne s'est pas fait sans engendrer des problèmes considérables : en effet, après le redémarrage, les fichiers utilisateurs situés sur le bureau s'étaient convertis en fichiers ayant les droits root. Une telle situation n'est guère étonnante, mais plutôt désagréable...
Pourtant, il est difficile de se satisfaire d'une procédure aussi peu fiable. Lors d'une conférence, les résultats d'analyse de fichiers à l'aide d'éditeur hexadécimal sont ennuyeux à présenter et d'autre part, le propriétaire de l'iBook ne souhaitait plus soumettre son appareil aux fins de cette expérience. Nous avons donc fini par « sacrifier » un ordinateur FreeBSD 5.3. La recherche de l'identifiant d'un utilisateur précis renvoyait beaucoup d'autres données ; elles avaient par ailleurs aussi été remises à zéro, engendrant une belle confusion. Nous avons alors tenté de construire une heuristique capable de reconnaître la structure du processus dans la mémoire et ne mettant les valeurs à zéro qu'a cet endroit-là. Dans la pratique, cela équivaut à rechercher, à l'aide d'expressions régulières, les valeurs typiques contenues dans la structure de description d'un processus. Il s'avéra malgré tout que de nombreuses données avaient été remises à zéro, données qu'on aurait préféré ne pas toucher, sans oublier l'instabilité postérieure de l'ordinateur. Mais il est évident que pour une première tentative, cela est satisfaisant et permet au pirate ayant un accès physique de récupérer un shell root sans rien faire ou presque.
Un iPod pour pénétrer dans la mémoire
L'iPod commercialisé par Apple n'est pas seulement un lecteur MP3, mais également un appareil disposant d'une interface FireVVire et d'un disque dur interne. De plus, une distribution Linux a même été développée pour l'iPod. De taille
limenté grâce à une batterie, l'iPod se révèle un outil parfait pour transposer les concepts décrits plus haut, mis en pratique sur d'autres machines. L'installation d'iPodLinux est très bien décrite sur les pages du projet [4]. Il existe toutefois une différence par rapport à la distribution normale : le module noyau raw1394 doit être compilé. C'est pourquoi il est nécessaire d'aménager un peu le système si vous installez Linux sur un iPod.
L'iPod doit être démarré dans le mode Disque à l'installation ; il suffit pour cela d'appuyer simultanément sur les touches « Back » et « Forward » pour un iPod de la troisième génération ou sur « Menu » et « Select » pour un modèle de la quatrième génération. La quatrième génération d'iPod n'est cependant pas officiellement supportée par iPodLinux, et n'est pas compatible FireWire. C'est pourquoi nous poursuivons notre exemple avec un iPod de troisième génération. En mode Disque, l'iPod sera reconnu comme appareil SCSI grâce au module SBP2 et associé à /dev/sda. Le firmware devra par ailleurs être sauvegardé grâce à dd if=idev/sda1 of=ipod_os_partition_backup, de manière à pouvoir revenir au mode normal baladeur. On partitionne ensuite le disque dur pour générer un nouveau système de fichiers (n'oubliez pas de sauvegarder préalablement les données importantes contenues dans votre iPod). L'iPod peut alors être monté sur ce système de fichiers avec court -t ext3 /dev/sda3 /mmt/ipod.
Une première étape pour la personnalisation du noyau sera d'installer les GNU Toolchains, qui comprennent un compilateur et des outils de cross-compilation pour l'architecture ARM du iPod. Vous trouverez une version binaire du projet Linux! Microcontroller aux liens indiqués en [4]. Ce projet repose sur un noyau 2.4.24, lequel est fourni avec des patches spéciaux pour l'iPod et des fichiers de configuration également spécifiques pour l'iPod. À ce stade, la procédure est différente des instructions données parce que le noyau doit contenir le module r a w1394. On appelle alors par exemple make mer ucon fi g et on choisit, dans le menu « IEEEI394 (FireWire) Support », l'option « Raw IEEE 1394 I/O support » en tant que module. On termine enfin en supprimant la fonction raw1394_rnmap et sa référence dans la
structure file ops qui apparaissent dans le fichier rux-2.4.241
drivers/ieee1394/raw1394.c. Cette dernière n'est pas utile et pourrait engendrer une erreur au chargement du module sur l'iPod. On continue ensuite avec la « construction du noyau »
(c'est-à-dire le paramétrage de my sw. bi m avec rra ke_f w et la
copie sur l'iPod via cid). Si l'iPod est disponible sous /innt/i pod, les modules peuvent ensuite être installés depuis le répertoire principal du noyau fraîchement compilé par la commande cake nsodul nstal 1 INSTALL_MOD_PATh=/mmt/i pod.
Il faut maintenant procéder à l'installation du reste du système d'exploitation sur l'iPod (section « Userland installation »), en adaptant certains fichiers et installant la version en cours de l'interface utilisateur graphique Podzilla (section « Finishing up »). À cause de l'installation du module raw1394, les lignes suivantes doivent être ajoutées au fichier /etc/rc
modprobe tsb43aa82
mknod -m uo /dev/raw1394 c 171 0
modprobe raw1394
Si vous ne souhaitez pas faire le travail vous-même, vous pouvez aussi télécharger notre version d'installation depuis [5] et importer les images des partitions sdal et sda3 sur votre iPod.
Filtre OHCI
Parallèlement à la lecture et à l'écriture directe sur l'unité Physical Response, la norme OHCI offre la possibilité d'empêcher cet accès. Les registres de 64 bits AsynchronousRequestFilter et Physi cal RequestFil ter sont prévus à cet effet. Dans les deux cas, un bit représente un appareil du bus FireWire. Ce bit mis à zéro dans le registre AsynchromousRequestFilter empêche généralement tout appareil d'accéder à la mémoire physique du système local. Cela permet ainsi de couper la liaison FireWire si nécessaire. Mais cela vous fait cependant passer à côté d'autres utilisations.
Plus important, le registre Physical RequestFi 1 ter interdit tout accès direct à un nœud (si le bit est remis à 0) sur l'unité Physical Response du noeud local, et remet la responsabilité au pilote au lieu du noeud en question. Le pilote identifie chaque tentative d'accès à la mémoire physique et peut décider au cas par cas s'il accepte la tentative d'accès ou la rejette. Pour plus de détails sur la norme OHCI, voir [i], paragraphe 5.14. Cette possibilité d'empêcher l'accès à la mémoire grâce au registre Rhys i cal Req uestPi 1 ter est prévue dans les pilotes Linux et Mac OS. Elle peut être activée facilement :
Lino, : ohci1394.c
/* Accept Physical requests from all socles, '1 reg_write(ohci3OHCI1394 JsRegFilterHiSet, Dxffffffff);
reg jiritelohci3OHC11394_AsRegFilterLoSet, Dxff ffffff 1;
/* Turn on phys dma reception.
* TODO: Enable some sort of filtering management. */
if (phys_dma) {
regirite(ohci3O1-1C11394_PhyReqFilterHiSet, Dxffffffff); regwrite(ohci3OHCI1394_PhyRegrilterLoSet, hfifffffff ); reg_write(ohci3O1-1CI1394_PhyRoperBoune, 0efff00001;
else {
reg write(ohoi3O4C11394_PhyReqFilteriliSet, DicIN00H00); reg_write(ohc1,01-1C11394_PhyReqFilterLoSet, Ox0D00BOD01;
DI3GMSG("PhyReqFilter=%08xgfix",
reg reaC(ohci3O0C11394_PhyRegFilterHiSet), reg_read(ohci,DHC11394_PhyRegFilterloSet)); MacOS X    10FireWireController.cop
IOUSecurityMode modo = klOrk1SecurityhiodeNormal ; OSString    securityModeProperty = OSDynamicCasti

if( securityModeProperty !. NULL
strup("nene", securityModeProperty->getC5tringlioCopy()) [.    )
// set security mode te secure/permanent mode    ŒFWSecurityModeSecurePermanent;
1
et ensuite :
// shut them ail clown!
fFWIM->sethdell)PhysicalFilter( kl0FWAllPhysicalFilters, false );
Pour empêcher l'accès sous Linux, les paramètres de la variable pnys_cma du fichier ohci 1393 .0 doivent être définis en chargeant le module, par exemple avec la commande modprcbe ohci 1394 phys_rinia =IO. Sur un système MacOS X 10.3, il existe un équivalent avec le fichier I0Fi reWl reController.cpp si le « security mode » de l'Open Firmware actuel renvoie une autre valeur que « none ». C'est dans ce fichier que les registres Physi cal RequestFilter seront remis à 0. Mais cette fonctionnalité n'est pour l'instant pas documentée. Ce dont nous sommes certains c'est que la version actuelle de MacOS X ne permet plus cet accès. NetBSD reconnaît bien le matériel FireWire et les appareils FireWire connectés, mais ne permet cependant aucun accès. Les registres sont directement placés dans un mode sûr. On peut le vérifier dans le code source avec fwohci .c.. Sous Windows, l'accès n'est pas possible non plus. Sur les anciennes versions de Windows 2000, cela venait tout simplement du fait que le système se bloquait dès qu'il était connecté à un Mac via une liaison FireVVire. Sur Windows XP, la connexion ne fonctionne pas, et donc l'accès est par le fait même impossible. Est-ce parce que les registres sont initialisés en mode sûr ou parce que ceux-ci demeurent dans leur état de démarrage lors de l'initialisation du matériel ? Impossible d'examiner la situation dans la mesure où aucun code source ni documentation ne sont disponibles.
Analyses post-mortem
Bien que les filtres soient finalement implémentés partout, il est possible de permettre à certains systèmes l'accès à la mémoire, et d'effectuer ainsi des analyses sur un ordinateur sous tension. Jusqu'à présent, il existe deux possibilités pour une analyse éteindre l'ordinateur et réaliser une analyse post-mortem, ce qui détruit les informations dans les processus en cours, ou récolter des informations sur un système sous tension, ce qui peut engendrer la disparition de preuves importantes. On peut résoudre le problème en réalisant un vidage complet de la mémoire via la liaison FireWire, sans pour autant modifier le système. Le défi de cette solution repose, entre autres, sur l'assignation de la mémoire physique par rapport à la disposition logique de la mémoire, car il s'agit de faire ressortir des données
utilisables de la mémoire qui a été vidée. Pour l'instant, il n'existe pas de logiciel qui permette une analyse post-mortem précise d'un programme à partir d'une image mémoire brute. Cela sous- entend que l'on peut certes rechercher des chaînes dans ce type d'image mémoire, mais que pour réaliser des recherches plus approfondies, comme par exemple, l'examen des connexions réseau ouvertes ou autres, les outils font actuellement défaut.
Conclusion
Quelle conclusion peut-on tirer de l'histoire du FireWire si ce n'est une évidence ? Les ports FireWire font partie du Trusted Computing Base (TCB). On ne devrait les relier qu'a des appareils dignes de confiance, ou le cas échéant, les bloquer ou les verrouiller. On peut supposer que d'ici peu on fera état de tel ou tel hack via FireWire, comme par exemple un piratage de fond d'écran, ou des manipulations sur des terminaux publics via des ports FireWire, tel qu'il en existe déjà sur les appareils des laboratoires photos. Mais l'aspect le plus intéressant est en fait le manque de communication entre les différentes communautés. Pour les développeurs de pilotes, il était connu que le FireVVire permettait un accès direct à fa mémoire. Cet accès est même utilisé depuis longtemps pour le débogage. Mais les implications liées à la sécurité n'ont jamais été prises au sérieux. Et, pendant longtemps, la communauté dite de sécurité ignorait tout de ces « caractéristiques ». Aussi, aujourd'hui, nous souffrons d'un manque cruel de communication. Des filtres OHCI sont installés par défaut ça et là, mais ils ne sont jamais documentés et il n'est pas aisé de deviner à quelle version d'OS s'adressent les règles de filtres OHCI. C'est pour cette raison qu'il semble urgent que la communauté de sécurité informatique et les fabricants de matériel collaborent plus activement sur ce thème mais également sur d'autres sujets, comme par exemple, l'USB.