Hey Edwin,Sorry for the delay. A few notes for you:1) I fixed the -p/--pid argument to linux_volshell (see r3392), so that should work better now.2) Using dt('mm_struct') in linux_volshell should not give you an error. Make sure you're in linux_volshell and not just "volshell" which is for Windows.3) The negative addresses are actually specific (as far as we know so far) to Ubuntu 12.04 with the 3.5.x kernel. The bug lies in the code that reads the output of dwarfparse and produces a vtype file for volatility. To "fix" it for linux_proc_maps we just used an overlay to hard-code the start and end members to unsigned (see [1]). However, as you've realized, that doesn't "fix" it for the structs/members used to calculate the stack address and for any other structs/members you may need to access in the future. So in the short term you can make similar manual overlays where needed (see the [1] patch location), and we'll spend some time fixing the real source of the bug in dwarfparser code, but it may not be until after 2.3 is released.Thanks and talk to you soon,MichaelOn Mon, Apr 15, 2013 at 10:40 AM, Edwin Smulders <edwin.smulders@gmail.com> wrote:
Sorry to bother you again, but I'm afraid there are still some things
broken, related to this bug.
With the patch, when using linux_proc_maps, the addresses are all
fine, but no stack is detected. It appears some values in mm_struct
are still broken.
Here's a paste, I don't think I'm supposed to get these negative
numbers in mm_struct?
http://paste.ubuntu.com/5710494/
If i remember correct, linux_proc_maps uses start_stack (which is
somewhere in the middle of the stack area) to determine which area is
the stack.
On a sidenote, if I start volshell with -p <pid>, is dt('mm_struct')
supposed to give me an error? Might be a bug too.
Cheers,
Edwin
On 2 April 2013 16:57, Michael Hale Ligh <michael.hale@gmail.com> wrote:
> Perfect!
>
>
> On Tue, Apr 2, 2013 at 10:50 AM, Edwin Smulders <edwin.smulders@gmail.com>
> wrote:
>>
>> It works, thank you!
>>
>> On 2 April 2013 14:21, Michael Hale Ligh <michael.hale@gmail.com> wrote:
>> > Alright, system built, problem reproduced, and subsequently fixed. The
>> > problem was our initial attempt to overlay (i.e. hard-code) the vm_start
>> > and
>> > vm_end members to unsigned values failed because the overlay was put in
>> > the
>> > wrong place.
>> >
>> > https://code.google.com/p/volatility/source/detail?r=3265
>> >
>> > Thanks,
>> > Michael
>> >
>> >
>> > On Tue, Apr 2, 2013 at 7:49 AM, Michael Hale Ligh
>> > <michael.hale@gmail.com>
>> > wrote:
>> >>
>> >> OK, so I'll grab
>> >> http://releases.ubuntu.com/12.04.2/ubuntu-12.04.2-server-i386.iso for
>> >> my
>> >> test system.
>> >>
>> >> Hang tight....we'll figure it out. There is eventually an explanation
>> >> for
>> >> all craziness!
>> >>
>> >> MHL
>> >>
>> >>
>> >> On Tue, Apr 2, 2013 at 7:45 AM, Edwin Smulders
>> >> <edwin.smulders@gmail.com>
>> >> wrote:
>> >>>
>> >>> I have ubuntu-12.04.2-server-i386.iso
>> >>>
>> >>> To give you a clue,
>> >>> 481d4000 =
>> >>> 0100 1000 0001 1101 0100 0000 0000 0000
>> >>>
>> >>> b7e2b000 =
>> >>> 1011 0111 1110 0010 1011 0000 0000 0000
>> >>>
>> >>> It's the inverse, so I guess some signing issue? But I don't know
>> >>> enough to say anything conclusive
>> >>>
>> >>> On 2 April 2013 13:36, Michael Hale Ligh <michael.hale@gmail.com>
>> >>> wrote:
>> >>> > Interesting....
>> >>> >
>> >>> > I think I'll build my own VM to match your specs so I can do more
>> >>> > debugging.
>> >>> > You're using Ubuntu 12.04 x86 desktop? Do you think the following
>> >>> > link
>> >>> > is
>> >>> > what most closely resembles your base build?
>> >>> >
>> >>> > http://releases.ubuntu.com/12.04.2/ubuntu-12.04.2-desktop-i386.iso
>> >>> >
>> >>> > Thanks!
>> >>> > Michael
>> >>> >
>> >>> >
>> >>> > On Tue, Apr 2, 2013 at 7:31 AM, Edwin Smulders
>> >>> > <edwin.smulders@gmail.com>
>> >>> > wrote:
>> >>> >>
>> >>> >> 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 <edwin.smulders@gmail.com>
>> >>> >> wrote:
>> >>> >> > http://paste.ubuntu.com/5670124/
>> >>> >> >
>> >>> >> > Change is improvement, I guess :)
>> >>> >> >
>> >>> >> > On 2 April 2013 13:25, Michael Hale Ligh <michael.hale@gmail.com>
>> >>> >> > 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
>> >>> >> >> <edwin.smulders@gmail.com>
>> >>> >> >> wrote:
>> >>> >> >>>
>> >>> >> >>> http://paste.ubuntu.com/5670109/
>> >>> >> >>>
>> >>> >> >>> Cheers,
>> >>> >> >>> Edwin
>> >>> >> >>>
>> >>> >> >>> On 2 April 2013 13:12, Michael Hale Ligh
>> >>> >> >>> <michael.hale@gmail.com>
>> >>> >> >>> 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
>> >>> >> >>> > <edwin.smulders@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@gmail.com>
>> >>> >> >>> >> 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
>> >>> >> >>> >> > <michael.hale@gmail.com>
>> >>> >> >>> >> > 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
>> >>> >> >>> >> >> <edwin.smulders@gmail.com> wrote:
>> >>> >> >>> >> >>>
>> >>> >> >>> >> >>> Correct URL:
>> >>> >> >>> >> >>> http://packages.ubuntu.com/precise/dwarfdump
>> >>> >> >>> >> >>>
>> >>> >> >>> >> >>> On 29 March 2013 16:18, Edwin Smulders
>> >>> >> >>> >> >>> <edwin.smulders@gmail.com>
>> >>> >> >>> >> >>> wrote:
>> >>> >> >>> >> >>> > On 29 March 2013 15:25, Michael Hale Ligh
>> >>> >> >>> >> >>> > <michael.hale@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@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@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@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@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@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@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@gmail.com>
>> >>> >> >>> >> >>> >>> >>> >> wrote:
>> >>> >> >>> >> >>> >>> >>> >>> Here's /proc/1264/maps
>> >>> >> >>> >> >>> >>> >>> >>>
>> >>> >> >>> >> >>> >>> >>> >>> http://paste.ubuntu.com/5584610/
>> >>> >> >>> >> >>> >>> >>> >>>
>> >>> >> >>> >> >>> >>> >>> >>> On 1 March 2013 18:01, Edwin Smulders
>> >>> >> >>> >> >>> >>> >>> >>> <edwin.smulders@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@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@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@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@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@volatilityfoundation.org
>> >>> >> >>> >> >>> >>> >>> >>>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>> >>> >> >>> >> >>> >>> >>> >>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>> _______________________________________________
>> >>> >> >>> >> >>> >>> >>> >>>>>>> Vol-users mailing list
>> >>> >> >>> >> >>> >>> >>> >>>>>>> Vol-users@volatilityfoundation.org
>> >>> >> >>> >> >>> >>> >>> >>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>>
>> >>> >> >>> >> >>> >>> >>> >>>>>>> http://lists.volatilesystems.com/mailman/listinfo/vol-users
>> >>> >> >>> >> >>> >>> >>> >>>>>
>> >>> >> >>> >> >>> >>> >>
>> >>> >> >>> >> >>> >>> >>
>> >>> >> >>> >> >>> >>> >
>> >>> >> >>> >> >>> >>
>> >>> >> >>> >> >>> >>
>> >>> >> >>> >> >>
>> >>> >> >>> >> >>
>> >>> >> >>> >> >
>> >>> >> >>> >
>> >>> >> >>> >
>> >>> >> >>
>> >>> >> >>
>> >>> >
>> >>> >
>> >>
>> >>
>> >
>
>