Discussion :

[Pech14]

Bonjour à tous,

Comme certains d'entre vous le savent déjà, il existe des méthodes simples pour compliquer le debug : par exemple l'utilisation de ptrace et de "faux-breakpoints".
J'ai voulu tenter leur utilisation mais ce serait trop beau si ça marchait du premier coup.

Pour illustrer, voici un résumé pratique de mon problème :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
#include <stdio.h>
#include <signal.h>
#include <sys/ptrace.h>
 
void sighandler(int signal)
{
   if(signal == SIGTRAP)  /* oui ça ne sert à rien, mais les warnings c'est le mal !! */
   {
   }
}
 
int main()
{
   /* on demande à notre programme de se tracer lui-même */
   if(ptrace(PTRACE_TRACEME, 0, NULL, NULL) == -1)
   {
      /* ptrace renvoie une erreur donc le process est tracé par autre chose (strace / débugger / ...) */
      return 1;
   }
 
   /* on utilise un signal handler qui ne fait rien : l'envoi de SIGTRAP sera transparent en exécution "normale" mais un débugger va breaker */
   signal(SIGTRAP, sighandler);  /* oui avec sigaction ce serait mieux etc */
 
   /* on envoie un SIGTRAP à notre programme */
   raise(SIGTRAP);
 
   puts("Je vais jamais être affiché T_T\n");
 
   return 0;
}

Le drame vient du fait que lorsqu'un programme est tracé, il se "met en pose" (statut "T" dans "ps") dès qu'il reçoit un signal (n'importe lequel) et le père doit appeler ptrace avec PTRACE_CONT pour relancer l'exécution.
Dans le cas présent, puisque le programme se trace lui-même, pas moyen de le relancer...

On en arrive (enfin) à ma question : y-a-t'il moyen d'empêcher cela ? Par exemple en arrêtant le traçage si l'appel à ptrace ne renvoie pas d'erreur (et donc si oui, comment ?).

Merci d'avance.

[kwariz]

Bonjour,

Anti-debug = se tirer une balle dans le pied.

Ce que tu cherches est simplement une protection de ton exécutable (et non pas de tes sources) contre un reverse engineering ou une utilisation frauduleuse (encryption des différents segments générés, éventuellement protection de l'exécution par mot de passe, debug de l'exécutable rendu impossible, ...).
Le plus simple au lieu de perdre du temps à insérer des «pièges» que les hackers intéressés sauront, je suppose, contourner aisément, et qui au final poseront des problèmes à toi-même en premier lieu, tourne toi vers des outils qui vont faire le boulot à ta place comme shiva (trouvé rapidement en googlant, je ne sais pas ce que ça vaut) par exemple.
Mais bon, si ton programme est vraiment intéressant/innovant/... il y a aura toujours un hacker pour briser tes défenses ... et s'il n'est pas intéressant/innovant tu auras juste perdu de ton temps.
Sans vouloir faire de prosélytisme, l'open source a de nombreux avantages sur le close paranoid source

En revanche si tu travailles dans un cadre pro, c'est un peu différent ... ces outils d'obfuscation peuvent être intéressants si tu n'as pas confiance en tes clients (ce qui en soi est mauvais signe) ou si tu n'as aucune certitude quant à la protection de l'environnement d'exécution. Mais l'option de miner ton code déplace,dans ce cas, le fusil des pieds vers la tête, enfin à mon avis.

[Pech14]

(Re)bonjour,

des «pièges» que les hackers intéressés sauront, je suppose, contourner aisément

En ce qui concerne ce dont je parle, sans aucun doute (même moi j'y arrive ^^).
De manière générale (ie. quelque soit la protection), le seul changement à faire dans ton affirmation est éventuellement d'enlever le "aisément" !

tourne toi vers des outils qui vont faire le boulot à ta place comme shiva (trouvé rapidement en googlant, je ne sais pas ce que ça vaut) par exemple.

Je suis allé voir rapidement, mais je n'ai pas trouvé les sources (je chercherai donc encore) : ça a été présenté à la BlackHat 2003 et le site donné n'existe plus...

tu auras juste perdu de ton temps.

Puisque mon but est uniquement d'apprendre, je ne perd pas de temps

Sans vouloir faire de prosélytisme, l'open source a de nombreux avantages sur le close paranoid source

Je ne "travaille" que sur ces techniques d'antidebugging et je n'ai donc pas pour but de rendre public quoi que ce soit (et en passant, je suis totalement d'accord avec toi !).

si tu travailles dans un cadre pro

Si c'était dans un cadre pro, je n'en parlerai surement pas !


Pour en revenir à mon problème, la réponse m'intéresse, même si cela n'a au final aucun but pratique.
Puisque tu as évoqué Shiva, au vu de leur présentation il semblerai qu'ils utilisent un fork() et n'aient donc pas ce problème ensuite... peut-être que c'est la seule solution

[kwariz]

[...]
Pour en revenir à mon problème, la réponse m'intéresse, même si cela n'a au final aucun but pratique.
Puisque tu as évoqué Shiva, au vu de leur présentation il semblerai qu'ils utilisent un fork() et n'aient donc pas ce problème ensuite... peut-être que c'est la seule solution

Il y a bien un article intéressant (hors doc ptrace) dans le linux journal ... http://www.linuxjournal.com/article/6100 et effectivement ça forke

[Pech14]

Merci pour le lien.
Je vais laisser le topic en "non-résolu" encore un peu, avec un vague espoir que quelqu'un me montre que puisse qu'il y a un "PTRACE_TRACEME", il existe quelque chose comme "PTRACE_STOPTRACINGME"