Closed GoogleCodeExporter closed 9 years ago
This is presumably a bigger problem than just with CSDVersion? If it's
legitimate to have a unicode string of length 0 and the buffer not matter, our
code should reflect that, so here's a counter patch (that also does away with a
catch-all exception handler, the removal of which can only be a good thing)...
So here's a counter-patch, please check if it fixes it, and if so let me know
and/or apply it if you think it's ok. 5:)
Original comment by mike.auty@gmail.com
on 22 Jan 2012 at 9:58
Attachments:
This issue was closed by revision r1296.
Original comment by michael.hale@gmail.com
on 22 Jan 2012 at 6:04
Please note that this returns an incorrect result for non-ascii strings.
Generally we should be returning a unicode object, or at least something which
is encoded correctly (say using utf8 which is a standard). Example:
In [18]: a = 'H\x00\xf6\x00r\x00e\x00n\x00'
In [19]: b = a.decode("utf16", "ignore")
In [20]: print b
Out[20]: Hören
In [21]: len(b)
Out[21]: 5
In [22]: b.encode("ascii", 'backslashreplace')
Out[22]: 'H\\xf6ren'
In [23]: len(_)
Out[23]: 8
Note that at least on linux the terminal is always utf8 so if we encode as utf8
at least it will be rendered properly. OTOH encoding to an escaped ascii will
always show garbage, and is not a standard encoding (its actually python
specific - you are encoding all utf8 codepoints as \u escapes).
Original comment by scude...@gmail.com
on 22 Jan 2012 at 6:31
That sounds like a separate issue to this fix, could you please file a new one?
Original comment by mike.auty@gmail.com
on 22 Jan 2012 at 6:33
We definitely need an overhaul of the unicode printing system (its kinda open
in http://code.google.com/p/volatility/issues/detail?id=168). Have you done
that in your branch scudette? At least with the patch for 186, it won't crash
anymore.
Original comment by michael.hale@gmail.com
on 22 Jan 2012 at 7:00
Someone just reported this issue to me today. I'm guessing this is also
related to issue 196. here's the output they sent:
$ python vol.py -f RAM.img imageinfo
Volatile Systems Volatility Framework 2.1_alpha
Determining profile based on KDBG search...
Suggested Profile(s) : WinXPSP3x86, WinXPSP2x86 (Instantiated with WinXPSP2x86)
AS Layer1 : JKIA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace (/home/<user>/ITSM/RAM.img)
PAE type : PAE
DTB : 0xa48000
KDBG : 0x8054d2e0
KPCR : 0xffdff000
KUSER_SHARED_DATA : 0xffdf0000
Image date and time : 1970-01-01 00:00:00
Image local date and time : 1970-01-01 00:00:00
Traceback (most recent call last):
File "vol.py", line 135, in <module>
main()
File "vol.py", line 126, in main
command.execute()
File "/home/<user>/volatility/volatility/commands.py", line 101, in execute
func(outfd, data)
File "/home/<user>/volatility/volatility/plugins/imageinfo.py", line 37, in render_text
for k, v in data:
File "/home/<user>/volatility/volatility/cache.py", line 534, in generate
for x in g:
File "/home/<user>/volatility/volatility/plugins/imageinfo.py", line 112, in calculate
for csdversion, numprocessors in self.find_task_items(addr_space):
File "/home/<user>/volatility/volatility/plugins/imageinfo.py", line 149, in find_task_items
csdvers[str(task.Peb.CSDVersion)] = csdvers.get(str(task.Peb.CSDVersion), 0) + 1
TypeError: __str__ returned non-string (type NoneObject)
Original comment by jamie.l...@gmail.com
on 1 Feb 2012 at 11:00
Original issue reported on code.google.com by
michael.hale@gmail.com
on 22 Jan 2012 at 8:21Attachments: