Hi all,
I'm thinking I might have a fundamental misunderstanding here, so I'm
hoping someone can help me out.
I'm looking for remnants of a data structure in the memory of a specific
process.
Originally, the data would have been on a heap.
I notice that in '/volatility/plugins/overlays/windows/windows.py' there is
a function named:
search_process_memory
I thought this would do the trick, but examining the code I notice that it
searches each of the VADs.
Which leads me to my question: would data that was originally on a heap,
but is no longer needed by the process still be in the VAD? That is, should
I be able to find it using this method?
If not, "where" is the data now? And is there a way of searching wherever
that "where" is?
I hope that makes sense!
Bridgey
Hi all,
System is Win7SP1x86.
pagefile is OFF.
Consider this VAD node (from vadinfo):
VAD node @ 0x85e076d0 Start 0x76440000 End 0x764dffff Tag Vad
Flags: CommitCharge: 5, Protection: 7, VadType: 2
Protection: PAGE_EXECUTE_WRITECOPY
Vad Type: VadImageMap
ControlArea @853ab1e0 Segment 8f6eba98
NumberOfSectionReferences: 1 NumberOfPfnReferences: 120
NumberOfMappedViews: 32 NumberOfUserReferences: 33
Control Flags: Accessed: 1, File: 1, Image: 1
FileObject @853ab898, Name:
\Device\HarddiskVolume1\Windows\System32\advapi32.dll
First prototype PTE: 8f6ebac8 Last contiguous PTE: fffffffc
Flags2: Inherit: 1
My understanding is that this VAD node is tracking the pages from
0x76440000 through to 0x764dffff.
When I look at the output of memmap for this process and this range I see:
--SNIP--
0x76228000 0x1f04c000 0x1000 0x2c1000
0x76440000 0x20670000 0x1000 0x2c2000 <-- start
0x76441000 0x0b728000 0x1000 0x2c3000
0x76451000 0x233a8000 0x1000 0x2c4000
0x76454000 0x1f5ab000 0x1000 0x2c5000
0x76455000 0x2336c000 0x1000 0x2c6000
0x76456000 0x1f6ed000 0x1000 0x2c7000
0x76457000 0x1f6ae000 0x1000 0x2c8000
0x76458000 0x2346f000 0x1000 0x2c9000
0x76459000 0x1e48b000 0x1000 0x2ca000
0x7645a000 0x21fcc000 0x1000 0x2cb000
0x7645b000 0x223cd000 0x1000 0x2cc000
0x76460000 0x1e3d2000 0x1000 0x2cd000
0x76461000 0x1e103000 0x1000 0x2ce000
0x764af000 0x20636000 0x1000 0x2cf000
0x764b1000 0x23ef8000 0x1000 0x2d0000
0x764b3000 0x0bded000 0x1000 0x2d1000
0x764b7000 0x1f730000 0x1000 0x2d2000
0x764e0000 0x208e6000 0x1000 0x2d3000 <-- first byte after end
--SNIP--
The file itself, advapi32.dll, is 0xa0000 bytes (well, in memory).
dlllist shows:
Base Size LoadCount Path
---------- ---------- ---------- ----
0x76440000 0xa0000 0xffff C:\Windows\system32\ADVAPI32.dll
0x76440000 through to 0x764dffff is 0x9FFFF bytes long.
However, memmap is only showing 0x13000 bytes.
The 0x13000 isn't big enough to hold the 0xa0000 bytes of the file.
My question is, why isn't the whole range (0x76440000 through to
0x764dffff) shown in memmap?
Is it the case that the VAD node is responsible for the whole range, but
simply not all the pages in that range are in use which is why they're
missing from the memmap output?
Or is there something that I'm missing?
Any comments greatly appreciated!
Adam
Oh dear. I've just realised my mistake.
The memory address is of course the memory address on my system of the
object being returned.
Thank goodness I have a week off coming up...
Hi all,
I've come across a peculiarity that I'd really like someone to shed some
light on. Consider:
> python vol.py --profile Win7SP1x64 -f Windows7x64.vmem volshell
Volatility Foundation Volatility Framework 2.4
Current context: System @ 0xfffffa80018ae890, pid=4, ppid=0 DTB=0x187000
Welcome to volshell! Current memory image is:
file:///C:/Windows7x64.vmem
To get help, type 'hh()'
>>> for p in getprocs():
... my_proc = p
... break
...
>>> print my_proc.UniqueProcessId, my_proc.ImageFileName
4 System
>>> for i in range(10):
... my_proc.get_process_address_space()
...
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76240>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76470>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D762E8>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76240>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76470>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D762E8>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76240>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76470>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D762E8>
<volatility.plugins.addrspaces.amd64.AMD64PagedMemory object at
0x0000000008D76240>
There appears to be three different objects that are returned on a cycle.
Is this normal, expected behaviour? Why are there three?
Thank you!
Hello All,
I was writing a quick email to say that the entire Volatility team will
be at OSDFC in a few weeks. MHL will be showing off some of our new
capabilities, along with the results of the plugin contest, in the
morning. After that, we will all be hanging around throughout the day.
Please come say 'hi'!
http://www.osdfcon.org/2015-event/2015-program/
Also, we have two public classes currently being offered for 2016. The
first is in San Diego and the second is in Reston. Our classes have been
selling out pretty consistently so contact us ASAP if you are interested
in a seat:
http://www.memoryanalysis.net/#!memory-forensics-training/c1q3n
Hope to see many of you in a few weeks!
--
Thanks,
Andrew (@attrc)
All,
I've been messing around with this fun challenge as of late -
http://www.binary-zone.com/2015/09/16/digital-forensic-challenge-4/ and
have been struggling with question #5 (using memory forensics, can you
identify the shellcode used?).
My initial approach was starting with malfind and dumping malfind artifacts
and reviewing. I also threw some shellcode based yara sigs together, but
didn't have much luck there either.
Anyways, any help or direction pointing is appreciated :)
Best,
-Jared
We put together a quick blog post of upcoming and recent conferences,
research, analysis capabilities, and news related to Volatility.
It has been a pretty crazy summer, and we thank you all for the
continued support of the project!
http://volatility-labs.blogspot.com/2015/08/volatility-updates-summer-2015.…
If you will be at HTCIA next week, be sure to stop by the Volexity booth
and say 'hi' to some of our team members. You will also get a chance to
win a free spot to a future training!
--
Thanks,
Andrew (@attrc)
The Volatility team will be participating in a number of events at Black
Hat this year, and we hope to see many of you there.
This includes a book signing, arsenal demo, and even a party!
Full information can be found here:
http://volatility-labs.blogspot.com/2015/07/volatility-at-black-hat-usa-dfr…
Please let us know if you have any questions, and we look forward to
seeing many of you in Vegas!
--
Thanks,
Andrew (@attrc)
Hello All,
I was writing to request testing from anyone who may be running or have
access to a CentOS installation running a 2.6.18 series kernel.
Even though that series of kernels is ancient, CentOS/RH backports years
of patches into that series (for unknown reasons...), and then uses the
kernels in production systems.
I think we finally figured out the quirks related to this OS & kernel
version, so if you have a system please test it. If you find bugs please
either email them to me or file a bug on the Volatility tracker
(https://github.com/volatilityfoundation/volatility/issues)
--
Thanks,
Andrew (@attrc)
