Using Helix 3 Pro, I took a memory capture of a compromised server. The capture finished, very slowly, but the Helix 3 Pro application froze during the verification phase.
I'm trying to analyze the memory capture using Volatility that's installed on SIFT Workstation 2.0.
When I ran
sansforensics@SIFT-Workstation/usr/local/src/volatility$ python volatility connscan -f /mnt/Share/ServerMem.img
I was able to get the connections just fine with that command.
When I saw a suspicious connection, I tried to dump it using
sansforensics@SIFT-Workstation/usr/local/src/volatility$ python volatility procdump -p 2156609524 -f /mnt/Share/ServerMem.img
I get the following output
Usage procdump [options] (see –help)
volatility error Unable to locate valid DTB in image.
I get that same error when I try several other switches, such as pslist, files, and suspicious. sockscan does work though.
Even when I run the ident switch, I get the following
Image Name /mnt/Share/ServerMem.img
Image Type UNKNOWN
Just to test that the volatility was working right I took a memdump from a different Windows XP system and ran it though all those in Volatility. Every single one worked and I was successfully able to pull executables out of memory.
Has anyone encountered the volatility error Unable to locate valid DTB in image and know a way around it, or perhaps a different Windows or Linux tool I can use to get a process listing and pull executables out of the memory image?
Sounds like your first memory dump is corrupted, volatility internal and plugin commands derive information from a memory dump using varying techniques. The DTB Directory Table Base is required by some of them to enumerate addressing, as this value is used by the C3 register of the processor to do address translation.
Using ident should produce something similar to this[echo6@logiq~/research/volatility/Volatility]$ ./volatility ident -f /home/echo6/research/memdumps/hacked.dd
Image Name /home/echo6/research/memdumps/hacked.dd
Image Type Service Pack 2
VM Type pae
DTB 0x319000
Datetime Tue Aug 11 130302 2009
So the reason why connscan is succesful is because it basically searches the whole memory image for data structure artifcats that resemble connections, i.e. connection objects. Whereas things like pslist require address translation to start reconstructing the process tree by "walking a list", it has to have some reference point from where to start.
Hope this makes sense! Also, all is not lost though, it might be worth popping into IRC #volatility on freenode and asking for further assistance with your memory dump.
@ honor_the_ways
Were you able to figure anything out? I cannot for the life of me get volatility working. I have tried to acquire using Helix, windd, etc.
I am trying to snap images within my vmware box (windows 7), and I have tried every possible file combinations, .img, .dd, 001, bin, dmp, mem, etc. and NOTHING works. When I run the ident flag i get UNKNOWN. I don't ever see anything when running connscans, pslist, etc.
I have spent hours imaging the memory. I actually changed my memory to 1024 to speed the process up from within my vmware configuration.
I suggest you get Tortoise SVM and use it to download and install the latest version of volatility (1.4) from the Google SVM archive.
Also, you may also want to use Python 2.5 - I've had issues with other versions.
You could also try out the Windows memory enscripts I mentionned in a post earlier this week. Basically Volatility ported to EnScripts.
http//www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=7241
... -p 2156609524 ...
Sure it is correct?
I svn checked out 1.4 and it fixed my issues. I used my linux machine, which is much easier than the windows route. Most of the python depends are already native.
Anyway, it seems to work after using the profiles optiones… #vol.py –profile=Win7SP0x86 [command] -f [image_name] [output-file=[filename.whatever] etc….
Also realized ServerMem.img. Are you using Server 2008 or something like new(er) like that?