Controllare le dimensioni reali della chiavetta USB

16

Recentemente ho letto molto su false chiavette USB che dichiarano di avere molto spazio (anche se chiedi al tuo computer), mentre offri meno. Recentemente ho acquistato un'unità USB SanDisk (dichiarata 128 GB) e voglio testarne le dimensioni. Non è acquistato tramite ebay o qualcosa del genere, ma voglio davvero testare la dimensione reale prima di usarla in modo produttivo.

Potrei semplicemente copiare qualcosa su di esso, copiarlo e controllare se i file sono a posto. Potrei anche automatizzarlo con Hash e roba. 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? Forse uno strumento specializzato e ben funzionante?

Aggiornamento: Per essere chiari, l'idea è di verificare che la dimensione che il sistema linux riceve dal controller sia corretta ( quindi nessun dato andrà perso ). Non è che voglio vedere se ottengo 128 GB invece di 127,3 GB. Voglio testare se tutti i dati che scrivo saranno nuovamente leggibili. Purtroppo posso trovare solo alcune informazioni su questo nei siti di tecnologia inglese. Ci sono buone fonti tedesche, però. In realtà sto cercando un'applicazione come questa, ma per Ubuntu / Linux: link

Update2: Ho provato a mettere insieme alcune fonti in inglese. Non li ho letti tutti in dettaglio, a causa del tempo mancante.

Update3: Spiegazioni

A causa degli strani commenti qui sotto, 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" Fake Drive "."

Sembra che alcune persone non capiscano il problema. Quindi cerco di spiegarlo nel modo più breve possibile nei dettagli, anche se penso che sia molto più ampio della mia domanda.

La capacità dei dispositivi USB forniti dal sistema operativo o dagli strumenti Unix può essere errata. Questo è fatale, dal momento che il tuo sistema operativo regola la quantità di dati a cui puoi inviarlo. Invia più dati di quanti possano effettivamente contenere, otterrai una perdita di dati. Questo è un problema. Quindi, perché può accadere?

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 necessita del proprio controller con una certa conoscenza dello scopo del dispositivo e, in questo caso, della sua capacità. Decide anche cosa è fatto, quando riceve il comando per memorizzare qualcosa. Se il controller è programmato in questo modo, può semplicemente ignorare il comando o sovrascrivere qualcosa con i dati.

Che cosa significa? Qualunque siano i tuoi strumenti Unix ti dicono della capacità del disco: è ciò che gli strumenti hanno chiesto all'unità, niente di più. Questo è il motivo per cui h2testw è stato inventato: prova le dimensioni reali con un metodo spiegato in seguito e lo confronta con ciò che dice l'unità. Se questo non è lo stesso, si può avere una perdita di dati, perché tutte le operazioni comuni per memorizzare i dati, si basano sulle informazioni del sistema operativo, che chiede solo al controller. Perché chiedere? Il test richiede tempo e sovrascrive tutti i dati sul disco. Quindi è naturale che un sistema operativo debba fare affidamento su queste informazioni.

Per verificare la capacità reale come h2testw, puoi effettivamente usare dd per scrivere i dati sul disco, leggerlo di nuovo e vedere se è lo stesso che hai scritto. Totalmente legale. La natura dell'hardware e l'unità lo rendono più complicato. Prendi in considerazione le cache di scrittura, ad esempio. È necessario assicurarsi di non leggere dalla cache. Questo è solo un esempio del perché non è così facile come sembra. Pensa anche che scrivere solo zeri significa una bassa entropia di informazioni, che può essere ricostruita durante la lettura. Non è così facile nei dettagli. Puoi sempre farlo manualmente, naturalmente.

Ma perché, quando puoi automatizzare le cose? Perché al lavoro? f3 come proposto nella mia risposta qui sotto, implementa tonnellate di pensieri di molti contributori (si consideri che è una specie di esteso h2testw) e implementa anche diversi metodi con diversi trade-off. Lo sviluppatore ha scoperto i trucchi di diverse unità false (ovvero le unità contraffatte) che avevano a portata di mano .Quindi, mentre comprendo la teoria e il problema (apparentemente poiché i problemi sono ben spiegati nei media tecnologici tedeschi, ma non nei media di lingua inglese), non pretendo di capire tutto, ed è per questo che ho menzionato sopra. È solo la teoria che capisco e sono più un ragazzo del software. Ma come studente di informatica lo capisco abbastanza bene da vedere il problema.

  

"Cerca di capire i programmi di utilità Unix di base"

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

Aiuta a comprare solo da fornitori di fiducia?

tl; dr: Non lo è.

  

"Quando si tratta di acquistare beni, proprio come qualsiasi forma di sicurezza, considera la possibilità di trovare un venditore affidabile e acquistare unità solo da loro."

La sicurezza (e la sicurezza) NON riguarda la fiducia! Si tratta di verifica e convalida! Scusa ma è così sbagliato in così tanti modi.

Supponete di acquistare tramite un venditore affidabile. Alcune domande:

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

  2. È possibile che acquisti cose che non sa essere false? Assolutamente, guarda i recenti ryzen fakes: link , link

  3. Se perdo la mia presentazione nel drive e rovino la presentazione, il mio fornitore di fiducia tornerà indietro nel tempo e mi libererà? Probabilmente sostituirà l'unità, dal momento che l'ultima volta che viaggiava a DeLorean fu distrutta nel 1885.

Altre cose

  

"Questa domanda sembra essere più simile a" promo "per ciò che piace a OP, e sembra che l'OP sia molto meno interessato a testare realmente le unità."

Questo è ridicolo. Stavo cercando in particolare uno strumento simile a h2testw che gira anche su linux. E sì, questo è quello che mi "piacerebbe", risposta utile, così dispiaciuta. Non avevo idea che la stampa di lingua inglese non fosse a conoscenza di tali problemi e che sia stata fortunata a trovare qualcosa di simile in seguito. Questo non è un promo, ma in realtà sembra che tu possa usarne uno.

    
posta verpfeilt 21.02.2016 - 19:23
fonte

3 risposte

20

C'è una sola alternativa che ho trovato, ma penso che sia anche migliore rispetto allo strumento h2testw originale per MS Windows. Fortunatamente, è davvero facile da usare, anche da linea di comando. Ci sono GUI disponibili, però. Ci sono anche molte informazioni sull'implementazione e il problema con le false unità sul sito web degli strumenti.

F3 - "Lotta contro la frode Flash" o "Combatti il ​​flash falso"

Fonte: link
GUI QT: link
GUI OSX: link

Il metodo h2testw

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>

f3write chiederà la dimensione richiesta dai dispositivi e la riempirà con i file generati con una dimensione di 1 GB ciascuno. f3read leggerà tutti quei file e vedrà che sono completi e non rotti. Ad esempio i comandi che ho usato per testare la mia pen drive 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 disco di queste dimensioni è durato circa tre ore con questo metodo e talvolta ha causato un carico pesante sul mio computer, ma mi è stato detto che è il più preciso.

Il metodo f3probe

f3probe è un altro modo per testare le unità, non come preciso ma più veloce poiché non scrive sull'intero disco. Puoi leggere ulteriori informazioni 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 le unità false e le loro dimensioni reali.

e

  

Infine, grazie a f3probe è il software libero e una volta f3probe è   provato, F3probe potrebbe essere incorporato su smartphone, fotocamere, MP3   giocatori e altri dispositivi per fermare una volta per tutte la proliferazione   di falso flash.

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

$ 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 consente agli utenti di utilizzare la reale capacità delle unità false senza perdere i dati.

Installa in Ubuntu

Gli strumenti descritti fanno parte del pacchetto f3 , che è almeno disponibile su Ubuntu 15.10. Secondo il sito web, ci sono altri strumenti disponibili. Per farli dare un'occhiata al sito web. Per installare il pacchetto è sufficiente digitare un terminale:

sudo apt-get install f3

Il pacchetto viene fornito con pagine man brevi ma utili, anche se penso che manchino alcune informazioni del sito web sulla differenza di f3read / write e f3probe per esempio, motivo per cui questa risposta ha avuto un po 'di più.

    
risposta data verpfeilt 02.04.2016 - 22:29
fonte
3

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

C'è un binario precompilato per Debian 7 disponibile per il download , che è molto probabile che funzioni senza problemi su un sistema Ubuntu moderno.

L'ho scritto per mio uso personale perché non sono riuscito a trovare uno strumento grafico per questo scopo. Devi solo installare prima la tua chiavetta USB vuota, selezionarla e avviare il test. È uno strumento molto stupido perché tutto ciò che fa è riempire l'unità con i file e quindi verificare che i dati sul disco siano corretti. Interrompe 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 uno scostamento logico, pertanto questa informazione potrebbe essere inutile perché dipende dal file system in cui si trovano i file sul disco. Tuttavia, quando l'unità è stata riempita di dati e tutto può essere letto e verificato, dovrebbe essere sicuro assumere che la capacità riportata dell'unità è corretta. Come nota a margine, i file di test vengono automaticamente cancellati (potrebbe non funzionare se l'unità è danneggiata).

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

Il feedback è apprezzato.

    
risposta data c0xc 01.08.2016 - 12:57
fonte
-5

Indirizzamento del comportamento dell'OP e "azionamento falso"

Sto modificando la risposta per affrontare correttamente alcuni punti, dal momento che OP è stato molto veemente (e secondo me, opponendosi alla maggior parte dei commenti e delle risposte tranne il proprio, che trovo sospetto). In particolare, c'è molto da dire che esiste "guida finta", ma non esiste una definizione chiara di cosa sulla terra significhi realmente. OP dichiarato:

  

Potrei semplicemente copiare qualcosa su di esso, copiarlo e controllare se i file sono a posto. Potrei anche automatizzarlo con Hash e roba. Ma speravo che ci fosse una soluzione più accurata.

Gli stessi OP hanno ammesso che "potevano semplicemente copiare cose" e verificare l'integrità dei dati, ma erano molto contrari a tutti gli altri commenti e risposte che proponevano qualsiasi altra cosa e OP continuava a spingere F3 come "vero affare". La domanda in sé è iniziata per la dimensione del disco, ma poi OP per qualsiasi motivo ha menzionato hash per "vedere se i file sono ok", come se ci fossero unità misteriose che richiedono una dimensione e ti permettono di scrivere quella dimensione, ma quindi i dati sono corrotti. Pertanto, lo trovo altamente sospetto e prenderemo in considerazione OP che promuove F3 come domanda e risposta spam.

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

Nella domanda, la definizione apparente dell'OP è

  

".. unità che pretendono di avere molto spazio (spesso trasportate troppo lontano, come 128 GB), mentre offrono fisicamente solo da 0,5 a 4 GB."

In altre parole, secondo OP, la quantità di dati del controllore X, ma USB può solo contenere qualcosa come 80-90% in meno di quanto richiesto.

L'utente sudodus proposto nel commenti (enfasi aggiunta):" Ho trovato che diverse chiavette USB sono leggermente più piccole delle dimensioni nominali. chiamali sottodimensionati . Penso che le unità false siano "sostanzialmente sottodimensionate" (in genere metà della dimensione nominale o inferiore ) ". Questa definizione è ottima, tuttavia se lo prendiamo, l'unità fasulla è definita al 50%. Un'unità che richiede 64 GB ma può contenere solo 32 GB, tecnicamente perde metà del suo valore per il proprietario e il proprietario può solo mettere la metà di ciò che intendeva sull'unità.

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

Il ± 15 % è molto ragionevole. Si consideri inoltre che gli utenti sono generalmente confusi tra le organizzazioni Unix, IEEE e IEC che utilizzano il prefisso binario invece della potenza del prefisso 10 per la dimensione di memorizzazione dei dati. La differenza arriva al 20% al livello prefisso yotta, tuttavia le unità USB non sono ancora disponibili, quindi forse per i prossimi 20 anni il 15% è ragionevole. (Vedi domanda su askubuntu "Significato di" i "in" MiB "" e Prefisso binario )

Test del disco

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 conformi a POSIX. Sottolineiamo e riformuliamo nuovamente la definizione:

  

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

Il modo semplice per farlo è con dd , basta sovrascrivere il dispositivo con zero (e ovviamente ricorda di salvare i tuoi file prima di farlo).

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

Notare bs=1 per la dimensione del blocco di 1 byte. Il comando dd di solito fornisce un rapporto su quanto è stato 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

Abbiamo chiesto di scrivere 1024 byte, ha scritto 1024 byte.

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

  • Calcola la quantità di dati dichiarati dall'unità (supponendo che tu sospetti che df sia "errato"). In questo esempio, supponiamo che /dev/sdb1 sia il mio file di dispositivo per l'unità USB:

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

    Notare che -P flag è per la portabilità POSIX, il che significa che la dimensione del blocco dei dati sarà 1024 byte e ciò significa che ci sono 115247656 * 1024 byte su quella unità.

  • Scopri quale è il 15% di tolleranza al di sotto di ciò che afferma l'unità (115247656), forse usa l'utilità che supporta il calcolo in virgola mobile come awk :

     $ awk 'BEGIN{printf "%d\n",115247656*(1-0.15)}'
     97960507
    
  • Crea dati casuali sul disco rigido con le 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 md5sum o sha1sum di ./mytestfile.random e confrontare ora con /dev/sda1 .Migliorare ancora meglio sarebbe scrivere il mytestfile.random sul mountpoint del file, mantenendo così il filesystem sull'unità e il partizionamento inalterato del drive, in altre parole

    dd if=./mytestfile.random of=/mountpoint/for/usb/drive/testfile.random
    
  • Quindi, per integrità, puoi eseguire qualsiasi controllo di hashsum, come md5sum , sha1sum , sha256sum o altri. Ad esempio

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

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

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

Conclusione

Questa domanda sembra essere più simile a "promo" per ciò che piace a OP, e sembra che l'OP sia molto meno interessato a testare realmente le unità. Inoltre, il problema in sé è più umano di un problema di "guida". Nei commenti, gli OP stessi hanno dichiarato di non capire veramente il comportamento USB, ma sono veemente colpevoli di "il controller". Lascerò questa domanda con 3 punti:

  • Scopri chiaramente qual è il problema che stai cercando di risolvere e qual è la definizione di "Fake Drive".
  • Cerca di capire le utilità di base di Unix
  • Quando si tratta di acquistare beni, proprio come qualsiasi forma di sicurezza, considera la possibilità di trovare un venditore affidabile e acquistare unità solo da loro.
risposta data Sergiy Kolodyazhnyy 26.02.2016 - 19:44
fonte

Leggi altre domande sui tag