foundations of file system analysis chapter 4: data ... · chapter 4: data acquisition and...

Lecture Computer Forensics

Chapter 4: Data Acquisition andFoundations of File System Analysis

Harald Baier

Hochschule Darmstadt, CASED

WS 2011/2012

Harald Baier Securing Phase/FS Foundations / WS 2011/2012 1/44

Data Acquisition

File System Analysis

The Reference Model of Carrier


Data Acquisition




Data Acquisition




Data Acquisition

Introduction

1. We distinguish betweenI Live system analysis

I Dead analysis

2. The dead analysis is more common to acquire data

3. One of the most important phases during a forensicinvestigation

I Not collected data may be lost ⇒ Not recognised as evidence!

I Not properly collected data has a reduced expressiveness

4. During data acquisition an exact (typically bitwise) copy ofstorage media is created


Data Acquisition

Dead versus Live Acquisition

1. A dead acquisition copies the data without the assistance ofthe suspect’s (operating) system

2. A live acquisition copies the data using the suspect’s(operating) system

I Risk: During the data acquisition an attacker can modify dataor software can produce tampered data⇒ The image has no evidence

I Should live acquisition be avoided?

3. If you work on a suspect’s system you should boot/use trustedtools (e.g. CD, USB stick):

I Take care to not mount drives or modify data.

I Consider: A suspect may have modified the hardware so that itreturns tampered data


Data Acquisition

Reading the Source Data (1/2)

Two methods to access data on a storage medium:

1. Direct access of software to the hard disc controller:I OS or acquisition software accesses the controller.

I The controller communicates with the disc.

I Software must be able to address controller and to issuecommands to it (e.g. read commands).

2. BIOS access:I OS or acquisition software accesses the hard disc through the

Basic Input/Output System (BIOS) hard disc services.

I Interrupt command 0x13 (INT13h function): Category offunctions to read, write, ... to hard disc:

I Original INT13h addresses via CHS: Max. 8 GiB.

I Extended INT13h addresses via 64-bit LBA: Max. 2 TiB.


Data Acquisition

Reading the Source Data (2/2)

Two tools using different disc access methods to determine the disc size. The BIOS is not properly configuredand returns a false disc size

Source: Brian Carrier, p. 44

1. With a false disc size the end of the disc will not copied.

2. It is useful to identify the size through different methods.

3. Assure that you know what access method the tool uses and ifit reports the correct disc size.


Data Acquisition

Error Handling

1. An acquistion tool MUST be able to handle read errors.

2. Sample error sources:I Physical problem where the storage drive no longer works

I Limited number of HDD blocks are damaged

3. General behavior to handle errors:I Log the addresses of damaged sectors

I Writing 0s for not readable data⇒ Further data is at the correct location

General error handling of acquisition tools


Data Acquisition

Write Blockers (1/4)

General:

I Allow acquisition of data from a storage device withoutchanging the drive’s contents.

I Write commands are blocked.

I Only read commands are allowed to pass the write blocker.

I Types of Blockers:I Hardware Write Blocker

I Software Write Blocker


Data Acquisition


Hardware Write Blockers:I The device sits in between investigator’s PC and storage

device.

I Supported storage interfaces are ATA, SCSI, Firewire (IEEE1394), USB or SATA.

I The controller cannot write values to the command register,which writes or erases data on the storage device.

Read Command Write Command

Source: File System Forensic Analysis by Brian Carrier


Data Acquisition


Software Write Blockers (SWB):

I A software layer that sits in between the OS and the devicedriver for the storage device.

I Prevents all disc requests that use sysem calls to write data tothe storage device.

I Be careful: Some SWB may allow direct disc access (INT13h).

Without Software Write Blocker With Software Write Blocker

Source: File System Forensic Analysis by Brian Carrier


Data Acquisition


Software Write Blockers (SWB):

I Choose known SWB that are often used

I The SWB should not modify a read-only disk

I The SWB is designed to prevent any operations on datastorage media that are not write protected

I Before the use of SWB on the target system, evaluate theseon a test system and practice the use

I SWBs:I ReadOnlyMounter (Mac)

I ForensicSoft, Safe Block (Windows)


Data Acquisition

Writing the Data to an Image: Destination location

1. Data can saved directly to a disk or to a file.

2. To disc:I The destination disc must be wiped with zeros before the

acquisition starts.

I The destination disc must not be mounted in the acquisitonsystem.

3. To file (e.g. image.dd):I The file can be saved on a hard disc or other storage media.

I An image has the advantage not to be automatically mountedin the acquisition system.

I Fragmentable in many smaller pieces to fit onto storage media.


Data Acquisition

File Format of the Image

1. Raw ImageI Includes only data from the suspected storage media

2. Embedded ImageI Includes data from the suspected storage media and additional

data about the acquisition (e.g. hash values, dates, times)

3. Raw Image and external file with additional data

Kinds of image file formats

4. Depending on the used tool the image can be compressed


Data Acquisition

Acquistion Tool dd (1/2)

1. dd reads block-sized chunks from the source media and writesit to an output file.

2. Imported flags:I Default block size: 512 bytes

I Source (file or drive) flag: ’if=’

I Destination (file or drive) flag : ’of=’

I Block size flag: ’bs=’I Take care of the block size: 1M means 1 MiB = 1024 * 1024

bytes. 1MB means 1000*1000

I Count flag: ’count=’

I Skip flag: ’skip=’


Data Acquisition

Acquistion Tool dd (2/2)

1. Imported flags:I Conversion flag: ’conv=’

I noerror: Do not stop when facing input / output errors

I sync: Pad input blocks with NULL (this keeps the offsetwithin the image in presence of errors)

I notrunc: Do not truncate the output file.

2. e.g.: # dd if=file1.dat of=file1.dd bs=512 skip=1000count=100 conv=noerror


Data Acquisition

Data Acquistion over Network

1. Possible to create an image file over networkI Transmitting data from source media over network and write

data to file

I Compressing is useful

2. How to:I First, the target computer (IP address 192.168.0.11) is

prepared for the reception of dataI netcat -l -p 9000 | dd of=file.dd

I If the target computer is ready to start the transmission on thesource computer is started

I dd if=/dev/hda | netcat 192.168.0.11 9000


Data Acquisition

Hash Values

1. Calculate hash values for evidence to prove the integrity of theimage

2. Is used to demonstrate the accuracy of data acquisition andthat the data acquisition did not change the original storagemedium

I Calculate hash from original media before acquisition starts

I Calculate hash from image after the data acquisition

I Compare both values

I e.g. sha1sum file1.dd



Data Acquisition





Basics of file systems (1/2)

1. General goal: Hierarchical organisation of data fromI diretories and

I files

2. Classification of the data inI User Data

I Structural Data (adminstration of the User Data)

3. File systems are often independent of hardware or operatingsystem

I Windows on FAT or NTFS

I Linux on FAT, ext2/ext3/ext4, ReiserFS

I Android on YAFFS, ext4



Basics of file systems (2/2)

1. Knowledge of file systems allows:I Access to data (structure and user data)

I Reconstruction of events on the file system

I Without the help of the actual operating system

2. The interpretation of the contents of user data lies oneabstraction level higher

I Must be examined with special application tools

I Not part of the file system analysis



The ambiguity of the term ’block’

1. Data storage block:I Smallest addressable unit on the storage media

I Created by low level formatting

I Typical sizes: 512 byte (today), 4096 byte (near future)

I Many authors/programmes call it a sector.

2. File system block:I Smallest addressable unit of the file system

I Created by file system formatting (e.g. via mkfs)

I Typical sizes: 1024 byte, 2048 byte, 4096 byte

I In this lecture: FS-Block

I Windows notation: Cluster



The ambiguity of the term ’address’

1. Logical partition address / device address:I Address (LBA) of the data storage block relative to the

beginning of the partition

I Unit: Data storage block / sector

2. Logical file system address:I Address of the FS-Block relative to the beginning of the file

system

I Unit: FS-Block / cluster

3. Logical file address:I Address of the data block relative to the beginning of the file

I Unit: FS-Block / cluster



Data Acquisition





Abstract reference model for file systems

1. Five categories of data:I File system data

I Content data

I Meta data

I File name

I Application data of the file system

2. Advantage:I Simplify comparison of file systems

I Allow abstract description of procedure for analysis

3. Disadvantage:I Reference model does not fit always



File system data

1. File system data provides general information about theorganisation of the file system.

2. Typical information:I Length of a filesystem block (e.g. in bytes, HDD blocks).

I How big is the file system?

I Which file system blocks are allocated?

I Where to get further information about the file system?

3. File system data (or at least some of it) are at the ’beginning’of the file system (boot sector and where applicable a fewmore HDD blocks).



Content data

1. Content data stores the actual content of the filesI Typically largest part of the file system.

2. Allocated in FS blocks:I Not to confound file system block and HDD block

I In Windows: Cluster.

I In Linux/UNIX: Block.

I Brian Carrier: Data Unit.

3. FS blocks of content data are allocated or not.



Meta data

1. Meta data = data about dataI Meta = About, behind, beside

2. Typical information:I Location of content data (different strategies)

I Size of the file

I MAC timestampsI Last change Modified M

I Last read access Accessed A

I Deletion / creation Created C

3. Examples: UNIX inodes, FAT directory entries



File name and application data

1. File name:I Typically provides connection between the external name (for

users) and internal names (e.g. inode)

I Usually stored in file directory

I Analogy: URL ⇔ IP-Address

2. Application data of the file systemI Not required for core functionality of the file system

I Typically provides useful features:I File system journal

I Quota statistics



Essential vs. non-essential data

1. Term distinction by Brian Carrier:I Essential file system data are those that are needed to save

and retrieve files

I Non-essential file system data are there for convenience andnot needed for the basic functionality

2. Examples:I Essential ?

I Non-Essential ?

3. Reliability of essential / non-essential data?



Analysis of file system data

1. Critical file system data are typically housed in the first datastorage blocks of the disc partition

2. Provides information on:I Type of file system

I Location of further information about the file system

I Trusted (because essential) data:I View with hex editor (e.g. xxd) or tool from TSK (fsstat)

3. Don’t forget the Volume Slack:I Unused disc blocks behind file system

I Potential location for hidden information



Analysis of content data: Allocated blocks

1. Create a file:I Data blocks are allocated

I Associated data blocks are assigned marked to the file system

I Allocation algorithm depends on the file system and OS

2. Deleting a file:I Often, only the references file name ⇒ Meta data deleted

I Data blocks are marked as unused

I Result: Data remains unchanged on storage media



Analysis of content data (1/2)

1. Search with the help of meta data:I If meta data is still available (in particular the references to

data blocks), analysis is relatively simpleI Readout data blocks ⇒ to a new file

I Afterwards analyze on file level

I Otherwise, string search, jigsaw technique ..

2. String search for key wordsI ASCII string (e.g. e-mail address, telephone number)

I File management string (’signatures’ e.g. in pdf, image, officefiles): File header / footer ⇒ carving

I Basic problem: The fragmentation of data



Analysis of content data (2/2)

1. Basic Problem: Fragmentation of dataI Data is usually stored in multiple FS blocks

I The locating of a string that goes over block boundaries ispossibly difficult to find.

I Reference test of Computer Forensic Tool Testing (CFTT):www.cftt.nist.gov

2. Search on unassigned data blocks

3. Access data blocks with tools from TSK:I xxd: Hex editor (e.g. used in pratical)

I dcat, blkcat: Access data blocks via their physical address /FS address.



Content data: File Slack (1/3)




1. File slack:I Memory area from EOF to the end of the final allocated FS

block.

I Background: Actual file size, and allocated space on the harddisc do usually not coincide.

I Consists of RAM slack and drive slack.

2. RAM Slack:I Memory area from EOF to the end of the current data storage

block

I Was described by DOS and older Windows versions withcontent from buffer memory (= RAM data)




1. Drive Slack:I ’Rear’ completely unused data storage blocks

I Their bit patterns typically remain unchanged

2. Example:I Data storage block size: 512 byte

I FS-Block size: 4096 byte

I Text file of 26 byte is stored

I File Slack: byte to byte

I RAM Slack: byte to byte

I Drive Slack: byte to byte



Content data: Secure deletion of files

1. Depending on your operating system there are many tools:I PGP for Windows

I shred for Linux: Overwrites all data blocks completely andseveral times with different byte patterns



Content Analysis: Problem encrypted files (1/2)

1. Encryption at various levels:I File encryption at the application level

I Encryption at the file system level

I At the hardware interface

2. File encryption at the application level:I Example: PGP and GnuPG

I Often the decryption key is derived from password

I In general, brute-force attack on password:I Weak password ⇒ data reconstructed

I Typically, metadata are present in plaintext



Content Analysis: Problem encrypted files (2/2)

1. Encryption at the file system level:I Examples: TrueCrypt, EFS / BitLocker (Windows), DM-Crypt

(Linux)

I Sometimes file system data are present in plaintext

I Decrytion as with file encryption

2. More promising approach as a brute-force attack:I Live analysis of the RAM

I Search for decryption keys in memory

I Techniques: dump of the RAM, Cold Boot



Analysis of the file name

1. File deletion strategies:I File system sets entry in the listing on unused:

I File name and the reference to meta data is preserved

I Very simple reconstruction

I File system keep up file name, but set the reference tometadata entry to ’0 ’

I With chronological assignment of metadata entries ⇒ Easy toguess metadata for a deleted file

I Caution: Shared data blocks can again be described

2. Search for keywords in file names



Analysis of the meta data (1/2)

1. Metadata can be used or unusedI With the deletion of a file meta data are often released

I Tool ils shows all the used and re-released metadata entriesof a listining (e.g. ils can list inode information and collectinodes of deleted files)

I Typical usage: ils -a image

2. Afterwards access to the meta data themselves:I istat tool shows the contents of metadata

I Typical Usage: istat image inode

I Then time stamps of the file as well as addresses of the datablocks are known.



Analysis of the meta data (2/2)

1. Evaluation of the Timestamp: TimeliningI Chronological analysis of access / change time

I Provides important clues for action of the attacker

I Caution: Timestamps are not essential data

2. Evaluation of data blocks:I Direct view or write out

I Analysis at the application level

I Don’t forget the file slack



Analysis of application data (1/2)

1. Typically, only journal analysis

2. Journal holds last performed modifications of the file system:I More efficient recovery after a crash

I At boot time the journal will be tested against the file system

I If nessesary changes are brought in

3. Journal analysis needs further research

4. Tools from TSKI jls: Applicable for FAT, NTFS, ext2/ext3, ISO9660

I jcat: Displays blocks in the journal



Analysis of application data (2/2)

1. jls [-f fstype] image


foundations of file system analysis chapter 4: data ... · chapter 4: data acquisition and...

Documents