Cours sur l''achitecture user mode et kernel mode
Posted: Thu Feb 05, 2026 2:41 pm
# Architecture interne de Windows (User Mode, Kernel Mode, NTDLL)
Salut
cours a pour objectif de te donner une **compréhension opérationnelle** de l’architecture interne de Windows, afin de savoir **où s’exécute le code**, **comment une application parle au noyau**, et **quels composants sont réellement critiques**.
On ne parle pas de théorie abstraite, mais de **flux réels d’exécution**, **frontières de sécurité**, et **comportements internes observables**, comme les comprennent les développeurs système, analystes malware et reverseurs.
---
## 1. Comprendre l’architecture Windows avant toute analyse
Avant de comprendre un malware, un exploit ou un crash, il faut **comprendre le terrain** :
comment Windows est structuré et **où passent les frontières de privilèges**.
---
### 1.1 User mode et Kernel mode (la base absolue)
Windows repose sur une séparation stricte des privilèges CPU.
**User mode** :
* Exécution non privilégiée
* Aucune interaction directe avec le matériel
* Accès limité à la mémoire
* Un crash ne fait tomber que le processus
**Kernel mode** :
* Exécution totalement privilégiée
* Accès au matériel et à toute la mémoire
* Gestion des threads, de la mémoire, des interruptions
* Une erreur entraîne un BSOD
Cette séparation est la **première barrière de sécurité** du système.
---
### 1.2 Pourquoi les applications ne parlent jamais directement au noyau
Une application Windows **ne peut pas** appeler directement une fonction kernel.
Toute transition se fait :
```
Application
→ DLL Win32 (kernel32.dll, user32.dll, advapi32.dll)
→ ntdll.dll
→ syscall / sysenter
→ kernel mode
```
Cette architecture empêche :
* l’accès direct aux structures internes
* les corruptions mémoire globales
* l’exécution arbitraire privilégiée
---
## 2. Le rôle central de NTDLL.dll
NTDLL.dll est la **frontière réelle** entre le monde utilisateur et le noyau.
---
### 2.1 Stubs d’appels système
NTDLL contient les fonctions :
* NtCreateFile
* NtReadFile
* NtCreateProcess
* NtQueryInformationProcess
Ces fonctions :
* préparent les paramètres
* exécutent l’instruction CPU de transition
* transfèrent le contrôle au noyau
Elles sont **peu documentées**, variables selon les versions de Windows,
et constituent une **cible classique d’instrumentation malware**.
---
### 2.2 Runtimes internes critiques
NTDLL fournit aussi :
* le loader PE (Ldr*)
* le heap bas niveau
* les fonctions Rtl*
* la gestion des exceptions
* les APC user-mode
Sans NTDLL, **aucun processus Windows ne démarre**.
---
## 3. Les sous-systèmes Windows
Windows implémente des **environnements d’exécution**, appelés sous-systèmes.
---
### 3.1 Le sous-système Windows (Win32)
C’est le sous-système principal.
Il comprend :
* csrss.exe (Client/Server Runtime Subsystem)
* win32k.sys (GUI en kernel mode)
* conhost.exe (console moderne)
* les DLL Win32
Csrss est un **processus critique** :
* sa terminaison provoque un crash immédiat
---
### 3.2 Pourquoi la GUI est en kernel mode
Contrairement à d’autres OS :
* la gestion des fenêtres
* le dessin graphique
* les entrées clavier / souris
sont exécutés en **kernel mode** via win32k.sys.
Avantage : performances
Inconvénient : surface d’attaque élargie
---
## 4. Le noyau Windows (Ntoskrnl.exe)
Le cœur du système est contenu dans **Ntoskrnl.exe**.
---
### 4.1 Executive vs Kernel
**Executive** :
* gestion des processus
* mémoire virtuelle
* sécurité
* I/O
* registre
* cache disque
Il implémente la **politique**.
**Kernel** :
* planification des threads
* interruptions
* synchronisation
* exceptions
Il implémente les **mécanismes bas niveau**.
---
### 4.2 Objets noyau et synchronisation
Le noyau repose sur des objets internes :
* threads
* mutex
* events
* semaphores
* timers
* APC / DPC
Ces objets contrôlent directement :
* l’ordonnancement
* la concurrence
* les attentes bloquantes
---
## 5. HAL et abstraction matérielle
Le **Hardware Abstraction Layer (HAL)** isole Windows du matériel réel.
Il masque :
* interruptions
* timers
* contrôleurs APIC
* DMA
* différences de cartes mères
Ainsi :
* le noyau reste portable
* les drivers restent compatibles
---
## 6. Les pilotes (drivers)
Les pilotes sont du **code kernel mode chargeable**.
Ils peuvent s’exécuter :
* dans le contexte d’un thread utilisateur
* dans un thread système
* en interruption
Installer un driver revient à **introduire du code dans le noyau**.
---
## 7. Méthodologie mentale pour l’analyse système
Quand tu analyses un système Windows, pose-toi toujours :
1. Ce code est-il en user ou kernel mode ?
2. Par quelle DLL passe-t-il ?
3. Y a-t-il une transition via NTDLL ?
4. Le comportement correspond-il au rôle du composant ?
---
## 8. Points clés à retenir
* NTDLL est la frontière user ↔ kernel
* Le noyau n’est jamais appelé directement
* La GUI Windows vit en kernel mode
* Les drivers sont le point le plus sensible
* Comprendre l’architecture rend les anomalies évidentes
---
## Conclusion
Windows est un système **strictement structuré**, pas un amas de DLL.
Quand tu comprends :
* où le code s’exécute
* comment il change de privilège
* quels composants sont critiques
alors les malwares, injections et comportements anormaux deviennent **beaucoup plus faciles à repérer**.
A bientôt pour un nouveau cours.
Salut
cours a pour objectif de te donner une **compréhension opérationnelle** de l’architecture interne de Windows, afin de savoir **où s’exécute le code**, **comment une application parle au noyau**, et **quels composants sont réellement critiques**.On ne parle pas de théorie abstraite, mais de **flux réels d’exécution**, **frontières de sécurité**, et **comportements internes observables**, comme les comprennent les développeurs système, analystes malware et reverseurs.
---
## 1. Comprendre l’architecture Windows avant toute analyse
Avant de comprendre un malware, un exploit ou un crash, il faut **comprendre le terrain** :
comment Windows est structuré et **où passent les frontières de privilèges**.
---
### 1.1 User mode et Kernel mode (la base absolue)
Windows repose sur une séparation stricte des privilèges CPU.
**User mode** :
* Exécution non privilégiée
* Aucune interaction directe avec le matériel
* Accès limité à la mémoire
* Un crash ne fait tomber que le processus
**Kernel mode** :
* Exécution totalement privilégiée
* Accès au matériel et à toute la mémoire
* Gestion des threads, de la mémoire, des interruptions
* Une erreur entraîne un BSOD
Cette séparation est la **première barrière de sécurité** du système.
---
### 1.2 Pourquoi les applications ne parlent jamais directement au noyau
Une application Windows **ne peut pas** appeler directement une fonction kernel.
Toute transition se fait :
```
Application
→ DLL Win32 (kernel32.dll, user32.dll, advapi32.dll)
→ ntdll.dll
→ syscall / sysenter
→ kernel mode
```
Cette architecture empêche :
* l’accès direct aux structures internes
* les corruptions mémoire globales
* l’exécution arbitraire privilégiée
---
## 2. Le rôle central de NTDLL.dll
NTDLL.dll est la **frontière réelle** entre le monde utilisateur et le noyau.
---
### 2.1 Stubs d’appels système
NTDLL contient les fonctions :
* NtCreateFile
* NtReadFile
* NtCreateProcess
* NtQueryInformationProcess
Ces fonctions :
* préparent les paramètres
* exécutent l’instruction CPU de transition
* transfèrent le contrôle au noyau
Elles sont **peu documentées**, variables selon les versions de Windows,
et constituent une **cible classique d’instrumentation malware**.
---
### 2.2 Runtimes internes critiques
NTDLL fournit aussi :
* le loader PE (Ldr*)
* le heap bas niveau
* les fonctions Rtl*
* la gestion des exceptions
* les APC user-mode
Sans NTDLL, **aucun processus Windows ne démarre**.
---
## 3. Les sous-systèmes Windows
Windows implémente des **environnements d’exécution**, appelés sous-systèmes.
---
### 3.1 Le sous-système Windows (Win32)
C’est le sous-système principal.
Il comprend :
* csrss.exe (Client/Server Runtime Subsystem)
* win32k.sys (GUI en kernel mode)
* conhost.exe (console moderne)
* les DLL Win32
Csrss est un **processus critique** :
* sa terminaison provoque un crash immédiat
---
### 3.2 Pourquoi la GUI est en kernel mode
Contrairement à d’autres OS :
* la gestion des fenêtres
* le dessin graphique
* les entrées clavier / souris
sont exécutés en **kernel mode** via win32k.sys.
Avantage : performances
Inconvénient : surface d’attaque élargie
---
## 4. Le noyau Windows (Ntoskrnl.exe)
Le cœur du système est contenu dans **Ntoskrnl.exe**.
---
### 4.1 Executive vs Kernel
**Executive** :
* gestion des processus
* mémoire virtuelle
* sécurité
* I/O
* registre
* cache disque
Il implémente la **politique**.
**Kernel** :
* planification des threads
* interruptions
* synchronisation
* exceptions
Il implémente les **mécanismes bas niveau**.
---
### 4.2 Objets noyau et synchronisation
Le noyau repose sur des objets internes :
* threads
* mutex
* events
* semaphores
* timers
* APC / DPC
Ces objets contrôlent directement :
* l’ordonnancement
* la concurrence
* les attentes bloquantes
---
## 5. HAL et abstraction matérielle
Le **Hardware Abstraction Layer (HAL)** isole Windows du matériel réel.
Il masque :
* interruptions
* timers
* contrôleurs APIC
* DMA
* différences de cartes mères
Ainsi :
* le noyau reste portable
* les drivers restent compatibles
---
## 6. Les pilotes (drivers)
Les pilotes sont du **code kernel mode chargeable**.
Ils peuvent s’exécuter :
* dans le contexte d’un thread utilisateur
* dans un thread système
* en interruption
Installer un driver revient à **introduire du code dans le noyau**.
---
## 7. Méthodologie mentale pour l’analyse système
Quand tu analyses un système Windows, pose-toi toujours :
1. Ce code est-il en user ou kernel mode ?
2. Par quelle DLL passe-t-il ?
3. Y a-t-il une transition via NTDLL ?
4. Le comportement correspond-il au rôle du composant ?
---
## 8. Points clés à retenir
* NTDLL est la frontière user ↔ kernel
* Le noyau n’est jamais appelé directement
* La GUI Windows vit en kernel mode
* Les drivers sont le point le plus sensible
* Comprendre l’architecture rend les anomalies évidentes
---
## Conclusion
Windows est un système **strictement structuré**, pas un amas de DLL.
Quand tu comprends :
* où le code s’exécute
* comment il change de privilège
* quels composants sont critiques
alors les malwares, injections et comportements anormaux deviennent **beaucoup plus faciles à repérer**.
A bientôt pour un nouveau cours.