Discussion :

[opc0de]

J'ai écris un petit code qui liste les "exported functions" d'une dll Windows, seulement depuis Seven on trouve ce genre de fonction: api-ms-win-core-processthreads-l1-1-0.CreateRemoteThreadEx
Cette fonction est enfaite une "forwarder" du coup il me faut allé dans api-ms-win-core-processthreads-l1-1-0.dll et lister cette dll à la recherche de CreateRemoteThreadEx. Mais le problème est que je n'obtiens pas la bonne adresse de la fonction, adresse que j'ai comparé avec LoadLibrary && GetProcAddress.
J'ai ce problème que depuis Seven le code a été écrit sur Vista et les forwarders du type NTDLL.TpReleasePool sont très bien géré.
Donc si quelqu'un a une idée...

Le code: http://pastebin.com/gmcqfC9C

[Neitsa]

Hello,

En fait ton parsing de l'export table est correct, c'est simplement que certains changement de bas niveau ont eu lieu dans le découpage des fonctions sous Windows 7.

Ton LoadLibrary() sur api-ms-win-core-processthreads-l1-1-0.dll charge en fait kernel32.dll. Du coup ta fonction pointe encore sur le forwarder de la fonction forwardée dans kernel32.dll

Concrétement le code de CreateRemoteThreadEx dans api-ms-win-core-processthreads-l1-1-0.dll est une fonction vide. C'est le chargeur de Windows (Windows Loader) qui substitue api-ms-win-core-processthreads-l1-1-0.dll avec kernelbase.dll, ce qui fait que la DLL api-ms-win-core-processthreads-l1-1-0.dll n'est jamais chargée.

Pour résumer, le 'vrai' code de kernel32!CreateRemoteThreadEx() se situe dans kernelbase!CreateRemoteThreadEx().

C'est simple à voir sous Windbg:

0:000> u kernel32!CreateRemoteThreadEx
kernel32!CreateRemoteThreadEx:
75261ed1 ff2560082675 jmp dword ptr [kernel32!_imp__CreateRemoteThreadEx (75260860)]
75261ed7 90 nop
75261ed8 90 nop
75261ed9 90 nop
75261eda 90 nop
75261edb 90 nop

0:000> dd 75260860 L1
75260860 76a02ef3

0:000> u 76a02ef3
KERNELBASE!CreateRemoteThreadEx:
76a02ef3 687c010000 push 17Ch
76a02ef8 68e878a276 push offset KERNELBASE!BemFreeContract+0x3dc (76a278e8)
76a02efd e8b2310200 call KERNELBASE!_SEH_prolog4_GS (76a260b4)
76a02f02 8b4508 mov eax,dword ptr [ebp+8]

[opc0de]

hello et merci pour ta réponse mais j'ai une autre petite question comment je peux le savoir depuis la dll ? pour réaliser mon code, c'est indiqué dans la dll qu'enfaite la fonction ce trouve dans telle dll ?

[Médinoc]

Oui, c'est indiqué.
Tu peux peut-être trouver quelques infos ici:
http://blogs.msdn.com/oldnewthing/ar...27/680250.aspx mais ça parle assez peu des redirections.

[opc0de]

sorry mais je ne trouve pas

[Elboras]

Comme la vrai adresse est substitué, je ne pense pas qu'avec une "analyse morte" ce soit possible.
Quelqu'un aurait il des informations sur comment exactement le windows loader substitue ces deux adresses ?

Comme on suppose que c'est en runtime, tu pourra observer l'adresse qu'en runtime.
Neitsa te montre sous windbg qu'il est facile de voir le saut vers la vrai adresse.

[Elboras]

apres avoir regardé rapidement l'application d'opc0de.
Il pourrait y avoir une solution crade, c'est à dire resolv la fonction CreateRemoteThreadEx de kernel32 par exemple.

Ensuite, avec un pointeur sur la fonction, lire l'adresse qui est a address+2
C'est a dire faire un read qu'on voit que les opcodes du jump sont :
ff2560082675
si on evite le ff25 qui sont les opcodes du jump, on peut read l'adresse qui nous interesse.
Ensuite, en regardant a cette adresse, on peut optenir directement l'adresse de la fonction que l'on veut.

Ceci est un peu crade, mais peut etre fait en quelques lignes de C ou d'assembleur.

Mais en regardant dans la table d'import (pas de debugger sous la main) on peut pas avoir le meme resultat plus facilement ?
Si au runtime les adresses sont changé, c'est soit dans la table d'import soit dans le code (j'opterais plus pour la table d'import).

On pourrait donc en dumpant la table d'import y arriver plus facilement ?