Quelqu'un a-t-il déjà essayé de faire un reverse de i802ptr.sys ?
Le truc serait de voir la tête de l'appel système qui entraine le reboot dans la procédure nommée par les frenchies : Crash_dump_avec_tes_doigts et par nos amis étatzuniens : Crsh_On_Ctrl_Scroll. Le rêve serait d'obtenir un outil pour lancer le processus sans avoir à ajouter une clé au registre et redémarrer la machine (impossible à faire dans la réponse à un incident).
Quelqu'un a-t-il une solution pour ne pas avoir à digérer l'un des pavés de Russinovich & Solomon pour comprendre la structure interne de la mémoire physique des systèmes MS Windows ?
Il faut vraiment en vouloir pour déchiffrer des hiéroglyphes d'un autre âge pour découvrir les adresses virtuelles des blocs _EPROCESS.
Quelqu'un connaît-il la sortie de FATKit de l'équipe de 4tphi.net et de KnTList de George Garner ?
FATKit a vraiment l'air sympa sur le papier (bien qu'un peu scolaire...) tandis que KnTList promet de résoudre les problèmes de restriction sur la mémoire physique en mode utilisateur avec les derniers MS Windows de sortie.
Voila. C'est dit !
Le truc serait de voir la tête de l'appel système qui entraine le reboot dans la procédure nommée par les frenchies : Crash_dump_avec_tes_doigts et par nos amis étatzuniens : Crsh_On_Ctrl_Scroll. Le rêve serait d'obtenir un outil pour lancer le processus sans avoir à ajouter une clé au registre et redémarrer la machine (impossible à faire dans la réponse à un incident).
Quelqu'un a-t-il une solution pour ne pas avoir à digérer l'un des pavés de Russinovich & Solomon pour comprendre la structure interne de la mémoire physique des systèmes MS Windows ?
Il faut vraiment en vouloir pour déchiffrer des hiéroglyphes d'un autre âge pour découvrir les adresses virtuelles des blocs _EPROCESS.
Quelqu'un connaît-il la sortie de FATKit de l'équipe de 4tphi.net et de KnTList de George Garner ?
FATKit a vraiment l'air sympa sur le papier (bien qu'un peu scolaire...) tandis que KnTList promet de résoudre les problèmes de restriction sur la mémoire physique en mode utilisateur avec les derniers MS Windows de sortie.
Voila. C'est dit !
Articles
En ce qui concerne la première question, c'est facile. La fonction KeBugCheck() est appelée directement par le driver.
RépondreSupprimerIl serait trivial d'écrire un driver, qui une fois chargé appelle directement KeBugCheck(). Pas besoin de reboot pour générer un dump, par contre l'empreinte mémoire du driver et du loader peut ne pas être négligeable ...
i8042prt.sys!_I8xProcessCrashDump@12:
[...]
xor ecx, ecx
push ecx ; BugCheckParameter4
push ecx ; BugCheckParameter3
push ecx ; BugCheckParameter2
push ecx ; BugCheckParameter1
push MANUALLY_INITIATED_CRASH ; BugCheckCode
mov [eax], ecx
call ds:__imp__KeBugCheckEx@20 ; KeBugCheckEx(x,x,x,x,x)
[...]
Tu as une idée de la taille ou de la proportion de la mémoire que prendraient ce driver et ce loader ?
RépondreSupprimerJe sais, cela doit dépendre complétement du système, des processus qu'il fait tourner et de sa RAM, mais j'ai besoin de cette info pour pouvoir un jour être en mesure de décider si cela vaut vraiment le coup : avoir une chance de récupérer des processus morts mais dont les données sont encore en mémoire sur un système non-préparé.
Au fait, je vais essayer dès lundi de battre mon record de récupération d'un processus mort depuis plus de dix jours.
A quand une théorie forensique sur la décomposition en mémoire des processus achevés ? Elle rejoindrait celle sur les vrais cadavres... C'est un véritable sujet de thèse ou de présentation au SSTIC ;-) Un peu macabre, peut-être !
J'ai bien l'intention de soumettre au SSTIC sur le sujet cette année, donc je ne peux pas t'en dire plus pour le moment ;)
RépondreSupprimer