search

pi-2r / volatility

Automatically exported from code.google.com/p/volatility
GNU General Public License v2.0
0 stars 0 forks source link

modules.lsmod usage in malware.threads #397

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Here I operate within a volshell instance and am using the Honeynet Challenge 
Bob.vmem sample (working in the context of PID 880).

Comparing the output of:
  sorted([ str(m.BaseDllName) for m in modules.lsmod(self.addrspace) ])
against:
  sorted([ str(m.BaseDllName) for m in self.proc.get_load_modules() ])
reveals very different lists.

As modules.lsmod(self.addrspace) is picking up its loaded modules from KDBG and 
self.proc.get_load_modules() uses _EPROCESS, I guess that the latter is the 
correct option for malware.threads?

Original issue reported on code.google.com by carl.pulley on 30 Mar 2013 at 4:22

GoogleCodeExporter commented 9 years ago 
Hey Carl, 

modules.lsmod() yields kernel modules and _EPROCESS.get_load_modules() yields 
DLLs in the target process (specifically from the 
_PEB.Ldr.InLoadOrderModuleList). For threads that start in kernel mode, we use 
the modules.lsmod() list to determine which kernel module it started it, and 
for threads that start in user mode we use the process-specific DLL list to 
resolve the owner. 

Here's where that decision occurs (based on whether the _ETHREAD.StartAddress 
is above _KDBG.MmSystemRangeStart (a kernel address):

https://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/malw
are/threads.py#432

Original comment by michael.hale@gmail.com on 30 Mar 2013 at 9:23

GoogleCodeExporter commented 9 years ago 
Sorry, I'd not immediately recognised the importance of that code (I had 
recognised that owner depended on mods/mod_addrs and then assumed that the code 
at line 335 was the start of the def-use chain for user mode threads - duh!).

Perhaps it might be clearer to place the user_mods/user_mod_addrs code (around 
lines 432-439) within the calculate method?

Original comment by carl.pulley on 30 Mar 2013 at 11:09

GoogleCodeExporter commented 9 years ago 
You're right, the module resolution is something you'd expect to happen in 
calculate() rather than render_text(). I've fixed this up in r3266 and as a 
positive side-effect we can also easily keep track of the processes whose dll's 
we've already enumerated so that work isn't duplicated each time.

Original comment by michael.hale@gmail.com on 2 Apr 2013 at 12:43