J'ai récemment beaucoup lu sur les fausses cartes MicroSD et les clés USB qui prétendent avoir beaucoup d'espace (même si vous demandez à votre ordinateur), tout en offrant physiquement beaucoup moins. J'ai récemment acheté une clé USB SanDisk (128 Go revendiqués) et je veux tester sa taille. Ce n'est pas acheté via ebay ou quelque chose, mais je veux vraiment tester la taille réelle avant de l'utiliser de manière productive.

Je pourrais simplement copier des trucs dessus, les recopier et voir si les fichiers sont corrects. Je pourrais aussi l'automatiser avec Hash et d'autres trucs. Mais j'espérais qu'il y aurait une solution plus précise. J'ai lu que pour Windows, H2testw fait l'affaire. Existe-t-il un moyen simple de tester cela sur Ubuntu / Linux? Un outil spécialisé et qui fonctionne bien peut-être?

Mise à jour: Juste pour être clair, l'idée est de vérifier que la taille que le système Linux reçoit du contrôleur est correcte ( donc aucune donnée ne sera perdue ). Ce n'est pas comme si je voulais voir si j'obtiens 128 Go au lieu de 127,3 Go. Je veux tester si toutes les données que j'écris seront à nouveau lisibles. Malheureusement, je ne peux trouver que quelques informations à ce sujet sur les sites de technologie en anglais. Il existe cependant de bonnes sources allemandes. Je recherche en fait une application comme celles-ci, mais pour Ubuntu / Linux: https://www.raymond.cc/blog/test-and-detect-fake-or-counterfeit-usb-flash-drives-bought-from -bay-with-h2testw /

Update2: J'ai essayé de rassembler quelques sources en anglais. Je ne les ai pas tous lus en détail, faute de temps.

• 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: Explications

En raison des étranges critiques ci-dessous, quelques explications.

Quel est le problème et pourquoi dd seul ne le résout-il pas?

Ceci est une réaction à

"Déterminez clairement quel est le problème que vous essayez de résoudre et quelle est la définition de" faux lecteur "."

Il semble que certaines personnes ne comprennent pas le problème. J'essaie donc de l'expliquer aussi brièvement que possible dans les détails, même si je pense que cela va bien au-delà de ma question.

La capacité des périphériques USB fournis par votre système d'exploitation ou les outils Unix peut être erronée. C'est fatal, car votre système d'exploitation réglemente la quantité de données à laquelle vous pouvez l'envoyer. Envoyez plus de données qu'il ne peut en contenir, vous obtiendrez une perte de données. C'est un problème. Alors, pourquoi cela peut-il arriver?

Vous n'avez pas besoin de bien connaître le protocole USB pour comprendre le problème. Les interfaces série ont la propriété commune, que le périphérique client (le lecteur USB) devra indiquer sa propre capacité via cette interface série. Cela signifie que l'appareil client a besoin de son propre contrôleur avec une certaine connaissance de l'objectif des appareils et, dans ce cas, de sa capacité. Il décide également de ce qui est fait, lorsqu'il reçoit la commande de stocker quelque chose. Si le contrôleur est programmé de cette façon, il peut simplement ignorer la commande ou écraser quelque chose avec les données.

Qu'est-ce que ça veut dire? Quels que soient vos outils Unix sur la capacité du disque: c'est ce que les outils demandaient au disque, rien de plus. C'est pour cela que h2testw a été inventé: il teste la taille réelle avec une méthode expliquée plus loin et la compare à ce que dit le lecteur. Si ce n'est pas la même chose, vous risquez d'avoir une perte de données, car toutes vos opérations courantes pour stocker des données, s'appuient sur les informations de votre système d'exploitation, qui demande simplement au contrôleur. Pourquoi juste demander? Les tests nécessitent du temps et écrasent toutes les données sur le lecteur. Il est donc naturel qu'un système d'exploitation doive s'appuyer sur ces informations.

Pour vérifier la capacité réelle comme h2testw, vous pouvez en effet utiliser ddpour écrire des données sur le lecteur, les relire et voir si c'est la même chose que vous avez écrite. Totalement légitime. La nature du matériel et du lecteur le rend plus compliqué. Prenons l'exemple des caches d'écriture. Vous devez vous assurer que vous ne lisez pas à partir du cache. Ce n'est qu'un exemple des raisons pour lesquelles ce n'est pas aussi facile qu'il n'y paraît. Pensez également que le simple fait d'écrire des zéros signifie une faible entropie d'informations, qui peut être reconstruite lors de la lecture. Ce n'est pas si simple en détail. Vous pouvez toujours le faire manuellement, bien sûr.

Mais pourquoi, quand on peut automatiser les choses? Pourquoi au travail? f3, comme proposé dans ma réponse ci-dessous, implémente des tonnes de réflexions de nombreux contributeurs (considérez qu'il s'agit d'une sorte de h2testw étendu) et il implémente également plusieurs méthodes avec différents compromis. Le développeur a compris les astuces des différents faux disques (alias disques contrefaits) qu'ils avaient sous la main . Donc, bien que je comprenne la théorie et le problème (apparemment puisque les problèmes sont bien expliqués dans les médias technologiques allemands, mais pas dans les médias anglophones), je ne prétends pas tout comprendre, c'est pourquoi je l'ai mentionné ci-dessus. C'est juste la théorie que je comprends, et je suis plutôt un gars du logiciel. Mais en tant qu'étudiant en informatique, je le comprends assez bien pour voir le problème.

"Essayez de comprendre les utilitaires de base d'Unix"

En fait, j'ai déjà répondu à celle-ci, mais pour être clair: les outils Unix utilisent simplement le protocole USB (pour les périphériques USB, bien sûr) pour recueillir des informations. Cela n'a pas de sens de faire plus que cela.

Est-il utile d'acheter uniquement auprès de fournisseurs de confiance?

tl; dr: Ce n'est pas le cas.

"Quand il s'agit d'acheter des marchandises, comme pour toute forme de sécurité, pensez à trouver un vendeur de confiance et n'achetez que des disques chez eux."

La sécurité (et la sécurité) n'est PAS une question de confiance! Il s'agit de vérification et de validation! Désolé mais c'est tellement faux à bien des égards.

Supposons que vous achetez via un vendeur de confiance. Quelques questions:

1. Le fournisseur a-t-il testé le matériel pour s'assurer qu'il n'y a aucune perte de données? Reconnaît-il quand il achète de faux disques et les vend? Pas nécessairement.

2. Est-il possible qu'il achète des trucs qu'il ne sait pas être faux? Totalement, regardez les faux ryzen récents: https://www.pcgamer.com/beware-of-fake-ryzen-processors-selling-on-amazon/ , https://www.heise.de/newsticker/meldung/ Direkt-von-Amazon-Faelschungen-von-AMDs-Ryzen-Prozessoren-im-Umlauf-3772757.html

3. Si je perds ma présentation dans le lecteur et que je bousille la présentation, mon fournisseur de confiance va-t-il remonter le temps et me sauver? Il remplacera probablement le lecteur, car le dernier DeLorean dans le temps a été détruit en 1885.

D'autres choses

"Cette question semble vraiment être plus" promo "pour ce que OP aime, et semble que OP est beaucoup moins intéressé à tester réellement les lecteurs."

C'est ridicule. Je cherchais spécifiquement un outil similaire à h2testw qui fonctionne également sur linux. Et oui, c'est ce que j'aimerais, réponse utile, désolé. Je ne savais pas que la presse anglophone n'était pas au courant de ces problèmes et j'ai eu la chance de trouver quelque chose comme ça plus tard. Ce n'est pas une promo, mais il semble que vous puissiez en utiliser une.

f3 - Lutte contre la fraude Flash

Il n'y a qu'une seule alternative que j'ai trouvée, mais je pense que c'est encore mieux que l' h2testwoutil d' origine pour MS Windows. Heureusement, il est vraiment facile à utiliser, même en ligne de commande. Il existe cependant des interfaces graphiques. Il existe également de nombreuses informations sur la mise en œuvre et le problème des faux disques sur le site Web des outils.

• Page principale ( code source ):
• Documentation
• GUI QT

f3 propose deux méthodes:

• Méthode f3probe: beaucoup plus rapide
• Méthode h2testw: plus lente. Testez également les performances R / W. Probablement plus fiable.

La méthode f3probe (recommandée)

f3probeest un moyen de tester les disques, pas aussi précis mais plus rapide car il n'écrit pas sur l'ensemble du disque. Vous pouvez en savoir plus à ce sujet sur le site Web des outils. Si vous voulez être sûr à 100%, mieux vaut utiliser la méthode h2testw. Comme le développeur le décrit sur le site Web:

f3probe est le moyen le plus rapide d'identifier les faux disques et leurs tailles réelles.

Et:

Enfin, grâce à f3probe étant un logiciel gratuit, et une fois que f3probe a fait ses preuves, f3probe pourrait être intégré sur les smartphones, appareils photo, lecteurs MP3 et autres appareils pour arrêter une fois pour toutes la prolifération des faux flashs.

Il existe également un exemple d'utilisation sur le site:

Avertissement : cela détruira toutes les données précédemment stockées sur votre disque!

$ 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

Notez qu'il renvoie également une commande qui vous permet d'utiliser le lecteur avec sa taille réelle, en utilisant f3fix.

L'outil f3fix

f3fix crée une partition qui correspond à la taille réelle du faux lecteur. Utilisez f3probela sortie de pour déterminer les paramètres d'i3fix

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

La méthode h2testw / Test des performances avec f3read / f3write

F3 est une collection d'outils qui traitent des faux lecteurs flash. Deux d'entre eux implémentent ensemble la h2testw-Méthode:

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

f3writedemandera la taille revendiquée des appareils et la remplira avec des fichiers générés d'une taille de 1 Go chacun. f3readva lire tous ces fichiers et voir qu'ils sont complets et non cassés. À titre d'exemple, les commandes que j'ai utilisées pour tester ma clé USB ~ 128 Go:

$ 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

Maintenant, pour tester si les fichiers sont correctement stockés:

$ 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

Le test pour un lecteur de cette taille a pris environ trois heures avec cette méthode et a parfois provoqué une lourde charge de disque sur mon ordinateur, mais il me semble être le plus précis.

Installer dans Ubuntu

Sur terminal:

sudo apt install f3

Cela vous apportera: f3brew, f3fix, f3probe, f3read, f3writeavec leurs pages de manuel.

Ces outils font partie du f3package, qui est au moins disponible sur Ubuntu 15.10. Selon le site Web, d'autres outils sont disponibles. Pour les obtenir, consultez le site Web.
Le paquet est livré avec des pages de manuel courtes mais utiles, bien que je pense qu'elles manquent certaines informations du site Web sur la différence de f3read / write et f3probe par exemple, c'est pourquoi cette réponse est devenue un peu plus longue.

J'ai écrit un outil simple pour cela, il s'appelle CapacityTester (capture d'écran) et il a une interface graphique ainsi qu'une CLI.

Il y a un binaire précompilé pour Debian 7 disponible au téléchargement , qui est très susceptible de fonctionner hors de la boîte sur un système Ubuntu moderne.

Je l'ai écrit pour mon usage personnel car je n'ai pas trouvé d'outil graphique à cet effet. Il vous suffit tout d'abord de monter votre clé USB vide, de la sélectionner et de lancer le test. C'est un outil très stupide car il ne fait que remplir le lecteur de fichiers, puis vérifier que les données sur le lecteur sont correctes. Il abandonnera le test sur la première erreur (écriture ou lecture / vérification). Il signalera le décalage du morceau qui n'a pas pu être écrit ou vérifié avec succès, mais il s'agit d'un décalage logique, de sorte que ces informations peuvent être inutiles car elles dépendent du système de fichiers où se trouvent les fichiers sur le lecteur. Cependant, lorsque le lecteur a été rempli de données et que tout a pu être lu et vérifié, il doit être sûr de supposer que la capacité signalée du lecteur est correcte. En remarque,

Encore une fois, c'est très simple car cela ne fonctionne qu'avec des fichiers au-dessus d'un système de fichiers existant. Il existe donc des Ko (+ 1M de mémoire tampon) qui ne peuvent pas être testés. Et c'est très lent car il remplit vraiment tout le système de fichiers. Le F3 est certainement beaucoup plus sophistiqué et aussi plus rapide, mais il n'a pas d'interface graphique. La seule raison pour laquelle CapacityTester existe est parce qu'il a une interface graphique de sorte qu'il peut être utilisé par des utilisateurs qui ne connaissent pas la ligne de commande ou qui préfèrent simplement une interface graphique.

Les commentaires sont appréciés.

S'attaquer au comportement de l'OP et au "faux lecteur"

J'édite la réponse pour répondre correctement à quelques points, car OP a été très véhément (et à mon avis, s'oppose à la plupart des commentaires et des réponses sauf les leurs, ce que je trouve suspect). En particulier, il y a beaucoup de prétentions qu'il existe une «fausse pulsion», mais il n'y a pas de définition claire de ce que cela signifie réellement. OP a déclaré:

Je pourrais simplement copier des trucs dessus, les recopier et voir si les fichiers sont corrects. Je pourrais aussi l'automatiser avec Hash et d'autres trucs. Mais j'espérais qu'il y aurait une solution plus précise.

OP a lui-même admis qu'il "pouvait simplement copier des choses" et vérifier l'intégrité des données, mais était très opposé à tous les autres commentaires et réponses qui proposent autre chose et OP n'a fait que pousser F3 comme "la vraie affaire". La question elle-même a d'abord commencé sur la taille du lecteur, mais ensuite, pour une raison quelconque, OP hachait "si les fichiers sont corrects", comme s'il y avait des lecteurs mystérieux qui réclamaient une taille et vous permettaient d'écrire cette taille, mais alors les données sont corrompues. Par conséquent, je trouve cela très suspect et considérerais OP faisant la promotion de F3 comme une question et une réponse de spam.

Quand un lecteur est en fait un faux lecteur

Dans la question, la définition apparente d'OP est

"..des disques qui prétendent avoir beaucoup d'espace (souvent trop loin, comme 128 Go), tout en n'offrant physiquement que 0,5 à 4 Go."

En d'autres termes, selon OP, le contrôleur réclame X quantité de données, mais l'USB ne peut contenir que 80 à 90% de moins que ce qui est revendiqué.

L'utilisateur sudodus a proposé dans les commentaires (non souligné dans l'original): "J'ai constaté que plusieurs clés USB sont légèrement plus petites que la taille nominale. Je les appelle sous-dimensionnées . Je pense que les faux disques sont " sensiblement sous-dimensionnés " (généralement la moitié de la taille nominale). ou moins ) ". Cette définition est excellente, mais si nous prenons cela, le faux lecteur est défini à 50%. Un lecteur qui revendique 64 Go mais ne peut en contenir que 32 Go, perd techniquement la moitié de sa valeur pour le propriétaire et le propriétaire ne peut mettre que la moitié de ce qu'il souhaitait sur le lecteur.

Je propose une définition plus simple: le dispositif de stockage de contrefaçon est celui qui prétend avoir une Claimed Sizetolérance inférieure à 15% (et la tolérance l'est Claimed Size ± 15 %).

C'est ± 15 %très raisonnable. Considérez également que les utilisateurs sont généralement confus entre les organisations Unix, IEEE et CEI utilisant le préfixe binaire au lieu de la puissance de 10 préfixe pour la taille de stockage des données. La différence atteint 20% au niveau du préfixe yotta, mais les clés USB ne sont pas encore là, donc pour peut-être 20 ans, 15% est raisonnable. (Voir question askubuntu "Signification de 'i' dans 'MiB'" et préfixe binaire )

Test du lecteur

En effet, l'utilisateur n'a pas besoin d'outils spéciaux, à part ce qui est déjà fourni avec Ubuntu et la plupart des systèmes Unix conformes POSIX. Soulignons et reformulons à nouveau la définition:

Si nous ne pouvons pas écrire la quantité de données sur le lecteur et que ce que nous écrivons est dans une tolérance de 15%, alors le lecteur est OK

La façon simple de le faire est de dd, écraser simplement l'appareil avec des zéros (et bien sûr, n'oubliez pas de sauvegarder vos fichiers avant de le faire).

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

Notez la bs=1taille de bloc de 1 octet. La ddcommande donne généralement un rapport sur le montant écrit.

$ 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

Nous lui avons demandé d'écrire 1024 octets, il a écrit 1024 octets.

Une liste plus précise des étapes respectant la définition serait:

• Calculez la quantité de données réclamée par le lecteur (en supposant que vous pensez dfêtre "trompé"). Dans cet exemple, supposons que /dev/sdb1c'est mon fichier de périphérique pour le lecteur USB:

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

  Notez que l' -Pindicateur est pour la portabilité POSIX, ce qui signifie que la taille des blocs de données sera de 1024 octets, et cela signifie qu'il y a 115247656 * 1024 octets sur ce lecteur.

• Déterminez ce qu'est une tolérance de 15% en dessous de ce que prétend le lecteur (115247656), utilisez peut-être un utilitaire qui prend en charge le calcul en virgule flottante, comme awk:

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

• Créez des données aléatoires sur un disque dur de la même taille que le lecteur à l'étape précédente pour l'utiliser comme référence: dd if=/dev/urandom of=./mytestfile.random bs=1024 count=97960507

• Maintenant, écrivez des données dd if=./mytestfile.random of=/dev/sda1. Si le lecteur peut contenir autant, c'est "réel". Vous pouvez également prendremd5sum ou sha1sumde ./mytestfile.randomet comparer avec /dev/sda1maintenant. Une amélioration encore meilleure consisterait à écrire le point mytestfile.randomde montage du fichier, gardant ainsi le système de fichiers sur le lecteur et un partitionnement inchangé du lecteur, en d'autres termes

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

• Pour l' intégrité alors, vous pouvez juste faire une vérification des checksums, tels que md5sum, sha1sum, sha256sumou autres. Par exemple

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

  Le point clé ici est que si la quantité de données écrites est dans la tolérance et produit une somme de contrôle correcte avant et après l'écriture - le lecteur est probablement OK.

Tout cela peut être mis dans un joli script pour plus de commodité, si l'on le souhaite.

Conclusion

Cette question semble vraiment être plus "promo" pour ce que OP aime, et semble que OP est beaucoup moins intéressé à tester réellement les disques. De plus, le problème lui-même est plus humain qu'un problème de "lecteur". Dans les commentaires, OP eux-mêmes ont déclaré qu'ils ne comprenaient pas vraiment le comportement USB, mais étaient véhémentes pour blâmer "le contrôleur". Je vais laisser cette question avec 3 points:

• Déterminez clairement quel est le problème que vous essayez de résoudre et quelle est la définition de «faux lecteur».
• Essayez de comprendre les utilitaires de base d'Unix
• Lorsqu'il s'agit d'acheter des marchandises, tout comme pour toute forme de sécurité, envisagez de trouver un vendeur de confiance et n'achetez que des disques chez eux.