Cours sur l''achitecture user mode et kernel mode

[Hydraxx]

Salut,

dans ce cours on va voir l’architecture interne de Windows, avec une approche vraiment orientée compréhension système. Le but n’est pas de réciter trois noms comme user mode, kernel mode et ntdll.dll, mais de comprendre où le code s’exécute réellement, comment une application parle au noyau, où se situent les frontières de privilèges, et quels composants sont vraiment critiques quand on fait du développement système, du reverse engineering, du debug ou de l’analyse de comportement.

Autrement dit, ce cours sert à construire un modèle mental solide. Et ce modèle est capital, parce qu’une fois qu’on comprend bien la structure interne de Windows, beaucoup de choses qui paraissaient “mystérieuses” deviennent logiques : les syscalls, les transitions de privilèges, les injections, les hooks user-mode, les drivers, les crashes, les BSOD, les objets noyau, ou encore les limites réelles d’un malware user-mode.

Pourquoi ce sujet est fondamental

Comprendre l’architecture interne de Windows permet de mieux voir :

• où s’exécute réellement le code
• comment une application passe du user mode au kernel mode
• pourquoi une DLL comme ntdll.dll est centrale
• quel est le rôle réel de ntoskrnl.exe, win32k.sys et de la HAL
• où vivent les objets noyau, les syscalls, les interruptions et les drivers
• quelles sont les vraies frontières de sécurité du système
• pourquoi certains comportements sont visibles en user-mode, et d’autres non

En pratique, c’est une base obligatoire si tu veux comprendre Windows sérieusement.

1) Comprendre l’architecture Windows avant toute analyse

Avant d’essayer de comprendre un malware, un exploit, un rootkit ou un crash, il faut d’abord comprendre le terrain. Windows n’est pas un amas de DLL posé au hasard. C’est une architecture stratifiée, avec des frontières précises, des responsabilités différentes selon les couches, et un modèle de privilèges très strict.

Le point de départ absolu, c’est la séparation entre user mode et kernel mode.

1.1 User mode et kernel mode : base absolue

Windows repose sur une séparation stricte des privilèges CPU.

User mode :

• exécution non privilégiée
• pas d’accès direct au matériel
• pas d’accès libre à toute la mémoire physique ou virtuelle du système
• un crash affecte en général seulement le processus courant

Kernel mode :

• exécution privilégiée
• accès au matériel
• accès global à la mémoire
• gestion des threads, des interruptions, de la mémoire et des objets noyau
• une erreur sérieuse peut provoquer un bugcheck, donc un BSOD

Cette séparation est la première grande barrière de sécurité du système.

Il faut immédiatement retenir une règle simple :

Code: Select all

user mode = espace contrôlé
kernel mode = espace de confiance du système

Un code user-mode peut être malveillant ou bogué, mais il reste contenu par le modèle de privilèges. Un code kernel-mode, lui, a pratiquement les clés du système.

1.2 Rings CPU et privilèges réels

Dans la théorie x86/x64, le processeur possède plusieurs rings de privilèges. En pratique, Windows moderne utilise surtout :

• Ring 3 pour le user mode
• Ring 0 pour le kernel mode

Il faut connaitre cette idée, parce qu’elle explique pourquoi certaines instructions ne sont pas autorisées en user mode, et pourquoi une transition de privilège est une opération spéciale contrôlée par le CPU et par l’OS.

Le changement de ring n’est jamais “gratuit” ni libre. Il passe par un mécanisme de transition bien défini.

1.3 Pourquoi une application ne parle jamais directement au noyau

Une application Windows n’appelle pas directement une routine interne du noyau comme si elle appelait une fonction C ordinaire dans le meme espace.

Le flux réel est beaucoup plus proche de ceci :

Code: Select all

Application
↓
DLL Win32 ou API native user-mode
↓
ntdll.dll
↓
instruction de transition système
↓
kernel mode
↓
ntoskrnl.exe / sous-systèmes noyau

On peut le résumer aussi comme ceci :

Code: Select all

application
→ kernel32.dll / user32.dll / advapi32.dll / etc.
→ ntdll.dll
→ syscall
→ noyau

Cette architecture sert à :

• empêcher l’accès direct aux structures internes du noyau
• centraliser la transition de privilège
• contrôler les appels système
• maintenir une séparation claire entre les couches

2) Le rôle central de NTDLL.dll

Si on devait désigner une DLL vraiment critique dans le user-mode Windows, ce serait ntdll.dll.

Elle est essentielle, parce qu’elle constitue la vraie frontière entre le code user-mode “normal” et l’entrée vers le noyau.

2.1 NTDLL comme frontière user ↔ kernel

NTDLL contient les stubs des appels système natifs, par exemple :

• NtCreateFile
• NtReadFile
• NtWriteFile
• NtOpenProcess
• NtQueryInformationProcess
• NtAllocateVirtualMemory
• NtProtectVirtualMemory
• NtCreateSection
• NtMapViewOfSection
• NtCreateProcessEx
• NtCreateThreadEx

Ces fonctions :

• préparent les registres et les paramètres
• chargent le numéro de syscall approprié
• exécutent l’instruction CPU de transition
• transfèrent le contrôle au noyau

Sur les systèmes modernes x64, la transition se fait typiquement via

Code: Select all

syscall

. Historiquement, on a aussi rencontré

Code: Select all

sysenter

ou des mécanismes plus anciens selon l’architecture et la version du système.

Il faut bien comprendre que ces fonctions Nt* ou Zw* ne sont pas de simples wrappers Win32. Elles forment l’API native NT, plus proche du noyau.

2.2 Nt* contre Zw*

En user mode, on rencontre surtout les noms Nt*. En kernel mode, on croise souvent Zw* et Nt*. Il ne faut pas entrer ici dans toutes les nuances de sémantique interne, mais il faut au moins savoir qu’il existe cette dualité, surtout quand on lit du code kernel ou de la documentation plus basse.

Ce qu’il faut retenir :

• en user mode, on passe typiquement par les stubs Nt* exportés par ntdll.dll
• en kernel mode, on voit souvent Zw* dans le code des drivers ou du noyau

2.3 Pourquoi NTDLL est une cible classique d’instrumentation

Comme ntdll.dll est la passerelle vers les syscalls, elle est naturellement une cible très fréquente pour :

• API hooking user-mode
• instrumentation de sécurité
• EDR user-mode
• anti-cheat
• malware qui veut détourner ou observer les appels système
• reverse engineering dynamique

Quand un malware veut surveiller ou détourner les appels à NtReadFile, NtOpenProcess ou NtAllocateVirtualMemory en user-mode, il touche souvent à ntdll.dll.

Cela explique aussi pourquoi les hooks user-mode ne “contrôlent pas le noyau”, mais influencent la couche user-mode avant la transition réelle.

2.4 Autres rôles critiques de NTDLL

NTDLL ne contient pas seulement les stubs d’appels système. Elle fournit aussi énormément de briques internes critiques.

Parmi les familles importantes :

• Ldr* : loader PE user-mode
• Rtl* : runtime NT bas niveau
• gestion du heap bas niveau
• gestion des exceptions
• APC user-mode
• gestion TLS / TEB / PEB selon le contexte

APIs ou familles de fonctions importantes à connaitre de nom :

• LdrLoadDll
• LdrGetProcedureAddress
• RtlAllocateHeap
• RtlFreeHeap
• RtlInitUnicodeString
• RtlCreateProcessParametersEx
• RtlCaptureContext
• RtlLookupFunctionEntry

Sans ntdll.dll, un processus Windows user-mode normal ne peut pas vivre correctement. C’est une DLL absolument centrale.

3) Les DLL Win32 “hautes” et leur rôle réel

Beaucoup d’applications n’appellent jamais directement NtCreateFile ou NtAllocateVirtualMemory. Elles passent par les DLL Win32 plus haut niveau, comme :

• kernel32.dll
• KernelBase.dll
• user32.dll
• gdi32.dll
• advapi32.dll
• ws2_32.dll

Exemple typique :

Code: Select all

CreateFileW
↓
KernelBase.dll / kernel32.dll
↓
NtCreateFile dans ntdll.dll
↓
syscall
↓
noyau

Il faut donc retenir :

• les API Win32 “classiques” sont souvent des couches plus haut niveau
• elles finissent très souvent par descendre vers l’API native NT via ntdll.dll

C’est très important en reverse engineering, parce qu’on peut raisonner à plusieurs niveaux d’abstraction.

4) Le Process Environment Block et le Thread Environment Block

Pour comprendre l’architecture interne de Windows coté user-mode, il faut aussi connaitre deux structures très importantes :

• PEB : Process Environment Block
• TEB : Thread Environment Block

Le PEB contient notamment des informations sur :

• le processus
• le loader
• la liste des modules chargés
• les paramètres du processus
• divers indicateurs internes

Le TEB contient des informations liées au thread courant :

• TLS
• gestion d’exceptions thread-locales
• pointeurs internes utiles au runtime
• accès au PEB via certaines chaînes internes

Ces structures sont très connues en reverse engineering, instrumentation, et analyse malware, parce qu’elles donnent une vision concrète de l’état user-mode d’un processus.

5) Les sous-systèmes Windows

Windows n’est pas simplement “le noyau + les applis”. Il existe aussi des sous-systèmes d’exécution.

Historiquement, Windows a supporté plusieurs environnements, mais le sous-système principal qui nous intéresse ici est bien sûr le sous-système Windows, souvent appelé Win32 subsystem.

5.1 Le sous-système Win32

Le sous-système Win32 comprend notamment :

• csrss.exe
• win32k.sys
• conhost.exe
• les DLL Win32 comme user32.dll, gdi32.dll, kernel32.dll, etc.

C’est ce sous-système qui fournit l’environnement d’exécution natif habituel des applications Windows.

5.2 CSRSS : processus critique

csrss.exe, le Client/Server Runtime Subsystem, est un processus critique.

Il intervient dans des mécanismes comme :

• une partie de la gestion des consoles historiquement
• certaines fonctions du sous-système Win32
• des aspects de gestion de processus / thread / session selon les versions

Point très important :

Code: Select all

la terminaison de csrss.exe provoque un crash système

Il faut donc toujours voir csrss.exe comme un composant critique du système, pas comme un simple processus “comme les autres”.

5.3 Conhost.exe

Pour les consoles modernes, conhost.exe joue aussi un rôle important. Il sert d’hôte console, dans un modèle plus propre que certaines anciennes architectures historiques.

En pratique, quand tu analyses une application console ou du code lié au terminal Windows, tu peux croiser conhost.exe dans la chaîne de processus.

6) Pourquoi la GUI Windows vit partiellement en kernel mode

C’est un point très important et souvent surprenant pour ceux qui viennent d’autres systèmes : sous Windows, une partie importante de la gestion GUI n’est pas purement user-mode.

Des éléments comme :

• la gestion des fenêtres
• le dessin GDI historique
• les entrées clavier / souris
• une partie du système graphique Win32

passent par win32k.sys, donc par du kernel mode.

Avantage :

• performances historiquement meilleures
• accès plus direct à certaines opérations graphiques ou de fenêtre

Inconvénient :

• surface d’attaque plus grande
• bugs GUI potentiellement plus critiques
• plus de code complexe en noyau

C’est un point de sécurité très important.

7) Le noyau Windows : Ntoskrnl.exe

Le cœur du système Windows est contenu dans ntoskrnl.exe.

C’est là que vivent énormément de mécanismes critiques :

• ordonnancement
• gestion mémoire
• objets noyau
• sécurité
• I/O
• registre
• cache
• gestion de processus et threads

Quand un syscall arrive depuis ntdll.dll, il finit typiquement dans le noyau, au sein de cette grande architecture incarnée notamment par ntoskrnl.exe.

7.1 Executive vs Kernel

Une distinction importante, classique dans l’architecture NT, est celle entre Executive et Kernel.

Executive :

• gestion des processus
• gestion mémoire virtuelle
• sécurité
• I/O manager
• object manager
• configuration manager (registre)
• cache manager

L’Executive exprime surtout des politiques et des grands services du système.

Kernel au sens plus strict :

• ordonnancement des threads
• interruptions
• exceptions
• DPC
• synchronisation bas niveau
• mécanismes machine plus proches du CPU

Le Kernel implémente davantage les mécanismes bas niveau.

Il faut retenir ceci :

Code: Select all

Executive = grands services système
Kernel = mécanique bas niveau du noyau

7.2 Les grands managers internes de l’Executive

Quelques composants internes très importants à connaitre de nom :

• Object Manager
• Memory Manager
• Process Manager / Process structures
• I/O Manager
• Security Reference Monitor
• Configuration Manager
• Cache Manager
• Plug and Play Manager
• Power Manager

Ce sont eux qui structurent réellement le fonctionnement interne du système.

Exemples :

• Object Manager : namespace d’objets, handles, objets noyau
• Memory Manager : mémoire virtuelle, pages, working sets, sections
• I/O Manager : IRP, devices, pilotes, dispatch d’I/O
• Configuration Manager : registre
• Security Reference Monitor : décisions d’accès

8) Objets noyau et synchronisation interne

Windows repose massivement sur des objets noyau.

Exemples importants :

• processus
• threads
• events
• mutex
• semaphores
• timers
• sections
• tokens
• jobs
• files

Une grande partie de la synchronisation et du contrôle du système passe par eux.

Il faut aussi connaitre certains concepts du noyau liés à l’exécution :

• APC
• DPC
• interruptions
• spinlocks
• dispatcher objects

Ces objets et mécanismes pilotent directement :

• l’ordonnancement
• les attentes bloquantes
• les réveils de threads
• la concurrence noyau

9) HAL : Hardware Abstraction Layer

Sous le noyau, Windows s’appuie aussi sur la HAL, le Hardware Abstraction Layer.

Son rôle est de masquer ou abstraire certaines différences matérielles, par exemple :

• interruptions
• timers
• APIC
• DMA
• différences de plateformes ou de cartes mères

Le but est clair :

• laisser le noyau plus portable
• éviter que chaque partie du système réécrive la gestion matérielle spécifique
• donner une couche d’abstraction plus propre pour certaines fonctions matérielles

Il ne faut pas voir la HAL comme “un autre noyau”, mais comme une couche d’abstraction matérielle essentielle.

10) Les pilotes : code noyau chargeable

Les drivers Windows sont du code kernel-mode chargeable.

Cela veut dire qu’un pilote :

• tourne avec des privilèges noyau
• peut manipuler des objets noyau
• peut traiter des IRP
• peut accéder au matériel selon son rôle
• peut provoquer un BSOD s’il se trompe

Un driver peut s’exécuter dans différents contextes :

• dans le contexte d’un thread utilisateur
• dans un thread système
• dans un contexte d’interruption ou de DPC selon le code concerné

Installer un driver revient donc à introduire du code dans la partie la plus sensible du système.

C’est pour cela que le kernel mode est beaucoup plus dangereux et beaucoup plus puissant que le user mode.

11) IRP, I/O Manager et communication avec les drivers

Même si ce cours n’est pas un cours complet sur les drivers, il faut au moins connaitre le rôle des IRP.

Les IRP, I/O Request Packets, sont les structures qui représentent les requêtes d’I/O dans le système.

Schéma simplifié :

Code: Select all

application
↓
CreateFile / DeviceIoControl / ReadFile / WriteFile
↓
ntdll.dll
↓
syscall
↓
I/O Manager
↓
IRP
↓
driver

C’est un point très important, parce qu’il montre que le système n’est pas juste une “suite de fonctions”, mais un pipeline structuré de requêtes.

12) Syscalls, SSDT et transition vers le noyau

Quand un thread en user-mode fait un appel natif, il passe par ntdll.dll puis par une instruction de transition comme

Code: Select all

syscall

.

Ensuite, coté noyau, Windows utilise le numéro de service système pour arriver au bon handler. Dans la littérature technique, on parle souvent de la SSDT, la System Service Dispatch Table.

Il faut au moins connaitre ces notions de nom, parce qu’elles sont fondamentales en internals, en sécurité et en reverse engineering.

Ce qu’il faut retenir :

• le code user-mode ne saute pas directement au hasard dans ntoskrnl
• il passe par une passerelle structurée
• les stubs ntdll et la logique de dispatch système sont critiques

13) Le loader PE et la naissance d’un processus

Quand un processus démarre, énormément de choses se mettent en place avant meme que ton code applicatif ne “commence vraiment”.

Parmi les composants critiques :

• le chargeur d’image PE
• ntdll.dll
• le PEB
• le loader Ldr*
• les imports
• les TLS callbacks éventuels

Le processus ne “tombe” pas directement dans ton main sans préparation. Le démarrage réel est beaucoup plus structuré.

C’est très important en reverse engineering et en analyse malware, parce que des comportements peuvent se produire très tôt, avant le point d’entrée applicatif attendu par un développeur classique.

14) Exceptions, SEH et contexte CPU

Windows possède aussi un modèle interne important pour la gestion des exceptions.

Notions importantes à connaitre :

• SEH, Structured Exception Handling
• VEH, Vectored Exception Handling
• contexte CPU
• pile d’exécution
• rôle de ntdll dans la gestion d’exceptions user-mode

En cas de crash, d’exception ou de breakpoint, cette mécanique devient essentielle.

Cela explique aussi pourquoi certaines anomalies sont visibles via :

• debuggers
• dump mémoire
• handlers d’exception
• instrumentation user-mode

15) Architecture 32 bits, 64 bits et WOW64

Sur les systèmes 64 bits, un autre concept très important existe : WOW64.

Il permet à des applications 32 bits de tourner sur un système 64 bits.

Cela implique plusieurs couches supplémentaires, par exemple :

• wow64.dll
• wow64win.dll
• wow64cpu.dll

Il faut connaitre ce concept, parce qu’il explique :

• certaines redirections d’API
• certaines différences de registre
• certaines différences de System32 / SysWOW64
• certaines observations de processus ou modules

Un analyseur ou un reverseur qui oublie WOW64 peut mal interpréter ce qu’il voit.

16) Frontières de sécurité réelles

Quand on parle de sécurité Windows, il ne faut pas raisonner uniquement en “admin ou pas admin”.

Les frontières importantes incluent aussi :

• user mode vs kernel mode
• processus vs autre processus
• token et privilèges
• session
• intégrité
• service vs application utilisateur
• driver signé ou non

Mais la plus grosse frontière reste bien :

Code: Select all

user mode ↔ kernel mode

Tout ce qui permet de franchir cette frontière sans contrôle constitue un enjeu majeur en sécurité.

17) Méthodologie mentale pour analyser un comportement système

Quand tu analyses un comportement Windows, pose-toi toujours des questions structurantes.

Exemple de grille mentale :

• ce code est-il en user mode ou en kernel mode
• quelle DLL user-mode est impliquée
• y a-t-il passage par ntdll.dll
• quel syscall ou quelle famille de syscall est probablement utilisée
• le composant qui agit a-t-il le bon rôle pour faire cela
• un driver est-il impliqué
• l’action observée est-elle cohérente avec l’architecture normale

Cette manière de penser change complètement la qualité de l’analyse.

18) Composants et binaires à connaitre absolument

Pour avoir une vraie base, il faut reconnaitre rapidement les composants suivants :

• ntdll.dll
• kernel32.dll
• KernelBase.dll
• user32.dll
• gdi32.dll
• advapi32.dll
• csrss.exe
• conhost.exe
• win32k.sys
• ntoskrnl.exe
• hal.dll / HAL selon le contexte
• smss.exe
• wininit.exe
• services.exe
• lsass.exe

Ce ne sont pas “juste des noms”.
Ce sont des pièces de l’architecture réelle.

19) Structures et notions qu’il faut connaitre de nom

Même sans entrer dans tous les détails d’implémentation, il faut connaitre au moins :

• PEB
• TEB
• EPROCESS
• ETHREAD
• KPROCESS
• KTHREAD
• IRP
• SSDT
• APC
• DPC
• IDT
• GDT
• SEH
• WOW64

Tu ne les manipules pas toutes directement en Win32 classique, mais les connaitre change totalement la lecture de la documentation, des livres d’internals et des outils de debug.

20) APIs et familles d’APIs à connaitre de nom

Dans le cadre de cette architecture, plusieurs familles d’API sont importantes à connaitre :

• CreateFile / ReadFile / WriteFile / DeviceIoControl
• VirtualAlloc / VirtualProtect / VirtualQuery
• NtCreateFile / NtReadFile / NtQueryInformationProcess
• LoadLibrary / GetProcAddress
• LdrLoadDll
• ReadProcessMemory / WriteProcessMemory
• GetThreadContext / SetThreadContext
• CreateProcess / CreateRemoteThread
• OpenProcess / OpenThread / OpenProcessToken

L’idée n’est pas que toutes ces APIs sont “architecturelles” au meme niveau, mais qu’elles s’inscrivent toutes dans le flux réel de communication entre le user-mode et les couches internes du système.

21) Ce qu’il faut retenir

Les idées essentielles de ce cours sont les suivantes :

• Windows est un système fortement structuré
• la séparation user mode / kernel mode est la barrière de base
• une application ne parle jamais directement au noyau
• ntdll.dll est la vraie frontière user ↔ kernel
• le noyau réel s’organise notamment autour de ntoskrnl.exe, de l’Executive, du Kernel et de la HAL
• la GUI Win32 implique aussi du code kernel-mode via win32k.sys
• les drivers sont l’un des points les plus sensibles du système
• comprendre cette architecture rend les comportements anormaux beaucoup plus visibles

Conclusion

Windows n’est pas un amas de DLL. C’est une architecture hiérarchique, avec des couches précises, des frontières de privilèges strictes, des composants critiques, et un modèle d’exécution cohérent.

Quand tu comprends vraiment :

• où le code s’exécute
• par quelle DLL il passe
• comment il change de privilège
• quels composants sont critiques

alors beaucoup de choses deviennent plus faciles à analyser :

• les injections
• les hooks user-mode
• les comportements malware
• les anomalies d’exécution
• les crashes
• les attaques contre le noyau

Et c’est précisément ce changement de vision qui fait passer d’une compréhension “surface API” à une vraie compréhension système de Windows.

A bientôt pour un nouveau cours.