evtlogs and getservicesids plugins

[GoogleCodeExporter]

Here are two other plugins that I would like to include in the new release: 
evtlogs and getservicesids.  Both of these plugins rely on the registryapi from 
issue 240 and evtlogs relies on getservicesids if one wants to calculate 
service SIDs for the parsed output of the event logs.  evtlogs also relies on 
ldrmodules which should already be included in trunk.

I'm sure there are some changes that can be made.  Let me know if you have any 
comments :-)

Original issue reported on code.google.com by jamie.l...@gmail.com on 5 Apr 2012 at 1:54

• Blocked on: #240

Attachments:

• evtlogs.py
• getservicesids.py

[GoogleCodeExporter]

updated to reflect changes in issue 240

Original comment by jamie.l...@gmail.com on 22 Apr 2012 at 10:41

Attachments:

• evtlogs.py
• getservicesids.py

[GoogleCodeExporter]

I just realized that there were some changes in the vad stuff and I just 
changed another thing in issue 240, so I'm reattaching these.

Original comment by jamie.l...@gmail.com on 22 Apr 2012 at 11:58

Attachments:

• evtlogs.py
• getservicesids.py

[GoogleCodeExporter]

Original comment by mike.auty@gmail.com on 6 May 2012 at 1:04

[GoogleCodeExporter]

Hiya,

So there's a few updates these plugins need.  Registryapi is now stored in 
volatility.plugins.registry, and requires two arguments to initialize it (one 
of which is a config).  They're also not using the is_valid_profile override to 
identify which profiles they'll work with.

Getservicesids appears to not only list sids found, but also all the default 
sids in Vista+ irrespective of their presence.  Also, I was wondering how much 
time the default list saves, and whether it's worth it if they can all be 
calculated relatively quickly?  If there's no need for the big table, then I'd 
rather simplify things by not having it there...

I'm a little unkeen on evtlogs just generating new files in the current 
directory, we don't have any other plugins that work that way, so I'd 
recommend, if possible, outputting the lines of each file and separating them 
with a header (as we do with the output from other plugins for multiple 
processes).  If the existing output format is for some kind of import into 
another tool, then this may benefit from table formatting (however, there seem 
to be multiple variable length fields, so it may not be worth it after all).  
5:)

I haven't fully gone through evtlogs, but the string handling looks a little 
bit weird (several manual splits on double nulls).  I'm not sure how best to 
get around the way we handle strings, but it could do with some cleaning up.  
Also, the TimeWritten value should probably be done as a new UnixTimeStamp 
object in the windows/basic.py, and then the helper function can be done 
properly and reusing the existing machinery put in place for displaying 
timezones correctly, etc...

I'd also rewrite:

            if len(items) == 1:
                source = self.remove_unprintable(items[0])
            elif len(items) > 1:
                source = self.remove_unprintable(items[0])
                computer_name = self.remove_unprintable(items[1])

as 

            source = self.remove_unprintable(items[0])
            if len(items) > 1:
                computer_name = self.remove_unprintable(items[1])

Definitely getting there go!  One more clean-up and I think we'll be ready for 
committing!  5:)

Original comment by mike.auty@gmail.com on 15 Jun 2012 at 1:39

[GoogleCodeExporter]

Original comment by michael.hale@gmail.com on 28 Jun 2012 at 7:04

• Added labels: Milestone-2.2.x
• Now blocked on: #240

[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]

fixed in r2303 and r2308

Original comment by jamie.l...@gmail.com on 5 Sep 2012 at 12:14

• Changed state: Fixed