[Vol-users] Extending the LiME Format

Joe Sylve joe.sylve at gmail.com
Sun Nov 11 19:15:40 EST 2018

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.volatilityfoundation.org/pipermail/vol-users/attachments/20181111/3cd53b89/attachment.html>

More information about the Vol-users mailing list