Se voulant comme une suite spirituelle de l’article du MISC hors-série n°33 sur l’interception réseau, il est vivement conseillé de lire ce dernier avant d’entamer la lecture de celui-ci. Les bases du fonctionnement d’Android, de l’émulation, du reverse engineering et de l’interception réseau sont considérées acquises. Ici, on va un peu plus loin et on tente de sortir des sentiers battus !

Si vous avez déjà parcouru un moteur JavaScript, un parseur de fichiers, un compilateur, ou n’importe quel projet où C/C++ est suffisamment ancien pour nourrir des légendes urbaines ou traumatiser les développeurs les plus aguerris, vous savez déjà ceci : il existe des bugs que personne ne trouvera jamais manuellement.

Les différents sanitizers ainsi que Valgrind sont d’excellents outils pour détecter certaines classes d’erreur à l’exécution. Lorsqu’une erreur est détectée, un message de diagnostic est en général affiché, mais il peut arriver que l’on souhaite plus d’informations sur l’état du programme à ce moment. Dans cet article, nous explorons comment un débugueur tel que GDB peut être utilisé pour inspecter un programme plus en profondeur lorsqu’une erreur est détectée.

Les comportements indéfinis, ou Undefined Behavior, sont à la fois un pilier de l’optimisation de code écrits en C par le compilateur, et une belle épine dans le pied des développeurs. Pour résoudre le dilemme performance vs. sûreté d’exécution, c’est encore une fois vers un sanitizer qu’on va se tourner.

Le code source de Firefox ne compile pas correctement à moins qu’on ne lui passe le drapeau -fno-strict-aliasing. Mais quel est donc ce drapeau, pourquoi est-il problématique et comment est-ce qu’un tout jeune sanitizer, nommé type sanitizer, peut-il aider à résoudre le problème ?

Parmi les outils les plus communément cités pour trouver des accès à de la mémoire non initialisée, on trouve bien sûr le vénérable Valgrind, et les très répandus Address et Memory Sanitizer. Et quand on se retrouve à devoir faire un choix entre les deux, plusieurs critères bien trop haut niveau entrent en compte : peut-on recompiler le code ? Quel est le surcoût à l’exécution ? Ces critères sont tout à fait pertinents, voire… raisonnables. Mais être raisonnable, ce n’est pas ce qui va nous intéresser dans cet article. Au contraire, nous allons pousser les outils dans leurs limites et essayer de leur faire adopter des comportements déraisonnables, le tout bien sûr afin de mieux comprendre leur fonctionnement interne.

Comme le rappelle un célèbre proverbe de développeurs : « Il existe deux types de programmeurs C : ceux qui ont déjà corrompu la mémoire, et ceux qui le feront un jour. ». La gestion manuelle de la mémoire est l’un des piliers du langage C, mais aussi probablement l’une de ses plus grandes sources d’erreurs. Cette liberté conduit tôt ou tard à une corruption du tas et à des fuites mémoire. Mais que signifie exactement cette notion de fuite ? Et surtout, comment la détecter, l’analyser et la corriger efficacement ?

J’écris cette introduction de dossier en période hivernale, deux semaines après avoir fait intervenir le chauffagiste sur ma chaudière. On se connaît, il me sait curieux, alors il m’a expliqué le fonctionnement interne de l’appareil, y compris le fonctionnement du capteur de température, équipé d’un réamorçage manuel qui pourrait m’être utile en cas de récidive.