Question:
Puis-je créer un fichier objet à l'aide de gcc qui ne peut pas être rétro-conçu?
asheeshr
2013-03-20 14:43:12 UTC
view on stackexchange narkive permalink

Est-il possible de créer un fichier objet en utilisant gcc qui ne peut pas être rétro-ingénierie à son code source?

si une machine peut le lire ... un humain aussi. vous pouvez rendre la tâche plus difficile pour l'humain ... mais à la fin, ils peuvent / continueront de le lire.
http://stackoverflow.com/questions/4111808/c-c-compiler-generating-obfuscated-code , http://stackoverflow.com/questions/1025494/obfuscating-c-c-code
Trois réponses:
#1
+25
Mike
2013-03-20 17:42:14 UTC
view on stackexchange narkive permalink

AFAIK ce n'est pas possible. Cependant, il y a d'autres choses que vous pouvez garder à l'esprit:

L'utilisation des indicateurs d'optimisation GCC aidera à rendre le code beaucoup moins lisible pour un humain. Lorsque vous compilez avec le plus haut niveau d'optimisation gcc -O3 , le compilateur déplacera les choses de telle sorte que le "flux" ne soit pas du tout ce que vous attendez.

Vous pouvez également utiliser le drapeau -static qui forcera gcc à prendre de petites fonctions et à les rendre en ligne. Cela les incorporera dans votre code au lieu de les afficher sous forme d'appels de fonction. Cela les rendra plus difficiles à distinguer.

Une chose à garder à l'esprit est aussi qu'il est important de se débarrasser de tous les symboles inutiles. Gcc propose -fvisibility = hidden et -fvisibility-inlines-hidden pour vous aider. Vous pouvez également passer l'indicateur -s à gcc pour supprimer les symboles.

Je pense que c'est à peu près tout ce que vous pouvez faire avec gcc pour empêcher l'inversion ingénierie. De plus, vous pouvez utiliser l'obfuscation du code, mais il y a aussi des problèmes à moins que vous ne l'implémentiez vous-même, si vous utilisez une méthode ou un outil facilement disponible pour empêcher l'ingénierie inverse, il existe probablement déjà un outil pour le contrer.

Gardez à l'esprit que l'exécutable final contiendra également des informations telles que la version de gcc avec laquelle il a été compilé. Cela aussi peut être supprimé avec la commande strip .

Si j'ai un exécutable ( myprog ), je peux exécuter objdump dessus pour vérifier certaines informations:

  mike @ mike-VirtualBox: ~ / C $ objdump --full-contents --section = .comment myprog | headmyprog: format de fichier elf64-x86-64Contenu de la section .commentaire: 0000 4743433a 20285562 756e7475 2f4c696e GCC: (Ubuntu / Lin 0010 61726f20 342e362e 332d3175 62756e74 aro 4.6.3-1ubunt 0020 753529.320. 

Oups, vous pouvez voir quelle version / compilateur j'ai utilisé. Eh bien, nous pouvons résoudre ce problème:

  mike @ mike-VirtualBox: ~ / C $ strip -R .comment -R .note myprogmike @ mike-VirtualBox: ~ / C $ objdump --full-contents --section = .comment myprog | headobjdump: section '.comment' mentionnée dans une option -j, mais introuvable dans aucune entrée filemyprog: format de fichier elf64-x86-64  

Il y a d'autres parties que vous pouvez également supprimer, comme .note.ABI-tag mais vous perdez la portabilité

Je ne recommanderais pas de supprimer `.note.ABI-tag` car cela empêchera d'exécuter l'exécutable sur FreeBSD ou un autre système d'exploitation prenant en charge l'émulation Linux.
@IgorSkochinsky - une bonne note pour la portabilité, je n'y pensais pas à l'époque, mais j'ai mis à jour maintenant. Merci.
Le décapage ne supprime pas la version GCC du fichier obj ...
@Mellowcandle - Je ne l'ai pas dit. J'ai dit qu'il l'avait supprimé de l'exécutable.
BTW, je ne sais pas pourquoi la recommandation sur les noms de variables. Si vous le faites correctement, il ne devrait y avoir * aucun * nom de variable dans le binaire final, sauf ceux éventuellement exportés publiquement, et ceux-ci doivent généralement avoir des noms appropriés et lisibles.
Igor a raison. Ces noms doivent être détruits par le compilateur lors de la création de l'objet binaire. Dans ce cas, il n'y a pas de différence. Dans le cas où vous expédiez des binaires contenant des symboles de débogage lourds, vous rencontrez des problèmes beaucoup plus importants que ce que vous avez nommé vos variables.
Vous devriez mettre à jour votre réponse concernant les noms de variables car cela ne fait aucune différence sur un binaire dépouillé.
#2
+21
perror
2013-03-20 14:56:04 UTC
view on stackexchange narkive permalink

Réponse courte : Non.

Réponse longue : Sur la (Im) possibilité de masquer les programmes par Boaz Barak, Oded Goldreich, Rusell Impagliazzo, Steven Rudich, Amit Sahai, Salil Vadhan et Ke Yang.

Réponse moyenne : si vous donnez votre programme à un utilisateur qui contrôle la plateforme là où votre programme sera exécuté, il n'y a aucun moyen d'empêcher le reverse-engineering de celui-ci. La seule chose que vous pouvez espérer est de forcer l'utilisateur à avoir une approche d'analyse boîte noire de votre logiciel (ce qui signifie que l'utilisateur ne pourra observer la sortie de votre programme que sur l'entrée choisie).

Mais, même cette analyse de la boîte noire est extrêmement difficile à appliquer sans un matériel supplémentaire (par exemple, une carte à puce) car l'utilisateur est censé être capable de prendre des instantanés intermédiaires de la mémoire pendant l'exécution de votre programme.

En plus concernant la sécurité matérielle: Google "Il n'y a pas de secrets dans le silicone"
N'oubliez pas qu'à un moment donné, vous devrez également déboguer cette fichue chose. Plus vous obscurcissez et réorganisez votre binaire, plus il sera difficile d'analyser en cas de problème sur le terrain. Cela devient particulièrement trixy si une version non masquée fonctionne parfaitement mais les BSOD de la version masquée en raison d'un timing imprévu ou d'autres interactions introduites par l'obfuscation elle-même.
#3
+8
Igor Skochinsky
2013-03-20 15:13:15 UTC
view on stackexchange narkive permalink

Eh bien, il peut être impossible de REER le fichier dans le code source original exact (par exemple, il n'y a aucun moyen de récupérer les commentaires ou les macros de préprocesseur), mais ce n'est probablement pas ce que vous vouliez demander.

Il est certainement toujours possible (bien que parfois difficile) de produire un code source équivalent , qui se comporte de la même manière que le code compilé. Avec un peu de travail supplémentaire, il pourrait même être possible de produire du code compilant exactement le même bytecode (tant qu'il n'y avait pas de post-traitement supplémentaire du binaire compilé). Cette présentation a décrit certaines des approches pour cela, mais je ne trouve pas les diapositives.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...