mercredi 13 août 2008

Holidays, sometimes holidays...

Genre tu laches ton PaiCai ?!

Bon en fait pas vraiment, mais (pour une fois) je vais raconter ma vie : je pars au Canada dans 7 jours pour une année : ca va être hallluucccccinant ! Mais le temps que je m'installe, que je règle tous les problèmes qui vont très certainement arriver... Bref, avant que je puisse rebosser tranquillement sur mes petits projets, un bon mois va se passer. Donc l'activité de ce bl0g sera réduite.

Pour pas te laisser sur ta faim cher lecteur, je te livre quand même un petit source, il s'agit d'un dumper d'IAT, tu lui donnes le PID de ton process cible et il va t'afficher l'Import Address Table du module exécutable du process. Rien de c00l, mais ça peut facilement se modifier pour faire du hook d'IAT. Sinon, je commence à me lancer sur des outils un peu plus complexes, et j'essaye de me diversifier en étudiant quelques applis par ci par là, so see you soon ;)

mercredi 6 août 2008

Cachez ce module que je ne saurai voir...

Putin qu'est ce qu'il fait chaud...

L'affichage des modules chargés par un processus ( les DLLs kwa !) de façon fiable est un problème qui se pose rapidement quand on commence à foutre le dawa dans la mémoire.

Il y a deux méthodes fort connues basées sur des fonctions documentées par Microsoft...

1- Cheese !

La première façon c'est d'utiliser CreateToolhelp32Snapshot() avec TH32CS_SNAPMODULE en premier argument, ça nous retourne un HANDLE sur un snapshot ( une "image" à un instant t de la mémoire, dans notre cas des modules ) et il suffit de se promener à partir de ce HANDLE avec la fonction Module32Next() pour récupérer une structure MODULEENTRY32 qui donne le nom de chaque module, son adresse de base, son chemin...

Le code source du bouzin est ici, j'ai aussi utilisé cette API pour lister les threads d'un process ( même méthode sauf qu'on parcourt des THREADENTRY32 ce coup ci).

2- EnumProcessModules()

La deuxième f0cking way de lister les modules c'est d'utiliser une fonction qui porte bien son nom : EnumProcessModules()... Ca nous remplit un tableau avec des HANDLEs sur tous les modules chargés en mémoire pour un processus donné, ensuite on récupère les infos intéressantes avec les fonctions GetModuleBaseName(), GetModuleFileNameEx() et GetModuleInformation().

Le code source du bouzin est , rien de bien particulier à dire.

3- Euh oué... et alors ?

Là cher lecteur t'a envie de me dire "Chapi chapo jojo, t'a réussi à utiliser des fonctions documentés pour faire exactement la même chose de deux manières différentes, putin tu roxsamere". Oui mais c'est là que ça devient intéressant...

Si on s'interesse à la structure du Process Executiv Block (celle qui "décrit" un processus en user-land), son troisième champ est :

PEB_LDR_DATA * LdrData;

Et la structure PEB_LDR_DATA contient (entre autre) :

...
LIST_ENTRY InLoadOrderModuleList;
LIST_ENTRY InMemoryOrderModuleList;
LIST_ENTRY InInitializationOrderModuleList;
...

C'est à dire le point de départ vers trois listes doublement chainées ( la structure LIST_ENTRY n'est constituée que deux pointeurs, l'un vers "l'avant", l'autre vers "l'arrière" ) qui vont liées entre elles des structures LDR_DATA_ENTRY décrivant les modules chargées en mémoire dans trois ordres différents...

Cette structure contient la suite du chainage dans ses trois premiers champs :

LIST_ENTRY InLoadOrderModuleList;
LIST_ENTRY InMemoryOrderModuleList;
LIST_ENTRY InInitializationOrderModuleList;


Tout ceci est décrit très brièvement, car même si ce n'est pas documenté officiellement tu trouvera facilement toutes les infos sur ces structures dans l'internet multimédia ( par exemple dans le post de lilxam sur nibbles ).

Ce qui est intéressant c'est que tout ça c'est dans l'user-land, alors bien sûr la première idée qui up dans ton mind c'est de modifier ces listes chainées, pour "cacher" ton module favoris dans un processus cible.

Et tu as raison, car c'est facile à faire :

On trouve l'adresse du PEB du processus cible en créant un thread distant sur la routine RtlGetCurrentPeb() et on récupère sa valeur de retour (l'adresse du PEB) avec un GetExitCodeThread().

On trouve ensuite l'adresse du premier module dans le champ LdrData, puis on démarre un parcours sur les LDR_DATA_ENTRY, quand on trouve le module qui nous intéresse, on l'enlève du chainage. Pour cela, c'est simplement de l'unlinkage dans une liste doublement chainée : on fait pointer le "pointeur avant" (Flink) du module précédent vers le module suivant, et le "pointeur arrière" (Blink) du module suivant vers le module précédent ( tu me suis ?). Par exemple, pour la InLoadOrderModuleList, ça donne :


/* Modifie Flink du module précédent (=Blink du module courant) pour le faire pointer sur le module suivant (=Flink du module courant) */
WriteProcessMemory(targetProcess,
module.InLoadOrderModuleList.Blink,
&module.InLoadOrderModuleList.Flink,
4,
NULL);

/* Modifie Blink du module suivant (=Flink du module courant + 4) pour le faire pointer sur le module précédent (=Blink du module courant) */
WriteProcessMemory(targetProcess,
module.InLoadOrderModuleList.Flink+4,
&module.InLoadOrderModuleList.Blink,
4,
NULL);

Faut pas oublier qu'on est dans un process distant, donc un autre espace mémoire, d'où le WriteProcesMemory(). Et là où ca pwne, c'est que si après cet unlinkage je lance mon premier programme de listings ( celui avec
CreateToolhelp32Snapshot()), mon module n'apparait plus !!

Par contre, le EnumProcessModules() fonctionne toujours.. si on était un peu naïf on pourrait se dire que cette API utilise une façon "sûre" de lister les modules avec des techniques de jedi inside the kernel, et là on commence à s'exciter sur une way de la bypasser...

...Et puis on se rapelle qu'il y a deux autres listes doublement chainées sur les modules : InMemoryOrderModuleList et InInitializationOrderModuleList. Alors on fait le même unlinkage et on s'aperçoit que
EnumProcessModules() utilise la InMemoryOrderModuleList, et qu'il est donc aussi facilement pwnable...

Ca nous donne un "cacheur" de modules que vous trouverez ici, vous lui filez un PID et un nom de module ( du type ntdll.dll kwa ) et il n'apparaitra plus lorsqu'on utilise les APIs sus-nommées.

C'est bien sûr pas la technique du siècle, il suffit de checker le dump mémoire pour voir les modules mais ce qui est rigolo c'est que par exemple ProcessExplorer utilise ces APIs pour lister les modules d'un process et donc on le pwn sans aucun souci, ça invite à être prudent sur les infos fournies par ce genre d'outils :-)

lundi 4 août 2008

Je sais que tu m'observes.

Et kéketufais toi ?

Toujours dans mes histoires de debuggeur, j'ai tenté d'améliorer la "non-intrusivité" du code que j'avais présenté dans ce post. Je me suis donc intéressé aux diverses techniques qui permettent à un processus de détecter qu'il est sous la surveillance d'un débuggeur, c'est classique mais ça mange pas de pain au nutella de le faire.

Pour cela, j'ai fait un développement en parallèle : à ma gauche... venu tout droit de sa contrée lointaine de l'user-land... le programme dontTryToDebugMe qui va faire appel à différentes techniques ninja pour checker la présence d'un débuggeur, et à ma droite... le JoE d3bugg3ur qui va tenter l'entourloupe de débugger son adversaire sans se faire repérer. La tension est à son comble, la foule est en délire... Avant de débuter ce qui sera sûrement un très grand match, rappelons que la principale contrainte est que je reste en user-land et que j'implémente les checks de la présence d'un débuggeur comme de simples appels de fonctions, c'est pas forcément très réaliste (pour certains d'entre eux) mais ça permet de se faire une bonne idée de leur fonctionnement.

1-PEB!IsDebugged et kernel32!IsDebuggerPresent


La première vérification de la présence d'un débuggeur peut se faire dans la structure Process Executive Block ( accessible en user-land et décrivant le process ). Si on la dump on trouve au troisième octet un champ nommé "IsDebugged" et qui (sans surprise) sera mis à 1 par le système si le process est débuggé ( y compris quand c'est par DebugActiveProcess() ). De plus, la fonction IsDebuggerPresent() va lire directement ce champ. Donc notre programme dontTryToDebugMe va faire un appel à la fonction sus-nommée et aussi checker directement la valeur de ce champ en récupérant l'adresse du PEB avec l'API RtlGetCurrentPeb() (histoire d'éviter les hooks sur IsDebuggerPresent()).
Ce double-check on the byte ne pose aucune problème a être éviter, il suffit bien entendu d'aller modifier en dur le champ avant que la cible n'ait pu le checker ( ce qui se fait sans souci, j'y reviens de suite ).

2- PEB!NtGlobalFlags and Heap Flags

La deuxième protection se trouve également en partie dans le Process Executiv Block. Elle se site au niveau du champ NtGlobalFlags qui va contenir des valeurs indiquant au programme comment gérer son tas ( cette gestion étant différente suivant que le process est débuggé ou non ). Après quelques tests, on se convainc assez facilement que ce champ prend la valeur 0x70 si le process est sous le contrôle d'un débuggeur. Il suffit alors de checker la valeur de ce champ, mais encore une fois le débuggeur n'a qu'a modifier la valeur pour y mettre 0x0 ( valeur de base ) avant que sa cible n'ait pu vérifier le champ.

Mais modifier en dur le PEB ne suffit pas en ce qui concerne le tas qui possède un comportement vraiment différent suivant que le process a été créé en mode debug ou non ( flags dans la structure de management du tas qui permettent aussi de checker le débuggage, taille des chunks différente..). Bref comme dirait l'ami zantrop "c'est le bowdel", et y a une solution qui permet de tout résoudre d'un coup : ne pas créer le process en mode debug et utiliser le mode non intrusif ( la boucle infinie à la place de l'EP et tout le bouzin, je te renvoie à ce post ), ce qui nous permet de bypasser tous les checks sur le tas !

Ca a aussi comme avantage qu'on maitrise le moment où notre cible commence à exécuter son code ( puisqu'on on le fait boucler sur son EP ) et donc on peut tranquillement modifier les champs du PEB avant de le laisser le process cible continuer et faire ses vérifications.

3- ntdll!NtQueryInformationProcess et kernel32!CheckRemoteDebuggerPresent

Plus profondément cachée, la fonction NtQueryInformationProcess() permet de récupérer tout un tas d'infos sur un processus. C'est un simple wrapper vers ZwQueryInformationProcess() qui débouche sur un appel système. Son prototype est :
NTSTATUS WINAPI NtQueryInformationProcess(
__in HANDLE ProcessHandle,
__in PROCESSINFOCLASS ProcessInformationClass,
__out PVOID ProcessInformation,
__in ULONG ProcessInformationLength,
__out_opt PULONG ReturnLength
);
En fixant la valeur de l'argument ProcessInformationClass, on indique quels types d'info on veut regarder. Ces informations "résultantes" seront placés dans le buffer pointé par ProcessInformation (3eme argument). Ce qui nous intéresse c'est que en mettant 7 en ProcessInformationClass, la fonction nous retourne "a DWORD_PTR value that is the port number of the debugger for the process. A nonzero value indicates that the process is being run under the control of a ring 3 debugger." C'est easy donc, il suffit pour dontTryToDebugMe d'appeler cette fonction et de checker la nullité de ProcessInformation :-D
Pour l'appel, la doc nous indique comment faire : "This function has no associated import library. You must use the LoadLibrary and GetProcAddress functions to dynamically link to Ntdll.dll."

Maintenant pour notre debuggeur user-land il faut réagir, la fonction étant appelé directement par son addresse, je ne vois qu'une seule manière de ne pas se faire repérer : il faut la hooker "in-line", c'est à dire modifier directement son code.

Notre objectif est simple : dans le cas où cette fonction est appelé avec 7 en ProcessInformationClass, on doit mettre 0 dans le ProcessInformation pour ne pas être repéré. De plus, comme la fonction NtQueryInformationProcess() est souvent appelée pour tout un tas de trucs (c'est précis comme description, hein ?), on doit modifier son résultat seulement dans le cas qui nous intéresse et la laisser s'exécuter normalement dans les autres, sinon on va foutre un bon gros bordel.

Donc pour le hook, je vais mettre en place à l'adresse de NtQueryInformationProcess() un jump vers un shellcode que j'aurai placé en mémoire qui me permettra de gérer tranquillement la fonction. Pour celà je regarde d'abord la geule du code au début de cette fameuse fonction (en fait ZwQueryInformationProcess(), mais on va les confondre :-) :

MOV EAX,9A
MOV EDX,7FFE0300
CALL DWORD PTR DS:[EDX]
RETN 14

Il s'agit d'un classique appel système, donc c'est là que je dois intervenir et mettre mon JMP vers un shellcode qui va tout pwned. Mon loader que je vais mettre à cet endroit aura la tête suivante :

MOV EAX,0xFAFAFEFE
JMP EAX

Où 0xFAFAFEFE est l'adresse où se trouve le shellcode et qui sera patché au moment de l'exécution.
Ce loader va ainsi écraser les deux premières instructions de NtQueryInformationProcess() en laissant trois opcodes inutilisés (rappelle toi en pour la suite cher lecteur), il me faudra donc les rétablir dans les cas où je veux laisser la fonction s'exécuter normalement.

Maintenant intéressons nous au shellcode, gardons à l'esprit que viennent d'être mis en place dans la pile les arguments de NtQueryInformationProcess():

//Est ce que ProcessInformationClass == 7 ?
CMP DWORD PTR SS:[ESP+8],7

// Si c'est pas le cas, on ne dois pas intervenir
JNZ SHORT Normal

// Time to hook !
MOV EAX,0 // on met en place la valeur de retour
MOV EDX,DWORD PTR SS:[ESP+C]
MOV DWORD PTR SS:[EDX],0 // on met 0 dans la valeur résultat => check pwned !
CMP DWORD PTR DS:[ESP+14],0 // on teste si ReturnLength est NULL
JE SHORT FinDuHook // si c'est le cas, on n'a pas à la modifier
MOV EDX,DWORD PTR SS:[ESP+14]
MOV DWORD PTR SS:[EDX],4 // on met 4 dans ReturnLength

FinDuHook:
RETN 14

Normal: // ici on doit rediriger vers le flux normal d'exécution
MOV EAX,9A // rétablissement des deux premières instructions que le
MOV EDX,7FFE0300 // loader a écrasé
PUSH EBX // sauvegarde de EBX qui sera utilisé pour le JMP suivant
MOV EBX,NTDLL.7C91D7E9
JMP EBX // reprendre le cours normal de la fonction ( appel système )

Quelques remarques :

1- D'après la doc "The function returns an NTSTATUS success or error code." et on se convainc assez facilement que 0 est le code de succès, donc à mettre dans EAX :-)

2- Dans le cas du hook, il ne faut pas oublier de positionner ReturnLength (5ème argument c'est à dire ESP+14) à 4 car d'après la doc, c'est "A pointer to a variable in which the function returns the size of the requested information." et donc, même si il est optionnel, on pourrait imaginer que dontTryToDebugMe l'utilise et teste la valeur retournée pour voir qu'elle n'est pas nulle (dans le cas d'un test de debug on retourne un DWORD_PTR donc c'est 4 bytes ). D'ailleurs c'est ce qu'il fait le petit salopio.

3- Dans le cas où on ne veut rediriger vers le flux normal d'exécution, y a pas de mystères, on exécute les deux instructions que le loader a écrasé et on saute sur l'adresse hardcodé qui était l'instruction suivante ( que j'apellerai instruction Y pour la suite de ce merdier ). En fait, comme pour ce JMP j'utilise EBX, je vais d'abord le sauvegarder sur la pile et je vais mettre juste avant l'instruction Y un POP EBX pour rétablir la valeur de ce registre et m'éviter de faire foirer le programme qui s'attend à trouver une "certaine" valeur dedans :-) Et tout ça tombe très bien puisque j'avais de la place à la fin de mon loader ( 3 opcodes précisément, rapelle toi ! ). Bon bien sûr c'est pas beau caca d'avoir hardcodé cette adresse, on pourrait tout à fait la patcher à l'éxecution puisqu'elle est située à distance fixe du début de NtQueryInformationProcess(). Mais j'avais la flemme, donc c'est l'adresse "kivabien" pour XP SP3.

Là où c'est tout bon c'est que en hookant cette fonction, on pwne aussi CheckRemoteDebuggerPresent() qui l'utilise :-)

4- La MSDN c'est plus fort que toi...

Si on s'intéresse un peu à la doc sur les exceptions dans la MSDN, on trouve la fonction suivante :

BOOL CheckForDebugger()
{
__try
{
DebugBreak();
}
__except(GetExceptionCode() == EXCEPTION_BREAKPOINT ?
EXCEPTION_EXECUTE_HANDLER : EXCEPTION_CONTINUE_SEARCH)
{
// No debugger is attached, so return FALSE
// and continue.
return FALSE;
}
return TRUE;
}
Rien de bien folichon, on déclenche une breakpoint exception dans le process appelant ( donc dontTryToDebugMe dans notre cas ), et on regarde si effectivement cette exception s'est produite ( par l'appel à GetExceptionCode() ), si ce n'est pas le cas ça veut dire qu'elle a été "catché" par un débuggeur. Pour bypasser ça, il suffit de faire en sorte que le débuggeur ne gère pas la breakpoint exception et la laisse arriver jusqu'au process debuggé, cela se règle dans la fonction ContinueDebugEvent() en mettant le troisième argument à DBG_EXCEPTION_NOT_HANDLED, ce qui laisse le programme responsable de l'exception la traiter ( et la détecter :-).
En pratique ça veut dire que toutes les breakpoints exceptions doivent pouvoir être gérés par le programme cible, ce qui posera sans doute des problèmes quand il s'agit d'exceptions "non-naturelles" (mises en place par le débuggeur), mais dans mon cas, mon but étant plutôt de tracer le comportement du programme de façon furtive ça n'a pas de conséquences.

5- debug me !

Pour l'instant le JoE d3bugg3r s'en sort bien, tous les checks d'avant sont assez facilement bypassables... C'est maintenant que les choses se compliquent :-)

Un autre trick consiste à se débugger soit même : on créé un nouveau processus et on lui fait appeler DebugActiveProcess() sur son processus parent, dans le cas où il on a déjà un débuggeur sur le dos, l'appel de cette fonction va échouer et hop, débuggeur spooted !

En pratique j'ai implémenté ça dans dontTryToDebugMe par une création d'un process "classique" ( = notepad.exe, pour être le plus "portable" possible ) dans lequel je vais créer un thread distant. Mais on ne peut pas juste lui faire exécuter DebugActiveProcess() car on va prendre dans la geule le comportement par défaut de cette fonction qui est "Exiting the debugger also exits the process unless you use the DebugSetProcessKillOnExit() function." c'est à dire que lorsque notre thread distant va terminer, il va tuer dontTryToDebugMe...
Donc il faut travailler un peu plus et se faire un petit shellcode qui va nous faire l'appel à DebugSetProcessKillOnExit() pour changer le comportement par défaut lors de la fin du thread distant.
En pratique, ca ressemble à ça :

push 0xFAFAFEFE // the PID of the process to debug
mov edx,kernel32.DebugActiveProcess
call edx
test eax,eax
jz fin // if it works we dont jump
mov edx,kernel32.DebugSetProcessKillOnEx
push 0
call edx

fin:
retn

0xFAFAFEFE est le PID de dontTryToDebugMe que je patche à l'exécution avant de copier le shellcode dans le process distant ( pas oublier de le faire en little-endian :). Il faut aussi éviter de faire l'appel à DebugSetProcessKillOnEx() dans le cas où DebugActiveProcess() à échoué car la valeur de retour de notre shellcode ( celle qui nous permet de dire si ça a marché ou pas ) sera celle du dernier appel, donc de DebugSetProcessKillOnEx() et cette fonction semble "marcher" même si DebugActiveProcess() a échoué.

Une fois le shellcode patché, on l'écrit dans notre process notepad.exe, on le fait s'exécuter en créant un thread à son adresse avec CreateRemoteThread() et on récupère la valeur de retour avec GetExitCodeThread()... Si c'est 0 ça veut dire que ça a échoué donc qu'un débuggeur est là :-)

Pour bypasser ça, c'est la galère... le débuggeur ne controlant pas la création du processus "fils" notepad.exe, il ne peut pas venir hooker à temps DebugActiveProcess() dans celui-ci. Et même si on y arrivait (= l'appel à DebugActiveProcess() "marcherait" tout le temps) dontTryToDebugMe pourrait venir vérifier qu'on reçoit effectivement les exceptions ( par exemple celle de création du process qui est toujours reçue en premier ).

6- Tic tac, tic tac...

Une technique bien connue consiste à utiliser les différents compteurs que le système maintient à jour : l'idée consiste simplement à remarquer que certaines opérations prennent beaucoup plus de temps selon qu'un débuggeur est présent ou non. Quel genre d'opérations ? Sur le net on trouve pas mal d'exemples avec de simples boucles sur des printf(). Perso j'ai aucune différences, les printfs prennent autant de temps que le débuggeur soit là ou pas (ce qui semble assez logique, l'affichage d'une chaine par le biais d'un printf() n'est pas un évènement de débug, non?)... Il faut donc mieux utiliser une opération véritablement couteuse dans le cas d'un débuggage, par exemple OutputDebugString() :-)

Le code qu'on met dans dontTryToDebugMe est donc du genre :

firstTick=GetTickCount();

for(loop=0;loop<10000;loop++)
{
OutputDebugString("MDR");
}

secondTick=GetTickCount();

if(secondTick-firstTick > NORMAL_TIME_COUNT)
{
// too long, debugger spooted xD
}
else
{
// no debugger
}

NORMAL_TIME_COUNT est une constante définie à partir de mesures des exécutions sans débuggeur ! Dans mon cas j'ai utilisé GetTickCount() mais on peut aussi faire avec QueryPerformanceCounter()...

Là encore pour le bypasser, c'est pas du gateau mon salop : on pourrait hooker GetTickCount() et lui faire retourner une valeur constante ( dans ce cas là le test secondTick-firstTick>NORMAL_TIME_COUNT serait toujours faux..) mais il suffit de modifier le test de notre précédent code et de mettre : if((secondTick-firstTick>NORMAL_TIME_COUNT)
||(secondTick==firstTick))

et on détecte le hook :)


7- C'est cadeau !

Pour terminer ce tour non-exhaustif, une technique un peu plus aggressive...

A force de m'attacher à des process pour essayer de leur démonter la tête, j'ai finis par m'apercevoir ( bien ouerj oeil de lynx ) que tous les débuggeurs ring3 ( que ça soit OllyDbg ou le JoE d3bugg3r ) créent un nouveau thread dès qu'ils s'attachent et que ce nouveau thread démarre toujours sur la fonction DbgUiRemoteBreakIn() dont le code est de la forme suivante :

VOID
NTAPI
DbgUiRemoteBreakin(VOID)
{
/* Make sure a debugger is enabled; if so, breakpoint */
if (NtCurrentPeb()->BeingDebugged) DbgBreakPoint();
/* Exit the thread */
RtlExitUserThread(STATUS_SUCCESS);
}

Mais le code n'est pas le plus important, ce qui rox, c'est que cette fonction soit toujours appelée au moment de l'attachement, pour empêcher un débuggeur de s'attacher, il nous suffit de remplacer le code de cette API par un code qui va l'emmerder ! Pour faire simple, dontTryToDebugMe va écrire un appel à TerminateProcess() à l'emplacement de cette fonction, et ainsi quand le débuggeur s'attache au process, BAM il se termine.

La parade est simple, il suffit au débuggeur de repatcher à chaud le code de cette API avant de s'y attacher. Bon, a noter que dans notre cas j'ai même pas eu besoin de le faire puisque le JoE d3bugg3r s'attache au moment où la cible est à son EP, donc elle n'a pas pu encore patché son DbgUiRemoteBreakin(). Disons que cette protection est utile pour empêcher l'attachement à un process en cours, ou alors il faudrait utiliser un version modifiée de la DLL qui contient cette fonction (ntdll) mais là j'imagine qu'on touche du doigt des domaines un peu plus compliqué ( packers ? ) et j'en suis pas encore là :-)

A noter un effet de bord intéressant : ce fameux DbgUiRemoteBreakin() explique l'exception qui est toujours levé lorsqu'on commence de débugger un process en mode non intrusif ( il y en a aussi une en mode intrusif mais cela ne nous regarde pas ;). J'avais pris en compte ce fait en laissant toujours de côté la première exception dans le code de mon débuggeur, mais là on s'aperçoit que si on modifie le byte IsDebugged du PEB, l'exception ne sera plus levée, donc la première exception qu'on cathera sera une "vraie", à prendre en compte donc :)

Pour conclure, on peut remarquer que dans les conditions dans lesquelles je me suis plaçé ( c'est à dire en avantageant le débuggeur en lui laissant la main en premier ), il est facile de bypasser les APIs fournie par Microsoft ( IsDebuggerPresent(), CheckRemoteDebugger() ), mais d'un autre côté il y a d'autres checks très faciles à mettre en place ( le self-debug ou les timers ) qui semblent difficiles (impossibles?) à pwned... Donc le JoE d3bugg3r a perdu, mais il reviendra, plus fort, plus beau :D

Je suis bien sûr loin d'avoir étudier tous les anti-debug ( j'en ai même laisser certains importants de côté ), je me suis cantonné à des techniques "non-agressive" (ormis la dernière, mais c'est du caca celle là), je continuerai ce travail d'ici peu de temps pour voir où ça mène ;-)

Le code du debuggeur se trouve ici, le mode non-intrusif implémente tous les anti-anti-debug que j'ai décrit au dessus. Le code source de dontTryToDebugMe est ainsi que le binaire compilé sous XP SP3 ici ( vous pouvez checker votre débuggeur maison, voir si il fait mieux que moi :p ).

Coté bibliographie je me suis en grande partie basé sur l'article référence de N. Fallière que vous pouvez trouver ici.