Recientemente leí mucho sobre la tarjeta MicroSD falsa y las unidades de memoria USB que afirman tener mucho espacio (incluso si le preguntas a tu computadora), mientras que físicamente ofrecen mucho menos. Recientemente compré una unidad USB SanDisk (128 GB reclamados) y quiero probar su tamaño. No se compra a través de eBay o algo así, pero realmente quiero probar el tamaño real antes de usarlo productivamente.
Podría simplemente copiar cosas en él, copiarlo de nuevo y ver si los archivos están bien. También podría automatizarlo con Hashes y otras cosas. Pero esperaba que hubiera una solución más precisa. Leí que para Windows, H2testw hace el truco. ¿Hay una manera fácil de probar esto en Ubuntu / Linux? ¿Tal vez una herramienta especializada y que funcione bien?
Actualización: para ser claros, la idea es verificar que el tamaño que el controlador le dice al sistema Linux sea correcto ( para que no se pierdan datos ). No es que quiera ver si obtengo 128 GB en lugar de 127.3 GB. Quiero probar si todos los datos que escribo serán legibles nuevamente. Desafortunadamente, solo puedo encontrar información sobre esto en sitios de tecnología en inglés. Sin embargo, hay buenas fuentes alemanas. En realidad estoy buscando una aplicación como esas, pero para Ubuntu / Linux: https://www.raymond.cc/blog/test-and-detect-fake-or-counterfeit-usb-flash-drives-bought-from -ebay-with-h2testw /
Actualización2: Traté de reunir algunas fuentes en inglés. No los leí todos en detalle, debido al tiempo perdido.
- 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/
Actualización3: Explicaciones
Debido a las extrañas críticas a continuación, algunas explicaciones.
¿Cuál es el problema y por qué dd solo no lo resuelve?
Esta es una reacción a
"Determine claramente cuál es el problema que está tratando de resolver y cuál es la definición de" disco falso "".
Parece que algunas personas no entienden el problema. Así que trato de explicarlo lo más brevemente posible en detalles, aunque creo que esto es muy extenso para mi pregunta.
La capacidad de los dispositivos usb que le proporcionan su sistema operativo o las herramientas de Unix puede ser incorrecta. Esto es fatal, ya que su sistema operativo regula la cantidad de datos a los que puede enviarlos. Envíe más datos de los que realmente puede contener, obtendrá una pérdida de datos. Esto es un problema. Entonces, ¿por qué puede suceder esto?
No necesita conocer bien el protocolo USB para comprender el problema. Las interfaces seriales tienen la propiedad común de que el dispositivo cliente (la unidad usb) necesitará indicar su propia capacidad a través de esta interfaz serial. Esto significa que el dispositivo cliente necesita su propio controlador con algún conocimiento sobre el propósito del dispositivo y, en este caso, su capacidad. También decide qué se hace, cuando recibe el comando para almacenar algo. Si el controlador está programado de esa manera, puede ignorar el comando o sobrescribir algo con los datos.
¿Qué significa esto? Lo que le digan sus herramientas Unix sobre la capacidad de la unidad: es lo que las herramientas le pidieron a la unidad, nada más. Para esto se inventó h2testw: prueba el tamaño real con un método explicado más adelante y lo compara con lo que dice la unidad. Si esto no es lo mismo, es posible que tenga una pérdida de datos, porque todas sus operaciones comunes para almacenar datos dependen de la información de su sistema operativo, que solo le pregunta al controlador. ¿Por qué solo preguntar? La prueba necesita tiempo y sobrescribe todos los datos en el disco. Por lo tanto, es natural que un sistema operativo necesite confiar en esta información.
Para verificar la capacidad real como h2testw, puede usar dd
para escribir datos en el disco, leerlo nuevamente y ver si es lo mismo que escribió. Totalmente legítimo La naturaleza del hardware y la unidad lo hacen más complicado. Considere escribir cachés por ejemplo. Debe asegurarse de no leer del caché. Este es solo un ejemplo de por qué no es tan fácil como parece. También piense que solo escribir ceros significa una baja entropía de información, que se puede reconstruir al leer. Simplemente no es tan fácil en detalle. Todavía puedes hacerlo manualmente, por supuesto.
¿Pero por qué, cuando puedes automatizar las cosas? ¿Por qué al trabajo? f3, como se propone en mi respuesta a continuación, implementa toneladas de pensamientos de muchos contribuyentes (considere que es una especie de h2testw extendido) y también implementa varios métodos con diferentes compensaciones. El desarrollador descubrió los trucos de diferentes unidades falsas (también conocidas como unidades falsificadas) que tenían a mano . Entonces, aunque entiendo la teoría y el problema (aparentemente porque los problemas están bien explicados en los medios tecnológicos alemanes, pero no en los medios de habla inglesa), no pretendo entender todo, por eso lo mencioné anteriormente. Es solo la teoría que entiendo, y soy más un tipo de software. Pero como estudiante de informática lo entiendo lo suficientemente bien como para ver el problema.
"Intenta comprender las utilidades básicas de Unix"
En realidad, ya respondí esto, pero para dejarlo claro: las herramientas de Unix solo usan el Protocolo USB (solo para dispositivos USB, por supuesto) para recopilar información. No tiene sentido hacer más que eso.
¿Ayuda comprar solo a proveedores de confianza?
TL; DR: no lo hace.
"Cuando se trata de comprar bienes, al igual que con cualquier forma de seguridad, considere encontrar un vendedor confiable y compre unidades solo de ellos".
¡La seguridad (y la seguridad) NO se trata de confiar! ¡Se trata de verificación y validación! Lo siento, pero esto está muy mal en muchos sentidos.
Suponga que compra a través de un vendedor de confianza. Unas cuantas preguntas:
¿El proveedor probó el hardware para asegurarse de que no haya pérdida de datos? ¿Reconoce cuándo compra discos falsos y los vende? No necesariamente.
¿Es posible que compre cosas que no sabe que son falsas? Totalmente, mire las recientes falsificaciones de ryzen: 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
Si pierdo mi presentación en el disco y la arruino, ¿mi proveedor de confianza retrocederá en el tiempo y me rescatará? Probablemente reemplazará el disco, ya que el último viaje en el tiempo DeLorean fue destruido en 1885.
Otras cosas
"Esta pregunta realmente parece ser más como" promoción "para lo que le gusta a OP, y parece que OP está mucho menos interesado en probar las unidades".
Esto es ridículo. Estaba buscando específicamente una herramienta similar a h2testw que también se ejecute en Linux. Y sí, eso es lo que me gustaría, respuesta útil, lo siento mucho. No tenía idea de que la prensa de habla inglesa no es tan consciente de tales problemas y tuve la suerte de encontrar algo así más adelante. Esto no es una promoción, pero en realidad parece que podrías usar una.
df --block-size=M
. El límite de 4 GB sugeriría que es solo el límite de tamaño de archivo FAT32, no la capacidad de la unidad. Nunca obtendrá la capacidad total indicada, es un promedio solo para clasificarlo.Respuestas:
f3 - Lucha contra el fraude flash
Solo encontré una alternativa, pero creo que esta es incluso mejor que la
h2testw
herramienta original para MS Windows. Afortunadamente, es realmente fácil de usar, incluso desde la línea de comandos. Sin embargo, hay GUI disponibles. También hay mucha información sobre la implementación y el problema con las unidades falsas en el sitio web de herramientas.f3 ofrece dos métodos:
El método f3probe (recomendado)
f3probe
es una forma de probar las unidades, no tan precisa pero más rápida ya que no escribe en toda la unidad. Puede leer más al respecto en el sitio web de herramientas. Si quieres estar 100% seguro, mejor usa el método h2testw. Como el desarrollador describe en el sitio web:Y:
También hay un ejemplo de uso en el sitio web:
Tenga en cuenta que también devuelve un comando que le permite usar la unidad con su tamaño real
f3fix
.La herramienta f3fix
El método h2testw / Prueba de rendimiento con f3read / f3write
F3 es una colección de herramientas que se ocupan de unidades flash falsas. Dos de ellos implementan juntos el
h2testw
Método:f3write
pedirá el tamaño reclamado de los dispositivos y lo llenará con archivos generados con un tamaño de 1 gb cada uno.f3read
leerá todos esos archivos y verá que están completos y no rotos. Como ejemplo, los comandos que utilicé para probar mi unidad flash de ~ 128 gb:Ahora para probar si los archivos están almacenados correctamente:
La prueba para una unidad de este tamaño tomó alrededor de tres horas con este método y, a veces, causó una gran carga de disco en mi computadora, pero se me dice que es la más precisa.
Instalar en Ubuntu
En terminal:
Esto le llevará:
f3brew
,f3fix
,f3probe
,f3read
,f3write
con sus páginas man.Estas herramientas son parte del
f3
paquete, que al menos está disponible en Ubuntu 15.10. Según el sitio web, hay algunas herramientas más que están disponibles. Para obtenerlos, eche un vistazo al sitio web.El paquete viene con páginas de manual cortas pero útiles, aunque creo que pierden información del sitio web sobre la diferencia de f3read / write y f3probe por ejemplo, por lo que esta respuesta se hizo un poco más larga.
fuente
apt-get
se instalaráf3read
yfwrite
solo comof3probe
yf3fix
se consideran experimentales. Si desea usarlos, tendrá que construirlos desde la fuente usandomake experimental
después de instalar sus dependenciassudo apt-get install libudev1 libudev-dev libparted0-dev
. Ver github.com/AltraMayor/f3#the-extra-applications-for-linuxHe escrito una herramienta simple para eso, se llama CapacityTester (captura de pantalla) y tiene una GUI y una CLI.
Hay un binario precompilado para Debian 7 disponible para descargar , que es muy probable que funcione de inmediato en un sistema Ubuntu moderno.
Lo escribí para mi uso personal porque no pude encontrar una herramienta gráfica para este propósito. Solo necesita montar su unidad flash USB vacía primero, seleccionarla e iniciar la prueba. Es una herramienta muy tonta porque todo lo que hace es llenar el disco con archivos y luego verificar que los datos en el disco sean correctos. Anulará la prueba en el primer error (escribir o leer / verificar). Informará el desplazamiento del fragmento que no se pudo escribir o verificar con éxito, pero este es un desplazamiento lógico, por lo que esta información puede ser inútil porque depende del sistema de archivos donde se encuentran los archivos en la unidad. Sin embargo, cuando la unidad se ha llenado de datos y todo se puede leer y verificar, debe ser seguro asumir que la capacidad informada de la unidad es correcta. Como nota al margen,
De nuevo, es muy simple, ya que solo funciona con archivos en la parte superior de un sistema de archivos existente. Por lo tanto, hay algunos KB (búfer de + 1M) que no se pueden probar. Y es muy lento porque realmente llena todo el sistema de archivos. F3 es ciertamente mucho más sofisticado y también más rápido, pero no tiene GUI. La única razón por la que existe CapacityTester es porque tiene una GUI para que pueda ser utilizada por usuarios que no están familiarizados con la línea de comandos o que simplemente prefieren una GUI.
Los comentarios son apreciados.
fuente
Abordar el comportamiento de OP y el "disco falso"
Estoy editando la respuesta para abordar adecuadamente algunos puntos, ya que OP ha sido muy vehemente (y en mi opinión, me opongo a la mayoría de los comentarios y respuestas, excepto a los suyos, lo que me parece sospechoso). Particularmente, hay muchas afirmaciones de que existe un "disco falso", pero no hay una definición clara de lo que en realidad significa. OP declaró:
OP admitieron que "simplemente podían copiar cosas" y verificar la integridad de los datos, pero estaban muy en contra de todos los demás comentarios y respuestas que proponían algo más, y OP solo siguió presionando a F3 como el "verdadero negocio". La pregunta en sí comenzó al principio sobre el tamaño de la unidad, pero luego OP por cualquier razón mencionó hashes para "ver si los archivos están bien", como si hubiera unidades misteriosas que reclaman un tamaño y le permiten escribir ese tamaño, pero entonces los datos están corruptos. Por lo tanto, me parece muy sospechoso y consideraría OP promoviendo F3 como preguntas y respuestas de spam.
Cuando una unidad es realmente una unidad falsa
En la pregunta, la definición aparente de OP es
En otras palabras, según OP, el controlador reclama X cantidad de datos, pero USB solo puede contener algo como 80-90% menos de lo que se reclama.
El usuario sudodus propuso en los comentarios (énfasis agregado): "He encontrado que varios pendrives USB son ligeramente más pequeños que el tamaño nominal. Los llamo de tamaño insuficiente . Creo que las unidades falsas son 'sustancialmente más pequeñas' (generalmente la mitad del tamaño nominal) o menos ) ". Esta definición es excelente, sin embargo, si tomamos eso, el disco falso se define al 50%. Una unidad que reclama 64 GB pero solo puede contener 32 GB, técnicamente pierde la mitad de su valor para el propietario y el propietario solo puede poner la mitad de lo que pretendía en la unidad.
Propongo una definición más simple: el dispositivo de almacenamiento falsificado es el que dice tener
Claimed Size
pero está por debajo del 15% de tolerancia (y la tolerancia esClaimed Size ± 15 %
).El
± 15 %
es muy razonable. Tenga en cuenta también que los usuarios suelen estar confundidos entre las organizaciones Unix, IEEE e IEC que usan el prefijo binario en lugar de la potencia de 10 prefijos para el tamaño de almacenamiento de datos. La diferencia llega al 20% en el nivel de prefijo yotta, sin embargo, las unidades USB aún no están allí, por lo que para los próximos 20 años el 15 por ciento es razonable. (Ver pregunta de askubuntu "Significado de 'i' en 'MiB'" y Prefijo Binario )Prueba de la unidad
Efectivamente, el usuario no necesita ninguna herramienta especial, aparte de lo que ya viene con Ubuntu y la mayoría de los sistemas Unix compatibles con POSIX. Enfaticemos y reformulemos la definición nuevamente:
La forma más sencilla de hacerlo es con
dd
, simplemente sobrescribir el dispositivo con ceros (y, por supuesto, recuerde guardar sus archivos antes de hacerlo).Tenga en cuenta el
bs=1
tamaño del bloque de 1 byte. Eldd
comando generalmente proporciona un informe de cuánto se escribe.Le pedimos que escribiera 1024 bytes, escribió 1024 bytes.
La lista más precisa de los pasos que se adhieren a la definición sería:
Calcule cuántos datos reclama la unidad (suponiendo que sospeche
df
que está "equivocada"). En este ejemplo, supongamos que/dev/sdb1
es el archivo de mi dispositivo para unidad USB:Tenga en cuenta que el
-P
indicador es para la portabilidad POSIX, lo que significa que el tamaño del bloque de datos será de 1024 bytes, y eso significa que hay 115247656 * 1024 bytes en esa unidad.Averigüe cuál es la tolerancia del 15% por debajo de lo que afirma la unidad (115247656), tal vez use una utilidad que admita el cálculo de coma flotante como
awk
:Cree datos aleatorios en el disco duro del mismo tamaño que la unidad en el paso anterior para usar como punto de referencia:
dd if=/dev/urandom of=./mytestfile.random bs=1024 count=97960507
Ahora escribe datos
dd if=./mytestfile.random of=/dev/sda1
. Si el disco puede aguantar tanto, es "real". También puede tomarmd5sum
osha1sum
de./mytestfile.random
y comparar con/dev/sda1
ahora. Una mejora aún mejor sería escribir el puntomytestfile.random
de montaje del archivo, manteniendo así el sistema de archivos en la unidad y sin alterar la partición de la unidad, en otras palabras.Para la integridad continuación, puede simplemente hacer ninguna verificación hashsum, tales como
md5sum
,sha1sum
,sha256sum
u otros. Por ejemploEl punto clave aquí es que si la cantidad de datos escritos está dentro de la tolerancia y produce una suma de verificación correcta antes y después de la escritura, la unidad probablemente esté bien.
Todo esto se puede poner en un buen guión por conveniencia, si así lo desea.
Conclusión
Esta pregunta realmente parece ser más como "promoción" para lo que le gusta a OP, y parece que OP está mucho menos interesado en probar las unidades. Además, el problema en sí es más humano que el problema de "unidad". En los comentarios, OP ellos mismos declararon que realmente no entienden el comportamiento de USB, pero son vehementemente culpables de "el controlador". Dejaré esta pregunta con 3 puntos:
fuente
dd
informa la cantidad de datos que ha escrito / dado al dispositivo, no veo cómo se puede falsificar.dd
y luego verificar el md5sum debería verificar cuánto se podría escribir y leer correctamente. (Creo que las herramientas especiales en la respuesta de @ verpfeilt parecen más atractivas, pero no las he probado. Tengo muchos pendrives USB y tarjetas de memoria, no creo que haya comprado una falsa todavía.)