Programmez N°117 mars 2009

Programmez N°117 mars 2009

Il est toujours utile d’avoir plusieurs outils à sa disposition pour résoudre un problème.
Lorsqu’on est développeur, on se rend souvent compte que des techniques non-
traditionnelles peuvent être efficaces dans des cas particuliers. Cet article à pour but de
présenter différentes méthodes qui sont utilisées dans le monde de la sécurité
informatique et qui s’appliquent potentiellement au développement traditionnel.
Quand on parlera de " hack " dans cet article, il s’agira de
techniques non-standard, c'est-à-dire qu’on ne trouve ni
dans les manuels ni dans les bonnes pratiques de code. En
aucun cas nous ne parlerons de méthodes malveillantes qui visent à
corrompre un système.
Cet article sera surtout orienté développement sous Windows,
allant aussi bien de Windows 2000 jusqu'à Windows 7 en englo-
bant bien sûr les architectures x86 et x64. Il faut bien comprendre
que tout ce que nous allons évoquer ici peut se porter sur d’autres
systèmes, même si les outils et les termes sont différents, au final
les systèmes se ressemblent beaucoup. Les Linux-addicted
devraient être donc en mesure de suivre cet article :]. Celui-ci
s’oriente plus vers des développeurs d’applications compilées, celles
qui sont interprétées par le CPU (comme des programmes codés
en C ou C++. Les personnes développant dans des langages néces-
sitant une machine virtuelle ou un interpréteur (Java ou .Net ou
encore les langages de scripts tel que Python et Ruby) ne trouveront
peut être pas forcément leur bonheur.
Pourquoi hacker son code ?
On peut se demander quel est l’intérêt de maîtriser des méthodes
obscures provenant du monde du " hack ". Il arrive parfois qu’on se
retrouve dans une situation bloquante, que la documentation ne pré-
voit pas. Une recherche sur le net n’aboutit pas toujours : le problè-
me étant trop simple à décrire, nous nous retrouvons noyés dans
les résultats, ou alors le problème est trop pointu pour obtenir des
résultats. Même si on dit souvent que Google est votre ami, il est
toujours plus rapide et pratique d’être capable d’identifier rapide-
ment la source précise du problème par nous-même.
Malheureusement il s’agit souvent de faire du debugging de code ou
bien d’utiliser des outils qu’on ne connaît pas, donc rien d’évident à
première vue.
Nombreux sont ceux qui ont passé des heures à debugger un code
à la main sans comprendre précisément ce qui se passait derrière.
Souvent parce qu’au delà du code et du binaire créé, existent des
fonctionnalités du système que la documentation n’explique pas,
mais qui interfèrent avec. L’idée de cet article est là : comprendre et
connaître les méthodes employées par des programmes malicieux
qui s’insèrent profondément dans le système afin de mieux les utili-
ser pour développer et debugger nos applications. Il s’agit aussi
bien de techniques de code, que de manipulations de propriétés sys-
tèmes souvent cachées.
On peut aussi introduire la notion de sécurité, en effet savoir coder
proprement c’est le faire de manière simple et sécurisée. Il faut
donc être conscient des risques potentiels que peuvent comporter
notre application. Dans ce cas, connaître les différentes failles et
techniques mises en place par les hackers pour les exploiter, pour nous permettre d’éviter de reproduire ces erreurs. Bien évidem-
ment, il s’agit là d’abord de best-practices que l’on trouve dans les
livres sur la programmation orientée sécurité ; mais c’est aussi un
travail de veille car les techniques de protections et d’exploitations
des systèmes évoluent constamment.
RTFM !
Un des principes de base que l’on oublie trop souvent, est de lire la
doc ! On ne le dira jamais assez. Mais avant de commencer à
émettre des hypothèses sur le mauvais fonctionnement du système
il faut d’abord remettre en cause ce que l’on a fait.
Cela implique de bien comprendre ce qu’on à écrit et parfois, ce
n’est pas évident, et cela parce que l’on fait appel à des fonctions
extérieures. Dès qu’intervient l’utilisation de fonctions extérieures il
faut tenir compte de la doc. Sous Windows, il existe la MSDN [1] qui
est très bien faite. Prenons un exemple avec le code suivant