[Vol-users] Extending the LiME Format
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
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
- 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...
More information about the Vol-users