[WINNT] INTERCEPTER LES APPELS AUX API WIN32

cs_EBArtSoft Messages postés 4525 Date d'inscription dimanche 29 septembre 2002 Statut Modérateur Dernière intervention 22 avril 2019 - 22 mai 2004 à 22:38
Xya Messages postés 103 Date d'inscription lundi 8 juillet 2002 Statut Membre Dernière intervention 24 novembre 2005 - 23 juil. 2007 à 19:14

Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.

https://codes-sources.commentcamarche.net/source/23072-winnt-intercepter-les-appels-aux-api-win32

Xya Messages postés 103 Date d'inscription lundi 8 juillet 2002 Statut Membre Dernière intervention 24 novembre 2005
23 juil. 2007 à 19:14

What worked for me to build it with VS2005 was to create a new Win32 project as a Win32 DLL and replace the generated files with SharpSpyHelper.cpp/h. In the 'linker settings/Input' tab, I've added 'SharpSpyHelper.def' to 'Module Definition File' and built the solution without changing any other setting.

This dynamically links SharpSpyHelper.dll to msvcr80.dll or mscvr80d.dll (depending on your project configuration (release or debug)) which may be what you're looking for or not.

LeChiffre Messages postés 1 Date d'inscription vendredi 13 juillet 2007 Statut Membre Dernière intervention 21 juillet 2007
21 juil. 2007 à 18:13

Sorry for using english language. Do you know how to compile it with VS2005?
Libc.lib isn't supported by VS2005 anymore. If I replace it with Libcmt.lib, I get strange errors. Also a problem if I install libc.lib from my old computer. Maybe additional compiler settings?

HeavenForsaker Messages postés 223 Date d'inscription mercredi 13 juillet 2005 Statut Membre Dernière intervention 8 août 2011
9 mai 2006 à 13:07

Bonjour,

Tu dit :

"je suis tombé il y a pas longtemps sur une fonction qui permettait d'intercepter un appel à une fonction de Windows, mais seulement dans le même processus"

Puis je savoir à quelle fonction tu fais référence ?

draluorg Messages postés 625 Date d'inscription vendredi 23 avril 2004 Statut Membre Dernière intervention 25 novembre 2010
1 mai 2006 à 23:46

Salut a tous,

Tres interessant :)

Manque plus qu'un exemple d'utilisation en Vb.net ^^

++

vitoto Messages postés 18 Date d'inscription dimanche 8 mai 2005 Statut Membre Dernière intervention 13 janvier 2006
3 janv. 2006 à 05:37

Some use in VB.Net ?

cs_EBArtSoft Messages postés 4525 Date d'inscription dimanche 29 septembre 2002 Statut Modérateur Dernière intervention 22 avril 2019 9
23 mai 2004 à 00:28

J'ajouterais que tout ce qui est fait peut etre defait
il suffira d'adapter son code a la platforme comme
tout bon code aujourd'hui. Et puis longhorn ne sera
qu'une nieme platforme avec ses probleme a resoudre
et ses facilité a exploiter.

BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
23 mai 2004 à 00:26

Adopte Richter pour la perennite du code alors.

BruNews, Admin CS, MVP Visual C++

Xya Messages postés 103 Date d'inscription lundi 8 juillet 2002 Statut Membre Dernière intervention 24 novembre 2005
23 mai 2004 à 00:14

C'est vrai que pour Longhorn les processus risquent d'être encore plus cloisonnés que maintenant, mais tant que l'utilisateur a les bonnes autorisations sur ses processus je pense qu'il sera possible d'écrire dans la mémoire d'un processus, ne serait ce qu'en utilisant les APIs et les autorisations de débogage (DebugActiveProcess & co). D'ailleurs Read/WriteProcessMemory sont classés dans MSDN parmi les fonctions de débogage. D'un autre coté, comme l'architecture de Longhorn n'est encore connue que dans ses grandes lignes (du moins parmi les non-MVPs), on n'est pas en mesure de savoir si ces techniques d'injections de Dll vont toujours être envisageables.

Xya

BruNews Messages postés 21040 Date d'inscription jeudi 23 janvier 2003 Statut Modérateur Dernière intervention 21 août 2019
23 mai 2004 à 00:03

Je pense inversement qu'il vaut mieux employer la technique decrite par Richter. Dans les prochains services packs (je pense) et dans Longhorn assurement, la protection des zones memoires contre l'injection de code par ecriture sera implementee pour les processeurs le supportant. SetWindowsHookEx ne subira par contre pas de modifs de ce point de vue.

Xya Messages postés 103 Date d'inscription lundi 8 juillet 2002 Statut Membre Dernière intervention 24 novembre 2005
22 mai 2004 à 23:47

Je connaissais pas la technique des hooks messages mais d'après ce que j'en ai compris on ne peut pas spécifier un processus particulier à hooker, SetWindowsHookEx injecte la Dll à chaque processus qui utilise une fenêtre et appelle à chaque message reçu par chaque fenêtre la fonction spécifiée, ce qui surcharge le système inutilement, alors qu'on n'a besoin d'exécuter du code une seule fois (dès qu'on peut exécuter du code on peut créer des threads et injecter du code comme on veut). Si on veut retirer le hook, la Dll est déchargée et on ne peut plus exécuter de code.

Même si ça marche sous Win98/ME ça me parait pas être le meilleur moyen d'injecter du code dans un processus.

Xya

ymca2003 Messages postés 2070 Date d'inscription mardi 22 avril 2003 Statut Membre Dernière intervention 3 juillet 2006 7
22 mai 2004 à 22:53

dans le bouquin de Richter :
http://brunews.free.fr/brunews/download/JR4.zip
http://brunews.free.fr/brunews/download/JR4Sources.zip

il y a un exemple similaire (Part IV Chap 22, API hooking) qui utilise un hook message pour injecter une Dll dans le processus cible, utilisable donc sous Win98/ME.

cs_EBArtSoft Messages postés 4525 Date d'inscription dimanche 29 septembre 2002 Statut Modérateur Dernière intervention 22 avril 2019 9
22 mai 2004 à 22:38

Meme genre en vb6 :
http://vbfrance.com/code.aspx?ID=22687

Discussions similaires

API Win32 avec python?????

envoi sms

application sms avec php

affecter la date du jour à une variable

poster une variable php dans un href

Votre réponse

Discussions similaires