¿Cómo puedo romper / dañar intencionalmente un sector en una tarjeta SD?

Necesito probar la resistencia de algún código de lectura / escritura para algún hardware integrado. ¿Cómo podría sacrificar algunas tarjetas SD y romper varios sectores conocidos para un estudio controlado?

Lo único que se me ocurre es sobrescribir un solo sector unos pocos millones de veces. Me pregunto si se puede crear un script de bloques defectuosos de Linux para ejecutar su prueba destructiva en un solo sector repetidamente durante varias horas.

Un enfoque alternativo que puede ser útil.

Si su código se ejecuta en Linux, tal vez pueda probarlo con un dispositivo lógico "defectuoso". dmsetuppuede crear dispositivos que devuelvan errores de E / S. Simplemente construya su dispositivo usando errory / o flakeyobjetivo. De man 8 dmsetup:

error
Errores cualquier E / S que vaya a esta área. Útil para probar o para crear dispositivos con agujeros en ellos.

flakey
Crea un mapeo similar al linearobjetivo pero exhibe un comportamiento poco confiable periódicamente. Útil para simular dispositivos con fallas durante las pruebas.

Nota: flakeyel uso objetivo está documentado aquí . Ejemplo básico aquí .

Hasta donde sé, se informará de inmediato un error de E / S, por lo que es diferente del comportamiento real de la tarjeta SD, donde puede esperar retrasos, retrasos, etc. Sin embargo, creo que este enfoque puede ser útil en algunos casos, al menos para realizarlo rápidamente prueba preliminar más o menos.

Este tipo hackeó el microcontrolador dentro de las tarjetas SD utilizadas para marcar bloques defectuosos: https://www.bunniestudios.com/blog/?p=3554

Es posible que pueda hacer lo mismo y marcar arbitrariamente los bloques como defectuosos.

Hoy, en el Chaos Computer Congress (30C3), xobs y yo revelamos que algunas tarjetas SD contienen vulnerabilidades que permiten la ejecución de código arbitrario, en la tarjeta de memoria. En el lado oscuro, la ejecución de código en la tarjeta de memoria permite una clase de ataques MITM (hombre en el medio), donde la tarjeta parece comportarse de una manera, pero de hecho hace otra cosa. Del lado de la luz, también permite a los entusiastas del hardware tener acceso a una fuente de microcontroladores muy barata y ubicua.

.

Estos algoritmos son demasiado complicados y específicos del dispositivo para ejecutarse a nivel de aplicación o sistema operativo, por lo que resulta que cada disco de memoria flash se entrega con un microcontrolador razonablemente potente para ejecutar un conjunto personalizado de algoritmos de abstracción de disco. Incluso la diminuta tarjeta microSD contiene no uno, sino al menos dos chips: un controlador y al menos un chip flash (las tarjetas de alta densidad acumularán múltiples matrices flash).

.

El microcontrolador incorporado suele ser una CPU 8051 o ARM muy modificada. En las implementaciones modernas, el microcontrolador se acercará a los niveles de rendimiento de 100 MHz y también tendrá varios aceleradores de hardware en matriz. Sorprendentemente, el costo de agregar estos controladores al dispositivo probablemente sea del orden de $ 0.15- $ 0.30, particularmente para las empresas que pueden fabricar tanto la memoria flash como los controladores dentro de la misma unidad de negocios. Probablemente sea más barato agregar estos microcontroladores que probar y caracterizar a fondo cada chip de memoria flash, lo que explica por qué los dispositivos flash administrados pueden ser más baratos por bit que los chips flash sin procesar, a pesar de la inclusión de un microcontrolador.

.

El quid de la cuestión es que un mecanismo de carga y actualización de firmware es prácticamente obligatorio, especialmente para controladores de terceros. Los usuarios finales rara vez están expuestos a este proceso, ya que todo sucede en la fábrica, pero esto no hace que el mecanismo sea menos real. En mis exploraciones de los mercados de la electrónica en China, he visto a los comerciantes quemando firmware en tarjetas que "expanden" la capacidad de la tarjeta; en otras palabras, cargan un firmware que informa que la capacidad de una tarjeta es mucho mayor que Almacenamiento disponible real. El hecho de que esto sea posible en el punto de venta significa que lo más probable es que el mecanismo de actualización no esté asegurado.

En nuestra charla en 30C3, informamos nuestros hallazgos explorando una marca particular de microcontroladores, a saber, Appotech y sus ofertas AX211 y AX215. Descubrimos una secuencia simple de "golpe" transmitida a través de comandos reservados por el fabricante (es decir, CMD63 seguido de 'A', 'P', 'P', 'O') que colocan el controlador en un modo de carga de firmware. En este punto, la tarjeta aceptará los siguientes 512 bytes y lo ejecutará como código.

Esto generalmente no funcionará porque las tarjetas SD más recientes (o eMMC) usan nivelación de desgaste estática y dinámica, lo que significa que un controlador inteligente interpreta su instrucción de escritura y la asigna a uno de los sectores flash menos utilizados.

Lo único que puede hacer es tratar de contactar a sus proveedores y solicitar su hoja de datos; Puede haber algunas formas (específicas del proveedor) para recuperar el estado de su algoritmo de nivelación de desgaste. Potencialmente, esto le permitirá consultar el estado / uso del flash subyacente. O puede que tengas mala suerte y esto puede no existir.

Si su objetivo es realmente destruir flash, todo lo que puede hacer es ejecutar ciclos masivos de lectura y escritura y verificar continuamente que los datos que está leyendo siguen siendo consistentes. Por ejemplo, cree dos archivos grandes, almacene sus sumas de verificación y léalas / escríbalas para verificar su suma de verificación. Cuanto más grande sea el flash, más tiempo llevará este proceso.

Puede aumentar el desgaste del transistor aumentando la temperatura de operación. Use ciclos de borrado de escritura en un chip calentado (70-120 ° C); Se desgastará más rápido.

Prefacio: esta opción requiere programación adicional y modificaciones de hardware, pero permitiría lecturas controladas muy probablemente transparentes para el host.

Una tarjeta SD tiene múltiples opciones de E / S, pero se puede controlar a través de SPI. Si tomara una tarjeta SD y la modificara para poder conectar los pines a un microcontrolador (como un Arduino), podría hacer que el Arduino imite la tarjeta SD y sea transparente para el dispositivo que lee la tarjeta SD. Su código en el microcontrolador podría devolver datos incorrectos a propósito cuando sea necesario. Además, puede colocar una tarjeta SD en el microcontrolador para que las lecturas puedan pasar a través del microcontrolador a la tarjeta SD para permitir gigabytes de prueba.

Iría a eBay / AliExpress y compraría la tarjeta SD más barata que pueda encontrar en China, la que es "demasiado buena para ser verdad". A menudo vienen con sectores defectuosos o están configurados en software para ser mucho más grandes de lo que realmente son. De cualquier manera, debe terminar con una tarjeta SD defectuosa para usar en las pruebas.

Érase una vez, hace muchos años, me pagaron para recuperar un conjunto de fotos y videos de graduación de una tarjeta SD para una madre bastante angustiada. Tras una inspección minuciosa, la tarjeta se había dañado físicamente de alguna manera con una grieta visible en la carcasa exterior y tenía varios sectores defectuosos, especialmente varios sectores críticos iniciales, que hicieron que incluso los programas de recuperación más confiables en ese momento no leyeran completamente la tarjeta . Además, las herramientas de datos forenses en ese entonces cuestan una fortuna.

Terminé obteniendo una tarjeta SD de marca / tamaño idéntica y escribiendo mi propio volcado de datos sin procesar personalizado y la utilidad de restauración para copiar los datos de la tarjeta defectuosa a la buena. Cada vez que la utilidad golpea un sector defectuoso, vuelve a intentarlo varias veces antes de escribir todos los ceros para ese sector y, en lugar de darse por vencido y detenerse, ignora la falla y pasa al siguiente sector. Los intentos de reintento se realizaron ya que también me di cuenta de que algunos sectores todavía tenían una tasa de éxito de lectura de alrededor del 40%. Una vez que los datos estuvieron en la nueva tarjeta SD, las herramientas de recuperación que habían fallado antes funcionaron perfectamente con una pérdida / corrupción de datos mínima. En general, alrededor del 98% de todos los archivos fueron recuperados. También se recuperó una cantidad de elementos que se habían eliminado anteriormente porque nunca se borró nada, solo se marcó como tal y se sobrescribió lentamente. Lo que comenzó como un ejercicio de recuperación de datos un poco aburrido se convirtió en uno de mis proyectos de desarrollo de software personal más memorables e interesantes. En caso de que te lo estés preguntando, la madre estaba encantada.

En cualquier caso, esta historia demuestra que es posible dañar físicamente una tarjeta SD de modo que los datos aún sean accesibles pero que tengan sectores que apenas funcionan y que cualquier cosa que intente leer tiene dificultades para hacerlo. El plástico de la tarjeta SD tiende a ser bastante frágil, por lo que doblar o cortar algunos baratos podría ser el truco. Su experiencia puede ser diferente.

También puede preguntar en algunos lugares de recuperación de datos en su área. Dado que se especializan en la recuperación de datos de varios dispositivos con fallas o fallidos, deberían tener algunas sugerencias / entradas útiles e incluso podrían tener a mano algunas tarjetas SD pre-reventadas (por ejemplo, con fines de capacitación) que podría obtener de ellas.

Esta respuesta es una expansión del comentario de @Ruslan

1. Llene su tarjeta SD hasta aproximadamente el 99.9%
2. Vuelva a escribir continuamente el contenido del 0.1% restante (Escribir A -eliminar-escribir B-borrar - Escribir A ...)
3. Pruebe (periódicamente) si ya ha roto la tarjeta

Posible alternativa:

No estoy seguro de si esto funciona para sus propósitos, pero tal vez sea suficiente para dañar físicamente su tarjeta, lo que podría ser mucho más rápido.

Podría intentar introducir una fuente de alimentación inestable o una señalización de mayor voltaje.

Una falla común para una familia de dispositivos que conozco tiene una fuerte correlación entre la corrupción de la tarjeta SD y el contacto intermitente de la batería.

Algunas tarjetas SD antiguas de baja capacidad (16 MB-ish) usan chips flash en paquetes de estilo TSOP / TSSOP. Un taller capaz de retrabajar SMT (si está haciendo un trabajo integrado, es posible que tenga esa habilidad internamente; de ​​lo contrario, compruebe que las pequeñas empresas que realizan reparaciones de teléfonos / computadoras portátiles a nivel de placa) posiblemente puedan separar y volver a colocar ese chip, para que pueda leerse y escribirse sin formato (incluidos los códigos ECC) con un programador de dispositivo.

Aún así, tenga en cuenta que probará principalmente:

• Cómo manejará su dispositivo las posibles aberraciones de tiempo / hipo introducidas por la corrección de errores internos

y en el peor de los casos

• cómo su dispositivo maneja una tarjeta SD con falla terminal.

Si solo desea verificar cómo se comporta con un comportamiento errático por cualquier motivo desde una tarjeta SD, probablemente sea mejor introducir ruido eléctrico en las líneas de la interfaz (por ejemplo, colocando un interruptor de bus FET en el medio, y en momentos aleatorios cambiando momentáneamente a una fuente de señales sin sentido (sin embargo, de los niveles eléctricos correctos).

Relacionado con la respuesta de OlafM pero diferente: puede programar un microcontrolador propio para hablar el protocolo de la tarjeta SD y luego emular cualquier comportamiento que desee que tenga.

El área FAT32 Master Boot Record es probablemente la más susceptible al abuso, ya que en un nivel lógico siempre necesita estar en el mismo lugar. (Tal vez esto se maneje mediante la reasignación suave de sectores defectuosos, pero soy un tanto escéptico de que esto se implemente en todo el hardware). Por lo tanto, podría ejecutar sfdisken un bucle y ver si puede destruirlo de esa manera.

Pero voy a rogarle que haga todo lo posible para mejorar la confiabilidad del hardware, en lugar de tratar de manejar el hardware defectuoso en el software. El problema es que las tarjetas SD fallan de muchas formas extrañas. Se vuelven ilegibles, no se pueden escribir, le dan datos erróneos, caducan durante las operaciones, etc. Tratar de predecir todas las formas en que una tarjeta puede fallar es muy difícil.

Este es uno de mis fallos favoritos, el "modo de big data":

Las tarjetas SD son productos de consumo que están bajo una tremenda presión de costos. Las piezas cambian rápidamente y las hojas de datos son difíciles de conseguir. El producto falsificado no es desconocido. Para un almacenamiento económico, son difíciles de superar, pero si bien los SSD hacen que la confiabilidad sea una prioridad, la prioridad para las tarjetas SD es la velocidad, la capacidad y el costo (probablemente no en ese orden).

Su primera línea de defensa es utilizar una pieza eMMC soldable con una hoja de datos real de un fabricante reconocido en lugar de una tarjeta SD extraíble. Sí, cuestan más por GB, pero la parte estará en producción durante un período de tiempo más largo, y al menos sabes lo que estás obteniendo. Soldar la parte hacia abajo también evita una gran cantidad de problemas potenciales (tarjetas extraídas durante las escrituras, mal contacto eléctrico, etc.) con una tarjeta extraíble.

Si su producto necesita almacenamiento extraíble, o es demasiado tarde para cambiar algo, considere gastar el dinero extra para tarjetas de grado "industrial", o trátelas como objetos desechables. Lo que hacemos (en Linux) es fsckla tarjeta en el arranque y formatearla si se informa algún error, ya que el formateo es aceptable en este caso de uso. Luego lo hacemos de fscknuevo. Si aún informa errores después del reformateo, lo realizamos con RMA y reemplazamos el hardware con una variante más nueva que usa eMMC.

¡Buena suerte!

Quizás esta no sea la dirección que deseaba, pero encontré que quitar mi tarjeta SD mientras mi radio o computadora portátil leía garantiza que una tarjeta SD se bloqueó aproximadamente 1/5 o 1/10 veces. Parece que a las tarjetas no les va bien si se quita el poder durante una lectura y presumiblemente escribe. Después de leer los comentarios de Robert Calhoun a continuación, me lleva a creer que puede estar dañando el FAT. Aunque no sé por qué solo leer causa un colapso, ¿no debería haber ninguna escritura?

Si su tarjeta SD tiene el formato FAT32, puede editar en hexadecimal las 2 grasas y marcar un sector como malo con el código hexadecimal correcto. Esto es solo un truco si desea probar lógicamente un software que se supone que encuentra un sector defectuoso en este lugar en particular; tampoco dañará su tarjeta sd, un reformateo lo devolverá a su estado normal.

Me pregunto si se puede crear un script de bloques defectuosos de Linux para ejecutar su prueba destructiva en un solo sector repetidamente durante varias horas.

En un solo sector, no, porque el código de nivelación de desgaste dentro de la tarjeta SD reasignará los bloques lógicos por todas partes.

Pero puede ejecutar fácilmente badblocks -wen un bucle hasta que aparezca algunos bloques defectuosos. Algo como esto debería funcionar:

while badblocks -w /dev/xx; do :; done

suponiendo que badblocks devuelve 0 si no se detectaron bloques defectuosos y ≠ 0 de lo contrario (la página del manual no dice y no he verificado el código fuente).

Normalmente con las tarjetas SD / uSD implementan nivelación de desgaste, por lo que esto podría ser bastante difícil. Dependiendo del tipo (celda de capa única, multicapa, TLC, 3D-NAND, etc.), el ciclo de escritura requerido para romperlo lo suficiente como para agotar el grupo de sectores puede estar en la TB múltiple.

Realmente probé esto con un Pro Duo de 4GB, 64GB y 256GB, SSD y memoria USB, el K --- s de 64GB con chips de 4 Micron y 16GB duró aproximadamente 3.84TB antes de que fallara con un solo error suave en el área FAT . El uso de 256 GB duró un poco menos, pero se estimaría sin acceso directo al chip, probablemente escribió tal vez 5 TB antes de que finalmente cediera con la corrupción MBR, pero no estaba claro si el controlador lo hizo funcionar de manera sólida en modo USB3 pero USB2 tuvo más fallas durante la lectura y también hacía mucho calor. 4GB Duo falló en el lector al copiar datos, de nuevo no puedo estar seguro, pero equivale a unos 6 años de uso y la cámara también mostraba mensajes de "Recuperación". Incidentalmente, la variación del voltaje de la fuente de alimentación durante la escritura hará que falle MUCHO más rápido. Mi microSD de 128 GB falló después de aproximadamente 2 años de uso con síntomas similares,

Se eliminaron notas irrelevantes sobre los experimentos de rayos X.