Re: [Vol-users] Incorrect addresses in linux_proc_maps

Hey Edwin, Hmm, yes, if you don't mind...there is one more thing. Could you type

clean" in the directory where vol.py exists and then re-run the plugin?

will make sure all possibly stale .pyc (compiled python objects) are removed. We basically hard-coded the vm start and end fields to be

so its really strange if they're still showing up negative. Also, could

paste just the first few lines of the linux_proc_maps output, something

may give us a clue if we see it. Thanks again, Michael On Tue, Apr 2, 2013 at 3:38 AM, Edwin Smulders <edwin.smulders(a)gmail.com 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 <michael.hale(a)gmail.com>

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

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

> >>> > tell there have been no updates to the package since december, so

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

> >>> >>> wrote: > >>> >>> > Hey Edwin, > >>> >>> > > >>> >>> > On second thought, if you could send your profile > >>> >>> > (LinuxUbuntu-12_04-3_5_0-25x86.zip), that would be even

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

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

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

> >>> >>> >>> guess > >>> >>> >>> they just overflowed. > >>> >>> >>> http://paste.ubuntu.com/5634126/ > >>> >>> >>> > >>> >>> >>> On 21 March 2013 14:44, Michael Ligh <

> >>> >>> >>> wrote: > >>> >>> >>> > Hey Edwin, > >>> >>> >>> > > >>> >>> >>> > Can you use linux_volshell and dt() the task.mm struct?

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

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

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

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

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

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

> >>> >>> >>> >>>>>>>> other > >>> >>> >>> >>>>>>>> processes > >>> >>> >>> >>>>>>>> as well. > >>> >>> >>> >>>>>>>> > >>> >>> >>> >>>>>>>> If this is a bug I'll make a new issue in the

> >>> >>> >>> >>>>>>>> with > >>> >>> >>> >>>>>>>> the > >>> >>> >>> >>>>>>>> steps > >>> >>> >>> >>>>>>>> I've followed to produce this. > >>> >>> >>> >>>>>>>> > >>> >>> >>> >>>>>>>> Cheers, > >>> >>> >>> >>>>>>>> Edwin > >>> >>> >>> >>>>>>>> _______________________________________________ > >>> >>> >>> >>>>>>>> Vol-users mailing list > >>> >>> >>> >>>>>>>> Vol-users(a)volatilityfoundation.org > >>> >>> >>> >>>>>>>> > >>> >>> >>> >>>>>>>> > >>> >>> >>> >>>>>>>>

> >>> >>> >>> >>>>>>> _______________________________________________ > >>> >>> >>> >>>>>>> Vol-users mailing list > >>> >>> >>> >>>>>>> Vol-users(a)volatilityfoundation.org > >>> >>> >>> >>>>>>> > >>> >>> >>> >>>>>>> > >>> >>> >>> >>>>>>>