Exemples de mots-clés d'un programme hook complet : hook, blocking, service
Il s'agit de la question du test pour « Analyste principal de programmes Windows » de l'entreprise xx que j'ai reçue lorsque je postulais pour un emploi. Les exigences spécifiques (c'est-à-dire la description de mon programme) sont :
1. Le programme client s'appelle Client. Surveillez le fonctionnement du système. Si vous constatez qu'il existe un processus « bloc-notes » (notepad.exe) ou un processus « calculatrice » (calc.exe) dans le système, arrêtez immédiatement le processus et écrivez l'événement dans la base de données ; Vérifiez périodiquement la base de données toutes les minutes et téléchargez les enregistrements d'événements qui n'ont pas encore été téléchargés sur le serveur.
1. L'environnement d'exploitation cible est le système d'exploitation Windows 2000.
2. Veuillez concevoir le programme pour qu'il serve le système.
3. Le programme doit disposer de capacités anti-attaque, y compris des fonctions telles que l'anti-suppression et la résistance à l'arrêt forcé des processus.
(1) Maintenir le programme en cours d'exécution en continu et empêcher d'autres programmes de mettre fin de force à l'exécution du programme en cours ;
(2) Protéger la base de données d'événements et le fichier d'exécution principal contre la suppression ;
(3) Si une anomalie est détectée (le processus est terminé, le fichier est supprimé, etc.), forcez immédiatement le rechargement/l'exécution du programme ;
(4) Si une anomalie est détectée trois fois de suite, le processus démon forcera le système d'exploitation à redémarrer après le redémarrage du système, garantissant que le programme se charge et s'exécute normalement ;
(A) Afin de réaliser les fonctions ci-dessus, le programme ne se limite pas à la forme EXE et la forme de mise en œuvre peut être décidée par soi-même en fonction des besoins.
(B) Les fonctions ci-dessus sont toutes implémentées dans l'environnement d'exploitation normal de Windows 2000 et sous les autorisations d'administrateur. Il n'est pas nécessaire de prendre en compte le mode de sécurité ou les autorisations de Windows ni d'autres problèmes.
4. Veuillez utiliser des bases de données de bureau simples, telles qu'Access, xBase et d'autres bases de données de fichiers.
5. Chaque événement généré contient au moins deux informations : l'heure de l'occurrence de l'événement et l'objet de traitement de l'événement.
Les données d'événement sont stockées dans la base de données dans la table tEvent. La table tEvent contient au moins deux champs :
(1) Champ EventTime : type heure/date. Enregistrez l’heure à laquelle l’événement s’est produit.
(2) Champ EventTarget : type de caractère. Enregistre les objets tués lors de l'événement. Les objets à considérer sont le processus Bloc-notes et le processus Calculatrice.
Si vous avez besoin d'autres tables ou champs, vous pouvez les ajouter selon vos besoins.
6. Le format de transmission des données réseau est personnalisé. Veuillez décider du contenu spécifique et du format de transmission en fonction de vos besoins, et il n'y a pas d'exigences spécifiques. Le réseau client doit fonctionner en conjonction avec le réseau serveur.
7. Il n'y a aucune limite quant au langage de développement et à l'environnement de développement intégré utilisés, vous pouvez les choisir vous-même.
8. Pour la méthode de connexion à la base de données, veuillez choisir en fonction de vos besoins.
2. Le programme côté serveur s'appelle Server. Surveillez le réseau et une fois qu'un client télécharge des données, les informations sur l'événement sont immédiatement extraites et affichées dans une liste dans l'interface utilisateur.
1. L'environnement d'exploitation cible est le système d'exploitation Windows 2000.
2. Le programme doit être conçu comme une application GUI Windows 2000 ordinaire. L'interface utilisateur doit contenir au moins une liste d'informations sur les événements, qui contient au moins trois éléments d'informations : l'heure d'occurrence de l'événement, l'objet de traitement de l'événement et la source de l'événement.
(1) Heure d'occurrence de l'événement : identique à l'heure d'occurrence de l'événement client.
(2) Objet de traitement d'événements : identique à l'objet de traitement d'événements client.
(3) Source de l'événement : adresse IP de la machine client qui a téléchargé l'événement en cours.
3. Le format de transmission des données réseau est personnalisé et fonctionne en collaboration avec le client.
4. Il n'y a aucune limite quant au langage de développement et à l'environnement de développement intégré utilisés, vous pouvez les choisir vous-même.
Instructions pour exécuter le programme :
client.ini doit être placé dans le répertoire racine du lecteur C. D'autres fichiers peuvent être placés n'importe où, mais survival.exe et client.exe doivent être placés dans le même dossier. Avant de démarrer survival.exe, veuillez configurer l'adresse IP du serveur (interval_server). ) dans client.ini ), puis démarrez ADServer.exe.
Description du code source 1. Serveur ADServer.exe
Parce que le côté serveur est simple, parlons d'abord du côté serveur :)
Le travail du serveur est de recevoir les données du réseau et d'utiliser la transmission bloquante TServerSocket. Chaque fois que TServerSocket reçoit une demande de connexion d'un client, il génère un thread TServerClientThread. Vous devez créer un nouveau TWinSocketStream dans ce thread pour lire et écrire les données du client. Le code principal est écrit dans la partie ClientExecute de ce fil.
Il n'y a aucun problème avec l'écriture de données par TWinSocketStream sur le client, mais la lecture des données du client (à l'aide de la méthode read) est souvent renvoyée avant la fin de la lecture, même si vous utilisez WaitForData. J'ai donc écrit une fonction waitDateComplete pour attendre que les données soient lues.
2. Client Le client est un peu plus gênant. Client.exe est un service et survival.exe est une application. Les deux se surveillent mutuellement. Si l'un est arrêté, l'autre le redémarrera. hookDll.dll est utilisé pour les hooks. Les hooks globaux doivent être écrits dans des modules dll indépendants (à l'exception de quelques hooks, veuillez vous référer à cet article : http://www.pconline.com.cn/pcedu/empolder/gj/vc/. 0403/340480.html).
Client.exe ne contient pas quelques lignes de code. Il utilise principalement CreateProcess pour démarrer le processus. Notez que si le service souhaite effectuer des opérations liées au shell Windows, telles que les hooks utilisés dans hookdll.dll démarré par ce programme, le ServiceType doit être défini sur stWin32 et la propriété TService::Interactive doit être définie sur true.
survival.exe est utilisé pour démarrer le service, charger hookdll.dll et signaler les événements au serveur.
1. Le démarrage du service nécessite trois processus. Tout d'abord, ouvrez le contrôleur de service, qui est le backend du « service » dans l'outil de gestion. Utilisez OpenSCManager pour obtenir le handle du gestionnaire de services, puis utilisez OpenService (handle du gestionnaire de services, nom du service). , SERVICE_START | SERVICE_QUERY_STATUS) pour obtenir le handle du service spécifié, et enfin vous pouvez utiliser StartService(...) pour ouvrir le service. Notez qu'au moins les deux autorisations, SERVICE_START et SERVICE_QUERY_STATUS, doivent être obtenues.
2. En termes de chargement de hookdll.dll, ce programme utilise des liens implicites, c'est-à-dire en utilisant le projetAjouter au projet de BCB pour importer le fichier lib de la dll. Après l'import, si la fonction de la dll n'est pas appelée dans le code, la dll ne sera pas chargée. Ce programme appelle la fonction beginTrace (hôte HWND) pour transmettre le handle de fenêtre de survival.exe, et la DLL envoie des messages à survival.exe via ce handle.
3. En termes de rapport d'événements au serveur, une classe TMSocketClient a été spécialement écrite, qui est principalement responsable du processus d'envoi de messages -> réception des reçus de messages. Le code principal est dans TMSocketClient::Command (….). le code dans ADServer.exe, il est très simple à lire. En #définissant différentes constantes de commande, ce module peut effectuer de nombreux types de tâches de transmission. En fait, ce module est une classe que j'ai écrite dans le passé pour simuler TNMFTP. Il a été simplifié en supprimant de nombreux #defines et utilisé pour transférer des fichiers dans un LAN virtuel (TNMFTP ne peut pas fonctionner dans un LAN virtuel).
3. hookDll.dll
Le code est très simple, il suffit de faire attention à une chose, c'est à dire que si N processus appellent la même dll, cette dll sera copiée N fois. De manière générale, différentes copies de ces N dll ont chacune leurs propres segments de données. C'est-à-dire que la valeur de leur même variable dans chaque copie est différente et n'interfère pas les unes avec les autres. Mais en fait, Windows a laissé un tel mécanisme qui nous permet de déclarer une telle variable dans une DLL et de maintenir la cohérence des données entre N instances de la DLL, tout comme s'il s'agissait d'un pointeur qui transcende l'espace de processus. Pour déclarer une telle variable, créez d'abord un fichier .def avec le même nom que la dll et écrivez dans le fichier :
SECTIONS
SHSEG LIRE ÉCRIRE PARTAGER
Ensuite, déclarez les variables DLL que vous souhaitez partager entre les processus en tant que variables globales et initialisez ces variables. Notez que la différence entre partager et ne pas partager est de savoir s'il est initialisé !
Ce programme fait référence à "Application of Hooks: Program Running Monitoring" sur CCRun. Merci à l'auteur Victor Chen.
OK, il semble que c’est essentiellement tout ce qu’il y a à expliquer. De plus, il y a des variables inutiles dans le programme, je n'ai pas le temps de les nettoyer. Veuillez me pardonner :) Merci d'avoir regardé !
Développer
