Come posso rompere / corrompere intenzionalmente un settore su una scheda SD?

Devo testare la resilienza di alcuni codici di lettura / scrittura per alcuni componenti hardware incorporati. Come potrei sacrificare alcune schede SD e rompere diversi settori noti per uno studio controllato?

L'unica cosa che mi viene in mente è di sovrascrivere un singolo settore qualche milione di volte. Mi chiedo se è possibile creare uno script di Linux Badblock per eseguire ripetutamente il test distruttivo su un singolo settore per diverse ore.

Un approccio alternativo che può essere utile.

Se il tuo codice viene eseguito su Linux, forse puoi provarlo con un dispositivo logico "difettoso". dmsetuppuò creare dispositivi che restituiscono errori I / O. Crea il tuo dispositivo usando errore / o flakeytarget. Da man 8 dmsetup:

error
Errori di qualsiasi I / O che va in quest'area. Utile per i test o per la creazione di dispositivi con buchi.

flakey
Crea una mappatura simile alla lineardestinazione ma presenta periodicamente comportamenti inaffidabili. Utile per simulare i dispositivi guasti durante il test.

Nota: flakeyl'utilizzo target è documentato qui . Esempio di base qui .

Per quanto ne so, verrà immediatamente segnalato un errore I / O, quindi questo è diverso dal comportamento reale della scheda SD in cui ci si può aspettare ritardo, stallo, ecc. Tuttavia, penso che questo approccio possa essere utile in alcuni casi, almeno per eseguire velocemente test preliminare o giù di lì.

Questo ragazzo ha violato il microcontrollore all'interno delle schede SD utilizzate per contrassegnare i blocchi danneggiati: https://www.bunniestudios.com/blog/?p=3554

Potresti essere in grado di fare lo stesso e contrassegnare arbitrariamente i blocchi come difettosi.

Oggi al Chaos Computer Congress (30C3), xobs e io abbiamo rivelato che alcune schede SD contengono vulnerabilità che consentono l'esecuzione di codice arbitrario - sulla scheda di memoria stessa. Sul lato oscuro, l'esecuzione del codice sulla scheda di memoria abilita una classe di attacchi MITM (man-in-the-middle), in cui la scheda sembra comportarsi in un modo, ma in realtà fa qualcos'altro. Il lato positivo, inoltre, consente agli appassionati di hardware di accedere a una fonte di microcontrollori molto economica e onnipresente.

.

Questi algoritmi sono troppo complicati e troppo specifici per il dispositivo per essere eseguiti a livello di applicazione o di sistema operativo, quindi risulta che ogni disco di memoria flash viene fornito con un microcontrollore ragionevolmente potente per eseguire un set personalizzato di algoritmi di astrazione del disco. Anche la scheda microSD ridotta non contiene uno, ma almeno due chip: un controller e almeno un chip flash (le schede ad alta densità impilano più flash).

.

Il microcontrollore incorporato è in genere una CPU 8051 o ARM fortemente modificata. Nelle implementazioni moderne, il microcontrollore si avvicina ai livelli di prestazione a 100 MHz e ha anche diversi acceleratori hardware on-die. Sorprendentemente, il costo dell'aggiunta di questi controller al dispositivo è probabilmente dell'ordine di $ 0,15- $ 0,30, in particolare per le aziende che possono sfruttare sia la memoria flash sia i controller all'interno della stessa business unit. Probabilmente è più economico aggiungere questi microcontrollori piuttosto che testare e caratterizzare accuratamente ogni chip di memoria flash, il che spiega perché i dispositivi flash gestiti possono essere più economici per bit rispetto ai chip flash grezzi, nonostante l'inclusione di un microcontrollore.

.

Il punto cruciale è che un meccanismo di caricamento e aggiornamento del firmware è praticamente obbligatorio, soprattutto per i controller di terze parti. Gli utenti finali sono raramente esposti a questo processo, poiché tutto accade in fabbrica, ma ciò non rende il meccanismo meno reale. Nelle mie esplorazioni dei mercati dell'elettronica in Cina, ho visto i negozianti che bruciano il firmware su schede che "espandono" la capacità della scheda - in altre parole, caricano un firmware che segnala che la capacità di una scheda è molto più grande del spazio disponibile effettivo. Il fatto che ciò sia possibile presso il punto vendita significa che molto probabilmente il meccanismo di aggiornamento non è garantito.

Nel nostro discorso a 30C3, riportiamo le nostre scoperte esplorando un particolare marchio di microcontrollori, vale a dire Appotech e le sue offerte AX211 e AX215. Scopriamo una semplice sequenza "knock" trasmessa su comandi riservati dal produttore (vale a dire, CMD63 seguito da 'A', 'P', 'P', 'O') che rilascia il controller in una modalità di caricamento del firmware. A questo punto, la scheda accetterà i successivi 512 byte e la eseguirà come codice.

Questo in genere non funziona perché le schede SD (o eMMC) più recenti utilizzano il livellamento dell'usura statico e dinamico, il che significa che un controller intelligente interpreta le tue istruzioni di scrittura e le mappa su uno dei settori flash meno utilizzati.

L'unica cosa che potresti fare è provare a contattare i tuoi fornitori e chiedere il loro foglio dati; potrebbero esserci alcuni modi (specifici del fornitore) per recuperare lo stato del loro algoritmo di livellamento dell'usura. Ciò consentirebbe potenzialmente di interrogare lo stato / l'utilizzo del flash sottostante. Oppure potresti essere sfortunato e questo potrebbe non esistere.

Se il tuo obiettivo è davvero quello di distruggere Flash, tutto ciò che potresti fare è eseguire enormi cicli di lettura e scrittura e verificare continuamente che i dati che stai leggendo siano ancora coerenti. Ad esempio, creare due file di grandi dimensioni, archiviare i loro checksum e leggerli / scriverli per verificarne il checksum. Più grande è il flash, più tempo richiederà questo processo.

È possibile aumentare l'usura del transistor aumentando la temperatura di funzionamento. Utilizzare cicli di cancellazione / scrittura su un chip riscaldato (70-120 ° C); indosserà più velocemente.

Prefazione: questa opzione richiede ulteriori modifiche alla programmazione e all'hardware, ma consentirebbe letture controllate molto probabilmente trasparenti per l'host.

Una scheda SD ha più opzioni di I / O, ma può essere controllata tramite SPI. Se dovessi prendere una scheda SD e modificarla in modo da poter collegare i pin a un microcontrollore (come un Arduino), potresti fare in modo che Arduino imiti la scheda SD e sia trasparente al dispositivo che legge la scheda SD. Il codice sul microcontrollore potrebbe restituire intenzionalmente dati errati quando necessario. Inoltre, è possibile inserire una scheda SD sul microcontrollore in modo che le letture siano in grado di passare attraverso il microcontrollore alla scheda SD per consentire gigabyte di test.

Vorrei andare su ebay / aliexpress e comprare la scheda SD più economica che posso trovare dalla Cina, quella che è "troppo bella per essere vera". Spesso vengono con settori difettosi o sono in software impostati per essere molto più grandi di quanto non siano in realtà. Ad ogni modo, dovresti finire con una scheda SD difettosa da utilizzare per il test.

Una volta, molti anni fa, sono stato pagato per recuperare una serie di foto e video di diplomi da una scheda SD per una madre piuttosto sconvolta. Dopo un'attenta ispezione, la scheda era stata in qualche modo danneggiata fisicamente con una crepa visibile nel case esterno e aveva diversi settori danneggiati, in particolare diversi settori critici precoci, che hanno reso i programmi di recupero più affidabili al momento completamente in grado di leggere la scheda . Inoltre, gli strumenti di dati forensi allora costano una fortuna.

Ho finito per ottenere una identica scheda SD di marca / dimensione e scrivere il mio dump di dati grezzi personalizzato e ripristinare l'utilità per copiare i dati dalla scheda difettosa a quella buona. Ogni volta che l'utilità ha colpito un settore danneggiato, dovrebbe riprovare più volte prima di scrivere tutti gli zero per quel settore e, invece di arrendersi e fermarsi, ignorare il fallimento e passare al settore successivo. I tentativi di tentativi sono stati fatti poiché avevo anche notato che alcuni settori avevano ancora un tasso di successo in lettura di circa il 40%. Una volta che i dati erano sulla nuova scheda SD, gli strumenti di recupero che avevano fallito prima funzionavano perfettamente con una perdita / corruzione minima dei dati. Complessivamente, sono stati recuperati circa il 98% di tutti i file. Un certo numero di elementi che erano stati precedentemente eliminati sono stati recuperati perché nulla è mai stato effettivamente cancellato, semplicemente contrassegnato come tale e sovrascritto lentamente. Quello che è iniziato come un esercizio di recupero dei dati leggermente noioso è diventato uno dei miei progetti di sviluppo di software personali più memorabili e interessanti. Nel caso te lo stessi chiedendo, la madre era elettrizzata.

In ogni caso, questa storia dimostra che è possibile danneggiare fisicamente una scheda SD in modo tale che i dati siano ancora accessibili ma che contengano settori che funzionano a malapena e che qualsiasi cosa tenti di leggerlo abbia difficoltà a farlo. La plastica della scheda SD tende ad essere piuttosto fragile, quindi piegare o tagliare alcuni economici potrebbe fare il trucco. Il tuo chilometraggio può variare.

Potresti anche chiedere in giro in alcuni luoghi di recupero dei dati nella tua zona. Poiché sono specializzati nel recupero dei dati da vari dispositivi guasti o guasti, dovrebbero avere alcuni suggerimenti / suggerimenti utili e potrebbero anche avere a portata di mano alcune schede SD pre-bustate (ad es. Per scopi di formazione) che potresti ottenere da loro.

Questa risposta è un'espansione sul commento di @Ruslan

1. Riempi la tua scheda SD fino a circa il 99,9%
2. Riscrivere continuamente il contenuto del restante 0,1% (Scrivi A-cancella-scrivi B-cancella - Scrivi A ...)
3. Verifica (periodicamente) se hai già rotto la carta

Alternativa possibile:

Non sono sicuro che funzioni per i tuoi scopi, ma forse sarà sufficiente danneggiare fisicamente la tua carta, il che potrebbe essere molto più veloce.

Potresti provare a introdurre un alimentatore instabile o una segnalazione di tensione più alta.

Un errore comune per una famiglia di dispositivi che conosco ha una forte correlazione tra corruzione della scheda SD e contatto intermittente della batteria.

Alcune vecchie schede SD a bassa capacità (16 MB-ish) usano chip flash in pacchetti in stile TSOP / TSSOP. Un'officina in grado di rilavorare SMT (se stai eseguendo un lavoro integrato, potresti avere quell'abilità interna, altrimenti controlla le piccole aziende che effettuano la riparazione a livello di telefono / laptop a livello di scheda) potrebbe concepibilmente separare e ricollegare quel chip, in modo che possa essere letto e scritto raw (compresi i codici ECC) con un programmatore di dispositivi.

Tuttavia, tieni presente che testerai principalmente:

• Come il dispositivo gestirà possibili aberrazioni / singhiozzi di temporizzazione introdotti dalla correzione degli errori interna

e nel peggiore dei casi

• come il dispositivo gestisce una scheda SD che non funziona correttamente.

Se vuoi semplicemente controllare come si comporta con un comportamento irregolare per qualsiasi motivo da una scheda SD, è probabilmente meglio introdurre solo disturbi elettrici nelle linee dell'interfaccia (ad esempio inserendo uno switch bus FET tra, e in momenti casuali alternando momentaneamente ad una fonte di segnali senza senso (dei giusti livelli elettrici).

Relativo alla risposta di OlafM ma diverso: puoi programmare un tuo microcontrollore per pronunciare il protocollo della scheda SD e quindi emulare qualsiasi comportamento tu voglia che abbia.

L'area Master Boot Record FAT32 è probabilmente la più suscettibile agli abusi, dal momento che a livello logico deve sempre trovarsi nello stesso posto. (Forse questo è gestito dal soft-remapping di settori danneggiati, ma sono un po 'scettico sul fatto che questo sia implementato su tutto l'hardware.) Quindi potresti correre sfdiskin un ciclo e vedere se riesci a rovinarlo in quel modo.

Ma ti supplico di fare tutto il possibile per migliorare l'affidabilità dell'hardware, invece di provare a gestire hardware difettoso nel software. Il problema è che le schede SD falliscono in tutti i modi strani. Diventano illeggibili, diventano non scrivibili, ti danno dati errati, scadono durante le operazioni, ecc. Cercare di prevedere tutti i modi in cui una carta può fallire è molto difficile.

Ecco uno dei miei errori preferiti, la "modalità big data":

Le schede SD sono prodotti di consumo che subiscono un'enorme pressione sui costi. Le parti cambiano rapidamente e le schede tecniche sono difficili da trovare. Il prodotto contraffatto non è inaudito. Per l'archiviazione economica sono difficili da battere, ma mentre gli SSD fanno dell'affidabilità una priorità, la priorità per le schede SD è la velocità, la capacità e il costo (probabilmente non in quell'ordine).

La tua prima linea di difesa consiste nell'utilizzare una parte eMMC saldabile con un foglio dati reale di un produttore affidabile anziché una scheda SD rimovibile. Sì, costano di più per GB, ma la parte sarà in produzione per un periodo di tempo più lungo e almeno sai cosa stai ottenendo. La saldatura della parte in basso evita anche tutta una serie di potenziali problemi (carte strappate durante le scritture, scarso contatto elettrico, ecc.) Con una carta rimovibile.

Se il tuo prodotto necessita di spazio di archiviazione rimovibile o è troppo tardi per cambiare qualcosa, prendi in considerazione la possibilità di spendere i soldi extra per le carte di livello "industriale" o di trattarli come oggetti usa e getta. Quello che facciamo (sotto Linux) è fsckla scheda all'avvio e la riformattiamo se vengono segnalati errori, dato che la riformattazione è accettabile in questo caso d'uso. Quindi di fscknuovo. Se dopo la riformattazione riporta ancora errori, lo RMA lo sostituiamo e sostituiamo l'hardware con una variante più recente che utilizza eMMC.

In bocca al lupo!

Forse questa non è la direzione che volevi, ma ho scoperto che rimuovere la mia scheda SD mentre la mia radio o il mio laptop stava leggendo da essa garantisce una scheda SD bloccata circa 1/5 o 1/10 volte. Sembra che le carte non vadano bene dopo aver rimosso il potere durante una lettura e presumibilmente le scritture. Dopo aver letto i commenti di Robert Calhoun qui sotto, mi porta a credere che potrebbe danneggiare il FAT. Anche se non so perché la sola lettura provoca un arresto anomalo, non dovrebbero esserci scritte in corso?

Se la tua scheda SD è formattata FAT32, puoi modificare i 2 grassi in modo esadecimale e contrassegnare un settore come difettoso con il codice esadecimale corretto. Questo è solo un trucco se vuoi testare logicamente un software che dovrebbe trovare un settore danneggiato in questo particolare posto; non danneggerà neanche la tua scheda SD, un riformattazione la riporterà alle condizioni normali.

Mi chiedo se è possibile creare uno script di Linux Badblock per eseguire ripetutamente il test distruttivo su un singolo settore per diverse ore.

Su un singolo settore: no, perché il codice di livellamento dell'usura all'interno della scheda SD rimappa i blocchi logici ovunque.

Ma puoi facilmente eseguirlo badblocks -win un ciclo fino a quando non vengono visualizzati alcuni blocchi danneggiati. Qualcosa del genere dovrebbe funzionare:

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

supponendo che badblocks restituisca 0 se non sono stati rilevati blocchi danneggiati e ≠ 0 altrimenti (la pagina man non dice e non ho controllato il codice sorgente.)

Normalmente con le schede SD / uSD implementano il livellamento dell'usura, quindi questo potrebbe essere piuttosto difficile. A seconda del tipo (cella a strato singolo, multistrato, TLC, 3D-NAND ecc.), Il ciclo di scrittura necessario per interromperlo abbastanza da esaurire il pool di settori può trovarsi nella TB multipla.

In realtà l'ho provato con un Pro Duo da 4 GB, 64 GB e 256 GB, SSD e thumbdrive, i 64 GB di K --- s --- usando 4 micron da 16 GB sono durati circa 3,84 TB prima di fallire con un singolo errore soft nell'area FAT . I 256 GB usati sono durati un po 'meno ma stimerebbero senza un accesso diretto ai chip che probabilmente ha scritto forse 5 TB prima che alla fine cedesse con corruzione MBR ma non era chiaro se il controller lo facesse funzionare in modo solido in modalità USB3 ma USB2 aveva più problemi durante la lettura e ha anche funzionato molto caldo. Duo da 4 GB non è riuscito nel lettore durante la copia dei dati, di nuovo non si può essere sicuri, ma equivale forse a 6 anni di utilizzo e la fotocamera mostrava anche i messaggi "Ripristino". La variazione accidentale della tensione di alimentazione durante la scrittura renderà molto più veloce il guasto. La mia microSD da 128 GB non è riuscita dopo circa 2 anni di utilizzo con sintomi simili,

Rimosse le note irrilevanti sugli esperimenti con i raggi X.