Recentemente, li muito sobre cartões microSD e pen drives USB falsos que afirmam ter muito espaço (mesmo que você pergunte ao seu computador), enquanto oferece fisicamente muito menos. Recentemente, comprei uma unidade USB SanDisk (128 GB reivindicada) e quero testar seu tamanho. Não é comprado via ebay ou algo assim, mas eu realmente quero testar o tamanho real antes de usá-lo produtivamente.

Eu poderia simplesmente copiar coisas nele, copiar novamente e verificar se os arquivos estão bem. Eu também poderia automatizá-lo com Hashes e outras coisas. Mas eu esperava que houvesse uma solução mais precisa. Eu li que, para Windows, o H2testw faz o truque. Existe uma maneira fácil de testar isso no Ubuntu / Linux? Uma ferramenta especializada e bem funcional, talvez?

Atualização: Apenas para esclarecer, a idéia é verificar se o tamanho que o sistema linux recebe pelo controlador está correto ( para que nenhum dado seja perdido ). Não é como se eu quisesse ver se recebo 128 GB em vez de 127,3 GB. Quero testar se todos os dados que escrevo serão legíveis novamente. Infelizmente, só consigo encontrar algumas informações sobre isso nos sites de tecnologia em inglês. Existem boas fontes alemãs, no entanto. Na verdade, estou procurando por um aplicativo como esses, mas para o Ubuntu / Linux: https://www.raymond.cc/blog/test-and-detect-fake-or-counterfeit-usb-flash-drives-bought-from -ebay-with-h2testw /

Update2: tentei reunir algumas fontes em inglês. Não li todos em detalhes, devido à falta de tempo.

• https://www.ebay.com/gds/All-About-Fake-Flash-Drives-2013-/10000000177553258/g.html
• https://en.wikipedia.org/wiki/USB_flash_drive#Counterfeit_products
• https://www.heise.de/newsticker/meldung/Verdaechtige-USB-Sticks-mit-2-Terabyte-bei-Amazon-Faelschungen-entlarven-Datenverluste-vermeiden-3915202.html
• http://www.pcgameshardware.de/USB-Stick-Hardware-255579/News/falsche-Speicherkapazitaet-bei-Amazon-1245682/

Update3: Explicações

Devido às críticas estranhas abaixo, algumas explicações.

Qual é o problema e por que o dd sozinho não o resolve?

Esta é uma reação a

"Descubra claramente qual é o problema que você está tentando resolver e qual é a definição de" unidade falsa "."

Parece que algumas pessoas não entendem o problema. Por isso, tento explicar o mínimo possível em detalhes, embora eu ache que isso seja muito para a extensão da minha pergunta.

A capacidade dos dispositivos USB fornecidos pelo sistema operacional ou pelas ferramentas unix pode estar errada. Isso é fatal, pois seu sistema operacional regula a quantidade de dados para os quais você pode enviá-los. Envie mais dados do que realmente pode conter; você terá uma perda de dados. Isto é um problema. Então, por que isso pode acontecer?

Você não precisa conhecer bem o protocolo USB para entender o problema. As interfaces seriais têm a propriedade comum de que o dispositivo cliente (a unidade USB) precisará informar sua própria capacidade por meio dessa interface serial. Isso significa que o dispositivo cliente precisa de seu próprio controlador, com algum conhecimento sobre a finalidade do dispositivo e, nesse caso, sua capacidade. Ele também decide o que é feito, quando recebe o comando para armazenar algo. Se o controlador estiver programado dessa maneira, ele pode simplesmente ignorar o comando ou substituir algo com os dados.

O que isto significa? O que quer que suas ferramentas unix digam sobre a capacidade da unidade: é o que as ferramentas pediram à unidade, nada mais. É para isso que o h2testw foi inventado: ele testa o tamanho real com um método explicado posteriormente e o compara com o que a unidade diz. Se isso não for o mesmo, você poderá ter uma perda de dados, porque todas as suas operações comuns para armazenar dados dependem das informações do seu sistema operacional, que apenas solicita ao controlador. Por que apenas perguntar? O teste precisa de tempo e substitui todos os dados na unidade. Portanto, é natural que um sistema operacional precise confiar nessas informações.

Para verificar a capacidade real como o h2testw, você pode realmente usar ddpara gravar dados na unidade, ler novamente e verificar se é o mesmo que você escreveu. Totalmente legítimo. A natureza do hardware e a unidade o tornam mais complicado. Considere caches de gravação, por exemplo. Você precisa garantir que você não leia a partir do cache. Este é apenas um exemplo de por que não é tão fácil quanto parece. Pense também que apenas escrever zeros significa uma baixa entropia de informações, que pode ser reconstruída durante a leitura. Simplesmente não é tão fácil em detalhes. Você ainda pode fazer isso manualmente, é claro.

Mas por que, quando você pode automatizar as coisas? Por que ao trabalho? O f3, como proposto na minha resposta abaixo, implementa muitos pensamentos de muitos colaboradores (considere que ele meio que estendeu o h2testw) e também implementa vários métodos com diferentes trade-offs. O desenvolvedor descobriu os truques de diferentes unidades falsas (também conhecidas como unidades falsificadas) que eles tinham em mãos . Portanto, embora eu compreenda a teoria e o problema (aparentemente porque os problemas são bem explicados na mídia tecnológica alemã, mas não na mídia de língua inglesa), não pretendo entender tudo, e foi por isso que mencionei acima. É apenas a teoria que eu entendo e sou mais um cara de software. Mas, como estudante de informática, eu o entendo bem o suficiente para ver o problema.

"Tente entender os utilitários básicos do Unix"

Na verdade, eu já respondi a essa pergunta, mas para deixar claro: as ferramentas Unix usam apenas o protocolo USB (apenas para dispositivos USB, é claro) para coletar informações. Não faz sentido fazer mais do que isso.

Ajuda comprar apenas de fornecedores de confiança?

tl; dr: Não.

"Quando se trata de comprar mercadorias, assim como qualquer forma de segurança, considere encontrar um vendedor confiável e comprar unidades apenas deles".

Segurança (e segurança) NÃO é confiança! É sobre verificação e validação! Desculpe, mas isso é tão errado de muitas maneiras.

Suponha que você compre através de um vendedor confiável. Algumas questões:

1. O fornecedor testou o hardware para garantir que não haja perda de dados? Reconhece quando ele compra discos falsos e os vende? Não necessariamente.

2. É possível que ele compre coisas que não sabe que são falsas? Totalmente, veja as recentes ryzen fakes: https://www.pcgamer.com/beware-of-fake-ryzen-processors-selling-on-amazon/ , https://www.heise.de/newsticker/meldung/ Direitos autorais: Amazon Faelschungen-AMDs-Ryzen-Prozessoren-im-Umlauf-3772757.html

3. Se eu perder minha apresentação na unidade e estragar tudo, meu fornecedor confiável voltará no tempo e me resgatará? Provavelmente substituirá a unidade, desde que o último DeLorean que viajou no tempo foi destruído em 1885.

Outras coisas

"Essa pergunta realmente parece mais uma" promoção "do que o OP gosta e parece que o OP está muito menos interessado em realmente testar as unidades."

Isto é ridículo. Eu estava procurando especificamente por uma ferramenta semelhante ao h2testw que também roda em linux. E sim, é disso que eu "gostaria", resposta útil, desculpe. Eu não tinha ideia de que a imprensa de língua inglesa não estava tão ciente de tais questões e tive a sorte de encontrar algo assim mais tarde. Esta não é uma promoção, mas, na verdade, parece que você poderia usá-la.

f3 - Combate à fraude em flash

Só encontrei uma alternativa, mas acho que essa é ainda melhor do que a h2testwferramenta original do MS Windows. Felizmente, é realmente fácil de usar, mesmo na linha de comando. Existem GUIs disponíveis, no entanto. Também há muitas informações sobre a implementação e o problema com unidades falsas no site das ferramentas.

• Página principal ( código fonte ):
• Documentação
• GUI QT

A f3 oferece dois métodos:

• método f3probe: muito mais rápido
• método h2testw: mais lento. Teste também o desempenho de R / W. Provavelmente mais confiável.

O método f3probe (recomendado)

f3probeé uma maneira de testar as unidades, não tão precisas, mas mais rápidas, pois elas não gravam em toda a unidade. Você pode ler mais sobre isso no site de ferramentas. Se você quiser ter 100% de certeza, use melhor o método h2testw. Como o desenvolvedor descreve no site:

O f3probe é a maneira mais rápida de identificar unidades falsas e seus tamanhos reais.

E:

Finalmente, graças ao f3probe ser um software livre e, uma vez comprovada a batalha, o f3probe pode ser incorporado em smartphones, câmeras, MP3 players e outros dispositivos para parar de uma vez por todas a proliferação de flash falso.

Há também um exemplo de uso no site:

Aviso : Isso destruirá todos os dados armazenados anteriormente no seu disco!

$ sudo f3probe --destructive --time-ops /dev/sdb
[sudo] password for michel: 
F3 probe 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing may **demolish data,** so it is more suitable for flash drives out of the box, without files being stored yet. The process normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient. 

Bad news: The device `/dev/sdb' is a counterfeit of type limbo

You can "fix" this device using the following command:
f3fix --last-sec=16477878 /dev/sdb

Device geometry:
             *Usable* size: 7.86 GB (16477879 blocks)
            Announced size: 15.33 GB (32155648 blocks)
                    Module: 16.00 GB (2^34 Bytes)
    Approximate cache size: 0.00 Byte (0 blocks), need-reset=yes
       Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 1'13"
 Operation: total time / count = avg time
      Read: 472.1ms / 4198 = 112us
     Write: 55.48s / 2158 = 25.7ms
     Reset: 17.88s / 14 = 1.27s

Observe que ele também retorna um comando que permite usar a unidade com seu tamanho real, usando f3fix.

A ferramenta f3fix

O f3fix cria uma partição que se ajusta ao tamanho real da unidade falsa. Use f3probea saída para determinar os parâmetros para o i3fix

sudo f3fix --last-sec=16477878 /dev/sdb

O método h2testw / Testando o desempenho com f3read / f3write

F3 é uma coleção de ferramentas que lidam com unidades flash falsas. Dois deles juntos implementam o h2testw-Method:

f3write [--start-at=NUM] [--end-at=NUM] <PATH>
f3read  [--start-at=NUM] [--end-at=NUM] <PATH>

f3writesolicitará o tamanho reivindicado pelos dispositivos e o preencherá com arquivos gerados com um tamanho de 1 GB cada. f3readvai ler todos esses arquivos e ver se eles estão completos e não estão quebrados. Como exemplo, os comandos que usei para testar meu pen drive de 128GB:

$ f3write /media/username/1EB8021AB801F0D7/
Free space: 117.94 GB
Creating file 1.h2w ... OK!                           
...
Creating file 118.h2w ... OK!                         
Free space: 0.00 Byte
Average writing speed: 11.67 MB/s

Agora, para testar se os arquivos estão armazenados corretamente:

$ f3read /media/username/1EB8021AB801F0D7/
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
...
Validating file 118.h2w ... 1979488/        0/      0/      0

  Data OK: 117.94 GB (247346272 sectors)
Data LOST: 0.00 Byte (0 sectors)
           Corrupted: 0.00 Byte (0 sectors)
    Slightly changed: 0.00 Byte (0 sectors)
         Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 32.38 MB/s

O teste para uma unidade desse tamanho levou cerca de três horas com esse método e às vezes causava uma carga pesada no disco do meu computador, mas me diz o mais preciso.

Instale no Ubuntu

No terminal:

sudo apt install f3

Isso trará a você: f3brew, f3fix, f3probe, f3read, f3writecom suas páginas man.

Essas ferramentas fazem parte do f3pacote, que está disponível pelo menos no Ubuntu 15.10. Segundo o site, existem mais algumas ferramentas disponíveis. Para obtê-los, dê uma olhada no site.
O pacote vem com páginas de manual curtas, mas úteis, embora eu ache que elas perdem algumas informações do site sobre a diferença de f3read / write e f3probe, por exemplo, e é por isso que essa resposta ficou um pouco mais longa.

Eu escrevi uma ferramenta simples para isso, chamada CapacityTester (captura de tela) e possui uma GUI e uma CLI.

Existe um binário pré - compilado para o Debian 7 disponível para download , que provavelmente funcionará imediatamente em um sistema Ubuntu moderno.

Escrevi para meu uso pessoal, porque não consegui encontrar uma ferramenta gráfica para esse fim. Você só precisa montar sua unidade flash USB vazia primeiro, selecioná-la e iniciar o teste. É uma ferramenta muito burra, porque tudo o que faz é encher a unidade com arquivos e verificar se os dados estão corretos. Ele interromperá o teste no primeiro erro (gravação ou leitura / verificação). Ele relatará o deslocamento do bloco que não pôde ser gravado ou verificado com êxito, mas esse é um deslocamento lógico, portanto essas informações podem ser inúteis porque dependem do sistema de arquivos em que os arquivos estão localizados na unidade. No entanto, quando a unidade estiver cheia de dados e tudo puder ser lido e verificado, deve ser seguro assumir que a capacidade relatada da unidade está correta. Como uma nota rodapé,

Novamente, é muito simples, pois só funciona com arquivos em cima de um sistema de arquivos existente. Portanto, existem alguns KB (+ 1M de buffer) que não podem ser testados. E é muito lento porque realmente preenche todo o sistema de arquivos. O F3 é certamente muito mais sofisticado e também mais rápido, mas não possui GUI. O único motivo pelo qual o CapacityTester existe é porque ele possui uma GUI para que possa ser usado por usuários que não estão familiarizados com a linha de comando ou que simplesmente preferem uma GUI.

O feedback é apreciado.

Abordando o comportamento do OP e a "unidade falsa"

Estou editando a resposta para abordar corretamente alguns pontos, já que o OP tem sido muito veemente (e, na minha opinião, me oponho à maioria dos comentários e respostas, exceto a deles, que acho suspeitos). Particularmente, há muitas alegações de que existe "unidade falsa", mas não há uma definição clara sobre o que realmente significa. O OP declarou:

Eu poderia simplesmente copiar coisas nele, copiar novamente e verificar se os arquivos estão bem. Eu também poderia automatizá-lo com Hashes e outras coisas. Mas eu esperava que houvesse uma solução mais precisa.

Os próprios OP admitiram que "apenas podiam copiar as coisas" e verificar a integridade dos dados, mas foram muito contrários a todos os outros comentários e responderam que propõem qualquer outra coisa e os OP continuaram pressionando F3 como o "negócio real". A pergunta em si começou no tamanho da unidade, mas depois o OP, por qualquer motivo mencionado, hashes para "verificar se os arquivos estão ok", como se houvesse unidades misteriosas que reivindicam um tamanho e permitem que você escreva esse tamanho, mas então os dados estão corrompidos. Portanto, acho altamente suspeito e consideraria o OP promover a F3 como pergunta e resposta de spam.

Quando uma unidade é realmente uma unidade falsa

Na questão, a definição aparente do OP é

"..as unidades que afirmam ter muito espaço (geralmente levadas longe demais, como 128 GB), enquanto oferecem fisicamente apenas 0,5 a 4 GB".

Em outras palavras, de acordo com o OP, o controlador reivindica X quantidade de dados, mas o USB pode conter apenas algo entre 80 e 90% menos do que é reivindicado.

O usuário sudodus propôs nos comentários (grifo nosso ): "Descobri que vários pendrives USB são um pouco menores que o tamanho nominal. Eu os chamo de subdimensionados . Acho que os drives falsos são 'substancialmente subdimensionados' (geralmente metade do tamanho nominal) ou menos ) ". Essa definição é ótima, no entanto, se considerarmos isso, o drive falso é definido em 50%. Uma unidade que reivindica 64 GB, mas pode conter apenas 32 GB, perde tecnicamente metade do seu valor para o proprietário e o proprietário pode colocar apenas metade do que pretendia na unidade.

Proponho uma definição mais simples: dispositivo de armazenamento falsificado é aquele que afirma ter, Claimed Sizemas está abaixo de 15% de tolerância (e tolerância é Claimed Size ± 15 %).

O ± 15 %é muito razoável. Considere também que os usuários geralmente ficam confusos entre as organizações Unix, IEEE e IEC usando prefixo binário em vez de poder do prefixo 10 para o tamanho do armazenamento de dados. A diferença chega a 20% no nível do prefixo yotta, no entanto, as unidades USB ainda não existem, então nos próximos 20 anos talvez 15% seja razoável. (Veja a pergunta askubuntu "Significado de 'i' em 'MiB'" e Prefixo binário )

Testando a unidade

Efetivamente, o usuário não precisa de ferramentas especiais, além do que já vem com o Ubuntu e a maioria dos sistemas Unix compatíveis com POSIX. Vamos enfatizar e reformular a definição novamente:

Se não pudermos gravar a quantidade de dados para dirigir e o que escrevermos tiver uma tolerância de 15%, a unidade estará OK

A maneira mais simples de fazer isso é ddsimplesmente substituir o dispositivo por zeros (e, claro, lembre-se de salvar seus arquivos antes de fazer isso).

sudo dd if=/dev/zero of=/dev/sdb1 iflag=nocache oflag=direct bs=1                        

Observe o bs=1tamanho do bloco for de 1 byte. O ddcomando geralmente fornece um relatório sobre quanto está escrito.

$ dd if=/dev/zero of=/dev/null bs=1 count=1024
1024+0 records in
1024+0 records out
1024 bytes (1.0 kB, 1.0 KiB) copied, 0.00261981 s, 391 kB/s

Pedimos para escrever 1024 bytes, ele escreveu 1024 bytes.

Uma lista mais precisa de etapas que aderem à definição seria:

• Descubra quantos dados a unidade reivindica (supondo que você suspeite dfestar "equivocado"). Neste exemplo, vamos assumir que /dev/sdb1é o arquivo do meu dispositivo para a unidade USB:

  $ df -P /dev/sdb1 | awk 'NR==2{print $2}'
  115247656
  

  Observe que o -Psinalizador é para portabilidade POSIX, o que significa que o tamanho do bloco de dados será 1024 bytes e isso significa que há 115247656 * 1024 bytes nessa unidade.

• Descobrir qual é a tolerância de 15% abaixo do que a unidade afirma (115247656), talvez use um utilitário que suporte o cálculo de ponto flutuante, como awk:

   $ awk 'BEGIN{printf "%d\n",115247656*(1-0.15)}'
   97960507
  

• Crie dados aleatórios no disco rígido do mesmo tamanho da unidade na etapa anterior para usar como referência: dd if=/dev/urandom of=./mytestfile.random bs=1024 count=97960507

• Agora escreva dados dd if=./mytestfile.random of=/dev/sda1. Se a unidade aguenta tanto, é "real". Você também pode tirar md5sumou sha1sumdo ./mytestfile.randome comparar com /dev/sda1agora. Melhoria ainda melhor seria gravar o mytestfile.randomponto de montagem do arquivo, mantendo assim o sistema de arquivos na unidade e particionamento inalterado da unidade, em outras palavras

  dd if=./mytestfile.random of=/mountpoint/for/usb/drive/testfile.random
  

• Para a integridade então, você pode apenas fazer qualquer verificação hashsum, como md5sum, sha1sum, sha256sumou outros. Por exemplo

  md5sum ./mytestfile.random  /mountpoint/for/usb/drive/testfile.random
  

  O ponto principal aqui é que, se a quantidade de dados gravados estiver dentro da tolerância e produzir uma soma de verificação correta antes e depois da gravação - a unidade provavelmente estará OK.

Tudo isso pode ser colocado em um bom roteiro por conveniência, se assim o desejar.

Conclusão

Essa pergunta realmente parece mais uma "promoção" do que o OP gosta e parece que o OP está muito menos interessado em realmente testar as unidades. Além disso, o problema em si é mais humano do que o "drive". Nos comentários, os próprios OP afirmaram que realmente não entendem o comportamento do USB, mas são veementemente culpados "pelo controlador". Vou deixar essa pergunta com 3 pontos:

• Descubra claramente qual é o problema que você está tentando resolver e qual é a definição de "unidade falsa".
• Tente entender os utilitários básicos do Unix
• No que diz respeito à compra de mercadorias, assim como a qualquer forma de segurança, considere encontrar um vendedor confiável e comprar unidades apenas deles.