Thanks Edwin. So in your dt() output, I can see those types are showing up
as "int" rather than "unsigned int" or "unsigned long" which
is why you see
some values showing up negative. However, I doubt they are really signed
values (especially when they're unsigned in all other versions of Linux).
So there may be an issue with our conversion code that reads the dwarfdump
output and creates the volatility vtypes. While we look into that, could
you tell me what version of dwarfdump you have installed?
Thanks!
Michael
On Fri, Mar 29, 2013 at 6:11 AM, Edwin Smulders <edwin.smulders(a)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(a)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(a)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(a)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(a)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(a)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(a)gmail.com>
>> >> wrote:
>> >>> Here's /proc/1264/maps
>> >>>
>> >>>
http://paste.ubuntu.com/5584610/
>> >>>
>> >>> On 1 March 2013 18:01, Edwin Smulders
<edwin.smulders(a)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(a)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(a)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(a)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(a)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(a)volatilityfoundation.org
>>>>>>>>
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>>> _______________________________________________
>>>>>>> Vol-users mailing list
>>>>>>> Vol-users(a)volatilityfoundation.org
>>>>>>>
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
>>>>>