2008-09-08 8 views
20

Por lo tanto, para simplificar mi vida, deseo poder añadir de 1 a 7 caracteres adicionales al final de algunas imágenes jpg que mi programa está procesando *. Estos son rellenos ficticios (rellenos, etc., probablemente todos 0x00) solo para que el tamaño del archivo sea un múltiplo de 8 bytes para el cifrado de bloques.¿Los datos aleatorios anexados a un JPG lo harán inutilizable?

Después de haber probado esto con algunos programas, parece que están bien con los caracteres adicionales, que aparecen después del FF D9 that specifies the end of the image, por lo que parece que el formato de archivo está lo suficientemente definido como para 'la corrupción'. el final no debería importar

Siempre puedo publicar el proceso de los archivos más tarde si es necesario, pero mi preferencia es hacer lo más simple posible, que es dejarlos permanecer (estoy descifrando otros tipos de archivos y no les importará, así que tener un caso especial es molesto).

Calculo con toda la charla de hace años Steganography hullaballo, alguien tiene alguna entrada aquí ...

(procesamiento de cifrado por bloques de 8 bytes, no desea guardar el tamaño del archivo cifrado previamente, por lo anexar 0x00 a los datos de entrada, y dejarlos allí después de la decodificación)

Respuesta

20

No, puede añadir bits a la final de un archivo JPG, sin hacer inutilizable. El encabezado del archivo jpg le dice cómo leerlo, por lo que el programa que lo lea se detendrá al final de los datos de jpg.

De hecho, las personas han ocultado archivos zip dentro de archivos jpg anexando los datos postales para el final de los datos jpg. Debido a la forma en que se estructuran estos formatos, el archivo resultante es válido en cualquier formato.

+0

inutilizable (que era la pregunta) no es lo mismo que reducir su usabilidad. Un poco de nickpick, lo concederé. Pero, una distinción importante porque puede ser una solución viable. –

+0

Ok, no estoy seguro de que decir "sin reducir su usabilidad" podría significar "hacerlo inutilizable", pero lo editaré solo para hacerlo más claro. – pkaeding

+0

Heh heh heh. Nosotros los programadores podemos dividir un cabello tan finamente ... –

7

Puede ... pero los resultados pueden ser impredecibles.

A pesar de que hay suficiente información en el formato de decirle al cliente para ignorar los datos adicionales que es probable que no es un caso probado para el programador.

Un programa paranoide podría mirar el tamaño, cuenta de la discrepancia y decidir que no procesará el archivo porque está claro que no entiende completamente. Esto es particularmente probable cuando se leen datos de la web cuando los bytes aleatorios en un archivo se pueden considerar un riesgo de seguridad.

3

Puede incrustar sus datos en la etiqueta XMP dentro de un campo JPEG (o EXIF ​​o IPTC para el caso). XMP es XML, por lo que tiene un poco de flexibilidad para hacer sus cosas personalizadas.

Probablemente no es lo más simple posible pero al poner aquí sus datos mantendrá la integridad del JPEG y no requerirá "procesamiento posterior".

Sus datos se mostrarán en otro software de imágenes como PhotoShop, que puede no ser ideal.

1

Como otros han dicho, no tiene ningún control sobre cómo los archivos de imagen programas de proceso y, por tanto, algunos programas pueden encontrar las imágenes que otros no válidos de mayo.

Sin embargo, hay un problema más grande aquí. A juzgar por su pregunta, deduzco que está practicando "seguridad a través de la oscuridad". En general se considera una práctica muy mala. Use Google para encontrar una gran cantidad de artículos sobre el tema.

+3

¿Qué indica esto? Estoy usando el algoritmo TEA para encriptar los datos, pero encripta 8 bytes a la vez. En lugar de incluir metadatos dentro del archivo cifrado para decirme qué tan grande era la información original, estoy rellenando el original con un límite de 8 bytes y dejando el relleno en su lugar. –