Tonight, myself, MHL, and Jamie will be on the Security Weekly (formerly
PaulDotCom) podcast discussing the new book:
http://securityweekly.com/2014/07/join-us-for-episode-380-with-andrew-case-…
If you cannot catch it live then they always post the recording within a
few days of the show.
Also, we are hearing that many people are getting their pre-order
shipping notifications for next week, and that the Kindle version is
already being sent to people's devices!
If you are going to be at Black Hat be sure to stop by on Thursday
during the book signing!
--
Thanks,
Andrew (@attrc)
It has been a busy year for the Volatility team, and we are inviting you
to celebrate the success with us at Black Hat and DFRWS. We have a
number of events happening across these conferences and have listed them
all in the following blog post:
http://volatility-labs.blogspot.com/2014/07/volatility-at-black-hat-usa-dfr…
We hope to see you all in Vegas and be sure to check out Dr. Golden's
talk if you will be at DFRWS!
--
Thanks,
Andrew (@attrc)
We are very happy to announce that you can now see the table of contents
and search through the Art of Memory Forensics on Amazon!
http://amzn.to/1o3ACn7
This book, written by the core Volatility developers, is over 900 pages
of memory forensics and malware analysis across Windows, Mac, and Linux.
It will be officially released at Blackhat and around this time it will
also be available through Amazon and other retailers. It will be
available in both hard copy and digital formats.
If you have any questions about the book please let us know, and we will
have more information about the release at Blackhat as it gets closer.
--
Thanks,
Andrew (@attrc)
We wanted to give everyone a quick update on some recent events in the
Volatility community.
First, the submissions for the Open Source Digital Forensics Conference
are available for voting. This conference's talk selection works by
posting each CFP submission in anonymized form and choosing talks based
on voting feedback from the community.
All of the talks can be found here:
http://www.basistech.com/osdfcon/osdfcon-vote-for-presentations
The submission from the Volatility Team is 'Next Generation Memory
Forensics'. If it sounds interesting to you then please give it a +1!
Second, our submission to Blackhat Arsenal was accepted!
https://www.blackhat.com/us-14/arsenal.html#Ligh
At this event we will be releasing the highly anticipated Volatility 2.4
that includes support for Windows 8, 8.1, 2012, 2012 R2 as well as new
plugins for Truecrypt, Linux, and Mac.
As Blackhat gets closer we will have more information on other events
there including a book signing and release party.
Finally, we now have a LinkedIn group for the Volatility and memory
forensics community:
https://www.linkedin.com/groups?mostRecent=&gid=8128809
This group is meant to allow analysts and researchers to ask questions,
learn from each other, and network. The group is open to all but marked
private to (hopefully) avoid spam.
--
Thanks,
Andrew (@attrc)
Hello all,
I'm analyzing a malware sample that is doing process hollowing. While
doing dynamic analysis, with Process Explorer open, I can see the
legitimate EXE (that appears to get hollowed) get started by the
malware, and is then orphaned as the malware terminates itself. A few
seconds later I see network communication starting.
The malfind plugin identifies the process as malware but when I try to
dump process from memory, the strings on the dumped process look the
same as the strings of the legitimate file in the System32 folder.
Using the yarascan plugin (following the example on the wiki) I'm able
to locate some strings (domain name, IP address, file requested by
GET) that are associated with the PID of the suspected hollowed
process.
Oh, and the malware is packed so I assume the unpacked code is being
placed into the address space of the legitimate file in memory.
The capture is a .vmem from a VM snapshot.
Any thoughts on how I can locate the unpacked code in memory?
Shouldn't dumping the PID with procexedump contain the unpacked code?
I've dumped the process by PID and physical offset (from psscan).
Thanks,
Carlos
Hi all,
Android Memory acquisition will be part of a paper I have to write. So
far I have no problem to follow the description for an AVD on
https://code.google.com/p/volatility/wiki/AndroidMemoryForensic
Please excuse this noob question (and my bad English) but I'm going
crazy figuring this out:
Can LiME be used in real life Android forensics that is Android memory
is acquired without having to reboot the Android device beforehand?
Let's say:
I get an running Android mobile phone and for some lucky reason it is
both rooted and the user interface unlocked. (Are there any statistics
available how often this is the case?) My task is to acquire its RAM.
As far as I understood in order to use Lime for RAM acquisition I have to
a) get the Android kernel's source code from the manufacturer,
b) cross compile a new kernel with some settings for later being able to
insmod the LiME kernel module,
c) flash the compiled kernel onto the phone and
d) reboot the phone to get the new kernel running, which
e) destroys all the RAM I wanted to acquire, before I can
f) insmod LiME.
Please be patient and give me a hint where I'm going wrong?!
All papers I found so far used prepared phones.
Thanks a lot and have a nice weekend,
Philipp
There are many new developments in the world of Volatility that we are
now happy to announce.
- The 2014 Volatility Plugin Contest has started
- We will be hosting a public training in Austin in December
- We have partnered with GMG Systems to provide our students access to
what we consider to be the most accurate and reliable memory acquisition
tool available
- The Volatility Foundation website is now live
For complete information on these and more, please see the following
blog post:
http://volatility-labs.blogspot.com/2014/05/volatility-update-all-things.ht…
--
Thanks,
Andrew (@attrc)
Dear sir,
Currently we doing investigate an security breach, our server is CentOS 5.8. After dump memory raw, we can not processing with Volatility. We have read the topic :
http://lists.volatilityfoundation.org/pipermail/vol-users/2013-February/000…
After edit to that DTB we found it work on LIME profile but doesn't work on Raw memory dump. Can we have some instruction how to convert Raw memory to LIME? Or how to debug to find correct DTB in raw memory only?
Btw, we trying to brute force like your advise but it very long since the range is from -0x200000 -> 0x200000.
Regards,
I'm looking for a patch-set that gets OSX 9.2 dumps from OSXPmem at
least marginally working. I know it's supposed to be in the upcoming
vol-2.4 release, but I'ld really like to see the progress/use
volatility instead of having to beat volafox in to shape to get 9.2
dumps to work.
Hi all,
I'm trying to understand what I've misunderstood.
Consider this entry from a run of vadinfo:
VAD node @ 0x84f1f3b0 Start 0x7ffde000 End 0x7ffdefff Tag Vadl
Flags: CommitCharge: 1, MemCommit: 1, NoChange: 1, PrivateMemory: 1, Protection: 4
Protection: PAGE_READWRITE
Vad Type: VadNone
First prototype PTE: 94181720 Last contiguous PTE: 94181728
This node represents a range which is private (PrivateMemory: 1).
If it's private, i.e. not shareable, why are there Prototype PTEs?
I though prototype PTEs were only used when a range was shareable?
I have a few Vadl nodes like this. The VadS nodes in the output with 'PrivateMemory: 1' don't show any prototype PTEs.
Any pointers greatly appreciated.
