I am aware that volatility and rekall only supports crash dumps that are complete memory dumps. Meaning that kernel memory dumps are not supported.
In particular I am working on extracting complete registry hives. I am able to solve this in a somewhat tedious/manual way by using windbg. So it's possible. But I was hoping there existed a smoother way of accomplishing this.
My question is;
Are there any tools out there that can analyze such kernel memory dumps?
Have you tried using encase? It analyzes dump.
Is some info on the file format useful?
Here
http//
jaclaz
Responder Pro does that, though it probably exceeds the scope of a "tool" in this case.
Responder Pro is supporting kernel memory dumps and is producing some nice reports of various stuff. But I can't make it reassemble and export registry hives. @C.S.R. do you know if it is possible with Responder Pro, and if so how?
Encase is untested (I have my doubts it will support it).
So, unless there is a tool out there that can do this, I think my best shot would be to programatically automate the (long) procedure I already have with WinDbg and that works for reassembling complete registry hives out of kernel memory dumps.
It is not a built-in function, you'd need to script Responder, too. However, I think it is much easier than automating WinDbg.
I acknowledge that Responder Pro have some nice features, and seems like a robust tool. Regarding its scripting as compared to windbg's scriptability it feels a little bit like managed coding compared to native coding. Thanks for the input. In my case I feel like sticking to WinDbg because it can do so many great things when you master it, because of its extreme power. I like to be in control over the power of WinDbg (still learning )).
However I find it strange that there's no tool out there that can reconstruct registry hives out of kernel memory dumps. I would assume that such MEMORY.DMP's, which is the default system configuration, is not unusual to find, as systems probably bluescreen'ed at least once during the entire lifetime.
Anyways, there's a very good reading to be found at http//