Re: [Vol-users] Incorrect addresses in linux_proc_maps

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