Difference between pages "Solid State Drive (SSD) Forensics" and "Rekall"

From ForensicsWiki
(Difference between pages)
Jump to: navigation, search
(Bibliography: added recent article on SSD forensics.)
 
m (Linux)
 
Line 1: Line 1:
Solid State Drives pose a variety of interesting challenges for computer forensics in comparison with traditional rotating magnetic platter hard drives.  
+
{{Infobox_Software |
 +
  name = Rekall |
 +
  maintainer = [[Michael Cohen]] |
 +
  os = {{Cross-platform}} |
 +
  genre = {{Memory analysis}}, {{Memory imaging}} |
 +
  license = {{GPL}} |
 +
  website = [https://code.google.com/p/rekall/ code.google.com/p/rekall/] |
 +
}}
  
Most SSD devices are based on flash memory; some have battery backed SRAM or DRAM with a flash backing store.
+
Rekall is the stand-alone continuation of the [[Volatility]] Technology Preview (TP) version, aka the scudette branch.
  
Flash has a number of key properties that complicate its use in computer storage systems and subsequent forensic analysis:
+
One of Rekalls goals is to provide better integration with [[GRR]] by improved modularity of the framework and having memory acquisition capability.[http://docs.rekall.googlecode.com/git/overview.html#_history]
# Internally, flash memory is not divided into the traditional 512 byte blocks, but instead is in pages of 2KiB, 4KiB, or larger, although it is still presented to the host computer in blocks
+
# Whilst hard drives can be written in a single pass, flash memory pages must be erased (in whole) before they can be rewritten.
+
# Rewriting a block at the operating system level does not necessarily rewrite the same page in the flash memory due to the controller remapping data to spread wear or avoid failing pages
+
# Each page can be erased and rewritten a limited number of times – typically 1000 to 10,000. (Hard drive sectors, in contrast, can be rewritten millions of times or more.)
+
# Flash data is often encrypted on the drive, and can be "erased" by telling the controller to forget the old key and generate a new one, as well as marking all blocks as unused
+
  
The controller in a flash SSD is significantly more complex in the number of tasks it has to perform in comparison to a magnetic rotating drive, with the following features:
+
== Memory acquisition drivers ==
# ''wear leveling'' – that is, spreading the writes to flash out among different sectors. Wear leveling is typically done with a ''flash translation layer'' that maps ''logical sectors'' (or LBAs) to ''physical pages''.  Most FTLs are contained within the SSD device and are not accessible to end users.
+
# ''read/modify/relocate+write'' - if the controller allows rewriting of a partial flash page, it must read the entire page, modify the sector that is being written, and write the new flash page in a new/fresh location which has been previously erased. the old pre-modification data's page is then queued for erase.
+
  
 +
The drivers can be found under:
 +
<pre>
 +
rekall/tools/linux
 +
rekall/tools/osx
 +
rekall/tools/windows
 +
</pre>
  
 +
=== Linux ===
 +
In rekall RC11 the advanced Linux acquisition tool (LMAP) was added. lmap allows to inject the pmem functionality into existing kernel modules to bypass having to build a pmem kernel module for every different kernel version. See the corresponding DFRWS EU 2014 paper for more information about LMAP.
  
==Bibliography==
+
To build the kernel module for the current kernel version, make sure you have a working build environment and the kernel headers installed. Change into this directory and run make:
<bibtex>
+
<pre>
@inproceedings{wei2011,
+
cd rekall/tools/linux/
  author = {Yuri Gubanov, Oleg Afonin},
+
make
  title = {Why SSD Drives Destroy Court Evidence, and What Can Be Done About It},
+
</pre>
  booktitle={Article},
+
  year = 2012,
+
  keywords = {ssd forensics},
+
  added-at = {2012-09-01T09:00:00.000+0100},
+
  url={http://forensic.belkasoft.com/en/why-ssd-destroy-court-evidence}
+
}
+
</bibtex>
+
  
<bibtex>
+
The acquisition driver is named pmem.ko.
@inproceedings{wei2011,
+
  author = {Michael Wei and Laura M. Grupp and Frederick M. Spada and Steven Swanson},
+
  title = {Reliably Erasing Data from Flash-Based Solid State Drives},
+
  booktitle={FAST 2011},
+
  year = 2011,
+
  keywords = {erasing flash security ssd},
+
  added-at = {2011-02-22T09:22:03.000+0100},
+
  url={http://cseweb.ucsd.edu/users/m3wei/assets/pdf/FMS-2010-Secure-Erase.pdf},
+
  biburl = {http://www.bibsonomy.org/bibtex/27c408ad559fc19f829717f485707a909/schmidt2}
+
}
+
</bibtex>
+
<bibtex>
+
@article{bell2011,
+
author="Graeme B. Bell and Richard Boddington",
+
title="Solid State Drives: The Beginning of the End for Current Practice in Digital Forensic Recovery?",
+
journal="Journal of Digital Forensics, Security and Law",
+
volume=5,
+
issue=3,
+
year=2011,
+
url={http://www.jdfsl.org/subscriptions/JDFSL-V5N3-Bell.pdf}
+
}
+
</bibtex>
+
<bibtex>
+
@inproceedings{Billard:2010:MSU:1774088.1774426,
+
author = {Billard, David and Hauri, Rolf},
+
title = {Making sense of unstructured flash-memory dumps},
+
booktitle = {Proceedings of the 2010 ACM Symposium on Applied Computing},
+
series = {SAC '10},
+
year = {2010},
+
isbn = {978-1-60558-639-7},
+
location = {Sierre, Switzerland},
+
pages = {1579--1583},
+
numpages = {5},
+
url = {http://doi.acm.org/10.1145/1774088.1774426},
+
doi = {http://doi.acm.org/10.1145/1774088.1774426},
+
acmid = {1774426},
+
publisher = {ACM},
+
address = {New York, NY, USA},
+
keywords = {cell phone, computer forensics, file carving, flash-memory dumps, forensics},
+
}
+
</bibtex>
+
<bibtex>
+
@mastersthesis{regan:2009,
+
  title="The Forensic Potential of Flash Memory",
+
  author="James E. Regan",
+
  school="Naval Postgraduate School",
+
  address="Monterey, CA",
+
  date=Sep,
+
  year=2009,
+
  pages=86,
+
  url="http://handle.dtic.mil/100.2/ADA509258"
+
}
+
</bibtex>
+
<bibtex>
+
@inproceedings{Phillips:2008:RDU:1363217.1363243,
+
author = {Phillips, B. J. and Schmidt, C. D. and Kelly, D. R.},
+
title = {Recovering data from USB flash memory sticks that have been damaged or electronically erased},
+
booktitle = {Proceedings of the 1st international conference on Forensic applications and techniques in telecommunications, information, and multimedia and workshop},
+
series = {e-Forensics '08},
+
year = {2008},
+
isbn = {978-963-9799-19-6},
+
location = {Adelaide, Australia},
+
pages = {19:1--19:6},
+
articleno = {19},
+
numpages = {6},
+
url = {http://portal.acm.org/citation.cfm?id=1363217.1363243},
+
acmid = {1363243},
+
publisher = {ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering)},
+
address = {ICST, Brussels, Belgium, Belgium},
+
keywords = {data recovery, flash memory, semiconductor data remanence},
+
}
+
</bibtex>
+
  
==Presentations==
+
To load the driver:
* [http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html Milan Broz's blog - TRIM & dm-crypt ... problems?]
+
<pre>
* [http://www.snia.org/events/storage-developer2009/presentations/thursday/NealChristiansen_ATA_TrimDeleteNotification_Windows7.pdf ATA Trim / Delete Notification Support in Windows 7], Neal Christiansen, Storage Developer 2009
+
sudo insmod pmem.ko
* [http://www.slideshare.net/digitalassembly/challenges-of-ssd-forensic-analysis Challenges of SSD Forensic Analysis], Digital Assembly,
+
</pre>
* [http://www.youtube.com/watch?v=WcO7xn0wJ2I Solid State Drives: Ruining Forensics], by Scott Moulton, DEFCON 16 (2008)
+
 
* Scott Moulton, Shmoocon 20008,  SSD drives vs. Hard Drives.
+
To check if the driver is running:
** [http://www.youtube.com/watch?v=l4hbdZFWGog SSD Flash Hard Drives - Shmoocon 2008 - Part 1]
+
<pre>
** [http://www.youtube.com/watch?v=mglEnIPnzjo SSD Flash Hard Drives - Shmoocon 2008 - Part 2]
+
sudo lsmod
** [http://www.youtube.com/watch?v=3psy_d-pyNg SSD Flash Hard Drives - Shmoocon 2008 - Part 3]
+
</pre>
** [http://www.youtube.com/watch?v=pKeZvhDd5c4 SSD Flash Hard Drives - Shmoocon 2008 - Part 4]
+
 
** [http://www.youtube.com/watch?v=9XMBdDypSO4 SSD Flash Hard Drives - Shmoocon 2008 - Part 5]
+
The driver create a device file named:
** [http://www.youtube.com/watch?v=LY36SWbfQg0 SSD Flash Hard Drives - Shmoocon 2008 - Part 6]
+
<pre>
* [http://risky.biz/RB185 Risky Business #185], Peter Gutmann talks SSD forensics, March 4, 2011 (Radio Show)
+
/dev/pmem
 +
</pre>
 +
 
 +
To unload the driver:
 +
<pre>
 +
sudo rmmod pmem
 +
</pre>
 +
 
 +
To read acquire the memory just read from the device file. e.g.
 +
<pre>
 +
dd if=/dev/pmem of=image.raw
 +
</pre>
 +
 
 +
For more information see:
 +
<pre>
 +
rekall/tools/linux/README
 +
</pre>
 +
 
 +
=== Mac OS X ===
 +
 
 +
For more information see:
 +
<pre>
 +
rekall/tools/osx/OSXPMem/README
 +
</pre>
 +
 
 +
=== Windows ===
 +
Since recent versions of Windows require a signed driver rekall comes with both pre-built (signed binary) and source versions of the driver.
 +
 
 +
Both the i386 and amd64 binary version of the driver can be found in the directory:
 +
<pre>
 +
rekall/tools/windows/winpmem/binaries
 +
</pre>
 +
 
 +
E.g.
 +
<pre>
 +
rekall/tools/winpmem/binaries/amd64/winpmem.sys
 +
</pre>
 +
 
 +
A standalone tool for imaging memory that uses an embedded copy of the pmem driver can be found as winpmem.exe in:
 +
<pre>
 +
rekall/tools/winpmem/executables/Release/
 +
</pre>
 +
 
 +
To load the driver:
 +
<pre>
 +
winpmem.exe -l
 +
</pre>
 +
 
 +
The device filename is (This can not be changed without recompiling):
 +
<pre>
 +
\\.\pmem
 +
</pre>
 +
 
 +
Note that running dd directly on this device file can crash the machine.
 +
Use the winpmem.exe tool instead because it handles protected memory regions.
 +
 
 +
To read and acquire the physical memory and write it to image.raw:
 +
<pre>
 +
winpmem.exe image.raw
 +
</pre>
 +
 
 +
To unload the driver:
 +
<pre>
 +
winpmem.exe -u
 +
</pre>
 +
 
 +
For more information see:
 +
<pre>
 +
rekall/tools/windows/README
 +
</pre>
 +
 
 +
== See Also ==
 +
* [[Memory analysis]]
 +
* [[Memory Imaging]]
 +
* [[Volatility]]
 +
 
 +
== External Links ==
 +
* [https://code.google.com/p/rekall/ Project site]
 +
* [http://docs.rekall.googlecode.com/git/index.html Project documentation]
 +
* [http://rekall-forensic.blogspot.com/ Rekall Memory Forensics blog]
 +
* [http://www.rekall-forensic.com/docs/References/Papers/DFRWS2013.html Anti-forensic resilient memory acquisition]] by [[Johannes Stüttgena]] [[Michael Cohen]], August 2013
 +
* [http://www.rekall-forensic.com/docs/References/Papers/DFRWS2014EU.html Robust Linux memory acquisition with minimal target impact], [[Johannes Stüttgena]] [[Michael Cohen]], May 2014

Revision as of 03:33, 25 June 2014

Rekall
Maintainer: Michael Cohen
OS: Cross-platform
Genre: Memory Analysis,Memory Imaging
License: GPL
Website: code.google.com/p/rekall/

Rekall is the stand-alone continuation of the Volatility Technology Preview (TP) version, aka the scudette branch.

One of Rekalls goals is to provide better integration with GRR by improved modularity of the framework and having memory acquisition capability.[1]

Memory acquisition drivers

The drivers can be found under:

rekall/tools/linux
rekall/tools/osx
rekall/tools/windows

Linux

In rekall RC11 the advanced Linux acquisition tool (LMAP) was added. lmap allows to inject the pmem functionality into existing kernel modules to bypass having to build a pmem kernel module for every different kernel version. See the corresponding DFRWS EU 2014 paper for more information about LMAP.

To build the kernel module for the current kernel version, make sure you have a working build environment and the kernel headers installed. Change into this directory and run make:

cd rekall/tools/linux/
make

The acquisition driver is named pmem.ko.

To load the driver:

sudo insmod pmem.ko

To check if the driver is running:

sudo lsmod

The driver create a device file named:

/dev/pmem

To unload the driver:

sudo rmmod pmem

To read acquire the memory just read from the device file. e.g.

dd if=/dev/pmem of=image.raw

For more information see:

rekall/tools/linux/README

Mac OS X

For more information see:

rekall/tools/osx/OSXPMem/README

Windows

Since recent versions of Windows require a signed driver rekall comes with both pre-built (signed binary) and source versions of the driver.

Both the i386 and amd64 binary version of the driver can be found in the directory:

rekall/tools/windows/winpmem/binaries

E.g.

rekall/tools/winpmem/binaries/amd64/winpmem.sys

A standalone tool for imaging memory that uses an embedded copy of the pmem driver can be found as winpmem.exe in:

rekall/tools/winpmem/executables/Release/

To load the driver:

winpmem.exe -l

The device filename is (This can not be changed without recompiling):

\\.\pmem

Note that running dd directly on this device file can crash the machine. Use the winpmem.exe tool instead because it handles protected memory regions.

To read and acquire the physical memory and write it to image.raw:

winpmem.exe image.raw

To unload the driver:

winpmem.exe -u 

For more information see:

rekall/tools/windows/README

See Also

External Links