8:14 p.m.
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
5:46 p.m.
New subject: Output from windows/wintree plugins - what does it mean?
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:
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
6:56 a.m.
New subject: Output from windows/wintree plugins - what does it mean?
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(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:
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)volatilesystems.com
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
10:15 a.m.
New subject: Output from windows/wintree plugins - what does it mean?
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?!)
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(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
<http://www.cc.gatech.edu/%7Ebrendan/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
<http://volatility-labs.blogspot.com/>
Training: http://memoryanalysis.net <http://memoryanalysis.net/>
On Mar 8, 2014, at 7:14 PM, Bridgey <adam.bridge(a)yahoo.com
<mailto:adam.bridge@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
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 <mailto:Vol-users@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
10:57 a.m.
New subject: Output from windows/wintree plugins - what does it mean?
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
9:44 a.m.
New subject: 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:
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>_______________________________________________ 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)volatilesystems.com
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 Vol-users mailing list
Vol-users(a)volatilesystems.com
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
5:05 p.m.
New subject: Output from windows/wintree plugins - what does it mean?
Hey Adam,
get_obj_offset is a method of the obj.Profile class:
https://code.google.com/p/volatility/source/browse/trunk/volatility/obj.py#…
It accepts a string name of the structure and string name of the desired member. Like
this:
address_space.profile.get_obj_offset(“tagWND”, “cbwndExtra”)
Assuming you have an instance of a tagWND in the variable wnd, you can access the method
like this:
wnd.obj_vm.profile.get_obj_offset(“tagWND”, “cbwndExtra”)
However, if you have an instance of wnd, and you just need the absolute address one of its
members, you can just do this instead:
wnd.cbwndExtra.obj_offset
So assuming the offsets are correct in the vtype definition, you could read cbwndExtra
number of bytes from WndExtra like this:
data = wnd.obj_vm.read(wnd.WndExtra.obj_offset, wnd.cbwndExtra)
That’s actually a tiny bit redundant, because if WndExtra is always cbwndExtra of bytes in
size, you can define that relationship in the vtype. For example, here’s how we do it for
a similar structure:
https://code.google.com/p/volatility/source/browse/trunk/volatility/plugins…
'_COMMAND': [ None, {
'CmdLength': [ 0x00, ['unsigned short']],
'Cmd' : [ 0x02, ['String', dict(encoding = 'utf16', length =
lambda x : x.CmdLength)]],
}],
The problem in your case is WndExtra is another structure, not a string of X characters or
an array of X types. So instead you could also just first check cbwndExtra just to make
sure there’s some data there and then do:
editbox = obj.Object(“_EDIT”, offset = wnd.WndExtra.obj_offset, vm = wnd.obj_vm)
Just a warning with all this, the structures you’re looking into IIRC are mostly
undocumented. Brendan named WndExtra himself, but his gdiutils library only covered XP
32-bit. The kernel structures for these objects were only divulged in pdb files for
Windows 7, so if any offsets changed between OS, they’d have to be reverse engineered
(unless you can find a reference somewhere).
For example here’s a windows 7:
https://code.google.com/p/volatility/source/browse/trunk/volatility/plugins…
It has a cbwndExtra, but no WndExtra. Its possible that WndExtra just exists in the space
immediately after the tagWND, if cbwndExtra > 0.
Hope this helps some!
MHL
--------------------------------------------------
Michael Ligh (@iMHLv2)
GPG: http://mnin.org/gpg.pubkey.txt
Blog: http://volatility-labs.blogspot.com
Training: http://memoryanalysis.net
On Mar 13, 2014, at 8:44 AM, Bridgey <adam.bridge(a)yahoo.com> wrote:
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:
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>_______________________________________________ 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 Vol-users mailing list
Vol-users(a)volatilityfoundation.org
http://lists.volatilityfoundation.org/mailman/listinfo/vol-users
3899
days inactive
3903
days old
vol-users@lists.volatilityfoundation.org
6 comments
3 participants
participants (3)
-
Bridgey -
Jamie Levy -
Michael Ligh