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:

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 >> >> >

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 >>>

>> dt('mm_struct')

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: and arg_start show up as unsigned? wrote: wrote: wrote: x86 Linux account for 2.3 mask_number. it michael.hale(a)gmail.com&gt; function vm_start numbers in we'll would be wrote: one of edwin.smulders(a)gmail.com&gt; I've can am processes steps

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:

While we look into that, could you tell me what version of dwarfdump you have installed?

On Fri, Mar 29, 2013 at 6:11 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: wrote: edwin.smulders(a)gmail.com&gt; wrote: run could ['vm_area_struct']] ['vm_area_struct']] wrote: why. edwin.smulders(a)gmail.com&gt; michael.hale(a)gmail.com&gt; long before re-incorporate know mask_number negative formatting, asked atcuno(a)gmail.com&gt; corresponds output: As http://lists.volatilityfoundation.org/mailman/listinfo/vol-users http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

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:

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:

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:

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: the edwin.smulders(a)gmail.com&gt; wrote: plugin? could something had output edwin.smulders(a)gmail.com&gt; to I december, so the like ['void']] ['void']] ['void']] start_brk/brk, so actually the monday. Windows). just the http://code.google.com/p/volatility/source/detail?r=3090) output guestcoredump. happens http://lists.volatilityfoundation.org/mailman/listinfo/vol-users http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

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: debugging. wrote: solves are you due is. as include it dt('mm_struct', types long'] long'] don't send and done to /proc/<pid>/maps http://code.google.com/p/volatility/source/detail?r=3090) Smulders the _______________________________________________ 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

Alright, system built, problem reproduced, and subsequently fixed. The problem was our initial attempt to overlay (i.e. hard-code) the vm_start and vm_end members to unsigned values failed because the overlay was put in the wrong place. https://code.google.com/p/volatility/source/detail?r=3265 Thanks, Michael On Tue, Apr 2, 2013 at 7:49 AM, Michael Hale Ligh &lt;michael.hale(a)gmail.com&gt; wrote:

Perfect! On Tue, Apr 2, 2013 at 10:50 AM, Edwin Smulders &lt;edwin.smulders(a)gmail.com&gt; wrote:

Hey Edwin, Sorry for the delay. A few notes for you: 1) I fixed the -p/--pid argument to linux_volshell (see r3392), so that should work better now. 2) Using dt('mm_struct') in linux_volshell should not give you an error. Make sure you're in linux_volshell and not just "volshell" which is for Windows. 3) The negative addresses are actually specific (as far as we know so far) to Ubuntu 12.04 with the 3.5.x kernel. The bug lies in the code that reads the output of dwarfparse and produces a vtype file for volatility. To "fix" it for linux_proc_maps we just used an overlay to hard-code the start and end members to unsigned (see [1]). However, as you've realized, that doesn't "fix" it for the structs/members used to calculate the stack address and for any other structs/members you may need to access in the future. So in the short term you can make similar manual overlays where needed (see the [1] patch location), and we'll spend some time fixing the real source of the bug in dwarfparser code, but it may not be until after 2.3 is released. Thanks and talk to you soon, Michael [1]. https://code.google.com/p/volatility/source/browse/trunk/volatility/plugins… On Mon, Apr 15, 2013 at 10:40 AM, Edwin Smulders &lt;edwin.smulders(a)gmail.com > Sorry to bother you again, but I'm afraid there are still some things > broken, related to this bug. > > With the patch, when using linux_proc_maps, the addresses are all > fine, but no stack is detected. It appears some values in mm_struct > are still broken. > Here's a paste, I don't think I'm supposed to get these negative > numbers in mm_struct? > > http://paste.ubuntu.com/5710494/ > > If i remember correct, linux_proc_maps uses start_stack (which is > somewhere in the middle of the stack area) to determine which area is > the stack. > > On a sidenote, if I start volshell with -p <pid>, is dt('mm_struct') > supposed to give me an error? Might be a bug too. > > Cheers, > Edwin > > On 2 April 2013 16:57, Michael Hale Ligh &lt;michael.hale(a)gmail.com&gt; wrote: > > Perfect! > > > > > > On Tue, Apr 2, 2013 at 10:50 AM, Edwin Smulders < > edwin.smulders(a)gmail.com&gt; >> >> > >> It works, thank you! > >> > >> On 2 April 2013 14:21, Michael Hale Ligh &lt;michael.hale(a)gmail.com&gt; > wrote: > >> > Alright, system built, problem reproduced, and subsequently fixed. > The > >> > problem was our initial attempt to overlay (i.e. hard-code) the > vm_start > >> > and > >> > vm_end members to unsigned values failed because the overlay was put > in > >> > the > >> > wrong place. > >> > > >> > https://code.google.com/p/volatility/source/detail?r=3265 > >> > > >> > Thanks, > >> > Michael > >> > > >> > > >> > On Tue, Apr 2, 2013 at 7:49 AM, Michael Hale Ligh > >> > &lt;michael.hale(a)gmail.com&gt; > >>> >> >> > >> >> OK, so I'll grab > >> >> http://releases.ubuntu.com/12.04.2/ubuntu-12.04.2-server-i386.isofor > >> >> my > >> >> test system. > >> >> > >> >> Hang tight....we'll figure it out. There is eventually an > explanation > >> >> for > >> >> all craziness! > >> >> > >> >> MHL > >> >> > >> >> > >> >> On Tue, Apr 2, 2013 at 7:45 AM, Edwin Smulders > >> >> &lt;edwin.smulders(a)gmail.com&gt; > >> >> wrote: > >> >>> > >> >>> 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; > >> >>>> >> >>> >> > >> >>> >> 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 > > > >> >>> >> wrote: > >> >>> >> > http://paste.ubuntu.com/5670124/ > >> >>> >> > > >> >>> >> > Change is improvement, I guess :) > >> >>> >> > > >> >>> >> > On 2 April 2013 13:25, Michael Hale Ligh < > michael.hale(a)gmail.com&gt; > >> >>> >>> >> >>> >> >> 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; > >> >>> >> >>>> >> >>> >> >>> >> > >> >>> >> >>> >> 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; > >> >>> >> >>> >>> >> >>> >> >>> >> >> > >> >>> >> >>> >> >> 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; > >> >>> >> >>> >> >>>> >> >>> >> >>> >> >>> >> 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; > >> >>> >> >>> >> >>> >>>> >> >>> >> >>> >> >>> >>> >> > >> >>> >> >>> >> >>> >>> >> 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; > >> >>> >> >>> >> >>> >>> >>>> >> >>> >> >>> >> >>> >>> >>> > > >> >>> >> >>> >> >>> >>> >>> >> 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 > >> >>> >> >>> >> >>> >>> >>> >>>>> > >> >>> >> >>> >> >>> >>> >> > >> >>> >> >>> >> >>> >>> >> > >> >>> >> >>> >> >>> >>> > > >> >>> >> >>> >> >>> >> > >> >>> >> >>> >> >>> >> > >> >>> >> >>> >> >> > >> >>> >> >>> >> >> > >> >>> >> >>> >> > > >> >>> >> >>> > > >> >>> >> >>> > > >> >>> >> >> > >> >>> >> >> > >> >>> > > >> >>> > > >> >> > >> >> > >> > > > > > >