Re: [Vol-users] Output from windows/wintree plugins - what does it mean?

Michael, Jamie - thank you (again) for the pointers. I promise I am spending time on this trawling through volatility source code, but I've hit a hurdle in my understanding (again). So I'm hoping for an answer that doesn't involve any Volatility code - I want to try and come up with that myself! In my plugin (a twist on the windows plugin), I cycle through the windows. In my head, I feel I should be issuing get_obj_offset against the wnd "object" that represents my EDIT window, but I can't - it's not a valid method. My hurdle: the Window (wnd) has a cbwndExtra of 0x4. So I want to be able to find the offset of WndExtra, i.e., use get_obj_offset. But I'm not sure which object stores this value. So my code will look something like offset_to_WndExtra = MYSTERY_A.get_obj_offset(MYSTERY_B, 'WndExtra'); This is my knowledge gap. I tried: offset_to_WndExtra = wnd._vol_vm.profile.get_obj_offset(MYSTERY_B, 'WndExtra'); but didn't know what to put for MYSTERY_B. I actually edited the obj.py to brute force the keys to see if any of them pointed to a value of 'WndExtra' but to no luck. So, I'm hoping, without giving me the code, what am I misunderstanding? Or, what documentation / blog / forum / Windows header file can I look at to find my answer? Thank you again, Adam On Wednesday, 12 March 2014, 14:57, Michael Ligh <michael.ligh(a)mnin.org> wrote: Hey Adam, Yes, aside from the tip Jamie gave you, I included a few comments inline below: On Mar 12, 2014, at 9:15 AM, Jamie Levy <jamie(a)memoryanalysis.net> wrote: Its close - cbwndExtra is the number of bytes in the WndExtra member. So first you would check if cbwndExtra is > 0 and if so, then it means WndExtra is valid and contains cbwndExtra number of bytes. You’d then need to get the offset to the WndExtra member to actually find the data. Ah, welcome to kernel session memory. See slide 10 of this PDF: https://docs.google.com/open?id=0B6sJr6AdVULGZE1EVTR6YVVMZXc You’re probably used to all processes having the same “view” of addresses in kernel mode, but there are exceptions. Assuming you’re on a system with only one session (i.e. the “Sess” column of pslist), then 0xfea0dc70 will translate to the same physical offset regardless of which process’s page table you use. However, if there are multiple sessions, then you must translate 0xfea0dc70 using a process running in the same session in which you found the tagWND. The windows plugin will print a header like this: ************************************************** Window context: 1\WinSta0\Default That tells you that all windows that follow are in session 1. To get the proper physical offset in that case, you can either edit the windows plugin to also print the physical offset next to each tagWND or you can use volshell like this: volshell> cc(pid = XX) # where XX is the pid of a process in the proper session volshell> process_space = self.proc.get_process_address_space() volshell> offset = process_space.vtop(0xfea0dc70) volshell> print hex(offset)