symbolic link scanner

[GoogleCodeExporter]

I see this is on the Todo list for 2.1. Here's a patch...comments welcome.

Volatile Systems Volatility Framework 2.1_alpha
Offset     #Ptr #Hnd CreateTime               From                 To
0x0076f168    1    0 2010-09-26 20:16:12      Global               '\\Global??'
0x00a93370    1    0 2010-09-26 20:16:12      Global               '\\Global??'
0x02dd01a8    1    0 2010-09-26 20:15:59      GLOBALROOT           
0x02ddd030    1    0 2010-09-26 20:15:59      Global               '\\GLOBAL??'
0x02ddd848    1    0 2010-09-26 20:16:03      SystemRoot           
'\\Device\\Harddisk0\\Partition1\\WINDOWS'
0x02dddfe0    1    0 2010-09-26 20:15:59      DosDevices           '\\??'
0x030ac578    1    0 2010-09-26 20:16:03      AUX                  
'\\DosDevices\\COM1'
0x030b1f80    1    0 2010-09-26 20:15:59      WMIAdminDevice       
'\\Device\\WMIAdminDevice'
0x030b1fe0    1    0 2010-09-26 20:16:03      PIPE                 
'\\Device\\NamedPipe'
0x030b4f50    1    0 2010-09-26 20:15:59      WMIDataDevice        
'\\Device\\WMIDataDevice'
0x030dab40    1    0 2010-09-26 20:16:03      NUL                  
'\\Device\\Null'

Original issue reported on code.google.com by michael.hale@gmail.com on 18 Aug 2011 at 6:01

Attachments:

• symlinkscan_patch.txt

[GoogleCodeExporter]

Looks good!

Can't see the point of setting kas, or keeping the kernel address space around, 
but otherwise looks good.  5:)

Also, be sure to include a (V) or (P) by offset, so people know what they're 
dealing with...

Original comment by mike.auty@gmail.com on 18 Aug 2011 at 6:23

[GoogleCodeExporter]

Hey Mike. 

> Can't see the point of setting kas

This an annoying problem that I'd love to get resolved. You'll notice FileScan, 
DriverScan, and MutantScan all create a self.kernel_address_space in addition 
to a physical address space for scanning. This is because the plugins need to 
dereference pointers found in the objects that the scanner picks up. 
FileScan.parse_string is hard-coded with self.kernel_address_space.read. 
Although I don't think I'm the one who did that, I probably made matters worse 
by carrying a similar parse_string function over to the _OBJECT_HEADER, which 
was so we could call object_hdr.get_object_type() and 
object_hdr.get_object_name(), which both require following pointers in kernel 
space by an _OBJECT_HEADER in physical space. 

So kas is set to the plugin's self.kernel_address_space before calling 
get_object_type() and get_object_name() so that we don't need to pass 
self.kernel_address_space to each of those functions individually. 

Does that make sense? I really hope there's a cleaner way to do all this, as I 
think I become depressed when I think about ;-)

> Also, be sure to include a (V) or (P) by offset

No problem.

Original comment by michael.hale@gmail.com on 18 Aug 2011 at 7:01

[GoogleCodeExporter]

Yeah, that does make sense.  I was looking for inherited reasons to use that, 
but saw render_text redefined and assumed there wasn't a reason for it.

Hmmm, oh, and I just realized why we did it that way.  It's so we don't have to 
ship it with each entry, because parse_string gets run in render_text after 
we've determined the kernel space already.  That's a little bit ugly, but I 
can't think of a better solution off the top of my head.  In that case I'm 
happy with it (once it has (V) or (P) or an option to choose which)...  5:)

Original comment by mike.auty@gmail.com on 18 Aug 2011 at 7:10

[GoogleCodeExporter]

Cool. So as it stands, we have two versions of parse_string (similar to our 
multiple hexdump problem ;-)). One is a method of FileScan in filescan.py and 
one is a method of _OBJECT_HEADER in windows.py. Although parse_string isn't 
necessarily a large amount of code, it would be nice to only have 1 copy. 
However, it doesn't make sense for _OBJECT_HEADER to inherit from FileScan, or 
vice versa. Meaning a generic location like volatility.utils might be 
suitable...but I don't want to all the sudden start dumping everything in 
utils. 

Original comment by michael.hale@gmail.com on 18 Aug 2011 at 7:30

[GoogleCodeExporter]

> Also, be sure to include a (V) or (P) by offset

Hmm, should it be implied that all offsets for scanning commands are physical? 
Just asking because if I went ahead and added (P) to symlinkscan it would 
actually be the exception. All other scanners just say Offset:

- DriverScan
- ModScan
- MutantScan
- PSScan
- ThrdScan 
- Connscan
- Sockscan
- Netscan 

With the one exception of FileScan which says Offset(V)...which is entirely 
incorrect. So which of the two options would be best:

1) Fix all of the above scanners to say Offset(P), including symlinkscan
2) Leave all of the above scanners as they are, saying just Offset, and remove 
the (V) from FileScan?

Thoughts?

Original comment by michael.hale@gmail.com on 18 Aug 2011 at 9:23

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 18 Aug 2011 at 9:23

[GoogleCodeExporter]

My recollection was that a lot of the scanners had a -P option to make them 
output physical addresses, but that otherwise they attempted to output virtual 
addresses (hence the need for the kernel address space, rather than the flat 
one the objects were made with)...

Definitely we should make them accurate first and foremost (and no indication 
is more right than the wrong indication).  I'd be ok with a default as long as 
it was the same default all through volatility (and that's not just scanners).  
The end goal is to make it clear for a user which type of offset he's dealing 
with.  If it's obvious, then no problem, but if it's ambiguous, I'd prefer them 
to state it explicitly, even if that requires changing lots of plugins...

Original comment by mike.auty@gmail.com on 18 Aug 2011 at 9:29

[GoogleCodeExporter]

> My recollection was that a lot of the scanners had a -P option

Its the list walking plugins (not the scanners) that have that option. So like 
pslist, modules, connections, etc. Unless the objects are self-referencing in 
some way, the scanners won't know virtual addresses. 

I'll wait before doing anything, but it sounds like the desired action is to 
change all of the scanning plugins to say Offset(P) instead of Offset (and then 
fix FileScan). 

Original comment by michael.hale@gmail.com on 18 Aug 2011 at 9:35

[GoogleCodeExporter]

I can change the scanning plugins to say Offset(P) if that's what we agree to 
do...  just let me know if there's a consensus.

Original comment by jamie.l...@gmail.com on 14 Sep 2011 at 10:51

[GoogleCodeExporter]

That sounds good to me, thanks.  5:)

Original comment by mike.auty@gmail.com on 15 Sep 2011 at 7:08

[GoogleCodeExporter]

This issue was closed by revision r1066.

Original comment by jamie.l...@gmail.com on 15 Sep 2011 at 2:04

• Changed state: Fixed