He oído hablar de herramientas que podrían usarse para graficar la entropía de un archivo. ¿Hay algún programa gráfico de Linux que pueda usar para este trabajo que me permita explorar convenientemente qué bloques de un archivo tienen ciertos patrones de entropía que podrían sugerir datos comprimidos o cifrados?
No existe tal cosa como la "entropía" de un archivo. La entropía es una característica de un proceso , por ejemplo, de un proceso que genera un archivo. La entropía no describe cuáles son los contenidos del archivo; describe lo que podría haber sido el contenido del archivo . Como tal, cualquier herramienta que pretenda identificar "patrones de entropía" está, en el mejor de los casos, perdiendo una terminología extremadamente pobre.
Dicho esto, todavía se pueden hacer algunas heurísticas. Sucede que la mayoría de los "datos de la vida real" exhiben mucha redundancia en su estructura; esto es de lo que se trata la compresión de datos . Por lo tanto, puede trabajar en el siguiente supuesto: los datos que pueden comprimirse por una cantidad no trivial son datos no que ya se han comprimido o cifrado. De hecho:
Los algoritmos de compresión se esfuerzan por identificar y eliminar redundancias. El resultado no debe ser susceptible a una mayor compresión; de lo contrario, esto significa que el algoritmo de compresión hace un mal trabajo.
Se supone que los datos cifrados son indistinguibles de la aleatoriedad (si el algoritmo de cifrado es bueno); por lo tanto, tiene una probabilidad extremadamente baja de ser compresible.
Para que pueda extraer fragmentos de su archivo y comprimirlos (por ejemplo, con gzip ), para ver si se pueden reducir sustancialmente. Por ejemplo, este comando extrae un fragmento de 2000 bytes del archivo data.bin (en el desplazamiento 15000), lo comprime e informa la longitud resultante:
dd if=data.bin bs=1 skip=15000 count=2000 2>/dev/null | gzip | wc -c
Si el valor resultante es sustancialmente menor que 2000, entonces el fragmento, probablemente, contiene datos que no están encriptados ni comprimidos. Por ejemplo, si uso como archivo de datos el archivo /usr/bin/gcc-4.8 (un ejecutable lleno de código, pero no comprimido) de mi computadora portátil Linux, obtengo una longitud de salida de 1491 bytes para esa porción, que es bastante más pequeña que 2000. Si me pruebo con /dev/urandom , obtengo 2023 bytes.
(Estas figuras se imprimen en mi pantalla como secuencias de caracteres, que proceso con mis ojos y mi cerebro. Esto, en mi opinión, califica como "gráfico".)
Ejecutar el comando en un bucle que extrae varios fragmentos de archivo y los comprime a todos se deja como un ejercicio para el lector (no es difícil, y si no puede hacerlo, entonces es probable que no pueda hacerlo). haga mucho con los archivos de todos modos; el procesamiento práctico de datos requiere algunas habilidades de programación).
Advertencia: gzip , como la mayoría de los compresores de propósito general, funciona por byte, y trata de encontrar patrones repetidos y sesgos en el uso de valores de bytes. Se sabe que esto funciona mal en datos analógicos que se han digitalizado, por ejemplo. muestras de audio La relación de compresión ofrecida por gzip en los archivos WAV es a menudo pobre, mientras que el archivo WAV todavía está "no comprimido" ( esta página afirma haber medido una longitud comprimida de aproximadamente el 92% del original, aunque dependerá de las características del archivo WAV).
Entonces, no imagine que la prueba "comprimir por gzip" es el método de detección definitivo para datos comprimidos / encriptados. Sin embargo, eso puede dar buenos resultados, siempre que los fragmentos comprimidos / encriptados que intenta localizar sean lo suficientemente largos (de esa manera no encontrará los fragmentos de 50 bytes).
Lea otras preguntas en las etiquetas encryption linux