2010-04-23 6 views
0

Dans un Portable-Executable, nous pouvons changer le nom de la DLL importée, en éditant le fichier PE, ici, j'avais changé dans un nom de DLL importé de l'application exe, cette fois il a changé normalement .... par exemple advapi32.dll à^dvapi32.dll, donc ici system32 ou tout autre emplacement de chemin n'a pas^dvapi32.dll .. cette fois j'ai simplement changé le vrai advapi32.dll en^dvapi32.dll et mis dans le répertoire de l'application, cette fois son travail bien .. ..mais quand j'essaie avec ntdll & gdi32.dll, il ne supporte pas, je ne peux pas résoudre le problème, pls m'aider vers le problème .. merci.Modifier le nom Dll importé?

+0

Juste curieux, pourquoi auriez-vous besoin de changer les noms des importations parce que ce sont des DLL appartenant à l'OS Windows lui-même. Votre application utilise-t-elle des versions modifiées des DLL Windows? – anonymous

+0

roys, dans un pe, nous pouvons changer le nom de la DLL importés, puis nous écrivons dans un fichier séparé comme le même dans system32, seul le nom va changer, alors pourquoi il ne supporte pas? – Rajakumar

+0

M. roys, désolé pour le déranger une fois de plus , je n'utilise pas les versions modifiées de Windows Dll, mais je veux rediriger le système dll dans ma copie locale, il y a autre que le changement de nom de dll, dites-moi environ – Rajakumar

Répondre

1

Les DLL système telles que GDI32.DLL sont chargées en mémoire au démarrage de Windows car elles fournissent des fonctions essentielles du système d'exploitation Windows (dans ce cas, des fonctions graphiques). Certaines DLL sont construites avec une ImageBase fixe (suspecte cela s'applique aux DLL système les plus essentielles, par exemple KERNEL32, GDI32.DLL, USER32.DLL) et copier et renommer ce type de DLL et les référencer ne fonctionnera pas, non sans modifier leur ImageBase dans l'en-tête PE. Cela se produit car ils tenteront de se charger dans la mémoire spécifiée par ImageBase et échoueront, car l'emplacement de mémoire particulier est déjà occupé par la DLL d'origine déjà en mémoire et leur ImageBase fixe les empêche de charger à d'autres emplacements de mémoire. Les DLL sans ImageBase fixe seront déplacées par Windows pour utiliser un autre emplacement de mémoire et s'exécuter sans problème.

Si l'ImageBase de la copie DLL est modifiée à une valeur différente, les DLL avec une ImageBase fixe fonctionneront correctement à condition que l'emplacement de mémoire pointé par ImageBase soit inoccupé.

Bien que je l'ai testé cette approche avec succès sur une copie du Bloc-notes puis modifiez les noms de DLL importés et ImageBases des copies de DLL sous Windows XP, je FORTEMENT Décourager ce tripoter les importations et la falsification des DLL système Windows dans ce manière.

+0

correct .basiquement ce n'est pas un bon pense, tout ce que je veux savoir pour une recherche sur pe. merci beaucoup pour votre information precieuse .... si je change la base de l'image du nom change de dll, l'application fonctionne bien ... n'est-ce pas? – Rajakumar

+1

Oui. Il est beaucoup plus facile d'utiliser un éditeur PE comme StudPE @ http://www.cgsoftlabs.ro/studpe.html pour éditer l'ImageBase des DLL mais cela peut être fait avec un éditeur hexadécimal. – anonymous

+0

ok, un autre doute pour moi, comment peut prédire, quel est l'emplacement inoccupé par les DLL système? – Rajakumar

Questions connexes