2 - Windows API
A - Interaction
A. Introduction : Win32 API et rôle général
B. User Mode vs Kernel Mode
C. Communication entre User Mode et Kernel Mode
D. Switching Point (transition des modes)
E. Runtime et Win32 API (chaîne d’exécution)
🧠 Résumé global
B - Win32 API Structure
A. Vue d’ensemble du Win32 API
B. Structure générale du Win32 API
C. Résumé global du modèle
🧠 Conclusion
C - OS Librairies Header Files + P/Invoke
A. Contexte : API calls et mémoire
B. Windows Header File (windows.h)
C. P/Invoke (Platform Invoke)
D. Étape 1 — Importation DLL avec P/Invoke
E. Étape 2 — Déclaration de fonction externe
F. Résumé global
🧠 Conclusion
D - Win32 API Calls - Naming Scheme & I/O Parameters
A. API Calls dans Win32
B. Système de nommage des API calls
C. Structure des paramètres I/O
D. Exemple : WriteProcessMemory
E. Remarque importante
🧠 Conclusion
E - C API call
A. Préparation : utilisation de Windows API en C/C++
B. Objectif du task : CreateWindowExA
C. API utilisée : CreateWindowExA
D. Explication des paramètres
E. Exemple d’appel CreateWindowExA
F. Explication de l’appel
G. Exemple d’application complète
H. Explication du fonctionnement
I. Conclusion
F - .NET and Powershell API Call
A. Principe général de P/Invoke
B. Exemple .NET — Import d’une API Win32
C. Exemple d’utilisation .NET
D. Adaptation en PowerShell
E. Définition des API calls en PowerShell
F. Compilation avec Add-Type
G. Utilisation des API en PowerShell
🧠 Conclusion
G - Abuse API Call
A. Contexte : API Win32 et usage malveillant
B. API calls les plus abusés
1. LoadLibraryA
2. GetUserNameA
3. GetComputerNameA
4. GetVersionExA
5. GetModuleFileNameA
6. GetStartupInfoA
7. GetModuleHandle
8. GetProcAddress
9. VirtualProtect
C. Résumé global
🧠 Conclusion
A - Interaction
A. Introduction : Win32 API et rôle général
📌 Problème initial
Les programmes doivent parfois :
accéder aux sous-systèmes Windows
interagir avec le matériel
Mais ces accès sont restreints pour éviter l’instabilité du système
📌 Solution Microsoft
Introduction du Win32 API
Rôle :
bibliothèque d’interface
pont entre :
applications user-mode
kernel Windows
§
B. User Mode vs Kernel Mode
Windows sépare l’exécution en deux modes principaux :
§
👤 User Mode
❌ Pas d’accès direct au matériel
Accès uniquement à la mémoire “appartenant” au processus
Mode standard des applications
🧱 Kernel Mode
✔ Accès direct au matériel
✔ Accès à toute la mémoire physique
Utilisé par :
kernel
drivers
§
📊 Tableau comparatif
Mode Accès matériel Mémoire
User mode Aucun accès direct mémoire limitée au processus
Kernel mode accès direct mémoire physique complète
§
C. Communication entre User Mode et Kernel Mode
🔄 Mécanisme principal
Les deux modes communiquent via :
API calls
System calls
📌 Rôle des appels :
transmettre des instructions au système
déclencher un traitement en kernel mode
D. Switching Point (transition des modes)
📌 Concept
Représente le point de passage :
User mode → Kernel mode
📌 Schéma logique
Application en user mode
appel API
passage via switching point
exécution en kernel mode
§
E. Runtime et Win32 API (chaîne d’exécution)
📌 Cas des langages modernes
Le processus peut être “modifié” par une couche intermédiaire :
🔁 Chaîne typique :
Application
Runtime du langage
Win32 API
Kernel
📌 Effet
Ajoute une couche supplémentaire entre :
code utilisateur
API Windows
🧠 Résumé global
Windows impose une séparation stricte :
User Mode = exécution limitée
Kernel Mode = contrôle total système
Le Win32 API agit comme pont sécurisé
Les interactions système passent toujours par :
API calls
system calls
Les langages modernes ajoutent souvent un runtime intermédiaire avant l’API
§
B - Win32 API Structure
§
A. Vue d’ensemble du Win32 API
📌 Définition
Le Win32 API (Windows API) est composé de plusieurs couches dépendantes
Ces couches définissent :
la structure
l’organisation
le fonctionnement des appels API
📌 Approche utilisée
Analyse top-down
du niveau le plus haut (API)
vers le niveau le plus bas (paramètres)
B. Structure générale du Win32 API
📊 Hiérarchie des couches
§
1. API
Définition :
terme général
représente tout appel Win32 API
§
2. Header files / Imports
Définition :
fichiers d’en-tête
bibliothèques importées au runtime
Fonction :
définissent les dépendances externes
utilisent des pointeurs
permettent de récupérer les adresses des fonctions
§
3. Core DLLs
Groupe de DLL principales :
KERNEL32
USER32
ADVAPI32
Rôle :
définissent les services kernel et user
ne sont pas contenus dans un seul sous-système
§
4. Supplemental DLLs
Autres DLLs Windows API
Exemples :
NTDLL
COM
FVEAPI
Caractéristiques :
environ 36 DLLs supplémentaires
gèrent des sous-systèmes spécifiques de Windows
§
5. Call Structures
Définition :
structure de l’appel API
définit :
fonction utilisée
paramètres associés
§
6. API Calls
Définition :
appel API réellement utilisé dans un programme
obtenu via des pointeurs vers les fonctions
§
7. In / Out Parameters
Définition :
valeurs passées dans l’appel API
Types :
Input parameters → données envoyées à la fonction
Output parameters → résultats retournés ou modifiés
§
C. Résumé global du modèle
📌 Hiérarchie complète (top → bottom)
API (concept global)
Header files / imports
Core DLLs (KERNEL32, USER32, ADVAPI32)
Supplemental DLLs (NTDLL, COM, FVEAPI…)
Call structures
API calls (via pointers)
In/Out parameters
§
🧠 Conclusion
Le Win32 API est organisé en couches dépendantes
Chaque couche :
abstrait la précédente
ajoute un niveau de structure ou d’accès
L’appel API final dépend :
des DLLs
des pointeurs de fonctions
des paramètres d’entrée/sortie
§
C - OS Librairies Header Files + P/Invoke
§
A. Contexte : API calls et mémoire
📌 Principe fondamental
Chaque API call Win32 :
existe en mémoire
nécessite un pointeur vers une adresse mémoire
📌 Problème principal : ASLR
ASLR (Address Space Layout Randomization) :
rend les adresses mémoire dynamiques
empêche de connaître les adresses fixes des fonctions
📌 Conséquence
Il faut des mécanismes pour :
retrouver les adresses des fonctions
obtenir des pointeurs valides
📌 Solutions abordées :
Windows Header File
P/Invoke
§
§
B. Windows Header File (windows.h)
📌 Rôle général
Solution Microsoft pour gérer les problèmes liés à ASLR
Permet d’accéder facilement aux API Win32
🔧 Fonctionnement (théorie) §
Lors du runtime :
le loader Windows analyse les appels API
il construit une thunk table
table de résolution d’adresses de fonctions
permet d’obtenir les pointeurs des API
§
📌 Utilisation
1 #include <windows.h>
📌 Effet :
permet d’appeler directement les fonctions Win32
dans un programme unmanaged
sans gérer manuellement les pointeurs
§
📌 Résultat attendu :
accès direct aux API Win32
résolution automatique des adresses via le loader
§
C. P/Invoke (Platform Invoke)
📌 Définition officielle
Technologie permettant :
d’accéder aux fonctions
structs
callbacks
provenant de bibliothèques unmanaged depuis du code managed
§
📌 Objectif
appeler des API Win32 depuis du code managé (ex: C#)
§
D. Étape 1 — Importation DLL avec P/Invoke
1 using System;
2 using [Link];
3
4 public class Program
5 {
6 [DllImport("[Link]", CharSet = [Link], SetLastError = true)]
7 ...
8 }
📌 Explication
using System;
importe les fonctionnalités de base .NET
using [Link];
donne accès à P/Invoke
[DllImport("[Link]")]
importe la DLL [Link]
permet d’accéder aux fonctions Win32 contenues dedans
CharSet = [Link]
définit l’encodage des chaînes (Unicode)
SetLastError = true
permet de récupérer les erreurs Windows
📌 Résultat attendu :
DLL chargée dans le programme managé
fonctions accessibles via déclaration externe
§
E. Étape 2 — Déclaration de fonction externe
1 using System;
2 using [Link];
3
4 public class Program
5 {
6 ...
7 private static extern int MessageBox(IntPtr hWnd, string lpText, string lpCaption, uint
uType);
8 }
📌 Explication
private static extern int MessageBox(...)
déclaration d’une fonction externe (non implémentée en C#)
§
📌 Paramètres :
IntPtr hWnd
handle de la fenêtre parent
string lpText
texte affiché dans la MessageBox
string lpCaption
titre de la fenêtre
uint uType
type de message box (boutons, icônes)
§
📌 Mécanisme
C# appelle une fonction managée
mais exécutée via DLL unmanaged ( [Link] )
§
📌 Résultat attendu :
appel indirect à la fonction Windows API
exécution réelle dans la DLL système
§
F. Résumé global
📌 Problème
ASLR rend les adresses mémoire dynamiques
nécessite une résolution de pointeurs
§
📌 Solutions
1. Windows Header File
utilise windows.h
loader Windows + thunk table
résolution automatique des fonctions
2. P/Invoke
utilisé en C# / code managé
importe DLL via [DllImport]
déclare fonctions externes avec extern
§
🧠 Conclusion
Toutes les API Win32 résident en mémoire
ASLR empêche les adresses fixes
Deux méthodes principales permettent d’y accéder :
Windows header file (unmanaged)
P/Invoke (managed)
Les deux servent à obtenir des pointeurs fonctionnels vers les API Windows
§
D - Win32 API Calls - Naming Scheme & I/O Parameters
A. API Calls dans Win32
📌 Définition
Les API calls sont un composant principal du Win32 API
Ils offrent :
extensibilité
flexibilité
adaptation à différents cas d’usage
§
📌 Documentation
Les API calls sont documentés sur :
Windows API documentation
[Link]
§
B. Système de nommage des API calls
📌 Principe
Les API Windows peuvent être modifiées via des suffixes
Ces suffixes changent :
encodage
comportement
fonctionnalités
§
📊 Tableau des suffixes
Caractère Signification
A 8-bit character set (ANSI encoding)
W Unicode encoding
Ex fonctionnalités étendues / paramètres supplémentaires
§
📌 Explication détaillée
🔹 A
version ANSI
utilise encodage 8-bit
🔹 W
version Unicode
utilisé par défaut dans Windows moderne
🔹 Ex
version étendue de la fonction
ajoute :
fonctionnalités supplémentaires
paramètres in/out supplémentaires
§
C. Structure des paramètres I/O
📌 Principe général
Chaque API call possède une structure définie :
paramètres d’entrée (input)
paramètres de sortie (output)
§
📌 Documentation
chaque fonction Windows API contient :
description des paramètres
type attendu
valeurs acceptées
rôle input/output
§
D. Exemple : WriteProcessMemory
📌 API utilisée
1 BOOL WriteProcessMemory(
2 [in] HANDLE hProcess,
3 [in] LPVOID lpBaseAddress,
4 [in] LPCVOID lpBuffer,
5 [in] SIZE_T nSize,
6 [out] SIZE_T *lpNumberOfBytesWritten
7 );
§
§
📌 Explication des paramètres
1. HANDLE hProcess
[in]
handle du processus cible
👉 rôle :
identifier le processus où écrire
2. LPVOID lpBaseAddress
[in]
adresse mémoire cible
👉 rôle :
zone mémoire où écrire les données
§
3. LPCVOID lpBuffer
[in]
buffer source
👉 rôle :
données à écrire dans le processus
§
4. SIZE_T nSize
[in]
taille des données
👉 rôle :
nombre d’octets à écrire
§
5. SIZE_T *lpNumberOfBytesWritten
[out]
pointeur vers variable de sortie
👉 rôle :
retourne le nombre d’octets réellement écrits
§
E. Remarque importante
📌 Problème courant
Certains API calls sont complexes à interpréter :
paramètres ambigus
documentation dense
📌 Recommandation
Toujours :
rechercher des exemples d’utilisation
analyser des implémentations réelles avant usage
§
🧠 Conclusion
Les API calls Win32 sont :
très flexibles
fortement documentés
structurés en input/output parameters
Le nom des fonctions dépend de suffixes :
A , W , Ex
Les paramètres sont clairement définis mais nécessitent souvent :
étude de cas pratiques pour être bien compris
§
E - C API call
A. Préparation : utilisation de Windows API en C/C++
📌 Support Microsoft
Microsoft fournit des langages bas niveau :
C
C++
Ces langages permettent :
accès direct aux API Win32
utilisation de bibliothèques préconfigurées
§
📌 Inclusion du header Windows
1 #include <windows.h>
📌 Explication
inclut le fichier header Windows
permet d’accéder à :
structures API
fonctions Win32
pointeurs de fonctions
§
§
B. Objectif du task : CreateWindowExA
📌 Objectif
Créer une fenêtre pop-up avec :
titre : "Hello THM!"
§
C. API utilisée : CreateWindowExA
📌 Signature complète
1 HWND CreateWindowExA(
2 [in] DWORD dwExStyle,
3 [in, optional] LPCSTR lpClassName,
4 [in, optional] LPCSTR lpWindowName,
5 [in] DWORD dwStyle,
6 [in] int X,
7 [in] int Y,
8 [in] int nWidth,
9 [in] int nHeight,
10 [in, optional] HWND hWndParent,
11 [in, optional] HMENU hMenu,
12 [in, optional] HINSTANCE hInstance,
13 [in, optional] LPVOID lpParam
14 );
§
D. Explication des paramètres
1. DWORD dwExStyle
style étendu de la fenêtre
optionnel
§
§
2. LPCSTR lpClassName
nom de la classe de fenêtre
§
3. LPCSTR lpWindowName
texte affiché dans la barre de titre
4. DWORD dwStyle
style de la fenêtre
exemple : fenêtre standard
§
5. int X
position horizontale de la fenêtre
§
6. int Y
position verticale de la fenêtre
§
7. int nWidth
largeur de la fenêtre
§
8. int nHeight
hauteur de la fenêtre
9. HWND hWndParent
handle de la fenêtre parent
§
10. HMENU hMenu
menu associé à la fenêtre
§
11. HINSTANCE hInstance
instance de l’application
§
12. LPVOID lpParam
données supplémentaires
§
§
E. Exemple d’appel CreateWindowExA
📌 Code complet
1 HWND hwnd = CreateWindowsEx(
2 0,
3 CLASS_NAME,
4 L"Hello THM!",
5 WS_OVERLAPPEDWINDOW,
6 CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
7 NULL,
8 NULL,
9 hInstance,
10 NULL
11 );
§
F. Explication de l’appel
📌 Paramètres utilisés :
0
pas de style étendu
CLASS_NAME
classe de la fenêtre
L"Hello THM!"
titre de la fenêtre
WS_OVERLAPPEDWINDOW
style standard de fenêtre
CW_USEDEFAULT
position et taille par défaut
NULL
pas de parent
NULL
pas de menu
hInstance
instance du programme
NULL
pas de paramètres supplémentaires
§
📌 Résultat attendu
création d’une fenêtre Windows
titre affiché :
Hello THM!
§
G. Exemple d’application complète
📌 Fonction Create()
1 BOOL Create(
2 PCWSTR lpWindowName,
3 DWORD dwStyle,
4 DWORD dwExStyle = 0,
5 int x = CW_USEDEFAULT,
6 int y = CW_USEDEFAULT,
7 int nWidth = CW_USEDEFAULT,
8 int nHeight = CW_USEDEFAULT,
9 HWND hWndParent = 0,
10 HMENU hMenu = 0
11 )
12 {
13 WNDCLASS wc = {0};
14
15 [Link] = DERIVED_TYPE::WindowProc;
16 [Link] = GetModuleHandle(NULL);
17 [Link] = ClassName();
18
19 RegisterClass(&wc);
20
21 m_hwnd = CreateWindowEx(
22 dwExStyle, ClassName(), lpWindowName, dwStyle, x, y,
23 nWidth, nHeight, hWndParent, hMenu, GetModuleHandle(NULL), this
24 );
25
26 return (m_hwnd ? TRUE : FALSE);
27 }
§
§
H. Explication du fonctionnement
📌 Étapes internes :
1. Initialisation WNDCLASS
structure de la fenêtre
2. Définition du Window Procedure
1 [Link] = DERIVED_TYPE::WindowProc;
gère les événements de la fenêtre
§
3. Enregistrement de la classe
1 RegisterClass(&wc);
enregistre la classe dans Windows
§
4. Création de la fenêtre
1 CreateWindowEx(...)
instancie la fenêtre réelle
§
§
5. Vérification du succès
1 return (m_hwnd ? TRUE : FALSE);
TRUE = succès
FALSE = échec
§
📌 Résultat attendu
fenêtre créée et affichée
gestion via WindowProc
§
I. Conclusion
windows.h permet d’accéder directement aux API Win32
CreateWindowExA permet de créer une fenêtre avec paramètres complets
chaque paramètre contrôle :
style
position
taille
comportement
les langages C/C++ facilitent fortement :
interaction avec Windows API
manipulation bas niveau du système
§
F - .NET and Powershell API Call
A. Principe général de P/Invoke
📌 Définition
P/Invoke (Platform Invoke) permet :
d’importer des DLL Windows
d’appeler des fonctions Win32 (unmanaged)
depuis du code managé (.NET)
📌 Objectif
créer des pointeurs vers des API calls
exécuter des fonctions Windows directement depuis C# / PowerShell
B. Exemple .NET — Import d’une API Win32
📌 Code principal
1 class Win32 {
2 [DllImport("kernel32")]
3 public static extern IntPtr GetComputerNameA(StringBuilder lpBuffer, ref uint lpnSize);
4 }
§
📌 Explication des composants
🔹 class Win32
classe conteneur
stocke les API Win32 importées
permet réutilisation dans tout le programme
§
🔹 [DllImport("kernel32")]
importe la DLL [Link]
permet d’accéder aux fonctions Win32 contenues dedans
§
🔹 public static extern IntPtr GetComputerNameA(...)
déclaration d’une fonction externe
extern = fonction non implémentée en C#
IntPtr = pointeur vers une adresse mémoire
📌 Paramètres de la fonction
1. StringBuilder lpBuffer
buffer de sortie
contient le nom du PC
2. ref uint lpnSize
taille du buffer
entrée + sortie (modifiable)
§
📌 Résultat attendu
fonction retourne :
nom de la machine Windows
valeur stockée dans lpBuffer
§
§
C. Exemple d’utilisation .NET
📌 Code complet
1 class Win32 {
2 [DllImport("kernel32")]
3 public static extern IntPtr GetComputerNameA(StringBuilder lpBuffer, ref uint lpnSize);
4 }
5
6 static void Main(string[] args) {
7 bool success;
8 StringBuilder name = new StringBuilder(260);
9 uint size = 260;
10 success = GetComputerNameA(name, ref size);
11 [Link]([Link]());
12 }
§
📌 Explication
🔹 StringBuilder name = new StringBuilder(260);
buffer de 260 caractères
reçoit le nom de la machine
🔹 uint size = 260;
taille initiale du buffer
🔹 GetComputerNameA(name, ref size);
appel de l’API Win32
remplit name avec le hostname
🔹 [Link]([Link]());
affiche le résultat
§
📌 Résultat attendu
1 DESKTOP-XXXXXX
§
D. Adaptation en PowerShell
📌 Principe
similaire à .NET
mais syntaxe adaptée PowerShell
nécessite Add-Type
§
E. Définition des API calls en PowerShell
📌 Code
1 $MethodDefinition = @"
2 [DllImport("kernel32")]
3 public static extern IntPtr GetProcAddress(IntPtr hModule, string procName);
4 [DllImport("kernel32")]
5 public static extern IntPtr GetModuleHandle(string lpModuleName);
6 [DllImport("kernel32")]
7 public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint
flNewProtect, out uint lpflOldProtect);
8 "@;
§
📌 Explication
🔹 $MethodDefinition
contient les signatures des API Win32
bloc de code C# injecté dans PowerShell
§
🔹 GetProcAddress
récupère l’adresse d’une fonction exportée par une DLL
🔹 GetModuleHandle
obtient le handle d’un module chargé en mémoire
🔹 VirtualProtect
modifie les permissions mémoire
permet de changer :
lecture
écriture
exécution
§
📌 Résultat attendu
définition des fonctions Win32 en mémoire
prêt à être compilé dans PowerShell
§
F. Compilation avec Add-Type
📌 Code
1 $Kernel32 = Add-Type -MemberDefinition $MethodDefinition -Name 'Kernel32' -NameSpace 'Win32' -
PassThru;
§
📌 Explication
🔹 Add-Type
compile dynamiquement le code C#
utilise [Link] en arrière-plan
génère un type .NET utilisable
🔹 -MemberDefinition $MethodDefinition
injecte les API définies
🔹 -Name 'Kernel32'
nom de la classe générée
🔹 -NameSpace 'Win32'
namespace utilisé
🔹 -PassThru
retourne l’objet compilé
§
📌 Résultat attendu
création d’un type .NET temporaire
accessible depuis PowerShell
§
G. Utilisation des API en PowerShell
📌 Syntaxe
1 [Win32.Kernel32]::<Imported Call>() §
📌 Explication
accès direct à la classe compilée
appel de la fonction Win32 importée
exécution de l’API dans PowerShell
§
📌 Résultat attendu
exécution de la fonction Windows API
retour de la valeur associée
§
🧠 Conclusion
P/Invoke permet d’appeler des API Win32 depuis .NET
Les fonctions sont déclarées avec :
[DllImport]
extern
types de paramètres exacts
PowerShell utilise :
Add-Type
compilation dynamique via [Link]
Les deux approches permettent :
accès direct aux DLL Windows
manipulation des API système depuis code managé
§
G - Abuse API Call
A. Contexte : API Win32 et usage malveillant
📌 Observation générale
Certaines API Win32 sont fréquemment utilisées pour des activités malveillantes
Elles sont documentées et analysées par plusieurs organisations :
SANS
[Link]
§
📌 Objectif de ces ressources
identifier :
API calls abusés
vecteurs d’attaque associés
techniques utilisées en malware
§
B. API calls les plus abusés
📊 Tableau des API couramment utilisées
§
1. LoadLibraryA
📌 Description
1 Maps a specified DLL into the address space of the calling process
📌 Explication
charge une DLL dans un processus
permet d’importer dynamiquement du code
📌 Résultat attendu
DLL injectée dans l’espace mémoire du processus
§
2. GetUserNameA
📌 Description
1 Retrieves the name of the user associated with the current thread
📌 Explication
récupère le nom de l’utilisateur courant
📌 Résultat attendu
chaîne contenant le username Windows
§
3. GetComputerNameA
📌 Description
1 Retrieves a NetBIOS or DNS name of the local computer
📌 Explication
récupère le nom de la machine
📌 Résultat attendu
hostname du système
§
4. GetVersionExA
📌 Description
1 Obtains information about the version of the operating system currently running
📌 Explication
récupère les informations de version OS
📌 Résultat attendu
version Windows (OS build / edition)
§
§
5. GetModuleFileNameA
📌 Description
1 Retrieves the fully qualified path for the file of the specified module and process
📌 Explication
récupère le chemin complet d’un module chargé
📌 Résultat attendu
chemin du fichier exécutable ou DLL
§
6. GetStartupInfoA
📌 Description
1 Retrieves contents of STARTUPINFO structure (window station, desktop, standard handles, and
appearance of a process)
📌 Explication
récupère les informations de démarrage d’un processus
📌 Résultat attendu
structure STARTUPINFO remplie
§
§
7. GetModuleHandle
📌 Description
1 Returns a module handle for the specified module if mapped into the calling process's address
space
📌 Explication
obtient un handle de module déjà chargé
📌 Résultat attendu
handle vers une DLL ou module
§
8. GetProcAddress
📌 Description
1 Returns the address of a specified exported DLL function
📌 Explication
récupère l’adresse mémoire d’une fonction exportée
📌 Résultat attendu
pointeur vers fonction DLL
§
9. VirtualProtect
📌 Description
1 Changes the protection on a region of memory in the virtual address space of the calling
process
📌 Explication
modifie les permissions mémoire :
lecture
écriture
exécution
📌 Résultat attendu
changement des droits sur une zone mémoire
§
C. Résumé global
📌 Observation principale
ces API sont légitimes
mais souvent utilisées dans :
malware
injection de code
reconnaissance système
§
📌 Catégories d’usage
🔍 Reconnaissance système :
GetComputerNameA
GetUserNameA
GetVersionExA
📦 Manipulation modules :
LoadLibraryA
GetModuleHandle
GetProcAddress
🧠 Manipulation mémoire :
VirtualProtect
§
🧠 Conclusion
Plusieurs API Win32 sont double usage :
administration système légitime
exploitation malveillante
Les plus critiques permettent :
chargement de DLL
résolution de fonctions dynamiques
modification mémoire
§