Hace tiempo que me interesa el tema de la autorización de consolas de medios en el portal Stalker, pero no fue antes de eso. Un día, accidentalmente obtuve el prefijo Infomir MAG250 y decidí abordar este problema.Formación
En primer lugar, desarme el prefijo, solde el cable al conector y lo conecte a la computadora. Después de lanzar el programa de terminal, me complació el familiar U-Boot. El proceso de arranque también se puede interrumpir presionando cualquier tecla (por lo general, el fabricante deshabilita dichos chips y tiene que pasar mucho tiempo para llevar U-Boot al estado deseado). El acceso con privilegios de root también estaba disponible a través de ssh.
La consola está equipada con DRAM de 256 MB y dos unidades flash, NOR 1 MB y NAND 256 MB. Con NOR, U-Boot se carga en el proceso, que carga el núcleo y el sistema de archivos desde NAND.Función Getuid ()
El prefijo se autoriza en el portal Stalker, enviando un montón de información, como, por ejemplo, tipo, versión de firmware, versión de hardware, número de serie, etc. Pero estaba específicamente interesado en el parámetro device_id, que emitió la función gSTB.GetUID (). A primera vista, era un hash como SHA256 o MD5. En referencia a la documentación oficial soft.infomir.com/stbapi/JS/v343/gSTB.html#.GetUID , la función puede tomar hasta dos parámetros, pero lo primero que me interesó fue la opción sin parámetros. Al cargar stbapp en la IDA, podemos encontrar fácilmente esta función.
Yendo un poco más allá, vemos un momento interesante
Aquí, el programa asigna 0x41 bytes de memoria, lo anula y llama a la función del controlador / dev / stapi / stevt_ioctl, pasándole este fragmento de memoria y el parámetro 0xC004C919. Por lo tanto, un determinado controlador stevt_ioctl es responsable de generar el UID. Para verificar esto, esbocé rápidamente este código: al
ejecutarlo en la consola, vi un UID familiar.stevt_ioctl
El siguiente paso es desmontar el controlador stapi_ioctl_stripped.ko, que se encuentra en / root / modules. Cargamos el controlador en la IDA y encontramos el controlador 0xC004C919 ioctl (llamé a esta función calcHash).
Hay tres puntos interesantes. Primero, se copian 0x41 bytes de memoria del espacio del usuario al espacio del núcleo (esto es exactamente lo que transmite el usuario y en nuestro caso consiste en ceros), la función get_mem_type se llama(en el camino en el núcleo mismo) y el resultado (nuevamente 0x41 bytes) se copia en el área de dirección del usuario. Para encontrar la dirección de la función get_mem_type, vi dos posibilidades: solo mira el archivo / proc / kallsysms, esperando que el acceso no esté restringido, o bien, o de lo contrario, escribe un ensamblaje en ensamblador para el controlador que devuelve el valor del registro r0 en el lugar correcto. Después de buscar en / proc / kallsysms, me sorprendió gratamente y encontré la dirección de la función get_mem_type 0x8080E380.Núcleo
Para un análisis posterior, deberá analizar el núcleo. El núcleo en sí se puede encontrar en el firmware del fabricante, o puede eliminar el volcado utilizando U-Boot
o montar la partición deseada.Según la información de U-Boot, el núcleo se carga a 0x80800000 y el punto de entrada se encuentra a 0x80801000. Cargamos el kernel en el IDA y encontramos la función get_mem_type .Después de analizar el código, descubrí esta sección, que supuestamente devolvió el UID.
Entonces el UID se almacena en 0x80D635EC. A continuación, estamos buscando en la AIF, donde se forma este valor. Esto estaba en la función init_board_extra (no traduciré la lista completa)
Entonces, este es el mismo valor desconocido en la dirección del registro r4 a partir del cual se calcula el hash de interés (por cierto, fill_hash fue resuelto por SHA256). Realmente estaba ansioso por descubrir qué era y rápidamente escribí un inserto en el ensamblador, que, a través de la función printk, devolvió el contenido de la memoria en la dirección del registro r2. Habiendo modificado el kernel de esta manera, hice una nueva uImage y la cargué en una unidad USB. Y en el conjunto de terminales U-Boot:usb start
fatload usb 0:1 80000000 uImage
bootm
Pero después del último equipo, me esperaba tanta tristeza.
U-Boot se negó cortésmente a enviar mi nuevo núcleo.Edición de U-Boot
Para convencer a U-Boot de que inicie mi kernel, decidí parchearlo en la memoria con el comando mw . Para comenzar, hice un volcado completo de NOR flash, que se encuentra en 0xA0000000. Habiendo conducido el volcado a la IDA, descubrí la dirección de memoria donde se copió el U-Boot. Fue 0x8FD00000. Nuevamente, después de deshacerme de esta parte de la memoria y ejecutar IDA, encontré fácilmente una función que verificaba la firma. Si todo estaba correcto, devolvió 0. Además, la llamaron en dos lugares diferentes.
Lo que hizo exactamente esta función no fue interesante para mí. Solo necesitaba devolver 0 así:mov #0x0, r0
rts
nop
El código correspondiente para U-Boot ahora era así:usb start
mw.l 8fd0ec08 000b200a;
mw.l 8fd0ec0c 00900009
fatload usb 0:1 80000000 uImage
bootm
Entonces U-Boot cargó felizmente mi kernel, que emitióEF0F3A38FF7FD567012016J04501200:1a:79:23:7e:2MAG250pq8UK0DAOQD1JzpmBx1Vwdb58f9jP7SN
Análisis completo
Entonces, ¿en qué consistía el UID? Era un número desconocido de 8 bytes, el número de serie de la consola, la dirección MAC, el tipo de consola y un pedazo de basura. Queda por averiguar qué tipo de número desconocido era y de dónde provenía la basura. Regresé a la función init_board_extra nuevamente .Se tomó un número desconocido de esta sección del código:
Aquí, usando la función __ioremap, el núcleo accedió a la memoria física a 0x00000000 (que era la dirección NOR del flash), escribió 0x0F a 0x00000000, luego 0x98 a 0x000000AA y leyó 8 bytes a partir de 0x000000C2. ¿Y qué es eso? Estos son los comandos del protocolo CFI con los que el núcleo se comunicó con NOR. 0x0F trajo el NOR a su estado original, y con el modificador de comando 0x98 mods CFI. En este módulo, en la dirección 0x000000C2 se encuentra el Área de código de seguridad o un número de dispositivo único de 64 bits. Aquellos. número desconocido es un número único de flash NOR. El siguiente es un volcado de identificación CFI.
Puede realizar su volcado directamente en U-Boot configurandomw.w a0000000 f0
mw.w a00000aa 98
md.b a1000000 100
Una pieza de basura era solo un juego de caracteres ordinario de 32 bytes que se coseba en el núcleo mismo.
Y esta basura se procesaba antes de usar la función de cifrado swap_pairs , que simplemente cambiaba la posición de los bytes.[0x00000003]<->[0x0000000F]
[0x00000005]<->[0x0000001F]
[0x00000009]<->[0x00000002]
[0x0000000A]<->[0x0000001D]
[0x00000010]<->[0x00000015]
[0x00000004]<->[0x00000013]
[0x0000000D]<->[0x00000018]
Según la información recibida, me atrevo a suponer que la base de datos del fabricante contiene información sobre cada ID NOR flash y el número de serie y la dirección MAC correspondientes.Por supuesto, es imposible seleccionar todo esto, pero puede escribir su propio software, que emulará completamente la consola.