Re: [Vol-users] Incorrect addresses in linux_proc_maps

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