Retour
Bon alors là je fais une parenthèse, car ça risque de se compliquer.
(Le mieux c'est encore de faire un schéma sur papier)
Dès qu'un 'debugging événement' se produit dans le programme cible, le débugger (ou ici notre Memory Patch)
l'enregistre dans une structure DEBUG_EVENT.
Nous, notre structure DEBUG_EVENT on l'a appelé DBEvent, mais ça aurait pu être un autre nom.
Enfin bon, quoi qu'il en soit on se réfèrera toujours au nom DBEvent quand on cherchera quelquechose contenu dans la structure DEBUG_EVENT.
Rappel :
DEBUG_EVENT
dwDebugEventCode; <-- quand un 'Debugging événement' se produit dans la cible, on le stocke ici!
dwProcessId; <-- on stocke le n°ID du Process cible.
dwThreadId <-- et on stoke aussi le n°ID du lien de la cible.
u <-- c'est une union, ou une option (on va y revenir plus tard car c'est là que ça se complique)
Bon, pour l'instant, si vous souhaitez savoir quel événement s'est produit dans la cible, il faudra donc
rechercher dans DBEvent.dwDebugEventCode (de gauche à droite on recherche
dans notre structure DBEvent dans son membre dwDebugEventCode car c'est lui qui retient quel type
d'événement s'est produit)...Ok! pas compliqué.
Maintenant revenons à 'u'.
Il y a 8 événements possibles
- EXCEPTION_DEBUG_INFO (Exception)
- CREATE_THREAD_DEBUG_INFO (CreateThread)
- CREATE_PROCESS_DEBUG_INFO (CreateProcessInfo) <-- il crée une structure 'Process_Info'
- EXIT_THREAD_DEBUG_INFO (ExitThread)
- EXIT_PROCESS_DEBUG_INFO (ExitProcess)
- LOAD_DLL_DEBUG_INFO (LoadDll)
- UNLOAD_DLL_DEBUG_INFO (UnloadDll)
- OUTPUT_DEBUG_STRING_INFO (DebugString)
'u' dépend entièrement de l'événement qui s'est produit. Si le 'Debugging événement' qui s'est produit dans la cible est
CREATE_PROCESS_DEBUG_EVENT, alors cet événement a été enregistré dans
dwDebugEventCode et en plus le débugger a créée une nouvelle structure (Process_Info)
dans laquelle il a récupéré plusieurs informations concernant le nouveau Process. Et les voici :
typedef struct _PROCESS_INFORMATION {/* pi */ Les nouvelles informations sont:
HANDLE hProcess; <-- le Handle du process cible
HANDLE hThread; <-- Le Handle du lien cible
DWORD dwProcessId; <-- Le n°ID du Process cible (qu'on a déjà d'ailleurs, grâce à DEBUG_EVENT!!)
DWORD dwThreadId; <-- Le n°ID du lien cible (Idem!!)
} PROCESS_INFORMATION;
Membre Description
hProcess Renvoie le HANDLE du process nouvellement créé. Grâce au HANDLE, on permet
toutes les opérations sur des objets appartenant à ce process.
hThread Renoie le HANDLE du lien nouvellement créé. Grâce au HANDLE, on permet
toutes les opérations sur des objets appartenant au lien.
dwProcessId Renvoie un n°ID de process Global lequel peut être employé pour identifier ce
process. Cette valeur sera valable à partir du moment où le process est créé
jusqu'à ce que celui-ci soit terminé.
dwThreadId Renvoie un n°ID de lien Global lequel peut être employé pour identifier ce lien.
Cette valeur sera valable à partir du moment où le lien est créé jusqu'à ce que
celui-ci soit terminé.
Donc voilà!!!
Si vous recherchez le Handle du programme cible, vous devez vous y prendre toujours de gauche à droite ainsi:
DBEvent.u.dwDebugEventCode.hProcess (car hProcess appartient à la structure PROCESS_INFO elle-même contenue dans la structure DEBUG_INFO)
Alors que si vous recherchez le n°ID du Process cible vous pouvez vous contenter de :
DBEvent.dwProcessID ( car il est directement accessible à partir de la structure DEBUG_EVENT)
Bon, pour ce qui concerne les autres événements, puisque le principe est vu, chacun se démerdera grâce au manuel W32API.
Retour