search

Leor3961 / volatility

Automatically exported from code.google.com/p/volatility
0 stars 0 forks source link

No output from dlllist or files when given process offset #53

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Suppose I have this process [output from psscan some output removed]:

Offset     PDB        Remarks
---------- ---------- -----------
0x0218d020 0x0e0808a0 cmd.exe 

$ ./volatility.py dlllist -f xpsp3.vmem -o 0x0218d020 --profile=WinXPSP3x86
Volatile Systems Volatility Framework 1.4_rc1
************************************************************************
- pid: ------
Unable to read PEB for task.

$ ./volatility.py files -f xpsp3.vmem -o 0x0218d020 --profile=WinXPSP3x86
Volatile Systems Volatility Framework 1.4_rc1

But with Volatility 1.3.2:

$ ./volatility dlllist -f xpsp3.vmem -o 0x0218d020
cmd.exe pid: 3460
Command line : "C:\WINDOWS\system32\cmd.exe" 

Base         Size         Path
0x4ad00000   0x61000      C:\WINDOWS\system32\cmd.exe
0x7c900000   0xb2000      C:\WINDOWS\system32\ntdll.dll
0x7c800000   0xf6000      C:\WINDOWS\system32\kernel32.dll
0x77c10000   0x58000      C:\WINDOWS\system32\msvcrt.dll
0x7e410000   0x91000      C:\WINDOWS\system32\USER32.dll
0x77f10000   0x49000      C:\WINDOWS\system32\GDI32.dll
0x5cb70000   0x26000      C:\WINDOWS\system32\ShimEng.dll
0x6f880000   0x1ca000     C:\WINDOWS\AppPatch\AcGenral.DLL
0x77dd0000   0x9b000      C:\WINDOWS\system32\ADVAPI32.dll
[snip]

$ ./volatility files -f xpsp3.vmem -o 0x0218d020
Pid: 3460  
File   
\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.
5512_x-ww_35d4ce83
File   \Documents and Settings\Administrator\Desktop

Original issue reported on code.google.com by jamie.l...@gmail.com on 16 Dec 2010 at 9:20

GoogleCodeExporter commented 8 years ago 
Hey guys, I was looking at this a little with Gleeda earlier. It looks like 
with 1.3, dlllist is taking the -o parameter and using it as a flat address:

try:
    flat_address_space = FileAddressSpace(filename)
except:
    op.error("Unable to open image file %s" %(filename))

directory_table_base = process_dtb(flat_address_space, types, offset)

The 1.4 dlllist uses -o as a virtual address instead:

addr_space = utils.load_as(self._config)

if self._config.OFFSET != None:
   tasks = [obj.Object("_EPROCESS", self._config.OFFSET, addr_space)]
else:
   tasks = self.filter_tasks(win32.tasks.pslist(addr_space))

So if you change it to utils.load_as(self._config, astype = 'physical'), then 
we're able to at least get an EPROCESS object, but getting the process address 
space and parsing the PEB becomes problematic.

Original comment by michael.hale@gmail.com on 17 Dec 2010 at 12:02

GoogleCodeExporter commented 8 years ago 
Ok, so I've just committed a potential fix, so that the behaviour is now the 
same as volatility-1.3.

The basic idea is to use both a physical and virtual address space.  Then we 
grab the virtual address of the first thread in ThreadListHead, and instantiate 
an _ETHREAD object in the virtual address space.  From there, we can bounce 
back to the _EPROCESS in virtual address space by simply dereferencing 
ThreadsProcess.  It's a little circuitous, but it's probably the best option 
we've got.

I'm happy to hear issues with this method, and other possible suggestions, but 
for the time being I'm going to mark this as Fixed.  Do please reopen this if 
you think that there are any forensic implications of the method we use to find 
the virtual _EPROCESS object (for instance, what if the offset is a dead 
_EPROCESS that's left in physical memory, but no longer has a virtual 
counterpart?  Should we be checking to make sure the physical and virtual 
_EPROCESSes match on certain fields?).  Just to make sure I get a few extra 
eyes on this now, I'm going to pull in Moyix as my chosen expert for this one 
(if that's ok? for some reason my instinct tells me this is your domain), and 
MHL since he was interested in finding a solution too...  5:)

Original comment by mike.auty@gmail.com on 17 Dec 2010 at 1:56

GoogleCodeExporter commented 8 years ago 
This seems to work, but I had something weird happen that I can't seem to 
reproduce.  Using Moyix's ds_fuzz_hidden_proc.img image:

$ python volatility.py dlllist -f ds_fuzz_hidden_proc.img --profile=WinXPSP3x86 
-o 0x01a4bc20

Volatile Systems Volatility Framework 1.4_rc1
************************************************************************
- pid: ------
Unable to read PEB for task.

# I know I should be able to read this...  I try without a profile:

$ python volatility.py dlllist -f ds_fuzz_hidden_proc.img -o 0x01a4bc20 
Volatile Systems Volatility Framework 1.4_rc1
************************************************************************
network_listene pid:   1696
Command line : "C:\Documents and Settings\moyix\Desktop\network_listener.exe" 
Service Pack 3

Base         Size         Path
0x00400000   0x022000     C:\Documents and 
Settings\moyix\Desktop\network_listener.exe
0x7c900000   0x0af000     C:\WINDOWS\system32\ntdll.dll
0x7c800000   0x0f6000     C:\WINDOWS\system32\kernel32.dll
0x71ab0000   0x017000     C:\WINDOWS\system32\WS2_32.dll
0x77dd0000   0x09b000     C:\WINDOWS\system32\ADVAPI32.dll
0x77e70000   0x092000     C:\WINDOWS\system32\RPCRT4.dll
0x77fe0000   0x011000     C:\WINDOWS\system32\Secur32.dll
0x77c10000   0x058000     C:\WINDOWS\system32\msvcrt.dll
0x71aa0000   0x008000     C:\WINDOWS\system32\WS2HELP.dll
0x71a50000   0x03f000     C:\WINDOWS\system32\mswsock.dll
0x662b0000   0x058000     C:\WINDOWS\system32\hnetcfg.dll
0x77f10000   0x049000     C:\WINDOWS\system32\GDI32.dll
0x7e410000   0x091000     C:\WINDOWS\system32\USER32.dll
0x76390000   0x01d000     C:\WINDOWS\system32\IMM32.DLL
0x71a90000   0x008000     C:\WINDOWS\System32\wshtcpip.dll

# Got it!  Now I try with a profile again:

$ python volatility.py dlllist -f ds_fuzz_hidden_proc.img --profile=WinXPSP3x86 
-o 0x01a4bc20
Volatile Systems Volatility Framework 1.4_rc1
************************************************************************
network_listene pid:   1696
Command line : "C:\Documents and Settings\moyix\Desktop\network_listener.exe" 
Service Pack 3

Base         Size         Path
0x00400000   0x022000     C:\Documents and 
Settings\moyix\Desktop\network_listener.exe
0x7c900000   0x0af000     C:\WINDOWS\system32\ntdll.dll
0x7c800000   0x0f6000     C:\WINDOWS\system32\kernel32.dll
0x71ab0000   0x017000     C:\WINDOWS\system32\WS2_32.dll
0x77dd0000   0x09b000     C:\WINDOWS\system32\ADVAPI32.dll
0x77e70000   0x092000     C:\WINDOWS\system32\RPCRT4.dll
0x77fe0000   0x011000     C:\WINDOWS\system32\Secur32.dll
0x77c10000   0x058000     C:\WINDOWS\system32\msvcrt.dll
0x71aa0000   0x008000     C:\WINDOWS\system32\WS2HELP.dll
0x71a50000   0x03f000     C:\WINDOWS\system32\mswsock.dll
0x662b0000   0x058000     C:\WINDOWS\system32\hnetcfg.dll
0x77f10000   0x049000     C:\WINDOWS\system32\GDI32.dll
0x7e410000   0x091000     C:\WINDOWS\system32\USER32.dll
0x76390000   0x01d000     C:\WINDOWS\system32\IMM32.DLL
0x71a90000   0x008000     C:\WINDOWS\System32\wshtcpip.dll

# Not sure what happened, but now I get output with a profile everytime.... :-/

Original comment by jamie.l...@gmail.com on 17 Dec 2010 at 2:07

GoogleCodeExporter commented 8 years ago 
I haven't gotten to test again yet, but most likely the output of your second 
command (without profile) is cached and its getting picked up by the third 
command. If you do this:

$ python volatility.py dlllist -f ds_fuzz_hidden_proc.img --profile=WinXPSP3x86 
-o 0x01a4bc20 --no-cache

Does it output the same as your first command?

I had a similar issue recently where specifying a profile didn't work, but not 
specifying a profile (and letting it choose) did work. Hmm if I can remember 
the situation or resolution I'll comment back..

Original comment by michael.hale@gmail.com on 17 Dec 2010 at 2:50

GoogleCodeExporter commented 8 years ago 
Ah, yes.  I thought about that... and attc also asked me about this on the 
channel.  I completely removed the cache and did --no-cache.  I can't reproduce 
the problem.  I moved to another machine that hadn't seen this image and ran 
with --no-cache and still couldn't reproduce the problem.

Original comment by jamie.l...@gmail.com on 17 Dec 2010 at 2:54

GoogleCodeExporter commented 8 years ago 
So my guess is, in fact, that the first command was cached (since the cache 
should always be ignored if the profile changes, and is cached based on the pid 
and now also the offset provided).  When you tried with the profile, after the 
code had changed, it re-read the cached (with the duff data), and then when you 
changed the profile it recreated the cache with the new profile (XPSP2).  Then 
when you went for XPSP3 again, it also recreated the cache, and it all worked 
out fine.  5:)

Glad to hear it's now returning you the correct results...

Original comment by mike.auty@gmail.com on 17 Dec 2010 at 3:01

GoogleCodeExporter commented 8 years ago 
I am getting this problem. Can someone tell me what's the fix?

$ python vol.py --profile=Win2K3SP0x86 -f 
~/Desktop/cases/Memory/XYwin2003-2006-03-17.img dlllist --offset=0x063baa10
Volatile Systems Volatility Framework 2.1_alpha
************************************************************************
- pid: ------
Unable to read PEB for task.

Original comment by aniket.b...@gmail.com on 21 Aug 2012 at 8:16