2015-11-11 6 views
0

J'ai trouvé l'astuce suivante pour utiliser si un programme utilise ptrace pour détecter si elle est en cours d'exécution dans un débogueur:Contourner ptrace dans gdb

catch syscall ptrace 
commands 1 
set ($eax) = 0 
continue 
end 

Quelqu'un peut me expliquer comment est-il efficace? J'ai essayé d'insérer i r eax après commands 1, mais je ne comprends pas les valeurs négatives que j'ai:

Catchpoint 1 (call to syscall ptrace), 0x00007ffff778af1e in ptrace (request=PTRACE_TRACEME) at ../sysdeps/unix/sysv/linux/ptrace.c:45 
45 ../sysdeps/unix/sysv/linux/ptrace.c: No such file or directory. 
eax   0xffffffda -38 

Catchpoint 1 (returned from syscall ptrace), 0x00007ffff778af1e in ptrace (request=PTRACE_TRACEME) at ../sysdeps/unix/sysv/linux/ptrace.c:45 
45 in ../sysdeps/unix/sysv/linux/ptrace.c 
eax   0xffffffff -1 

Répondre

0

L'appel système ptrace permet un processus de tracer une autre. Ma conjecture est que votre application (qui essaie de détecter le débogueur) engendre un processus enfant (ou peut-être thread) et utilise ptrace pour attacher à cet enfant, tout comme un débogueur le ferait.

Le hic est que seul un processus peut tracer une autre, si un second processus tente de fixer avec ptrace alors la deuxième ptrace échouera, retour -1 et la mise en errno-EPERM. Si vous exécutez sous un débogueur, le débogueur sera entré en premier et attaché avec ptrace, donc lorsque l'application elle-même essaye d'attacher avec ptrace cet appel échouera.

Ainsi, dans votre exemple, lorsque le Catchpoint déclenche sur le retour de syscall ptrace vous pouvez voir que eax est réglé sur -1, ce qui indique que le syscall a échoué (registre eax détient la valeur de retour sur x86-64) .

Maintenant, si le code dans l'application que vous le débogage est très bon, et il ne vérifie pour voir si ptrace renvoie un succès ou non, ce qui oblige alors la valeur de eax à 0 (où 0 indique le succès pour ptrace) peut-être être assez pour tromper l'application en pensant qu'il ne fonctionne pas sous un débogueur.

De toute évidence, il serait possible d'écrire du code plus complexe dans l'application qui fait une utilisation plus large de ptrace tel qu'il serait plus difficile (mais pas impossible) de contourner cette détection.