Controlla le dimensioni reali della chiavetta USB


28

Di recente ho letto molto su false schede MicroSD e chiavette USB che affermano di avere molto spazio (anche se chiedi al tuo computer), offrendo fisicamente molto meno. Di recente ho acquistato un'unità USB SanDisk (dichiarata 128 GB) e voglio testarne le dimensioni. Non viene acquistato tramite ebay o qualcosa del genere, ma voglio davvero testare le dimensioni reali prima di usarlo in modo produttivo.

Potrei semplicemente copiare roba su di esso, copiarlo indietro e vedere se i file sono a posto. Potrei anche automatizzarlo con hash e roba del genere. Ma speravo che ci fosse una soluzione più accurata. Ho letto che per Windows, H2testw fa il trucco. C'è un modo semplice per testarlo su Ubuntu / Linux? Uno strumento specializzato e ben funzionante forse?

Aggiornamento: giusto per essere chiari, l'idea è quella di verificare che la dimensione che il sistema linux viene comunicato dal controller sia corretta ( quindi nessun dato andrà perso ). Non è che voglio vedere se ottengo 128 GB invece di 127.3 GB. Voglio verificare se tutti i dati che scrivo saranno nuovamente leggibili. Sfortunatamente posso trovare solo alcune informazioni al riguardo su siti di tecnologia inglese. Ci sono buone fonti tedesche, però. In realtà sto cercando un'applicazione come quelle, ma per Ubuntu / Linux: https://www.raymond.cc/blog/test-and-detect-fake-or-counterfeit-usb-flash-drives-bought-from -ebay-con-H2testw /

Aggiornamento2: ho provato a mettere insieme alcune fonti in inglese. Non li ho letti tutti in dettaglio, a causa della mancanza di tempo.

Aggiornamento 3: spiegazioni

A causa degli strani critici di seguito, alcune spiegazioni.

Qual è il problema e perché dd da solo non lo risolve?

Questa è una reazione a

"Scopri chiaramente qual è il problema che stai cercando di risolvere e qual è la definizione di" unità falsa "."

Sembra che alcune persone non capiscano il problema. Quindi provo a spiegarlo il più brevemente possibile nei dettagli, anche se penso che questo sia molto al limite della mia domanda.

La capacità dei dispositivi USB forniti dal sistema operativo o dagli strumenti unix può essere errata. Questo è fatale, poiché il tuo sistema operativo regola la quantità di dati a cui puoi inviarli. Invia più dati di quanti ne possano realmente contenere, otterrai una perdita di dati. Questo è un problema. Quindi, perché può succedere?

Non è necessario conoscere bene il protocollo USB per risolvere il problema. Le interfacce seriali hanno la proprietà comune, che il dispositivo client (l'unità USB) dovrà comunicare la propria capacità tramite questa interfaccia seriale. Ciò significa che il dispositivo client ha bisogno del proprio controller con una certa conoscenza dello scopo dei dispositivi e, in questo caso, della sua capacità. Decide anche cosa viene fatto, quando riceve il comando di memorizzare qualcosa. Se il controller è programmato in questo modo, può semplicemente ignorare il comando o sovrascrivere qualcosa con i dati.

Cosa significa questo? Qualunque cosa i tuoi strumenti unix ti diano sulla capacità dell'unità: è ciò che gli strumenti hanno chiesto all'unità, niente di più. Questo è ciò per cui è stato inventato h2testw: verifica la dimensione reale con un metodo spiegato più avanti e lo confronta con ciò che dice l'unità. Se questo non è lo stesso, potresti avere una perdita di dati, perché tutte le tue operazioni comuni per archiviare i dati si basano sulle informazioni del tuo sistema operativo, che richiede solo al controller. Perché basta chiedere? I test richiedono tempo e sovrascrivono tutti i dati sull'unità. Quindi è naturale che un sistema operativo debba fare affidamento su queste informazioni.

Per verificare la reale capacità come h2testw, puoi effettivamente utilizzare ddper scrivere dati sul disco, leggerlo di nuovo e vedere se è lo stesso che hai scritto. Totalmente legittimo. La natura dell'hardware e dell'unità lo rendono più complicato. Considerare ad esempio le cache di scrittura. Devi assicurarti di non leggere dalla cache. Questo è solo un esempio del perché non è così semplice come sembra. Pensa anche che scrivere solo zeri significa una bassa entropia di informazioni, che può essere ricostruita durante la lettura. Non è così semplice nei dettagli. Puoi ancora farlo manualmente, ovviamente.

Ma perché, quando puoi automatizzare le cose? Perché al lavoro? f3, come proposto nella mia risposta di seguito, implementa tonnellate di pensieri di molti partecipanti (considera che è un tipo di h2testw esteso) e implementa anche diversi metodi con diversi compromessi. Lo sviluppatore ha scoperto i trucchi di diverse unità false (ovvero unità contraffatte) che avevano a portata di mano . Quindi, mentre comprendo la teoria e il problema (apparentemente dal momento che i problemi sono ben spiegati nei media tecnologici tedeschi, ma non nei media di lingua inglese), non pretendo di capire tutto, motivo per cui l'ho menzionato sopra. È solo la teoria che capisco e sono più un tipo di software. Ma come studente di informatica lo capisco abbastanza bene da vedere il problema.

"Cerca di capire le utility di base di Unix"

In realtà ho già risposto a questo, ma per chiarire: gli strumenti Unix usano semplicemente il protocollo USB (solo per i dispositivi USB) per raccogliere informazioni. Non ha senso fare di più.

Aiuta a comprare solo da fornitori di fiducia?

tl; dr: non lo fa.

"Quando si tratta di acquistare beni, proprio come per qualsiasi forma di sicurezza, prendere in considerazione la ricerca di un venditore di fiducia e acquistare unità solo da loro."

La sicurezza (e la sicurezza) NON riguarda la fiducia! Si tratta di verifica e validazione! Mi dispiace ma questo è così sbagliato in così tanti modi.

Supponi di acquistare tramite un venditore di fiducia. Alcune domande:

  1. Il fornitore ha testato l'hardware per assicurarsi che non vi siano perdite di dati? Riconosce quando acquista unità false e le vende? Non necessariamente.

  2. È possibile che acquisti cose che non sa essere false? Totalmente, guarda i recenti falsi ryzen: https://www.pcgamer.com/beware-of-fake-ryzen-processors-selling-on-amazon/ , https://www.heise.de/newsticker/meldung/ Direkt-von-Amazon-Faelschungen-von-AMD-Ryzen-Processori-im-Umlauf-3772757.html

  3. Se perdo la mia presentazione nel drive e rovino la presentazione, il mio fornitore di fiducia tornerà indietro nel tempo e mi salverà? Probabilmente sostituirà l'unità, poiché l'ultimo DeLorean in viaggio nel tempo è stato distrutto nel 1885.

Altre cose

"Questa domanda sembra davvero essere più simile a" promozionale "per ciò che piace a OP, e sembra che OP sia molto meno interessato a testare effettivamente le unità."

Questo è ridicolo. Stavo cercando specificamente uno strumento simile a h2testw che funziona anche su Linux. E sì, questo è quello che "mi piacerebbe", risposta utile, quindi mi dispiace. Non avevo idea che la stampa di lingua inglese non fosse così consapevole di tali problemi ed è stato fortunato a trovare qualcosa di simile in seguito. Questo non è un promo, ma in realtà sembra che potresti usarne uno.


2
Non ha molto senso testarlo, andare da ciò che il computer dice che è disponibile o df --block-size=M. Il limite di 4 GB suggerirebbe che è solo il limite della dimensione del file FAT32, non la capacità dell'unità. Non otterrai mai la piena capacità dichiarata, è una media solo per classificarla.
Sir_Scofferoff,

6
Ciò che il computer dice è disponibile è proprio quello che gli viene detto dal controller dell'unità USB. Le unità false stanno mentendo. Se ha una capacità di 4 GB ma afferma di avere 512 GB, il resto che scrivo verrà eliminato o il vecchio spazio verrà sovrascritto, a seconda del controller. Quindi c'è davvero un punto nel testarlo.
verpfeilt,

questo è interessante. non mi è mai venuto in mente di contraffare le dimensioni di un SSD, ma mi piace l'idea di come scrivono i dati e li leggono byte per byte per verificarne la coerenza. posso vedere come questo potrebbe essere un problema e uno strumento come questo potrebbe essere utile.

1
FakeFlashCheck ha anche una scansione rapida. C'è qualche OSALT per quello?
neverMind9,

PS: ho già trovato f3probe. Vedi il mio commento qui sotto.
neverMind9,

Risposte:


34

f3 - Combatti la frode flash

Ho trovato solo un'alternativa, ma penso che sia addirittura migliore rispetto allo h2testwstrumento originale per MS Windows. Fortunatamente, è davvero facile da usare, anche dalla riga di comando. Ci sono GUI disponibili, però. Ci sono anche molte informazioni sull'implementazione e sul problema delle unità false sul sito Web degli strumenti.

f3 offre due metodi:

  • Metodo f3probe: molto più veloce
  • Metodo h2testw: più lento. Testare anche le prestazioni R / W. Probabilmente più affidabile.

Il metodo f3probe (consigliato)

f3probeè un modo per testare le unità, non così preciso ma più veloce poiché non scrive sull'intera unità. Puoi leggere di più a riguardo sul sito web degli strumenti. Se vuoi essere sicuro al 100%, usa meglio il metodo h2testw. Come lo sviluppatore descrive sul sito Web:

f3probe è il modo più veloce per identificare unità false e le loro dimensioni reali.

E:

Infine, grazie al fatto che f3probe è un software gratuito e una volta che f3probe è stato provato in battaglia, f3probe potrebbe essere incorporato su smartphone, fotocamere, lettori MP3 e altri dispositivi per arrestare una volta per tutte la proliferazione di falsi flash.

C'è anche un esempio di utilizzo sul sito Web:

Attenzione : questo distruggerà tutti i dati precedentemente memorizzati sul tuo 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

Si noti che restituisce anche un comando che consente di utilizzare l'unità con le sue dimensioni reali, utilizzando f3fix.

Lo strumento f3fix

f3fix crea una partizione che si adatta alle dimensioni effettive dell'unità falsa. Usa l f3probe'output per determinare i parametri per i3fix

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

Il metodo h2testw / Test delle prestazioni con f3read / f3write

F3 è una raccolta di strumenti che si occupano di unità flash false. Due di loro insieme implementano il h2testw-Method:

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

f3writechiederà la dimensione richiesta per i dispositivi e la riempirà di file generati con una dimensione di 1 GB ciascuno. f3readleggerà tutti quei file e vedrà che sono completi e non rotti. Ad esempio i comandi che ho usato per testare la mia chiavetta USB da 128 GB:

$ 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

Ora per verificare se i file sono archiviati correttamente:

$ 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

Il test per un'unità di queste dimensioni ha richiesto circa tre ore con questo metodo e talvolta ha causato un pesante caricamento del disco sul mio computer, ma mi viene detto che è il più preciso.

Installa in Ubuntu

Sul terminale:

sudo apt install f3

Questo vi porterà: f3brew, f3fix, f3probe, f3read, f3writecon le loro pagine man.

Questi strumenti fanno parte del f3pacchetto, che è almeno disponibile su Ubuntu 15.10. Secondo il sito Web, ci sono alcuni altri strumenti disponibili. Per farli dare un'occhiata al sito web.
Il pacchetto viene fornito con manpage brevi ma utili, anche se penso che manchino alcune informazioni dal sito Web sulla differenza di f3read / write e f3probe per esempio, motivo per cui questa risposta è diventata un po 'più lunga.


2
Grazie per aver introdotto questo fantastico strumento. Voglio solo aggiungere che l'installazione utilizzando apt-getverrà installato f3reade fwrite solo come f3probee f3fixsono considerati sperimentali. Se vuoi usarli dovrai costruirli dal sorgente usando make experimentaldopo aver installato le loro dipendenze sudo apt-get install libudev1 libudev-dev libparted0-dev. Vedi github.com/AltraMayor/f3#the-extra-applications-for-linux
Ahmed Essam

1
"[f3probe] non è più sperimentale, ma è disponibile solo su Linux." github.com/AltraMayor/f3/issues/78#issuecomment-378599141
verpfeilt

4

Ho scritto un semplice strumento proprio per questo, si chiama CapacityTester (screenshot) e ha una GUI e una CLI.

C'è un binario precompilato per Debian 7 disponibile per il download , che molto probabilmente funzionerà immediatamente su un moderno sistema Ubuntu.

L'ho scritto per uso personale perché non sono riuscito a trovare uno strumento grafico per questo scopo. Devi solo montare prima la tua chiavetta USB vuota, selezionarla e avviare il test. È uno strumento molto stupido perché tutto ciò che fa è riempire l'unità di file e quindi verificare che i dati sull'unità siano corretti. Si interromperà il test al primo errore (scrittura o lettura / verifica). Riporterà l'offset del blocco che non è stato possibile scrivere o verificare correttamente, ma si tratta di un offset logico, pertanto queste informazioni potrebbero essere inutili perché dipendono dal filesystem in cui si trovano i file sull'unità. Tuttavia, quando l'unità è stata riempita di dati e tutto può essere letto e verificato, dovrebbe essere sicuro supporre che la capacità dichiarata dell'unità sia corretta. Come nota a margine,

Ancora una volta, è molto semplice in quanto funziona solo con i file in cima a un file system esistente. Quindi ci sono alcuni KB (+ 1M buffer) che non possono essere testati. Ed è molto lento perché riempie davvero l'intero filesystem. F3 è sicuramente molto più sofisticato e anche più veloce, ma non ha una GUI. L'unico motivo per cui CapacityTester esiste è perché ha una GUI in modo che possa essere utilizzata da utenti che non hanno familiarità con la riga di comando o che semplicemente preferiscono una GUI.

Il feedback è apprezzato.


Come affermato sul sito Web degli sviluppatori, sono disponibili una GUI QT e una GUI per OSX (non le ho provate). Penso che sia basato su QT4, però. Perché non usare anche F3 come backend? Non renderebbe il tuo strumento più complicato e probabilmente lo renderebbe più funzionale / efficace, usando la conoscenza che è stata spesa su F3.
verpfeilt

-6

Affrontare il comportamento di OP e il "drive falso"

Sto modificando la risposta per affrontare correttamente alcuni punti, poiché OP è stato molto veemente (e secondo me, opporsi alla maggior parte dei commenti e delle risposte tranne il loro, che trovo sospetto). In particolare, molti sostengono che esiste un "falso impulso", ma non esiste una definizione chiara su cosa diavolo significhi realmente. OP dichiarato:

Potrei semplicemente copiare roba su di esso, copiarlo indietro e vedere se i file sono a posto. Potrei anche automatizzarlo con hash e roba del genere. Ma speravo che ci fosse una soluzione più accurata.

Gli stessi OP hanno ammesso di "poter semplicemente copiare roba" e di verificare l'integrità dei dati, ma erano molto contrari a tutti gli altri commenti e risposte che propongono qualsiasi altra cosa e OP ha continuato a spingere F3 solo come "vero affare". All'inizio la domanda stessa è iniziata sulla dimensione dell'unità, ma poi OP per qualsiasi motivo menzionato hash per "guardare se i file sono ok", come se ci fossero unità misteriose che rivendicano una dimensione e ti permettono di scrivere quella dimensione, ma quindi i dati sono corrotti. Pertanto, lo trovo altamente sospetto e considererei OP che promuove F3 come domanda e risposta di spam.

Quando un'unità è in realtà un'unità falsa

Nella domanda, la definizione apparente di OP è

"... unità che dichiarano di avere molto spazio (spesso portate troppo lontano, come 128 GB), offrendo fisicamente solo da 0,5 a 4 GB."

In altre parole, secondo OP, il controller rivendica una quantità X di dati, ma USB può contenere solo qualcosa come l'80-90% in meno di ciò che viene rivendicato.

L'utente sudodus ha proposto nei commenti (enfasi aggiunta): "Ho scoperto che diversi pendrive USB sono leggermente più piccoli della dimensione nominale. Li chiamo sottodimensionati . Penso che le unità false siano " sostanzialmente sottodimensionate " (di solito metà della dimensione nominale o meno ) ". Questa definizione è ottima, tuttavia se la prendiamo, la falsa unità è definita al 50%. Un'unità che afferma 64 GB ma può contenere solo 32 GB, tecnicamente perde metà del suo valore per il proprietario e il proprietario può solo mettere metà di ciò che intendeva sull'unità.

Propongo una definizione più semplice: il dispositivo di archiviazione contraffatto è quello che afferma di avere Claimed Sizema è inferiore al 15% di tolleranza (e la tolleranza lo è Claimed Size ± 15 %).

Il ± 15 %è molto ragionevole. Considera anche che gli utenti sono generalmente confusi tra le organizzazioni Unix, IEEE e IEC che utilizzano il prefisso binario invece del potere del prefisso 10 per la dimensione di archiviazione dei dati. La differenza arriva al 20% a livello di prefisso yotta, tuttavia le unità USB non sono ancora presenti, quindi forse per i prossimi 20 anni il 15 percento è ragionevole. (Vedi la domanda di askubuntu "Significato di 'i' in 'MiB'" e Prefisso binario )

Test dell'unità

In effetti, l'utente non ha bisogno di strumenti speciali, a parte ciò che già viene fornito con Ubuntu e la maggior parte dei sistemi Unix compatibili con POSIX. Sottolineiamo e riformuliamo di nuovo la definizione:

Se non possiamo scrivere quantità di dati da guidare e ciò che scriviamo è entro il 15% di tolleranza, allora l'unità è OK

il modo semplice per farlo è con dd, basta sovrascrivere il dispositivo con zeri (e ovviamente ricordarsi di salvare i file prima di farlo).

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

Nota bs=1per la dimensione del blocco di 1 byte. Il ddcomando di solito fornisce un rapporto su quanto è scritto.

$ 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

Gli abbiamo chiesto di scrivere 1024 byte, ha scritto 1024 byte.

Un elenco più preciso dei passaggi che aderiscono alla definizione sarebbe:

  • Scopri quanti dati afferma l'unità (supponendo che tu sospetti dfdi essere "errato"). In questo esempio, supponiamo che /dev/sdb1sia il mio file di dispositivo per l'unità USB:

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

    Si noti che il -Pflag è per la portabilità POSIX, il che significa che la dimensione del blocco di dati sarà 1024 byte e ciò significa che ci sono 115247656 * 1024 byte su quell'unità.

  • Scopri qual è la tolleranza del 15% al ​​di sotto di quanto afferma l'unità (115247656), forse utilizza un'utilità che supporta il calcolo in virgola mobile come awk:

     $ awk 'BEGIN{printf "%d\n",115247656*(1-0.15)}'
     97960507
    
  • Crea dati casuali su disco rigido delle stesse dimensioni dell'unità nel passaggio precedente da utilizzare come benchmark: dd if=/dev/urandom of=./mytestfile.random bs=1024 count=97960507

  • Ora scrivi i dati dd if=./mytestfile.random of=/dev/sda1. Se l'unità può contenere così tanto, è "reale". Puoi anche prendere md5sumo sha1sumdel ./mytestfile.randome confrontare con /dev/sda1ora. Un miglioramento ancora migliore sarebbe scrivere il mytestfile.randommountpoint del file, mantenendo così il filesystem sull'unità e inalterando il partizionamento dell'unità, in altre parole

    dd if=./mytestfile.random of=/mountpoint/for/usb/drive/testfile.random
    
  • Per l'integrità allora, si può solo fare alcun controllo hashsum, come ad esempio md5sum, sha1sum, sha256sumo altro. Per esempio

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

    Il punto chiave qui è che se la quantità di dati scritti rientra nella tolleranza e produce un checksum corretto prima e dopo la scrittura, probabilmente l'unità è OK.

Tutto questo può essere inserito in una bella sceneggiatura per comodità, se uno lo desidera.

Conclusione

Questa domanda sembra davvero essere più simile a "promozionale" per ciò che piace a OP, e sembra che OP sia molto meno interessato a testare effettivamente le unità. Inoltre, il problema stesso è più umano del problema "drive". Nei commenti, gli stessi OP hanno affermato di non capire veramente il comportamento USB, ma sono veemente da incolpare "il controller". Lascerò questa domanda con 3 punti:

  • Capisci chiaramente qual è il problema che stai cercando di risolvere e qual è la definizione di "falso drive".
  • Cerca di capire le utility di base di Unix
  • Quando si tratta di acquistare beni, proprio come per qualsiasi forma di sicurezza, prendere in considerazione la ricerca di un venditore di fiducia e acquistare unità solo da loro.

1
Grazie, ma non sono sicuro che dd rilevi le dimensioni reali, perché il controller fingerebbe che abbia tanto spazio. Penso che devi scrivere in un file (o più file) e verificare se riesci a recuperarlo completamente. Suppongo che ci sia un motivo per cui ci sono strumenti dedicati per i test, purtroppo è solo Windows. Immagino che dovrò usare una VM. Beh, è ​​stato abbastanza grande nelle notizie in Germania qualche tempo fa. (Fonte tedesca sull'argomento: heise.de/ct/ausgabe/… )
verpfeilt

1
@verpfeilt Beh, non parlo tedesco quindi l'articolo dovrà essere riassunto o tradotto da qualcuno. In che modo il controller potrebbe fingere di avere la stessa quantità di spazio? ddriporta la quantità di dati che ha scritto / dato al dispositivo, non vedo come possa essere simulato.
Sergiy Kolodyazhnyy

2
Bene, puoi scrivere tutto, ma ciò non significa che il client USB lo memorizzerà. Se ho capito bene, il problema risiede direttamente nell'architettura USB. Non puoi semplicemente attaccare un po 'di memoria flash, ma ha bisogno di un chip che soddisfi il protocollo. Come uno stub ( en.wikipedia.org/wiki/Method_stub ) questo ti consente di creare una memoria di sola scrittura (il disco ha una piccola quantità di memoria per archiviare piccoli file). Ecco perché esistono strumenti come h2testw. Ecco qualcosa in inglese: myce.com/news/…
verpfeilt

1
@SergiyKolodyazhnyy, ho scoperto che diversi pendrive USB sono leggermente più piccoli delle dimensioni nominali. Li chiamo sottodimensionati . Penso che le unità false siano "sostanzialmente sottodimensionate" (di solito metà della dimensione nominale o inferiore). Immagino che scrivere qualcosa sull'unità con dde successivamente controllare il md5sum dovrebbe controllare quanto potrebbe essere scritto e letto correttamente. (Penso che gli strumenti speciali nella risposta di @ verpfeilt siano più attraenti, ma non li ho testati. Ho molte chiavette USB e schede di memoria, non credo di averne ancora acquistato uno falso.)
sudodus

1
@SergiyKolodyazhnyy, concordo con la tua definizione aggiornata, "il dispositivo di archiviazione contraffatto è quello che afferma di avere dimensioni dichiarate ma è inferiore al 15% di tolleranza (e la tolleranza è dichiarata dimensione ± 15%)". - Grazie per un ottimo aggiornamento della tua risposta :-)
sudodus
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.