Question:
Techniques anti-débogage sur les plates-formes Unix?
perror
2013-03-20 14:13:52 UTC
view on stackexchange narkive permalink

J'essaie de scanner toutes les techniques possibles pour interrompre l'utilisation d'un débogueur sur une plate-forme Unix (ie POSIX et un peu plus).

Je pense à des techniques telles que le PTRACE test au début d'un programme (ou à différents points de son exécution), l'insertion de faux points d'arrêt (ex: opcode int3 / 0xcc x86) ou time chèques. Mais, aussi des stratégies globales définies sur le programme pour ralentir l'analyse du programme.

Pour l'instant, toutes les techniques que j'ai trouvées sur Internet ont été facilement contournées dès que la technique anti-débogage a été comprise . Alors, je me demande s'il y en a des plus forts.

"toutes les techniques que j'ai trouvées sur Internet ont été facilement contournées dès que la technique anti-débogage a été comprise" <- c'est le cas de la plupart d'entre elles mais pas une raison de les écarter juste à cause de cela.
Vous voudrez peut-être vérifier [ce] [1] sujet. [1]: http://reverseengineering.stackexchange.com/questions/1930/detecting-tracing-in-linux
Deux réponses:
#1
+20
Igor Skochinsky
2013-03-21 00:27:37 UTC
view on stackexchange narkive permalink

En voici quelques-unes que j'ai vues ou dont j'ai entendu parler:

  • Suppression des en-têtes de section. Une action simple et entièrement légale qui arrête GDB sur ses rails. Ne fonctionne pas avec certains autres débogueurs (par exemple IDA). Peut être effectué à l'aide de l'outil sstrip .

  • Utilisation de la fonction syscall ou des instructions directes de syscalls au lieu d'appeler des fonctions spécifiques comme ptrace () . Peut être vaincu en définissant le point d'arrêt sur la fonction syscall ou simplement en parcourant le fichier, mais peut être non évident si vous ne le savez pas.

  • Exécution d'actions anti-débogage avant main () , par exemple dans les constructeurs d'objets globaux ou en utilisant __attribute __ ((constructor)) . Puisque GDB définit généralement le point d'arrêt initial dans main () , il prend en charge la situation par défaut. La solution de contournement est simple: mettez un point d'arrêt sur le point d'entrée du fichier réel ( fichier d'information dans GDB).

  • S'envoyant des signaux liés au débogage comme SIGTRAP . (Notez que cela peut être ignoré avec handle SIGTRAP nostop dans GDB.)

  • Se bifurquer et se tracer avec ptrace .

  • Insertion de faux points d'arrêt: l'insertion de int3 / 0xcc forcera le débogueur à s'arrêter sur ces octets car ils seront traités comme des points d'arrêt logiciels. S'ils sont nombreux cela pourrait ralentir considérablement l'analyse.

  • Détection des points d'arrêt: j'ai vu cette technique dans ce article, vous pouvez attacher une fonction qui sera déclenché lorsqu'un point d'arrêt est détecté. Cet article couvre également d'autres astuces.

Ok, cela semble une liste raisonnable de techniques mais rien de surprenant jusqu'à présent. Et, vous manquez les astuces des points d'arrêt (insertion de faux points d'arrêt pour confondre le débogueur lors de PTRACEd et vérification du hachage du bloc de code suivant pour voir si de nouveaux points d'arrêt logiciels ont été insérés ou non). Mais connaissez-vous un article décrivant toutes ces techniques pour Unix (je connais quelques articles pour MS-Windows mais aucun pour les systèmes Unix).
@Emmanuel:, n'hésitez pas à le modifier et à en ajouter, c'est pourquoi j'en ai fait un wiki. Je ne connais aucun article, mais vous pouvez peut-être trouver d'autres astuces dans quelque chose comme Phrack.
Mon IDA est mort en essayant de charger un binaire ARM dont les en-têtes de section ont été supprimés. Donc, # 1 peut encore être une astuce utile (même si j'ai finalement écrit un script pour reconstituer les en-têtes).
@nneonneo: si cela se produit avec la version actuelle, veuillez envoyer un rapport de bogue. Merci.
Le vrai plaisir est de fork et d'utiliser ptrace () sur vous-même comme une forme d'IPC.
#2
+9
Andrew
2013-03-20 19:31:52 UTC
view on stackexchange narkive permalink

Ma compréhension de la technologie anti-débogage est que c'est un jeu de chat et de souris (ou de chat et aussi de chat). Une technique fonctionne jusqu'à ce qu'elle soit comprise par le camp adverse, puis elle ne fonctionne plus. Je pense qu'en fin de compte, l'avantage est du côté du débogueur. Envisagez une instrumentation binaire dynamique ou des systèmes de machines virtuelles. Vous pouvez détecter la présence de DBI ou d'émulation en recherchant des fissures ou des défauts dans l'émulation de la plate-forme, mais ce ne sont que des erreurs dans le logiciel d'émulation / traduction. Si vous aviez un système d'émulation «parfait», une application déboguée ne pouvait pas savoir qu'elle était tracée?

Je pense donc que le mieux que vous puissiez faire est de petites choses faciles à contourner. Je pense que le système Shiva représente toujours une protection "correcte" contre le débogage sur les plates-formes Unix, car il déchiffre de petites portions de lui-même pour s'exécuter à la demande, puis les rechiffre, comme je me souviens.

Je marquerais le système Shiva comme un packer avancé mais pas vraiment une technique anti-débogage (même si son effet principal est de rendre l'utilisation d'un débogueur extrêmement fastidieuse car votre fenêtre en mémoire où vous pouvez définir efficacement des points d'arrêt est extrêmement petite par rapport à un programme "normal").


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