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).

Rich.

On Wed, Mar 02, 2016 at 05:59:32PM +0200, noxdafox wrote: > 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. Yes that's a rather large dependency. However it's possible to use optgroups ["optional" field in generator/actions.ml] and subpackaging to mean that end users don't need to install this dependency unless they want it.

Would need to see the patches before really deciding. Rich.