NtFlushProcessWriteBuffers

Prototype

VOID NtFlushProcessWriteBuffers(VOID);

Arguments

IDs de syscalls par version de Windows

Stub du syscall

4C 8B D1                  mov r10, rcx
B8 F3 00 00 00            mov eax, 0xF3
F6 04 25 08 03 FE 7F 01   test byte ptr [0x7FFE0308], 1
75 03                     jne short +3
0F 05                     syscall
C3                        ret
CD 2E                     int 2Eh
C3                        ret

Notes non documentées

NtFlushProcessWriteBuffers (wrapper Win32 `FlushProcessWriteBuffers`) ne retourne pas de statut et ne prend aucun paramètre. En interne, le noyau envoie une interruption inter-processeur (IPI) à chaque CPU sur lequel un thread du processus appelant est actuellement exécutable, forçant chacun à exécuter une barrière mémoire complète — l'astuce de la barrière mémoire asymétrique qui permet aux algorithmes lock-free du thread appelant de sauter un `mfence` explicite sur le chemin *rapide* et de ne payer le coût complet que sur le rare chemin *lent*. .NET, Java HotSpot via ses wrappers natifs, et les files lock-free haute performance (Boost.Lockfree, concurrentqueue) l'utilisent tous. Le coût est élevé — dizaines de microsecondes — mais amorti sur de nombreuses lectures sur chemin rapide.

Usage courant par les malwares

Honnêtement, ce syscall a quasiment aucun signal offensif. Il n'alloue, ne lit, n'écrit ou ne touche pas autrement l'état du processus de manière utile à un attaquant. Le seul abus théorique est le **canal auxiliaire de timing CPU-bound** : le coût de l'IPI est proportionnel au nombre de CPU exécutant actuellement des threads du processus appelant, ce qui peut fuiter de l'information grossière sur l'ordonnancement d'autres cœurs — mais c'est académique et pas vu dans le malware réel. Une poignée de checks anti-debugger obscurs ont utilisé FlushProcessWriteBuffers pour détecter le single-stepping (le timing IPI change sous debugger matériel), mais c'est une technique marginale. Ne gâchez pas votre temps de chasse sur celui-ci.

Opportunités de détection

Pas une cible de détection utile. L'usage légitime est répandu (tout processus avec un runtime .NET, une JVM ou une bibliothèque lock-free moderne l'appellera). Les fournisseurs ETW n'exposent pas ce syscall, et il n'y a pas de callback noyau valant la peine d'être hooké. Si vous vous retrouvez à écrire une règle de détection autour de NtFlushProcessWriteBuffers, vous êtes probablement allé trop loin — re-priorisez.

Exemples de syscalls directs

// Fast path: a regular load, no fence.
// Slow path (writer): publish, then NtFlushProcessWriteBuffers to fence every
// reader CPU at once.
#include <windows.h>

static volatile LONG g_seq;

void writer_publish(void) {
    InterlockedIncrement(&g_seq);
    FlushProcessWriteBuffers();   // ntdll!NtFlushProcessWriteBuffers
}

LONG reader_fast(void) {
    return g_seq;   // no mfence — the writer's IPI guarantees ordering.
}

NtFlushProcessWriteBuffers PROC
    mov  r10, rcx
    mov  eax, 0F3h
    syscall
    ret
NtFlushProcessWriteBuffers ENDP

Mappings MITRE ATT&CK

• T1106Native APImitre ↗