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@volatilesystems.com
>> >>> >>> >>> >>>>>>>>
>> >>> >>> >>> >>>>>>>>
>> >>> >>> >>> >>>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>> >>> >>> >>> >>>>>>> _______________________________________________
>> >>> >>> >>> >>>>>>> Vol-users mailing list
>> >>> >>> >>> >>>>>>> Vol-users@volatilesystems.com
>> >>> >>> >>> >>>>>>>
>> >>> >>> >>> >>>>>>>
>> >>> >>> >>> >>>>>>> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>> >>> >>> >>> >>>>>
>> >>> >>> >>
>> >>> >>> >>
>> >>> >>> >
>> >>> >>
>> >>> >>
>> >>
>> >>
>> >
>
>