noxdafox
2016-Mar-02 15:47 UTC
[Libguestfs] [libguestfs] Libguestfs as filesystem forensic tool
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. Thank you.
Richard W.M. Jones
2016-Mar-02 15:53 UTC
Re: [Libguestfs] [libguestfs] Libguestfs as filesystem forensic tool
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. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
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. >