Re: [Vol-users] Incorrect addresses in linux_proc_maps

On 29 March 2013 15:25, Michael Hale Ligh <michael.hale(a)gmail.com>

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 <

> 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 &lt;michael.hale(a)gmail.com&gt;

>> > 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 >> > &lt;michael.hale(a)gmail.com&gt; >> > wrote: >> >> >> >> Hey Edwin, >> >> >> >> Sorry for the delay and thanks for the additional output. Could you

>> >> one more thing, please? Instead of doing dt('mm_struct', address)

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

>> >> 0x4 : mm_rb ['rb_root'] >> >> 0x8 : mmap_cache ['pointer',

>> >> 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 >> >> &lt;edwin.smulders(a)gmail.com&gt; 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 &lt;michael.hale(a)gmail.com&gt;

>> >>> > 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 >> >>> > &lt;edwin.smulders(a)gmail.com&gt; >> >>> > 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

>> >>> >> wrote: >> >>> >>> Here's /proc/1264/maps >> >>> >>> >> >>> >>> http://paste.ubuntu.com/5584610/ >> >>> >>> >> >>> >>> On 1 March 2013 18:01, Edwin Smulders <

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

>> >>> >>>> wrote: >> >>> >>>>> Ah, this has to do with the fact that a long and unsigned

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

>> >>> >>>>> the >> >>> >>>>> 2.3 >> >>> >>>>> release, then we'll revert the patch in r3090 to

>> >>> >>>>> mask_number. >> >>> >>>>> >> >>> >>>>> Please still send the output of /proc/<pid>/maps just so we

>> >>> >>>>> how it >> >>> >>>>> looks for the future. >> >>> >>>>> MHL >> >>> >>>>> >> >>> >>>>> >> >>> >>>>> On Fri, Mar 1, 2013 at 10:53 AM, Michael Hale Ligh >> >>> >>>>> &lt;michael.hale(a)gmail.com&gt; >> >>> >>>>> wrote: >> >>> >>>>>> >> >>> >>>>>> Thanks for reporting. We just recently removed the

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

>> >>> >>>>>> numbers in >> >>> >>>>>> output). >> >>> >>>>>> >> >>> >>>>>> I'm guessing this may be a problem with our output

>> >>> >>>>>> but >> >>> >>>>>> we'll >> >>> >>>>>> look into it (the output of /proc/<pid>/maps like Andrew

>> >>> >>>>>> for >> >>> >>>>>> would be >> >>> >>>>>> useful). >> >>> >>>>>> >> >>> >>>>>> >> >>> >>>>>> On Fri, Mar 1, 2013 at 10:47 AM, Andrew Case <

>> >>> >>>>>> wrote: >> >>> >>>>>>> >> >>> >>>>>>> Can you send the output of /proc/<pid>/maps that

>> >>> >>>>>>> to >> >>> >>>>>>> one of >> >>> >>>>>>> the processes with the broken plugin output? >> >>> >>>>>>> >> >>> >>>>>>> On Fri, Mar 1, 2013 at 6:52 AM, Edwin Smulders >> >>> >>>>>>> &lt;edwin.smulders(a)gmail.com&gt; >> >>> >>>>>>> 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

>> >>> >>>>>>>> >> >>> >>>>>>>> http://paste.ubuntu.com/5576450/ >> >>> >>>>>>>> >> >>> >>>>>>>> I was expecting similar output to "cat /proc/<pid>/maps".

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

>> >>> >>>>>>> _______________________________________________ >> >>> >>>>>>> Vol-users mailing list >> >>> >>>>>>> Vol-users(a)volatilityfoundation.org >> >>> >>>>>>>

>> >>> >>>>> >> >> >> >> >> > > >