[Vol-users] Incorrect addresses in linux_proc_maps

Edwin Smulders edwin.smulders at gmail.com
Fri Mar 29 10:19:13 CDT 2013


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


More information about the Vol-users mailing list