Re: [Vol-users] Incorrect addresses in linux_proc_maps

http://paste.ubuntu.com/5670109/ Cheers, Edwin On 2 April 2013 13:12, Michael Hale Ligh &lt;michael.hale(a)gmail.com&gt; 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 > &lt;edwin.smulders(a)gmail.com&gt; > 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 &lt;michael.hale(a)gmail.com&gt; >> 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 >> > &lt;michael.hale(a)gmail.com&gt; >> > 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 >> >> &lt;edwin.smulders(a)gmail.com&gt; wrote: >> >>> >> >>> Correct URL: http://packages.ubuntu.com/precise/dwarfdump >> >>> >> >>> On 29 March 2013 16:18, Edwin Smulders &lt;edwin.smulders(a)gmail.com&gt; >> >>> wrote: >> >>> > On 29 March 2013 15:25, Michael Hale Ligh >> >>> > &lt;michael.hale(a)gmail.com&gt; >> >>> > 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 >> >>> >> &lt;edwin.smulders(a)gmail.com&gt; >> >>> >> 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; >> >>> >>> 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 >> >>> >>> > &lt;michael.hale(a)gmail.com&gt; >> >>> >>> > 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 >> >>> >>> >> &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; >> >>> >>> >>> 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 >> >>> >>> >>> > &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 >> >>> >>> >>> >> why. >> >>> >>> >>> >> >> >>> >>> >>> >> On 4 March 2013 10:02, Edwin Smulders >> >>> >>> >>> >> &lt;edwin.smulders(a)gmail.com&gt; >> >>> >>> >>> >> wrote: >> >>> >>> >>> >>> Here's /proc/1264/maps >> >>> >>> >>> >>> >> >>> >>> >>> >>> http://paste.ubuntu.com/5584610/ >> >>> >>> >>> >>> >> >>> >>> >>> >>> On 1 March 2013 18:01, Edwin Smulders >> >>> >>> >>> >>> &lt;edwin.smulders(a)gmail.com&gt; >> >>> >>> >>> >>> 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 >> >>> >>> >>> >>>> &lt;michael.hale(a)gmail.com&gt; >> >>> >>> >>> >>>> 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 >> >>> >>> >>> >>>>> &lt;michael.hale(a)gmail.com&gt; >> >>> >>> >>> >>>>> 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 >> >>> >>> >>> >>>>>> &lt;atcuno(a)gmail.com&gt; >> >>> >>> >>> >>>>>> 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 >> >>> >>> >>> >>>>>>> &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 >> >>> >>> >>> >>>>>>>> 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 >> >>> >>> >>> >>>>> >> >>> >>> >> >> >>> >>> >> >> >>> >>> > >> >>> >> >> >>> >> >> >> >> >> >> > > >