Contexte et objectifs

En été 2025, l’auteur du blog a publié HellGates, un crackme basé sur un processeur 32 bits entièrement décrit en VHDL. Le CPU est bit‑addressable (contrairement aux architectures classiques qui sont byte‑addressable) et chaque mot de mémoire est chiffré. Après une année sans solution, GPT‑6 a résolu le défi en 20‑30 minutes sur la plateforme SRE‑Bench, révélant une faiblesse majeure du schéma de protection.

Architecture du processeur et du chiffrement

Le cœur du processeur comporte 16 registres généraux de 32 bits et un ensemble de registres spéciaux (overflow_flag, condition_flag, program_counter, key_modifiers, index_for_key_modifier, tea_pseudo_random_state). Les opérations supportées sont les classiques ALU (add, sub, mul, div, shift, rotate) ainsi que des instructions de lecture/écriture mémoire et de branchement. Les opcodes sont codés sur 5 bits, comme le montre l’extrait suivant :

constant opcode_type_or      : opcode_type := "00001";
constant opcode_type_and     : opcode_type := "00010";
constant opcode_type_not     : opcode_type := "00011";
constant opcode_type_add     : opcode_type := "00100";
constant opcode_type_substract : opcode_type := "00101";
... // suite des opcodes

La mémoire utilise un bloc de chiffrement de 64 bits, identique à la taille d’un mot. L’accès bit‑par‑bit impose un alignement strict : lire à l’adresse 0x10001 nécessite de combiner deux mots de 64 bits, comme illustré dans le code C++ fourni dans l’article. Cette contrainte rend la lecture d’instructions non alignées complexe et augmente la surface d’erreur si le chiffrement est mal implémenté.

Analyse de la faille et de l’attaque GPT‑6

Le point de rupture identifié par GPT‑6 est la « crypto protégeant l’état du CPU » décrite comme « lazily done and very weak ». Aucun algorithme de chiffrement robuste n’est détaillé, ce qui a permis d’appliquer une attaque par canal différentiel. En observant les variations de temps d’exécution liées aux vérifications anti‑tamper et aux contrôles de timing, le modèle a pu reconstruire les clés internes, décrypter les registres et ré‑encrypter les valeurs au fur et à mesure de l’exécution. Le résultat est un dump complet de 1 GB de mémoire (data.bin) obtenu en quelques minutes, après que les couches d’obfuscation aient été neutralisées.

Limites et enseignements

Cette démonstration montre que la sécurité d’un CPU custom ne repose pas uniquement sur l’obfuscation du netlist ou sur des vérifications de timing. Une clé de chiffrement faible ou mal dérivée rend le système vulnérable à des analyses statistiques, même lorsqu’il est implémenté au niveau des portes logiques. De plus, la capacité d’un LLM de grande taille à orchestrer une attaque différentiel indique que les protections doivent être évaluées contre des adversaires capables de combiner simulation, analyse de traces et génération de code automatisée. Enfin, l’article ne fournit pas de métriques de performance du CPU synthétisé, ni de détails sur le processus de génération du netlist, ce qui limite la reproductibilité de l’expérience.