Ingénierie inverse 9S12HY64 : correctifs sans désassembleur

Modifier les données statiques dans le firmware 9S12HY64 sans déassembler

Changer l'apparence des indicateurs sur un tableau de bord automobile basé sur le microcontrôleur MC9S12HY64 se fait en analysant le trafic I²C et en modifiant le fichier firmware SREC. Cette méthode évite toute décomposition du code, se concentrant plutôt sur l'identification de signatures dans les données statiques à l'aide de Ghidra. L'objectif est de remplacer les caractères A par P et M par D, tout en éliminant les artefacts numériques.

Analyse matérielle et protocole

Le microcontrôleur 9S12HY64 est connecté à l'affichage via une interface à 6 broches sans driver externe. Le tracé du circuit et les manuels techniques confirment l'utilisation du protocole I²C. Un analyseur logique Saleae capte le trafic entre le MCU et l'affichage dans toutes les positions du levier de vitesses.

Un tableau récapitulatif du trafic révèle des octets variables qui peuvent servir de signatures potentielles :

• Mode A1 : 5A C9 9A 8D...
• Mode M1 : 5A C9 9A 8D... (variations au niveau des premiers octets)

Les octets en rouge sont ciblés pour la recherche dans le firmware, supposés représenter un tableau 2D de charges utiles statiques.

Localisation des signatures dans le firmware

Ghidra est utilisé pour effectuer une recherche hexadécimale sans démontage HCS12. La signature 0x5A, 0xC9, 0x9A, 0x8D permet d'identifier une région mémoire. Format du message : numéro d'octet affiché + données.

Correspondance trafic/mémoire :

• Le premier octet identifie le segment (A/M).
• Les octets suivants définissent les motifs de caractère.

À partir du firmware d'un cluster neuf, les messages pour P et D ont été extraits :

• P : remplacement d'un seul octet.
• D : correction de deux octets.

Comparaison des messages :

| Mode | Message original | Message cible |

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

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

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

Modification du fichier SREC

Structure SREC : en-tête, adresse, données, checksum. Les modifications d'octets exigent un recalcul du checksum (KS).

Script Python pour le calcul du KS :

# Exemple de script (adapté depuis GitHub)
def calc_srec_checksum(line):
    # Somme des octets avec inversion
    s = sum(bytes.fromhex(line[1:-1]))  # Exclure S et KS
    return format((~s + 1) & 0xFF, '02X')

Modifications :

• Pour P : modifier le 1er octet dans une ligne.
• Pour D : ajuster le 1er et le 2e octets dans deux lignes.

Recalcul du KS ; le firmware résultant montre un remplacement partiel avec des artefacts numériques.

Élimination des artefacts numériques

Les chiffres (1 à 5) sont générés comme suit : octet 00 + nybble provenant du 12e octet (base 0x80 + valeur). Recherche de signature dans le firmware pour les chiffres, en zéroant les données pour '4' (en conservant 1, 2, 3).

• Format : numéro d'octet – données.
• Recalcul du KS pour les lignes modifiées.

Le firmware final offre une émulation complète de P/D sans chiffres.

Points clés

• Capture du trafic I²C permet de localiser les données statiques sans analyse de code.
• Recherche hexadécimale dans Ghidra fonctionne efficacement même pour des architectures inconnues comme HCS12.
• Modification du fichier SREC nécessite une gestion précise du checksum pour garantir la validité.
• La méthode est scalable vers d'autres systèmes embarqués utilisant des protocoles série.
• Réduction du risque en évitant l'exécution du code modifié.

— Editorial Team