RE: [Vol-users] Output of strings not found in memdump output - QEMU/QEVM sample

Thanks Michael, I confirm that I now see what I was expecting. Sorry for the rookie mistake. I *really* need to get to your class... Geoff I only said that because I didn't think I was... :-P -----Original Message----- From: vol-users-bounces(a)volatilityfoundation.org [mailto:vol-users-bounces@volatilesystems.com] On Behalf Of Michael Ligh Sent: Saturday, May 09, 2015 9:00 AM To: vol-users(a)volatilityfoundation.org Subject: Re: [Vol-users] Output of strings not found in memdump output - QEMU/QEVM sample -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Geoff, The key to get strings working is to make sure you have a raw memory dump. lqs2mem *should* give you that, however I've not personally used it before. One discrepancy I see with your logic is regarding this line: memory_dump.ram.vol.strings:183190042 [3156:0189321a] <Search_String> It tells you the search string is at virtual address 0189321a in pid 3156. You then dumped the *executable* for pid 3156 which gives you memory from the base of the exe 400000 to its base + size (nowhere near 0189321a). Try using the memdump or vaddump plugins on 3156 instead. That will give you ALL of the process's addressable memory, not just the range that contains the exe. MHL On 5/7/15 3:03 PM, Torres, Geoff (Cyber Security) wrote: > Hi, > > Sorry for the 'me too' response, but I'm having this exact same > problem. However, the main difference is that I'm using a 'QEMU' > memory image (Hex dump sig is QEVM in the first 4 bytes) from a cloud > instance. > > I've converted these in the past using the 'lqs2mem' tool written by > Juerg Haefliger and Andrew Tappert and it's worked perfectly for the > 'netscan' and 'ps' type plugins. However, I haven't needed to dump > processes before and look for specific strings. I can locate the > strings in the converted image, but it's not translating to the > processes that are identified by the 'strings' plugin. > > > Here's the steps I've been taking - > > ## Memory dump info >> ll memory_dump > -rw------- 1 geoff citsirt 7579914273 Apr 27 13:36 memory_dump > >> file memory_dump > memory_dump: QEMU suspend to disk image > >> xxd memory_dump | head -n1 > 0000000: 5145 564d 0000 0003 0100 0000 0105 626c QEVM..........bl > > > ## Convert the dump >> lqs2mem -w pc.ram memory_dump memory_dump.ram > section = pc.ram size = 8192 [MB] > 8589934592 [bytes] section = pc.bios size > = 128 [KB] 131072 [bytes] section = pc.rom > size = 128 [KB] 131072 [bytes] section = vga.vram > size = 16 [MB] 16777216 [bytes] section = > 0000:00:02.0/cirrus_vga.rom size = 64 [KB] 65536 > [bytes] Wrote 8589934592 bytes from section 'pc.ram' to file > memory_dump.ram > > > ## Create the strings file >> strings -a -t d memory_dump.ram > memory_dump.ram.strings > >> strings -a -t d -el memory_dump.ram >> memory_dump.ram.strings > > > ## Create the volatility strings file >> python /data/download/apps/forensic_tools/volatility/vol.py -f >> memory_dump.ram --profile=Win2008SP2x64 strings -s >> --output-file=memory_dump.ram.vol.strings > > >> ll memory_dump.ram.strings memory_dump.ram.vol.strings > -rw-rw-r-- 1 geoff citsirt 2914258187 May 7 08:58 > memory_dump.ram.strings -rw-rw-r-- 1 geoff citsirt 4292775089 May > 7 12:17 memory_dump.ram.vol.strings > > > ## '<Search_String>' is found in both string files as expected >> fgrep <Search_String> memory_dump.ram.strings >> memory_dump.ram.vol.strings > memory_dump.ram.strings:183190042 <Search_String> > memory_dump.ram.vol.strings:183190042 [3156:0189321a] <Search_String> > > > ## Dump process 3156 as identified by volatility >> python /data/download/apps/forensic_tools/volatility/vol.py -f >> memory_dump.ram --profile=Win2008SP2x64 procdump -p 3156 -D >> processes -m > Volatility Foundation Volatility Framework 2.4 Process(V) > ImageBase Name Result ------------------ > ------------------ -------------------- ------ 0xfffffa800a4e6370 > 0x0000000000400000 iwproxy.exe OK: executable.3156.exe > >> ll processes/executable.3156.exe > -rw-rw-r-- 1 geoff citsirt 3248128 May 7 12:35 > processes/executable.3156.exe > > > ## '<Search_String>' not found in the dumped executable >> strings -a processes/executable.3156.exe | fgrep <Search_String> >> strings -a -el processes/executable.3156.exe | fgrep >> <Search_String> > > > I've tried many different variations of the above steps and all > have the same results. > > According to what I've read in this thread is that the issue is to > make sure the original dump is properly converted. How can I do > that? 'lqs2mem' has limited options. > > Any ideas on what I can do differently to get this to work? > > Thanks, > > Geoff > > > > -----Original Message----- From: > vol-users-bounces(a)volatilityfoundation.org > [mailto:vol-users-bounces@volatilityfoundation.org] On Behalf Of Michael > Ligh Sent: Tuesday, March 24, 2015 6:49 AM To: Bridgey theGeek Cc: > vol-users(a)volatilityfoundation.org Subject: Re: [Vol-users] Output of > strings not found in memdump output > > Perfect! Glad to hear all is good in the world ;-) > > MHL > > On 3/24/15 5:05 AM, Bridgey theGeek wrote: >> Awesome, thanks Michael. > >> I generated a raw dump as follows, with the vmsn and vmem files >> in the same folder: $ python vol.py -f winxp.vmem >> --profile=WinXPSP2x86 imagecopy -O winxp.raw > >> Then ran strings again (having generated a new input text file >> because of course the offsets will be different): $ python vol.py >> -f winxp.raw --profile=WinXPSP2x86 strings -s pk.txt > >> I was then able to find the banner at the offsets reported by >> strings. And all was good in the world. > >> Thank you very much for the support. > >> Adam > >> On 23 March 2015 at 19:39, Michael Ligh &lt;michael.ligh(a)mnin.org >> <mailto:michael.ligh@mnin.org>> wrote: > >> Hey Adam, > >> A few things: > >> * Yes, vmss2core creates a windows crash dump * You can use >> volatility on the original vmem/vmss by doing the following: > >> * make sure both vmem and vmss files are in the same dir * make >> sure they have the same base name (i.e. test.vmem and test.vmss) >> * run your volatility plugins against the vmem > >> In this case, it would also be required to generate a raw memory >> dump before running strings. So you would use imagecopy on the >> vmem. > >> LMK if that helps! Michael > >> On 3/23/15 10:51 AM, Bridgey theGeek wrote: >>> Hi Michael, > >>> *sigh* When will I learn to check the origin of my samples?! > >>> The guy who provided me with the sample tells me that he took a >>> snapshot of a VMWare machine and then used vss2core to convert >>> it. I BELIEVE that makes it into a Windows Memory Core Dump..? > >>> I got hold of the original vmem and vmsn files. Trying to use >>> imagecopy on the vmsn just replicated the input file. I think >>> the header is not what Volatility would expect: $ xxd Windows\ >>> XP\ Pro\ SP2\ \(32-bit\)-Snapshot49.vmsn |head 0000000: d2be >>> d2be 0800 0000 6300 0000 4368 6563 ........c...Chec 0000010: >>> 6b70 6f69 6e74 0000 0000 0000 0000 0000 kpoint.......... >>> 0000020: 0000 0000 0000 0000 0000 0000 0000 0000 >>> ................ 0000030: 0000 0000 0000 0000 0000 0000 0000 >>> 0000 ................ 0000040: 0000 0000 0000 0000 0000 0000 >>> fc1e 0000 ................ 0000050: 0000 0000 ab03 0000 0000 >>> 0000 4775 6573 ............Gues 0000060: 7456 6172 7300 0000 >>> 0000 0000 0000 0000 tVars........... 0000070: 0000 0000 0000 >>> 0000 0000 0000 0000 0000 ................ 0000080: 0000 0000 >>> 0000 0000 0000 0000 0000 0000 ................ 0000090: 0000 >>> 0000 0000 0000 0000 0000 a722 0000 .............".. > >>> Does that mean I can't use this with Volatility? > >>> Thank you, Adam > >>> On 23 March 2015 at 14:57, Michael Ligh &lt;michael.ligh(a)mnin.org >>> <mailto:michael.ligh@mnin.org> <mailto:michael.ligh@mnin.org >>> <mailto:michael.ligh@mnin.org>>> wrote: > >>> Hey Adam, > >>> We forgot to ask if the sample was a raw memory dump. For >>> example: > >>> $ xxd ~/Desktop/memory.dmp | less > >>> 0000000: 5041 4745 4455 4d50 0f00 0000 280a 0000 >>> PAGEDUMP....(... 0000010: 8001 6c07 00c0 e680 a031 5580 5892 >>> 5580 ..l......1U.X.U. 0000020: 4c01 0000 0100 0000 8000 0000 >>> 5444 4f00 L...........TDO. 0000030: 0000 0000 0000 0000 0000 >>> 0000 5041 4745 ............PAGE 0000040: 5041 4745 5041 4745 >>> 5041 4745 5041 4745 PAGEPAGEPAGEPAGE > >>> If its something like a crash dump, hibernation, etc then the >>> file format headers throw off the offsets. You can convert >>> those special file types into a raw memory dump with the >>> imagecopy plugin and then your strings translations should be >>> accurate. > >>> Cheers! MHL > >>> On 3/23/15 8:54 AM, Bridgey theGeek wrote: >>>> Hi Andrew, > >>>> I was certain I was running the latest version, but just to >>>> be sure I grabbed the latest version. Same result, same >>>> offsets. > >>>> I can make the sample available, but more than happy to do >>>> whatever debugging needs doing (if I can!) > >>>> Adam > >>>> On 23 March 2015 at 13:03, Andrew Case &lt;atcuno(a)gmail.com >>>> <mailto:atcuno@gmail.com> <mailto:atcuno@gmail.com >>>> <mailto:atcuno@gmail.com>> >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> >>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>> wrote: > >>>> Are you using the latest git checkout of Volatility or the >>>> 2.4 release? Can you try the latest checkout and re-run >>>> Volatility strings (you can run it on just the offsets from >>>> PID 123 to make it faster). > >>>> If you are already on the latest checkout then we will need >>>> to debug further. > > > > >>>> Thanks, Andrew (@attrc) > >>>> On 03/23/2015 04:38 AM, Bridgey theGeek wrote: >>>>> Thanks Andrew: >>>>> >>>>> python vol.py --profile=WinXPSP2x86 -f memory.dmp volshell >>>>> -p 123 Volatility Foundation Volatility Framework 2.4 >>>>> Current context: myapp.exe @ 0x822042f8, pid=123, ppid=392 >>>> DTB=0x76c0040 >>>>> Welcome to volshell! Current memory image is: >>>>> file:///home/memory.dmp To get help, type 'hh()' >>>>>>>> db(0x75b6b4d8) >>>>> 0x75b6b4d8 c3 7c 15 c7 85 00 ff ff ff 01 00 00 00 75 09 8d >>>>> .|...........u.. 0x75b6b4e8 85 0c ff ff ff 50 ff 17 39 >>>>> 9d 00 ff ff ff 89 85 .....P..9....... 0x75b6b4f8 30 ff ff >>>>> ff 74 12 6a 0c 8d 85 c4 fe ff ff 50 6a 0...t.j.......Pj >>>>> 0x75b6b508 07 6a fe e8 ea 92 ff ff 83 bd 28 ff ff ff 0c 0f >>>>> .j........(..... 0x75b6b518 84 8c 59 00 00 e9 18 ff ff ff >>>>> 90 90 47 00 6c 00 ..Y.........G.l. 0x75b6b528 6f 00 62 00 >>>>> 61 00 6c 00 5c 00 54 00 65 00 72 00 o.b.a.l.\.T.e.r. >>>>> 0x75b6b538 6d 00 53 00 72 00 76 00 52 00 65 00 61 00 64 00 >>>>> m.S.r.v.R.e.a.d. 0x75b6b548 79 00 45 00 76 00 65 00 6e 00 >>>>> 74 00 00 00 90 90 y.E.v.e.n.t..... >>>>> >>>>> Nope, still no banner. But it is identical to what I find >>>>> at >>>> 0x1a34d8 in >>>>> 123.dmp. (As you'd expect.) Double-checked that I was >>>>> searching Unicode and ASCII - still no luck. >>>>> >>>>> Hmmm. >>>>> >>>>> Adam >>>>> >>>>> On 23 March 2015 at 04:02, Andrew Case &lt;atcuno(a)gmail.com >> <mailto:atcuno@gmail.com> >>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> >>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>> >>>>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>> >>> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> >> <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com>>>>> wrote: >>>>> >>>>> Can do you: >>>>> >>>>> vol.py ... volshell -p 123 >>>>> >>>>> Then in volshell do: >>>>> >>>>> db(0x75b6b4d8) >>>>> >>>>> And see if you get the banner printed at the beginning? >>>>> >>>>> Also, how are you searching 123.dmp? Did you search ascii >>>>> & >>>> unicode >>>>> (most common error) >>>>> >>>>> Thanks, Andrew (@attrc) >>>>> >>>>> On 03/20/2015 03:59 PM, Bridgey theGeek wrote: >>>>>> Hi all, >>>>>> >>>>>> I can't quite see what's wrong with my logic here, but I >>>>>> must be >>>>> missing >>>>>> something. Hoping someone can help me out. >>>>>> >>>>>> I'm looking for a private key in a memory sample >>>>>> (WinXPSP2x86). Specifically, to find out which process/es >>>>>> is/are accessing it. >>>>>> >>>>>> I can find the key by searching the raw memory dump >>>> (memory.dmp). >>>>>> As you might expect it's between: -----BEGIN RSA PRIVATE >>>>>> KEY----- -----END RSA PRIVATE KEY----- >>>>>> >>>>>> I generated an offset:string file by using strings. Then, >>>>>> using the strings plugin I get this output: $ python >>>>>> vol.py -f memory.dmp --profile=WinXPSP2x86 strings >>>> -s pk.txt >>>>>> Volatility Foundation Volatility Framework 2.4 188435934 >>>>>> [FREE MEMORY:-1] -----BEGIN RSA PRIVATE KEY----- >>>>>> 188435968 [FREE MEMORY:-1] -----END RSA PRIVATE KEY----- >>>>>> 317375704 [kernel:d2ab24d8] -----BEGIN RSA PRIVATE >>>>>> KEY----- 317376575 [kernel:d2ab283f] -----END RSA PRIVATE >>>>>> KEY----- 417203416 [123:75b6b4d8] -----BEGIN RSA PRIVATE >>>>>> KEY----- 417204287 [123:75b6b83f] -----END RSA PRIVATE >>>>>> KEY----- 419888606 [FREE MEMORY:-1] -----BEGIN RSA >>>>>> PRIVATE KEY----- 419888640 [FREE MEMORY:-1] -----END RSA >>>>>> PRIVATE KEY----- >>>>>> >>>>>> Lovely. So I now do a memdump of process 123: $ python >>>>>> vol.py -f memory.dmp --profile=WinXPSP2x86 memdump >>>> --pid=123 >>>>>> --dump-dir=123 Volatility Foundation Volatility >>>>>> Framework 2.4 >>>>>> >>>>> > > >> ********************************************************************* * ** _______________________________________________ Vol-users mailing list Vol-users(a)volatilityfoundation.org http://lists.volatilityfoundation.org/mailman/listinfo/vol-users