Banner publicitario de PCBWay

TV Debugging Tool

Por lo que estuve investigando, UFI no obtiene la clave por medio del ext_csd, sino desde la e-MMC original.
Esto lo logra debido a una vulnerabilidad en el firmware del RPMB que UFI aprovecha usando métodos de bajo nivel.
Buenas noches.

Una pregunta: Un ESP32-S3 es capas de leer los sectore del RPMB y el EXT_CSD a base de codigo, o influye cosas como el voltaje, pinout adicionales, ect?

Desconozco esos detalles.

Gracias.
 
Una pregunta: Un ESP32-S3 es capaz de leer los sectores del RPMB y el EXT_CSD a base de código, o influye cosas como el voltaje, pinout adicionales, ect?
Eso no es ningún problema, con cualquier microcontrolador se pueden leer y escribir los bloques de una e-MMC.
Obviamente sí importan los voltajes de operación, pero se adaptan.
 
Eso no es ningún problema, con cualquier microcontrolador se pueden leer y escribir los bloques de una e-MMC.
Es cierto, pero te doy un ejemplo de lo que quiero decir:

El AU6438 es capaz de leer y escribir en el "user area" de la eMMC, pero no es capaz de obtener el RPBM o leer el EXT_CSD del eMMC.

El ESP32-S3 si es capaz de hacerlo?

Disculpa si es muy logico que "si" o "no", solo quiero estar seguro.
 
El AU6438 es capaz de leer y escribir en el "user area" de la eMMC, pero no es capaz de obtener el RPBM o leer el EXT_CSD del eMMC.
Lo que pasa es que el AU6438 lee la e-MMC como si fuera un dispositivo de almacenamiento extraíble.
Por eso no lee otros bloques, no es lo mismo que un microcontrolador que sí fue programado para eso.
El ESP32-S3 si es capaz de hacerlo?
Sí, ya mencioné que con cualquier microcontrolador, y para un ESP32 es como matar mosquitos a cañonazos.
Y aunque mencionar que con cualquier microcontrolador se puede, es de tomar en cuenta la disponibilidad de E/S.
La velocidad es importante, pero solo un limitante.
 
Lo que pasa es que el AU6438 lee la e-MMC como si fuera un dispositivo de almacenamiento extraíble.
Por eso no lee otros bloques, no es lo mismo que un microcontrolador que sí fue programado para eso.

Sí, ya mencioné que con cualquier microcontrolador, y para un ESP32 es como matar mosquitos a cañonazos.
Gracias por la metafora jajaja, ya esta confirmado.

Da igual si se usa solo D0, o todos las lineas DATA?
 
Por lo que estuve investigando, UFI no obtiene la clave por medio del ext_csd, sino desde la e-MMC original.
Esto lo logra debido a una vulnerabilidad en el firmware del RPMB que UFI aprovecha usando métodos de bajo nivel.
Bien, empecemos por el principio. Tengo una placa con el MT9216 EL.MT9216-FG48, que se vende como una versión económica del Sharp 32FH8EA. Muchas otras marcas también la usan. La compré para un televisor secundario, pero no para un uso serio. En mis registros de OpenWRT, recibía spam constante de solicitudes DHCP incluso con el televisor apagado (el problema era que no se apagaba por completo; necesitaba mantener pulsado el botón de apagado del control remoto). Entonces empecé a investigar qué estaba pasando y quizás a solucionarlo. Compré todo el material para reballing EMMC, etc. Por ahora, según entiendo, UFi Box usa un truco de bajo nivel, como mencionaste, para calcular el hash de la partición RPMB. Este es el primer método descubierto. El segundo es que alguien puede capturar tramas RPMB durante la programación (https://eprint.iacr.org/2024/180.pdf).

Ahora mis preguntas:

1. Me preguntaba si mtkclient puede explotar MT9216. De ser así,

2. ¿MT9216 tiene una ROM de arranque?

3. De ser así, ¿cómo acceder a ella?

4. ¿Qué tan difícil es omitir el AVB EMMC original para acceder a la raíz si terminé en estado rojo?

5. En caso de que sea posible acceder a la raíz, busca la solicitud de actualización cuyo enlace lleve al archivo .zip.
 
¿MT9216 tiene una ROM de arranque?
Sí, por supuesto.
De ser así, ¿cómo acceder a ella?
Ya lo mencionaste, con MTKClient.
Si quieres saber los métodos, puedes estudiar el repositorio.
¿Qué tan difícil es omitir el AVB EMMC original para acceder a la raíz si terminé en estado rojo?
Si se implementa debe ser complicado, pero ten en cuenta que lo que se aprovecha son las vulnerabilidades.
En los firmware anteriores al Android 13 de MTK para TV y otros, no he visto que se implemente.
En los firmware recientes que estén certificados y que usen Google TV, sí podría estar implementado.
En caso de que sea posible acceder a la raíz, busca la solicitud de actualización cuyo enlace lleve al archivo .zip.
Esto no lo entendí, pero si desempacas un firmware, puedes estudiarlo para ver su nivel de seguridad.
 
Sí, por supuesto.

Ya lo mencionaste, con MTKClient.
Si quieres saber los métodos, puedes estudiar el repositorio.

Si se implementa debe ser complicado, pero ten en cuenta que lo que se aprovecha son las vulnerabilidades.
En los firmware anteriores al Android 13 de MTK para TV y otros, no he visto que se implemente.
En los firmware recientes que estén certificados y que usen Google TV, sí podría estar implementado.

Esto no lo entendí, pero si desempacas un firmware, puedes estudiarlo para ver su nivel de seguridad.
Tengo una pregunta más para ti.
¿Conseguiste acceder a la ROM de arranque del mt92xx? Intenté conectar a tierra CMD + CLK + DATA1 (por error en lugar de DAT0), si no recuerdo mal, con las resistencias y el EMMC desconectados, y no funcionó.
en la salida del analizador lógico tenia un error relacionado con emmc CMDxx no lo recuerdo, pero aun así quería restaurar la comunicación con emmc
 
¿Conseguiste acceder a la ROM de arranque del MT92XX?
¿En qué aspecto?
Para explotarla, no, pero sí para obtenerla.
Intenté conectar a tierra CMD + CLK + DATA1 (por error en lugar de DAT0), si no recuerdo mal, con las resistencias y el EMMC desconectados, y no funcionó.
¿Con qué intención hiciste eso? Por lógica, un procesador sin e-MMC no podrá realizar ninguna función en el hardware externo.
 
¿En qué aspecto?
Para explotarla, no, pero sí para obtenerla.

¿Con qué intención hiciste eso? Por lógica, un procesador sin e-MMC no podrá realizar ninguna función en el hardware externo.
El procesador deja de arrancar porque comprueba la clave RPMB, ¿verdad? ¿No puedes configurar la ROM de arranque para que acepte todo? El exploit mtkclient requiere que el procesador esté en la ROM de arranque, ¿o me estoy perdiendo algo?
 
El procesador deja de arrancar porque comprueba la clave RPMB, ¿verdad?
No, el procesador siempre "arranca" y carga el sistema por ejecución del cargador, exista o no, sea válida o no, la clave del RPMB.
Lo que deja de funcionar son las aplicaciones que dependan de las claves HDPC.
¿No puedes configurar la ROM de arranque para que acepte todo?
Solo teniendo el código fuente y compilando uno modificado.
El exploit mtkclient requiere que el procesador esté en la ROM de arranque, ¿o me estoy perdiendo algo?
Esto me parece confuso: "el procesador esté en la ROM de arranque".
Lo que tú llamas "ROM de arranque" es comúnmente conocido como bootloader.
El bootloader se escribe en la e-MMC y cuando enciende el TV se carga en RAM, ejecuta lo que tenga que ejecutar y se cierra.
Después de cargar el sistema o una instalación, ya no está activo hasta un reinicio.
 
Atrás
Arriba