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: <mailto:atcuno@gmail.com <mailto:atcuno@gmail.com> >> 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. >>> >>>> >>> 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>>>>> 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) >>> >>>> >>> 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 >>> ************************************************************************ <mailto:Vol-users@volatilityfoundation.org> <mailto:Vol-users@volatilityfoundation.org>> > <mailto:Vol-users@volatilityfoundation.org> <mailto:Vol-users@volatilityfoundation.org>>> > <mailto:Vol-users@volatilityfoundation.org> <mailto:Vol-users@volatilityfoundation.org>> > <mailto:Vol-users@volatilityfoundation.org> > <mailto:Vol-users@volatilityfoundation.org>>>> <mailto:Vol-users@volatilityfoundation.org> > <mailto:Vol-users@volatilityfoundation.org>> -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iF4EAREKAAYFAlURazkACgkQXnt9v1O0LItfjAD/W7UeZMNiWVRMqeeJftNRaxG2 dpi/c755Qxc6X7PUKU8A/iREkToI9Ad0/GejtG32OpZMLjk0gjhj5XoMxAWuY69D =JNEv -----END PGP SIGNATURE-----