Closed GoogleCodeExporter closed 8 years ago
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
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
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
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
> 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
Original comment by michael.hale@gmail.com
on 18 Aug 2011 at 9:23
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
> 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
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
That sounds good to me, thanks. 5:)
Original comment by mike.auty@gmail.com
on 15 Sep 2011 at 7:08
This issue was closed by revision r1066.
Original comment by jamie.l...@gmail.com
on 15 Sep 2011 at 2:04
Original issue reported on code.google.com by
michael.hale@gmail.com
on 18 Aug 2011 at 6:01Attachments: