J'ai besoin de tester la résilience de certains codes en 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, c’est d’écraser un seul secteur quelques millions de fois. Je me demande si un script Linux badblocks peut être créé pour exécuter son test destructif sur un même secteur de manière répétée pendant plusieurs heures.
Une approche alternative qui peut peut être utile.
Si votre code fonctionne 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'E/S. Il suffit de construire votre appareil en utilisant error
et/ou flakey
target. De man 8 dmsetup
:
error
Erreurs de toute entrée/sortie qui se rend dans cette zone. Utile pour tester ou pour créer des appareils avec des trous.
flakey
Crée un mappage similaire à la ciblelinear
mais présente un comportement non fiable périodiquement. Utile pour simuler les périphériques défaillants lors des tests.
Remarque: L’utilisation de la cible flakey
est documentée ici . Exemple de base ici .
Autant que je sache, une erreur d’entrée/sortie sera immédiatement signalée. C’est donc différent du comportement réel de la carte SD dans lequel vous pouvez vous attendre à un délai, à un blocage, etc. Néanmoins, je pense que cette approche peut être utile dans certains cas, du moins pour une exécution rapide. test préliminaire ou si.
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 pourrez peut-être faire la même chose et marquer arbitrairement des blocs comme défectueux.
Aujourd’hui, au Chaos Computer Congress (30C3), xobs et moi-même avons révélé qu’une carte SD contenait des vulnérabilités permettant l’exécution arbitraire de code - sur la carte mémoire elle-même. Du côté obscur, l’exécution de code sur la carte mémoire active une classe d’attaques MITM (homme du milieu), où la carte semble se comporter dans un sens, mais fait en réalité autre chose. D'un autre côté, cela permet également aux passionnés de matériel d'accéder à une source de microcontrôleurs très bon marché et omniprésente.
.
Ces algorithmes sont trop compliqués et trop spécifiques à un périphérique pour être exécutés au niveau de l'application ou du système d'exploitation. Ainsi, chaque disque de mémoire flash est livré avec un microcontrôleur assez puissant pour exécuter un ensemble personnalisé d'algorithmes d'abstraction de disque. Même la petite carte microSD contient non pas une, 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 processeur 8051 ou ARM fortement modifié. Dans les implémentations modernes, le microcontrôleur atteindra des niveaux de performance de 100 MHz et disposera de plusieurs accélérateurs matériels sur puce. Étonnamment, le coût d’ajout de ces contrôleurs à l’appareil est probablement de l’ordre de 0,15 à 0,30 USD, en particulier pour les entreprises capables de fabriquer à la fois la mémoire flash et les contrôleurs d’une même unité. Il est probablement moins coûteux d’ajouter ces microcontrôleurs que de tester et de caractériser minutieusement chaque puce de mémoire flash, ce qui explique pourquoi les périphériques flash gérés peuvent être moins chers par bit que les puces flash brutes, malgré l’inclusion d’un microcontrôleur.
.
Le point crucial est qu’un mécanisme de chargement et de mise à jour du microprogramme est pratiquement obligatoire, en particulier pour les contrôleurs tiers. Les utilisateurs finaux sont rarement exposés à ce processus, puisque tout se passe en usine, mais cela ne rend pas le mécanisme moins réel. Dans mes explorations des marchés de l'électronique 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 chargeaient un micrologiciel qui signalait que la capacité d'une carte était bien plus grande que la espace de stockage disponible réel. Le fait que cela soit possible sur le point de vente signifie très probablement que le mécanisme de mise à jour n'est pas sécurisé.
Dans notre exposé de 30C3, nous rapportons nos résultats 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 par des commandes réservées au fabricant (à savoir CMD63, suivies de «A», «P», «P», «O») qui placent le contrôleur dans un mode de chargement de microprogramme. À ce stade, la carte acceptera les 512 octets suivants et l'exécutera en tant que code.
Cela ne fonctionne généralement pas car les cartes SD (ou eMMC) les plus récentes 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 puissiez faire est d’essayer de contacter vos fournisseurs et de demander leur fiche technique; il peut y avoir des moyens (spécifiques au fournisseur) de récupérer l'état de leur algorithme de mise à niveau. Cela vous permettrait potentiellement d'interroger l'état/l'utilisation du flash sous-jacent. Ou vous pourriez être malchanceux et cela pourrait ne pas exister.
Si votre objectif est réellement de détruire le flash, tout ce que vous pouvez faire est d'exécuter des cycles de lecture et d'écriture massifs et de vérifier en permanence que les données que vous lisez sont toujours cohérentes. Par exemple. créer deux fichiers volumineux, stocker leurs sommes de contrôle et les lire/écrire afin de vérifier leur somme de contrôle. Plus le flash est grand, plus ce processus prendra longtemps.
Vous pouvez augmenter l'usure du transistor en augmentant la température de fonctionnement. Utilisez des cycles d'écriture-effacement sur une puce chauffée (70-120 ° C); il va porter plus vite.
Préface: Cette option nécessite une programmation supplémentaire et des modifications matérielles, mais elle permettrait des lectures contrôlées transparentes pour l'hôte.
Une carte SD possède plusieurs options d'E/S, mais elle peut être contrôlée via SPI. Si vous deviez prendre une carte SD et la modifier afin de pouvoir relier les broches à un microcontrôleur (tel qu’un Arduino), l’Arduino pourrait imiter la carte SD et rester transparent pour le périphérique qui la lisait. Votre code sur le microcontrôleur peut à dessein renvoyer des données incorrectes en cas de besoin. En outre, vous pouvez installer une carte SD sur le microcontrôleur afin que les lectures puissent passer à travers le microcontrôleur sur la carte SD pour permettre des tests de plusieurs gigaoctets.
Je voudrais aller à ebay/aliexpress et acheter la carte SD la moins chère que je puisse trouver en Chine, celle qui est "trop belle pour être vraie". Ils viennent souvent avec des secteurs défectueux ou sont dans un ensemble de logiciels beaucoup plus gros qu’ils ne le sont réellement. De toute façon, vous devriez vous retrouver avec une carte SD défectueuse à utiliser pour les tests.
Il était une fois, il y a de nombreuses années, j'étais payé pour récupérer un ensemble de photos et de vidéos de fin d'études d'une carte SD pour une mère plutôt désemparée. Après une inspection minutieuse, la carte avait été physiquement endommagée, avec une fissure visible dans le boîtier externe et plusieurs secteurs défectueux, notamment plusieurs secteurs critiques précoces, qui rendaient même les programmes de récupération les plus fiables à ce moment-là complètement lus. . En outre, les outils de données médico-légales coûtaient alors une fortune.
J'ai fini par obtenir une carte SD de marque/taille identique et d'écrire mon propre utilitaire de copie et de restauration de données brutes personnalisé pour copier les données de la mauvaise carte vers la bonne. Chaque fois que le service public rencontrait un secteur défectueux, il réessayait plusieurs fois avant d'écrire tous les zéros pour ce secteur et, au lieu d'abandonner et d'arrêter, ignorait l'échec et passait au secteur suivant. Les tentatives ont été tentées à nouveau, car j’avais également remarqué que certains secteurs avaient encore un taux de réussite de lecture de 40% environ. Une fois les données stockées sur la nouvelle carte SD, les outils de récupération qui avaient échoué auparavant fonctionnaient parfaitement, avec une perte/corruption de données minimale. Dans l’ensemble, environ 98% de tous les fichiers ont été récupérés. Un certain nombre d'éléments précédemment supprimés ont également été récupérés, car rien n'est jamais réellement supprimé - ils sont simplement marqués comme tels et lentement remplacés. Ce qui a commencé comme un exercice de récupération de données légèrement ennuyeux est devenu l’un de mes projets de développement de logiciels personnels les plus mémorables et les plus intéressants. Au cas où vous vous le demanderiez, la mère était ravie.
Quoi qu’il en soit, cette histoire montre qu’il est possible d’endommager physiquement une carte SD de telle sorte que les données restent accessibles mais que certains secteurs ne fonctionnent que très peu et que tout lecteur qui tente de le lire puisse avoir de la difficulté à le faire. Le plastique de la carte SD a tendance à être assez fragile, alors plier ou couper des morceaux bon marché peut faire l'affaire. Votre kilométrage peut varier.
Vous pouvez également demander à certains endroits de la récupération de données dans votre région. Dans la mesure où ils se spécialisent dans la récupération de données à partir de divers périphériques défaillants ou défaillants, ils doivent disposer de conseils/astuces utiles et peuvent même disposer de cartes SD pré-décomposées (par exemple, à des fins de formation).
Cette réponse est une extension du commentaire de @Ruslan
Alternative possible:
Vous n'êtes pas sûr que cela fonctionne à vos fins, mais peut-être que cela suffira réellement à endommager physiquement votre carte, ce qui pourrait être beaucoup plus rapide.
Certaines cartes SD de faible capacité (16 Mo) utilisent des puces flash dans des packages de style TSOP/TSSOP. Un atelier capable de retravailler SMT (si vous effectuez un travail intégré, vous pouvez disposer de cette compétence en interne, sinon vérifiez si les petites entreprises effectuent des réparations au niveau du téléphone/de l'ordinateur portable au niveau du conseil d'administration) pourrait éventuellement séparer et rattacher cette puce, afin qu'elle puisse être lue et écrite. raw (y compris les codes ECC) avec un programmeur d’appareil.
Néanmoins, sachez que vous allez principalement tester:
et dans le pire des cas
Si vous souhaitez simplement vérifier le comportement erratique d’une carte SD pour une raison quelconque, il est probablement préférable d’introduire simplement du bruit électrique dans les lignes d’interface (en plaçant par exemple un commutateur de bus FET entre à une source de signaux non sensés (des bons niveaux électriques cependant).
Vous pouvez essayer d’introduire une alimentation instable ou une signalisation de tension plus élevée.
Une erreur commune à une famille d’appareils que je connais a une forte corrélation entre la corruption de la carte SD et le contact intermittent de la batterie.
Relatif à la réponse d'OlafM, mais différent: vous pouvez programmer votre propre microcontrôleur pour qu'il parle le protocole de la carte SD, puis émuler le comportement que vous souhaitez.
Ce n’est peut-être pas la direction que vous souhaitiez mais j’ai trouvé que retirer ma carte SD pendant que ma radio ou mon ordinateur portable lisait garantissait une carte SD bloquée environ 1/5 ou 1/10 fois. Il semble que les cartes ne fonctionnent pas bien lorsque le courant est coupé pendant une lecture et probablement écrites. Après avoir lu les commentaires de Robert Calhoun ci-dessous, cela me porte à croire que cela pourrait endommager le FAT. Bien que je ne sache pas pourquoi la simple lecture provoque un blocage - il ne devrait y avoir aucune écriture en cours?
La zone FAT32 Master Boot Record est probablement la plus susceptible d’être utilisée de manière abusive car, d’un point de vue logique, elle doit toujours se trouver au même endroit. (Peut-être que cela est géré par le remappage en douceur des secteurs défectueux, mais je suis un peu sceptique quant à son implémentation sur tout le matériel.) Vous pouvez donc exécuter sfdisk
dans une boucle et voir si vous pouvez le détruire de cette façon.
Mais je vais vous prier de faire tout ce qui est en votre pouvoir pour améliorer la fiabilité du matériel, au lieu d'essayer de gérer un matériel défectueux dans un logiciel. Le problème, c’est que les cartes SD échouent de toutes sortes de façons étranges. Elles deviennent illisibles, deviennent illisibles, vous donnent de mauvaises données, elles expirent lors d'opérations, etc. Il est très difficile de prédire tous les moyens par lesquels une carte peut échouer.
Voici l'un de mes échecs préférés, le "mode big data":
Les cartes SD sont des produits de consommation courante qui subissent une pression énorme sur leurs coûts. Les pièces changent rapidement et les fiches techniques sont difficiles à obtenir. Les produits contrefaits ne sont pas inconnus. Pour le stockage bon marché, ils sont difficiles à battre, mais si les SSD font de la fiabilité une priorité, la priorité des cartes SD est la vitesse, la capacité et le coût (probablement pas dans cet ordre).
Votre première ligne de défense consiste à utiliser une pièce soudable eMMC avec une vraie fiche technique d'un fabricant de bonne réputation au lieu d'une carte SD amovible. Oui, ils coûtent plus cher par Go, mais la pièce sera en production plus longtemps et au moins, vous savez ce que vous obtenez. Souder la pièce évite également une foule de problèmes potentiels (cartes éjectées pendant les écritures, mauvais contact électrique, etc.) avec une carte amovible.
Si votre produit nécessite un stockage amovible ou qu'il est trop tard pour changer quoi que ce soit, envisagez de dépenser plus d'argent pour les cartes de qualité «industrielle» ou de les traiter comme des objets jetables. Ce que nous faisons (sous linux) correspond à fsck
la carte au démarrage et la reformate si des erreurs sont signalées, car le reformatage est acceptable dans ce cas d’utilisation. Ensuite, nous fsck
il à nouveau. S'il signale toujours des erreurs après le reformatage, nous le RMA et remplaçons le matériel par une variante plus récente utilisant eMMC.
Bonne chance!
Si votre carte SD est au format FAT32, vous pouvez éditer les 2 graisses en hexadécimal et marquer un secteur comme défectueux avec le code hexadécimal correct. Ce n'est qu'une astuce si vous voulez tester logiquement un logiciel supposé trouver un secteur défectueux à cet endroit particulier; cela ne nuira pas à votre carte SD non plus, un reformatage la ramènera à un état normal.
Je me demande si un script Linux badblocks peut être créé pour exécuter son test destructif sur un même secteur de manière répétée pendant plusieurs heures.
Sur un seul secteur - non, car le code de correction d'usure à l'intérieur de la carte SD remappera les blocs logiques dans tous les sens.
Mais vous pouvez facilement exécuter badblocks -w
dans une boucle jusqu’à ce que les blocs quelques mauvais apparaissent. Quelque chose comme ça devrait marcher:
while badblocks -w /dev/xx; do :; done
en supposant que badblocks renvoie 0 si aucun bloc défectueux n'a été détecté et ≠ 0 sinon (la page de manuel ne dit pas et je n'ai pas vérifié le code source.)