Identify File System Characteristics

Published Date: 02 Nov 2017

Introduction

This exercise contributes to the deliverable 1.2 – Technical Report of the coursework assessment. The exercise comprises of three parts:

Analyse a NTFS file system in order to establish a number of characteristics about the file system.

Analyse the file system as it has been quick formatted where you are to recover file metadata in order to identify files that were present in the file system.

A short research based exercise requiring you to do some background reading.

To complete this exercise you need to download the file CWK_1_2_2_NTFS.E01 digital evidence file from week 15’s topic on the module’s moodle webpage. Create a new case in EnCase and add this digital evidence file to the case.

1. Identify file system characteristics (weighting 0.2).

NTFS like FAT has a boot sector where they share a number of the same items of data in approximately the same locations. Using the table on this webpage, http://www.ntfs.com/ntfs-partition-boot-sector.htm, find the following items of data in the NTFS boot sector (not the MBR).

Number of sectors per cluster.

Number of sectors in the reserved area.

The media type of the storage device that has been formatted with FAT.

Sectors per track in storage device.

Number of head in storage device.

Total Sectors

Logical cluster number for where the $MFT file starts

You need to state whereabouts in the file system you found these items of data. You are to use the GPS to give you this information. Complete the following table with your answers:

Item

GPS

Value (give both the hexadecimal and decimal value)

1

PS 63 LS 0 CL 0 SO 013 FO 13 LE 1

04h

2

PS 63 LS 0 CL 0 SO 014 FO 14 LE 4

00 00 h

3

PS 63 LS 0 CL 0 S0 021 F0 21 LE 1

F8 = FIX DRIVE

4

PS 63 LS 0 CL 0 S0 024 F0 24 LE 2

300 = 63 HEX

5

PS 63 LS 0 CL 0 S0 026 FO 26 LE 1

04 LITTLE INDIAN = 40hex = 64 dec

6

PS 63 LS 0 CL 0 S0 028 F0 28 LE 1

3F HEX = 63 DEC total

63 SECTORS

7

PS 697575 LS 697512 CL 174378 S0 000 FO 0 LE 1

00 00 00 00 00 02 A9 2A BIG ENDIAN

For item 7, the Logical Cluster Number for the file $MFT, confirm this is the case by finding the $MFT in the Table view and checking the $MFT file’s GPS position. Write the GPS data below:

PS

LS

CL

SO

FO

LE

697575

697512

174378

000

0

1

2. Analyse NTFS and recover MFT records (weighting 0.5)

The digital evidence file, NTFS_CWK_1_2_2.E01, is of a NTFS formatted volume that has been quick formatted resulting in the file system metadata files being reset to a initial ‘empty’ state. As a result, any files that were present in the file system are now no longer listed when browsed using Windows File Explorer. However, quick formatting does not erase file data where this should still be present. Sometime also file system metadata such as MFT records may still be present although you can expect that others will be overwritten as a result of quick formatting. The result being you may be able to recover all files and a partial list of file system data such as filenames, timestamps, users, etc.

Using EnCase, perform an analysis to what files were present in the volume before it was quick formatted. In order to do this you need to work out how you will search for file system metadata for NTFS considering how file system metadata is structured and any identifying characteristics within that structure that will help you identify file system metadata from other data. You will also need to consider where you will target your search, e.g. what regions or clusters. Choosing incorrectly will result in either too many or no file system metadata being found.

For this exercise write a brief explanation on what you will do using EnCase to discover fragments of the previous file system metadata. You need to state:

What function in EnCase will you use to find the previous file system metadata.

What items you will define in EnCase in order to conduct a search to find file system metadata, e.g. keywords of file signatures or combinations of characters.

What options you select in EnCase when performing the search and what areas of the digital evidence file you will search.

The level of detail needs to be sufficient to allow another individual to repeat your analysis but not to the level of describing how to use the EnCase user interface. For example, you may define a keyword to search for some feature of file system metadata in a specific location such as $MFT. Your explanation would indicate you are performing a keyword search, state the characters/regular expression that makes up the keyword or keywords you are going to define in terms of the characters, numbers, symbols, etc. to search for as well as the options you would select for the keyword in EnCase, e.g. GREP, Ansi-Latin-1, UNICODE, etc., and why you have chosen those options. You also are to state the locations you are going to search and search options such as "Only selected keywords". You do not state how to select options in EnCase in terms of moving the mouse, clicking on menus and selecting sub options and so on.

Conduct your analysis and answer the following questions based on the results of your analysis:

State what version of NTFS has the file system been formatted to. To answer this you need to find the attribute and file that stores the file system version and state the data’s GPS location. Do not use the information displayed by EnCase when you add the digital evidence as the version, you have to find it within the digital evidence. Can you find any evidence of the version of NTFS used in the previous file system?

How many user created files were present in the file system before it was quick formatted. You need to discern old file system metadata from current file system metadata. Also you need to discern metadata you find about system files such as the MFT and LogFile from user files, where you can ignore analysing records you find for system files unless otherwise stated below.

Produce a list of filenames from 2 using the correct character encoding scheme. Include the full path to the file if it is stored in a directory. This also means you need to state which filenames you find refer to directories.

Obtain the modified, accessed and created timestamps for the files and write them down in human readable form.

Identify the logical size of each file.

Identify if the file data referred to by the MFT record is resident or non-resident. For resident file data, extract the file data using the correct encoding. For non-resident data, try to find where the data is stored in the file system, e.g decode the attribute that contains .

You will need to identify MFT records that define the above. For the MFT records you find for user files only show:

The GPS location of where the record is in the digital evidence.

A list of attribute types it contains, e.g. STANDARD_INFORMATION, FILENAME, etc.

The MFT record’s original record number. The number it was allocated in the MFT.

How much data is stored in the MFT record. That is the total number of bytes used for the header, attributes and trailer/end of record marker.

The id of each attribute. This is not the attribute’s type such as STANDARD_INFORMATION, FILE_NAME, etc.

Validate the length of the attributes against the data stored in the MFT record.

What are the flags have been set for the file, e.g. archive, hidden, system, deleted, etc.

What data is stored in the attributes, e.g. the filename in the $FILE_NAME attribute, where it is possible to state attribute data such a filename or clusters where file data can be found.

You need to state at a minimum the GPS data for the item’s location and the type of data at location, e.g. the logical size of the file is 1000 bytes and the location of the logical file size data is at GPS location PS 10000 LS 9000 CL 4000 FO 20 SO 020 LE 4 etc. Ideally you should identify the MFT attribute the data is defined in and give a breakdown of the fields in the attribute.

For MFT records confirm that they are valid by checking the fixup arrays defined in the record showing your results.

Finally, you should identify, in comparison to the example exercise and other records you find, the content of one record is significantly different. What you have to identify is the cause of this difference and what the user did to result in the record being different, e.g. create a file system object, delete a file system object, make a link to a file system object or something else.

3. Research exercise (0.3)

Microsoft has released a new file system called ReFS (Resilient File System). This file system is based on NTFS concepts but its metadata and data organisation is not the same as NTFS and cannot be interpreted by EnCase. EnCase is not able to show the file system structure in terms of a MFT or files or directories because the metadata is in a different format and possibly different location. The result is EnCase considers all of the sectors/clusters as unallocated where metadata and file data are all collected together.

Research into ReFS and find out:

File system characteristics in comparison to NTFS. That is what is the maximum size for a partition/volume, how many files can be on the volume, maximum size of a file, etc.

Function

NTFS

ReFS

Max number of files in a directory

No limit

2 power of 64

Maximum size of a single file

2 power of 64 = 18,446,744,073,709,551,616Bytes – 1

= 18,446,744,073,709,551,615Bytes

= 16EB

264 = 18,446,744,073,709,551,616Bytes – 1

= 18,446,744,073,709,551,615Bytes

= 16EB

Max size of a single volume

256terabytes

4.7zb zettabytes

Max file name length

unicode characters 32k

unicode characters 32k

Boot to file system

Yes

no

Max number of directories in a volume

No limit

2 power of 64

Maximum path length

32k

32k

Attributes

Yes

no

OBJECT IDs

Yes

no

Encryption

Yes

no

WindowsITPro. 2013. What features does NTFS support that ReFS does not support?. [ONLINE] Available at: http://windowsitpro.com/windows-server-2012/q-what-features-does-ntfs-support-refs-does-not-support. [Accessed 28 April 13].

Equivalent to the BOOT sector/Volume Boot Record details identifying, where possible, location of the BOOT sector, the size of the record, key fields such as number of reserved sectors, size of clusters (identify if ReFS uses the same term as cluster or uses a different name for an allocation unit), number of clusters, etc. Some of this data is available online, some of it has not been decoded by practitioners yet. What you have to do is find out what is currently known.

What are the file system metadata structures called identifying any key features. For example, if this research was about FAT then you would state in FAT there are the FAT tables and ROOT directory, giving an overview of the structure of each. If it were NTFS then you would state in NTFS there is the MFT and that comprises of MFT records of 1024bytes where each record comprises of a number of attributes. Find out about what the ReFS file system structures are called with any details you find.

For any specific data you find about the file system give an indication of if you believe the data is useful in a computer forensic examination. For example, you may find in your research that a specific location in the BOOT Sector/VBR is important to a computer examiner in finding file data. One way to make a judgement is to consider what you find in comparison to FAT and NTFS data. If the data is comparable to data in FAT or NTFS and that data (FAT/NTFS) is fundamental in an examination then it is likely to be useful in examining ReFS.

The word limit for the research exercise is 500 words.

State your sources using the Harvard Referencing system. If you are unsure about how to reference using the Harvard system, then seek advice from the Learning Centre.

Criteria

Part 1

Mark

Criteria

0

No attempt

1-29

Significantly incomplete or incorrect with no indication of how data was obtained.

30-39

Contains many errors with little indication of how data was obtained.

40-49

All data items found with minor errors and omissions.

50-59

All data items found with correct GPS data, minor errors in interpretation of values obtained

60-69

All data items found with correct GPS data and correct values extracted with minor errors in how the data was interpreted.

70+

All data items found with correct GPS, correct values extracted with the correct interpretations

Part 2

Mark

Criteria

0

No attempt

1-29

Significantly incomplete or incorrect with no indication of how data was obtained.

30-39

Contains many errors with little indication of how data was obtained.

40-49

Explanation of analysis to be performed contains minor errors and omissions but is generally complete.

Analysis conducted generally correctly with all files found.

At a minimum must produce a list of file names indicating where the filenames were derived from and timestamps in human readable form.

50-59

Explanation of analysis to be performed contains minor errors and omissions but is generally complete.

Analysis conducted generally correctly with all files found.

At a minimum must identify the correct number of user files before quick formatting, produce a list of file names using the correct encoding, full set of timestamps in human readable form, logical size of each file in bytes and whether the file data is resident or not.

60-69

Explanation of analysis to be performed is clear and correct. Contains no errors and is repeatable.

Analysis conducted generally correctly with all files found.

At a minimum must identify the correct number of user files before quick formatting, produce a list of file names using the correct encoding, full set of timestamps in human readable form, logical size of each file in bytes and whether the file data is resident or not.

Identifies which record is different with an explanation of the difference.

Also, there is an attempt at analysing the attributes in the MFT records found where at a minimum there is a list of attributes in the record.

70+

Explanation of analysis to be performed is clear, concise and correct. Contains no errors and is repeatable.

Analysis conducted generally correctly with all files found.

At a minimum must identify the correct number of user files before quick formatting, produce a list of file names using the correct encoding, full set of timestamps in human readable form, logical size of each file in bytes and whether the file data is resident or not.

Identifies which record is different with an explanation of the difference.

Also, there is an attempt at analysing the attributes in the MFT records found where at a minimum there is a list of attributes in the record, a demonstration that the MFT record is valid based on the values in the fixup array and what flags are set for the attribute.

Part 3

Mark

Criteria

0

No attempt

1-29

Significantly incomplete or incorrect with no references to sources of information about the file systems.

30-39

Contains many errors with few sources to information about the file systems.

40-49

Basic explanation of ReFS where there is a basic overview of the file system characteristics, some metadata and some key data identified. Contains minor errors and omissions.

Sources to information about the file systems stated in Harvard referencing system.

50-59

Good explanation of ReFS where there is a good but concise overview of the file system characteristics, some metadata and some key data identified. Some consideration of key data in ReFs for use in a computer forensic examination.

Good sources to information about the file systems stated in Harvard referencing system.

60-69

Very good explanation of ReFS where there is a full list of the file system characteristics with many items of metadata and key data identified. Good consideration of key data in ReFs for use in a computer forensic examination.

Good and credible sources (from computer forensic practitioners for example) to information about the file systems stated in Harvard referencing system.

70+

Excellent explanation of ReFS where there is a full list of the file system characteristics with many items of metadata and key data identified. Very good consideration of key data in ReFS for use in a computer forensic examination with supporting justification.

Good and credible sources (from computer forensic practitioners for example) to information about the file systems stated in Harvard referencing system.