[Vol-users] Incorrect addresses in linux_proc_maps

Michael Hale Ligh michael.hale at gmail.com
Fri Mar 29 19:13:38 CDT 2013


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
<edwin.smulders at gmail.com>wrote:

> Correct URL: http://packages.ubuntu.com/precise/dwarfdump
>
> On 29 March 2013 16:18, Edwin Smulders <edwin.smulders at gmail.com> wrote:
> > On 29 March 2013 15:25, Michael Hale Ligh <michael.hale at gmail.com>
> 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 at gmail.com>
> >> 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 <michael.hale at gmail.com>
> 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
> >>> > <michael.hale at gmail.com>
> >>> > 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
> >>> >> <edwin.smulders at gmail.com> 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 <michael.hale at gmail.com>
> 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
> >>> >>> > <edwin.smulders at gmail.com>
> >>> >>> > 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 <edwin.smulders at gmail.com
> >
> >>> >>> >> wrote:
> >>> >>> >>> Here's /proc/1264/maps
> >>> >>> >>>
> >>> >>> >>> http://paste.ubuntu.com/5584610/
> >>> >>> >>>
> >>> >>> >>> On 1 March 2013 18:01, Edwin Smulders <
> edwin.smulders at gmail.com>
> >>> >>> >>> 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 at gmail.com>
> >>> >>> >>>> 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
> >>> >>> >>>>> <michael.hale at gmail.com>
> >>> >>> >>>>> 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 at gmail.com>
> >>> >>> >>>>>> 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
> >>> >>> >>>>>>> <edwin.smulders at gmail.com>
> >>> >>> >>>>>>> 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 at volatilityfoundation.org
> >>> >>> >>>>>>>>
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> >>> >>> >>>>>>> _______________________________________________
> >>> >>> >>>>>>> Vol-users mailing list
> >>> >>> >>>>>>> Vol-users at volatilityfoundation.org
> >>> >>> >>>>>>>
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
> >>> >>> >>>>>
> >>> >>
> >>> >>
> >>> >
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.volatilityfoundation.org/pipermail/vol-users/attachments/20130329/50f6314f/attachment.html


More information about the Vol-users mailing list