Discussion :

[Taron31]

Bonjour, j'ai fait une DLL que je souhaite protéger de tentative de reversing, de débogage, j'aurais donc deux questions.

La première : j'utilise la plus basique (et la plus simple à bypasser), celle du IsDebuggerPresent, cependant, en reversant la DLL on retrouve très facilement l'utilisation de cette API et une modification "on the fly" du binaire permettrait de bypasser cette protection, j'essaie donc de camoufler l'utilisation de cette API, comme je peux, par exemple j'utilise deja GetProcAddress pour une liaison dynamique avec cette API, pour éviter qu'elle n'apparaisse dans la table IAT, et ensuite je n'utilise pas directement la string "IsDebuggerPresent" en paramètre :

au lieu de procéder ainsi :

Code :

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

procCheckDebugger = (MYPROC_2)GetProcAddress(hKernel32, "IsDebuggerPresent");

j'utilise :

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
__asm {

		push 0x00000074
		push 0x6E657365
		push 0x72507265
		push 0x67677562
		push 0x65447349

		lea eax, [esp]
		push eax

		push hKernel32
		call GetProcAddress
		mov procCheckDebugger, eax

		add esp, 0x14
	}

Je ne sais pas si c'est une solution très efficace, mais j'essaie au mieux de cacher la string "IsDebuggerPresent" passée en paramètre. Mais en utilisant cette seconde solution, la DLL ne fonctionne pas, pourtant je restaure la pile comme il faut, c'est là que j'aurais notamment besoin de vous ...


Seconde question : je pensais également déranger de potentiels débuggueurs en modifiant les DRx, donc en les effaçant, pour cela j'utilise GetThreadContext et SetThreadContext.. mais à quel moment "privilégié" je pourrais effacer ces registres de deug DRx ?? parce que le but est d'empêcher au debugger de placer des breakpoints, donc à quel moment effacer les DRx ??

J'attends de vos lumières, merci.

[Médinoc]

À mon avis, un API Hook sur IsDebuggerPresent reste capable de détecter toute utilisation de la fonction. Ou bien, le debugger peut sûrement aussi hooker le chargement de kernel32.dll et trifouiller sa table d'exportation pour rediriger vers sa propre version de IsDebuggerPresent() (ou patcher la fonction en mémoire)...

Pour la seconde question, je ne sais pas ce que tu appelles les DRx...

[Taron31]

Salut, concernant IsDebuggerPresent, je souhaite seulement dissimulmer un peu son utilisation, c'est pour cela que j'ai testé le code asm et qui ne fonctionne pas; ensuite les DRx sont les registres de debug.

Merci.

[Neitsa]

Bonjour,

IsDebuggerPresent ne comporte que trois ligne d'asm, tu peux les utiliser plutôt que d'appeler la fonction :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
BOOL CheckDebugger(void)
{
     BOOL IsDebugged = FALSE;
 
     __asm{
     MOV EAX,DWORD PTR FS:[18] ; pointeur sur TEB
     MOV EAX,DWORD PTR DS:[EAX+30]; pointeur sur PEB
     MOVZX EAX,BYTE PTR DS:[EAX+2] ; IsDebugged ?
     MOV IsDebugged, EAX;
     }

     return IsDebugged; /*TRUE si debug, FALSE autrement*/
}

En ce qui concerne les Drx, ils sont locaux à chaque CONTEXT de thread. Comme on ne peut pas obtenir le Context du thread qui appelle Get/SetThreadContext() il faut créer un thread secondaire qui se chargera de vérifier le context d'un autre thread car le thread dont on doit retrouver le CONTEXT doit expressément être suspendu.
Si ce thread est le thread principale (généralement le thread responsable de l'UI), ça oblige à bloquer l'UI pendant la vérification des Drx.

Ceci dit, la vérification du booléen IsDebugged du PEB et la vérification des Drx sont des "tricks" très connus des déplombeurs...