10:57 a.m.
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:
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/…
[2]
http://code.google.com/p/volatility/source/browse/trunk/volatility/plugins/…
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?!)
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.
> 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.
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)
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(a)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(a)yahoo.com> wrote:
--
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
<0x27A4AC92.asc>_______________________________________________
Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users 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(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