On 02/03/16 17:53, Richard W.M. Jones wrote:
On Wed, Mar 02, 2016 at 05:47:40PM +0200, noxdafox wrote:
> Greetings,
>
> I am playing around with the idea of using libguestfs as a forensic
> tool to investigate VM disk images.
>
> Some use cases as example:
> * Sandbox for malware analysis.
> * Incident response in cloud environments.
>
> Libguestfs is a precious resource in this case as it allows to
> abstract the disk image internals and expose them as mountable
> devices.
>
> Combined with some state of the art tool such as The Sleuth Kit it
> would turn it into a pretty powerful forensic tool.
>
http://www.sleuthkit.org/
>
> I played around with some proof-of-concept and the idea seems to work.
>
> The question I'd like to ask is if this feature would interest the
> libguestfs community or if I shall fork the project
> (libguestforensic?) and, if so, what is the preferable way to do it.
Actually I believe parts of libguestfs (and especially hivex) are
already used in this way.
Anyhow you're free to fork libguestfs provided you obey the license.
It may be easier/less work if you submit patches upstream where they
make sense for the upstream project, such as generally useful APIs
(like the ntfscat-i API).
One of the patches I'm talking about would add TSK
(The Sleuth Kit) as a
dependency within the appliance.
This would bring new APIs such as:
'fls' more powerful 'ls' command allowing to get list of deleted files
or timelines at a given path.
'icat' similar to ntfscat-i but it supports multiple FS.
Yet I'm not sure whether it's desirable as it is for a narrow use case
and on my Debian box TSK is a 12Mb binary.
Rich.