REGISTRY GUARD BETA
MuPuF
Messages postés
536
Date d'inscription
mercredi 27 avril 2005
Statut
Membre
Dernière intervention
22 août 2008
-
17 juil. 2006 à 19:24
pianopariss Messages postés 6 Date d'inscription vendredi 23 décembre 2005 Statut Membre Dernière intervention 13 avril 2007 - 13 avril 2007 à 19:23
pianopariss Messages postés 6 Date d'inscription vendredi 23 décembre 2005 Statut Membre Dernière intervention 13 avril 2007 - 13 avril 2007 à 19:23
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/38646-registry-guard-beta
https://codes-sources.commentcamarche.net/source/38646-registry-guard-beta
13 avril 2007 à 19:23
C'est un très pratique programme (même si il fait planter MSN etc.) :-).
Je me suis moi (pas tout seul) lancé dans la construction d'un antivirus, (c.f. http://www.viropy.com ) et je cherche à faire quelque chose se rapprochant mais comme l'a dit Brunews avec un driver, donc, si quelqu'un trouve quelque chose (documentation, etc.) ce serait gentil de poster ici ou bien de me le dire (MP etc.) car je pense que ça en ferait profiter tout le monde.
++, PianoPâriss.
23 août 2006 à 14:00
20 juil. 2006 à 10:06
20 juil. 2006 à 05:30
20 juil. 2006 à 05:13
Taron31 >> Je viens de regarder ton code d'un peu plus près. C'est effectivement l'utilisation de SetWindowsHook() qui permet de ne pas s'occuper de l'énumération des processus et la détection de ceux nouvellement créés. C'est donc le système qui fait ce travail. C'est dommage que cela ne permette pas de hooker les processus sans fenêtre. Pourtant, je trouve l'utilisation de SetWindowsHook() très propre par rapport aux autres méthodes de hook. Je connais plutôt la célèbre méthode de Jeffrey Ritcher qui consiste à:
1- Enumérer tous les processus existants (avec ou sans fenêtre).
2- Ouvrir chaque processus.
3- Allouer de la mémoire dans l'espace alloué au processus.
4- Ecrire le chemin contenant le nom de notre dll dans cette zone mémoire.
5- Récupérer l'adresse de LoadLibary() dans Kernel32.dll
6- Créer un thread dans le processus cible. La fonction de ce thread est l'adresse de LoadLibrary() ayant comme paramètre le pointeur sur la zone allouée contenant le chemin de notre dll.
7- Attendre que ce Thread se termine.
8- Libérer le handle du thread, celui du processus et la mémoire allouée.
Notre dll sera donc chargée dans tous les processus. Elle modifiera leurs tables d'import afin de rediriger tous les appels de l'API voulue vers une fontion contenu dans cette dll.
Je trouve cette solution très élégante. Le problème qui reste à résoudre est celui de la détection de nouveux processus.
Un autre problème apparaitra car il parait que Microsoft a l'intention d'interdire l'écriture dans une zone mémoire allouée dans un processus externe à une application. Dans tel cas, cette méthode ne sera plus utilisable.
La solution du hook avec SetWindowsHook() sera toujours supportée.
Je te conseille donc de garder cette solution dans la prochaine mise à jour de ce code source en essayant d'y apporter quelques améliorations. Dans beaucoup de cas, ce genre de solution suffit largement.
Pour perfectionner les choses, on sera donc obligés d'utiliser la solution proposée par BruNews. Je vais m'y mettre bientôt. je suis sûr que ce sera passionnat et plein de découvertes.
Vive la programmation! :)
19 juil. 2006 à 00:05
18 juil. 2006 à 23:59
BruNews: il faudrait modifier quand même plusieurs entrées nan ? pour l'ouverture, la création, la lecture, l'écriture et la fermeture... non ?
Merci
18 juil. 2006 à 23:38
A propos de la taille de l'EXE, tu peux la réduire avant même de le passer sous UPX. La taille finale sera encore plus petite.
18 juil. 2006 à 23:33
18 juil. 2006 à 23:29
En cas de hook par driver, tu n'as plus à te soucier de quelles fonctions sont appelées pour accès à la BDR, que soit de ntdll ou kernel32 peu importe, elles finiront sur l'entrée modifiée par le driver du ServiceDescriptorTableEntry qui devra repointer sur TA fonction perso.
Pour de la doc sur les drivers, faut lire Walter Oney 2de édition et surtourt collecter tout ce que tu trouveras sur le net car le bouquin suppose pas mal de concepts connus (pas évident pour tout le monde). Il te faudra le DDK, il comporte un gros chm d'aide.
18 juil. 2006 à 23:11
A propos de programmation de drivers, j'ai le DDK 2000. ça marchait parfaitement sur Win2000. Dernièrement, j'ai voulu l'installer sur Win XP-SP2 puis j'ai dû formatter mon PC et tout réinstaller car ça redémarre tout seul. Je ne sais pas si c'est à cause du DDK ou non. J'aimerais donc savoir si je peux utiliser mon ancien DDK sur XP ou existe-t-il une version spéciale pour XP?
18 juil. 2006 à 23:10
Racpp: c'est vrai j'avais deja remarqué ce problème là, je ne comprends pas vraiment et je ne sais pas comment y remedier ; car si on detecte le nouveau processus, je devrais peut-être injecter la DLL manuellement ? A voir... Concernant encore la taille, un coup d'UPX et ça fera 200ko à tout casser.
Concernant tes remarques sur l'interface, et les menus, je pense le laisser comme ça (pas sûr) car d'autres fonctionnalités seront sûrement à venir. Il y'a aussi le problème de la ToolBar à régler c'est veridict, enfin bref, je corrigerai tout ça. Je tenterai de lancer une nouvelle version en août dès que j'aurais le temps, parce que là je suis en stage. En tout cas merci beaucoup pour tes commentaires, ça aide.
BruNews, justement c'était un point que je comptais aborder, tout ne sera pas hooké. Et dans d'autre produits (tel que Regmon par exemple) utilisent des Drivers en Kernel Mode pour tout catcher. Et je me pose exactement les mêmes question que Racpp, pour hooker les fonctions agissant sur la registry de ntdll.dll il faut passer obligatoirement en kernel mode ? En fait, je comptais utiliser un driver pour avoir un meilleur impact dans le hook mais j'ai trouvé aucune doc à ce sujet.
Merci pour vos commentaires, j'en attends d'autre...
18 juil. 2006 à 22:55
ZwCreateKey, ZwSetValueKey, etc... Il est clair que si on les appelle direct, on saute le hook des fonctions du mode user.
Si on veut hooker celles ci, il faut suivre l'exemple quej'ai fait pour cacher les progs, ça passe par force par un driver. C'est la seule méthode qui garantit l'interception pour tout le system. Ce sera par contre un gros boulot.
18 juil. 2006 à 22:33
Certains programmes utilisent les fonctions de ntdll.dll. Ils sont également non hookables par la méthode utilisée dans ce code source.
Quand tu dis "kernel mode dans un driver" tu parles du hook des fonctions de la ntdll.dll ou les autres APIs?
18 juil. 2006 à 22:18
De nombreux progs en langages interprétés utilisent les classes WMI pour accès à la BDR (entre autre), idem ils ne seront pas hookés, etc...
Pour un hook complet sur la BDR, il faut passer le code en kernel mode dans un driver.
18 juil. 2006 à 21:53
MuPuf >> Merci pour la réponse. Je sais ce que c'est un hook d'API. J'en ai déjà fait. Je parlais donc du hook des 3 APIs pour un programme nouvellement lancé alors que RegistryGuard est déjà actif.
Taron32 >> Merci pour la précision. En effet, je viens de tester en ouvrant Winzip. Mais il parait que le programme ne détecte pas les processus n'ayant pas une fenêtre ou une boite de dialogue. Que ces processus soient créés avant ou après le lancement de RegistryGuard, ils ne sont pas hookés. Voici un petit exemple de code à compiler et tester:
int WINAPI WinMain(HINSTANCE hInst, HINSTANCE hPrev,LPSTR cmd, int show)
{
HKEY keyHandle;
RegOpenKeyEx(HKEY_LOCAL_MACHINE,"SOFTWARE\\Microsoft\\Windows\\CurrentVersion",0,KEY_ALL_ACCESS,&keyHandle);
RegCloseKey(keyHandle);
ExitProcess(0);
}
Il est donc préférable de lister tous les processus existants, avec ou sans fenêtre. Le cas de ceux nouvellement créés (sans fenêtre) est plus délicat. J'avais ce genre de problème dans une application qui doit hooker une API pour tous les processus existants et à venir. J'ai lu quelque part qu'il existe une fonction de ntdll.dll qui permet à une application d'être informée quand un processus quelconque vient d'être créé. Je n'ai pas encore testé cette solution car j'ai encore du temps avant la première mise à jour de mon application.
Pour la taille de l'exécutable, l'un des responsable est, c'est vrai, surtout l'image BMP nagsreen de 263ko. Tu peux la convertir en JPG pour avoir une taille de seulement 25ko en gardant 100% de la qualité originale. Pour l'afficher dans ton programme tu utliseras l'interface IPicture. Ainsi, tu gagneras donc 238Ko. A remarquer aussi que la taille de la DLL est assez garnde aussi (200Ko).
Concernant l'interface du programme, j'ai quelques remarques:
- Puisqu'il n'y a pas beaucoup de fonctionnalités, il est préférable d'utiliser une ToolBar au lieu des menus.
- La ListView doit avoir une ScrollBar vericale.
- Les derniers éléments ajoutés à la ListView doivent être en bas de la liste au lieu du début.
- En actionnant la roulette de la souris, l'affichage de la ListView n'est plus normal.
- L'heure de la détection ne correspond pas à l'heure locale du PC.
- L'affichage de l'heure de détection doit être corrigé. Par exemple ça affiche "21:4 52 sec" au lieu de "21:04:52".
Je sais que c'est une version Beta et que tout cela n'est pas difficile à régler.
Je le répète, je trouve ce code très très intéressant.
J'attends la prochaine mise à jour pour donner une note, qui sera certainement 10/10.
Merci.
18 juil. 2006 à 12:33
Voilà.
Merci.
18 juil. 2006 à 12:06
Le programme ne hooke pas l'execution d'un programme, seulement si celui çi accede au registre ou pas.
A la base, c'étais pour faire un antivirus qui demande trés peu de ressource (on est partit du constat qu'un virus écrit à 98% dans la bdr, ça permet d'allerter, à l'utilisateur de faire son travail aprés).
Voila, pour la taille de l'exe, il a mit des images dedans ;-)
Bonne journée
18 juil. 2006 à 04:12
Je n'ai pas encore regardé le code source, mais ça parait très intéressant. J'ai deux petites questions.
1- C'est normal que la taille de l'exécutable soit si grande?
2- Supposons que le programme est déjà lancé, puis on ouvre un programme quelconque. Sera-t-il hooké à son ouverture?
Je regarderai plutard le code.
Merci.
17 juil. 2006 à 19:24
Signé, le lacheur ;-D