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