<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 20/07/16 17:04, Pino Toscano wrote:<br>
    <blockquote cite="mid:12451823.AGtT5iSxgh@thyrus.usersys.redhat.com"
      type="cite">
      <pre wrap="">Hi,

On Sunday, 17 July 2016 20:40:18 CEST Matteo Cafasso wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">v2:

 - Rebase on top of master

Matteo Cafasso (2):
  New API: download_blocks
  Added download_blocks API test

 daemon/sleuthkit.c                | 41 ++++++++++++++++++++++++++-
 generator/actions.ml              | 24 ++++++++++++++++
 gobject/Makefile.inc              |  2 ++
 src/MAX_PROC_NR                   |  2 +-
 tests/tsk/Makefile.am             |  1 +
 tests/tsk/test-download-blocks.sh | 58 +++++++++++++++++++++++++++++++++++++++
 6 files changed, 126 insertions(+), 2 deletions(-)
 create mode 100755 tests/tsk/test-download-blocks.sh
</pre>
      </blockquote>
      <pre wrap="">The series LGTM, I pushed it after removing the extra change in
do_download_inode and fixing the version.

More a curiosity question than a complain or something else: how are
these APIs are supposed to be used?  What is the forensics-related
workflow using them?  </pre>
    </blockquote>
    Current focus is deleted/unaccessible files retrieval as I believe
    this is the most interesting feature for libguestfs users.<br>
    <br>
    A forensic workflow example would be:<br>
     * start libguestfs and identify the disk partition where your data
    is<br>
     * run filesystem_walk to get list of files which are visible within
    that disk partition<br>
     * if the deleted file you want to recover is in that list, you'll
    get its inode<br>
     * use download_inode to try recovering the deleted file<br>
    <br>
    For Ext3+ filesystems the thing is a bit more complicated. These
    filesystems remove the block links when the file gets deleted making
    its recovery more difficult. Only choice is carving out the data and
    download_blocks is the function which allows you to do so. What the
    User needs is an API capable of mapping disk blocks to files and
    then he/she will be able to recover them using download_blocks.<br>
    <br>
    Most of the APIs I am introducing are inspired from TSK ones. Here's
    a more detailed example on how to retrieve deleted data from disks.<br>
    <a class="moz-txt-link-freetext" href="http://wiki.sleuthkit.org/index.php?title=FS_Analysis">http://wiki.sleuthkit.org/index.php?title=FS_Analysis</a><br>
    <br>
    Afterwards, we could focus on more interesting topics such as
    evidence gathering and forensics analysis. Automating it is a
    challenging topic as most of the "evidence reconstruction" requires
    careful thinking as the data might have been tampered or obfuscated.
    <br>
    <br>
    Yet there are quite interesting features we can add which could
    support forensic analysis as well as cloud security solutions. Think
    about libguestfs scanning Open Stack instance disks to detect
    anomalies within cloud deployments. libguestfs is the perfect tool
    as it easily allows to abstract both the disk virtualisation
    technology (qcow2, vmdk etc..) and the guest Operating System.<br>
    <br>
    You can find an example on libguestfs-based VM scanning solution in
    here:<br>
    <a class="moz-txt-link-freetext" href="https://github.com/noxdafox/vminspect">https://github.com/noxdafox/vminspect</a><br>
    <br>
    If you check the "timeline" command implementation, you'll find few
    of the new APIs in use. <br>
    <br>
    <blockquote cite="mid:12451823.AGtT5iSxgh@thyrus.usersys.redhat.com"
      type="cite">
      <pre wrap="">Considering they are quite specific, I was
thinking about adding a documentation paragraph and/or some example
to describe/show them better, what do you think?</pre>
    </blockquote>
    <br>
    This is a good question, I was thinking about a blog post to start
    with but a paragraph in the documentation sounds good as well. Let
    me know if you need help for that, I can provide some real-life
    example.<br>
    <br>
    <blockquote cite="mid:12451823.AGtT5iSxgh@thyrus.usersys.redhat.com"
      type="cite">
      <pre wrap="">
Thanks,
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Libguestfs mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Libguestfs@redhat.com">Libguestfs@redhat.com</a>
<a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/libguestfs">https://www.redhat.com/mailman/listinfo/libguestfs</a></pre>
    </blockquote>
  </body>
</html>