tking2 / volatility

Automatically exported from code.google.com/p/volatility
GNU General Public License v2.0
0 stars 1 forks source link

plugin proposal: MFT record scanner (actual code attached) #309

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I would like to propose the attached module.
As I do not rebuild the whole mft and the $files the info is not as complete as 
from NTFSinfo, yet getting the timeline from the memdump remains handy for 
standard response.

(if you accept to take it) Concerning licence, do as you want I do not really 
care. If you need some modif do not hesitate to ask.

Best regards,
--matthieu

Original issue reported on code.google.com by tecamac on 20 Jul 2012 at 6:40

Attachments:

GoogleCodeExporter commented 9 years ago
That's very cool matthieu, thanks for the contribution! We are in the process 
of getting 2.1 released and have a massive set of features already lined up for 
2.2, but I'm sure we can find some time to help test and implement this ;-) 
Keep up the good work, we'll keep this issue open and hopefully you'll get some 
feedback from users as they play with it ;-)

Original comment by michael.hale@gmail.com on 20 Jul 2012 at 9:54

GoogleCodeExporter commented 9 years ago
Thanks :)
KR,
--matthieu

Original comment by tecamac on 26 Jul 2012 at 11:49

GoogleCodeExporter commented 9 years ago
Matthieu,
  Just as an initial comment we would need this code to be eventually rewritten in terms of the volatility object parsing framework. So we would need to have vtypes/overlays etc written. The code should not need to use the struct module at all.

You can have a go at conversion now, or I can help you convert this later.

Original comment by scude...@gmail.com on 26 Jul 2012 at 3:36

GoogleCodeExporter commented 9 years ago
IE i should write the mft structures in overlays?
If so, where should I locate such structure? It is not OS dependent but file 
system dependent (only works for ntfs).
BR,
--matthieu

Original comment by tecamac on 26 Jul 2012 at 7:00

GoogleCodeExporter commented 9 years ago
You would write it in your plugin itself.  Currently in trunk with a
global profile it will be installed into the global profile, but in
future it will become a domain specific profile (i.e. only those who
care about ntfs can use it).

See these as examples (There are many more).
http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/overl
ays/windows/hibernate_vtypes.py
http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/malwa
re/svcscan.py

But it would be preferable that you place them in your plugin IMHO.

Michael.

Original comment by scude...@gmail.com on 26 Jul 2012 at 9:03

GoogleCodeExporter commented 9 years ago
This is cool Matthieu.  It's funny because I actually wrote a plugin to do this 
as well, which uses the proper Volatility structures.  I was planning to 
release it at OMFW, which is why I haven't release it yet.  

I'm thinking we can put the structures in the overlays folder, since they apply 
to all supported windows machines at this time.  (I'm guessing things will 
change when windows 8 hits, but we'll worry about that when it comes).  I'm 
thinking to upload what I have to this issue sometime after I get back from 
Vegas so we can combine our efforts and not duplicate work.  Since I already 
have the structures defined there is no reason to reimplement them I think ;-)

Original comment by jamie.l...@gmail.com on 27 Jul 2012 at 4:38

GoogleCodeExporter commented 9 years ago
oh actually I just saw scudette's comment above and that makes sense to keep it 
self contained in the plugin, which is actually how i have it.  so disregard 
that part ;-)

Original comment by jamie.l...@gmail.com on 27 Jul 2012 at 4:40

GoogleCodeExporter commented 9 years ago
Ho that's great! The structure part and the display part are quite boring. 
Please do not  hesitate to take part of the code I wrote to make a more 
appropriate module (you can even remove authorship I actually don't care as 
long as I have access to something which do the job ;p). 

You can also ask me to integrate the objects you wrote, this should be quite 
quick...

Cheers,
--matthieu

Original comment by tecamac on 27 Jul 2012 at 7:30

GoogleCodeExporter commented 9 years ago
By the way, i also have my personal parser for event logs in c, as i have to 
upgrade to evtx i was thinking about moving to volatility framework. 
Please tell me if this work is already ongoing on your side,
KR,
++matthieu

Original comment by tecamac on 28 Jul 2012 at 6:43

GoogleCodeExporter commented 9 years ago
Right now all we have is support for the older event log format (evt).  You can 
find a plugin for that in issue 241 (which needs to be updated).  

It would be interesting to have a plugin for evtx, but I'm wondering how much 
of the logs we'd get back.  They are not mapped the same way as the evt logs 
and from what I understand there are only minimal pieces of the logs in memory 
at any one time.  I'll have to check back in my notes, but I think this is the 
case.

Anyway, it still would be cool to have.  So if you want to take a stab at the 
evtx format, that would be cool :-)

Original comment by jamie.l...@gmail.com on 28 Jul 2012 at 6:00

GoogleCodeExporter commented 9 years ago

Original comment by jamie.l...@gmail.com on 22 Oct 2012 at 9:21