Announcing our memory forensics trainings for 2019!
by Andrew Case
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
5 years, 11 months
- 1
- 0
Extending the LiME Format
by Joe Sylve
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.
6 years
- 1
- 0