Contexte du défi
Jane Street a publié un challenge consistant à identifier le comportement d’un ASIC à partir d’un fichier GDS. Le participant dispose d’un GDS (Graphic Data System) décrivant la géométrie du circuit et d’un fichier VCD (Value Change Dump) contenant une trace de signaux. L’objectif final est de retrouver une éventuelle clé ou un message caché dans le circuit.
Analyse des formats GDS et VCD
Le GDS est un format de description physique utilisé dans la fabrication de semi‑conducteurs. Chaque cell représente un bloc logique ou une couche de matériau. En exécutant le script Python suivant, le participant a compté 27 cellules dans le fichier de warm‑up :
python3 -c 'print(len(__import__("gdstk").read_gds("warmup/04_final.gds").cells))'Le VCD est un fichier texte qui consigne les changements d’état des signaux au cours d’une simulation. En le parsant, le programme C fourni a produit la chaîne « TRY AGAIN », prouvant que le circuit intègre des messages ASCII.
Méthodologie de reconstruction du circuit
L’auteur a d’abord exploité la bibliothèque Python gdstk pour extraire les géométries et les métadonnées (labels, coordonnées). Les éléments proviennent de la bibliothèque standard sky130_fd_sc_hd__, une collection de cellules logiques open‑source pour le processus SkyWater 130 nm. En combinant les labels SVG générés par gdstk avec la documentation sky130, il a pu associer chaque forme géométrique à une porte logique (ex. and, or, not, o21bai).
Pour établir les interconnexions, il a utilisé la fonction d’intersection 2‑D de gdstk, qui détecte le chevauchement des zones de métal. Cette approche repose sur l’hypothèse que les labels sont centrés sur leurs ports ; les résultats ont confirmé que la plupart des labels coïncident avec les points de connexion, ce qui a permis de générer un graphe de netlist à partir de la géométrie brute.
Le netlist a ensuite été importé dans un simulateur maison construit autour de sqlite3, où chaque nœud représente une porte et chaque arête un fil. Le simulateur lit le VCD, applique les fonctions logiques décrites par les cellules sky130, et compare les sorties attendues avec les messages extraits (« TRY AGAIN »). Cette chaîne d’outils a été itérée plusieurs fois, chaque passage affinant la correspondance entre géométrie et logique.
Limites et perspectives
La reconstruction repose fortement sur la précision des labels SVG. Aucun mécanisme de vérification croisée (par exemple, extraction de netlists officielles) n’est disponible, ce qui introduit un risque d’interprétation erronée, surtout pour les cellules complexes comme o21bai. De plus, le format GDS ne conserve aucune information temporelle ; le comportement dynamique du circuit ne peut être évalué qu’à partir du VCD fourni, qui ne couvre qu’une séquence de test.
Malgré ces contraintes, la démarche démontre qu’un ASIC décrit uniquement par sa géométrie peut être rétro‑ingénieré en combinant extraction de métadonnées, correspondance avec une bibliothèque de cellules standard et simulation logique. L’approche pourrait être généralisée à d’autres processus (ex. GF180) ou automatisée via des outils de reconnaissance de motifs pour réduire la dépendance aux annotations manuelles.
