Volver al inicio

Ingeniería inversa 9S12HY64: parcheo sin desensamblador

El artículo describe la ingeniería inversa del firmware 9S12HY64 sin desensamblador: escucha de I²C, búsqueda de firmas en Ghidra, parcheo de SREC para cambiar la pantalla. Se logró un resultado funcional de emulación de indicadores. El enfoque es aplicable a tareas similares.

Parcheo de firmware 9S12HY64: desde I²C hasta el resultado
Advertisement 728x90

Parche de datos estáticos en firmware 9S12HY64 sin desensamblar

Modificar cómo aparecen los indicadores en un panel de instrumentos automotriz basado en el microcontrolador MC9S12HY64 se logra analizando el tráfico I²C y parcheando el archivo de firmware SREC. Este método evita completamente la desensambladura del código, centrándose en identificar firmas en datos estáticos usando Ghidra. El objetivo es reemplazar los caracteres A por P y M por D, eliminando al mismo tiempo artefactos numéricos.

Análisis de hardware y protocolo

El microcontrolador 9S12HY64 se conecta a la pantalla mediante una interfaz de 6 pines sin controlador externo. El rastreo del circuito y los manuales de referencia confirman el uso del protocolo I²C. Un analizador lógico Saleae capta el tráfico entre el MCU y la pantalla en todos los modos del selector de marchas.

Una tabla resumen del tráfico revela bytes cambiantes que sirven como posibles firmas:

Google AdInline article slot
  • Modo A1: 5A C9 9A 8D...
  • Modo M1: 5A C9 9A 8D... (variaciones en los primeros bytes)

Los bytes resaltados en rojo son los objetivos de búsqueda en el firmware, supuestamente representan una matriz 2D de cargas útiles estáticas.

Localización de firmas en el firmware

Ghidra se utiliza para búsquedas hexadecimales sin necesidad de desensamblar HCS12. La firma 0x5A, 0xC9, 0x9A, 0x8D localiza una región de memoria. Formato del mensaje: número de byte en pantalla + datos.

Correlación entre tráfico y memoria:

Google AdInline article slot
  • El primer byte identifica el segmento (A/M).
  • Los bytes siguientes definen los patrones de carácter.

A partir del firmware de un cluster nuevo, se extrajeron mensajes para P y D:

  • P: reemplazo de un solo byte.
  • D: corrección de dos bytes.

Comparación de mensajes:

| Modo | Mensaje original | Mensaje objetivo |

Google AdInline article slot

|------|------------------|------------------|

| A1 | 5A C9 9A 8D... | 5A XX XX 8D... (P) |

| M1 | 5A C9 9A 8D... | 5A YY ZZ 8D... (D) |

Parche del archivo SREC

Estructura SREC: encabezado, dirección, datos, checksum. Los cambios de bytes requieren recalcular el checksum (KS).

Script Python para cálculo de KS:

# Ejemplo de script (adaptado de GitHub)
def calc_srec_checksum(line):
    # Suma de bytes con inversión
    s = sum(bytes.fromhex(line[1:-1]))  # Excluir S y KS
    return format((~s + 1) & 0xFF, '02X')

Cambios:

  • Para P: modificar el primer byte en una línea.
  • Para D: ajustar el primer y segundo bytes en dos líneas.

Recalcular KS; el firmware resultante muestra reemplazo parcial con artefactos numéricos.

Eliminación de artefactos numéricos

Los dígitos (1–5) se generan como: byte 00 + nibble del byte 12 (base 0x80 + valor). Búsqueda de firmas en firmware para dígitos, cero de datos para '4' (manteniendo 1, 2, 3).

  • Formato: número de byte – datos.
  • Recalcular KS para líneas modificadas.

El firmware final ofrece emulación completa de P/D sin dígitos.

Conclusiones clave

  • Escaneo de tráfico I²C permite localizar datos estáticos sin análisis de código.
  • Búsqueda hexadecimal en Ghidra funciona eficazmente incluso en arquitecturas desconocidas como HCS12.
  • Parche SREC exige manejo preciso del checksum para mantener validez.
  • El enfoque es escalable a otros sistemas embebidos que usan protocolos serie.
  • El método reduce riesgos al evitar la ejecución de código modificado.

— Editorial Team

Advertisement 728x90

Leer después