garble

go install mvdan.cc/garble@latest # or @master

Obfusquez le code Go en encapsulant la chaîne d'outils Go. Nécessite Go 1.27 ou une version ultérieure.

garble build [build flags] [packages]

L'outil prend également en charge garble test pour exécuter des tests avec du code obfusqué, garble run pour obfusquer et exécuter des programmes simples, garble reverse pour désobfusquer du texte tel que les traces de pile, et garble bug pour déposer un rapport de bug pré-rempli. Exécutez garble -h pour voir toutes les commandes et options disponibles.

Objectif

Produire un binaire qui fonctionne aussi bien qu'une compilation classique, mais qui contient le moins d'informations possible sur le code source d'origine.

L'outil est conçu pour être :

• Couplé à cmd/go, pour prendre en charge les modules et la mise en cache des compilations
• Déterministe et reproductible, à partir du même code source initial
• Réversible à partir du code source d'origine, pour désobfusquer les traces de pile de panique

Mécanisme

L'outil encapsule les appels au compilateur et à l'éditeur de liens Go pour transformer la compilation Go, afin de :

• Remplacer les identifiants et les chemins de paquets par de courts hachages base64
• Remplacer les informations de position par de courts noms de fichiers hachés en base64
• Supprimer toutes les informations de build, de module et de débogage
• Obfusquer les littéraux, si l'option -literals est fournie
• Supprimer les informations supplémentaires, si l'option -tiny est fournie

L'outil obfusque tous les paquets pris en charge en cours de compilation, y compris le runtime standard. Les paquets non pris en charge runtime/cgo et crypto/internal/fips140 sont exclus. L'obfuscation du runtime suit les cibles GOOS/GOARCH prises en charge par Go ; Garble ne maintient pas de liste d'architectures autorisées plus restreinte.

Notez que des commandes comme garble build utiliseront la version de go trouvée dans votre $PATH. Pour utiliser différentes versions de Go, vous pouvez utiliser GOTOOLCHAIN.

Cas d'usage

Une question fréquente est de savoir pourquoi un obfuscateur de code est nécessaire pour Go, un langage compilé. Les binaires Go contiennent une quantité surprenante d'informations sur le code source d'origine ; même avec les informations de débogage et les tables de symboles supprimées, de nombreux noms et positions subsistent pour les besoins des traces, de la réflexion et du débogage.

Certains cas d'usage de Go nécessitent de partager un binaire Go avec l'utilisateur final. Si le code source du binaire est privé ou nécessite un achat, son obfuscation peut aider à décourager l'ingénierie inverse.

Un cas d'usage similaire est une bibliothèque Go dont le code source est privé ou acheté. Comme les bibliothèques Go ne peuvent pas être importées sous forme binaire, et que les plugins Go ont leurs défauts, le partage de code source obfusqué devient une option. Voir #369.

L'obfuscation peut également aider pour des aspects totalement étrangers aux licences. Par exemple, l'option -tiny peut réduire la taille des binaires de 15 %, de manière similaire à la pratique courante sur Android pour réduire la taille des applications. L'obfuscation a également aidé certains développeurs open source à contourner des analyses antivirus traitant à tort les binaires Go comme des logiciels malveillants.

Obfuscation des littéraux

L'utilisation de l'option -literals fait que les expressions littérales telles que les chaînes de caractères sont remplacées par des expressions plus complexes, résolues à la même valeur à l'exécution. Les littéraux de chaîne injectés via -ldflags=-X sont également remplacés par cette option. Cette fonctionnalité est optionnelle, car elle peut entraîner des ralentissements selon le code d'entrée.

Les littéraux utilisés dans des expressions constantes ne peuvent pas être obfusqués, car ils sont résolus à la compilation. Cela inclut par exemple toute expression faisant partie d'une déclaration const.

Notez que ce processus peut être inversé avec suffisamment d'efforts ; voir #984.

Mode tiny

Avec l'option -tiny, encore plus d'informations sont supprimées du binaire Go. Les informations de position sont entièrement supprimées, plutôt qu'obfusquées. Le code du runtime qui affiche les paniques, les erreurs fatales et les informations de trace/débogage est supprimé. De nombreux noms de symboles sont également omis des sections binaires au moment de l'édition de liens. Dans l'ensemble, cela peut réduire la taille des binaires d'environ 15 %.

Avec cette option, aucune panique ni erreur fatale du runtime ne sera jamais affichée, mais elles peuvent toujours être gérées en interne avec recover comme d'habitude.

Notez que cette option peut rendre le débogage des plantages plus difficile, car une panique quittera simplement tout le programme sans afficher de trace de pile, et les positions dans le code source ainsi que de nombreux noms sont supprimés. De même, garble reverse n'est généralement pas utile dans ce mode.

Obfuscation du flux de contrôle

Voir : CONTROLFLOW.md

Vitesse

garble build devrait prendre environ deux fois plus de temps que go build, car il doit effectuer deux compilations. La compilation d'origine, pour pouvoir charger et vérifier les types du code d'entrée, puis la compilation obfusquée.

Garble obfusque un paquet à la fois, à l'image de la façon dont Go compile un paquet à la fois. Cela permet à Garble de prendre entièrement en charge le cache de compilation de Go ; les appels incrémentaux à garble build ne devraient recompiler et réobfusquer que le code modifié.

Notez que le premier appel à garble build peut être comparativement lent, car il doit obfusquer chaque paquet pour la première fois. Cela équivaut à vider GOCACHE avec go clean -cache et à lancer un go build à partir de zéro.

Garble utilise également son propre cache pour réutiliser le travail, à l'image du GOCACHE de Go. Il pointe par défaut vers un répertoire situé dans le répertoire de cache de votre utilisateur, tel que ~/.cache/garble, et peut être placé ailleurs en définissant GARBLE_CACHE.

Déterminisme et graines

Tout comme Go, les compilations garble sont déterministes et reproductibles par nature. Cela présente des avantages significatifs, comme la mise en cache des compilations et la possibilité d'utiliser garble reverse pour désobfusquer les traces de pile.

Par défaut, garble obfusquera chaque paquet de manière unique, ce qui changera si son entrée de compilation change : la version de garble, la version de Go, le code source du paquet, ou tout paramètre de compilation tel que GOOS ou -tags. C'est une valeur par défaut raisonnable puisque deviner ces entrées est très difficile.

Vous pouvez utiliser l'option -seed pour fournir votre propre graine d'aléa d'obfuscation. Réutiliser la même graine peut aider à produire la même obfuscation de code, ce qui peut aider lors du débogage ou de la reproduction de problèmes. Faire tourner régulièrement la graine peut aussi aider contre l'ingénierie inverse sur le long terme, car sinon on peut observer les changements dans la façon dont la bibliothèque standard de Go est obfusquée pour deviner quand les versions de Go ou de garble ont été modifiées au fil d'une série de compilations.