¿Cómo corromper un archivo de forma controlada?

Escribí una función que busca un archivo dañado usando una suma de verificación CRC.

Para probarlo, acabo de abrir el archivo y codifiqué el contenido con un editor hexadecimal. El problema es que no creo que esta sea la forma correcta de generar un archivo dañado.

¿Hay alguna otra forma de crear una "corrupción controlada", por lo que no será totalmente aleatoria, pero puede simular lo que sucede con archivos corruptos reales? Nunca tuve que corromper algo a propósito, así que no estoy realmente seguro de cómo hacerlo, además de la aleatorización aleatoria de datos en un archivo.

Tampoco he hecho muchas pruebas de fuzz , pero aquí hay dos ideas:

Escribe algunos ceros en el medio del archivo. Usar ddcon conv=notrunc. Esto escribe un solo byte (tamaño de bloque = 1 cuenta = 1):

dd if=/dev/zero of=file_to_fuzz.zip bs=1 count=1 seek=N conv=notrunc

Usar /dev/urandomcomo fuente también es una opción.

Alternativamente, perfore múltiples agujeros de 4k con fallocate --punch-hole. Incluso podría fallocate --collapse-rangecortar una página sin dejar un agujero lleno de cero. (Esto cambiará el tamaño del archivo).

Una descarga reanudada en el lugar incorrecto coincidiría con el --collapse-rangeescenario. Un torrente incompleto coincidirá con el punch-holeescenario. (Archivo disperso o extensiones preasignadas, ya sea como cero en cualquier lugar que aún no se haya escrito).

La RAM defectuosa (en el sistema desde el que descargó el archivo) puede causar daños, y las unidades ópticas también pueden dañar los archivos (su ECC no siempre es lo suficientemente fuerte como para recuperarse perfectamente de arañazos o decoloración del tinte).

Los sectores de DVD (bloques ECC) son 2048B , pero pueden ocurrir errores de un solo byte o incluso de un solo bit. Algunas unidades probablemente le darán los datos incorrectos corregibles en lugar de un error de lectura para el sector, especialmente si lee en modo sin formato, o w / e se llama.

Las otras respuestas parecen estar relacionadas principalmente con errores de hardware. Permítanme enumerar algunas corrupciones causadas por software:

• LF reemplazado por CRLF.
• CR eliminado. (Incluso si no es seguido por LF)
• Bytes nulos adicionales insertados.
• Se insertó una "Marca de orden de bytes" extra Unicode.
• Juego de caracteres convertido de UTF-8 a Latin-1 o viceversa.
• Se elimina el carácter EOF de DOS (# 1A), incluso cuando no está al final del archivo.

Estas cosas son bastante inofensivas cuando les sucede a los archivos de texto, pero generalmente son mortales cuando se aplican a archivos binarios.

Úselo ddpara truncar el archivo, o pruebe con un editor binario como hexereditar e introducir algunas corrupciones.

Ejemplo de truncar archivo usando dd

Crear archivo de 5 MB

# dd if=/dev/zero of=foo bs=1M count=5
5+0 records in
5+0 records out
5242880 bytes (5.2 MB) copied, 0.0243189 s, 216 MB/s
# ls -l foo
-rw-r--r-- 1 root root 5242880 Aug 12 20:13 foo
#

Truncar 10 bytes del final

# dd if=foo of=foo-corrupted bs=1 count=5242870
5242870+0 records in
5242870+0 records out
5242870 bytes (5.2 MB) copied, 23.7826 s, 220 kB/s
# ls -l foo foo-corrupted
-rw-r--r-- 1 root root 5242880 Aug 12 20:13 foo
-rw-r--r-- 1 root root 5242870 Aug 12 20:14 foo-corrupted
#

Página del manual de Hexer

HEXER(1)                              General Commands Manual                             HEXER(1)

NAME
   hexer - binary file editor

SYNOPSIS
   hexer [options] [file [...]]

DESCRIPTION
   hexer  is  a  multi-buffer  editor  for  viewing  and  manipulating binary files.  It can't
   (shouldn't) be used for editing block devices, because it tries to load the whole file into
   a  buffer (it should work for diskettes).  The most important features of hexer are:  multi
   buffers, multi level undo, command line editing with completion, binary regular expressions
   (see  below).   The  user  interface  is  kept similar to vi, so if you know how to use vi,
   you'll get started easily.

Sugerencia:

Comience a escribir en un archivo y deje de escribir antes de que termine. Esto puede ocurrir durante cortes de energía y otros escenarios.

Escenario de la vida real:

Una vez corrompí un archivo zip al tratar de copiar más datos de los que cabría en el medio. Windows (esto era Windows 7 en modo seguro ftr) intentó completar la acción antes de determinar si había suficiente espacio, y para cuando lo descubrió, el archivo estaba medio completo y, por lo tanto, corrupto. Espero que hayan solucionado ese problema en versiones posteriores de Windows o que solo haya sido un modo seguro.

Otro tipo común de corrupción es el bit-twiddling: donde un solo bit (o varios bits) se alternan en un flujo de datos.

Así que un byte 1111 0000podría llegar a ser, por ejemplo, 1111 0010o 1011 0000, o 1110 1100, o lo que sea.

Los sistemas de suma de verificación de paridad y conteo de unidades tienen problemas con cosas como 1110 1000donde hay un número igual de conjuntos y desarmados, ya que tanto la paridad como el número de unidades permanecen iguales.

Por lo tanto, reemplazar todas las instancias de un carácter aleatorio con su inverso, digamos 0x57 a 0x75 ('9' a 'K') o viceversa, podría no ser detectable. Para los sistemas que tienen mysql, el comando "reemplazar" existe para tal propósito:

replace K 9 < goodInputFile > corruptedOutputFile

También puede intentar intercambiar las letras K y 9, lo que será una prueba particularmente buena si ambas aparecen la misma cantidad de veces en el archivo:

replace K 9 9 K < goodInputFile > corruptedOutputFile

Úselo man replacepara más información.

Los cambios aleatorios en los datos de prueba corruptos no son un buen enfoque, ya que no puede reproducir la muestra para volver a ejecutar las pruebas.

Estaría contento con solo 3 muestras, cambiando solo 1 bit en el primer byte, en el último byte y en cualquier byte medio. Pero solo 1 bit, no todo el byte.

Pero la mejor muestra de prueba sería aquella en la que podría generar muestras cambiando cada bit del archivo del primero al último byte. Esto no se puede obtener (generalmente) con las herramientas habituales, necesita construir una (supongo).

Con este enfoque, aísla muchas posibilidades, incluida la endianess si su algoritmo se basa en un tipo de endianess. En otras manos, una muestra grande puede consumir mucho tiempo para procesar.

Por fin, algunas muestras truncando o agregando bytes completarán sus pruebas.