auto-detecting the profile

[GoogleCodeExporter]

Quick question...why do we default to xpsp2 instead of auto-detecting the 
profile (like imageinfo does) if a user doesn't supply --profile? Is it because 
some profiles look related (like vista sp1/2 and w2k8 sp1/2)? I feel like we 
should develop a method of making that reliable, at least for the release that 
follows 2.0. In the case where you've got several memory dumps from unknown 
systems and want to iterate over them all like:

$ for i in `ls /dir/mem`; do ./vol.py pslist -f $i; done 

That wouldn't be possible right now, unless they are all xpsp2. In the future 
once we set up other rendering functions (like render_sql) it would be a nice 
feature to iterate over them all with one command...then go back and analyze 
your database. Thoughts?

Original issue reported on code.google.com by michael.hale@gmail.com on 29 Jun 2011 at 6:34

[GoogleCodeExporter]

I think this would be a good feature.  It definitely would make things easier 
as you stated there.  Not sure why we don't do this for other plugins either.  
I await ikelos' reasoning :-)

Original comment by jamie.l...@gmail.com on 29 Jun 2011 at 6:51

[GoogleCodeExporter]

Hmmm, we currently do this because it takes a long time to check all the 
profiles, and will likely take even longer once we include linux/64-bit 
profiles.  Generally XPSP2 was a good default, although that may not be the 
case anymore.

If people want to spend a long time, they probably won't mind spending a few 
extra seconds running imageinfo first.  If they don't want to spend a long 
time, they definitely will *not* want to wait for scanning to complete on every 
run.

Given that users can also specify their favoured default using the config file, 
I'd rather not put profile auto-detection into every plugin.  I am however up 
for changing the de-facto default profile if people think XPSP2 is less common 
these days?  Which is the most common one?

Original comment by mike.auty@gmail.com on 29 Jun 2011 at 6:57

[GoogleCodeExporter]

Alright, I'm going to close this issue. Its been open long enough and seems 
like supplying --profile on command line (or in a user preference file) is 
pretty set in stone. 

If, however, someone finds a quicker way to identify the OS in the future, feel 
free to re-open. It would come in handy, for example, if you have a repository 
of 100 memory dumps and want to check which ones have a particular process 
running. 

$ for i in `ls /dir/mem`; do ./vol.py pslist -f $i >> output; done 
$ grep process_name output

Original comment by michael.hale@gmail.com on 27 Oct 2011 at 3:02

• Changed state: Invalid