Volatility - cmdscan buggy?

I tweeted last week that I was impressed with a new command in Volatility called cmdscan.  The command is designed to extract command shell history.  I had run it on a variety of new and old RAM dumps and appeared to get slightly random results, often interspersed with obviously correct history.

In my tweet I made the comment that the command was good but a bit buggy. 

An example of my issues are in the image below:-

You can see that the upper part of the results seem to display erroneous results whereas the lower portion is very obviously a series of recovered commands. 

To my pleasant surprise Michael Ligh himself dropped me a line asking for more details which I duly provided only to discover that I should have not been such an ass but have checked the code before making the comment,  Turns out it is doing exactly what it should.  I thank Mike for his gracious response and explanation which I re-print here:-

MHL

...so in short, cmdscan is to consoles as psscan is to pslist. In other words, the consoles plugin (not sure if you tried that one) will find active/running console sessions (like pslist will only find active processes) and not only print command history but full input/output buffers. The cmdscan plugin, on the other hand, will scan through memory using pattern matching and try to brute force with sanity checks etc - the advantage being that it can not only find histories from active/running processes but also closed consoles that have been partially deallocated or overwritten (similar to how psscan carves and finds terminated processes).

If you take a look at the command history structure:

http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/malware/cmdhistory.py#44

You'll see there's a CommandBucket member which is an array of pointers (to command structures). The CommandCount member tells you how many pointers in the CommandBucket are valid. However, if the command history structs belong to closed/terminated processes, then we cannot rely on CommandCount. It could be 0 although there are still valid pointers in the CommandBucket array. Or vice versa - it could be 40 although there are only 10 valid pointers in the array - not even continuous, it could be slots 0, 4, 5, 10, 11, 12, 18, etc.

So cmdscan ignores the CommandCount member and treats CommandBucket as an array of 50 pointers, because 50 is the max history on most systems. If a pointer points to a valid location (i.e. somewhere allocated and not paged) and looks like it might be at lest some unicode characters, then its printed to the terminal.

If you look at your "Screen Shot 2012-09-21 at 15.27.59.png" image, it says CommandCount is 15. You see slots 0-14 are are valid but it goes on to print slot 18, 25, 32, 39, and 46 anyway just in case CommandCount isn't accurate. The consoles command would trust CommandCount and only print slots 0-14.

After looking at the screen shots, I'd say the plugin is working as expected. So if you do get a chance to look over the code, its pretty well commented and you should be able to figure out why it seemed buggy.

Thanks again to MHL and the Volatility team for such a useful toolset.