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

Michael Ligh michael.ligh at mnin.org
Fri May 15 10:15:15 CDT 2015


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

My command:

db(0xf9805ba44800)

Your command:

db(f9805ba44800)

The missing 0x in front makes Python think f9805ba44800 is a variable
name rather than a number.

On 5/15/15 11: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%20Refe
re
>
> 
nce#volshell
> <https://github.com/volatilityfoundation/volatility/wiki/Command%20Ref
erence#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-use
r
>
>>>>>>>>>>>>>> 
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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org

iF4EAREKAAYFAlVWDYMACgkQXnt9v1O0LIvfXgD9FqED/dZF7HPqsQNfzLHQKunI
Tkg8T95vXlb8g5nSzz0A/16gxMP/ZHn22FFXhzq4bPdhHBXCZ27FTbVhxea66t5H
=L2wX
-----END PGP SIGNATURE-----


More information about the Vol-users mailing list