Re: [Vol-users] Incorrect addresses in linux_proc_maps

I have ubuntu-12.04.2-server-i386.iso To give you a clue, 481d4000 = 0100 1000 0001 1101 0100 0000 0000 0000 b7e2b000 = 1011 0111 1110 0010 1011 0000 0000 0000 It's the inverse, so I guess some signing issue? But I don't know enough to say anything conclusive On 2 April 2013 13:36, Michael Hale Ligh &lt;michael.hale(a)gmail.com&gt; wrote: > Interesting.... > > I think I'll build my own VM to match your specs so I can do more > debugging. > You're using Ubuntu 12.04 x86 desktop? Do you think the following link > is > what most closely resembles your base build? > > http://releases.ubuntu.com/12.04.2/ubuntu-12.04.2-desktop-i386.iso > > Thanks! > Michael > > > On Tue, Apr 2, 2013 at 7:31 AM, Edwin Smulders > &lt;edwin.smulders(a)gmail.com&gt; > wrote: >> >> This is the actual /proc/pid/maps of the process I just tested >> >> http://paste.ubuntu.com/5670138/ >> >> On 2 April 2013 13:26, Edwin Smulders &lt;edwin.smulders(a)gmail.com&gt; >> wrote: >> > http://paste.ubuntu.com/5670124/ >> > >> > Change is improvement, I guess :) >> > >> > On 2 April 2013 13:25, Michael Hale Ligh &lt;michael.hale(a)gmail.com&gt; >> > wrote: >> >> Hey Edwin, >> >> >> >> OK, update to r3264 and I will keep my fingers crossed that this >> >> solves >> >> the >> >> issue. >> >> >> >> Thanks for the quick reply! >> >> Michael >> >> >> >> >> >> On Tue, Apr 2, 2013 at 7:17 AM, Edwin Smulders >> >> &lt;edwin.smulders(a)gmail.com&gt; >> >> wrote: >> >>> >> >>> http://paste.ubuntu.com/5670109/ >> >>> >> >>> Cheers, >> >>> Edwin >> >>> >> >>> On 2 April 2013 13:12, Michael Hale Ligh &lt;michael.hale(a)gmail.com&gt; >> >>> wrote: >> >>> > Hey Edwin, >> >>> > >> >>> > Hmm, yes, if you don't mind...there is one more thing. Could you >> >>> > type >> >>> > "make >> >>> > clean" in the directory where vol.py exists and then re-run the >> >>> > plugin? >> >>> > This >> >>> > will make sure all possibly stale .pyc (compiled python objects) >> >>> > are >> >>> > removed. We basically hard-coded the vm start and end fields to >> >>> > be >> >>> > unsigned, >> >>> > so its really strange if they're still showing up negative. >> >>> > Also, >> >>> > could >> >>> > you >> >>> > paste just the first few lines of the linux_proc_maps output, >> >>> > something >> >>> > else >> >>> > may give us a clue if we see it. >> >>> > >> >>> > Thanks again, >> >>> > Michael >> >>> > >> >>> > >> >>> > On Tue, Apr 2, 2013 at 3:38 AM, Edwin Smulders >> >>> > &lt;edwin.smulders(a)gmail.com&gt; >> >>> > wrote: >> >>> >> >> >>> >> Finally, it's tuesday morning, I can test your solution. >> >>> >> >> >>> >> Sadly, it's still giving me the same output (revision 3263). >> >>> >> >> >>> >> Is there anything else I can do to help you find a solution? >> >>> >> >> >>> >> Cheers, >> >>> >> Edwin >> >>> >> >> >>> >> On 2 April 2013 04:37, Michael Hale Ligh >> >>> >> &lt;michael.hale(a)gmail.com&gt; >> >>> >> wrote: >> >>> >> > Hey Edwin, >> >>> >> > >> >>> >> > Hope you had a nice weekend! Just wanted to check and see if >> >>> >> > you >> >>> >> > had >> >>> >> > a >> >>> >> > chance to determine if the linux_proc_maps plugin is printing >> >>> >> > output >> >>> >> > in >> >>> >> > a >> >>> >> > more accurate way now? >> >>> >> > >> >>> >> > Thanks! >> >>> >> > Michael >> >>> >> > >> >>> >> > >> >>> >> > On Fri, Mar 29, 2013 at 8:13 PM, Michael Hale Ligh >> >>> >> > &lt;michael.hale(a)gmail.com&gt; >> >>> >> > wrote: >> >>> >> >> >> >>> >> >> Hi Edwin, >> >>> >> >> >> >>> >> >> Could you please svn update to revision 3220 or later and >> >>> >> >> re-test >> >>> >> >> the >> >>> >> >> linux_proc_maps plugin? >> >>> >> >> >> >>> >> >> Thanks, >> >>> >> >> Michael >> >>> >> >> >> >>> >> >> >> >>> >> >> On Fri, Mar 29, 2013 at 11:19 AM, Edwin Smulders >> >>> >> >> &lt;edwin.smulders(a)gmail.com&gt; wrote: >> >>> >> >>> >> >>> >> >>> Correct URL: http://packages.ubuntu.com/precise/dwarfdump >> >>> >> >>> >> >>> >> >>> On 29 March 2013 16:18, Edwin Smulders >> >>> >> >>> &lt;edwin.smulders(a)gmail.com&gt; >> >>> >> >>> wrote: >> >>> >> >>> > On 29 March 2013 15:25, Michael Hale Ligh >> >>> >> >>> > &lt;michael.hale(a)gmail.com&gt; >> >>> >> >>> > wrote: >> >>> >> >>> >> While we look into that, could you >> >>> >> >>> >> tell me what version of dwarfdump you have installed? >> >>> >> >>> > >> >>> >> >>> > I would love to tell you, but I had to go home early and >> >>> >> >>> > due >> >>> >> >>> > to >> >>> >> >>> > easter >> >>> >> >>> > I can tell you on tuesday morning what the exact version >> >>> >> >>> > is. >> >>> >> >>> > However, it was a fresh install of ubuntu 12.04 and as >> >>> >> >>> > far as >> >>> >> >>> > I >> >>> >> >>> > can >> >>> >> >>> > tell there have been no updates to the package since >> >>> >> >>> > december, so >> >>> >> >>> > it >> >>> >> >>> > must be this version: >> >>> >> >>> > http://packages.ubuntu.com/precise/libdwarf-dev >> >>> >> >>> > >> >>> >> >>> >> On Fri, Mar 29, 2013 at 6:11 AM, Edwin Smulders >> >>> >> >>> >> &lt;edwin.smulders(a)gmail.com&gt; >> >>> >> >>> >> wrote: >> >>> >> >>> >>> >> >>> >> >>> >>> (Sending this a second time, first time i forgot to >> >>> >> >>> >>> include >> >>> >> >>> >>> the >> >>> >> >>> >>> mailing-list) >> >>> >> >>> >>> Here's the struct: >> >>> >> >>> >>> http://paste.ubuntu.com/5657610/ >> >>> >> >>> >>> I did not realise the first time that I could simply dt >> >>> >> >>> >>> it >> >>> >> >>> >>> like >> >>> >> >>> >>> that. >> >>> >> >>> >>> >> >>> >> >>> >>> I've attached the profile, if it's not too big. >> >>> >> >>> >>> >> >>> >> >>> >>> Cheers, >> >>> >> >>> >>> Edwin >> >>> >> >>> >>> >> >>> >> >>> >>> On 28 March 2013 18:49, Michael Hale Ligh >> >>> >> >>> >>> &lt;michael.hale(a)gmail.com&gt; >> >>> >> >>> >>> wrote: >> >>> >> >>> >>> > Hey Edwin, >> >>> >> >>> >>> > >> >>> >> >>> >>> > On second thought, if you could send your profile >> >>> >> >>> >>> > (LinuxUbuntu-12_04-3_5_0-25x86.zip), that would be >> >>> >> >>> >>> > even >> >>> >> >>> >>> > better. >> >>> >> >>> >>> > >> >>> >> >>> >>> > Thanks! >> >>> >> >>> >>> > Michael >> >>> >> >>> >>> > >> >>> >> >>> >>> > >> >>> >> >>> >>> > On Thu, Mar 28, 2013 at 1:04 PM, Michael Hale Ligh >> >>> >> >>> >>> > &lt;michael.hale(a)gmail.com&gt; >> >>> >> >>> >>> > wrote: >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> Hey Edwin, >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> Sorry for the delay and thanks for the additional >> >>> >> >>> >>> >> output. >> >>> >> >>> >>> >> Could >> >>> >> >>> >>> >> you run >> >>> >> >>> >>> >> one more thing, please? Instead of doing >> >>> >> >>> >>> >> dt('mm_struct', >> >>> >> >>> >>> >> address) >> >>> >> >>> >>> >> could >> >>> >> >>> >>> >> you >> >>> >> >>> >>> >> just do dt('mm_struct'). That will show the actual >> >>> >> >>> >>> >> types >> >>> >> >>> >>> >> rather >> >>> >> >>> >>> >> than >> >>> >> >>> >>> >> the >> >>> >> >>> >>> >> values of a specific structure. For example: >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> >>> dt('mm_struct') >> >>> >> >>> >>> >> 'mm_struct' (436 bytes) >> >>> >> >>> >>> >> 0x0 : mmap ['pointer', >> >>> >> >>> >>> >> ['vm_area_struct']] >> >>> >> >>> >>> >> 0x4 : mm_rb ['rb_root'] >> >>> >> >>> >>> >> 0x8 : mmap_cache ['pointer', >> >>> >> >>> >>> >> ['vm_area_struct']] >> >>> >> >>> >>> >> 0xc : get_unmapped_area ['pointer', >> >>> >> >>> >>> >> ['void']] >> >>> >> >>> >>> >> 0x10 : get_unmapped_exec_area ['pointer', >> >>> >> >>> >>> >> ['void']] >> >>> >> >>> >>> >> 0x14 : unmap_area ['pointer', >> >>> >> >>> >>> >> ['void']] >> >>> >> >>> >>> >> 0x18 : mmap_base ['unsigned >> >>> >> >>> >>> >> long'] >> >>> >> >>> >>> >> 0x1c : task_size ['unsigned >> >>> >> >>> >>> >> long'] >> >>> >> >>> >>> >> ..... >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> Can you paste the output of that command? >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> Thanks for your patience, >> >>> >> >>> >>> >> Michael >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> On Thu, Mar 21, 2013 at 10:12 AM, Edwin Smulders >> >>> >> >>> >>> >> &lt;edwin.smulders(a)gmail.com&gt; wrote: >> >>> >> >>> >>> >>> >> >>> >> >>> >>> >>> Yes, also it seems that I was wrong about >> >>> >> >>> >>> >>> start_brk/brk, so >> >>> >> >>> >>> >>> i >> >>> >> >>> >>> >>> guess >> >>> >> >>> >>> >>> they just overflowed. >> >>> >> >>> >>> >>> http://paste.ubuntu.com/5634126/ >> >>> >> >>> >>> >>> >> >>> >> >>> >>> >>> On 21 March 2013 14:44, Michael Ligh >> >>> >> >>> >>> >>> &lt;michael.hale(a)gmail.com&gt; >> >>> >> >>> >>> >>> wrote: >> >>> >> >>> >>> >>> > Hey Edwin, >> >>> >> >>> >>> >>> > >> >>> >> >>> >>> >>> > Can you use linux_volshell and dt() the task.mm >> >>> >> >>> >>> >>> > struct? >> >>> >> >>> >>> >>> > Do >> >>> >> >>> >>> >>> > start_stack >> >>> >> >>> >>> >>> > and arg_start show up as unsigned? >> >>> >> >>> >>> >>> > >> >>> >> >>> >>> >>> > MHL >> >>> >> >>> >>> >>> > >> >>> >> >>> >>> >>> > Sent from my iPhone >> >>> >> >>> >>> >>> > >> >>> >> >>> >>> >>> > On Mar 21, 2013, at 7:29 AM, Edwin Smulders >> >>> >> >>> >>> >>> > &lt;edwin.smulders(a)gmail.com&gt; >> >>> >> >>> >>> >>> > wrote: >> >>> >> >>> >>> >>> > >> >>> >> >>> >>> >>> >> I'd like to expand a bit more on this issue. I >> >>> >> >>> >>> >>> >> don't >> >>> >> >>> >>> >>> >> think >> >>> >> >>> >>> >>> >> it's >> >>> >> >>> >>> >>> >> just a >> >>> >> >>> >>> >>> >> formatting issue, now that I'm actually using >> >>> >> >>> >>> >>> >> this >> >>> >> >>> >>> >>> >> to >> >>> >> >>> >>> >>> >> develop >> >>> >> >>> >>> >>> >> my >> >>> >> >>> >>> >>> >> own >> >>> >> >>> >>> >>> >> plugin I noticed that the values I get from the >> >>> >> >>> >>> >>> >> task.mm.start_stack, >> >>> >> >>> >>> >>> >> task.mm.arg_start and several other values are >> >>> >> >>> >>> >>> >> actually >> >>> >> >>> >>> >>> >> negative >> >>> >> >>> >>> >>> >> numbers. task.mm.start_brk/task.mm.brk seem to >> >>> >> >>> >>> >>> >> be >> >>> >> >>> >>> >>> >> ok, >> >>> >> >>> >>> >>> >> not >> >>> >> >>> >>> >>> >> sure >> >>> >> >>> >>> >>> >> why. >> >>> >> >>> >>> >>> >> >> >>> >> >>> >>> >>> >> On 4 March 2013 10:02, Edwin Smulders >> >>> >> >>> >>> >>> >> &lt;edwin.smulders(a)gmail.com&gt; >> >>> >> >>> >>> >>> >> wrote: >> >>> >> >>> >>> >>> >>> Here's /proc/1264/maps >> >>> >> >>> >>> >>> >>> >> >>> >> >>> >>> >>> >>> http://paste.ubuntu.com/5584610/ >> >>> >> >>> >>> >>> >>> >> >>> >> >>> >>> >>> >>> On 1 March 2013 18:01, Edwin Smulders >> >>> >> >>> >>> >>> >>> &lt;edwin.smulders(a)gmail.com&gt; >> >>> >> >>> >>> >>> >>> wrote: >> >>> >> >>> >>> >>> >>>> Thanks for the quick response. >> >>> >> >>> >>> >>> >>>> Sadly, I can't access my VMs at home, so I'll >> >>> >> >>> >>> >>> >>>> send >> >>> >> >>> >>> >>> >>>> the >> >>> >> >>> >>> >>> >>>> /proc/<pid>/maps first thing in the morning on >> >>> >> >>> >>> >>> >>>> monday. >> >>> >> >>> >>> >>> >>>> >> >>> >> >>> >>> >>> >>>> Cheers, >> >>> >> >>> >>> >>> >>>> Edwin >> >>> >> >>> >>> >>> >>>> >> >>> >> >>> >>> >>> >>>> On 1 March 2013 17:29, Michael Hale Ligh >> >>> >> >>> >>> >>> >>>> &lt;michael.hale(a)gmail.com&gt; >> >>> >> >>> >>> >>> >>>> wrote: >> >>> >> >>> >>> >>> >>>>> Ah, this has to do with the fact that a long >> >>> >> >>> >>> >>> >>>>> and >> >>> >> >>> >>> >>> >>>>> unsigned >> >>> >> >>> >>> >>> >>>>> long >> >>> >> >>> >>> >>> >>>>> on >> >>> >> >>> >>> >>> >>>>> x86 Linux >> >>> >> >>> >>> >>> >>>>> is actually 8 bytes (instead of 4 like on >> >>> >> >>> >>> >>> >>>>> Windows). >> >>> >> >>> >>> >>> >>>>> >> >>> >> >>> >>> >>> >>>>> We'll take a look at changing the formatting >> >>> >> >>> >>> >>> >>>>> specification >> >>> >> >>> >>> >>> >>>>> to >> >>> >> >>> >>> >>> >>>>> account for >> >>> >> >>> >>> >>> >>>>> this difference in sizes, and if it can't be >> >>> >> >>> >>> >>> >>>>> done >> >>> >> >>> >>> >>> >>>>> easily >> >>> >> >>> >>> >>> >>>>> before >> >>> >> >>> >>> >>> >>>>> the >> >>> >> >>> >>> >>> >>>>> 2.3 >> >>> >> >>> >>> >>> >>>>> release, then we'll revert the patch in r3090 >> >>> >> >>> >>> >>> >>>>> to >> >>> >> >>> >>> >>> >>>>> re-incorporate >> >>> >> >>> >>> >>> >>>>> mask_number. >> >>> >> >>> >>> >>> >>>>> >> >>> >> >>> >>> >>> >>>>> Please still send the output of >> >>> >> >>> >>> >>> >>>>> /proc/<pid>/maps >> >>> >> >>> >>> >>> >>>>> just >> >>> >> >>> >>> >>> >>>>> so >> >>> >> >>> >>> >>> >>>>> we >> >>> >> >>> >>> >>> >>>>> know >> >>> >> >>> >>> >>> >>>>> how it >> >>> >> >>> >>> >>> >>>>> looks for the future. >> >>> >> >>> >>> >>> >>>>> MHL >> >>> >> >>> >>> >>> >>>>> >> >>> >> >>> >>> >>> >>>>> >> >>> >> >>> >>> >>> >>>>> On Fri, Mar 1, 2013 at 10:53 AM, Michael Hale >> >>> >> >>> >>> >>> >>>>> Ligh >> >>> >> >>> >>> >>> >>>>> &lt;michael.hale(a)gmail.com&gt; >> >>> >> >>> >>> >>> >>>>> wrote: >> >>> >> >>> >>> >>> >>>>>> >> >>> >> >>> >>> >>> >>>>>> Thanks for reporting. We just recently >> >>> >> >>> >>> >>> >>>>>> removed >> >>> >> >>> >>> >>> >>>>>> the >> >>> >> >>> >>> >>> >>>>>> mask_number >> >>> >> >>> >>> >>> >>>>>> function >> >>> >> >>> >>> >>> >>>>>> >> >>> >> >>> >>> >>> >>>>>> >> >>> >> >>> >>> >>> >>>>>> >> >>> >> >>> >>> >>> >>>>>> >> >>> >> >>> >>> >>> >>>>>> (http://code.google.com/p/volatility/source/detail?r=3090) >> >>> >> >>> >>> >>> >>>>>> because >> >>> >> >>> >>> >>> >>>>>> vm_start >> >>> >> >>> >>> >>> >>>>>> and vm_end are already unsigned (so you >> >>> >> >>> >>> >>> >>>>>> shouldn't >> >>> >> >>> >>> >>> >>>>>> see >> >>> >> >>> >>> >>> >>>>>> negative >> >>> >> >>> >>> >>> >>>>>> numbers in >> >>> >> >>> >>> >>> >>>>>> output). >> >>> >> >>> >>> >>> >>>>>> >> >>> >> >>> >>> >>> >>>>>> I'm guessing this may be a problem with our >> >>> >> >>> >>> >>> >>>>>> output >> >>> >> >>> >>> >>> >>>>>> formatting, >> >>> >> >>> >>> >>> >>>>>> but >> >>> >> >>> >>> >>> >>>>>> we'll >> >>> >> >>> >>> >>> >>>>>> look into it (the output of /proc/<pid>/maps >> >>> >> >>> >>> >>> >>>>>> like >> >>> >> >>> >>> >>> >>>>>> Andrew >> >>> >> >>> >>> >>> >>>>>> asked >> >>> >> >>> >>> >>> >>>>>> for >> >>> >> >>> >>> >>> >>>>>> would be >> >>> >> >>> >>> >>> >>>>>> useful). >> >>> >> >>> >>> >>> >>>>>> >> >>> >> >>> >>> >>> >>>>>> >> >>> >> >>> >>> >>> >>>>>> On Fri, Mar 1, 2013 at 10:47 AM, Andrew Case >> >>> >> >>> >>> >>> >>>>>> &lt;atcuno(a)gmail.com&gt; >> >>> >> >>> >>> >>> >>>>>> wrote: >> >>> >> >>> >>> >>> >>>>>>> >> >>> >> >>> >>> >>> >>>>>>> Can you send the output of /proc/<pid>/maps >> >>> >> >>> >>> >>> >>>>>>> that >> >>> >> >>> >>> >>> >>>>>>> corresponds >> >>> >> >>> >>> >>> >>>>>>> to >> >>> >> >>> >>> >>> >>>>>>> one of >> >>> >> >>> >>> >>> >>>>>>> the processes with the broken plugin >> >>> >> >>> >>> >>> >>>>>>> output? >> >>> >> >>> >>> >>> >>>>>>> >> >>> >> >>> >>> >>> >>>>>>> On Fri, Mar 1, 2013 at 6:52 AM, Edwin >> >>> >> >>> >>> >>> >>>>>>> Smulders >> >>> >> >>> >>> >>> >>>>>>> &lt;edwin.smulders(a)gmail.com&gt; >> >>> >> >>> >>> >>> >>>>>>> wrote: >> >>> >> >>> >>> >>> >>>>>>>> Hi all, >> >>> >> >>> >>> >>> >>>>>>>> >> >>> >> >>> >>> >>> >>>>>>>> I've just created a profile for my Ubuntu >> >>> >> >>> >>> >>> >>>>>>>> 12.04 >> >>> >> >>> >>> >>> >>>>>>>> (3.5.0-25) >> >>> >> >>> >>> >>> >>>>>>>> and >> >>> >> >>> >>> >>> >>>>>>>> I've >> >>> >> >>> >>> >>> >>>>>>>> dumped the memory using virtualbox >> >>> >> >>> >>> >>> >>>>>>>> guestcoredump. >> >>> >> >>> >>> >>> >>>>>>>> Using the linux_proc_maps plugin I get the >> >>> >> >>> >>> >>> >>>>>>>> following >> >>> >> >>> >>> >>> >>>>>>>> output: >> >>> >> >>> >>> >>> >>>>>>>> >> >>> >> >>> >>> >>> >>>>>>>> http://paste.ubuntu.com/5576450/ >> >>> >> >>> >>> >>> >>>>>>>> >> >>> >> >>> >>> >>> >>>>>>>> I was expecting similar output to "cat >> >>> >> >>> >>> >>> >>>>>>>> /proc/<pid>/maps". As >> >>> >> >>> >>> >>> >>>>>>>> you >> >>> >> >>> >>> >>> >>>>>>>> can >> >>> >> >>> >>> >>> >>>>>>>> see, these "-0x4...000" addresses are >> >>> >> >>> >>> >>> >>>>>>>> obviously >> >>> >> >>> >>> >>> >>>>>>>> wrong. >> >>> >> >>> >>> >>> >>>>>>>> Is >> >>> >> >>> >>> >>> >>>>>>>> this I >> >>> >> >>> >>> >>> >>>>>>>> am >> >>> >> >>> >>> >>> >>>>>>>> doing wrong myself, or is this a bug? It >> >>> >> >>> >>> >>> >>>>>>>> happens >> >>> >> >>> >>> >>> >>>>>>>> for >> >>> >> >>> >>> >>> >>>>>>>> other >> >>> >> >>> >>> >>> >>>>>>>> processes >> >>> >> >>> >>> >>> >>>>>>>> as well. >> >>> >> >>> >>> >>> >>>>>>>> >> >>> >> >>> >>> >>> >>>>>>>> If this is a bug I'll make a new issue in >> >>> >> >>> >>> >>> >>>>>>>> the >> >>> >> >>> >>> >>> >>>>>>>> tracker >> >>> >> >>> >>> >>> >>>>>>>> with >> >>> >> >>> >>> >>> >>>>>>>> the >> >>> >> >>> >>> >>> >>>>>>>> steps >> >>> >> >>> >>> >>> >>>>>>>> I've followed to produce this. >> >>> >> >>> >>> >>> >>>>>>>> >> >>> >> >>> >>> >>> >>>>>>>> Cheers, >> >>> >> >>> >>> >>> >>>>>>>> Edwin >> >>> >> >>> >>> >>> >>>>>>>> >> >>> >> >>> >>> >>> >>>>>>>> >> >>> >> >>> >>> >>> >>>>>>>> _______________________________________________ >> >>> >> >>> >>> >>> >>>>>>>> Vol-users mailing list >> >>> >> >>> >>> >>> >>>>>>>> Vol-users(a)volatilityfoundation.org >> >>> >> >>> >>> >>> >>>>>>>> >> >>> >> >>> >>> >>> >>>>>>>> >> >>> >> >>> >>> >>> >>>>>>>> >> >>> >> >>> >>> >>> >>>>>>>> >> >>> >> >>> >>> >>> >>>>>>>> >> >>> >> >>> >>> >>> >>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >> >>> >> >>> >>> >>> >>>>>>> >> >>> >> >>> >>> >>> >>>>>>> _______________________________________________ >> >>> >> >>> >>> >>> >>>>>>> Vol-users mailing list >> >>> >> >>> >>> >>> >>>>>>> Vol-users(a)volatilityfoundation.org >> >>> >> >>> >>> >>> >>>>>>> >> >>> >> >>> >>> >>> >>>>>>> >> >>> >> >>> >>> >>> >>>>>>> >> >>> >> >>> >>> >>> >>>>>>> >> >>> >> >>> >>> >>> >>>>>>> >> >>> >> >>> >>> >>> >>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users >> >>> >> >>> >>> >>> >>>>> >> >>> >> >>> >>> >> >> >>> >> >>> >>> >> >> >>> >> >>> >>> > >> >>> >> >>> >> >> >>> >> >>> >> >> >>> >> >> >> >>> >> >> >> >>> >> > >> >>> > >> >>> > >> >> >> >> > >