MHL,
Which you all have also told me numerous times again...I need to write
this stuff down.
Thanks for the reminder, I wasn't thinking about the malware plugin in
relation to the others. I think it was more so because it hadn't
shown up before even though the plugin was there that threw me.
Thanks again,
Tom
On Mon, Mar 19, 2012 at 4:16 PM, Michael Hale Ligh
<michael.hale(a)gmail.com> wrote:
Hey Tom,
The malware.py file should only be used with volatility 2.0. From the
output below, I can tell you that zesusscan1, zeusscan2, evtlogs, and
timeliner depend on malware plugins, so they also can only be used
with volatility 2.0.
There won't be a malware.py for volatility 2.1, because we're slowly
building the malware plugins into the volatility core. So the good
news is - when 2.1 is out, you won't have to synchronize files from
various locations...everything will just be there. The bad news is -
2.1 isn't out yet, but its close ;-)
MHL
On Mon, Mar 19, 2012 at 4:56 PM, Tom Yarrish <tom(a)yarrish.com> wrote:
> Mike,
> (sigh) I keep forgetting about that....it's probably the third or
> fourth time I forgot to do it.
>
> That got rid of most of the errors, now I get:
>
> Volatile Systems Volatility Framework 2.1_alpha
> *** Failed to import volatility.plugins.zeusscan1 (AttributeError:
> 'module' object has no attribute 'ImpScan')
> *** Failed to import volatility.plugins.zeusscan2 (AttributeError:
> 'module' object has no attribute 'ApiHooks')
> *** Failed to import volatility.plugins.evtlogs (AttributeError:
> 'module' object has no attribute 'LdrModules')
> *** Failed to import volatility.plugins.timeliner (AttributeError:
> 'module' object has no attribute 'LdrModules')
> Determining profile based on KDBG search...
>
> So I'm guessing those are plugin issues and not with Volatility itself.
>
> Tom
>
> On Mon, Mar 19, 2012 at 1:57 PM, Mike Auty <mike.auty(a)gmail.com> wrote:
>> Hi Tom,
>>
>> Please could you make sure to clean out your *.pyc files (or run make
>> clean), and then try using volatility again. Python should regenerate
>> these compiled python files whenever the contents of the original python
>> files change, but since subversion can set the timestamps of the newer
>> files in the past, this doesn't always happen. If you're still
>> experiencing problems after that, then we can investigate further...
>>
>> Thanks,
>>
>> Mike 5:)
> _______________________________________________
> Vol-users mailing list
> Vol-users(a)volatilityfoundation.org
>
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users