Muchos de los consejos que estoy a punto de sugerir requieren un uso excesivo del aleatorizador. No son ataques de diccionario, pero sí incluyen una gran cantidad de codificaciones de contraseñas con el fin de recopilar datos. Si su objetivo es hacer esto sin demasiadas pruebas de prueba contra la función, o no puede hacerlo, realmente no tengo muchos consejos.

Enteros

Es fácil trabajar con los enteros, y cualquier persona que implemente una codificación propia probablemente esté operando en enteros, no en cadenas. Encontrar una correspondencia entre los dos símbolos ( J8 , D9 , etc.) y los enteros podría ser crucial. Dado que todos los números y las letras están representados, hay 26*20=260 tokens diferentes para trabajar. 260 está cómodamente cerca de 256 , lo que podría sugerir que los tokens son solo una codificación de bytes.

El enfoque intuitivo es interpretar Xn como 10*X+n , donde X es el índice de la letra X y n un número entero entre 0 y 9. Esto queda descartado por el token Z8 , que correspondería al entero 258 , que es demasiado grande para un byte. De manera similar, se pueden descartar varias otras codificaciones, al menos estas combinaciones lineales simples:

b = 10*X + n
b = 10*(26-X) + n
b = (26-X) + 26*n
b = 10*(26-X) + (9-n)
b = (26-X) + 26*(9-n)

Para descartar las conjeturas para la codificación que hacemos, saber qué tokes aparecen en los scrambles es muy útil. Si los tokens son una codificación para bytes, entonces debería haber 260-256=4 tokens que nunca aparecen. Encontrar estas fichas podría dar pistas valiosas. Si todos los tokens ocurren en algún momento, también sería una pista valiosa.

Cajas

Las codificaciones para las contraseñas ('AAA', 'AAAA', 'AAAAA' ...) nos dan información útil. Podemos deducir que la función de aleatorización para un solo símbolo es una función f(symbol, integer) -> token donde el entero i es la suma de la longitud de la contraseña y el índice del símbolo. P.ej. %código%. En general, f(A, 4+1) = f(A, 3+2) = J8 es constante para todas las longitudes e índices.

A  A  A  A
F6 J8 D3 J0

A  A  A
N6 F6 J8

Como la contraseña está limitada a 8 símbolos, tenemos f(symbol, length + index) diferentes funciones de aleatorización 8+8 = 16 para encontrar. Es difícil establecer a partir de los datos disponibles si estas funciones dependen del entero 'n' (es decir, g_n(symbol) -> token ). Las funciones length + index podrían implementarse como tablas de búsqueda y no seguir ningún patrón en absoluto.

@

El carácter g_n me ha dejado perplejo, pero tal vez sea para reconocer direcciones de correo electrónico codificadas. Las direcciones de correo electrónico tienen más de 8 símbolos y podrían implicar que la codificación funciona también con una entrada más larga, lo que a su vez sugiere que las funciones @ son dependientes de g_n (teorema de la pereza, nadie hace más de 16 tablas de búsqueda aleatoria)

Construyendo las tablas de búsqueda

Esto se podría hacer simplemente mezclando todas las contraseñas n , aa...a ... bb...b , y usando la relación de longitud y posición para decidir a qué función ^^...^ pertenece el resultado codificado. Estos datos también ayudarán a descubrir qué y cómo los tokens codifican los datos.

Mirando las tablas

Si construimos tablas para todas las contraseñas alfabéticas de repetición de longitud 8, es decir. g_n , aaaaaaaa , etc. podríamos visualizar los resultados codificados como una imagen de 8x26. Los humanos son buenos para mirar imágenes, por lo que las cosas más simples (como la linealidad) se ven fácilmente desde la imagen. La búsqueda de artefactos horizontales, verticales, cuadrados o diagonales en una imagen puede decir mucho sobre el algoritmo utilizado para codificar las contraseñas. Este enfoque es muy orgánico y requiere algunas habilidades de programación / scripting.

Mi enfoque de visualización sería el siguiente:

• generar codificaciones para todas las contraseñas de 8 caracteres ASCII repetidos (o bytes, si es posible)
• convierta los tokens en bytes usando un esquema simple (por ejemplo, una combinación lineal)
• guarde los bytes como un archivo binario bbbbbbb
• utilice el ImageMagick bytes.gray utilidad: convert
• mira la imagen y trata de encontrar patrones

Esta secuencia:

a  b  a  b  a  b  a  b
H1 E3 B8 W6 Z4 S0 X1 K4

b  b  b  b  b  b  b  b
S8 E3 O2 W6 G6 S0 C0 K4

a  a  a  a  a  a  a  a
H1 L3 B8 H5 Z4 D7 X1 Z8

dice que se está utilizando una clave para codificar la contraseña de entrada, al igual que XOR, excepto que la mayoría de los usos de XOR saldrían en hexadecimal mientras que esta salida es base36?

Esta secuencia

A  B  A  B  A  B  A  B
B0 Y1 V6 Q5 T3 I9 R0 E3

A  A  A  A  A  A  A  A
B0 F2 V6 B4 T3 X5 R0 T7

A  A  A  A  A  A  A
J0 B0 F2 V6 B4 T3 X5

A  A  A  A  A  A
D3 J0 B0 F2 V6 B4

me hace pensar que hay diferentes claves para diferentes cadenas de longitud.

Entonces, supongo que el algoritmo toma el texto en claro 'a', toma el valor ascii de 'a' (97) lo convierte a base36 (2P), XORs con el valor respectivo en la clave y le da la base36 valor de H1.

EDITAR: no parece ser base36. Sea cual sea el esquema de codificación en uso, todavía estoy adivinando que usa XOR. Ayudaría a explicar el comportamiento de cero, ya que cero XORed con X es siempre X.

Si eso es cierto, el proceso es reversible y se pueden encontrar las claves, eliminando la necesidad de fuerza bruta o la creación de tablas de búsqueda.