KDBG scanning does not really need signatures

[GoogleCodeExporter]

Currently we have a KDBG signature for each profile in the KDBGHeader as can be 
seen in the code:

class AbstractKDBGMod(obj.ProfileModification):
    kdbgsize = 0x290

    def modification(self, profile):
        signature = '\x00\x00\x00\x00\x00\x00\x00\x00' if profile.metadata.get('memory_model', '32bit') == '32bit' else '\x00\xf8\xff\xff'
        signature += 'KDBG' + struct.pack('<H', self.kdbgsize)
        profile.merge_overlay({'VOLATILITY_MAGIC': [ None, {
                                'KDBGHeader': [ None, ['VolatilityMagic', dict(value = signature)]]
]})
                                                            }

I think this code generates per header signatures, also from another per 
profile value (kdbgsize) (this code is not particularly obvious). Anyway 
setting a breakpoint in kdbg scan shows the following signatures are actually 
used:

{'Win2008SP1x86': '\x00\x00\x00\x00\x00\x00\x00\x00KDBG0\x03', 'Win7SP1x64': 
'\x00\xf8\xff\xffKDBG@\x03', 'Win7SP0x64': '\x00\xf8\xff\xffKDBG@\x03', 
'VistaSP0x64': '\x00\xf8\xff\xffKDBG(\x03', 'Win2008R2SP1x64': 
'\x00\xf8\xff\xffKDBG@\x03', 'WinXPSP3x86': 
'\x00\x00\x00\x00\x00\x00\x00\x00KDBG\x90\x02', 'Win2008SP2x64': 
'\x00\xf8\xff\xffKDBG0\x03', 'Win2008SP1x64': '\x00\xf8\xff\xffKDBG0\x03', 
'Win2008R2SP0x64': '\x00\xf8\xff\xffKDBG@\x03', 'Win7SP1x86': 
'\x00\x00\x00\x00\x00\x00\x00\x00KDBG@\x03', 'VistaSP1x86': 
'\x00\x00\x00\x00\x00\x00\x00\x00KDBG0\x03', 'VistaSP2x64': 
'\x00\xf8\xff\xffKDBG0\x03', 'VistaSP2x86': 
'\x00\x00\x00\x00\x00\x00\x00\x00KDBG0\x03', 'Win2008SP2x86': 
'\x00\x00\x00\x00\x00\x00\x00\x00KDBG0\x03', 'Win2003SP1x86': 
'\x00\x00\x00\x00\x00\x00\x00\x00KDBG\x18\x03', 'Win2003SP2x64': 
'\x00\xf8\xff\xffKDBG\x18\x03', 'Win7SP0x86': 
'\x00\x00\x00\x00\x00\x00\x00\x00KDBG@\x03', 'Win2003SP2x86': 
'\x00\x00\x00\x00\x00\x00\x00\x00KDBG\x18\x03', 'VistaSP1x64': 
'\x00\xf8\xff\xffKDBG0\x03', 'VistaSP0x86': 
'\x00\x00\x00\x00\x00\x00\x00\x00KDBG(\x03', 'Win2003SP0x86': 
'\x00\x00\x00\x00\x00\x00\x00\x00KDBG\x18\x03', 'Win2003SP1x64': 
'\x00\xf8\xff\xffKDBG\x18\x03', 'WinXPSP2x64': '\x00\xf8\xff\xffKDBG\x18\x03', 
'WinXPSP1x64': '\x00\xf8\xff\xffKDBG\x18\x03', 'WinXPSP2x86': 
'\x00\x00\x00\x00\x00\x00\x00\x00KDBG\x90\x02'}

The thing is that we really do not need these signatures to find KDBG at all. 
The finding of kdbg can be done completely without signatures as described here:

http://moyix.blogspot.com/2008/04/finding-kernel-global-variables-in.html

So what you do is look for the string "KDBG" which is always the OwnerTag, then 
you cast the _KDDEBUGGER_DATA64 over it. You can easily eliminate false hits by 
reflecting through the Header.List element.  This check works both for 32 bit 
and 64 bit system as the structure is always the same.

You can then use the size element to identify the likely profile if you want 
this information. It seems that kdbgscan is actually doubling as a profile 
guesser right now (not sure if thats by choice). Anyway you do not really need 
to know exactly which profile it is to find it.

By eliminating KDBG signatures it makes it easier to add new windows versions 
to volatility.

An example of a signature free scanner can be found here:
http://code.google.com/p/volatility/source/browse/branches/scudette/volatility/p
lugins/windows/kdbgscan.py#62

Original issue reported on code.google.com by scude...@gmail.com on 4 Mar 2012 at 11:55

[GoogleCodeExporter]

Hey guys, should this be merged with Issue #141 or is it different? 

Original comment by michael.hale@gmail.com on 6 Mar 2012 at 7:34

[GoogleCodeExporter]

Well it is a little different. This issue is about finding KDBG in the first 
place, where #141 is about being able to list processes without the kdbg at all 
using an alternate algorithm.

Its nice to keep both ways to list processes I think, so in the new branch i 
have kept the kdbg way in addition to the new eprocess way. In the new code the 
kdbg scanning is also implementing the above described method making it more 
reliable.

I am not sure what the policy of the issue tracker should be - as I find more 
problems or suggestions in trunk I can post the issues here, although these 
will generally be fixed already in my branch.

Original comment by scude...@gmail.com on 6 Mar 2012 at 9:03

[GoogleCodeExporter]

Hey scudette, 

I checked out the branch to test a few things, but I get the following error. 
Any idea how to fix it?

$ python vol.py --info
Volatile Systems Volatility Framework 3.0_alpha
Traceback (most recent call last):
  File "vol.py", line 200, in <module>
    main()
  File "vol.py", line 156, in main
    registry.PluginImporter(config.PLUGINS)
AttributeError: 'module' object has no attribute 'PluginImporter'

Original comment by michael.hale@gmail.com on 10 Mar 2012 at 9:45

[GoogleCodeExporter]

Hi Michael,
   The vol.py file will disappear soon.  The main entry point is
volshell.py now. This is a sample session:

scudette@laptop:~/volatility/svn$ python volshell.py
Welcome to volshell!
To get help, type 'help()'

In [1]: session.filename = "test_data/win7_trial_64bit.raw"

In [2]: session.profile = "Win7SP1x64"

In [3]: vol plugins.pslist
------> vol(plugins.pslist)
INFO:root:Autodetected physical address space
<volatility.plugins.addrspaces.standard.FileAddressSpace object at
0x29e29d0>

WARNING:volatility.obj:Overlay structure VOLATILITY_MAGIC not present in vtypes
INFO:root:Autodetected virtual address space
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x3034250>

INFO:root:KDBG not provided - Volatility will try to automatically
scan for it now using plugin.kdbgscan.
INFO:root:Found a KDBG hit [_KDDEBUGGER_DATA64 _KDDEBUGGER_DATA64] @
0xF80002803070. Hope it works. If not try setting it manually.
 Offset(V) Offset(P)  Name                 PID    PPID   Thds   Hnds   Time
---------- ---------- -------------------- ------ ------ ------ ------
-------------------
0xfffffa80004b09e0 0x17fef9e0 System                    4      0
78    489 2012-02-22 19:58:20
0xfffffa8000ce97f0 0x176e97f0 smss.exe                208      4
2     29 2012-02-22 19:58:20
0xfffffa8000c006c0 0x176006c0 csrss.exe               296    288
9    385 2012-02-22 19:58:24
0xfffffa8000c92300 0x17692300 wininit.exe             332    288
3     74 2012-02-22 19:58:30
....

I intend on making a screen cast this weekend of the current
interface, once I finishs porting some of the linux modules over.

Original comment by scude...@gmail.com on 10 Mar 2012 at 10:04

[GoogleCodeExporter]

Oh BTW, as the info log above explains, you can use kdbgscan to see potential 
kdbg hits. If you check the code, it autodetects the kdbg using this very 
module, picking the first hit. This replaces the current VolatilityMagic hack 
(which is deprecated in the new code base):

In [5]: vol plugins.kdbgscan
------> vol(plugins.kdbgscan)
Potential hits for kdbg strctures.
  Offset (V)         Offset (P)
----------------  ----------------
0x00f80002803070   0x00000002803070
Out[5]: <volatility.plugins.windows.kdbgscan.KDBGScan object at 0x29e2bd0>

Original comment by scude...@gmail.com on 10 Mar 2012 at 10:09

[GoogleCodeExporter]

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

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

[GoogleCodeExporter]

Got it, thanks for the extra info scudette! I'll get back to you after some 
testing. 

Original comment by michael.hale@gmail.com on 12 Mar 2012 at 12:47

[GoogleCodeExporter]

Analysis of the KDBG scanning/detection is going to be required for 
auto-selection of profiles, so I'm just adding this issue to the 2.2.x 
milestone. 

One thing for sure is I don't think we should continue to pick the first KDBG 
hit, because that's often not the right choice. If we have the capability to 
determine which KDBG is valid when there are multiple choices, we should do so. 
Also see Issue #268. 

Original comment by michael.hale@gmail.com on 13 Jun 2012 at 2:51

• Added labels: Milestone-2.2.x

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 26 Aug 2012 at 5:34

• Added labels: Milestone-2.3.x
• Removed labels: Milestone-2.2.x

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 1 Feb 2013 at 4:46

• Added labels: Milestone-3.0.x
• Removed labels: Milestone-2.3.x

[GoogleCodeExporter]

Original comment by jamie.l...@gmail.com on 6 Jan 2014 at 7:10

[GoogleCodeExporter]

Upon further investigation, this isn't a critical issue that needs fixing. The 
current implementation of kdbgscan has worked find for years. Although it 
indeed is based on signatures ("KDBG" + size), the proposed method is also 
based on a signature ("KDBG"). 

Original comment by michael.hale@gmail.com on 7 Mar 2014 at 6:07

• Changed state: WontFix