Continuons cette série sur les codes fantastiques avec un exemple tiré d’une histoire vécue : retrouver les sources d’un plug-in Python obfusqué...
En Python, un fichier avec l’extension .pyc représente un fichier de bytecode, spécifique à une version de Python. Tout code Python passe par cet état (au moins en mémoire) avant d’être interprété. Fournir un fichier dans un tel format au lieu d’un fichier source n’apporte guère de protection en termes d’obfuscation de code : il est plutôt facile de régénérer les sources à partir d’un fichier de bytecode, en utilisant un outil comme uncompyle6, tout juste perd-on les commentaires...
La créativité humaine n’ayant pas de limite, je vous propose cette protection anti-reverse découverte en analysant un plug-in Python qui avait été volontairement obfusqué. Commençons avec un code des plus simple en apparence :
Son exécution affiche sans surprise bye dans la console. On peut forcer sa compilation en bytecode :
Et inspecter le bytecode associé à l’aide du script suivant :
Sans rentrer dans les détails du format pyc, disons qu’on saute les 12 premiers octets d’en-tête pour atterrir sur le code Python qu’on charge avec marshal et désassemble avec dis, ce qui nous donne (extrait) :
Maintenant, remplaçons l’opcode associé à LOAD_CONST par un 0x10, c’est-à-dire changeons l’opcode associé pour un opcode qui n’aurait pas de sens ici, par exemple BINARY_MATRIX_MULTIPLY, que l’on sauve dans hello.pyc :
Quand on exécute hello.pyc, malgré la séquence invalide, aucune erreur ne ressort, et le programme affiche hello dans la console.
Que s’est-il passé ? BINARY_MATRIX_MULTIPLY attend deux arguments sur la pile, il a pris ce qu’il y trouvait qui n’a pas de sens (dans ce cas, une string et une fonction, pas le top pour un produit matriciel), il lève alors une exception, que l’on attrape. Et uncompyle6 ne parviendra pas à désassembler le bytecode, échouant sur un joli :