Utilité d'une image minidump pour le forensique

Tout système MS Windows est configuré pour réaliser un enregistrement de son état lorsqu'il se plante. En regardant dans les propriétés avancées du Poste de Travail, on constate qu'il existe trois niveaux d'enregistrement :
- image mémoire complète : contient la totalité de la mémoire physique au moment du crash.
- image mémoire du noyau contient uniquement les pages lecture/écriture du mode noyau présentes dans la mémoire physique au moment du crash. Elle ne contient donc pas a priori les processus du mode utilisateur.
- image mémoire partielle. Une petite image mémoire, appelée communément minidump, d'une taille fixe de 64KB (ou 128KB pour les systèmes 64 bits).

Par défaut, seule une image minidump est générée par un système MS Windows. Nous allons étudier l'utilité éventuelle d'une telle image pour le forensique.

Pour une analyse forensique à distance, une minidump semble idéale de part sa taille (64KB ou 128 pour les systèmes 64 bits) car elle peut facilement être envoyée par messagerie. Reste à pouvoir la générer après une éventuelle compromission. En effet, la machine suspectée n'a pas, a priori, été configurée pour se crasher à l'aide de la séquence de touches de l'article précédent (sinon on aurait également configuré une image mémoire complète).

Après quelques recherches, j'ai mis la main sur l'utilitaire Notmyfault.exe de Mark Russinovich (encore disponible ici, mais pour combien de temps ??). Il permet de lancer un driver "bidon" (myfault) qui fait crasher le système selon différentes méthodes.

Après le crash, il s'agit de récupérer la minidump dans le répertoire \Windows\Minidump\. Son nom est alors composé de la chaîne "Mini" suivie de la date et d'un numéro de séquence (par ex: Mini-121106-01.dmp).

Malheureusement, si l'analyse d'une minidump permet de comprendre ce qui a généré le crash, elle n'est pas vraiment exploitable pour l'analyse d'une éventuelle compromission.
En effet, le seul processus analysable est celui qui a provoqué le crash (la séquence clavier ou le driver spécialement corrompu myfault) ! Par conséquent, une recherche des processus cachés à l'aide de l'outil hidden.dll est impossible.

En décortiquant d'avantage cette mini-image, celle-ci ne contient que le code stop et ses paramètres, la liste des drivers chargés, le processus et le thread courant (EPROCESS et THREAD) et la pile noyau pour le thread qui a causé le crash.

Conclusion : lorsque le système suspect n'a pas été préparé pour générer un crash dump complet (via la séquence de touches spéciales du BugCheck Trap), il faut se rabattre sur l'utilitaire dd et ses images de mémoire physique non compatibles avec le débogueur noyau de Microsoft...