Hello All,
We are excited to announce the keynote and speaker lineup for BSidesNOLA
2017!
http://www.bsidesnola.com
This all-day event will take place on April 1st in the New Orleans CBD.
It is a great time for learning, networking, and enjoying great food and
drinks.
It is $15 to attend, and this includes refreshments and a t-shirt.
We had around 215 people attend last year, and expect more this year.
If you have any questions then please let me know.
--
Thanks,
Andrew (@attrc)
Hi all,
I know in an ideal world I'd submit this as a pull request to the github
project, but you'll see why I haven't.
With the Win81U1x64 profile, the `windows` plugin is able to correctly
report the associated PID:
Window Handle: #20074 at 0xfffff90140819cf0, Name: Untitled - Notepad
ClassAtom: 0xc12c, Class: -
SuperClassAtom: 0xc12c, SuperClass: -
pti: 0xfffff9014225b9b0, Tid: 2532 at 0xffffe00001dbe600
ppi: 0xfffff90140747010, Process: notepad.exe, Pid: 2528
However, using the Win10x64 profile it cannot, because tagWND.head.pti.ppi
is 0x0.
Window Handle: #10222 at 0xfffff90140a26ae0, Name: Untitled - Notepad
ClassAtom: 0xc16d, Class: -
SuperClassAtom: 0xc16d, SuperClass: -
pti: 0xfffff90141fa3b20, Tid: 4652 at 0xffffe00014b9e380
ppi: 0x0, Process: -, Pid: -
I'm pretty sure I've traced this to being that in tagWND.head.pti the
offset to ppi is wrong.
$ python vol.py -f Win10x64.vmem --profile Win10x64 volshell
--SNIP--
>>> dt('tagTHREADINFO')
'tagTHREADINFO' (936 bytes)
0x0 : pEThread ['pointer64', ['_ETHREAD']]
0x8 : RefCount ['unsigned long']
--SNIP--
0x168 : spklActive ['pointer64', ['tagKL']]
0x170 : pcti ['pointer64',
['tagCLIENTTHREADINFO']]
0x170 : ppi ['pointer', ['tagPROCESSINFO']]
0x178 : rpdesk ['pointer64', ['tagDESKTOP']]
--SNIP--
You can see that `ppi`, the pointer to `tagPROCESSINFO`, is at 0x170 - the
same as `pcti`.
The pointer to the tagPROCESSINFO structure is actually at 0x178 -
currently shown as `rpdesk`.
If I modify `volatility/plugins/gui/vtypes/win8.py`, at line 197 from:
'ppi': [0x170, ['pointer', ['tagPROCESSINFO']]],
to:
'ppi': [0x178, ['pointer', ['tagPROCESSINFO']]],
the `windows` plugin now behaves itself:
Window Handle: #10222 at 0xfffff90140a26ae0, Name: Untitled - Notepad
ClassAtom: 0xc16d, Class: -
SuperClassAtom: 0xc16d, SuperClass: -
pti: 0xfffff90141fa3b20, Tid: 4652 at 0xffffe00014b9e380
ppi: 0xfffff90141fa5c10, Process: notepad.exe, Pid: 3692
And it's at this point where my understanding of the Volatility code breaks
down and why I'm not comfortable submitting a pull request. I don't know
how to implement an overlay for Win10 and what knock-on effect it might
have.
My *guess* would be that Microsoft has added an extra value to the
tagTHREADINFO structure between Windows 8 and Windows 10 meaning the offset
(within the tagTHREADINFO structure) has moved along 8 bytes (0x170 ->
0x178), but I don't know the rest of the structure well enough to
confidently validate this theory.
Perhaps one of the Volatility core developers does?
Thanks,
Adam
All,
My Forensic team is hiring two paid Forensic Interns for the summer of 2017
in the Northern Virginia area. We are charged with directly supporting
Sony's global SOC, which ends up touching many core facets of digital
forensics and incident response including:
memory analysis
disk analysis
mobile device forensics
timeline investigations
research and development projects
data analytics
If you are interested please feel free to apply directly on the job listing
below. If you have any questions you can reach out to me directly.
https://careers.sony.com/sony/?_3x3524903Z2U14Kdf8024bc-fbd2-4d8e-96d7-d7a5…
I'll also be doing some recruiting at BSides New Orleans
<http://www.securitybsides.com/w/page/113990746/BSidesNOLA%202017> on 4/1
where i'll be talking about a case study on Andromeda malware.
Best Regards,
Jared Greenhill (@jared703)
Hi all,
I feel like I'm missing something obvious. Consider the following from
volshell.
Profile is Win10x64 in case it matters; I'd already imported messagehooks
(mh).
>>> sc()
Current context: System @ 0xffffe00012a61840, pid=4, ppid=0 DTB=0x1aa000
>>> for winsta, atom_tables in mh.calculate():
... for desktop in winsta.desktops():
... for wnd, _level in desktop.windows(desktop.DeskInfo.spwnd):
... if wnd.cbwndExtra == 8:
... break
>>> wnd
[tagWND spwndNext] @ 0xFFFFF90140A04AD0
>>> dt(wnd)
[tagWND spwndNext] @ 0xFFFFF90140A04AD0
0x0 : head 18446736382507371216
0x28 : bActiveFrame 0
0x28 : bAnsiCreator 0
--SNIP--
0x120 : bLinked 1
0x120 : bRedirectedForPrint 0
0x120 : bVerticallyMaximizedLeft 0
0x120 : bVerticallyMaximizedRight 0
>>> dt('tagWND', wnd.v())
ERROR: could not instantiate object
Reason: Invalid Address 0xFFFFF90140A04AD0, instantiating tagWND
>>> hex(wnd.v())
'0xfffff90140a04ad0L'
>>> db(wnd.v())
Memory unreadable at fffff90140a04ad0
Why is the memory address unreadable? Is my error in assuming that object
'wnd' is made up of bytes located at 0xFFFFF90140A04AD0?
Given the address is in Kernel space, I should be able to access it right?
Any pointers appreciated! (Pardon the pun.)
Adam
