Difference between pages "Linux Logical Volume Manager (LVM)" and "Imager NG Ideas"

From Forensics Wiki
(Difference between pages)
Jump to: navigation, search
 
(Supportive tooling)
 
Line 1: Line 1:
{{expand}}
+
This page is for discussing ideas regarding next-generation (NG) imaging tools.
  
The [[Linux]] Logical Volume Manager, is commonly abreviated to LVM. Although LVM can used for other [http://en.wikipedia.org/wiki/Logical_Volume_Management Logical Volume Management] variants as well.
+
Note that some of the ideas mentioned can be already used by imaging tools, but the idea of this page is to determine how useful these features could be for next-generation of imaging tools.
 +
The scope is mainly a software-based imaging tools, but not limited to. Some features might not be doable, because of limitations of certain image file formats.
  
Not all forensic tools have support for Linux Logical Volume Manager (LVM) volumes, but most modern Linux distributions do.
+
Please, do not delete text (ideas) here. Use something like this:
  
== Mounting an LVM from an image ==
 
If you have an image mount the LVM read-only on a loopback device (e.g. /dev/loop1) by:
 
 
<pre>
 
<pre>
sudo losetup -r -o $OFFSET /dev/loop1 image.raw
+
<s>bad idea</s>
 +
good idea
 
</pre>
 
</pre>
  
Note that the offset is in bytes.
+
This will look like:
  
If you need to write to the image, e.g. for recovery, use [[xmount]] to write the changes to a [[shadow file]] (or cachefile in xmount terminology).
+
<s>bad idea</s>
<pre>
+
sudo xmount --in dd --cache sda.shadow sda.raw image/
+
</pre>
+
  
You can then safely mount the LVM in read-write mode (just omit the -r in the previous losetup command).
+
good idea
  
To remove this mapping afterwards run:
+
= License =
<pre>
+
sudo losetup -d /dev/loop1
+
</pre>
+
  
To scan for new physical volumes:
+
= Features =
<pre>
+
* Compression
lvm pvscan
+
* Integrity checks
</pre>
+
* Encryption
 +
* Error correction (parity)
 +
* Pre-processing during imaging
 +
* User suspend/resume, resume after failure
 +
* Remote imaging
 +
* Error resistance in reading storage media, e.d. disks
 +
** maybe have different techniques, e.g. to use for heavily damaged storage media
 +
* Support different types of storage media
 +
** disk
 +
** volume
 +
** optical discs
 +
** memory
 +
** files and directories
 +
* Store relevant data about the storage media and the imaging process
 +
** read errors
 +
* Support multiple image format
 +
** not all image formats have support for all the features
  
You cannot unmount an active volume group. To detach (or deactivate) the volume group:
+
== Compression ==
<pre>
+
* Reduces the amount of data that needs to be written; improved the overall imaging speed.
vgchange -a n $VOLUMEGROUP
+
** hash-based imaging
</pre>
+
** detection of easy (emtpy-block) and hard (encrypted block) to compress data
 +
** multi-threaded compression
 +
** sparse ranges
 +
** de-duplication
  
Where $VOLUMEGROUP is the corresponding name of the volume group
+
=== de-duplication ===
 +
* hash-based imaging
 +
* sparse or repeated ranges
 +
* pattern-fill
  
The individual volume devices are now available in:
+
== Integrity checks ==
<pre>
+
* Integrity hash (MD5, SHA1, SHA256)
/dev/mapper/$VOLUMEGROUP-$VOLUMENAME
+
* piecewise hashing
</pre>
+
 
+
== Mounting an LVM from a device ==
+
 
+
To list the Volume Groups (VG) run:
+
<pre>
+
pvs
+
</pre>
+
 
+
To list information about a Volume Group (VG) run:
+
<pre>
+
lvdisplay $VOLUMEGROUP
+
</pre>
+
 
+
The field "LV Name" provides the volume name
+
 
+
To make the volume group known to the system
+
<pre>
+
vgexport $VOLUMEGROUP
+
</pre>
+
 
+
And active the volumes in the volume group
+
<pre>
+
vgchange -a y $VOLUMEGROUP
+
</pre>
+
 
+
The individual volume devices are now available in:
+
<pre>
+
/dev/mapper/$VOLUMEGROUP-$VOLUMENAME
+
</pre>
+
 
+
These now can be analyzed with e.g. a tool like the [[Sleuthkit]] or loop-back mounted.
+
 
+
To read-only loop-back mount an individual volume:
+
<pre>
+
mount -o ro /dev/mapper/$VOLUMEGROUP-$VOLUMENAME filesystem/
+
</pre>
+
  
== Also see ==
+
= Supportive tooling =
* [[:Category:File Systems|File Systems]]
+
== Image verification ==
 +
* modes:
 +
** full verification and print a report at the end
 +
** stop on error (useful for automation?)
  
== External Links ==
+
= Image format =
* [http://en.wikipedia.org/wiki/Logical_Volume_Manager_%28Linux%29 Wikipedia article on Logical Volume Manager]
+
Implied features for an image format
* [http://www.datadisk.co.uk/html_docs/redhat/rh_lvm.htm RedHat - LVM cheatsheet]
+
* High-speed imaging
 +
* Compact storage
 +
* Error-resistant storage (over a longer time)
 +
* Minimal overhead on read
 +
* Evidence bag
 +
** multiple images in one image format
 +
** support for additional information e.g. case data
  
[[Category:Volume Systems]]
+
[[Category:Research]]

Revision as of 13:17, 6 September 2012

This page is for discussing ideas regarding next-generation (NG) imaging tools.

Note that some of the ideas mentioned can be already used by imaging tools, but the idea of this page is to determine how useful these features could be for next-generation of imaging tools. The scope is mainly a software-based imaging tools, but not limited to. Some features might not be doable, because of limitations of certain image file formats.

Please, do not delete text (ideas) here. Use something like this:

<s>bad idea</s>
good idea

This will look like:

bad idea

good idea

Contents

License

Features

  • Compression
  • Integrity checks
  • Encryption
  • Error correction (parity)
  • Pre-processing during imaging
  • User suspend/resume, resume after failure
  • Remote imaging
  • Error resistance in reading storage media, e.d. disks
    • maybe have different techniques, e.g. to use for heavily damaged storage media
  • Support different types of storage media
    • disk
    • volume
    • optical discs
    • memory
    • files and directories
  • Store relevant data about the storage media and the imaging process
    • read errors
  • Support multiple image format
    • not all image formats have support for all the features

Compression

  • Reduces the amount of data that needs to be written; improved the overall imaging speed.
    • hash-based imaging
    • detection of easy (emtpy-block) and hard (encrypted block) to compress data
    • multi-threaded compression
    • sparse ranges
    • de-duplication

de-duplication

  • hash-based imaging
  • sparse or repeated ranges
  • pattern-fill

Integrity checks

  • Integrity hash (MD5, SHA1, SHA256)
  • piecewise hashing

Supportive tooling

Image verification

  • modes:
    • full verification and print a report at the end
    • stop on error (useful for automation?)

Image format

Implied features for an image format

  • High-speed imaging
  • Compact storage
  • Error-resistant storage (over a longer time)
  • Minimal overhead on read
  • Evidence bag
    • multiple images in one image format
    • support for additional information e.g. case data