AW: [Vol-dev] Re: Pylint and code questions

Hello Mike, hello list, -----Ursprüngliche Nachricht----- Von: Mike Auty [mailto:mike.auty@gmail.com] Gesendet: Sonntag, 13. September 2009 22:14 An: Michael Felber Cc: vol-dev(a)volatilityfoundation.org Betreff: Re: [Vol-dev] Re: Pylint and code questions Michael Felber wrote: Hiya Michael! moment (the raw1394 is unable to see the Vista PC). I've used it in anger against a Vista box without problem (well, it appeared to bluescreen *slightly* more often, but that's just an opinion). --> With your mental support in mind I've managed it today to take a 1394memimage of a Vista running desktop machine. (After 3GB it did end twice, maybe because my own machine has only 4GB like the target machine and on mine a John was running in the background cracking a cached domain password) https://www.moonloop.org/bin/view/Moonloop/Stream?tag=ida) to winlockpwn so it works fine with any uptodate SP3 system I have testet. --> Sadly it seems to fail with Vista anyway. I'll try to look at the msv1_0.dll with IDA and hope to be able to adapt my extension. Everyone is invited to have a look at it too. (see attachement) That's cool, I was hoping to extend the idea, so there'd be a volatility plugin that locates DLL images within memory, pieces them back together using pefile, extracts the version information from the resource section and then uses the filename and resource to lookup the correct offsets and patches to apply to the image. I've already got some proof of concept stuff for extracting version information after finding the page with the DLL MZ header. The idea is there'd be a big database of useful patches, and then they could be automatically deployed against a live system. --> You think of some kind of RAM-backtrace. Cool, I'll like it. The code from winlockpwn should be included, if metlstorm agrees. All of this, however, would require enhancing the volatility plugin interface to accept address spaces (and command line options) rather than just command line options. It should help reduce a bit of the code duplication that's going on, but it's quite an invasive change, and might require plugin rewrites (unless we work in a plugin versioning system, something like plugins based on forensics.commands.commandv2 maybe?). That'll start to get complicated over time though, and in either situation the input interface will need to be designed carefully. I'm still at too early a stage with the code to figure out what the various plugins out there need/use and what they don't, so I can throw out/mock up suggestions for how it might work, but it'll need someone with a bit more knowledge of the system to let me know if I've missed anything or if the interface isn't right for any reason. It'd be most useful to find out what people think about backwards compatibility for plugins? Is it worth trying to keep old plugins working, or do you think people would be happy enough rewriting for the new architecture? --> Sadly I am not able to write for any architecture yet. I did learn and teach programming with Turbo Pascal years ago. Now I am willing learning Python as well. volatile, even a memory dump is not as consistent as a hiberfil.sys or memory.dmp would be. No, I know that, the firewire extension I'm proposing was to use all the existing plugins to examine a live system from an educational/debugging perspective, rather than as evidence. I figured that being able to see how memory gets reallocated and manipulated live might be of interest, just like the behaviour of live animals is of use to archaeologists... 5;) --> From that point of view you're completely right. As a forensics guy I need pure evidences but sometimes it needs a little bit of hacking and cracking to get it. So the Firewire access is a funny thing getting a pure memory snapshot finding things in it a post mortem image of the hdd never would show. Today I've tested that with Truecrypt passphrases (see another posting). Cu Michael Mike 5:)