pstree broken in trunk

[GoogleCodeExporter]

Currently pstree is broken in trunk in a number of ways:

This bug report references the WIN-II7VOJTUNGL-20120324-193051.raw image from:
https://sites.google.com/site/volatilityng/sample-images/

This image is a chinese trial version with a process running named in chinese 
(just a copy of python.exe).

1) There is no check for circular references in find_root() so it will hang on 
cases where ppid/pid relations are circular - see for example the image above.

2) The check for config.VERBOSE is > 1. This is unexpected as we expect to set 
--verbose to see the commandline.

3) Finally, the UNICODE_STRING stuff is still broken, so even after fixing this 
it break on the above image:

 0xFFFFFA8002051060:?????ub?U.exe                     1964    384      1     32 2012-03-24 19:29:17       
Traceback (most recent call last):
  File "vol.py", line 173, in <module>
    main()
  File "vol.py", line 164, in main
    command.execute()
  File "/home/scudette/projects/volatility/trunk/volatility/commands.py", line 101, in execute
    func(outfd, data)
  File "/home/scudette/projects/volatility/trunk/volatility/plugins/pstree.py", line 86, in render_text
    draw_branch(0, root)
  File "/home/scudette/projects/volatility/trunk/volatility/plugins/pstree.py", line 72, in draw_branch
    ' ' * pad, task_info['command_line']))
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-8: 
ordinal not in range(128)

This happens despite the following lines in profiles:
volatility/plugins/overlays/windows/win7_sp1_x86_vtypes.py:    'CommandLine' : 
[ 0x40, ['_UNICODE_STRING']],

So it knows the CommandLine is actually unicode, yet it is still trying to 
convert it to a string.

These problems are fixed in the scudette branch so this is just a reminder for 
trunk to back port these fixes.

Expected output for the interesting process is:

 0xFFFFFA8002051060:��b�U.exe                         1964    384      1     32 2012-03-24 19:29:17       
    cmd: 可以访问该页面的单.exe
    path: c:\Python27\可以访问该页面的单.exe
    audit: \Device\HarddiskVolume2\Python27\可以访问该页面的单.exe

It seems that the _EPROCESS.ImageFileName is something weird (not any unicode 
encoding I recognize) but the commandline and image path from the other sources 
are normal _UNICODE_STRING.

Original issue reported on code.google.com by scude...@gmail.com on 4 Apr 2012 at 2:48

[GoogleCodeExporter]

According to [1], you're listed as primary maintainer of pstree, so how do you 
want to handle this?

[1] http://code.google.com/p/volatility/wiki/Plugins

Original comment by mike.auty@gmail.com on 6 Apr 2012 at 5:12

[GoogleCodeExporter]

I committed a back port of the fix for the circular reference issue but the 
unicode issue goes beyond pstree alone. Is unicode supported in trunk? If not 
we can close this bug, or else we can merge it with some other unicode related 
bug?

Original comment by scude...@gmail.com on 6 Apr 2012 at 5:39

[GoogleCodeExporter]

Unicode is supported in trunk for String objects by providing an encoding 
parameter, and so by extension _UNICODE_STRINGs.  The output format is ascii 
with encoding errors replaced by ?, so str(task_info['command_line']) should be 
used to ensure that the string can be printed to the console without issue.

Original comment by mike.auty@gmail.com on 6 Apr 2012 at 5:51

[GoogleCodeExporter]

Ok so unicode is supported by replacing non ascii characters with "?"?
Thats not what I would call supported.  If you check the scudette
branch the outfd which render_text() is writing on is not just a bare
stdout but its wrapped with a special class which ensure output is
encoded appropriately. You can also just use
codecs.StreamWriter(sys.stdout) instead to do the same thing.

So I think your unicode support in trunk is very close, you just need to:
 1) pass a wrapper stream to the render_text method in
commands.Comamnd.execute(). You can have a global flag which controls
encoding or do some clever guessing - on linux always use utf8, on
windows you need to find the current code page.

 2) Always expand formatting into unicode when writing. e.g (note the
unicode format string):
      outfd.write(u"{0}    cmd: {1}\n".format(' ' * pad,
process_params.CommandLine))

This is better than forcing the UNICODE_STRINGS to a string which will
destroy any unicode information.

Michael.

Original comment by scude...@gmail.com on 6 Apr 2012 at 6:11

[GoogleCodeExporter]

This issue was closed by revision r1870.

Original comment by michael.hale@gmail.com on 13 Jun 2012 at 3:52

• Changed state: Fixed