Discussion :

[homeostasie]

Bonsoir,

Un titre peut être pas très explicite mais je m'explique:
Je cherche à comprendre comment est gérée une fonction importée d'une bibliothèque kernel32 (par exemple) au niveau de l'exécutable.
Au moment de l'exécution, les DLLs requises sont chargées puis les adresses de fonctions importées sont stockées dans l'IAT. OK!

Je me fais un petit programme tout simple avec l'utilsation de la fonction Sleep().

Code :

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

1
2
3
4
5
6
7
8
9
typedef void (*SLEEP_FCN)(DWORD dwMilliseconds);

int main(void)
{
    SLEEP_FCN AddrSleepFcn = (SLEEP_FCN)Sleep;
    AddrSleepFcn(2000);
    Sleep(2000);
}

Avec le debugger, je visualise cela en faisant un "watch":

AddrSleepFcn = (SLEEP_FCN)0x401f98 <Sleep@4>
+Sleep
0x7c802446 <Sleep>

J'aurais pensé que AddrSleepFcn aurait la même valeur que Sleep mais ce n'est pas le cas. Sauriez vous pourquoi?
D'ailleurs que signifie ce <Sleep@4>?

Evidemment l'appel à AddrSleepFcn(2000) fonctionne bien.

Merci

Nicolas

[Médinoc]

Ça a été expliqué en détails sur le blog de Raymond Chen.
Alors, pour commencer par le plus simple:
Le @4, c'est la décoration C de la fonction. Elle dépend de la convention d'appel, mais dans la convention d'appel __stdcall (celle qui est recommandée pour les DLLs), le chiffre à droite de l'@ est la taille en octets de ses paramètres. Par contre, il est conseillé d'exporter les noms non-décorés des fonctions de DLL, mais ça demande plus de travail (c'est le cas pour les DLLs Windows).

Pour l'importation, la bibliothèque statique d'importation (ici, kernel32.lib) contient deux points d'entrée: _Sleep@4 et __imp_Sleep@4. Le second correspond à l'emplacement du pointeur dans l'IAT, tandis que le premier est une fonction wrapper qui se contente de lire l'adresse et y faire un JMP. Un compilo "éduqué" utilsera directement le second point d'entrée, tandis qu'un compilo plus "naïf" utilisera le premier.

Pour les pointeurs de fonction, il doit y avoir une subtilité, genre toujours choisir le wrapper, ou un truc du genre. Le mieux serait de voir le code assembleur généré...

[Melem]

Evidemment l'appel à AddrSleepFcn(2000) fonctionne bien.

Pourtant ça ne devrait pas. Sleep utilise la convention d'appel WINAPI (__stdcall) comme toutes les API des Windows, AddrSleepFcn est un pointeur vers une fonction qui nécessite un paramètre DWORD, qui ne retourne rien et qui utilise la convention d'appel standard du C (__cdecl). Tu dois donc encore remplacer ton typedef par :

Code :

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

typedef void (WINAPI * SLEEP_FCN)(DWORD dwMilliseconds);

[homeostasie]

Ça a été expliqué en détails sur le blog de Raymond Chen.

Merci pour la référence. J'ai commençé à y jeter brièvement un oeil mais faudra que je m'y penche un peu plus.

Sinon sympa pour l'explication!

Pour les pointeurs de fonction, il doit y avoir une subtilité, genre toujours choisir le wrapper, ou un truc du genre. Le mieux serait de voir le code assembleur généré...

Je me galère un peu avec cà. J'utilise code blocks, il me désassemble le programme principal mais je ne peux visualiser ni ce qui se trouve à 0x401f98<Sleep@4>, ni à 0x7c802446 <Sleep> .

Par contre, je peux visualiser les opcodes à ces emplacements mémoires par l'outil "examine memory". Mais du peu de mes recherches, je n'ai pas trouvé de doc. sur la traduction opcode-instruction assembleur. Faudrait que je m'y penche aussi...Je pense que ca doit être du intel x86...

Peut être connaissez vous d'autres outils pour débugger la mémoire d'un fichier PE (gratuit )?

@Melem: Merci pour la correction!

Bonne soirée.
Nicolas

[bacelar]

WinDbg (gratuit, fournis pas M$)

[homeostasie]

Après quelques recherches et analyses avec le désassembleur OllyDbg (ce n'est peut être pas le meilleur, j'ai vu aussi IDA free et WinDbg), l'appel de la fonction Sleep(2000) se déroule ainsi:

0040135A |. E8 B9050000 CALL <JMP.&KERNEL32.Sleep> ; \Sleep

-> Jump vers un offset relatif: 40135A+ 05B9= 401913

00401918 $-FF25 C8504000 JMP DWORD PTR DS:[<&KERNEL32.Sleep>] ; kernel32.Sleep

Je ne l'explique pas mais le jump me mène à l'adresse 00401918, c'est à 5 octets de plus que ce que j'avais prévu. Si quelqu'un à une explication?
On constate ici un jump vers le contenu pointé à l'emplacement mémoire 4050C8.
J'examine cette adresse mémoire, je me retrouve dans l'IAT et donc je récupère l'adresse de la fonction Sleep() importée 0x7c802442.

Pour aller plus loin, suite au jump à l'adresse 0x7c802442, je constate que c'est la fonction SleepEx() qui est réellement appellée:

7C802442 > 8BFF MOV EDI,EDI
7C802444 55 PUSH EBP
7C802445 8BEC MOV EBP,ESP
7C802447 6A 00 PUSH 0
7C802449 FF75 08 PUSH DWORD PTR SS:[EBP+8]
7C80244C E8 4BFFFFFF CALL kernel32.SleepEx

Le CALL kernel32.SleepEx équivaut à CALL 7C80239C mais je ne comprends pas le jump vers 4BFFFFFF pour obtenir cette valeur (Je ne trouve pas le moyen de visualiser ce qu'il y a à cet emplacement). Je suis prenneur aussi pour une petite explication?

Nicolas

[homeostasie]

J'aurais pensé que AddrSleepFcn aurait la même valeur que Sleep mais ce n'est pas le cas. Sauriez vous pourquoi?

Pour les pointeurs de fonction, il doit y avoir une subtilité, genre toujours choisir le wrapper, ou un truc du genre. Le mieux serait de voir le code assembleur généré...

Après plusiseurs recherches car ça me tracasse:

The JMP instruction indirects through a DWORD variable in the .idata section. This .idata section DWORD contains the real address of the operating system function entry point. After thinking about this for a while, I came to understand why DLL calls are implemented this way. By funneling all calls to a given DLL function through one location, the loader doesn't need to patch every instruction that calls a DLL. All the PE loader has to do is put the correct address of the target function into the DWORD in the .idata section. No call instructions need to be patched. This is in marked contrast to NE files, where each segment contains a list of fixups that need to be applied to the segment. If the segment calls a given DLL function 20 times, the loader must write the address of that function 20 times into the segment. The downside to the PE method is that you can't initialize a variable with the true address of a DLL function.

Source du lien: Peering Inside the PE: A Tour of the Win32 Portable Executable File Format

Est ce quelqu'un sait comment le loader trouve l'adresse de l'IAT où il doit placé la véritable addresse de la fonction importée? L'information se trouverait elle déjà dans le PE avant chargement et le loader s'en servirait?

[Médinoc]

Raymond Chen : Plus d'infos sur la subtilité

Quand à ta question sur l'IAT, je suppose que ça se passe dans l'autre sens: Le loader parcoure l'IAT et résout tous les imports qu'elle contient, dans l'ordre...

[Melem]

Mais pourquoi ne pas faire un bête :

Code :

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

SLEEPADDR SleepAddr = (SLEEPADDR)GetProcAddress(GetModuleHandle("kernel32.dll"), "Sleep");

Ou bien je n'ai pas bien compris la question ? Certes, cela ne fonctionne que pour les fonctions exportées par nom mais c'est bien notre cas actuellement ...

[homeostasie]

Mais pourquoi ne pas faire un bête :

Code :

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

SLEEPADDR SleepAddr = (SLEEPADDR)GetProcAddress(GetModuleHandle("kernel32.dll"), "Sleep");

Ou bien je n'ai pas bien compris la question ? Certes, cela ne fonctionne que pour les fonctions exportées par nom mais c'est bien notre cas actuellement ...

Oui tout à fait, j'ai déjà fait exactement cette ligne de code et on récupère bien directement l'adresse de la fonction Sleep().

En fait mes questions n'ont pour but que la compréhension de comment est géré l'importation de fonctions.

C'est juste de la curiosité! Et lorsqu'on cherche à approfondir, toujours d'autres questions surviennent...

Par exemple:
Je constate qu'après analyse de la même dll "kernel32.dll":
- sur Windows XP SP2: Sleep() a pour adresse 0x70802442
- sur Windows XP SP3: Sleep() a pour adresse 0x70802446

Ca m'échappe, à moins que ce soit une des dlls chargées avant celle-ci dans l'espace d'adressage du processus qui ai été modifiée!
(Enfin, bref, je n'en suis même pas certain de cette explication)

[Médinoc]

Regarde les numéros de version de Kernel32.dll : Y'a des chances que ce ne soit pas la même, donc pas les mêmes adresses dans le code...

[Melem]

Normalement les adresses (RVAs) sont les mêmes car un exe doit pouvoir s'exécuter quelle que soit la version du système. C'est l'adresse de base de chargement de la DLL qui varie selon la version. L'adresse dans l'espace virtuel d'un processus d'une fonction contenue dans une DLL est égale à Adresse de base de la DLL + RVA de la fonction.

[Médinoc]

Mais si c'était le cas, on n'aurait pas besoin d'une IAT, ni de table d'exportation dans la DLL. l'IAT est justement là pour que l'importation des fonctions d'une DLL puisse être indépendante de l'adresse de la fonction au sein de celle-ci...

Ainsi, seuls comptent le nom de la fonction, et son ordinal dans la table d'exportation...

[Melem]

Ah oui c'est vrai, les adresses des fonctions (importées) ne sont pas inscrites en dur dans l'exe. On passe par l'IAT qui contient la liste des fonctions dont l'exe a besoin et c'est le loader qui convertit les noms (ou ordinaux) en adresses. C'est bête que je ne m'en souvienne plus de tout cela ...

[homeostasie]

Regarde les numéros de version de Kernel32.dll : Y'a des chances que ce ne soit pas la même, donc pas les mêmes adresses dans le code...

Je n'ai pas regardé les numéros de versions puisque c'est censé être les mêmes.
Voici la manipulation que j'ai fait:
- Sous ma machine virtuelle Win XP SP2, je vérifie avec ollydbg l'adresse de la fonction Sleep.
- Je copie ensuite cette même dll sur mon pc Win XP SP3, celui qui fait tourner la machine virtuelle. J'anlyse de même cette dll avec ollydbg et je constate un décalage de 4 octets pour la même dll. Est ce dû à la machine virtuelle...

Mais je pourrais refaire la manip et bien vérifier la version!

Mais si c'était le cas, on n'aurait pas besoin d'une IAT, ni de table d'exportation dans la DLL. l'IAT est justement là pour que l'importation des fonctions d'une DLL puisse être indépendante de l'adresse de la fonction au sein de celle-ci...

Ainsi, seuls comptent le nom de la fonction, et son ordinal dans la table d'exportation...

J'aurais pensé que l'adresse des fonctions dans la table d'exportation compte bien tout autant. Ce champ contient un tableau de RVAs pour chaque fonction exportée. Ainsi on peut retrouver l'adresse de la fonction exportée au sein de la DLL.
Puis le loader met à jour l'IAT du module cible pour une fonction donnée, en ajoutant la RVA (fournit par la table d'exportation de la DLL) à l'adresse de base de la DLL chargée dans le module cible. Ainsi, on obtient l'adresse de la fonction importée au sein du processus exécuté.

On peut supposer donc que si on modifie l'EAT d'une DLL cible avec une RVA pré-calculé pour pointer vers un emplacement mémoire précis dans un processus cible alors on peut modifier le comportement de ce programme lors de l'exécution de la fonction importée.

[Médinoc]

Ollydbg peut-il t'assurer que c'est bien cette version de Kernel32 qui est chargée, et non la version présente dans le dossier système de Windows?

On peut supposer donc que si on modifie l'EAT d'une DLL cible avec une RVA pré-calculé pour pointer vers un emplacement mémoire précis dans un processus cible alors on peut modifier le comportement de ce programme lors de l'exécution de la fonction importée.

Sans doute, mais ce n'est pas un problème de sécurité puisque tu dois avoir le droit de modifier la DLL pour ça. Donc, autant remplacer le code de ses fonctions par du code à toi...

[homeostasie]

Ollydbg peut-il t'assurer que c'est bien cette version de Kernel32 qui est chargée, et non la version présente dans le dossier système de Windows?

En effet, bonne remarque! Je vais vérifier cela et si c'est bien la cas, je clos ce topic.

Sans doute, mais ce n'est pas un problème de sécurité puisque tu dois avoir le droit de modifier la DLL pour ça. Donc, autant remplacer le code de ses fonctions par du code à toi...

Tout à fait, ça m'a juste traversé l'esprit. C'est clair qu'il est bien plus aisé, justifié et "légale" de faire ses propres fonctions.

[homeostasie]

Ollydbg peut-il t'assurer que c'est bien cette version de Kernel32 qui est chargée, et non la version présente dans le dossier système de Windows?

En effet, bonne remarque! Je vais vérifier cela et si c'est bien la cas, je clos ce topic.

Donc en effet, Ollydbg place par défaut la kernel32.dll qui se trouve sous "system32" (celle de SP3) à son emplacement défini à 0x7c801000 et me place celle de SP2 que je veux débugger à un autre emplacement 0x870000.

Bref, je clos le topic!