Como posso intencionalmente quebrar / corromper um setor em um cartão SD?

138

Eu preciso testar a resiliência de alguns códigos de leitura / gravação para alguns hardwares incorporados. Como posso sacrificar alguns cartões SD e quebrar vários setores conhecidos para um estudo controlado?

A única coisa em que consigo pensar é sobrescrever um único setor alguns milhões de vezes. Gostaria de saber se um script de badblocks do Linux pode ser criado para executar seu teste destrutivo em um único setor repetidamente por várias horas.

    
por Gabe Krause 11.09.2017 / 09:28

15 respostas

166

Uma abordagem alternativa que pode ser útil.

Se o seu código for executado no Linux, talvez você possa testá-lo com um dispositivo lógico "defeituoso". dmsetup pode criar dispositivos que retornam erros de E / S. Basta criar seu dispositivo usando error e / ou flakey target. De man 8 dmsetup :

error
Errors any I/O that goes to this area. Useful for testing or for creating devices with holes in them.

flakey
Creates a similar mapping to the linear target but exhibits unreliable behaviour periodically. Useful for simulating failing devices when testing.

Observação: o uso de meta flakey está documentado aqui . Exemplo básico aqui .

Até onde eu sei, um erro de I / O será reportado imediatamente, então isso é diferente do comportamento real do cartão SD onde você pode esperar atrasos, atrasos, etc. No entanto, eu acho que essa abordagem pode ser útil em alguns casos, pelo menos para realizar um teste preliminar rápido ou assim.

    
por 11.09.2017 / 10:33
75

Esse cara hackeou o microcontrolador dentro dos cartões SD usados para marcar bloqueios ruins: link

Você pode fazer o mesmo e arbitrariamente marcar blocos como defeituosos.

Today at the Chaos Computer Congress (30C3), xobs and I disclosed a finding that some SD cards contain vulnerabilities that allow arbitrary code execution — on the memory card itself. On the dark side, code execution on the memory card enables a class of MITM (man-in-the-middle) attacks, where the card seems to be behaving one way, but in fact it does something else. On the light side, it also enables the possibility for hardware enthusiasts to gain access to a very cheap and ubiquitous source of microcontrollers.

.

These algorithms are too complicated and too device-specific to be run at the application or OS level, and so it turns out that every flash memory disk ships with a reasonably powerful microcontroller to run a custom set of disk abstraction algorithms. Even the diminutive microSD card contains not one, but at least two chips — a controller, and at least one flash chip (high density cards will stack multiple flash die).

.

The embedded microcontroller is typically a heavily modified 8051 or ARM CPU. In modern implementations, the microcontroller will approach 100 MHz performance levels, and also have several hardware accelerators on-die. Amazingly, the cost of adding these controllers to the device is probably on the order of $0.15-$0.30, particularly for companies that can fab both the flash memory and the controllers within the same business unit. It’s probably cheaper to add these microcontrollers than to thoroughly test and characterize each flash memory chip, which explains why managed flash devices can be cheaper per bit than raw flash chips, despite the inclusion of a microcontroller.

.

The crux is that a firmware loading and update mechanism is virtually mandatory, especially for third-party controllers. End users are rarely exposed to this process, since it all happens in the factory, but this doesn’t make the mechanism any less real. In my explorations of the electronics markets in China, I’ve seen shop keepers burning firmware on cards that “expand” the capacity of the card — in other words, they load a firmware that reports the capacity of a card is much larger than the actual available storage. The fact that this is possible at the point of sale means that most likely, the update mechanism is not secured.

In our talk at 30C3, we report our findings exploring a particular microcontroller brand, namely, Appotech and its AX211 and AX215 offerings. We discover a simple “knock” sequence transmitted over manufacturer-reserved commands (namely, CMD63 followed by ‘A’,’P’,’P’,’O’) that drop the controller into a firmware loading mode. At this point, the card will accept the next 512 bytes and run it as code.

    
por 12.09.2017 / 11:21
38

Isso normalmente não funciona porque os cartões SD mais recentes (ou eMMC) usam nivelamento de desgaste estático e dinâmico, o que significa que um controlador inteligente interpreta suas instruções de gravação e as mapeia para um dos setores menos utilizados.

A única coisa que você pode fazer é tentar entrar em contato com seus fornecedores e pedir a folha de dados deles; pode haver algumas maneiras (específicas do fornecedor) de recuperar o estado de seu algoritmo de nivelamento de desgaste. Isso potencialmente permitiria consultar o estado / uso do flash subjacente. Ou você pode ser azarado e isso pode não existir.

Se o seu objetivo é realmente destruir o flash, tudo o que você pode fazer é executar ciclos maciços de leitura e gravação e verificar continuamente se os dados que você está lendo ainda são consistentes. Por exemplo. crie dois arquivos grandes, armazene seus checksums e os leia / escreva para verificar sua soma de verificação. Quanto maior o flash, mais tempo esse processo levará.

    
por 11.09.2017 / 09:37
32

Você pode aumentar o desgaste do transistor aumentando a temperatura de operação. Use ciclos de escrita em um chip aquecido (70-120 ° C); vai usar mais rápido.

    
por 11.09.2017 / 10:59
18

Prefácio: Esta opção requer programação adicional e modificações de hardware, mas permitiria leituras controladas, provavelmente mais transparentes para o host.

Um cartão SD tem várias opções de E / S, mas pode ser controlado pela SPI. Se você pegasse um cartão SD e o modificasse para que pudesse conectar os pinos a um microcontrolador (como um Arduino), você poderia fazer com que o Arduino imitasse o cartão SD e fosse transparente para o dispositivo que estivesse lendo o cartão SD. Seu código no microcontrolador pode propositadamente retornar dados ruins quando necessário. Além disso, você pode colocar um cartão SD no microcontrolador para que as leituras possam passar pelo microcontrolador para o cartão SD para permitir gigabytes de testes.

    
por 11.09.2017 / 14:55
15

Eu iria ao ebay / aliexpress e compraria o cartão SD mais barato que eu pudesse encontrar na China, o que é "bom demais para ser verdade". Eles geralmente vêm com setores defeituosos ou estão em um conjunto de software muito maior do que realmente são. De qualquer forma, você deve acabar com o cartão SD com defeito para usar no teste.

    
por 12.09.2017 / 10:05
11

Era uma vez, muitos anos atrás, eu era pago para recuperar um conjunto de fotos de formatura e vídeos de um cartão SD para uma mãe um pouco perturbada. Após uma inspeção cuidadosa, o cartão tinha sido fisicamente danificado com uma rachadura visível no gabinete externo e tinha vários setores defeituosos, principalmente vários setores iniciais e críticos, o que fez com que até mesmo os programas de recuperação mais confiáveis no momento não conseguissem ler o cartão. . Além disso, ferramentas de dados forenses custavam uma fortuna.

Acabei obtendo um cartão SD de marca / tamanho idêntico e escrevendo meu próprio utilitário de despejo e restauração de dados brutos personalizado para copiar os dados da placa ruim para a boa. Toda vez que o utilitário atinge um setor defeituoso, ele tenta novamente várias vezes antes de escrever todos os zeros para esse setor e, em vez de desistir e parar, ignora a falha e passa para o próximo setor. As tentativas de repetição foram feitas, pois também notei que alguns setores ainda tinham uma taxa de sucesso de leitura de 40%. Uma vez que os dados estavam no novo cartão SD, as ferramentas de recuperação que falharam antes funcionaram perfeitamente com o mínimo de perda / corrupção de dados. No geral, cerca de 98% de todos os arquivos foram recuperados. Vários itens que haviam sido excluídos anteriormente também foram recuperados porque nada é realmente excluído - apenas marcado como tal e substituído de forma lenta. O que começou como um exercício de recuperação de dados ligeiramente entediante tornou-se um dos meus projetos de desenvolvimento de software pessoal mais memoráveis e interessantes. Caso você esteja se perguntando, a mãe ficou emocionada.

De qualquer forma, esta história mostra que é possível danificar fisicamente um cartão SD, de modo que os dados ainda estejam acessíveis, mas os setores que mal funcionam e que qualquer tentativa de leitura tenha dificuldades em fazê-lo. Plástico de cartão SD tende a ser bastante frágil, então dobrar ou cortar alguns mais baratos pode fazer o truque. Sua milhagem pode variar.

Você também pode perguntar em alguns locais de recuperação de dados em sua área. Como eles são especializados em recuperação de dados de vários dispositivos com falha ou falha, eles devem ter algumas entradas / dicas úteis e podem até ter alguns cartões SD pré-eliminados disponíveis (por exemplo, para fins de treinamento) que você poderia obter deles.

    
por 13.09.2017 / 07:43
5

Esta resposta é uma expansão no comentário do @Ruslan

  1. Preencha o seu cartão SD até cerca de 99,9%
  2. Continuamente reescreva o conteúdo dos 0,1% restantes (Escreva A -Excluir-escrever B-apagar - Escrever A ...)
  3. Teste (periodicamente) se você já quebrou o cartão

Alternativa possível:

Não tenho certeza se isso funciona para seus objetivos, mas talvez seja suficiente danificar fisicamente o seu cartão, o que pode ser muito mais rápido.

    
por 11.09.2017 / 14:27
3

Você pode tentar introduzir uma fonte de alimentação instável ou uma sinalização de voltagem mais alta.

Uma falha comum em uma família de dispositivos que eu conheço tem uma strong correlação entre a corrupção do cartão SD e o contato intermitente da bateria.

    
por 11.09.2017 / 21:14
3

Alguns cartões SD mais antigos e de baixa capacidade (16MB-ish) usam chips flash em pacotes estilo TSOP / TSSOP. Um workshop capaz de retrabalho SMT (se você estiver fazendo trabalho incorporado, você pode ter essa habilidade em casa, caso contrário, verifique se as pequenas empresas que fazem reparo de telefone / laptop no nível da placa) poderiam separar e recolocar esse chip, para que ele possa ser lido e escrito em bruto (incluindo os códigos ECC) com um programador de dispositivos.

Ainda assim, esteja ciente de que você estará testando principalmente:

  • Como seu dispositivo lidará com possíveis aberrações / interrupções de tempo introduzidas pela correção interna de erros

e no pior dos casos

  • como o seu dispositivo manipula um cartão SD com falha terminal.

Se você quiser apenas verificar como ele se comporta com comportamento errático por qualquer motivo de um cartão SD, provavelmente é melhor apenas introduzir ruído elétrico nas linhas da interface (por exemplo, colocando um comutador FET entre eles e aleatoriamente). vezes mudando momentaneamente para uma fonte de sinais sem sentido (dos níveis elétricos certos).

    
por 12.09.2017 / 07:48
2

Relacionado à resposta do OlafM, mas diferente: você pode programar um microcontrolador para falar o protocolo do cartão SD e emular o comportamento que quiser.

    
por 13.09.2017 / 04:51
1

A área FAT32 Master Boot Record é provavelmente a mais suscetível a abusos, já que em um nível lógico ela sempre precisa estar no mesmo lugar. (Talvez isso seja tratado pelo soft remapeamento de setores defeituosos, mas eu sou um pouco cético que isso é implementado em todo o hardware.) Então você pode executar sfdisk em um loop e ver se você pode destruí-lo dessa maneira. p>

Mas vou pedir-lhe para fazer o que for possível para melhorar a fiabilidade do hardware, em vez de tentar lidar com hardware defeituoso no software. O problema é que os cartões SD falham em todos os tipos de formas estranhas. Eles se tornam ilegíveis, tornam-se irreconhecíveis, fornecem dados incorretos, eles param durante as operações, etc. Tentar prever todas as maneiras pelas quais um cartão pode falhar é muito difícil.

Aqui está uma das minhas falhas favoritas, "modo big data":

OscartõesSDsãoprodutosdeconsumoqueestãosobenormepressãodecusto.Aspeçasmudamrapidamenteeasfolhasdedadossãodifíceisdeencontrar.Oprodutofalsificadonãoéinédito.Paraarmazenamentobarato,elessãodifíceisdesuperar,masenquantoosSSDspriorizamaconfiabilidade,aprioridadedoscartõesSDéavelocidade,acapacidadeeocusto(provavelmentenãonessaordem).

SuaprimeiralinhadedefesaéusarumaparteeMMCsolderablecomumafolhadedadosrealdeumfabricanterespeitávelemvezdeumcartãoSDremovível.Sim,elescustammaisporGB,masapeçaestaráemproduçãoporumlongoperíodoe,pelomenos,vocêsabeoqueestárecebendo.Soldarapeçatambémevitatodaumasériedepossíveisproblemas(cartõesarrancadosdurantegravações,contatoelétricoinadequado,etc.)comumcartãoremovível.

Seoseuprodutoprecisardearmazenamentoremovível,ousefortardedemaisparaalterarqualquercoisa,consideregastarodinheiroextraemcartõesdegrau"industrial" ou tratá-los como objetos descartáveis. O que fazemos (no linux) é fsck do cartão na inicialização e reformatamos se algum erro for relatado, pois a reformatação é aceitável neste caso de uso. Então nós fsck novamente. Se ainda relatar erros após a reformatação, nós o RMA e substituiremos o hardware por uma variante mais nova que use o eMMC.

Boa sorte!

    
por 13.09.2017 / 23:55
1
Talvez essa não seja a direção que você queria, mas descobri que remover meu cartão SD enquanto meu rádio ou laptop estava lendo garante um cartão SD com falha de 1/5 ou 1/10 vezes. Parece que as cartas não se saem bem com o poder removido durante uma leitura e presumivelmente escreve. Depois de ler os comentários de Robert Calhoun abaixo, isso me leva a acreditar que pode estar prejudicando o FAT. Embora eu não saiba por que a leitura causa uma falha - não deveria haver nenhuma escrita acontecendo?

    
por 13.09.2017 / 01:38
1

Se o seu cartão SD estiver formatado em FAT32, você poderá editar hexadecimais as duas gorduras e marcar um setor como ruim com o código hexadecimal correto. Este é apenas um truque se você quiser testar um software supostamente para encontrar um setor ruim neste lugar específico; Não irá prejudicar o seu cartão SD, uma reformat irá trazê-lo de volta à condição normal.

    
por 18.09.2017 / 15:19
0

I wonder if a Linux badblocks script can be created to run its destructive test on a single sector repeatedly for several hours.

Em um único setor - não, porque o código de nivelamento de desgaste dentro do cartão SD irá remapear os blocos lógicos em todo o lugar.

Mas você pode facilmente executar badblocks -w em um loop até causar alguns blocos ruins para aparecer. Algo como isso deve funcionar:

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

assumindo que badblocks retornam 0 se nenhum bloco ruim foi detectado e ≠ 0 caso contrário (a página man não diz e eu não verifiquei o código fonte.)

    
por 18.09.2017 / 16:09