Tag Archives: Digital Forensics

Making disk imaging a little easier

Greetings everyone. I recently created a Linux bash script that will add a text based user interface to one of the oldest disk imaging tools out there. The idea behind this was I tend to fat finger a bit so instead of typing out all of the command I would rather have a script handle the command syntax for me and all I would have to do is enter a few bits of data. After that the script would handle the rest.

This script uses the dd command for imaging. First let’s start off with the normal way dd is used.

checking for mounted devices
Before I use the dd command I check on which location in the file system the drive I want to image is located.
image being taken
This is the way the dd command is used on the command line.

Here’s the breakdown of the command:

sudo = this command provides the user with temporary root privileges

dd= the invocation of the dd command

if= This is the location of the disk that is to be imaged. In this case it’s /dev/sdb

of= the name of the output file. In this cases it’s image.dd

bs= this is the block size. DD takes data in chunks called blocks. The smaller the block the less errors you may have during imaging but it will take longer. The block size for this image is 2048K

Here’s the script in action.

This is the invocation of the dd script
This is the invocation of the dd script
Entering the location
Next the script will display a list of what devices are mounted to the OS The blkls command is used in the script to show this data. From this data a location of a mounted drive can be entered in.
entering output file name
The script is then going to ask for a file name for the image
Selecting the block size
After the file name is entered the script is going to ask for a block size. All the user has to do is enter a number 1-4 and a corresponding block size is selected
imaging started
Next the script will show what options the user selected and the imaging will begin. The script is still a work in progress. This is evident with the blank output in the current location field. The image is always located in the current working directory.

I plan on making tweaks and changes to this script. Once everything is done I’ll put the completed script in another post. Thanks for reading!

Advertisements

A taste of memory forensics

As hacking techniques evolve more and more, hacks are being done without the malicious programs touching the hard drive. All of these processes reside inside the memory of the victim computer. When this happens memory forensics becomes necessary. In this post I’m going to show a few of the volatility modules that can be used to find running processes, unknown network connections, and the DLLs associated with each process that are found inside of computer memory.

First I’m going to make sure I’m in the directory that has my memory images

I navigated to the directory where I have my memory images and I used the ls command to list them.
I navigated to the directory where I have my memory images and I used the ls command to list them.

Once I know I have the right images to analyze I use the volatility framework to analyze the memory files. Volatility is a free open source suite of software that is used for advanced memory forensics. It is supported by the Volatility Foundation. The website for the volatility foundation can be found at: http://www.volatilityfoundation.org/

First I’m going to check for open network connections.

This is the command that is used to see the open network connections at the time the memory image was taken
This is the command that is used to see the open network connections at the time the memory image was taken. The timeliner module is going to be used
I used the grep command to narrow down the results to just network connections that are active or "established".
I used the grep command to narrow down the results to just network connections that are active or “established”.

This is odd because this computer should not have any active network connections at all. So this is the first indication that something is wrong.

Next I dig a little deeper and I use volatility to display a list of all the running processes. The pslist module is used to do this.

The command for viewing the running processes
The command for viewing the running processes
Notice that you see an FTKimager.exe process. This is the imaging software that I used to capture the memory image
Notice that you see an FTKimager.exe process. This is the imaging software that I used to capture the memory image

In windows each executable (.exe) has dynamic link libraries (DLLs) associated with it. These are located inside of the .exe file. Volatility can be used to see each DLL that is inside of an executable. The dlllist module is used for this task.

The command to get the DLLs from the executables.
The command to get the DLLs from the executables.
The dlllidt module lists all of the DLLs associated with the EXEs. The modle also lists the command line syntax that is used to run each executable. The process ID for each EXE is also listed.
The dlllist module lists all of the DLLs associated with the EXEs. The module also lists the command line syntax that is used to run each executable. The process ID for each EXE is also listed.

I found an interest DLL in one of the executables. I decided to Google it to see if it was something odd.

After searching Google for this I found out that this DLL is the Microsoft Visual C Run Time Library. It is a normal process that runs in Windows.
After searching Google for this I found out that this DLL is the Microsoft Visual C Run Time Library. It is a normal process that runs in Windows.

This is a small taste of what memory forensics is. It is a growing field and the more complex hacking attacks get the more rouge processes may be located in memory. Thanks for reading!

Rob’s Toolbox: md5sum and sha256sum

Greetings everyone, in this post I’ll be discussing the facts and importance of hashing. Hashing is the process of changing a string of characters into a fixed length value. This process is useful for digital forensics as well as for storing passwords on computer systems. When a user account is created on a computer system the operating system does not store the clear text password (i.e. not the password the user typed in. For example if a user set password as his password the operating system does not store the word “password”). Instead the operating system takes the typed in password and hashes it using a hashing algorithm. After the clear text password is put through the hashing algorithm a hash is produced. This hash is stored by the operating system. When the user attempts to log into the system the password the user types in is hashed then the hash of the typed in password is compared to the stored password hash that was made when the account was created. If the hashes match then the user is granted access.

Hashing is also used in digital forensics, when evidence is taken a copy of the original evidence is generated for examination. This “working” copy must be exactly the same as the original. The way to confirm if this is true is to use hashing. First the original evidence is hashed then the copy is hashed. If the hashes match then they are exactly the same bit for bit. With hashing when a file is even slightly changed the resulting hash will be radically different than before. (I will show this in the demo later in this post).

There are two main hashing algorithms being used in digital forensics:

  • MD5
  • SHA-256

The MD stands for message digest; this algorithm creates a 128 bit (16 byte) hash value when used. This value is sometimes shown as a 32 digit hexadecimal number.

SHA stands for secure hash algorithm; SHA-256 creates a 256 bit (32 byte) hash value. This value is sometimes shown as a 64 digit hexadecimal value.

For more information on MD5 and SHA-256 visit these pages:

These hashing algorithms are not reversible. Meaning if the hash is known it there is no way it can be changed back into the file it was computed from.

Using an Ubuntu linux system I will demo how the tools are used.

The tools that I will use are called md5sum and sha256sum. Both md5sum and sha256sum are included in the Linux coreutils program package and are usually installed by default.

First I create a test file.
First I create a test file.
I used the md5sum program to calculate the md5 hash of the test file. This is the digital fingerprint of the test file. The hash is also known as the checksum.
Next used the md5sum program to calculate the md5 hash of the test file. This is the digital fingerprint of the test file. The hash is also known as the checksum. The random string of numbers is the checksum of the test.txt file.
Next I use the sha256sum program to calculate the SHA-256 hash of the test file. The output is pretty much the same as the md5sum program. The checksum is longer than the md5 checksum.
Next I use the sha256sum program to calculate the SHA-256 hash of the test file. The output is pretty much the same as the md5sum program. The sha-256 checksum is longer than the md5 checksum.
To show that the checksums will change if the file's content is changed I'm going to slightly change the content of the test file.
To show that the checksums will change if the file’s content is changed I’m going to slightly change the content of the test file. I used the nano text editor to do this. I changed the first letter in the test file from a capital t to a lowercase t.
Lastly I take the hashes of both the original file and the altered file. Notice how both hashes changed. This shows that the file's content has been changed.
Lastly I take the hashes of both the original file and the altered file. Notice how both hashes changed. This shows that the file’s content has been changed. The blue rectangles are the original file’s hashes and the yellow rectangles are the altered file’s hashes.

Because the hashes change when the file’s content is changed this makes hashing incredibly useful if not vital to digital forensics. The original evidence as well as the evidence that is examined (the working copy) cannot change at all. If it does then the case can be thrown out. Hashing is used to make sure that changes do not happen to any of the evidence during the course of an investigation and a case. Thanks for reading.

Allocated and Unallocated Space: How Computers Store Data

I remember way back about 12 years ago I got my first computer. It was an HP Pavilion desktop. I stored my music on the machine and one day I accidently deleted one of my music tracks from the hard drive. At the time I didn’t have a CD of the track so it was lost for good it seemed.

Fast forward 12 years later, I still have the computer from 12 years ago and one day I decided to put my digital forensics knowledge to use. I removed the hard drive and imaged it. Using the imaging program I performed a triage on the hard drive and poked around to see what was on it. I was not surprised to see the music track that I thought 12 years ago was gone for good. During my forensics training I learned that deleted data may not be gone from the hard drive for good. So I used the imaging program to recover the data and all was well. So how do computers store data and why can the data still be there when it is deleted?

When a file is created on a hard drive the operating system needs to allocate space for that file. With NTFS (New Technology File System) formatted hard drives there are two ways that the operating system searches for unallocated space, I’ll describe one of them.

One of the ways Windows searches for unallocated space to allocate to a file is it will comb the hard drive and the first set of unallocated space that it finds that is big enough to accommodate the size of the file will be allocated to the file. Then the file’s data will be placed into that space. Here’s an analogy:

A family of three enters a theater and they need to find three seats to accommodate them. So they search for the first three seats that are next to each other and empty. The empty seats are the unallocated space, seats that are taken are allocated space and the family is data. When the family finds the seats they sit in them and seats are allocated to the family.

When a file is created and space is allocated to the file a file name is chosen by the user to identify that file. This file name is used by the operating system to find the file’s metadata entry. Metadata is data about data. An example of metadata is when you create a document in Microsoft Word usually the file has a creation time, modified time, author, and file size. This is the word document’s metadata. Once the metadata entry for the file is found the metadata entry points to the file’s content, the content is just the file’s actual data. So when you double click on a document to open it the operating system boots the program that will view the file then uses the file name to find the metadata entry then the metadata entry points to file’s content and the content is displayed in the viewer.

When a file is deleted from a computer is it truly gone for good? It depends. When a file is deleted from a computer (say by right clicking on the file and clicking delete) all the user is doing is telling the operating system to lose track of the file and unallocate the space that was given to that file. The file’s data is still there. It’s kind of like ripping out an index entry in a book, the index may be gone but the chapter is still there. The only time a file is truly deleted from a computer is if the space the deleted file is on is overwritten by another file or if a forensic cleaning program is used to wipe the unallocated space. Once a file is deleted even though the data is still there the operating system cannot recover the data on its own. Special programs need to be used to find the deleted data.

To show the concept of this I’ll do an experiment using one of my thumb drives.

First I have to create some test files.

Creation of the first test file

Creation of the second test file

Creation of the third test file

After that I confirm with both the GUI and the command line that the three files are on the thumb drive.

Both the GUI and the CLI showing the three files

Next I delete two of the test files.

Before deleting two files

Both the GUI and the CLI showing that two files have been deleted

Both the GUI and the command line show that two of the test files have been deleted. From here Windows on its own cannot recover the files even though they are still present on the hard drive. To show that the files are still there I’m going to use some forensic techniques.

First I image the thumb drive.

Imaging the USB

Next I import the image file into the Autopsy forensic browser and display the files that are contained within the image file.

Autopsy showing the deleted files

The files with the red names are the files that I have deleted. The content is still there but the space that it is on has been unallocated so another file’s content can take up the space.

So with this still be careful when you go to delete something. Make sure you really want it gone. But at least there is still hope for getting the data back. Thanks for reading!

A mock case of IP theft

Greetings everyone. This post is going to be a mock digital forensics case and how I would go about answering the questions about an event that takes place on a computer system. First I’ll give you the case details:

XYZ corp has contacted me about an attempted cyber theft of sensitive company information. They believe that an administrator who works for the company is involved in the theft. They confiscated a personal USB drive that belonged to the employee in question. They believe this USB was used to steal the sensitive information. My job will be to confirm that the information is on the USB drive and that the USB was plugged into the work computer that contains the company’s information. I was told that the sensitive files are on his work computer and they have the words “secret” and “confidential” in their file names.

There are several questions I need to answer about the case:

  • Is the stolen data on the USB drive?
  • When was the data stolen?
  • When was the last time the USB drive was plugged into the computer?
  • What user account was logged into the computer at the time the data was stolen?

So the first step that I would take would be to take images of both the computer and the USB drive.

I used dd to take the image of the USB drive.
I used dd to take the image of the USB drive

Next I took a live image of the xyz computer.

I changed the power settings for both the machine being imaged and the forensic machine performing the imaging. I didn't either machine to go to sleep which the imaging was taking place.
I changed the power settings for both the machine being imaged and the forensic machine performing the imaging. I didn’t want either machine to go to sleep while the imaging was taking place.
Here is the settings I used for taking the image of the xyz computer. I didn't want to deal with a bunch of fragmented image files so I set the fragment size to zero.
Here is the settings I used for taking the image of the xyz computer. I didn’t want to deal with a bunch of fragmented image files so I set the fragment size to zero.
When the imaging finished FTK Imager automatically started to hash the image file and verify the hashes.
When the imaging finished FTK Imager automatically started to hash the image file and verify the hashes.
Both the MD5 and SHA-1 hashes verified. Now Im ready to prep both pieces of evidence for examination.
Both the MD5 and SHA-1 hashes verified. Now I’m ready to prep both pieces of evidence for examination.

The images I took above are the “best” evidence. A best practice is to never examine the original or “best” evidence. So in order to get the image files over to my forensic system I have two choices:

  • Copy the image files over using a normal copy method like drag and drop
  • Take an image of the best evidence and use that image as the “working” evidence or the evidence to be examined

I chose option two because with taking an image I’ll know for sure that the copies will be exactly the same bit for bit. With the drag and drop copy I won’t be sure if the operating system will make changes to the evidence.

Imaging working copy of xyz corp computer
So I took my forensic hard drive that contained the original evidence and mounted it to my forensic system. Then I rehashed the xyz computer image and took an image of the best evidence using the dcfldd tool.
Next I took a second image of the USB drive
Next I took a second image of the USB drive to use as the “working” evidence”
After both working copies were made I hashed both of them and compared them to the original evidence.
After both working copies were made I hashed both of them and compared them to the original evidence.

With both working copies made and the hashes checking out I move on to the examination of both pieces of evidence. The first question I want to answer is if the stolen data is on the USB drive. I have two ways of confirming this:

  • Mount the drive to the forensic system and see if the data is on the drive
  • Use the Autopsy forensic browser and run a keyword search

I decided to use Autopsy to run a Keyword search. Because I know that either the words “Confidential” or “Secret” is in the file names. I ran a search for both of these keywords.

Keyword search using Autopsy
Searching the USB for the word “confidential” on the USB drive
Search results for the keyword "Confidential"
Search results for the keyword “Confidential” on the USB drive
Searching for the keyword "secret"
Search results of Autopsy looking for the keyword “Secret” on the USB drive

So far these search results tell me that four hits were found for “confidential” and 3 hits were found for “secret”. This is a good indication that the stolen files are on the USB drive.

I did not want to base the answer to the question on the keyword search results alone so I used Autopsy to perform file analysis on the USB drive’s contents. This option will give me a list of what files are on the drive, if they are deleted or not, the file’s timestamps, and which metadata entry points to the file.

All of the stolen files are found. This answers the first question of the case.
All of the stolen files are found.

With this the first question of the case is answered. The stolen files are on the USB drive. There is something odd with the timestamps however. The time values in the yellow box are the written timestamps and the time values in the red box and the created timestamps. Under normal circumstances the creation time would be before the written time. But this clearly says the the last written time is before the created time. This is a clear indication that the files that were stolen were created on a different machine and moved to the USB drive. So the created time values are the times when the file’s were created on the USB drive. So each file’s creation time is when the file was stolen. This answers the second question.

  • Confidential file # 1
    • Stolen on 11/30/2014 at 13:06:11 EST
  • Secret File 1
    • Stolen on 11/30/2014 at 12:41:43 EST
  • Secret File 2
    • Stolen on 11/30/2014 at 12:41:43 EST
  • Secret File 3
    • Stolen on 11/30/2014 at 12:41:43 EST

Now that I have some time values I can check the computer image and see who was logged in at the time the files were stolen. Also I will check when the USB drive was plugged into the computer. I mounted the computer image file to my forensics system and ran a program that extracts data from the Windows registry. The program is called regripper. The registry is a series of database files that contain configuration information for the operating system. With Windows the registry is split into five hives:

  • Sam
  • Security
  • System
  • Software
  • NTUSER.DAT

Each user account on a computer has an NTUSER.DAT registry hive that is associated with it. The hives that contain the information I need to learn about the USB drive are located in the Software, System, and NTUSER.DAT hives. I first decided to rip the information from the System hive.

I used the losetup command along with the mount command for mounting the image file.
I used the mmls, losetup command, and  the mount command to mount the image file.
I used regripper to rip the information from the system hive. From this information I found the last time the USB was plugged into the computer
I used regripper to rip the information from the system hive. From this information I found the last time the USB was plugged into the computer

So this answers the third question: The USB was last plugged into the computer on Dec 2, 2014 at 01:09:07 UTC. Registry times are in UTC time or Zulu time. Since this computer was located on the east coast the time (which is 5 hours behind zulu time) is Dec 1 2014 at 22:09:07 EST. This is the last time the USB drive was plugged into the computer. Next I ripped the Software and the NTUSER.DAT registry hives for more information about the USB drive itself. I was able to find out several things about the USB drive from these hives:

  • Serial number
  • USB Vendor
  • Vendor ID
  • Product ID
  • Last drive letter the USB drive was assigned
  • Volume GUID (Globally unique identifier)
  • The user account which was logged in when the USB was plugged in

Once I found out the volume GUID I used this information to find out which user account was logged on when the USB was plugged in.

Once I ripped the NTUSER.DAT hive I searched for the volume GUID. Since the GUID is found it confirms that the account associated with this NTUSER.DAT hive was logged in when the USB was plugged in.
Once I ripped the NTUSER.DAT hive I searched for the volume GUID. Since the GUID is found it confirms that the account associated with this NTUSER.DAT hive was logged in when the USB was plugged in.

Now the final question is answered. This NTUSER.DAT hive belongs to the Admin account on the computer in question, so the Admin account was logged in when the USB drive was plugged in.

After the examination I would report to my mock client that I found evidence that the Admin account was logged in when the USB drive in question was plugged into the computer. Also that the sensitive company information was found on the USB drive. There was no need to find out if his account was compromised due to the fact that the suspect was seen plugging in his personal USB drive into the computer at the time of the theft. So with this evidence xyz corp woud make a decision based on the facts.

In the world of information security any number of cyber crimes can be committed against a person or an organization. This is one example of what can happen to a company. With that said always be careful with what you put on the internet. Thanks for reading!

Acquisition: How to use three of my favorite tools

In my last post I talked about some of the acquisition tools that are available to use for imaging evidence. This post will demonstrate how to use the tools I mentioned: dd, dcfldd, and FTK Imager.

For dd and dcfldd I’ll be using the SANS SIFT kit and for the FTK Imager demo I’ll by using a Windows 7 machine.

First let’s start with dd:

With the dd command i need to know the location of the mounted USB device that I'm going to image. The mount command will show where the USB device is in the Linux filesystem.
With the dd command I need to know the location of the mounted USB device that I’m going to image. The mount command will show where the USB device is in the Linux filesystem. The third line before the last line says: /dev/sdc1 on /media/Thumb Drive This is the device I’m looking for. /dev/sdc1 is where the USB device is located within the Linux filesystem.
Now that I know the location of the USB devide I can start the imaging process. In this screenshot I invoked the dd command to image the USB bit for bit and to send the image file to a location of my choosing.
Now that I know the location of the USB device I can start the imaging process. In this screenshot I invoked the dd command to image the USB bit for bit and to send the image file to a location of my choosing.

I’ll break down the command: First I have sudo, this command allows me to run a command as a different user. In this case I’m running this command as the root user. This user has privileges to make changes to the system. This is required because root access is needed to use the /dev/sdc device. Next is dd, this is the invocation of the dd command. Next is if=/dev/sdc. This is telling dd that the input file is the /dev/sdc device. Notice that I put /dev/sdc not /dev/sdc1. The reason for this is because the 1 is the first partition of the USB drive. I want to image the entire drive so I have to take out the 1 and that will allow dd to image the entire drive front to back. After if= is bs=, this is the block size. The block size tells dd how many bytes to convert at one time. The default block size is 512 bytes. This can be changed to a larger size but it may affect performance. Typically I use the block size of 4096 bytes or 4KB. The last part of the command is of=ntfs_usb1.dd. This is the where the output of the dd command is going to be placed. Because I only have the name of the file rather then the full path of the file, the output of the dd command will be placed inside of the file and that file will be placed inside of the current working directory. Notice the the file name ends with the dd extension. This is a raw file, literally ones and zeros. It can not be read by normal means. Forensic software has to be used to be able to view its contents.

dd image completion
This screen will show after the dd command has completed imaging the USB drive.

After imaging to file I take MD5 hashes of both the USB drive and the image file to make sure that the image file is exactly the same as the USB drive.

md5 sum of original and image
Notice that the random stings of numbers and letters before ntfs_usb1.dd and /dev/sdc are exactly the same. This verifies that the USB drive and the image file are the same.

Next is dcfldd, this program is almost identical to the dd command:

Using dcfldd to take an image
The only differences between the dcfldd command the dd command shown above is dcfldd after sudo, that’s the invocation of the dcfldd program, hash=md5 (I’m telling dcfldd to use MD5 as the hashing algorithm for image verification), and md5log=md5hash.txt (I’m telling dcfldd to send the md5 hash it generates to a text file named md5hash.txt)

Notice that dcfldd shows what it has copied so far.

After imaging is complete the same output screen as dd will show.

dcfldd image completion

After dcfldd completed imaging the USB drive I took a MD5 hash of the USB drive and compared it to the hash the dcfldd generated during the imaging process.

md5 hashes of image file and original
Both hashes match

The last tool is GUI based and has far more options then the command line tools used above.

After starting FTK Imager here's the screen that you will see.
After starting FTK Imager here’s the screen that you will see.
Click on create image
Click on create image
Select the source of the evidence. In this cases it's a physical drive.
Select the source of the evidence. In this case it’s a physical drive.
Next select which drive to image
Next select which drive to image, the drop down list will have all of the drives that are connected to and recognized by the system.
After drive selection
Next a destination for the image has to be specified. Click add.
Select which format the image is going to be. In my case I chose Raw (dd)
Select which format the image is going to be. In my case I chose Raw (dd)
Next FTK Imager will ask you to fill in some case information.
Next FTK Imager will ask you to fill in some case information.
Next select a destination for the image file.
Next select a destination for the image file. I choose to place the image file on the desktop. Also notice the image fragment size. FTK Imager can split the image file into multiple pieces based on what size is placed in the fragment box. If the size is zero then FTK Imager will not fragment the image file. The image file can also be compressed and encrypted.
After all of the options are selected click start to begin the imaging process
After all of the options are selected click start to begin the imaging process
FTK Imager will display the current progress of the imaging
FTK Imager will display the current progress of the imaging
After imaging is complete FTK Imager will show hash reports and other data related to the imaging process. The most important thing is to make sure that the hashes match.
After imaging is complete FTK Imager will show hash reports and other data related to the imaging process. The most important thing is to make sure that the hashes match.

So here are the three tools that I use the most when it comes to forensic imaging. I hope you enjoyed this post. My next post will be a mock case where I will go through the first two steps of the forensic process: acquisition and examination. Thanks for reading!

Acquisition: Storing the evidence and imaging tools

In the previous post I discussed some of the first steps in the acquisition process. Finding the physical or digital evidence at the crime scene, starting the chain of custody, recording when change of control takes place on the chain of custody document, image hashing, and making the copy of the original or best evidence to use for forensic examination. The only task left in the acquisition process is storing the original evidence. In this post I’ll also introduce some acquisition tools and describe some of their features.

Depending on whether or not the best evidence in a case is digital or physical the best practices for storing that evidence will change how the original evidence should be stored. If a physical hard drive is the original evidence then the usual storing method is to place the hard drive on a shelf in a climate controlled room. There are several problems with this method. Original evidence can sit in storage for years before it is called upon for a case. This can lead to the hard drive breaking down while it is in storage. If this happens then the evidence will be changed and the case will most likely be thrown out. With physical hard drives there is not much that can be done to fix this. However with digital evidence measures can be taken that can safeguard it from these problems. The best thing to do with digital evidence is to upload it to a managed RAID system that has regular backups done. (RAID stands for redundant array of independent disks. This type of system is designed to be a more robust type of data storage.) Another method is to have offsite backups of the evidence done. The main copy can be in a computer system at the police station and the backup can be at a separate location for example. If disaster strikes the main location and the main storage system is damaged or destroyed the backup can be used.

There are multiple disk imaging tools to choose from, some use the command line and others use the GUI (Graphical user interface). Let’s start with one of the oldest tools still in use: dd.

dd is a command line tool that is used to capture forensic images from hard drives, USB drives, and other forms of media. dd stands for data description; others may believe that dd stands for data dump. I’ve heard both terms being used so I interchange them; they both refer to the same tool. Dd is built into the Unix operating system, is part of the GNU Corutils package, and has many features:

  • Forensic image creation
  • Drive wiping
  • Data copying

Dcfldd is an upgraded version of the dd program that was created by the US Department of Defense Computer Forensics Lab. Dcfldd has many more features than its dd counterpart:

  • Hashing of the data on the fly
    • Meaning that while the imaging is in progress the program is creating a hash
  • Displays progress of the imaging process
  • Imaging bit for bit verification
  • MD5 and SHA-256 hashing of data

FTK Imager is a GUI based tool made by Access Data. FTK Imager can be run from a forensic system or from a USB drive. This tool has a plethora of features:

  • Forensic image creation
  • Memory image creation
  • Local file system mounting
    • This feature will allow the examiner to take a peek at what’s inside the hard drive and determine if further examination is needed
  • Image mounting
  • Deleted file recovery
  • Hashing of the imaged media
  • File and folder exporting from forensic images

These are three great tools that can be used to acquire forensic images in the field. In my next post I’ll show how to use each of these tools. Thanks for reading.