Je dois tester la résilience de certains codes de lecture/écriture pour du matériel embarqué. Comment pourrais-je sacrifier quelques cartes SD et casser plusieurs secteurs connus pour une étude contrôlée ?
La seule chose à laquelle je peux penser est d'écraser un seul secteur plusieurs millions de fois. Je me demande si un script Linux badblocks peut être créé pour exécuter son test destructeur sur un seul secteur de manière répétée pendant plusieurs heures.
Une approche alternative qui peut être utile.
Si votre code s'exécute sous Linux, vous pouvez peut-être le tester avec un périphérique logique "défectueux". dmsetup peut créer des périphériques qui renvoient des erreurs d'I/O. Il vous suffit de construire votre périphérique en utilisant les cibles error et/ou flakey. D'après man 8 dmsetup :
error
Erreurs de toutes les I/O qui vont vers cette zone. Utile pour les tests ou pour créer des périphériques présentant des lacunes.
flakey
Crée un mappage similaire à la ciblelinearmais présente un comportement peu fiable de manière périodique. Utile pour simuler des périphériques défaillants lors des tests.
Remarque : l'utilisation de la cible flakey est documentée ici. Exemple de base ici.
D'après ce que je sais, une erreur d'I/O sera signalée immédiatement, ce qui est différent du comportement réel d'une carte SD où l'on peut s'attendre à des retards, des blocages, etc. Néanmoins, je pense que cette approche peut être utile dans certains cas, au moins pour effectuer des tests préliminaires rapides, ou quelque chose du genre.
Ce gars a piraté le microcontrôleur à l'intérieur des cartes SD utilisées pour marquer les blocs défectueux : https://www.bunniestudios.com/blog/?p=3554
Vous pourriez faire la même chose et marquer arbitrairement des blocs comme défectueux.
Aujourd'hui, lors du Chaos Computer Congress (30C3), xobs et moi avons révélé une découvertes selon laquelle certaines cartes SD contiennent des vulnérabilités qui permettent l'exécution de code arbitraire - sur la carte mémoire elle-même. Du côté obscur, l'exécution de code sur la carte mémoire permet une classe d'attaques MITM (homme du milieu), où la carte semble se comporter d'une certaine manière, mais en fait elle fait quelque chose d'autre. Du côté lumineux, cela permet également la possibilité pour les amateurs de matériel d'accéder à une source très bon marché et omniprésente de microcontrôleurs.
.
Ces algorithmes sont trop compliqués et trop spécifiques à l'appareil pour être exécutés au niveau de l'application ou du système d'exploitation, il s'avère donc que chaque disque de mémoire flash est livré avec un microcontrôleur relativement puissant pour exécuter un ensemble personnalisé d'algorithmes d'abstraction de disque. Même la minuscule carte microSD contient non pas un, mais au moins deux puces - un contrôleur, et au moins une puce flash (les cartes à haute densité empilent plusieurs matrices flash).
.
Le microcontrôleur intégré est généralement un CPU 8051 ou ARM fortement modifié. Dans les implémentations modernes, le microcontrôleur atteindra des niveaux de performance d'environ 100 MHz, et disposera également de plusieurs accélérateurs matériels sur la puce. Étonnamment, le coût d'ajout de ces contrôleurs au dispositif est probablement de l'ordre de 0,15 à 0,30 $, en particulier pour les entreprises capables de fabriquer à la fois la mémoire flash et les contrôleurs au sein de la même unité commerciale. Il est probablement moins cher d'ajouter ces microcontrôleurs que de tester et caractériser minutieusement chaque puce de mémoire flash, ce qui explique pourquoi les dispositifs de mémoire flash gérés peuvent être moins chers par bit que les puces flash brutes, malgré l'inclusion d'un microcontrôleur.
.
L'essence du problème est qu'un mécanisme de chargement et de mise à jour du micrologiciel est pratiquement obligatoire, surtout pour les contrôleurs tiers. Les utilisateurs finaux sont rarement exposés à ce processus, car tout se passe à l'usine, mais cela ne rend pas le mécanisme moins réel. Dans mes explorations des marchés électroniques en Chine, j'ai vu des commerçants graver des micrologiciels sur des cartes qui "étendent" la capacité de la carte - en d'autres termes, ils chargent un micrologiciel qui rapporte que la capacité d'une carte est beaucoup plus grande que le stockage réel disponible. Le fait que cela soit possible au point de vente signifie très probablement que le mécanisme de mise à jour n'est pas sécurisé.
Dans notre présentation à 30C3, nous relatons nos découvertes en explorant une marque de microcontrôleur particulière, à savoir, Appotech et ses offres AX211 et AX215. Nous découvrons une simple séquence de "knock" transmise via des commandes réservées au fabricant (à savoir, CMD63 suivie de 'A', 'P', 'P', 'O') qui plongent le contrôleur en mode de chargement d'un micrologiciel. À ce stade, la carte acceptera les 512 prochains octets et les exécutera en tant que code.
Cela ne fonctionnera généralement pas car la plupart des cartes SD récentes (ou eMMC) utilisent un nivellement d'usure statique et dynamique, ce qui signifie qu'un contrôleur intelligent interprète votre instruction d'écriture et la mappe sur l'un des secteurs flash les moins utilisés.
La seule chose que vous pourriez faire est essayer de contacter vos fournisseurs et leur demander leur fiche technique; il pourrait y avoir des moyens (spécifiques au fournisseur) pour récupérer l'état de leur algorithme de nivellement d'usure. Cela vous permettrait potentiellement de interroger l'état/l'utilisation du flash sous-jacent. Ou vous pourriez ne pas avoir de chance et cela pourrait ne pas exister.
Si votre but est vraiment de détruire le flash, tout ce que vous pourriez faire est d'exécuter des cycles de lecture et écriture massifs et de vérifier continuellement que les données que vous lisez sont toujours cohérentes. Par exemple, créez deux gros fichiers, stockez leurs sommes de contrôle et lisez/écrivez-les dans l'ordre pour vérifier leurs sommes de contrôle. Plus le flash est grand, plus ce processus prendra de temps.
Préface : Cette option nécessite des programmations supplémentaires et des modifications matérielles, mais permettrait des lectures contrôlées probablement transparentes pour l'hôte.
Une carte SD propose plusieurs options d'E/S, mais peut être contrôlée via SPI. Si vous preniez une carte SD et la modifiez pour pouvoir connecter les broches à un microcontrôleur (tel qu'un Arduino), vous pourriez faire en sorte que l'Arduino imite la carte SD et soit transparent pour le dispositif lisant la carte SD. Votre code sur le microcontrôleur pourrait délibérément renvoyer de mauvaises données au besoin. De plus, vous pourriez mettre une carte SD sur le microcontrôleur afin que les lectures puissent passer par le microcontrôleur jusqu'à la carte SD pour permettre des tests de gigaoctets.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
