En este artículo voy a explicar, de forma resumida, el proceso que seguí para descifrar una copia de seguridad de la configuración de un router Sagemcom F@ST 5655v2. Este método también es aplicable al Sagemcom F@ST 5657.
El equipo utilizaba el firmware:
SGDV10000059
Al exportar la configuración desde el WebInterface, el router generaba un archivo device.cfg. Sin embargo, al abrirlo con un editor hexadecimal o intentar descomprimirlo, era evidente que no se trataba de un XML, ZIP o GZIP normal.
El objetivo era averiguar:
- Qué formato utilizaba el archivo
- Qué algoritmo de cifrado empleaba
- De dónde obtenía el router la clave
- Cómo recuperar finalmente el XML de configuraciónPunto de partida
En este modelo no disponía inicialmente de una shell funcional desde la que poder inspeccionar directamente el sistema.
Por suerte, posteriormente pude conseguir:
- Un volcado NAND/UBI reciente del F@ST 5655v2
- Una copia de seguridad device.cfg generada por ese mismo router
Era importante que ambos archivos pertenecieran al mismo equipo o, al menos, que el volcado incluyera los parámetros permanentes de ese dispositivo.
Esto terminó siendo fundamental, porque la clave utilizada para proteger la configuración no es completamente genérica.
Extracción del firmware
El primer paso fue extraer el contenido del volcado NAND, cortesía de mi amigo Asu (muchas gracias).
El firmware estaba organizado mediante volúmenes UBI, así que hubo que identificar y extraer los diferentes volúmenes hasta obtener los sistemas de archivos que utilizaba el router.
Dentro del contenido extraído aparecieron las librerías, ejecutables y archivos de configuración habituales de un sistema Linux embebido.
Entre todo ese contenido, las librerías más interesantes para este análisis fueron:
libgsdf.so
libsmu.so
También apareció un archivo llamado:
permanent_param
Este archivo contiene parámetros permanentes propios del dispositivo. Más adelante veremos que uno de esos parámetros interviene directamente en la generación de la clave.
Identificando el formato del backup
Analizando la cabecera y la estructura de device.cfg, pude comprobar que el archivo utilizaba la cabecera:
AEAD 10
Este formato ya aparece en otros routers del fabricante.
A partir de ese momento, el problema parecía estar bastante claro: probablemente el algoritmo general no había cambiado, pero faltaba conocer la clave utilizada por este modelo concreto.
El proceso interno del archivo era, de forma simplificada:
Contenedor AEAD 10
↓
Descifrado AES en modo CTR
↓
Datos comprimidos con GZIP
↓
Configuración XML
Por tanto, para llegar al XML primero había que interpretar correctamente el contenedor, descifrar su contenido y después descomprimir el resultado.
Buscando la clave dentro del firmware
El siguiente paso fue analizar las librerías relacionadas con la exportación e importación de la configuración.
Siguiendo las referencias entre libgsdf.so y libsmu.so, apareció una llamada especialmente interesante:
gsdfSetCryptoKey(0x3001, 0, key, 0x20);
Esta función registraba una clave criptográfica de:
0x20 bytes = 32 bytes
Después de seguir la construcción de la variable key, se pudo ver que no se utilizaba una clave fija incluida directamente en el firmware.
La clave se construía concatenando tres valores:
"A91D2F0C" + H235_KEY + "9BD25A01"
Es decir:
Prefijo fijo
+
Clave H235 propia del dispositivo
+
Sufijo fijo
El prefijo y el sufijo son comunes, pero el valor central cambia en cada equipo.
El resultado final es una cadena de 32 caracteres que la función entrega como una clave de 32 bytes.
Un detalle importante es que esa cadena se utiliza tal cual. No hay que convertir los caracteres hexadecimales en una clave binaria de 16 bytes.
Localizando H235_KEY
Ya sabíamos cómo se construía la clave, pero todavía faltaba obtener el valor de:
H235_KEY
Siguiendo de nuevo el código del firmware apareció esta función:
bsp_get_permParam_h235Key()
Su nombre daba una pista bastante clara.
La función recuperaba el valor desde los parámetros permanentes del router, almacenados en:
permanent_param
Dentro del volcado del equipo pude localizar el valor correspondiente a H235_KEY.
No voy a publicar aquí la clave real de mi router, pero tendría un formato parecido a este:
H235_KEY = XXXXXXXXXXXXXXXX
Con ese valor ya era posible construir la clave completa:
A91D2F0CXXXXXXXXXXXXXXXX9BD25A01
Esto también explica por qué una clave obtenida de otro Sagemcom, aunque utilice el mismo formato de backup, no tiene por qué funcionar.
El algoritmo es el mismo, pero una parte de la clave depende del dispositivo.
Descifrando device.cfg
Una vez obtenida la clave completa, el resto del proceso consistió en reproducir lo que hacía el propio firmware.
De forma resumida:
1. Leer el contenedor AEAD 10
2. Extraer los parámetros necesarios para AES-CTR
3. Utilizar la clave de 32 bytes
4. Descifrar el contenido
5. Comprobar que el resultado comienza con una cabecera GZIP
6. Descomprimirlo
7. Guardar el XML resultante
Al utilizar la clave correcta, el resultado descifrado comenzó con la cabecera habitual de GZIP:
1F 8B
Después de descomprimirlo apareció finalmente el XML completo de configuración.
Dentro del archivo estaban los parámetros del router, incluyendo la configuración de Internet, GPON, telefonía, Wi-Fi y otros servicios gestionados por el operador.
Esquema completo
El proceso completo quedaría más o menos así:
Volcado NAND del router
│
▼
Extracción de los volúmenes UBI
│
▼
Análisis de libgsdf.so y libsmu.so
│
▼
Localización de gsdfSetCryptoKey()
│
▼
Clave = prefijo + H235_KEY + sufijo
│
▼
Obtención de H235_KEY desde permanent_param
│
▼
Descifrado AES-CTR del contenedor AEAD 10
│
▼
Descompresión GZIP
│
▼
Configuración XML
Conclusiones
Finalmente, el formato de las copias de seguridad del F@ST 5655v2 no era completamente nuevo.
Sagemcom seguía utilizando el esquema:
AEAD 10 → AES-CTR → GZIP → XML
La diferencia principal estaba en la clave.
En este firmware, la clave se construye utilizando dos partes fijas y un valor H235_KEY almacenado en los parámetros permanentes del dispositivo:
"A91D2F0C" + H235_KEY + "9BD25A01"
Esto significa que no existe una única clave universal válida para todos los F@ST 5655v2. Para descifrar un backup es necesario disponer del valor H235_KEY correspondiente a ese router.
Lo más complicado no fue realmente implementar AES-CTR o descomprimir el archivo, sino seguir el recorrido dentro del firmware hasta descubrir de dónde salía exactamente la clave.
Una vez localizada la llamada a gsdfSetCryptoKey() y su relación con permanent_param, el resto del proceso quedó bastante claro.
Finalizando
Estarás diciendo, 'ya que voy a desoldar la memoria para leerla puedo obtener los datos necesarios directamente del volcado', y así es, por lo que todo este proceso no te sería necesario. Pero como aquí hemos venido a jugar, a continuación adjunto una pequeña aplicación web, que funciona todo en local, para cifrar y descifrar el archivo de configuración.
Comentarios
0 comentarios