miércoles, 31 de marzo de 2021

SJCL: Cifrado en el Sercomm FG824CD

Como ya sabréis, me estoy pegando con el router FG824CD para intentar recuperar datos que no te dan el usuario cutre que sólo te da unas posibilidades muy limitadas y que apenas sirven para nada. Como quieras hacer cosillas, como obtener los datos de acceso al servidor VoIP, lo llevas claro. 

Una de las cosas que uno se encuentra al hacer debug en la interfaz web mientras se van cargando cada una de las secciones a las que se accede es una librería de cifrado y descifrado sjcl: "Stanford Javascript Crypto Library (SJCL)". Según la describen los que la han desarrollado está destinada para aplicaciones web que no requieran muchos recursos. Y eso es lo que puede necesitar un router. Además tienen una demo que permite hacer pruebas. Yo ya lo intenté ver cuando me puse a pegarme con esto pero no vi muy bien cómo funcionaba. Hasta que hace unos días...

Ahora mi idea es probar a hacer un cifrado con los parámetros que me parezcan lo más parecido posible a lo que veo al debuguear.

Una primera prueba que he hecho ha sido la que se puede ver en la siguiente captura:

Prueba de cifrando con SCJL
Prueba de cifrando con SCJL

En este ejemplo he hecho un cifrado sin tirar de contraseña, ya que he visto que aparentemente en el router se utiliza una clave de 32 dígitos hexadecimales. Al menos, claves de esas me he encontrado en bastantes ocasiones. Al hacer el cifrado el textarea del mensaje se borra. 

Como tengo que volver a buscar algunos datos, ya sea porque no tengo todo y porque ya hace un tiempo que no miro esta parte lo tengo un poco olvidado, voy a recopilar algunos más actualizados. Por lo que buscaré las variables sys_encryption_key y dk, las cuales acababan conteniendo el mismo valor. Queriendo recordar me suena que cuando estas tenían contenían algún valor también había alguna variable justo con los datos del scjl. Lo que también significa que tendré que volver a habilitar los puntos de ruptura en esta librería.

La primera en la frente. Poniendo el hash que me ofrecen y el resultado en el formato json con el que guardaban los datos que van a descifrar, quería probar a lanzarlo yo mismo en la demo, pero el resultado ha salido infructuoso:

SCJL intentando descifrar datos del router Sercomm FG824CD sin éxito
SCJL intentando descifrar datos del router Sercomm FG824CD sin éxito

Hay una cosa curiosa que ya la conté en su momento: ese sys_encryption_key no es estático. He visto un montón de veces que al ir al mismo sitio me mostraba distintos valores. Pero a su vez es  un parámetro que se pasa al método que se encarga de hacer el descifrado. Lo que significa que tiene que sufrir alguna transformación específica. Seguro. O al menos habrá que pensar que algo de eso tiene que ser. Si cada X tiempo cambia o es así o el sistema cifra todos los datos constantemente para poder descifrarlo después. ¿Alguna otra opción se os ocurre?

El método al que se llama contiene este código. De los cuatro parámetros que puede recibir se le mandan dos. El primero es el hash y el segundo el resultado de lo que se obtuvo al cifrar los datos y que ahora el router quiere descifrar.

´Método decrypt de la librería SJCL en el Sercomm FG824CD
´Método decrypt de la librería SJCL en el Sercomm FG824CD

Mientras he estado viendo poco a poco los pasos que hace, y la verdad, algunos resultados intermedios no podría decir qué son porque convierten cadenas a "binario" (eso dicen: acaban siendo arrays numéricos) me he encontrado con una función en la que dentro se muestra precisamente el mensaje del alert que suelta la demo:

SJCL en FG824CD: CCM tag doesn't match
SJCL en FG824CD: CCM tag doesn't match

En este punto tendría que ver por qué en el router no me da este mensaje pero sí que salta en la demo. Iba a dejarlo aquí, pero he querido hacer la siguiente prueba: buscar esa línea en la demo, ver qué me encontraba y a una mala manipular los datos para forzar a que no saltase esa excepción.


Debug de SJCL en la página demo
Debug de SJCL en la página demo

Me ha llamado la atención que son distintas versiones ya que como se puede apreciar las líneas no coinciden. Y por desgracia los valores que se comparan, en efecto, son distintos. No he podido profundizar el por qué. No obstante, he probado a ver qué pasaba si forzaba la igualdad, en dos ocasiones, cambiando el valor del otro operador en cada una de ellas... Pero me ha salido unos datos muy raros. 

El resumen: si se os ocurre algo más para atacar este problema, bienvenido sea. Y como de costumbre, lo podéis dejar en los comentarios.

[Update]
Se me ha ocurrido: ¿qué pasaría si me descargase la demo y después la versión de la librería sjcl.js que carga el router para forzar que la demo llame a esta última? Me da el mismo error.
[/Update]

No hay comentarios:

Publicar un comentario