The CFP deadline is tomorrow for the 10th Annual Open Source Digital
Forensics Conference (OSDFCon). The conference will be held on Oct 16,
2019.
There are openings for:
* 10-minute short talks
* 35-minute in-person talks
* 35-minute remote talks
* 3-hour hands on workshops
https://www.osdfcon.org/2019-event/2019-call-for-presentations/
Please submit your ideas about open source tools you've developed, used, or
want to exist. The event is 1-day long with 400+ attendees. It's the
biggest open source digital forensics event and the biggest DFIR event in
the Metro DC region.
All you need to submit is an abstract and then we'll crowd source the
agenda.
thanks,
brian
We wanted to send a reminder that our next Malware and Memory Forensics training offering will be in Reston in April. We are about 8 weeks away now and already have a number of seats filled. Our courses in the Reston/Herndon area generally sell out early so please contact us ASAP if you wish to attend.
Full information can be found here:
https://volatility-labs.blogspot.com/2018/11/malware-and-memory-forensics-t…
We are looking forward to meeting many of you there!
We are excited to announce our public Malware and Memory Forensics training offerings for 2019!
We will be headed back to Herndon in the Spring and to Herndon and London in the Fall.
Full details of the training, including a list of newly updated material, can be found on our blog post:
https://volatility-labs.blogspot.com/2018/11/malware-and-memory-forensics-t…
We deeply appreciate your continued support for Volatility and our trainings, and we are excited for another great year of open source memory forensics research and development.
-- The Volatility Team
Since there seems to be a renewed interest in LiME and it's format, I think
it's time that we extend the format to include the storage of optional
metadata. Anything that can be collected at acquisition time saves the
need for scanning and other possibly more complex processes during
analysis. Formats like AFF4 are great, but are too complex to implement in
the kernel.
I'd like to crowdsource opinions on how the LiME format should be
extended. When contributing thoughts please keep the following in mind.
- Changes to the format should not break existing parsers
- To minimize the number of future changes, the enhancements should be
as flexible as possible. For example, I've heard rumors that the LiME
format is being used in acquisition tools that target more than just Linux,
so I'd prefer a generic key/value store for metadata rather than any
hardcoded solution.
- Whatever we collect during acquisition time (at least in LiME) must be
easily accessible from a kernel module
What are your thoughts? What metadata should be collected? Obvious
answers that come to mind are DTB, kernel virtual base address, and KASLR
slide, but I'm sure there are more.
We wanted to send a quick note that we will have a sponsor table tomorrow at OSDFCON. Please come by and see us during the day and also during the conference social at night.
If you are a previous training course alumni and/or a past Volatility contributor then please stop by as we will have some special edition swag for you:
https://twitter.com/volatility/status/1052210342577795073
We will also be raffling a free seat for one of our 2019 trainings offerings:
https://twitter.com/volatility/status/1050769125080006658
We are looking forward to seeing many of you tomorrow!
We wanted to send a reminder as the deadline for both the Volatility Analysis Contest AND the Volatility Plugin Contest is approaching:
https://volatility-labs.blogspot.com/2018/05/the-6th-annual-volatility-plug…
The Plugin contest gives you the opportunity to showcase your research and development skills.
The Analysis Contest lets you showcase your memory forensics skills against malware and real-world IR situations.
Both contests have a number of prizes and a bunch of swag ready for the winners.
We hope to see many great submissions, and we look forward to reviewing them all!
Thanks,
The Volatility Team
Hi list,
Apologies for the cross-post.
Has anyone created a Volatility profile for Solaris or AIX that they would
be willing to share?
I am also searching for a way/tool to image RAM from Solaris and AIX
operating systems. If anyone has any experience in this area please get it
touch.
Thanks,
Brent Muir
As members of the Volatility mailing list, you know that memory
acquisition has proven to be one of the most important and precarious
aspects of digital investigations. Over the years, you have seen the
Volatility team spend a lot of time troubleshooting issues that were
ultimately caused by failed or corrupted acquisition attempts. You have
also seen our colleague, George M. Garner, lead spirited debates about the
reliability of proposed acquisition tools and techniques. With George’s
untimely passing last summer, the industry not only lost one of the most
robust Window’s acquisition tools, but it also lost an industry thought
leader who held the forensics community to a higher standard.
Unfortunately, many investigators still blindly trust free and commercial
acquisition tools without understanding the associated risks and
limitations. While these tools may be readily accessible, many are
unsupported or have been effectively abandoned by their original
developers who have moved on to pursue other projects. As an example,
Google’s GRR project recently disabled their memory forensics capabilities
because it was introducing instabilities, and it wasn’t being actively
maintained. A recent empirical study also showed that most open source or
commercial Windows memory acquisition tools either failed to collect or
crashed systems with modern security features enabled. We can also share
countless stories of investigators and law enforcement officers returning
to their labs only to discover that their memory acquisitions had failed.
There is a growing need for a reliable and actively supported memory
acquisition capability across Windows, Linux, and macOS.
If you follow us on twitter (@volatility) or have taken our training
classes within the last couple of years, you have heard about Volexity’s
Surge Collect. Surge Collect provides a reliable and commercially
supported collection capability with flexible storage options. Surge
Collect can also be easily integrated with Tanium, Carbon Black, and other
enterprise software agents. It is currently in use by many of the largest
federal and local law enforcement agencies around the world. Surge
Collect is also actively used by leading incident response firms,
technology companies, telecommunication providers, universities, Fortune
companies, and branches of the military.
If you are looking for a commercially supported acquisition solution with
dedicated development and support teams for Windows, Linux, and macOS, I
recommend you check out Volexity’s Surge Collect. Hopefully, this will
FINALLY give investigators a reliable and flexible acquisition capability
they can depend on and allow the Volatility team to focus more of our time
on developing exciting new memory analysis capabilities!
Thanks,
AAron Walters
Original author of Volatility
Founder of The Volatility Foundation
