[Vol-users] Sample error or real module? (and other questions)

Michael Ligh michael.ligh at mnin.org
Fri May 15 09:49:39 CDT 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

You would just type db(0xf9805ba44800) in volshell (or whatever other
address you want to see).

https://github.com/volatilityfoundation/volatility/wiki/Command%20Refere
nce#volshell

I would also search an electronic copy of the AMF book for "volshell"
- - there are lots of examples.


On 5/14/15 10:52 PM, Gregory Pendergast wrote:
> Thanks Michael. Regarding the latter part of inspecting the data 
> around the strings, that's where I really need the help. I know I
> can accomplish that with volshell, but I'm not proficient enough
> yet to know how to get at it.
> 
> If you could provide the necessary commands to get at the data
> around this hit [kernel:f9805ba44800] as an example, that would be
> most helpful.
> 
> I'm sure I was doing something n00bishly wrong, but I could never
> get to the point of displaying the data around that location. I'd
> be more specific about my attempts, but I'm not in front of my
> analysis machine right now and don't recall exactly what I tried.
> 
> thanks, greg
> 
>> On May 14, 2015, at 9:39 PM, Michael Ligh <michael.ligh at mnin.org>
>> wrote:
>> 
> I wouldn't think the module at 0x48706657040b0003 requires 
> investigation. Not only bc its not in the 0xfffff8 range, but you 
> might notice legitimate modules are typically loaded at page
> aligned base addresses (not XXX0003). Your result looks like a
> false positive and given the way modscan works (pool scanning) its
> probably a partially overwritten structure in free/deallocated
> memory. We *could* put a sanity check in the code to suppress
> entries that aren't loaded at page aligned addresses, but there are
> a few exceptions where you'll have modules loaded from non-page
> aligned addresses. For example, we just looked at a rootkit today
> in class that is loaded at 0x81b91b80 (on a 32-bit system). Jared's
> advice is also good - if you ever suspect something like this
> again, you can use volshell to display the data at the alleged base
> address and see what's there. If its not an MZ signature, then its
> probably not a currently loaded module (but keep in mind you can
> overwrite the MZ with 00 or anything else as a trick...but in that
> case you'll see real executable code not too far away).
> 
> I would suggest trying to figure out what downloaded the EXE in
> the first place, so that you can determine what it does after the
> download finishes (drop to disk and run, drop to disk and run then
> delete, load directly into memory without touching disk, etc). I
> would also inspect the data around the strings you found in kernel
> and free memory - is it verbatim with what you see in the pcap
> (i.e. just a copy of the packet) or has it been altered (i.e.
> unpacked, executed, expanded).
> 
>>>> On 5/14/15 4:31 PM, Gregory Pendergast wrote: Just as a
>>>> follow up to my last reply, the shimcache plugin reported 
>>>> that there was no shimcache data, and the timeliner plugin
>>>> didn't reveal anything apparently interesting except IE
>>>> history related to the download.
>>>> 
>>>> Thanks, Greg
>>>> 
>>>> 
>>>> On May 14, 2015, at 12:35 PM, Jared Greenhill
>>>> <jared703 at gmail.com <mailto:jared703 at gmail.com>> wrote:
>>>> 
>>>>> Hey Greg,
>>>>> 
>>>>> A couple thoughts/ideas:
>>>>> 
>>>>> What was the initial reason for investigation- the suspect
>>>>> EXE? Do you have a timeframe of the suspect activity?
>>>>> 
>>>>> What was the context around the suspect EXE download, just
>>>>> the PCAP or? If so, did the memory capture occur when there
>>>>> was still an active connection? Sometimes this can be a
>>>>> dealbreaker when the connection isn't there.
>>>>> 
>>>>> Does moddump work on the module with that base address? If
>>>>> so, what type of strings are you seeing?
>>>>> 
>>>>> As far as execution goes, does the shimcache plugin provide
>>>>> any results around the time of interest? Assuming you have
>>>>> a time of interest, you could also try the timeliner plugin
>>>>> to pull in other temporal artifacts to hone in around that
>>>>> suspect time.
>>>>> 
>>>>> hope this helps, Jared - @jared703
>>>>> 
>>>>> 
>>>>> On Tue, May 12, 2015 at 3:36 PM, Gregory Pendergast 
>>>>> <greg.pendergast at gmail.com
>>>>> <mailto:greg.pendergast at gmail.com>> wrote:
>>>>> 
>>>>> Greeting,
>>>>> 
>>>>> I'm examining a memory sample (captured locally with 
>>>>> winpmem_1.6.2) <yeah...i know...>
>>>>> 
>>>>> Modscan shows one apparently strange module that has no
>>>>> name and no file listed. The base address space also seems
>>>>> way out of whack for the rest of the sample.
>>>>> 
>>>>> So all i have are offset, base, and size:
>>>>> 0x000000023a80b540 0x48706657040b0003 0xf3a54f0
>>>>> 
>>>>> In particular, that base address seems way out of range
>>>>> compared to everything else in 0xfffff8.... space
>>>>> 
>>>>> How can I tell if this is an error of some kind in the
>>>>> captured sample versus a legitimate anomaly that bears
>>>>> investigation?
>>>>> 
>>>>> 
>>>>> Lastly, and pardon me if this is a n00b question, but how
>>>>> can I determine why specific strings appear in kernel
>>>>> memory (based on strings plugin output)? For context, I
>>>>> have a suspicious executable download, but there appears to
>>>>> be no evidence of the file in $MFT (I don't have access to
>>>>> UsnJrnl) and I'm trying to find out what happened to it and
>>>>> whether it ran. Strings from the executable (ontained from
>>>>> pcap) do appear in Free Memory and Kernel memory, but I'm
>>>>> not clear whether that's a symptom of the download or a
>>>>> sign of execution.
>>>>> 
>>>>> Thanks, greg
>>>>> 
>>>>> 
>>>>>>> On May 11, 2015, at 11:30 AM, Torres, Geoff (Cyber
>>>>>>> Security)
>>>>>> <geoff.torres at hp.com <mailto:geoff.torres at hp.com>>
>>>>>> wrote:
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>>> Don't be afraid to tell me I'm doing something
>>>>>>> stupid... :-)
>>>>>> 
>>>>>> I only said that because I didn't think I was...   :-P
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> -----Original Message----- From: 
>>>>>> vol-users-bounces at volatilityfoundation.org
>>>>> <mailto:vol-users-bounces at volatilityfoundation.org> 
>>>>> [mailto:vol-users-bounces at volatilityfoundation.org 
>>>>> <mailto:vol-users-bounces at volatilityfoundation.org>] On Behalf
>>>>> Of Michael Ligh
>>>>>> Sent: Saturday, May 09, 2015 9:00 AM To: 
>>>>>> vol-users at volatilityfoundation.org
>>>>> <mailto:vol-users at volatilityfoundation.org>
>>>>>> Subject: Re: [Vol-users] Output of strings not found in 
>>>>>> memdump
>>>>> output - QEMU/QEVM sample
>>>> 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
>>>>>>>> 
>>>>>>>> Don't be afraid to tell me I'm doing something
>>>>>>>> stupid... :-)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -----Original Message----- From: 
>>>>>>>> vol-users-bounces at volatilityfoundation.org
>>>>>> <mailto:vol-users-bounces at volatilityfoundation.org>
>>>>>>>> [mailto:vol-users-bounces at volatilityfoundation.org
>>>>>> <mailto:vol-users-bounces at volatilityfoundation.org>] On Behalf
>>>>>> Of Michael
>>>>>>>> Ligh Sent: Tuesday, March 24, 2015 6:49 AM To:
>>>>>>>> Bridgey theGeek Cc: vol-users at volatilityfoundation.org
>>>>>> <mailto:vol-users at 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 
>>>>>>>>> <michael.ligh at mnin.org
>>>>>> <mailto:michael.ligh at mnin.org>
>>>>>>>>> <mailto:michael.ligh at mnin.org 
>>>>>>>>> <mailto:michael.ligh at 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
>>>>>> <michael.ligh at mnin.org <mailto:michael.ligh at mnin.org>
>>>>>>>>>> <mailto:michael.ligh at mnin.org 
>>>>>>>>>> <mailto:michael.ligh at mnin.org>>
>>>>>> <mailto:michael.ligh at mnin.org
>>>>>> <mailto:michael.ligh at mnin.org>
>>>>>>>>>> <mailto:michael.ligh at mnin.org
>>>>>> <mailto:michael.ligh at 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 
>>>>>>>>>>> <atcuno at gmail.com
>>>>>> <mailto:atcuno at gmail.com>
>>>>>>>>>>> <mailto:atcuno at gmail.com
>>>>>>>>>>> <mailto:atcuno at gmail.com>>
>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at gmail.com>
>>>>>>>>>>> <mailto:atcuno at gmail.com
>>>>>>>>>>> <mailto:atcuno at gmail.com>>>
>>>>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at gmail.com>
>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at gmail.com>>
>>>>>>>>>>> <mailto:atcuno at gmail.com
>>>>>>>>>>> <mailto:atcuno at gmail.com>
>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at 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 
>>>>>>>>>>>> <atcuno at gmail.com
>>>>>> <mailto:atcuno at gmail.com>
>>>>>>>>> <mailto:atcuno at gmail.com
>>>>>>>>> <mailto:atcuno at gmail.com>>
>>>>>>>>>> <mailto:atcuno at gmail.com
>>>>>>>>>> <mailto:atcuno at gmail.com>
>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at gmail.com>>>
>>>>>>>>>>> <mailto:atcuno at gmail.com
>>>>>>>>>>> <mailto:atcuno at gmail.com>
>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at gmail.com>>
>>>>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at gmail.com>
>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at gmail.com>>>>
>>>>>>>>>>>> <mailto:atcuno at gmail.com
>>>>>>>>>>>> <mailto:atcuno at gmail.com>
>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at gmail.com>>
>>>>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at gmail.com>
>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at gmail.com>>>
>>>>>>>>>> <mailto:atcuno at gmail.com
>>>>>>>>>> <mailto:atcuno at gmail.com>
>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at gmail.com>>
>>>>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at gmail.com>
>>>>>> <mailto:atcuno at gmail.com <mailto:atcuno at 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
>>>>>>>> 
>>>>>>>> 
>>>>>> *****************************************************************
***
>
>>>>>> 
*
>>>> 
> *
>>>> **
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>>>>> Writing myapp.exe [   123] to 123.dmp
>>>>>>>>>>>>> 
>>>>>>>>>>>>> However, if I search 123.dmp neither the
>>>>>>>>>>>>> BEGIN or END
>>>>>>>>>>> strings are
>>>>>>>>>>>> present.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> So I thought I'd try and find it via the
>>>>>>>>>>>>> virtual address give,
>>>>>>>>>>>> 0x75b6b4d8:
>>>>>>>>>>>>> $ python vol.py -f memory.dmp 
>>>>>>>>>>>>> --profile=WinXPSP2x86 memmap
>>>>>>>>>>> --pid=123
>>>>>>>>>>>>> Virtual    Physical         Size
>>>>>>>>>>>>> DumpFileOffset ---------- ----------
>>>>>>>>>>>>> ---------- -------------- --SNIP--
>>>>>>>>>>>>> 0x75b6b000 0x18de0000     0x1000 0x1a3000
>>>>>>>>>>>>> --SNIP--
>>>>>>>>>>>>> 
>>>>>>>>>>>>> The text is indeed at 0x18de04d8 in
>>>>>>>>>>>>> memory.dmp, but not at
>>>>>>>>>>> 0x1a34d8 in
>>>>>>>>>>>>> 123.dmp. Again, it's no where to be found
>>>>>>>>>>>>> in 123.dmp.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Any suggestions..??
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Many thanks, Adam
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>
>>>>>>>>>>>>> 
Vol-users mailing list
>>>>>>>>>>>>> Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>
>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>>
>>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>
>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>>>
>>>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>
>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>>
>>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>
>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>>>>
>>>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>
>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>>
>>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>
>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>>>
>>>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>
>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>>
>>>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>
>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>>>>>
>>>>>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-user
s
>>>>>>
>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>> 
_______________________________________________
>>>>>>>>>>> Vol-users mailing list
>>>>>>>>>>> Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>
>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>>
>>>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>
>>>>>>>>> <mailto:Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>>>
>>>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>>
>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>>> 
_______________________________________________ Vol-users
>>>>>>>> mailing list Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>
>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>>
>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 
_______________________________________________ Vol-users
>>>>>>>> mailing list Vol-users at volatilityfoundation.org
>>>>>> <mailto:Vol-users at volatilityfoundation.org>
>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>
>>>>
>>>>>>>> 
_______________________________________________
>>>>>> Vol-users mailing list Vol-users at volatilityfoundation.org 
>>>>>> <mailto:Vol-users at volatilityfoundation.org> 
>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>>
>>>>>> 
_______________________________________________ Vol-users
>>>>>> mailing list Vol-users at volatilityfoundation.org 
>>>>>> <mailto:Vol-users at volatilityfoundation.org> 
>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>
>>>>>> 
_______________________________________________ Vol-users mailing
>>>>> list Vol-users at volatilityfoundation.org 
>>>>> <mailto:Vol-users at volatilityfoundation.org> 
>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>
>>>>
>>>>
>>>>> 
_______________________________________________ Vol-users mailing
>>>> list Vol-users at volatilityfoundation.org 
>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> _______________________________________________ Vol-users mailing
> list Vol-users at volatilityfoundation.org 
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iF4EAREKAAYFAlVWB4MACgkQXnt9v1O0LIsI8AD+N1jJH/FEwPQ5p8ThY6y6XvF8
oSV54CPklfdkYGefXxEBAI8zB9osPwkRpru0SJfH/WgXoXDv9zrvctNkC2QJZSam
=1igm
-----END PGP SIGNATURE-----


More information about the Vol-users mailing list