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

Andrew Case atcuno at gmail.com
Fri May 15 10:22:05 CDT 2015


Hey Greg,

Just add a "0x" in front of your number so python know it is a hex
value. Otherwise, it will try to treat it as a variable name.

Let us know if that fixes your issue.

Thanks,
Andrew (@attrc)

On 05/15/2015 10:05 AM, Gregory Pendergast wrote:
> Thanks Michael. I did try that, and received an error. That's why I
> thought I must be doing/forgetting something stupid. Now that I'm back
> at my analysis machine, here's the output:
>  
>>>> db(f9805ba44800)
> Traceback (most recent call last):
>   File "<console>", line 1, in <module>
> NameError: name 'f9805ba44800' is not defined
>>>> addrspace()
> <volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at 0xbef520c>
>>>>
> Note that I'm using Volatilty through the VM provided for the most
> recent class in Reston, in case the version is in question.
> The profile for this sample is WIn7SP1x64.
>  
> Thanks,
> Greg
>  
>  
> 
> On Fri, May 15, 2015 at 10:49 AM, Michael Ligh <michael.ligh at mnin.org
> <mailto:michael.ligh at mnin.org>> wrote:
> 
> 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
> <https://github.com/volatilityfoundation/volatility/wiki/Command%20Reference#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
> <mailto: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>
> <mailto: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>
>>>>>> <mailto: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>
> <mailto: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>>
>>>>>> [mailto: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>
>>>>>> <mailto: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>>
>>>>>>>>> [mailto: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>
>>>>>>> <mailto: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>>
>>>>>>>>>> <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,
>>>>>>>>>
>>>>>>>>>> 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>>>
>>>>>>> <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
> <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>>>>
>>>>>>>>>> <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:
>>>>>>>>>
>>>>>>>>>>>> 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>>>>>
>>>>>>>>>>>>> <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 <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>>>>>
>>>>>>>>>>>> <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
> <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>>>
>>>>>>>>>>>> <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-users
>>>>>>>
>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>
> _______________________________________________ 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>>
>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>>>
>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
> _______________________________________________ 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>>
>>>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>>
>>>>>
>>>>>>>>>
> _______________________________________________
>>>>>>> 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>>
>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>>>
>>>>>>>
> _______________________________________________ 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>>
>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>>
>>>>>>>
> _______________________________________________ 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>>
>>>>>> 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
> 


More information about the Vol-users mailing list