Cómo escribir un programa en lenguaje C que descifre violentamente el código de descompresión de archivos comprimidos

Debido a que hay un archivo Rar importante que debe desbloquearse, primero probé ARPC, pero la velocidad de descompresión era extremadamente lenta, solo unas 30 veces por segundo, así que se me ocurrió la idea de descomprimirlo exhaustivamente, pero Todavía no me di por vencido porque nunca defiendo la pobreza. En cuanto al método de descifrado, a menos que puedas ejecutarlo decenas de millones de veces por segundo, podría intentarlo, así que decidí estudiar el algoritmo de cifrado de Winrar 3. .x para ver si es posible descifrar la contraseña. Revisé la información en Internet, incluidas las respuestas en las preguntas frecuentes, y todos afirmaron que solo se puede descifrar mediante el método exhaustivo. Al principio no lo entendí, pero a través de la investigación, entendí la razón por la cual las personas mayores. En las preguntas frecuentes decía esto, y no pude evitar admirar a Winrar.

Winrar La madurez de las ideas detrás del cifrado. Aunque los resultados de la investigación no son nada nuevo, decidí compartir los resultados de mi investigación con todos, para aquellos que todavía piensan que la contraseña de Winrar puede ser como descifrar el código de registro modificando el cuadro emergente de Winrar y otros métodos, cambiando el proceso del archivo. dirección, puede omitir la contraseña. Verifique amigos y haga una explicación simple.

1. El proceso de generación de archivos Rar.

Winrar cifra archivos en dos pasos:

1: Primero comprime el archivo fuente en segmentos de datos.

2: Luego cifra el segmento de datos comprimidos.

Para el mismo archivo fuente, sin cifrado, los segmentos de datos en el archivo rar después de la compresión son exactamente los mismos. Pero si es el mismo archivo fuente, incluso si se usa la misma contraseña, los segmentos de datos en el archivo rar cifrado son diferentes. Esto se debe a que la clave de cifrado se basa en Salt (clave de 8 bytes, utilizada para el cifrado). encabezado almacenado en el archivo rar)

Entonces, la clave para descifrar el archivo rar cifrado es descifrar los datos en este paso, así que estudiemos cómo cifrarlo a continuación.

El proceso de cifrar el "segmento de datos comprimidos"

1. Obtenga la clave:

Junte la contraseña de texto sin formato y Salt y utilice el algoritmo HASH. para generar dos claves A de 16 bytes. (Uno es KEY (un parámetro del algoritmo AES) y el otro es initVector)

2 Utilice Key e initVector para cifrar los datos comprimidos:

Aquí hay un cifrado cíclico. estructura, cada 16 bytes se cifra como un bloque (probablemente esta sea la razón por la que la longitud del archivo cifrado es siempre múltiplo de 16). El cifrado utiliza el algoritmo AES (RAR utiliza la aplicación estándar rijndael de AES). Tenga en cuenta aquí: cuando se cifra AES, hay una operación XOR, que consiste en XOR cada bloque de 16 bytes con el resultado del cifrado del bloque de 16 bytes anterior y luego realizar el algoritmo AES.

Utilizo un código esquemático simple para ilustrar:

;================================= = ==============

packblock[0]=packblock[i]^initVector

encryptBlock[0]=AES(packblock[0] ) ;(KEY es la clave de AES)

para i=1 al número de bloques-1

packblock[i]=packblock[i]^encryptBlock[i-1]

encryptBlock[i]=AES(packblock[i]) ;(KEY es la clave de AES)

next

;packblock[i] significa Cada 16 bytes de datos después de la compresión

;encryptBlock[i] representa cada 16 bytes de datos después del cifrado

;============ ==== ================================

3. Proceso de descifrado

Dado que el algoritmo AES es simétrico, el proceso de descifrado es el proceso inverso al proceso de cifrado. Pero el proceso de descifrado del algoritmo AES es diferente del proceso de cifrado (porque el proceso de descifrado es diferente de la tabla de subclaves generada por KEY). Todavía requiere que ingresemos una contraseña y genera dos claves de 16 bytes, KEY e initVector, y un salt.

;=========================================== =====

packblock[0]=AES1( encryptBlock[0]) ; (KEY es la clave de AES)

packblock[0]=packblock[i]^ initVector

para i=1 al número de bloques-1

packblock[i]=AES1(encryptBlock[ i]) (KEY es la clave de AES)

;

packblock[i]=packblock[i]^encryptBlock[i-1]

Siguiente paso

;============== =============================== ==

Entonces, ¿dónde juzgas si la contraseña es correcta? ?

El proceso de descifrado consiste en descomprimir el bloque de datos descifrado, luego descomprimirlo en un archivo fuente, realizar una verificación CRC en el archivo y comparar los códigos de verificación CRC de los archivos RAR existentes en el archivo fuente. Si son iguales, Si la contraseña es correcta, si es diferente, la contraseña es incorrecta.

4. No se puede descifrar en unos segundos.

De lo anterior, entendemos la idea general de los archivos RAR. Todo el mundo sabe que al descifrar, debe haber un paso para determinar si la contraseña es correcta. Además, según la experiencia pasada, es posible que podamos mover algunos puntos de juicio, lo que puede reducir el proceso de descifrar ideas. ¿Dónde está este paso en RAR? Pone la suma de comprobación como último paso. ¿Qué hacemos con el barro si queremos romperlo en segundos? Al menos no creo que esto sea posible en este momento.

Veamos el proceso de descifrado a la inversa:

1. ¿CRC comprueba este salto modificado? Esto no tiene ningún sentido porque ya es el paso final. Puede modificar el valor CRC del encabezado del archivo RAR, puede modificarlo, puede usar cualquier contraseña para extraer el valor CRC del archivo, pero su archivo no es el archivo original en absoluto. Es posible que haya quedado completamente desfigurado. Por lo tanto, este proceso no es factible.

La suma de comprobación CRC en sí es irreversible

2. Entonces, ¿qué pasa con el avance del juicio a los datos comprimidos?

Después de la descompresión, ¿hay algo que pueda determinar si los datos comprimidos son correctos? Los datos comprimidos no tienen características fijas y pueden usarse como base para juzgar si están descomprimidos. En este paso, no podemos encontrar características fijas efectivas y utilizables. Porque este paso implica el algoritmo de compresión de RAR. Incluso si es un archivo fuente, incluso si la primera mitad de su archivo es exactamente igual, pero solo la segunda mitad ha cambiado, luego de la compresión, los datos serán exactamente los mismos. Porque los datos comprimidos se comprimen primero y luego se codifican. Diferentes archivos tienen diferentes tablas de compresión escaneadas. La codificación depende de la tabla de compresión, por lo que aquí no existe una característica fija que pueda usarse para juzgar los datos comprimidos.

No importa cómo se vean los datos comprimidos, Winrar los descomprimirá como siempre sin juzgar si los datos comprimidos son válidos.

3. ¿Qué pasaría si desciframos AES?

Dado que AES solo depende de la CLAVE, si el algoritmo AES está descifrado y conocemos la CLAVE, podemos descomprimir los datos, pero hay un problema aquí. Hay una clave initVector para los primeros 16 bytes de. Los bloques de datos son diferentes, ¡no se puede decodificar el primer bloque de datos de 16 bytes sin el parámetro initVector!

4

4. Entonces solo puedes comenzar con el algoritmo hash en el primer paso.

Incluso si puedes descifrar el hash, el resultado después del hash ¿Está todo embarrado y arenoso? Sin resultados, cómo hacer retroceder la contraseña.

Para resumir, descubrí que el cifrado rar está vinculado entre sí mediante algoritmos hash y AES, y estos dos algoritmos son actualmente irrompibles. Al menos no hay forma de descifrar el segundo por el momento. Entonces entiendo lo que significa el Maestro Xue.

5. Algunas reflexiones sobre cómo hacer todo lo posible para mejorar la eficiencia del algoritmo.

He compilado el módulo de algoritmo para el descifrado exhaustivo RAR en ensamblador, pero ¿cómo mejorar la eficiencia del descifrado exhaustivo y optimizar la velocidad del descifrado exhaustivo? Tengo las siguientes ideas:

1. Encontrar funciones a partir de datos comprimidos y eliminar la descompresión, el código de prueba CRC y el código de generación para generar initVector. En la actualidad, a través de muchos experimentos, he descubierto una característica (no sé si es correcta), es decir, el último byte del último bloque de 16 bytes después del descifrado debe ser 0. Después de muchos experimentos con diferentes longitudes, intenté comenzar desde el último bloque de 16 bytes del segmento de datos cifrados y descifrar solo este bloque para ver si un byte es 0. De esta manera, solo se descifran 16 bytes de datos, lo que puede mejorar enormemente ¿Mejorar la eficiencia? Si esto se puede hacer, al descifrar todos los datos, se puede determinar una suma de verificación CRC.

2. Si la primera característica no se cumple, para archivos comprimidos en formatos específicos, como doc, jpg, etc., ¿están los datos comprimidos implicados entre sí? Por lo tanto, al juzgar este paso de antemano, no sé cómo encontrar si hay datos relacionados entre sí en los datos comprimidos.