Hi Adam,

You should be able to use get_obj_offset() in lieu of get_member_offset().  You can see several examples of this function in cmdhistory [1] [2]. 

All the best,

-Jamie

[1] http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/malware/cmdhistory.py#679
[2] http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/malware/cmdhistory.py#712

 

On 3/12/2014 6:56 AM, Bridgey wrote:
Hi Michael,

Thanks so much for the tips - I've been reading through Brendan Dolan-Gavitt’s initial set of GDI utilities and have decided that using the existing 'windows' plugin is a good starting point.

My logic is as follows: Iterate over the tagWND objects (as per the windows plugin) and when I come across one that has a SuperClassAtom of Edit get the offset of 'cbwndExtra' and then read the Edit control properties/structure from the data at this offset. (Eeek! Maybe?! Is that right?!)

You kindly told me that "0xfea0dc70 is a virtual address in this case, its the location of the tagWND structure in kernel memory." so I thought I could look this up in the output from memmap:

Virtual    Physical         Size DumpFileOffset
---------- ---------- ---------- --------------
0xfea0d000 0x040ea000     0x1000      0xa80e000

So I thought I should be able to find the structure at offset 0x040eac70 in my raw dump file. This is so that I can manually look at the bytes when I'm building my plugin/script.

So, my actual question is... Brendan's code used get_member_offset(). I can see from the SVN that this was removed back in 2010, so what's the method of doing the same thing in today's code?

The bits are loosely there in my head - just trying to put them together in my head!
It's hard, but I'm loving it =)

Adam


On Sunday, 9 March 2014, 21:46, Michael Ligh <michael.ligh@mnin.org> wrote:
Hey Adam,

0xfea0dc70 is a virtual address in this case, its the location of the tagWND structure in kernel memory. Indeed, you can pull the text out of edit controls and various other window elements that we don’t currently analyze. Brendan Dolan-Gavitt’s initial set of GDI utilities [1] contained definitions for _TOOLBAR_WINDOW32, _TEXT_DESCRIPTOR, _EDIT_BOX, _STATUS_BAR, and a few of the critical structures for MSHTML documents. However, they’re for XP SP2/SP3 and may have changed since then, so its definitely possible, but will just require a bit of research.

Also, if you have access to a retail version of Visual Studio (not the free express version), then you should have Spy++ [2]. This lets you select any window on your desktop using your cursor and it will display the details like handle value, address in kernel memory, coordinates, and types of messages it sends/receives.

Hope this helps!
Michael

[1]. http://www.cc.gatech.edu/~brendan/volatility/dl/gdiutils-0.3.zip
[2]. http://msdn.microsoft.com/en-us/library/dd460756.aspx

--------------------------------------------------
Michael Ligh (@iMHLv2)
GPG: http://mnin.org/gpg.pubkey.txt
Blog: http://volatility-labs.blogspot.com
Training: http://memoryanalysis.net

On Mar 8, 2014, at 7:14 PM, Bridgey <adam.bridge@yahoo.com> wrote:

> Hi all,
>
> In my continuing exploration of Windows memory and Volatility I'm current looking at Windows, literally, the GUI.
>
> Looking at a notepad process, wintree shows me:
> .Untitled - Notepad (visible) notepad.exe:100 Notepad
> ..#20128  notepad.exe:100 6.0.7601.17514!msctls_statusbar32
> ..#20126 (visible) notepad.exe:100 6.0.7601.17514!Edit
> .Default IME  notepad.exe:100 IME
> .MSCTFIME UI  notepad.exe:100 MSCTFIME UI
>
> So, I'm assuming #20128 is the status bar at the bottom of the Notepad window, and #20126 is the edit control, that is, the textarea into which the user types.
>
> This is the corresponding output from the windows plugin for the edit control:
> Window Handle: #20126 at 0xfea0dc70, Name:
> ClassAtom: 0xc119, Class: 6.0.7601.17514!Edit
> SuperClassAtom: 0xc018, SuperClass: Edit
> pti: 0xfe2a4008, Tid: 1692 at 0x8550d368
> ppi: 0xffa95550, Process: notepad.exe, Pid: 100
> Visible: Yes
> Left: 10, Top: 52, Bottom: 485, Right: 701
> Style Flags: WS_VSCROLL,WS_CHILD,WS_OVERLAPPED,WS_VISIBLE,WS_HSCROLL
> ExStyle Flags: WS_EX_CLIENTEDGE,WS_EX_LTRREADING,WS_EX_RIGHTSCROLLBAR,WS_EX_LEFT
> Window procedure: 0x744399d0
>
> Question 1:
> Window Handle: #20126 at 0xfea0dc70 - what is the offset? Physical, virtual? Of what? The Edit control object?
> (I'm guessing: physical, yes, of the edit control object.)
>
> Question 2:
> I can see that it's Window-esque properties (X, Y, width, height, style flags, et al) are all clearly present., but where can I find information specific to this control (in this instance, an 'Edit'). For example, maybe the text it contains?
> (I'm guessing, take a look at 0xfea0dc70 and there'll be some kind of structure to parse.)
>
> As always, many thanks. (This is all going towards a plugin that I'm hoping to write!)
> Also as always, if I could've found this information on my own, please let me know where to look.
> I've read the Command Reference and the associated MoVP posts.
>
> Adam
> _______________________________________________
> Vol-users mailing list
> Vol-users@volatilityfoundation.org
> http://lists.volatilityfoundation.org/mailman/listinfo/vol-users




_______________________________________________
Vol-users mailing list
Vol-users@volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users

-- 
Jamie Levy (@gleeda)
Blog: http://volatility-labs.blogspot.com/
GPG:  http://pgp.mit.edu/pks/lookup?op=get&search=0x196B2AB527A4AC92
Fingerprint: 2E87 17A1 EC10 1E3E 11D3  64C2 196B 2AB5 27A4 AC92