Discussion :

[sloshy]

Bonsoir,
Voila pour un projet scolaire, j'ai du coder deux injecteurs de code dans des processus, l'un injecte une dll et le second injecte directement un shellcode.

Aucun soucis a ce niveau, ca fonctionne niquel chrome, mais une fois presente au prof, celui ci me dis que le second injecteur (ou j'injecte un shellcode donc) n'est pas bon, je dois trouver une autre maniere d'injecter du code dans le processus, sans passer par une etape de creation de shellcode, il m'a conseille de me renseigner sur le PIC, je l'ai fait mais j'avoue ne pas vraiment comprendre son attente.

Je lui ai fait pars de mon incomprehention mais il semblerait qu'il en reste a cette simple explication et que je doive me debrouiller.

auriez vous des information sur le sujet pour moi?

[Melem]

Moi non plus je n'injecterais pas du shellcode mais directement une fonction :

Code c :

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

1
2
3
4
5
6
7
8
9
10
DWORD WINAPI Func(LPVOID lpParams)
{
    MessageBox(NULL, TEXT("Injection réussie"), TEXT("Func"), 0);
    return 0;
}
 
DWORD WINAPI MarquageFin(LPVOID lpParams)
{
    return 0;
}

Code c :

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

1
2
3
4
/* Déterminons "sizeof(Func)", qui ne peut justement pas être déterminé à l'aide de sizeof ... */
SizeofFunc = abs((char *)MarquageFin - (char *)Func); /* J'ai mis abs car je ne suis pas sûr sur le coup que MarquageFin apparait bien en mémoire après Func. */
/* Injecter Func */
InjecterCode(hProcess, (char *)Func, SizeofFunc);

[sloshy]

Peux tu detailler un peu?
J'ai bien compris le code, pas ce qui se passe derriere.

[Neitsa]

Hello,

le problème principal est que sous Windows, on ne peut pas injecter du code qui appel des fonctions (ou fait référence à des données) sans le rendre "position independant".

Pour reprendre un exemple semblable à celui de Melem, une fois compilé:

Code :

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

1
2
3
4
5
6
7
8
CPU Disasm
Address   Command                                  Comments
00F61000  PUSH 0                                   ; /Type = MB_OK|MB_DEFBUTTON1|MB_APPLMODAL
00F61002  PUSH OFFSET Test.00F620F4                ; |Caption = "caption"
00F61007  PUSH OFFSET Test.00F620FC                ; |Text = "text"
00F6100C  PUSH 0                                   ; |hOwner = NULL
00F6100E  CALL DWORD PTR DS:[0F620A4] ; \USER32.MessageBoxA

Les deux chaînes de caractères (text & caption) et le CALL vers MessageBoxA sont dépendant du binaire dans lequel ils sont compilés.

Les chaînes parce qu'elles référencent la section .data, à un endroit précis (celui où se trouve les chaînes), l'appel vers MessageBoxA parce qu'il fait référence à la table d'import du binaire dans lequel l'appel est fait (0xF620A4 pointe vers MessageBoxA dans user32.dll).

Dans le contexte d'un autre processus, les adresses utilisées ici ne veulent plus rien dire.

Pour rendre du code indépendant, il faut se substituer au loader de Windows et résoudre les appels soit mêmes, il n'y a pas d'autres solutions. Les shellcodes utilisent tous la même chose:

- Résolution de l'adresse de base de kernel32
- Parsing de la table d'export de kernel32 pour trouver LoadLibrary() et GetProcAddress(). A partir de là on dispose de deux pointeurs de fonctions.
- Chargement des DLLs via le pointeur de LoadLibrary(). Dans notre exemple, on chargerait user32.dll
- On obtient les pointeurs de fonctions via GetProcAddress(). Dans notre exemple, après avoir obtenu le pointeur sur la base du module user32.dll (HINSTANCE), on récupère le pointeur de MessageBoxA() via GetProcAddress().
- Appel de la fonction. Les arguments (c-a-d les chaînes dans notre exemple) seront dans l'espace d'adressage du processus courant. Généralement on pousse les chaînes sur la pile et on obtient un pointeur sur la pile, vers la/les chaîne(s).

On peut théoriquement se passer de GetProcAddress () qui ne fait que du parsing de l'export table de la DLL chargée, mais ça prend beaucoup moins de place, pour un shellcode d'appeler directement cette fonction. Par contre on ne peut pas se passer de LoadLibrary() sauf si la DLL est déjà chargée dans l'espace d'adressage du processus (on peut alors parser des structures internes de Windows pour retrouver les adresses de base des DLLs chargées).

Sous x86 (x86-64) il n'existe pas non plus d'instruction permettant d'avoir le program counter (EIP/RIP) type "MOV R32, EIP", mais il existe des palliatifs basés sur les calculs d'offsets notamment.

Les shellcodes sous linux (ou systèmes héritant d'unix) sont plus courts grâce aux syscalls qui ne changent pas entre les différentes releases des systèmes ou des noyaux, même majeures. Sous Windows les syscalls existent aussi (via une interruption (INT 0x2E ou par SYSENTER) mais sont différents pour chaque release majeure du noyau, d'où la non portabilité de tels shellcodes.

Une autre solution sous Windows (nettement moins pratique, donc uniquement théorique) est "d'épier" (à grand coup de ReadProcessMemory) le processus à injecter pour résoudre les pointeurs avant injection. C'est tellement peu pratique que ça reste purement théorique.

Ceci dit les shellcodes Windows couramment utilisés (par exemple: command execute, bind, reverse connect, etc.) sont tous des shellcodes PIC par essence. Je ne vois pas vraiment où voulait en venir ton prof sur ce coup là...

[sloshy]

Bonsoir,
C'est toujours un plaisir de te lire.
J'ai lu une partie de tutoriel de toi, datant de 2004 sur le sujet ou tu expliquait comment cree sa propre routine d'import

Si j'ai bien tout compris, le code de melem ne sera pas bon?
Il me semble avoir lu (attention a la grosse betise et au gros amalgame qui vont sortir) que kernel32.dll (ou ntdll.dll je ne sais plus) se chargeait toujours a la meme adresse virtuelle, du coup les appels de fonction reste correcte non?

[Neitsa]

Hello,

Si j'ai bien tout compris, le code de melem ne sera pas bon?

Oui c'est bien cela. Je vais essayer de développer sur le pourquoi ça ne peut pas fonctionner en l'état.

Il faut bien comprendre que lorsqu'un programme appel une fonction (si celle ci n'est pas incluse dans le binaire (inline ou statique) et c'est le cas des fonctions du système), il n'appelle pas "directement" la fonction, mais passe d'abord par sa table d'import.

Je prendre l'exemple de code assembleur sur MessageBoxA:

Code :

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

1
2
3
4
5
6
7
8
CPU Disasm
Address   Command                                  Comments
00F61000  PUSH 0                                   ; /Type = MB_OK|MB_DEFBUTTON1|MB_APPLMODAL
00F61002  PUSH OFFSET Test.00F620F4                ; |Caption = "caption"
00F61007  PUSH OFFSET Test.00F620FC                ; |Text = "text"
00F6100C  PUSH 0                                   ; |hOwner = NULL
00F6100E  CALL DWORD PTR DS:[0F620A4] ; \USER32.MessageBoxA

La table d'import est une table qui est résolue par le système lors du chargement d'un module (.exe, .dll, .sys, etc.) et qui contient des pointeurs vers les fonctions exportées par les DLLs dont le code à besoin.
Un exemple avec un exécutable appelant MessageBoxA. Dans le fichier binaire la table d'import est une table relativement simple, avec (pour simplifier) des couples de type "chaine + chaine" ou "chaine + numéro", par exemple (pour le couple "chaîne + chaine"):

Code :

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

1
2
USER32 MessageBoxA [00000000]

Le système parse la table d'import de l'exécutable. Il voit la chaîne "USER32", il charge donc USER32.dll dans l'espace d'adressage du processus. Ensuite il voit la chaîne "MessageBoxA" et fait un GetProcAddress sur MessageBoxA dans USER32. Il récupère le pointeur (exemple bidon: 0x7FE00123) de la fonction et met ce pointeur dans la table d'import de l'exécutable:

Code :

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

1
2
USER32 MessageBoxA [7FE00123]

Dans notre exemple d'exécutable, l'adresse de MessageBoxA en 0x7FE00123 (son pointeur), se trouvera mise dans la table d'import de l'exécutable en 0xF620A4 !

Code :

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

1
2
00F6100E  CALL DWORD PTR DS:[0F620A4] ; \USER32.MessageBoxA

Si tu injectes le code ci-dessus dans un autre processus, rien ne garantie que, pour le processus injecté:

- Sa table d'import se trouve à la même adresse.
- Que 0xF620A4 soit le pointeur vers MessageBoxA.
- Que MessageBoxA soit en 0x7FE00123.

A propos de ce dernier point, les DLLs sont "relogeables" ("relocatable" en anglais) ce qui signifie que le système ne garantie pas que tu trouve les DLLs au même endroit entre deux processus ou entre deux fonctionnements du même programme.

Il y a d'autres problèmes relatif au code en lui-même:

Code :

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

1
2
00F61002  PUSH OFFSET Test.00F620F4                ; |Caption = "caption"

Il y a peu de chance que dans un autre processus, on retrouve la chaine "caption" en 0xF620F4 par exemple.

Créer du code position independant c'est donc prendre en charge soit même ce qui est normalement dévolu au système d'exploitation: résolution des imports, code relogeable, etc.

--------------------------------------

Il me semble avoir lu (attention a la grosse betise et au gros amalgame qui vont sortir) que kernel32.dll (ou ntdll.dll je ne sais plus) se chargeait toujours a la meme adresse virtuelle, du coup les appels de fonction reste correcte non?

Pas tout à fait. En fait on peut trouver de manière sûre leurs adresses, mais qui seront probablement différentes à chaque fois.

Le segment FS pointe vers une structure interne appelée TEB. A l'offset 0x18 on trouve son adresse linéaire.

Un exemple, je m'attache sur calc.exe avec windbg:

On obtient le TEB:

Code :

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

1
2
3
4
0:001> !teb
TEB at 7ffdd000
[...]

On regarde le début du TEB qui est une structre NT_TIB. Note l'offset 0x30 qui pointe vers la structure PEB.

Code :

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

1
2
3
4
5
6
7
8
9
10
0:001> dt _TEB 7ffdd000
ntdll!_TEB
   +0x000 NtTib            : _NT_TIB
   +0x01c EnvironmentPointer : (null) 
   +0x020 ClientId         : _CLIENT_ID
   +0x028 ActiveRpcHandle  : (null) 
   +0x02c ThreadLocalStoragePointer : (null) 
   +0x030 ProcessEnvironmentBlock : 0x7ffdf000 _PEB
[...]

Le TEB / NT_TIB. En +0x18 on voit bien l’adresse linéaire du TEB, facile à récupérer en assembleur (donc via un shellcode ).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
0:001> dt _NT_TIB 0x7ffdd000
ntdll!_NT_TIB
   +0x000 ExceptionList    : 0x0095ffe4 _EXCEPTION_REGISTRATION_RECORD
   +0x004 StackBase        : 0x00960000 
   +0x008 StackLimit       : 0x0095f000 
   +0x00c SubSystemTib     : (null) 
   +0x010 FiberData        : 0x00001e00 
   +0x010 Version          : 0x1e00
   +0x014 ArbitraryUserPointer : (null) 
   +0x018 Self             : 0x7ffdd000 _NT_TIB

Un aperçu du PEB:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
0:001> dt _PEB 0x7ffdf000
ntdll!_PEB
   +0x000 InheritedAddressSpace : 0 ''
   +0x001 ReadImageFileExecOptions : 0 ''
   +0x002 BeingDebugged    : 0x1 ''
   +0x003 SpareBool        : 0 ''
   +0x004 Mutant           : 0xffffffff 
   +0x008 ImageBaseAddress : 0x01000000 
   +0x00c Ldr              : 0x001a1e90 _PEB_LDR_DATA
[...]

A l'offset 0x0C on trouve la structure PEB_LDR_DATA, structure initialisée par le loader de Windows ('LDR' pour "Loader"):

Code :

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

1
2
3
4
5
6
7
8
9
10
0:001> dt _PEB_LDR_DATA 0x001a1e90
ntdll!_PEB_LDR_DATA
   +0x000 Length           : 0x28
   +0x004 Initialized      : 0x1 ''
   +0x008 SsHandle         : (null) 
   +0x00c InLoadOrderModuleList : _LIST_ENTRY [ 0x1a1ec0 - 0x1a2da8 ]
   +0x014 InMemoryOrderModuleList : _LIST_ENTRY [ 0x1a1ec8 - 0x1a2db0 ]
   +0x01c InInitializationOrderModuleList : _LIST_ENTRY [ 0x1a1f28 - 0x1a2db8 ]
   +0x024 EntryInProgress  : (null)

- InLoadOrderModuleList : ordre de chargement des modules en mémoire.
- InMemoryOrderModuleList: Ordre des modules (suivant leur adresse de base) en mémoire.
- InInitializationOrderModuleList: Ordre d'initialisation des modules.

Chacun des InxxxOrderModuleList est une LIST_ENTRY qu'on peut transtyper en structure LDR_DATA_TABLE_ENTRY.

Je prend le premier pointeur de InLoadOrderModuleList (0x1a1ec0), bingo je tombe sur "calc.exe" qui est bien le premier à être chargé dans l'espace d'adressage:

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
0:001> dt _LDR_DATA_TABLE_ENTRY 0x1a1ec0
ntdll!_LDR_DATA_TABLE_ENTRY
   +0x000 InLoadOrderLinks : _LIST_ENTRY [ 0x1a1f18 - 0x1a1e9c ]
   +0x008 InMemoryOrderLinks : _LIST_ENTRY [ 0x1a1f20 - 0x1a1ea4 ]
   +0x010 InInitializationOrderLinks : _LIST_ENTRY [ 0x0 - 0x0 ]
   +0x018 DllBase          : 0x01000000 
   +0x01c EntryPoint       : 0x01012475 
   +0x020 SizeOfImage      : 0x1f000
   +0x024 FullDllName      : _UNICODE_STRING "C:\WINDOWS\system32\calc.exe"
   +0x02c BaseDllName      : _UNICODE_STRING "calc.exe"
   +0x034 Flags            : 0x5000
   +0x038 LoadCount        : 0xffff
   +0x03a TlsIndex         : 0
   +0x03c HashLinks        : _LIST_ENTRY [ 0x1a2c9c - 0x7c97e270 ]
   +0x03c SectionPointer   : 0x001a2c9c 
   +0x040 CheckSum         : 0x7c97e270
   +0x044 TimeDateStamp    : 0x3b7d8410
   +0x044 LoadedImports    : 0x3b7d8410 
   +0x048 EntryPointActivationContext : (null) 
   +0x04c PatchInformation : (null)

Suivant (ntdll.dll !):

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
0:001> dt _LDR_DATA_TABLE_ENTRY 0x1a1f18
ntdll!_LDR_DATA_TABLE_ENTRY
   +0x000 InLoadOrderLinks : _LIST_ENTRY [ 0x1a1fc0 - 0x1a1ec0 ]
   +0x008 InMemoryOrderLinks : _LIST_ENTRY [ 0x1a1fc8 - 0x1a1ec8 ]
   +0x010 InInitializationOrderLinks : _LIST_ENTRY [ 0x1a1fd0 - 0x1a1eac ]
   +0x018 DllBase          : 0x7c900000 
   +0x01c EntryPoint       : 0x7c912c48 
   +0x020 SizeOfImage      : 0xb2000
   +0x024 FullDllName      : _UNICODE_STRING "C:\WINDOWS\system32\ntdll.dll"
   +0x02c BaseDllName      : _UNICODE_STRING "ntdll.dll"
   +0x034 Flags            : 0x80084004
   +0x038 LoadCount        : 0xffff
   +0x03a TlsIndex         : 0
   +0x03c HashLinks        : _LIST_ENTRY [ 0x7c97e2c8 - 0x7c97e2c8 ]
   +0x03c SectionPointer   : 0x7c97e2c8 
   +0x040 CheckSum         : 0x7c97e2c8
   +0x044 TimeDateStamp    : 0x49901d48
   +0x044 LoadedImports    : 0x49901d48 
   +0x048 EntryPointActivationContext : (null) 
   +0x04c PatchInformation : (null)

Note l'adresse de base au membre 'DllBase' !

Et suivant (kernel32.dll !):

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
0:001> dt _LDR_DATA_TABLE_ENTRY 0x1a1fc0
ntdll!_LDR_DATA_TABLE_ENTRY
   +0x000 InLoadOrderLinks : _LIST_ENTRY [ 0x1a2060 - 0x1a1f18 ]
   +0x008 InMemoryOrderLinks : _LIST_ENTRY [ 0x1a2068 - 0x1a1f20 ]
   +0x010 InInitializationOrderLinks : _LIST_ENTRY [ 0x1a2258 - 0x1a1f28 ]
   +0x018 DllBase          : 0x7c800000 
   +0x01c EntryPoint       : 0x7c80b64e 
   +0x020 SizeOfImage      : 0xf6000
   +0x024 FullDllName      : _UNICODE_STRING "C:\WINDOWS\system32\kernel32.dll"
   +0x02c BaseDllName      : _UNICODE_STRING "kernel32.dll"
   +0x034 Flags            : 0x80084004
   +0x038 LoadCount        : 0xffff
   +0x03a TlsIndex         : 0
   +0x03c HashLinks        : _LIST_ENTRY [ 0x7c97e2b0 - 0x7c97e2b0 ]
   +0x03c SectionPointer   : 0x7c97e2b0 
   +0x040 CheckSum         : 0x7c97e2b0
   +0x044 TimeDateStamp    : 0x49c4f482
   +0x044 LoadedImports    : 0x49c4f482 
   +0x048 EntryPointActivationContext : (null) 
   +0x04c PatchInformation : (null)

En fait les shellcodes font la même chose, mais en assembleur, parce que sous Windows, on est sur qu'en suivant ce chemin:

- Segment FS -> TEB -> PEB -> PEB_LDR_DATA.InLoadOrderModuleList

Et en parsant les trois premières entrées, on trouve:

- 1) La structure décrivant, du point de vue du loader, l'exécutable.
- 2) La structure décrivant, du point de vue du loader, ntdll.dll.
- 3) La structure décrivant, du point de vue du loader, kernel32.dll.

Les modules suivant peuvent changer, mais ceux-là sont garantis. Quoi que le programme appelle (même s'il n'appelle aucune fonction) on est sur qu'il importe ntdll.dll et kernel32.dll.

La première sert (notamment) à appeler des fonctions système pour le loader et pour les fonctions de kernel32, la seconde à initialiser le thread primaire ainsi que la mort du thread primaire et du processus.

Voilà, j'espère ne pas avoir été trop long et trop ennuyeux :p. N'hésites pas si je n'ai pas été clair où si tu as d'autres questions.

[Melem]

Hello,

Si j'ai bien tout compris, le code de melem ne sera pas bon?

Oui c'est bien cela. Je vais essayer de développer sur le pourquoi ça ne peut pas fonctionner en l'état.

Oula, vous allez trop fort vous ne trouvez pas ? Je veux bien que ça soit limité du fait que la fonction qu'on injecte ainsi ne peut pas contenir d'appels à une fonction ou de référence à une variable, et désolé de ne pas l'avoir précisé dès le départ, mais la technique en elle-même est bien valide. Elle est un remplacement avantageux de l'utilisation de shellcode. D'ailleurs, dès qu'on parle de shellcode sous Windows, il ne peut être question que de code ultra simple et/ou très limité et dans tous les cas, il est toujours préférable d'écrire une fonction, au pire avec de l'assembleur en ligne, plutôt que de taper du shellcode. Je ne parle pas de Linux, que je ne connais pas assez d'ailleurs.

Pour revenir à la discussion, bah, euh, je ne vois plus ce que je pourrai encore ajouter .

EDIT : J'ai pas vu que j'avais mis un MessageBox dans mon exemple , je tapais trop vite. Comme l'a montré Neitsa, ça ne marchera pas. C'était effectivement une grosse erreur de ma part .

[sloshy]

Bonjour,
merci pour les info (et désolé pour le retard, c'est un peu la folie en ce moment, exam, projet toussa)
Je vais relire tout à tête reposé début de semaine, et je reviendrai surement avec des questions ou exemple

@Melem, c'était aps une critique, j'essaye juste de comprendre