Address Space usage in Malware/Threads

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Using the Honeynet challenge 3 memory image (i.e. Bob.vmem) list threads 
under PID 1752 (i.e. vol.py -f Bob.vmem threads -p 1752)

2. Modify the plugins/malware/threads.py code so that at lines 494, 495 and 
498, thread.StartAddress is replaced by trapframe.Eip. Now repeat step 1 using 
this modified code.

What is the expected output? What do you see instead?

1. No disassembly is performed for any of the threads. Working via volshell in 
the context of PID 1752, the dis command can be used to disassemble valid 
instructions (at least for some of the processes threads).

2. No disassembly is performed for any of the threads (they all have an Eip 
value of 0x7c90eb94) - this in itself seems odd (surely Eip should be a valid 
address?). Working via volshell in the context of PID 1752, the dis command can 
be used to disassemble valid instructions.

What version of the product are you using? On what operating system?

Using 2.3 alpha (revision 3179) of Volatility.

Please provide any additional information below.

Looking at plugins/malware/threads.py and plugins/volshell.py, it appears that 
the difference observed above is due to differing address spaces being used?

plugins/volshell.py is using the process address space, whilst 
plugins/malware/threads.py appears to use the configured profiles address space?

It appears that plugins/malware/threads.py should actually be using the 
(current filtered) processes address space?

Original issue reported on code.google.com by carl.pulley on 15 Mar 2013 at 2:02

[GoogleCodeExporter]

Original comment by jamie.l...@gmail.com on 18 Mar 2013 at 9:06

[GoogleCodeExporter]

Hey Carl, 

Thanks for reporting. I made a few changes in the latest revision. One change 
makes it use a process AS when disassembling the StartAddress (should be fine 
now for threads that start in kernel or user mode). 

Regarding the common Eip value of 0x7c90eb94, I think that's OK. It is 
KiFastSystemCallRet. Also, most if not all threads that start in user mode will 
have a StartAddress of 0x7c810856 UNKNOWN (in Bob.vmem) which is inside 
kernel32!CreateThread. I updated the plugin to show something like "0x7c810856 
kernel32.dll" instead. 

Let me know if that doesn't improve things for you. 

Original comment by michael.hale@gmail.com on 25 Mar 2013 at 3:32

[GoogleCodeExporter]

This issue was closed by revision r3181.

Original comment by michael.hale@gmail.com on 25 Mar 2013 at 3:55

• Changed state: Fixed