Why is KDBG needed?

[GoogleCodeExporter]

I looked through the code and it seems that the only place where get_kdbg() is 
used is to find PsLoadedModuleList.PsActiveProcessHead in order to traverse the 
list for all running processes.

This is not really necessary as you can just traverse through the 
_EPROCESS.ActiveProcessLinks list for any alive process. We already find the 
Idle process for DTB using carving.

I propose we fallback to this mechanism when KDBG is not known. There are many 
cases where KDGB is not known e.g. when using a dd image rather than a crash 
dump. Right now we carve for it anyway which is kind of pointless because it 
requires specialized per profile signatures.

Original issue reported on code.google.com by scude...@gmail.com on 22 Sep 2011 at 1:49

[GoogleCodeExporter]

I really don't have that much of a problem with per-profile signatures (as long 
as there's not 20 per profile), and I have the feeling that the KDBG/KPCR will 
be useful for many more things than it's currently being used for.  I think for 
a single profile it really wouldn't be that time consuming, but I'm definitely 
open to patches for comparison and determining whether the new method is as 
good or better than the current one efficiency/false-positive wise...

I couldn't tell you the difference between _EPROCESS.ActiveProcessLinks and 
PsLoadedModuleList.PsActiveProcessHead, but I'd find it odd that volatility's 
been doing it one way for years, rather than doing it a quicker/easier way.  
Can anyone else shed any light on the difference/pros and cons of the two 
methods?

Original comment by mike.auty@gmail.com on 22 Sep 2011 at 10:18

[GoogleCodeExporter]

Hmm I don't think there's a such thing as 
PsLoadedModuleList.PsActiveProcessHead (PsLoadedModuleList is the list head for 
modules and PsActiveProcessHead is the list head for processes - they're both 
members of the debugger data block...one is not a member of the other). Finding 
the debugger data block is required for locating PsActiveProcessHead, which is 
required for traversing EPROCESS.ActiveProcessLinks. 

Original comment by michael.hale@gmail.com on 26 Sep 2011 at 12:36

[GoogleCodeExporter]

You're quite right, not sure where PsLoadedModuleList came from.  Irrespective 
of that, I think scudette's saying we can jump over the need for KDBG, because 
we already attempt to identify the Idle process (for DTB loading), and then 
could just use that _EPROCESS, rather than starting at the beginning of the 
list using KDBG.

I guess this hinges on whether ActiveProcessLinks either cyclic, or 
doubly-linked so that we can ensure we get all the processes.  We should also 
consider the anti-forensics implications, but I suppose we'd have those with 
KDBG as well...

Original comment by mike.auty@gmail.com on 26 Sep 2011 at 6:41

[GoogleCodeExporter]

Aggh, I mean _KDDEBUGGER_DATA64.PsActiveProcessHead. Clearly it was too late 
for me to be making any sense.

A malware could eaily change the  _KDDEBUGGER_DATA64 structure in memory 
because its not really needed for the system running. Its a bit more difficult 
to unlink regular system processes though (and even harder to unlink threads in 
such a way they will still continue to run afterwards.).

ActiveProcessLinks is a double list which is cyclic. It will give all actively 
running processes (unless they got unlinked by malware). It will also give us 
the list head itself (which is not an _EPROCESS) but we can identify it i think.

Removing our reliance on kdbg will mean we dont need to scan for it each time, 
make the forensics more robust. It would also make it easier to add more 
profiles as you would not need to find the sig for it each time.

Original comment by scude...@gmail.com on 26 Sep 2011 at 9:40

[GoogleCodeExporter]

Got it, that makes sense. I can't think of any disadvantages to that technique 
at the moment. Nice catch scudette!

Original comment by michael.hale@gmail.com on 26 Sep 2011 at 2:40

[GoogleCodeExporter]

Ok, so following on from the meeting.  The reasoning against this is that 
malware can easily rename the Idle process, so we'd have to rely on robust 
process scanning, and for that we'd already have to know which profile we're 
intending to use, or try them all.

Since not finding the Idle process also messes with DTB finding, we should 
probably try and implement using the Idle process location to provide the 
ActiveProcessLinks for plugins that use it.  That suggests we'll need some way 
of carrying data over from one pass over the image to another, which is what 
the caching system was built for.  We shouldn't dismantle the KDDBG finding 
code, since that's a useful source of information.  Anyone willing to mock up a 
patch?

Original comment by mike.auty@gmail.com on 17 Dec 2011 at 11:40

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 10 Mar 2012 at 10:54

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I'm closing this because the Idle process's ActiveProcessLinks are always 0 
(hence it not turning up in pslist), so it won't help us in the slightest.

Original comment by mike.auty@gmail.com on 6 Apr 2012 at 6:07

• Changed state: Invalid

[GoogleCodeExporter]

Indeed the Idle process does not participate in any lists itself so its a bad 
choice for finding PsActiveProcessHead, however the technique works very well 
with looking for other processes (e.g. System, svchost etc). For example we can 
do psscan and then use that to list processes without finding kdbg.

We should offer the ability to list processes based on the address of one 
process, so that even if kdbg fails to be found we can locate 
PsActiveProcessHead anyway.

Original comment by scude...@gmail.com on 6 Apr 2012 at 6:41

[GoogleCodeExporter]

Also we dont currently use per-profile signatures for finding kdbg anyway, so 
its not such a big problem.

Ikelos do you have any interest in implementing the signature free kdbg scanner 
or is that going to remain a feature of my version?

Original comment by scude...@gmail.com on 6 Apr 2012 at 8:27