Hardcoded values for kernel space are present in filescan.py

[GoogleCodeExporter]

Taken from issue 173...

"Any plugins using hard-coded address for kernel mode being >= 0x80000000 
should probably be changed. The value can be a volatility magic equaling 
0x80000000 for x86 and 0xffff0800‘00000000 for x64."

Original issue reported on code.google.com by mike.auty@gmail.com on 22 Jan 2012 at 7:01

[GoogleCodeExporter]

Also see:

nt!MmHighestUserAddress
nt!MmSystemRangeStart 

and 

KDBG.MmHighestUserAddress
KDBG.MmSystemRangeStart

Just in case we want to look up the values memory sample, instead of 
hard-coding them. 

Original comment by michael.hale@gmail.com on 25 Jan 2012 at 3:07

[GoogleCodeExporter]

Ok,

Here's a patch that just makes use of MmHighestUserAddress (should be easy to 
sed to MmSystemRangeStart if I chose the wrong one), but I have the horrible 
feeling that it'll slow down the plugins on profiles where the KDBG location 
isn't known (Win7 for example).  It could probably do with some 
optimization/checking to make sure it works as expected and I haven't 
accidentally put the scan in any loops.

Also, there may still be two hardcoded values in hibinfo and the hibernation 
AS, and one in the ssdt plugin.  These could do with checking and if they're 
valid, integrating into the patch...

Original comment by mike.auty@gmail.com on 5 Feb 2012 at 12:02

Attachments:

• volatility-hardcoded-kernel.patch

[GoogleCodeExporter]

Did you mean to comment out lines 144+ of the patch?  That might be a mistake 
since we have this commented code: 

http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/modsc
an.py#107

Original comment by jamie.l...@gmail.com on 5 Feb 2012 at 12:09

[GoogleCodeExporter]

I didn't comment them out, they were already commented.  I figured I ought to 
update them in case we ever decided to UNcomment them...  5:)

Original comment by mike.auty@gmail.com on 5 Feb 2012 at 12:12

[GoogleCodeExporter]

ahh no sorry, I thought that those were part of the changes you wanted us to 
test.. ok no worries.  cool, i'll test it out :-)

Original comment by jamie.l...@gmail.com on 5 Feb 2012 at 12:15

[GoogleCodeExporter]

Gleeda if you have the cycles, could you also test on a machine that's been 
booted with the /3GB switch? KDBG.MmHighestUserAddress should reflect the fact 
that the highest user address is quite different than when there are only 2GB 
of user space. Just want to make sure everything still works in those cases. 

Original comment by michael.hale@gmail.com on 5 Feb 2012 at 12:17

[GoogleCodeExporter]

In testing Gleeda and I realized the KDBG.MmHighestUserAddress and 
KDBG.MmSystemRangeStart are pointers to the corresponding global variables in 
ntoskrnl (nt!MmHighestUserAddress and nt!MmSystemRangeStart). Thus instead of 
this:

kdbg = tasks.get_kdbg(space)
if value < kdbg.MmHighestUserAddress.v() 

We have to do this:

kdbg = tasks.get_kdbg(space)
p = obj.Object("address", kdbg.MmHighestUserAddress, space)
if value < p.v(): 

Alternately we can create an overlay for these two members so we can just do 
something like this:

kdbg = tasks.get_kdbg(space)
if value < p.MmHighestUserAddress.dereference():

Original comment by michael.hale@gmail.com on 6 Feb 2012 at 3:46

[GoogleCodeExporter]

Ah, I just looked at kdbg.MmHighestUserAddress and since it was close to 
0x80000000 figured it must be right.  You may also be able to do 
kdbg.MmHighestUserAddress.dereference_as('address') and that might work...

Original comment by mike.auty@gmail.com on 6 Feb 2012 at 3:50

[GoogleCodeExporter]

Cool, that does work. I thought in order to be dereferenced the type needed to 
be pointer or address already. So yeah that is better than using an overlay. 

Original comment by michael.hale@gmail.com on 6 Feb 2012 at 3:52

[GoogleCodeExporter]

OK Gleeda and I have some feedback on the patch: 

1) we need to dereference_as("address") the 2 KDBG members since they are 
actually pointers 
2) the patch breaks psscan because it calls kdbg = 
tasks.get_kdbg(self.address_space) but self.address_space is physical inside 
the ScannerCheck 

I'm not sure if Gleeda has noticed any performance hit from using the scanners 
on Win7 etc. Gleeda can you update? 

As an alternative approach, kind of a hybrid between the hard-coded 0x80000000 
and the dynamic tasks.get_kdbg, which may solve some problems...what about the 
possibility of a volatility magic value as described in the initial comment for 
this issue? There are really only two typical cases here. On x86 the highest 
user address is 0x7ffeffff and system range start is 0x80000000. On x64 the 
highest user address is 0x7fffffeffff and system range start is 
0xffff080000000000. 

So we only need volatility magic for highest user address which would be 
0x7ffeffff or 0x7fffffeffff depending on the architecture. As for the rare 
cases when memory dumps are from systems with the /3GB switch enabled, we could 
provide a command-line override like --kdbg currently. And in the output of 
imageinfo since we're already instantiating a _KDDEBUGGER_DATA64 object, we can 
just print the MmHighestUserAddress value. This fits with how we currently show 
possibly profiles which users then pick up and use. Just FYI highest user 
address on x86 with /3GB boot switch is 0xbffeffff. 

Original comment by michael.hale@gmail.com on 6 Feb 2012 at 10:31

[GoogleCodeExporter]

So 1) is dead easy to fix, but 2)'s much, much harder.  I may look at allowing 
native_vm's to be passed through scanner objects, but it's a little ugly...  5:\

I'm really not keen on adding more command line parameters, particularly for 
something so specific, and if we can calculate the correct value, I think we 
should.

My question is what happens if we can't find the kdbg, or it's been overwritten 
with bad data?  Blargh, no clear solution here...

Original comment by mike.auty@gmail.com on 6 Feb 2012 at 11:15

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 6 Jun 2012 at 8:31

• 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:39

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

[GoogleCodeExporter]

After further investigation and nearly 1.5 years of using the code in its 
current state, the hard-coded values don't cause any problems, so I'm going to 
dismiss this as a defect. If we need to reopen later, then that's always a 
possibility. 

Original comment by michael.hale@gmail.com on 7 Mar 2014 at 5:14

• Changed state: WontFix