Question:
Est-il possible de masquer les détails du compilateur utilisé?
asheeshr
2013-03-23 08:47:10 UTC
view on stackexchange narkive permalink

Le compilateur ajoute des informations système au fichier de sortie / objet créé lors de la compilation.

  • Existe-t-il une option du compilateur qui peut empêcher l'ajout de ces informations?
  • La signature du compilateur peut-elle être complètement supprimée afin de rendre difficile / improbable la détection du compilateur utilisé?
Je suis déchiré. Ce n'est pas une copie * exacte * de [cette question] (http://reverseengineering.stackexchange.com/questions/11) mais il y a beaucoup de points communs, et les réponses seront presque les mêmes ...
@IgorSkochinsky,, corrigez-moi si je me trompe, mais aucune des réponses de la question à laquelle vous faites référence ne discute de la façon de supprimer ou d'obscurcir les attributs du compilateur, mais à la place discuté de leur existence.
Cinq réponses:
#1
+8
Rolf Rolles
2013-03-23 12:34:21 UTC
view on stackexchange narkive permalink

Ma réponse ici est spécifique aux compilateurs C / C ++ courants, mais les principes qui sous-tendent la réponse se généralisent à d'autres scénarios.

Les différences entre les compilateurs se manifestent de bien des manières, dont certaines sont très subtiles. S'il s'agissait strictement d'attributs dans l'en-tête de l'exécutable, alors nous pourrions facilement imaginer réécrire ledit en-tête. Cependant, chaque compilateur a sa propre saveur unique de code généré (et qui varie en fonction du niveau d'optimisation). Chaque compilateur a sa propre bibliothèque standard par défaut (qui comprend souvent des chaînes révélatrices) et un code standard par défaut différent au point d'entrée de l'exécutable. Il existe d'autres différences telles que: les optimisations utilisées dans un compilateur qui ne sont pas utilisées dans un autre; la convention d'appel par défaut peut différer; le code généré pour les prologues de fonction est sensiblement différent sur gcc et MSVC (par exemple); différents compilateurs ont des séquences de code et des structures de données différentes pour la gestion des exceptions; et bien d'autres exemples. Je dirais qu'il est pratiquement impossible de déguiser quel compilateur a produit un exécutable donné.

#2
+4
omghai2u
2013-03-23 14:04:30 UTC
view on stackexchange narkive permalink

Pour répondre à votre première question: Non, je ne pense pas qu'il existe des options de compilateur pour les compilateurs populaires qui vous permettent de l'empêcher d'ajouter ses artefacts de compilateur.

Une partie du problème est exploré par la réponse de @ Syzygy: les compilateurs génèrent, parfois, des instructions très différentes.

De plus, connaître les artefacts laissés par les différents compilateurs vous permet de rendre difficile la distinction du compilateur utilisé. Par exemple, imaginez compiler votre exécutable Windows avec mingw, mais ensuite y ajouter un en-tête RICH. Ceci est un exemple artificiel, mais l'ajout de cet artefact du compilateur MSVC à la sortie mingw confondrait probablement certains outils automatisés.

#3
+4
George V. Williams
2013-03-29 23:06:40 UTC
view on stackexchange narkive permalink

Beaucoup de réponses précédentes ont noté que cela est impossible car le compilateur laissera toujours des artefacts derrière lui. J'ai décidé de faire une petite étude de cas en utilisant un programme sous Linux, bien que l'idée soit transférable.

Par exemple, j'ai créé un petit "Hello World!" fichier en C:

  #include <stdio.h>int main (void) {met ("Hello World!"); return 0;}  

Ensuite, je l'ai compilé et utilisé hexdump -C sur les résultats. Ce qui suit sauf identifie assez clairement le compilateur!

  00001020 47 43 43 3a 20 28 55 62 75 6e 74 75 2f 4c 69 6e | GCC: (Ubuntu / Lin | 00001030 61 72 6f 20 34 2e 36 2e 33 2d 31 75 62 75 6e 74 | aro 4.6.3-1ubunt | 00001040 75 35 29 20 34 2e 36 2e 33 00 00 2e 73 79 6d 74 | u5) 4.6.3 ... symt | 00001050 61 62 00 2e 73 74 72 74 61 62 00 2e 73 68 73 74 | ab..strtab..shst | 00001060 72 74 61 62 00 2e 69 6e 74 65 72 70 00 2e 6e 6f | rtab..interp..no | 00001070 74 65 2e 41 42 49 2d 74 61 67 00 2e 6e 6f 74 65 | te.ABI-tag..note | 00001080 2e 67 6e 75 2e 62 75 69 6c 64 2d 69 64 00 2e 67 | .gnu.build-id ..g | 00001090 6e 75 2e 68 61 73 68 00 2e 64 79 6e 73 79 6d 00 | nu.hash..dynsym. | 000010a0 2e 64 79 6e 73 74 72 00 2e 67 6e 75 2e 76 65 72 | .dynstr ..gnu.ver | 000010b0 73 69 6f 6e 00 2e 67 6e 75 2e 76 65 72 73 69 6f | sion..gnu.versio | 000010c0 6e 5f 72 00 2e 72 65 6c 61 2e 64 79 6e 00 2e 72 | n_r ..rela.dyn..r | 000010d0 65 6c 61 2e 70 6c 74 00 2e 69 6e 69 74 00 2e 74 | ela.pl t..init..t | 000010e0 65 78 74 00 2e 66 69 6e 69 00 2e 72 6f 64 61 74 | ext..fini..rodat | 000010f0 61 00 2e 65 68 5f 66 72 61 6d 65 5f 68 64 72 00 | a..eh_frame_hdr. | 00001100 2e 65 68 5f 66 72 61 6d 65 00 2e 63 74 6f 72 73 | .eh_frame..ctors | 00001110 00 2e 64 74 6f 72 73 00 2e 6a 63 72 00 2e 64 79 | ..dtors..jcr..dy | 00001120 6e 61 6d 69 63 00 2e 67 6f 74 00 2e 67 6f 74 2e | namic..got..got. | 00001130 70 6c 74 00 2e 64 61 74 61 00 2e 62 73 73 00 2e | plt..data..bss .. |
00001140 63 6f 6d 6d 65 6e 74 00 00 00 00 00 00 00 00 00 | comment ......... |  

Exécution de strip -R .comment aide partiellement, et supprime complètement la mention explicite de GCC, mais il y a encore des signes révélateurs:

  00000260 47 4e 55 00 00 00 00 00 02 00 00 00 06 00 00 00 | GNU ............. | 00000270 18 00 00 00 04 00 00 00 14 00 00 00 03 00 00 00 | ............... . | 00000280 47 4e 55 00 5f 8a 1b 97 01 5a ac d7 93 fb 96 29 | GNU ._.... Z .....) | * * * 00000310 00 00 00 00 00 00 00 00 00 00 5f 5f 67 6d 6f 6e 5f | .........__ gmon_ | 00000320 73 74 61 72 74 5f 5f 00 6c 69 62 63 2e 73 6f 2e | start __. Libc.so. | 00000330 36 00 70 75 74 73 00 5f 5f 6c 69 62 63 5f 73 74 | 6. entrées .__ libc_st | 00000340 61 72 74 5f 6d 61 69 6e 00 47 4c 49 42 43 5f 32 | art_main.GLIBC_2 | 00000350 2e 32 2e 35 00 00 00 00 02 00 02 00 00 00 00 00 | .2.5 ............ | * * * 00001020 00 2e 73 68 73 74 72 74 61 62 00 2e 69 6e 74 65 | ..shstrtab..inte | 00001030 72 70 00 2e 6e 6f 74 65 2e 41 42 49 2d 74 61 67 | rp..note.ABI-tag | 00001040 00 2e 6e 6f 74 65 2e 67 6e 75 2e 62 75 69 6c 64 | ..note.gnu.build | 00001050 2d 69 64 00 2e 67 6e 75 2e 68 61 73 68 00 2e 64 | -id..gnu.hash..d | 00001060 79 6e 73 79 6d 00 2e 64 79 6e 73 74 72 00 2e 67 | ynsym..dynstr..g | 00001070 6e 75 2e 76 65 72 73 69 6f 6e 00 2e 67 6e 75 2e | nu.version..gnu. | 00001080 76 65 72 73 69 6f 6e 5f 72 00 2e 72 65 6c 61 2e | version_r..rela. | 00001090 64 79 6e 00 2e 72 65 6c 61 2e 70 6c 74 00 2e 69 | dyn..rela.plt..i | 000010a0 6e 69 74 00 2e 74 65 78 74 00 2e 66 69 6e 69 00 | nit..text. .fini. | 000010b0 2e 72 6f 64 61 74 61 00 2e 65 68 5f 66 72 61 6d | .rodata..eh_fram | 000010c0 65 5f 68 64 72 00 2e 65 68 5f 66 72 61 6d 65 00 | e_hdr..eh_frame . | 000010d0 2e 63 74 6f 72 73 00 2e 64 74 6f 72 73 00 2e 6a | .ctors..dtors..j | 000010e0 63 72 00 2e 64 79 6e 61 6d 69 63 00 2e 67 6f 74 | cr .. dynamic..got | 000010f0 00 2e 67 6f 74 2e 70 6c 74 00 2e 64 61 74 61 00 | ..got.plt..data. |
00001100 2e 62 73 73 00 00 00 00 00 00 00 00 00 00 00 00 | .bss ............ |  

J'ai décidé de voir ce que se produit si je remplace la dernière partie de ce code par des octets nuls. Le programme fonctionnait toujours bien, mais cela réduisait la portabilité vers d'autres systèmes d'exploitation.

Si vous essayez de remplacer GNU par un autre compilateur, disons, clang , cela fonctionne toujours très bien. Bien que cela puisse perturber l'ingénierie inverse, ce n'est certainement pas si difficile à remarquer.

Enfin, j'ai essayé de voir ce qui se passe si je supprimais toute trace de GLIBC...

  ./a.out: ./ a.out: aucune information de version disponible (requise par ./a.out)./a.out: erreur de relocalisation: ./a.out: symbole, version non définie dans le fichier avec référence de temps de liaison  
Les "artefacts" n'incluent pas uniquement des chaînes. Même si vous supprimez toutes les chaînes, le code reste et peut souvent pointer vers le compilateur utilisé de manière très définitive.
Bien que vos propres découvertes soient intéressantes, Igor a raison. Il ne s'agit pas seulement de chaînes, mais également de portions de code que le compilateur insère dans votre binaire final. Vous devez faire de l'ingénierie inverse et redéfinir instruction par instruction jusqu'à ce que vous supprimiez complètement toutes les caractéristiques. Essayez de créer une autre version de votre programme, mais au lieu d'utiliser put (), c'est-à-dire scanf (), vous remarquerez qu'ils ont certaines caractéristiques en commun.
#4
+2
Remko
2013-03-23 14:58:18 UTC
view on stackexchange narkive permalink

Réponse courte: non. Je ne connais aucun compilateur qui a un commutateur "mode furtif" et s'il avait le résultat final, l'OMI serait juste une autre signature pour le même compilateur.

Comme @ omghai2u le suggère, vous pouvez modifier manuellement le binaire et le tester contre des outils automatisés mais je ne pense pas que cela aidera beaucoup.

Une meilleure approche serait peut-être d'utiliser un exe packer / protecteur. Bien qu'un RE expérimenté puisse probablement le déballer, cela signifie encore beaucoup de travail et de connaissances. Donc au moins c'est une première ligne de défense.

Alors il emballe son exe, vous le décompressez et vous vous retrouvez souvent avec les artefacts du compilateur d'origine. En ajoutant de faux artefacts de compilateur, si cela est fait suffisamment et correctement, il devrait être impossible de déterminer quel compilateur a vraiment été utilisé. Une première ligne de défense RE consiste à emballer, bien sûr peut-être (personnellement, je ne suis pas d'accord); mais certainement pas pour cacher la signature du compilateur à l'analyse.
#5
+1
jvoisin
2013-07-16 01:06:45 UTC
view on stackexchange narkive permalink

Vous pouvez essayer:

  • Pour utiliser la strip et la commande sstrip pour supprimer certaines traces.
  • Pour utiliser des options de compilation étranges
  • Pour utiliser des compilateurs étranges (comme tcc) ou anciens
  • Pour utiliser des packers

Mais il n'y a pas de solution miracle. Peut-être devriez-vous vous interroger sur l'aspect pourquoi de votre question plutôt que sur comment

Est-ce le `sstrip` de [ElfKickers] (https://github.com/BR903/ELFkickers) que vous parlez? (parce que je n'ai pas trouvé de paquet pour mon Debian)
Oui, ça l'est. Mais n'hésitez pas à ouvrir un ticket pour les inclure dans Debian;)
Je peux le compiler pour moi, aucun package nécessaire. ;-)


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...