j\r ^

PRS

Computer
Forensic
Examiner

% IACIS has been approved by the FSAB

I ' as an accredited certifying body in the
i?' field of Computer and Digital Forensics
 A Welcome From the President
Congratulations on your selection for the 2018 training event and welcome to Tallinn, Estonia! The International
Association of Computer Investigative Specialists (IACIS) and our training staff are pleased to return to Europe to
participate in the European Anti-Fraud Office (OLAF) training event.

IACIS is a non-profit, all-volunteer organization dedicated to the training and certification of forensic methodologies
and best practice to forensic professionals around the world. Since its founding on April 6, 1990, due to the
dedication of its all-volunteer staff, IACIS has matured into a well-respected organization and quickly become the
leader in forensic training and certification among forensic practitioners in federal, state, and local law enforcement
as well as forensic professionals in cyber security and incident response.

In 2007, IACIS joined forces w ith the German Federal Police (BKA) and OLAF to bring our digital forensic training and
certification program to the law enforcement community in Europe. Over the years, this relationship transitioned to
an alliance w ith Access Data and INsig2 to continue the formalized training in the region by signing a multi-year
contract w ith OLAF. This year kicks o ff a new multi-year contract that will continue this professional relationship for
several years to come.

As a student of this event, you have been provided membership to the organization that includes an IACIS email
address, membership resources, and the IACIS listserv, giving you instant access to the knowledge o f some o f the
most experienced forensic professionals around the world. Through your association w ith IACIS, you will forge both
professional relationships and friendships that will not only help you expand your knowledge and understanding of
digital forensics but serve to strengthen the entire forensic community.

In addition to the training you are about to receive, you have the opportunity to participate in the next available
certification process associated w ith the course you are attending. Those attending the Basic Computer Forensic
Examiner training course will have the opportunity to obtain the highly coveted Certified Forensic Computer
Examiner (CFCE) certification, while those attending the Advanced Windows Forensic Artifacts (WFE) will have the
opportunity to test for the Certified Advanced Windows Forensics Examiner (CAWFE) certification. The Network
Forensic Analysis (NFA) course does not have a certification associated w ith it; however, the knowledge you will
receive from the course will significantly increase your understanding o f network-related data and artifacts.

The IACIS certification program sets us apart from all the other digital forensic organizations. The CFCE certification
program encompasses the entire digital forensic process and serves as the mechanism to transition the participant
from "student" to "certified professional" and is highly regarded. The program will test your skills in virtually every
aspect of digital forensics from evidence acquisition and data analysis to documentation, while using forensically
sound methodologies and best practice. During the process, you will receive one-on-one coaching during the peer
review process before your skills are tested in the final exam. The CAWFE certification will test your knowledge and
understanding o f advanced Windows artifacts and file systems, including Windows registry, internal system files,
and disk structures.

Delivering world-class training and certification is no small task and would not be possible w ithout the tireless effort
and dedication of our countless volunteer staff that often give their own personal time to research and develop
cutting-edge material for the training and certification programs. IACIS is extremely proud of our volunteers, and I
urge you to also participate and give back to the forensic community by becoming an IACIS volunteer. I believe you
will find it to be incredibly rewarding.

Please enjoy the training, and I encourage you to take advantage of all IACIS has to offer.

M. Gene Shantz
IACIS President
 IACIS
The International Association of Computer
Investigative Specialists

IACIS Certified Forensic Computer Examiner (CFCE)

Core Competencies

IACIS Certified Forensic Computer Examiner (CFCE) Program

The CFCE core competencies described in this document are a binding set of competencies that
guide both the training and certification programs to ensure that the skills and knowledge points
delivered within the training program are also the same set of standards evaluated within the
certification program.

Certified Forensic Computer Examiner Core Competencies

There are Seven (7) competency areas addressed in the CFCE Program:

I. Pre-Examination Procedures and Legal Issues

II. Computer Fundamentals
III. Partitioning Schemes
IV. Windows File Systems
V. Data Recovery
VI. Windows Artifacts
VII. Presentation of Findings

I. Pre-Examination Procedures and Legal Issues

a. Knowledge of the legal process, rules of evidence and the IACIS Code of Ethics and
Professional Conduct as applicable to computer forensics, laws, and procedures.
b. Ability to explain on-scene actions taken for the preservation of physical and volatile digital
evidence.
c. Knowledge of proper computer search and seizure methodologies to include photographic
and/or scene sketch procedures and documentation.
d. Ability to establish, maintain and document a forensically sound examination environment.

II. Computer Fundamentals

a. Recognize and document various computer hardware and small-scale devices.
b. Understand the BIOS, UEFI and Boot sequence.
c. Understand binary, decimal and hexadecimal numbering systems to include bits, bytes and
nibbles.
d. Knowledge of sectors, clusters, volumes and file slack.
e. Understand the difference between logical and physical drives.
f. Understand the difference between logical and physical files.
g. Knowledge of what happens when media is formatted.
III. Partitioning Schemes
a. Ability to identify current partitioning schemes.
b. Knowledge of individual structures and system areas used by different partition schemes.
c. Understand that partition schemes can be used with different file systems and operating
systems.
d. Understand the difference between a primary and extended partition.
e. Define Globally Unique Identifier (GUID) and explain its application.

IV. Windows File Systems

a. Understanding of file system concepts and system files.
b. Understand FAT tables, root directory, subdirectories and directory entries.
c. Understand how FAT directories store dates and times.
d. Understand the structure of ExFAT directory entries.
e. Ability to distinguish, examine and analyze the NTFS master file table.
f. Understand the structure of $MFT records.
g. Understand the Standard Information, File Name and Data attributes, to include parsing
their contents.
h. Understand how the $MFT stores dates and times.

V. Data Recovery
a. Be able to validate forensic hardware, software and examination procedures.
b. Ability to generate and validate forensically sterile media.
c. Ability to generate and validate a forensic image of media.
d. Understand hashing and hash sets.
e. Understand file headers.
f. Ability to extract file metadata from common file types.
g. Understanding of file fragmentation.
h. Ability to extract component files and data from compound files, to include database files.
i. Knowledge of encrypted files and strategies for recovery.
j. Knowledge of Internet and browser artifacts.
k. Understand Email headers.
l. Knowledge of search strategies for examining electronic evidence.

VI. Windows Artifacts

a. Understand the purpose and structure of the component files that create the Windows
registry.
b. Be able to identify and extract important data from a registry.
c. Understand the importance of volume shadow copy services.
d. Knowledge of the locations of common Windows artifacts.
e. Be able to analyze the Windows thumbcaches.
f. Be able to analyze the recycle bin.
g. Be able to analyze link files and Jump lists.
h. Be able to extract and view Windows event logs.
i. Ability to locate, mount and examine virtual drive files.
j. Understand the Windows swap and hibernation files and the evidence they may contain.
VII. Presentation of Findings

a. Ability to draw sound conclusions based on examination findings.

b. Be able to report findings using industry standard/technically accurate terminology.
c. Ability to explain complex technical concepts or processes in terms easily understood by
non-technical people.
d. Be able to give consideration to local legal requirements when undertaking a forensic
examination.
Q ^
IAGIS
The International Association of
Program Description and Syllabus
Computer Investigative Specialists Administration

Contents
A. Program Overview
B. Prerequisites
C. Automated Forensic Tools, Forensic Hardware, and Software
D. Required Equipment and Supplies
E. Attendance and Program Conduct Requirements
F. Course Schedule for Week 1 and Week 2

A. Program Overview

IACIS is an independent, non-profit, peer-review organization that has been recognized

as a leader in computer forensics training since 1991. Each year IACIS offers several
courses of study, at various locations worldwide, including a variety of advanced and
specialized courses and programs that are specifically targeted to a particular topical
focus or a particular sub-specialty within the field of computer forensics.

Of the programs offered by IACIS, the Basic Computer Forensic Examiner

(BCFE) Training Program is at the forefront.

The IACIS BCFE Training Program is a 76-hour course of instruction this is offered over
a period of two (2) consecutive weeks, and which is designed to provide students with
the foundation knowledge necessary to enter the IACIS Certified Forensic Computer
Examiner (CFCE) process. Through a combination of lectures, instructor-led and
independent hands-on practical exercises, and independent laboratory activities students
will learn the underlying principles of computer forensic examination and how to apply
them in practice.

While this program might seem to be primarily for those students who are new to or just
starting out in the field of computer forensics, it is in fact equally suitable for more
advanced students and those who are long-time practitioners: IACIS espouses, and the
BCFE program champions, a forensic tool-independent and forensic methodology-
independent approach to learning computer forensics. This enables IACIS to provide
students with a deeper exploration of underlying principles than might be afforded in
other programs, which are designed to teach students how to use a particular forensic
tool to complete a particular task.

Approximately 90% of what is needed for students to successfully complete the BCFE
program and the subsequent certification process is provided during course program
 lectures and practical exercises, and so students are expected to do additional outside
reading and to perform additional independent research.

The program schedule includes substantial laboratory time (optional) for students who
need or want additional assistance on particular topics.

B. Prerequisites

While there are no prerequisites for entry into the BCFE program beyond the applicable
IACIS membership requirements, students are expected to be comfortable using a
computer and working with electronic devices; and students should have an appropriate
interest in the field of computer forensics generally.

And while students are also expected to be familiar with the Windows family of operating
systems, no advanced level knowledge of the various Windows versions or editions is
expected or required. That said, the student whose experience with Windows is limited to
Windows 10 versions and earlier may find the BCFE program very challenging.

Finally, while knowledge of and experience working within different operating system
environments such as DOS, various versions of Apple/Mac/iOS, and various flavors of
the Linux operating system can be helpful for students, such knowledge and experience
are by no means required for successful completion of the BCFE program or the CFCE
process.

It is important to note that the BCFE program does not distinguish between someone who
has very basic computing skills and who is just starting out in the field of computer
forensics, and one who has more advanced knowledge of computers or prior training in
general information technology topics or in computer forensics.

Certainly one who has more extensive experience will initially be more comfortable with
some of the foundational course material, but as the program advances whatever
“knowledge gap” there might be at the start of the program will quickly close.

In the end, all students are considered at the same level, as it were; and individual
courses are constructed with this in mind.

C. Automated Forensic Tools, Forensic Hardware, and Software

IACIS espouses a forensic tool-independent and forensic methodology-independent

approach to teaching computer forensics. To this end, IACIS does not endorse or
support any particular forensic software tool, forensic hardware device, or any particular
software program generally.

Students are not required or expected to have any knowledge of any particular forensic
software or automated tool suite; and in fact there is no expectation that students in the
BCFE program be familiar with or have any experience using any particular software
program.
 Similarly, students are not required or expected to have any knowledge of any particular
forensic hardware device or component.

The above notwithstanding, automated and manual forensic software tools will be used
during instructional modules to illustrate teaching points and to facilitate MANUAL study
of data structures and data recovery by using a limited functionality of particular tool or
suite of tools. Similarly, particular forensic hardware devices might also be used to teach
students about particular forensic processes.

In cases where use of any particular hardware item or software program of any type is
required for an instructor-led activity, in-class practical exercise, or independent
laboratory exercise, students will be provided access to the particular hardware item or
software program, and there will be instruction as to the use of that particular hardware
item or software program for the limited purpose of the activity at hand.

So there are no misunderstandings, regardless of what hardware item or software

program might be used, the purpose of any instruction that might be provided with
respect the item or program is intended solely for the immediate purpose of the
instructional block at hand, and is not designed to provide specific training on that
hardware item or software program.

D. Required Equipment and Supplies

Students will be supplied with all the materials needed to successfully complete the
BCFE program.

This includes a program manual that includes instructor-led practical and independent
laboratory exercises, various hardware and software tools/items, and other items and
resources that are needed for particular courses or that might be of benefit later, in the
field.

Students are NOTrequired to bring a computer with them to the training program. With
participation in the BCFE training event, IACIS is providing each student a laptop computer
for their use during the event and also to take home with them and use. Along with the
laptop, student will also receive a write-blocker amongst other equipment. The BCFE
Training is contained in three (3) printed manuals. Students should be aware that they will
be returning home with more baggage than they came with and should make arrangements
for this.

In the past, IACIS has tried to get a package mailing company to stop by the hotel
towards the end of the event so that students can ship extra equipment back to their homes
or Agencies. This is at the students’ own cost. There is a UPS store within the
conference center at the Caribe Royale Hotel.

Students may bring a laptop computer or other digital device with them for personal use
outside of the classroom. Students are not permitted to use their personal laptop
 computers, pad/tablet computing devices, cellular telephones, and other personal
computing devices in the classroom.

E. Attendance and Program Conduct Requirements

The BCFE program provides approximately seventy-six (76) hours of instruction in

various computer forensics courses. The program runs for two (2) consecutive weeks,
Monday through Friday, from 8:00 AM to 5:00 PM daily each week, with a one (1) hour
break for lunch from 12:00 noon to 1:00 PM each day. On the 2 nd Friday of the
program, the event will conclude by 4:00 PM after closing ceremonies, as noted below.
Courses are timed using the traditional “50 minute hour” to allow for a short break near
the top of each hour, whenever possible.
On the first day of the program, the first hour (from 8:00 AM to 9:00 AM) is used for
administrative purposes such as staff introductions and providing students information
about the programming to follow. That hour is considered part of the overall program due
to the vital information provided.
The afternoon on the last day of the program (2:00 PM to 4:00 PM) is dedicated to
various administrative and IACIS membership services topics. This includes a critical
presentation on the Certified Forensic Computer Examiner (CFCE) process. At the
conclusion of the presentations students who met all requirements for successful
completion of the program will be issued certificates of completion for the BCFE program.

So there is no misunderstanding, the certificate of completion awarded to students who

successfully complete the 76-hour BCFE course of instruction and is not the IACIS
Certified Computer Forensic Examiner certificate. The CFCE process is a process unto
itself. The CFCE process will be addressed during the BCFE program.

Students are expected to attend all training sessions. Classes begin promptly at 8:00
AM, and students are expected to be prepared to begin the instructional day at that
time. Classes will always continue until 5:00 PM on each class day. On the final day,
the program will close by 4:00 PM.

It is important for students to understand that the presentations in the afternoon of the last
day, are considered mandatory: The bulk of the afternoon consists of a lengthy session
addressing the CFCE process, and it is during this time that all of the information
regarding that process is presented to students. Moreover, vital information is provided
on what IACIS services and resources are available to members; and instructions are
provided on how these services and resources are accessed. Due to the important
information being discussed towards the end of the training event, information that will
help you during the CFCE process, please do not book return flights out of Tallinn
before 7:00 or 7:30 p.m. on Friday to allow for security clearances and traffic to the
airport.

IACIS understands that unforeseen circumstances and emergency situations may arise,
and so students are permitted to briefly leave the classroom to deal with such situations.
That said, students who have prolonged absences from class may not be issued a
certificate of completion at the end of the program, and may not qualify for entry into the
CFCE process.
While students are encouraged to take notes during classes, activities, and laboratory
sessions, students are n s i permitted to use their personal laptop computers or other
personal computing devices during any classes. Similarly, students are not permitted to
use any audio or video recording devices, at any time during any classroom or laboratory
session.

Students are expected to dress professionally and appropriately for a “business casual”
environment (collared shirt, slacks/5.11 style pants, etc.). Shorts, tank tops, sandals, flip-
flops, and similar casual apparel will not be permitted in the classroom at any time.

Something for students to consider is that the classroom is air conditioned, and the
temperature is set lower than what one may typically expect to keep the room comfortable
given the heat that can be generated by a large group people and numerous computers.
At times, however, when the computers are idle, the room can become too cold for some
students, so one might consider bringing a sweater or light jacket to wear.

Students must be mindful of the fact that the classroom is large, with approximately
75 students and staff. Even small distractions can make it difficult for others to hear
or to remain focused on the instructor. So, then, students are asked to be courteous
and aware of their fellow students.

During classes, students are expected to be attentive and fully engaged. Cell phones
must be put on “vibrate” or “silent” mode, and students should step out of the classroom
if it becomes necessary.
 Operating System (OS)
Boot Sequence

Disk Structures

Contents
i. Synopsis
ii. Learning Objectives
III Definitions
IV. Boot Sequence Overview
V. Conclusion

I. Synopsis
The forensic computer examiner must, first and foremost, control the processes which take place during
the acquisition and examination of the evidence. Due to the wide variety of operating systems, file systems
and hardware encountered during a forensic examination, there are many variables that must be taken into
consideration in order to ensure the original evidence is not altered by our interaction.

We must first understand what takes place during the boot process of a personal computer. This includes
the computer used for imaging and analysis. If we understand the process then we can take measures to
control the process and protect the integrity of the evidence.

This paper will acquaint the student with the processes that take place during the boot process. Further,
we will define terms commonly encountered with the boot process.

II. Learning Objectives

At the conclusion of this course the student should be able to:

• Understand the meaning of the various terms and acronyms used during the boot sequence of a
personal computer

• Understand the breakdown of the boot sequence process in general

• Understand the way the personal computer with a Windows operating system boots

• Understand in general how a computer with either a Mac OS or a Linux OS boots

BIOS: An acronym for Basic Input Output System. The computer’s BIOS is a small segment of code normally
stored on a ROM (see ROM) chip. The entire content of that segment of code varies amongst the different
manufacturers, but It generally contains similar data. Normally this includes the information required for the
computer to properly interact with the various input and output devices, e.g. keyboard, CPU, video card, on­
board media devices, motherboard resources and the ISA/PCI/AGP expansion slots).

BOOT: It is commonly used to refer to the entire startup process, as in “I’m going to start the computer” or "I'm
going to boot the computer”. For the purposes of this paper, "boot" will be analogous to the word “start”. To
extend this, the “boot process” is the process of starting the computer and “reboot” is the process of restarting
the computer.

BOOTABLE MEDIA: Media that can contain the software required to startup a computer. Most often this is a
hard disk drive, floppy diskette, a bootable CD/DVD or a USB device. In many computers the default is set for
the hard drive to act as the boot device. Newer computers now set the CD/DVD-ROM and/or the USB device to
have priority in booting over the hard drive.

CMOS: An acronym for Complementary Metal Oxide Semiconductor. This type of semiconductor has a very
low power draw and is supplied long-term power by a battery, typically mounted on the computer's motherboard.
Stored within the memory of the CMOS are the system date and time and the initial system start up instructions.

EFI: See UEFI below

KERNEL: The kernel is the essential center of a computer’s operating system; the core that provides the basic
services for all other parts of the operating system. Typically, a kernel (or any comparable center of an operating
system) includes an interrupt handler that handles all requests or completed Input/Output operations that
complete the kernel’s services; a scheduler that determines which programs share the kernel's processing time
in what order; also, a supervisor that actually gives use of the computer to each process at the time it is
scheduled.

POST: An acronym for Power On Self Test. The POST is the initial test the computer performs to ensure the
core components are present and functional.

RAM and ROM: Acronyms for Random Access Memory (RAM) and Read Only Memory (ROM). Modern
computers use both types of memory. RAM is considered volatile and maintains information only while the
computer is powered on and the operating system is running. Shut the operating system down or interrupt the
power supply and the information stored in RAM is lost. ROM is considered non-volatile since it does not rely
on the computer’s power supply to retain its information. The term ROM evolved from its original state of read­
only. ROM chips in modern computers are often programmable and can be modified by the end-user.

UEFI: Unified Extensible Firmware Interface. It replaces the legacy BIOS method of booting a computer. It is a
much larger platform than BIOS. But it provides the same function as BIOS in that it provides communications
between the hardware and the operating system. UEFI has its own boot loader and supports the new GPT
(GUID - Globally Unique Identifier - Partition Table) partitioning scheme in addition to the MBR (Master Boot
Record) partitioning scheme. One of the most common features of UEFI encountered by the Forensic Examiner
is the "Secure Boot" feature. The Secure Boot feature of UEFI v.2.3.1 and later which allows only signed and
authenticated Operating Systems to boot into that computer. This is discussed in further detail in the Windows 8
and Windows 10 section of the Forensic Boot Media block.

IV. Boot Sequence Overview

Once the power is turned on the computer performs the POST and then begins passing control from the
CMOS to the BIOS, which seeks out the bootable media from which the operating system is loaded into
• Part I - everything before the bootable media receives control.

• Part II - covers everything once control is turned over to the boot device and the operating system
begins to load.

PART I - BREAKDOWN

It is crucial to understand this process in depth. This paper only provides a synopsis of the process. The
Computer Forensic Examiner should possess a fundamental understanding of each step during this
process in order to identify the source of any problem should something go wrong.

When the power is first turned on, electrical impulses travel along the circuitry on a pre-determined path.
These impulses arrive at the processor and re-initialize the processor’s memory registers. One of these
registers stores the starting location for the instructions within the ROM. These instructions are loaded
and executed, which begins a “system status check" also known as POST.

The POST first sends impulses throughout the circuitry or bus to verify the pathways are properly
functioning. The real-time clock (RTC) is responsible for regulating the system’s timing/synchronization
and its functionality is now verified. The POST then checks for a video BIOS. The precise method varies
among systems, but in general it looks to the CMOS and BIOS for information on how to find the video
BIOS and then attempts to load the video BIOS.

Up to this point, any problems encountered during the POST are reported to the user by way of tones
(combination of beeps) from the computer’s internal speaker. This is why a computer has this speaker.
The actual tones vary among different computers, but almost always reporting problems with the CPU,
RAM, ROM, BUS or the video ROM. Should the Forensic Examiner encounter a POST error during a
system boot-up, an Internet search of the POST error beeps along with the computer make and model can
help the Examiner narrow the cause of the boot failure and possibly rectify it. At this point the video is now
active and additional information is communicated to the user by way of the monitor.

The user should see information gathered about the video BIOS, then the CPU and, finally, the memory
(RAM). Once the POST is complete, the startup instructions from the BIOS are loaded and executed.

The subsequent steps, which will be reported through the monitor vary, however in general, the startup
program “talks” to each of the input/output devices and configures them according to the settings
contained within the BIOS. These settings can include information about the hard disk drives affixed to the
system, floppy disk drives, other media devices such as CD-ROM or DVD drives, system controlled power
management and system passwords (not to be confused with operating system specific passwords).
Once all of the code within the BIOS has been executed, the computer then checks the BUS for any other
executable BIOS. The most common example of this would be the BIOS located on a SCSI (Small
Computer System Interface - pronounced “scuzzy”) Host Controller. If an executable BIOS is located, its
code is now loaded and executed. The system now passes control to the bootable media

PART II - LOADING THE OPERATING SYSTEM

There are a multitude of operating systems in use today. All of them have unique processes and all are
loaded into RAM by different means. As a result, this paper only covers the most basic aspects of the
process for the kernel built Windows 7, Windows 8, Windows 10, Linux and Mac OS X.

Windows 7

The Windows 7 operating system supports booting from a BIOS based system or an EFI (Extensible
Firmware Interface) based computer. There are slightly different sequences depending on what type of
system you have.

For an EFI based system:

• EFI has a boot manager built in and the Windows install makes a single line entry into the
boot manager titled “Windows Boot manager". It points to EFI\Microsoft\Boot\bootmgfw.efi
on the EFI partition.

• If you select Win 7 in EFI menu (if you have multiple systems) it loads the boot manager
(bootmgr).

• From here on out, it is the same as a BIOS based system.

For a BIOS based system:

• Looks for MBR (if booting from Hard Drive) and reads into memory and transfers control
from BIOS to code in the MBR.

• MBR reads the partition tables and enables the system to read the file system.

• Locates and starts Boot Manager (bootmgr) in root directory. If there is only one OS on the
system, it boots to that OS

• Once Boot Manger loads, it is the same process for BIOS and EFI based systems.

• If an active partition is located, the code loads Windows Boot Loader (WinLoad).

• If there is only one operating system installed, the boot manager has a built in delay to
allow the user to safe boot or select the boot loader (any key).

• Boot Loader then loads kernel (ntoskrnl.exe) but does not run it.

• HAL (Hardware Abstraction Layer) is loaded but not used until kernel is launched.

• Loads services from the System Registry Key.

• Loads all device drivers into memory but not used until the kernel is launched.

• Enables Paging.

• Launches Kernel, HAL and Device Drivers. Kernel creates HKey Local
Machine\Hardware. Current Control Set is processed unless you choose Last Known
Good from menu.

• Session Manager (Smss.exe) takes over and will run as long as it is booted. All prior steps
have been in text mode. Now switches to graphics mode and launches the "Starting
Windows" Logo.

• The logon manager launches and the user then logs on.

The biggest difference between the installation of Windows 7 and its predecessor (Windows Vista) is the
automatic installationof the Windows Recovery Environment (WinRE) by Windows 7. WinRE was
available with Windows Vista but was not installed by default. To access the Startup Repair Tool, which
is part of WinRE, IT professionals had to configure the required partition and install the tools to it. With
Windows 7, WinRE is installed on the hard drive by default. Windows 7 automatically opens WinRE, if
Windows 7 fails to start. If the hard drive is damaged, the user can still run WinRE from the Windows 7
 Another change to Windows 7 was the reduction in the time the operating system took to start-up, shut­
down and resume from sleep. Windows 7 code increased the speed at with these operations took
place. Apart from that, there were no significant changes in the boot-up process from Windows Vista to
Windows 7.1

Windows 8
In October 2012, Microsoft Corporation released Windows 8. Windows 8 entered the market at a time
when many manufacturers are moving from the traditional BIOS to UEFI on new client systems.
According to various blogs posted on Microsoft Developer Network (MSDN) Windows 8 will continue to
support legacy BIOS but on systems that have UEFI it will take advantage of the features offered by it.
Some examples would be using the Graphical Output Protocol (GOP) driver to render a graphical
resolution in native format. Another example is the use of “Secure Boot” which allows the firmware and
operating system to have a secure handoff while booting - in turn preventing bootup malware. Windows
8 will display a logo - generally from the PC manufacturer and then transfer control over to the
Operating System in what should be a seamless function.2

Windows 8 had many features to keep the user experience safe and secure. It used a certification
process that required Windows Store apps to be certified and if they were not, they could not be
included in the store. It also took advantage of features like Secure Boot, Trusted Boot and Early
Launch Anti-Malware (ELAM) to protect the computer and the OS.

Secure Boot: Most, if not all computers pre-loaded with Windows 8, supported UEFI and Microsoft took
advantage of the features that were part of the UEFI. Upon bootup the computer first finds the
Operating Systems bootloader. If the computer is not using the Secure Boot feature, it will boot any
bootloader that is available - trusted or not. For PCs adhering to the Secure Boot concept, the
bootloader firmware is checked to see if has been digitally signed as "trusted" and only then will it boot
into that operating system.

Trusted Boot: Once Secure Boot has completed its signature checks, it passes control to the Trusted
Boot section of the startup process. It is during this section that the Windows 8 kernel will check and
verify other components of the start-up process. This includes, but is not limited to, startup files, bootup
drivers and the ELAM (Early Launch Anti-Malware). If any of these files seem to be tampered with, it
will prevent the booting of that OS.

ELAM - Early Launch Anti-Malware: Once the Trusted Boot has verified the files and drivers, Microsoft
then launches ELAM. The purpose of ELAM is to further protect the OS. Since Secure Boot and
Trusted Boot verify the files involved within the OS, there is an opportunity for 3rd party drivers to now
infect the computer. Since the OS has not started yet and to ensure that Windows starts as quickly as
possible, the one main task of ELAM is to examine every driver that is activate during this boot process.
If the driver is not part of the trusted list, the OS will cease to boot. It is important to note that ELAM is
not a complete anti-malware program, but rather a streamlined single-focused program that is tasked to
protect the computer and operating system before the user even sees the Windows Login screen.

1Tulloch, Mitch; Northrup, Tony; Honeycutt, Jerry; Wilson Ed and the Windows 7 Team at Microsoft (2010),
Windows 7 Resource Kit, Microsoft Press
2 Sinofsky, Steven, Reengineering the Windows Boot Process, Microsoft Developer Network (MSDN) Blogs
 When Windows 8 boots Into a UEFI-based system with
ui
oc Secure Boot activated, UEFI will check to see if the OS
Z) O Is a trusted and signed OS. If so, it will pass control to
u O
UI CÛ the Trusted Boot component of the Boot Process.
l/)
During the Trusted Boot component of the boot
process the Master Boot Record (MBR) is read and it
starts the Boot Manager (BootMgr.exe). The Boot
Manager will then find the Windows Loader
(Winload.exe) in the windows boot partition and load it
followed by the Kernel (ntoskrnl.exe).

At this point other system drivers and files are checked

for integrity and if they are verified, control is passed to
the ELAM which then checks every diver that is being
loaded which includes 3rd party drivers.

The Session Manager (smss.exe) now takes control

and loads and starts the device drivers. Any anti­
malware (like Windows Defender) then loads to ensure
further system security at which point, if everything is
verified, WinLogon.exe launches and shows the user
the login screen.

Once the user logs in and is authenticated, Windows

creates a session for that user at which point
explorer.exe starts and the desktop is presented to the
user.

The boot process seems to work similar to the

Windows 7 boot process. Systems with UEFI will
notice how quickly the POST handoff to Windows
occurs. This prevents the user to press any function
keys that were possible (like F8 and F2) during POST.
Windows 8 does not do a full “plug-n-play" enumeration
of drivers during a cold boot - it does however initialize
these drivers during this time. This also aids in
speeding up the boot process.3

(information courtesy Microsoft:

https://technet.microsoft.com/en-us/windows/dn168167.aspx and
https://blogs.msdn.microsoft.com/b8/2011/09/08/delivering-fast-boot-times-in-windows-8/)

3 Sinofsky, Steven, Delivering Fast Boot Time In Windows 8, Microsoft Developer Network (MS
DN) Blogs
Microsoft released Windows 10 in 2015. While detailed information on the boot process of Windows 10
is not easily available, it looks like Windows 10 functions similar to Windows 8 during boot, relying
heavily on UEFI features..

Just like with Windows 8, when a Windows 10 computer is powered on BIOS or UEFI will run its regular
POST and make sure all devices are connected to the computer and functioning nominally. Once that
is done, the Master Boot Record (MBR) is located on the bootable partition which in turn calls up the
Boot Manager (BootMgr.exe). The BootMgr looks to see if there are different versions of Windows
installed and if not, will run the Windows Loader (WinLoad) followed by the OS Kernel (NTOSKRNL).

The process continues just like with Windows 8 where the Kernel will load the system drivers checking
these files for integrity at with point the Early Launch Anti-Malware (ELAM) is executed which verifies
that each driver being loaded does not include malicious payload. Once this is done, the process is
handed over to the Session Manager (SMSS) which loads any 3rd party drivers, any anti-malware
software (not to be confused with ELAM) and finally launches WinLogon that shows the user the login
screen. Once the user signs in and is authenticated, a new session is started for that user and the
desktop is shown.

The flowchart shown on the previous page for the Windows 8 boot process can also be used for the
Windows 10 boot process in that they are almost identical. The biggest visual difference between these
two operating systems is the return of the Start Menu in Windows 10 - a welcomed feature for the
majority of users.

(Information courtesy Microsoft:

https://docs.microsoft.com/en-us/windows/security/hardware-protection/secure-the-winclows-10-boot-process)

Linux

This is an extremely robust operating system whose kernel is “open source", resulting in the end-user
having the ability to modify and re-compile a custom kernel. This makes Linux a very flexible operating
system, but also results in a much higher learning curve. The boot process is relatively simple. In the
shortest form, the Linux boot sequence appears as follows: The computer is turned on and the system
BIOS scans the Master Boot Record for a boot loader. On a stand alone Linux machine either LILO
(Unux LOader) or GRUB (GRand Unified Bootloader) - two popular Linux boot loaders - will be loaded
and executed. The boot loader will now find and load the kernel. The kernel will now load the primary
process, init. Init will now run a series of startup scripts commonly called “rc files”. The "rc files" are
very similar in purpose to the AUTOEXEC.BAT and CONFIG.SYS used in the DOS boot process.
These “rc files”, which are generally shell scripts, spawn all of the processes that make up a running
Linux system. Due to the end-user’s ability to create a variety of startup scripts, the processes started
during the boot sequence vary from computer to computer and are far too many in number to name or
explain in this paper.

Mac OS X

The boot process in a Mac has four stages with each providing a visual or audible cue:
1. Firmware
2. Booter
3. Kernel
4. User Environment

Firmware
The firmware or BootROM differs for the PowerPC and Intel Macs. The PPC Mac utilized Open
Firmware while the Intel Mac uses Extensible Firmware Interface (EFI). For this particular situation, we
will generalize what they do and just refer to both as firmware. The firmware contains instructions of the
initialization of the system prior to booting the Operating System.
Once power is started, the firmware (BootROM) initiates a power on self-test (POST). The POST is a
pre-boot operation in which the system hardware is tested to ensure it is working correctly. The system
software booter is also located and initiated. If there is a problem, the display will be blank or off, there
will be no start up chime and the POST will provide either a series of beeps or flashes from the LED in a
set sequence. These error codes will provide information which will help diagnose the issue.

If the Mac passes the POST, the startup chime will sound and a grey screen will be shown. (Figure 2)
The firmware will also check to see if any boot modifier keys are being used. Finally the firmware will
select the OS booter. This will normally be the last Booter that was selected in the System Preference’s
Startup Disk or the Boot Camp Control Panel in Windows. When the Booter is located, the boot process
will start. This is indicated by a dark grey apple in the center of the screen. (Figure 3)

FIGURE 2: POST Screen FIGURE 3: Booter Screen

Booter:
The firmware passes the boot process and any boot modifiers to the Booter. The Booter, BootX for the
PPC and boot.efi for the Intel starts the loading of the OS kernel in order for it to take over the boot
process and continue the start up process. The firmware also passes information to the Booter for any
special startup mode instructions,i.e. Safe Mode, Single User Mode, Target Disk Mode, etc. Once it is
successfully started, the screen will display a spinning cog under a light grey apple. (Figure 4)

If the Booter is unable to load the kernel, a dark grey prohibition symbol will appear in the middle of the
screen. (Figure 5)

FIGURE 4: Kernel Screen With Cog Wheel FIGURE 5: Prohibition Screen

 Kernel:
Once the kernel has been successfully loaded, It takes over startup process. The kernel is responsible
for the core UNIX system and initiating the user environment by starting launchd. The start of the
launchd process is indicated by the blue screen. (Figure 6)

«OO Activity Monitor

• §
Quit Process Inspect
3
Sample Process
All Processes

SI

10 kcxtd root 0.0 2

11 DirecioryScrvice root 0.0 6

FIGURE 6: Launchd Screen FIGURE 7: Activity Monitor showing Launchd as Process #1

User Environment:
The launchd process is responsible for starting all the other processes needed to run the operating
system and the user environment. This is the very first process that is started in the User Environment
and has a process identification number of 1. This can be seen in the Activity Monitor. (Figure 7)

The Parent launchd runs as root and initiates all other processes. The last step of the process is the
launching of the loginwindow application by launchd. The loginwindow will initiate the login screen and,
if autologin is not selected, will reach out to Open Directory to authorize the User. Once the User is
authenticated the User launchd takes control. It sets up the GUI User session by applying account
settings, configuring user preferences, opening the Dock, Finder and SystemUIServer. It also
automatically opens the User’s login items. The start up process is now complete.

This has been a brief overview of the boot process for the Mac OS X operating system. There are
several other ancillary processes which run during the boot process and should be reviewed at the
examiner’s convenience.

V. CONCLUSION

Forensic Computer Examiner’s need to have a comprehensive understanding of the boot process for
the operating system they are using. While different versions of an Operating System (OS) may seem to
behave the same, their boot processes may be different. DOS used to be the easiest to control during
boot, however, it is no longer a prevalent OS. The newer operating systems, as we have seen, perform
a wide variety of functions during their boot process and having knowledge of how each of them boots is
always beneficial for that Examiner.
 Overview of the Windows Boot Process

* This is a generic graphical representation of the windows boot process. The actual process depends
on the type and version and Windows Operating System
 Forensic Boot Media

Disk Structures

Contents
I. Synopsis
II. Learning Objectives
III. Forensic Boot Media Concepts
IV. Types of Forensic Boot Media
V. Bootable CDs or DVDs
VI. Bootable USB devices
VII. Concerns About Using Bootable optical medias or USB Devices
VIII. Windows and UEFI Secure Boot
IX. Conclusion
X. Recommended Resources

I. Synopsis
It is normal accepted forensic practice to by-and-large remove a hard drive from a personal computer,
write-block it and then image that hard drive. Increasingly, Forensic Examiners are encountering computers
where the hard drive cannot be removed and imaging of the storage device needs to be done with it con­
nected to the computer.

To achieve a “forensic” boot of a computer with the original hard drive still in it, the Examiner needs to boot
the computer using either a:
• Bootable Diskette;
• Bootable CD-ROM; or
• Bootable USB device
all the while ensuring that the evidence on the computer is not altered either during the boot or the acquisi­
tion phase of the process.

II. Learning Objectives

At the conclusion of this course the student should be able to understand:
• The concept of forensic boot media
• Different kinds of available forensic boot media
• How to create and boot a computer using a bootable CD-ROM
• How to create and boot a computer using a bootable USB device
• Issues pertaining to booting a computer using a CD-ROM or USB device
• How to create a forensic edition of a Windows Operating System (WinFE)
• How the UEFI Secure Boot concept can affect an Examiner's work
III. Forensic Boot Media: Concept

Forensic boot media is defined as any bootable device that can successfully boot a computer without "making
calls" or changes to the data that is on the hard drive of the computer. When a computer boots, after a certain
point in the boot process, the Operating System (OS) takes control of the boot process. During this time, the
OS may update or modify certain files on the hard drive of the computer. While this may not affect user data
that is stored on the computer, it will change dates of times of certain files and registry entries. For example an
Examiner wanting to find out the last time a suspect booted a computer would "step-on" or corrupt the location
where this information is stored if he/she were to boot that computer without properly protecting it. The primary
objective of Forensic Boot Media is to protect the hard drive(s) from being accessed by the booting Operating
System (and thereby being written to), effectively changing the sum total of the contents of that hard drive.

With that in mind, should Forensic Examiners encounter such an instance whereby the hard drive cannot be
removed from the computer and properly write-protected, they should be prepared to boot that system with a
specially created and tested Forensic Boot Medium - be it a diskette, a CDROM or a USB thumb/harddrive.

Some instances that the Examiner many encounter are:

• Not having a write-blocker available to remove the drive and image it
• Wanting to preview a system without contaminating the original contents of the hard drive
• Finding it hard or impossible to remove the hard drive from the system

Finally, the longer you are in this profession, the more you realize that there is no one magic tool that does eve­
rything you want. Having another tool (in this case a way to forensically boot a computer with removing the hard
drive) in your arsenal may prove to be beneficial and helpful to you in the future.

IV. Types of Forensic Boot Media

The first type of forensic boot media created was the DOS-based boot diskette. It was found that only one file in
the DOS operating system was responsible for altering the contents of a hard drive of that system. Once that
file was modified, and a couple of non-required files deleted, the Examiner effectively had a forensic bootable
diskette. DOS is now an archaic and obsolete operating system and as such it is very rare to find the need to
boot devices using a DOS-based forensic boot diskette.

With the advent of computers all having optical disc drives, and being able to boot from them, CD-ROMs were
the next media that were created to be forensically sound during boot. As we learned in the OS Boot Sequence
portion of this block, Linux operating systems are some of the most configurable operating systems available
many flavors of which are free. While not all Linux flavors are automatically "forensically sound", there are many
that are available that are. Many years later, WinFE (Windows Forensic Edition) was born and with the operat­
ing system being Windows, Examiners found it easier to use and work with once they had created a bootable
WinFE DVD.

As computers got smaller and manufacturers decided to make optical drives optional in many netbooks and lap­
tops, IT and technophiles had to find a way to boot those computers. This gave rise to the Bootable USB device
which allowed anyone to boot a computer via a USB device. Forensic Examiners took advantage of this feature
and created forensic bootable USB devices that could boot a computer without an optical drive and still protect
the contents of the hard drive.

In summary, there are 3 ways to boot a computer forensically. They are:

- Diskettes (now obsolete for the most part)
- CD/DVDs
- USB (For those computers that do not have CD/DVD-drive)
Linux-Based
As diskette-drives in computers started to become scarce, the Forensic Examiner had to find a way to forensi-
cally boot the computer using a CD-ROM. The forensic community turned to Linux. The robust Linux operating
system was also chosen for the following reasons:

• Control - not only of the software but also of the environment. Most Linux distributions will require the
Examiner to mount and write-enable any hard drive connected to it.

• Flexibility - the ability to boot a complete operating system from a CD and also the ability of a user to
create his/her own shell scripts and create a customizable environment

In August 1991, a Finn by the name of Linus Torvalds sent a message to the USENET group comp.os.minix.'
Minix (which stood for Minimal Unix) was an Unix-like operating system developed by Andrew Tannenbaum in
198712 The message (Figure 1) said that Torvalds was working on a new operating system as a hobby and was
asking for input from fellow Minix users.
_________________________________________ Figure 1_________________________________________
Path: gmdzilunido!fauern!ira.uka.de!sol.ctr.columbia.edu!zaphod.mps.ohio-
state.edu!wupost!uunetImcsun!news.funet.fi!hydra!klaava!torvalds
From: [email protected] (Linus Benedict Torvalds)
Newsgroups: comp.os.minix
Subject: What would you like to see most in minix?
Summary: small poll for my new operating system
Keywords: 386, preferences
Message-ID: <1991Aug25.205708.954ISklaava.Helsinki.FI>
Date: 25 Aug 91 20:57:08 GMT
Organization: University of Helsinki
Lines: 20

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones. This has been brewing
since april, and is starting to get ready. I'd like any feedback on
things people like/dislike in minix, as my OS resembles it somewhat
(same physical layout of the file-system (due to practical reasons)
among other things).

I've currently ported bash(1.08) and gcc(1.40), and things seem to work.
This implies that I'll get something practical within a few months, and
I'd like to know what features most people would want. Any suggestions
are welcome, but I won't promise I'll implement them :-)

Linus (torva...Skruuna.helsinki.fi)

PS. Yes - it's free of any minix code, and it has a multi-threaded fs.
It is NOT protable (uses 386 task switching etc), and it probably never
will support anything other than AT-harddisks, as that's all I have :-(.

This "hobby” operating system would turn out to be the operating system we now know as Linux.

With Linux being so robust, portable and customizable, users started to create their own flavors of the operating
system. Different source codes were compiled into various flavors (distros) of Linux like Kali, Redhat, Suse,
Debian, Knoppix, Ubuntu and Fedora - to name a few.

1Wikipedia - Linus Torvalds

2 Byfield, Bruce (2010) An Introduction to Minix, Linux Journal (www.linuxjournal.com)
Soon after, the forensic community started seeing bootable CD-ROMs (or Live CDs) emerge and contained fo­
rensic tools used for analysis and acquisition. The majority of these tools are free to download. At the time of
this paper, numerous forensic boot CDs or DVDs are available for the Forensic Examiner:
• P a lad in -www.sumuh.com
• D E F T -www.deftlinux.net
• Helix - http://www.e-fense.com/products.php
• Linux4n6 - www.lnx4n6.be
• Caine - www.caine-live.net
are a few commonly used Linux based forensic boot CDs.3

To create a Live optical boot disc, Examiner can follow these generic steps.
• Visit the website for the Live CD you want to create

• Find the download link and download the ISO file for that Live CD
o The file will generally have an .ISO extension to it - for example: Paladin-7.0.ISO

• Once the file is downloaded to your computer, use a CD-burning program to write the ISO to the CD
o Bear in mind that writing the ISO image file to a CD to make it bootable is not the same as cop­
ying that ISO file to the CD. When you write an ISO to a CD (or extract the ISO image to a CD)
the CD burning program will expand the files that are stored in the ISO image to the CD. This
process is usually found in the “copy CD" or “Create Image” section of the CD burning program,
o In Windows 8 and 10, you are able to right+click the ISO file and choose Burn Disk Image from
the sub-menu that opens. This opens the Windows Disk Image Burner to let you create the CD.

• Once the Live CD. has been created, you should be able to look at the contents of the CD. If you only
see the ISO image file - you have not created a bootable CD and will need to redo the creation steps.

Windows-Based
While Linux-based bootable CDs worked very well for the Forensic Examiner, it was increasingly evident that
most Examiners were not familiar with Linux. As such, other than using the tools available via the menu, many
Examiners were unable to do much else. The need for a Windows-based bootable CD arose, however, due to
licensing requirements and the proprietary nature of Windows, creating a bootable Windows CD is not as easy
as creating a Linux-based one.

When Microsoft introduced Windows PE (Preinstallation Environment) an opportunity to create a bootable Win­
dows Forensic CD presented itself. According to Microsoft4 :

Windows Preinstallation Environment (Windows PE) 2.0 is a minimal Win32 operating system with limited
services, built on the Windows Vista kernel. It is used to prepare a computer for Windows installation, to
copy disk images from a network file server, and to initiate Windows Setup.

Windows PE is not designed to be the primary operating system on a computer, but is instead used as a
standalone preinstallation environment and as an integral component of other setup and recovery technol­
ogies, such as Setup for Windows Vista, Windows Deployment Services (Windows DS), the Systems Man­
agement Server (SMS) Operating System (OS) Deployment Feature Pack, and the Windows Recovery En­
vironment (Windows RE).

Troy Larson, a Senior Forensic Investigator with Microsoft Corporation is largely credited with creating the first
forensic Windows bootable CD using Windows PE. Since then others have created their own versions of a
bootable Windows forensic CD.

3 IACIS does not endorse any one particular product over the other. The list given is for reference only. All pro­
grams should be tested by the Examiner prior to use in a live environment
4 Microsoft TechNet, undated, What is Windows PE
Most notable amongst them are:
• WinFE - Windows Forensic Environment - created by Brett Shavers - http://winfe.wordpress.com/
• System Acquisition Forensic Environment (SAFE) Boot Disk by Forensic Soft, www.forensicsoft.com
• Gargoyle Investigator by Wetstone - http://www.wetstonetech.com/cgi-bin/shop.cgi7view,40

WinFE is a free product but requires configuration on the part of the user prior to use. SAFE and Gargoyle are
commercial programs which are ready to be used once purchased.

Once a forensic boot CD is created, the Examiner should be able to boot a computer with it, however, there are
a few caveats that the Examiner should bear in mind:
• The Examiner must test and verify that the CD works the way they want it to - specifically that the at­
tached hard drives are being properly write-protected.

• Some hard drives with certain file systems, like XFS or EXTx (under certain conditions) may not be
properly write-protected.

• The boot priority of the CD-ROM on the target machine should be higher than that of the hard drive or
else the hard drive will boot first. This needs to be verified by the Examiner by accessing the Bl-
OS/UEFI of the target system. With the advent of UEFI and Secure Boot (see section on it later), other
changes in UEFI/BIOS may also be required to allow the computer to boot from that CD.

• In testing by the creator of WinFE, using a Windows 7 version of WinFE to boot a suspect drive that has
not been used in a Windows environment before may get a signature written to that suspect drive at the
location 0x1 B8. Using a Windows 8 and newer version of WinFE was found to not create accidental
writes to the suspect media (http://www.forensicfocus.com/downloads/WinFE.pdf;
http://mistyprojects.co.uk/mistype/mini-winfe.docs/readme.files/usage.htm)

VI. Bootable USB Devices

As computers continued to get smaller, the forensic community was faced with the issue of having to image a
computer which had no CD-ROM drive, no diskette drive and one whose hard drive was difficult to physically
access. Around 2007, Arpad and Geza Kovacs wrote a program called UNetBootln (Universal Network Boot
Installer). The purpose of this program was to create a USB thumbdrive or USB hard drive that would boot vari­
ous flavors of Linux.

With the forensic community already relying on bootable Linux CD-ROMs, the transition to a bootable USB de­
vice was the next step. Creating a bootable USB thumb drive or USB hard drive using UNetBootln is fairly sim­
ple. Instructions for downloading the software and creating the bootable device are available on the UNetBootln
website at: http://unetbootin.sourceforge.net

Another similar utility that has come into the forefront is Rufus. Rufus is a utility that is very similar to UNetBoot­
ln and lets you create a bootable USB thumb drive from a bootable CD-ROM. Rufus can be downloaded at:
http://rufus.akoe.ie

As mentioned in previous sections, the Forensic Examiner must test the USB device they have created. It
should also be noted that the computer system being booted will require that the USB Device have a higher
boot priority than the hard drive. Further, not all computers allow booting from a USB device. The Examiner
must be prepared to check and change the settings in BIOS and also be prepared to defend their actions should
the computer inadvertently boot into the resident operating system. The Examiner must also understand the
concept of the UEFI Secure Boot and how it prevents a computer from booting to an "unsigned" Operating Sys­
tem.
As with any procedure undertaken by the Forensic Examiner, there are concerns that the Examiner needs to be
aware of and be able to address. Using CD-ROMs and USB devices to boot a computer system presents the
following concerns (at the least) that the Examiner must consider when performing such a procedure:
• Booting a computer system with a device other than the internal primary hard drive (CD-ROM, USB,
diskette) requires the appropriate Boot Priority to be set in BIOS. If the primary hard drive is set to a
higher priority than the peripheral devices, the target machine will boot into its installed operating sys­
tem
• Accessing the BIOS to make changes to the boot priority (as mentioned above) can sometimes be
tricky. If the Examiner does not press the proper access-key or is slow to trigger BlOS-access, the tar­
get machine will boot into the installed operating system.
• While newer computer systems are capable of being booted with a CD-ROM, older systems do not have
this capability. The Examiner must know the machine he/she is working with. Not all computers will
boot using a USB device. An attempt to boot an unsupported system using a USB device may result in
the target machine booting into its installed operating system.
• Not all file systems are properly write-protected. This is mostly true of XFS and EXTx file systems under
certain conditions and also depends on how the forensic boot software has been configured. The Ex­
aminer must be cognizant of the limitations of the software that is being used.
• Newer computers now take advantage of a UEFI feature called "Secure Boot" (see below) which is a
way for the computer to prevent "unsigned" Operating Systems from booting it. The Examiner must be
able to recognize this and take steps to bypass this feature if necessary.
• Documentation of steps and reasons for those steps should always be properly done by the Forensic
Examiner. This is particularly true should the suspect system not perform the way the Examiner intends
at which point good detailed documentation will assist the Examiner in defending his/her actions.
• As with everything we use in the performing of our jobs, any software that you use on a case should be
tested and verified before being used on case evidence.

VIII. Windows and UEFI Secure Boot

This is what we understand about Windows and the UEFI Secure Boot:
When Microsoft introduced Windows 8 towards the latter part of 2012, many Examiners began to notice that
computers that were pre-installed with Windows 8 or some that had Windows 8 installed on it as its base operat­
ing system (i.e. not upgraded from a previous version of Windows) would not allow an Examiner to boot the
computer from a CD or a USB device. They further noticed that access to the BIOS in many cases had been
disabled so that the Forensic Examiner could not change the boot-up sequence.

Upon research it was found that Microsoft was using a feature called “Secure Boot” on machines that had Uni­
fied Extensible Firmware Interface - UEFI - which is also loosely known as "the new BIOS”. Secure Boot is a
feature of UEFI (version 2.3.1 and later) and not Windows 8 or 10 - Windows just takes advantage of this fea­
ture on systems that have UEFI. Microsoft took advantage of this UEFI feature in an effort to prevent malware
from booting a system. For the Forensic Examiner, this presents a few problems.

As we have seen in the past, the “old" BIOS allows an Examiner to enter the setup and change settings to per­
mit the computer from booting to a CD or an external USB device. The traditional boot process works like this:

Operating
BIOS ANY OS
LOADER System
V_______________) CODE Start
Microsoft saw this as a vulnerability and addressed it in Windows 8. Windows now installs and takes advantage
of the UEFI Secure Boot feature and only Operating Systems that are properly signed and authenticated are
allowed to execute their code in the pre-boot environment.

NATIVE
Only Verified Operating
UEFI System
and Signed
Ver 2.3.1 +
v_____ ______ / OS Loader Start

As a result, computers that were installed with Windows 8 (and now Windows 10) and had UEFI and Secure
Boot enabled prevented the user from booting that computer with a non-signed, not-authenticated CD or USB
OS loader. We anticipate this to be the case with future versions of the Operating System too.

So what does this mean for the Forensic Examiner? When this section in the paper was originally written, it was
found that all common preview Linux CDs like Paladin had problems booting certain Windows Secure Boot sys­
tems. A Windows FE boot CD also failed to boot certain machines. In some cases, the tester was able to press
the <SHIFT> key during boot and be able to have the computer boot using a boot CD or boot USB, in other
cases it was not possible. In some cases, the tester was able to see the BIOS <Function> keys visible during
boot and was able to choose the Boot Menu option and then choose CDROM or USB as the boot device thus
allowing the computer to boot to the Forensic Boot CD Preview operating system; though this was not possible
in all cases. Since then, user access to UEFI/BIOS has become easier, however, "unsigned" Operating Sys­
tems are still prevented from booting the computer unless changes to those settings in UEFI are made.

The Linux community has petitioned hardware manufacturers to allow Linux Boot CDs to be treated as authenti­
cated OS and boot a UEFI Secure Boot system. Since then there are some distributions and other commercial­
ly bootable CDs that have been signed to allow for booting a system with Secure Boot enabled.

There is a way to disable Secure Boot, however, it involves accessing the Advanced Settings in Windows, and
choosing it to boot to the UEFI settings on next boot. This obviously changes your evidence which you may
have to account for at a later time via proper knowledge and documentation. There are some UEFI systems
that will allow you to press <Function> keys during boot to access these settings. As with the <Function> keys
to access the traditional BIOS, there is no set key at this point and is dependent on the make and model of the
computer being accessed. The Examiner would have to research options available for their particular computer
and UEFI to get the proper access options.

So for now, as with anything we do in the field of Digital Forensics, the Examiner should use caution and docu­
ment their every step - especially when trying to preview Windows 8 and newer version machines using boot­
able CDs or USB devices. The best practice of removing a hard drive, attaching it to a write blocker and imag­
ing it is still the best practice. However, there are times when a preview must be done. If it is a Windows 8 or
10 machine that you may be previewing, there is a chance you will boot to the resident Operating System de­
spite best efforts to prevent it from happening. An Examiner must be able to explain why this happened and be
able to document the steps taken during their preview attempt.
It is critical to understand the environment within a digital forensics laboratory. That environment includes the
operating system used to forensically acquire the original evidence. DOS is the last operating system that we
have learned to control how it accesses the original evidence. While DOS is no longer used, the creation of a
DOS-based forensic bootable diskette is an option for a Forensic Examiner should the need arise.

A Forensic Examiner can also create a bootable CD-ROM that can boot a computer system in a forensically
sound manner. During those instances where neither a CD-ROM nor a diskette drive are present on a comput­
er system, a Forensic Examiner now has the tools to create a bootable USB device that can boot a suspect ma­
chine in a forensically sound manner. The creation of a Windows Forensic Edition (WinFE) now also allows Ex­
aminers who are only familiar with the Windows environment to be able to forensically boot a suspect computer
and perform an examination or image of it.

However, as we have seen with the introduction of Windows 8 and the UEFI Secure Boot feature, things change
without notification. What seemed to be acceptable methodology one day could possibly contaminate your evi­
dence the next day.

As with all software and hardware you work with, the authors recommend that you test and validate everything
so that you can defend your analyses and findings.

X. Recommended Resources
• UNetBootln homepage: http://unetbootin.sourceforge.net/

• UNetBootln Wiki on SourceForge: http://sourceforge.net/apps/trac/unetbootin/wiki

• Windows Forensic Environment Homepage: http://winfe.wordpress.com/

• WinFE ForensicWiki: http://www.forensicswiki.org/wiki/WinFE

• Protecting the Pre-OS Environment (2012), Steven Sinofsky, MSDN Blogs

http://blogs.msdn.eom/b/b8/archive/2011/09/22/protecting-the-pre-os-environment-with-uefi.aspx

• Rufus homepage: http://rufus.akeo.ie

--------------- >
IACIS
Tim IfUirmatKXwl Association of
Compute Im-esogairve S p e e d s»

OBJECTIVE
To create a bootable USB (thum b) drive th a t will boot a com puter system into a live CD version of
Paladin.

SUMMARY:
You would be hard-pressed to find a com puter with a diskette drive nowadays; and the newer,
more light-w eight Netbooks are also forsaking the CDROM drive to save on size and weight. In
some cases, removing the hard drive may be either impossible or improbable. There will be tim es
when the only option for the Forensic Examiner would be to boot the com puter using a bootable
USB device th a t has been pre-loaded with a forensic operating system like Paladin.

PRACTICAL SYNOPSIS:
• Use UNetBootln to create a PALADIN bootable thum b drive.
• Use that bootable thum b drive to boot the training laptop

BACKGROUND:
• Paladin (created by Sumuri - w w w .sum uri.com ) is a free modified Live Linux CD used to
forensically image digital media. Paladin allows the user to m ount, image, hash, form at and
sterilize digital media in a forensically sound manner. I t can image to FAT32, NTFS, HFS+ and
EXT3 file systems as either a .E01, DD (raw image), .DMG (Macintosh disk image file) form at or a
physical device (clone). Paladin also allows for two forensic images to be created simultaneously.
• UNETBOOTIN (Universal Network Boot Installer) was w ritten by Geza Kovacs and is a project of
SourceForge that allows you to create a Live USB bootable drive using a variety of Linux flavors.
In our practical, we will be using Paladin.
• A version of UnetBootln can be found at: h ttp ://u n e tb o o tin .so u rcefo rg e .n e t/ (for this
practical, it has already been downloaded for you and is stored on your laptop)
• On your laptop under the BOOT MEDIA PRACTICAL folder, you will find two files.
o UNETBOOTIN
o PALADIN_Edge.ISO
• You will need an em pty USB thum b drive th a t is at least 4GB in size. This drive needs to be
form atted for the FAT32 file system and larger than the size of the ISO. Most thum b drives are
form atted FAT32, however, if yours is not, you can form at it using Windows.

THE BOOT CREATION PROCESS IS NOT SET TO DELETE DATA THAT IS

CURRENTLY ON YOUR USB DEVICE, HOWEVER, IT IS ALWAYS SAFE TO
WORK WITH A CLEAN USB DRIVE. FUTURE VERSIONS OF UNETBOOTIN
MAY CHANGE THE DELETE OPTION - SO PLEASE SAVE YOUR DATA
BEFORE YOU USE YOUR USB DEVICE.
o -------->
IACIS
The tru«na&onal Association of
Conçu•* * toves^p&ré Speoaiss

STEP-BY-STEP PROCESS:
STEP 1 - Form atting the Device:

T h is is NOT required. You w ill lose all yo u r data on the device if you form at it. If you do NOT
w ant to fo rm a t y o u r USB device, skip to STEP 2, how ever, the USB device you use m ust be
form atted as a FAT32 device or else it w ill not w ork.

• Insert the USB device that you want to make bootable into your com puter's USB port.
• Make sure the USB has been recognized and Windows has given it a drive letter.
• Ensure th a t the USB drive has been form atted as FAT32. You can do this by Right+Clicking the
USB drive letter and selecting PROPERTIES (see image below)

• I f not, you can form at it using Windows Explorer. Form atting yo u r drive w ill m ake you lose
everyth in g on it. Make sure you have saved y o u r data elsew here.
• Once your USB device has been form atted and is ready you can start the bootable image process.

• To form at a USB Device, Right+Click on it from the Windows Explorer window and choose FORMAT.
Ensure th a t it says FAT32 as the File System that is being form atted on the USB Device
- Deuces with Removable Storape (4)
US8 DISK R e m o v a l Disk *J
Open
BD-ROM Drive (F:) CD Drive
Open in new window
t U BD-ROM Drive (G:) CD Drive Open AutoPlay...
¡3 .6 0 GB
“ 3
Fée system
^ DVD RW Drive (R:) CD Drive ©Eraser ►
— zi
Share with ► A lo c a to n unit s u e
Open as Portable Device
JS Scan with AVG Free
¡1 6 U o b y te s
3
0 Scan with Matwarebytes* Anti-Malware
R esto re device d efau lts |

V o k m eiab ei

Cut
Copy Format options --------------------------

Paste W Quck Format

F G e i* .; tri BT-OOS sta rtup
Create shortcut
Rename

Properties
iLJâgjLiil I
G — ■>
IACIS
Tfic »ntcrnabcoal Asso caton of
Computer imeshgaM« Speeaksts

STEP 2:
• Open the Boot Media Practical folder on your desktop
o I f you get a User Account Control popup window - choose YES
• Double-click the Unetbootin shortcut
o I f you see a "Security Warning", select RUN to let the program Run•

• From the Unetbootin window (above) click on DISKIMAGE [A]

o We choose Disklmage since we will be working with an ISO image of Paladin to create the
bootable USB device.
• Select ISO from the Diskimage dropdown list [B]
• Use the [...] button and from the DESKTOP folder and BOOT MEDIA PRACTICAL subfolder, select
the PALADIN_Edge.ISO file [C]
• Make sure the Type says USB Drive [D], I f it does not, change it.
o The two options are: USB Drive and Hard Drive.
o You only need a 2GB USB thum b drive to create this bootable USB device, however you can
use a USB hard drive (like a passport drive) if you wish,
o For all destinations connected to the USB port you need to choose USB DRIVE,
o The Hard Drive option is used to install the operating system on an Internal Hard drive
(other than the one that you are currently using)
o From the Drive dropdown box [E], select the drive letter of your destination USB device.
Make sure you have selected YO UR USB DEVICE.
G --------- ^
IACIS
• Your final screen should look som ething like this.
□
Z? UNetbootin

O Distribution = = S d e ct Distribution = = == Select Version ==

Welcome to UNetbootin. the Universal Netboot Installer. Usage:

1. Select a distribution and version to download from the fest above, or manuafly specify files to
load below.
2. Select an installation type, and press OK to beg n insta&ng.

® DtsIdmage [ISO sktop® ootl-tediaPractical'fA lA D IIJ.5.02.iso

Space used to preserve files across reboots (Ubuntu only): 0 : m3

Type: USB Dove ▼ Drive: F:\ OK Cancel

7

• When you are satisfied, click the OK button. •

• When the creation of the USB Boot Media is done, click EXIT to close UNetBootln.

• Safely Remove the USB - using the "Safely remove hardware and eject media" icon at the bottom
right of the task bar
o — >
IA O S
The inierrKrtKxva! Association of
Computer Investigative Speciists

PERFORMING A BOOT OF THE STUDENT LAPTOP USING

THE CREATED USB DEVICE

For The BCFE Student Laptop:

Use the instructions on in this block labeled "How to Change Setup Setting To Allow Laptop To Boot to
USB or CD/DVD" (Page 10 of the Bootable M ini-W inFE practical) to make the proper settings changes in
Setup to allow your USB to boot

• Boot the laptop.

• You may get a message requesting some action on your part to allow the laptop to boot from a
USB device. Follow the instructions.
• I f done correctly, you will see Paladin start to boot.
• Upon completion of the Paladin boot process, you will see the Paladin desktop.

• To shutdown Paladin - click on the PALADIN button on the top LEFT and choose the Power icon

• Ensure that you revert the SETUP setting s to allow you to boot back to W indow s
o This should be at the end of the Bootable Mini-W inFE practical - Page 16

VALIDATION
• As with everything th a t you use in the performance of your duties, it is im portant to validate that
the USB boot device you have created does indeed boot the com puter in a forensically sound
manner.
• To do this in your lab, hash a test machine's hard drive
• Create a USB boot device with the operating system version of your choice
• Boot the com puter using the USB boot device
• Upon successful boot, shut the system down.
• Re-hash the internal hard drive and compare hash values.

It is im portant to re m e m b e r that not all com pu ters allow you to boot via the USB port. M ost
old com pu ters do not have th is capability, and m any new ones m ay list the USB port under
the hard drive in boot priority.

If the com pu ter is set to check the hard drive for a boot code before a USB device, you w ill
end up booting the ta rg et com pu ter using the operating system on the hard drive! You need
to be aw are of how the targ et com p u te r is set to boot and change the boot sequ ence in BIOS
if n ecessary.

USB d evices created using U N e tB o o tln w ill NOT w ork on Macs. The Mac block w ill explain
how you can im age M acs w here hard drive rem oval is im possible or im probable.
o
1/
The Inlematonaf
Inlematjona! Association o?
Coow»rtmvs&gath«Se
peoaiBB

OBJECTIVE
To create a bootable Mini Windows Forensic Environm ent (WinFE) CD using a 90-day trial version
of Window 8.1 and Mini-WinFE Builder.

PRACTICAL SYNOPSIS:
• Configure mini-WinFE Builder to create a Mini-WinFE bootable CD
• Configure the builder to also include FTK Im ager
• Create the ISO and burn it to a CD
• Boot the laptop using the created CD
• Use a drive protect, m ount and permission-change tool to protect the suspect drive
• Mount the suspect hard drive in read-only mode to view data on it
• Mount the drive used to store your evidence

BACKGROUND:
• Troy Larson, Senior Forensic Examiner of Microsoft, created the Windows Forensic Environment
(WinFE) by making two subtle, yet very im portant changes to the Windows Pre-install Environment
(WinPE) registry. These registry changes converted the WinPE environm ent into a WinFE
environm ent.
• The two registry changes are made to prevent the "autom ounting" of attached drives.
• Brett Shavers ( h ttp :// h ttp ://b re ttsh a ve rs.cc ) used the inform ation presented by Troy Larson to
create a batch file to add the appropriate drivers and make the appropriate registry changes to the
"im age" before an ISO of th a t was created to be used in the bootable CD. The configuration of
WinFE and the ISO creation was all done via DOS commands in a DOS-like environm ent.
• A while later, Brett Shavers collaborated with the creators of W inBuilder ( h ttp ://re b o o t.p ro ) to
incorporate these changes into a specialized version of WinBuilder called WinFE WinBuilder.
W inBuilder is a free application designed to build boot disks (Live CDs) based on Microsoft
Windows.
• WinFE W inBuilder is no longer available however Colin Ramsden built a GUI program that would
not autom atically m ount the drives on the com puter and would give the Examiner and easy way to
m ount drives and make them read/w rite enabled. Previously this was done through the command
prom pt.
• W ithout the use of Colin's script, the drives will autom ount and the evidence would be
compromised. Colin has two scripts - one for the full version of Windows the other is a lite
version. The two are NOT interchangeable.
• Sometime in October 2013, Brett Shaver contacted a user on the WinBuilder website named
"m isty" who had created MistyPE. MistyPE is a m inim alistic 32-bit or 64-bit WinPE/WinFE with a
GUI shell called BBLean (based on Blackbox for Windows). Misty was tasked to create a sim ilar
m inim alistic WinFE builder and Mini-WinFE was created •

• For training, we will be using the 90-day evaluation version of Window 8.1 32-bit. This version can
be downloaded from Microsoft's Technet website.
• In a work environm ent, the user is responsible for using licensed copies of the operating system
• We wish to thank Brett Shavers for his assistance with the original batch file th a t was used at
previous training events and for assisting with this practical.
PR EPAR ATIO N A LR EAD Y DONE FOR TH IS P RACTICAL
• Mini-WinFE Builder was downloaded and saved to the C:\Mini-WinFE folder. Note: Mini-WinFE
Builder must run from a folder on the root drive or else it will not run. A shortcut icon to this
program was put on your desktop
• Colin Ramsden script is now part of the Mini-WinFE builder
• For this practical, a copy of the extracted files (not the ISO image) found on the 90-day evaluation
of Windows 8.1 CD are in the C:\Win8Eval folder. This is used by Mini-WinFE WinBuilder to create
the bootable CD.
• An Internet connection may be required to autom atically download needed files from the Internet,
however, for this practical we have downloaded all necessary files to your com puter

• Mini-WinFE builder is a very m inim alistic builder that will let you create a bootable Windows CD
th a t will protect the hard drives from being w ritten to. This version does not allow for many
customizations, however, the full version of WinFE WinBuilder will.

RESOURCES:
• Brett Shaver's website:
o h ttp ://b re ttsh a ve rs.cc
• Reboot Pro Website:
o h ttp ://re b o o t.p ro
• Misty's Mini Win-FE Builder Website:
o http://m istyprojects.co.uk/m istyp e/m ini-w infe.docs/re adm e.h tm l
o — >
TACIS • /■
Coñputef mvessga&ve Speca-sa

STEP-BY-STEP PROCESS:
Step 1: Executing and C onfiguring M ini-W inFE Builder
• On your desktop open the Boot Media Practical folder
• Double click the Mini-WinFE Builder icon - if asked, confirm th a t you want to run the program

izf'v1
Mini WinFE
Builder

• At the window th a t opens (see below):

o Click the SOURCE button [ 1 ]
o Browse the SOURCE DIRECTORY folder [2A] and select where your copy of the Windows CD
files that you will be using for this practical is located. For this practical, the contents of the
CD have been copied to C:\Win8Eval [2] folder and has been selected already
o [3] shows the location and name of the final ISO file th a t will be created during this
process. I f you are creating m ultiple ISOs (in your lab) you should rename them or choose
the appropriate location. We will not make any changes to the name for this practical.
■ For reference: (% Basedir% in this case is: C:\Mini-WinFE)
a
> - WinBuilder (OS2] - □ X

W i n B u i l d e r
0 % © m
BUILD Y O U R E N V I R O N M E N T
vv V Play Tods Download
O Script . S o ire e *
3 Mini-WinFE (2014-07-03)
$17’¿3 Core
& i7 Ó Essential Paths
S 3 Programs Please note that these settings only apply to the currently selected project. Read carefuiy the instructions
S D[7 0 She*.Then.End ms*de each project to better understand which so iree is required. %BaseDir% is a variable which represents
the same folder from where this program is executed. r_ ,
í±. |7 ó Boot.Media
[2A]
Si r Ó Tools
_0 Work directories \7 R utes

Selected project S o u r c e d ir e c t o r y ( % S o u r c e D ir % )
^ Mri-W H=E (2014-07*03)
C:\W n8Eval ^ -------------------------[ 2 ]
S3
Source directory is the folder from where your files w t be copied and used as support
fo r b jJd n g your project.

Target directory (%TargetD«-0/c)

< % Ba se Di r % \Ta rg e t \% Pro j ectTitle%

- £3
Targ e t Directory is the folder where your scripts w id e appled. In most projects it's the
place where your btatd fifes w tfbe placed. j ^^

This project is based on the

McstyPE core. Create ISO fie (%ISOfiie%)
W nFE from Windows
0/oBaseDir<yb\ISO\%ProjectTitletyo.iso
Y»sta\2008\7\S\2012\S.l
mstalation media (DVD,
£3
efese image, network share) Ths is the fie mage used b y CD/D'YD burners to create boot dsks
u -------->
IACIS
7 ' c lnicrn3i)orta! Association of
Computer Im-esôçaüva Specalsts

Step 2: Adding FTK -Im aqer and O ther Softw are To The Build
• Click the SCRIPT tab on top of the main window
• Click the [ + ] next to the Programs folder [4]
• Make sure th a t "FTK Im ager Lite" is highlighted and checked [ 5 ]
• Notice the "Path to FTK Im ager.exe" [ 6 ] field. This is where you would browse to your FTK Im ager
executable file.
• For this practical it has been pre-filled and does not need to be changed

> WinBuilder [082] X

W i n B u i I d
0 % © ®
^
B U I L D T O U R E N V I R O N M E N T

Play Tools Download

i-WnFE (2014-07-03) ,

FTK Imager Lite 4 >

[7
Programs
W n FE Q Forensic tool th a t can create a physical or logical image o f a ny drive, as w et a s capturing
!r , Add Custom Folders’flie s RAM . Image form ats include raw , SM ART form at or E01 format. Tested with version 3.1.1

hr , doneDtsk
! hr DMDE
f7 F.A .U .
WARNING - 32-bit application. To run in a 64-bit build, enable SysW0W64...
1-17' FTK Imager Lite [5]
r7 ... HW M =0
17 LinuxReader
r r j M W Snap FTK website http:./ftvw w .accessdata.com / HELP
17 . NT pass'.vorc Edit
[7 . Opera
[7 Sumatra PDF Reader
r7 Virtual Keyboard (FreeVK) FTK Imager Possible Download link HELP
-1 7 : j Wallpaper
r -j V.rinHex
I Lr ■j X-W ays Forensics
P A T H t o " F T K I m a g e r . e x e ” C: VJsers\StudentT>esktop®oot Media P ra c tK a lfT K Imager Li j
œ170 Shet.Then.End
ffl 170 Boot.Media
i-r ö Tools
[ 6]
ÏA C IS
The »ntemafconaf Association of J/
CcrnçuMt hvesiçaCve Speoahss/y

• Next click the Wallpaper link on the left column. Make sure it is highlighted and checked. [7]
• This is where you would browse to a wallpaper of your Agency or Task Force [ 8 ]
• The dropdown choice of "Custom" must be selected to add a custom background
• For this practical, it has been pre-filled and does not need to be changed.
• For this practical we will check the other boxes as shown in [9] The following programs will now be
part of the CD build
o FAU: a collection of forensic utilities like dd, netcat, wipe etc. by George Garner Jr.
o HWiNFO: System Inform ation and Diagnostics
o LinuxReader: D isklnternals Linux Reader for E xt2/Ext3/Ext4, HFS and ReiserFS File Systems
o MWSnap: A screen capture program
o NT Password Edit: To change Windows logon passwords
o Opera: A web browser
o Sumatra PDF Reader: PDF Reader
o Virtual Keyboard: An onscreen virtual keyboard
• You can also have the builder add Custom Folders or Files to your WinFE build by choosing the
proper option [9A]

'/ WinBuilder [082] □ X

W i n B u i l d e r ► % $ m
B U I L D Y O U R E N V I R O N M E N T
Play Took Download

-0> Script
E [7 i MW-YVnF£ (2014-07-03)
Œ [7 ô Core
(H -J7 ô Essential Wallpaper 4 1

lJ ►
B I7 Ô Programs
vr~ W inFE
Change desktop wallpaper
r Add Custom Folders iFies-«
Walhaper
I.r OoneDtsk
V.1

;r DMDE
w F .A .U .

[9] ; it” FTK Imager Lite

I-17 HW H FO
CUSTO M ^ ] Add Wallpaper? p
!—17 LinujeReader
1-17 M W Snap
} 17 NT Password Edit
17 Opera C:V Jsers’S tu d e n tp e sk to p ® o o t Media Pracfical\WW=E_Ba<| l J Browse to custom .jpg File
17 Sumatra PDF Reader
(7 Virtual K e y b ^ ^ (F re e V K )
[8]

717 3
1 WSnHex
X-W ays Forensics
SheB.7Vien.End
É r 7 c O Soot.M edia
ffi-r_JTools

• NOTE: Some of the above programs selected in [9] may require an Inte rne t connection for the
builder to download them from the In te rn e t if they do not exist in the build. For this practical, they
have already been downloaded to your laptop.
O --------- >
IACIS
The International Association oI
Corpputer Investigative Sp^ötsts

• At this point in this practical, we are ready to create the CD ISO image.
• Click the [+ ] next to Boot.Media and make sure Create ISO [10A] is selected.
o This will let you create an ISO of WinFE so you can create a CD with it.
o The Builder software also allows you to create bootable USBs if you so choose,
o For this practical, we will create an ISO
• Click the Play button [10B]

> W tn B u ild e r [082] □ X

W i n B u i I d e r
B U I L D Y O U R E N V I R O N M E N T [10B i? r © p
Tools Download

I Script & I Source

¡-WinFE (2014-07-03)
I Core
I Essential Create ISO 'l ►
I Programs ft A *“
f ( , WinFE
Create a bootable DVD/CD Image F ie (ISO)
Add Custom FoldersVnles
•... CloneDisk
DI-IDE
r F .A .U .
' FTK Imager Lite
' mm
r , LinuxReader
M W Snap
' ,:j NT Password E d t
r .... O pera Options
' r\ Sumatra PDF Reader
... Virtual K eyboard (FreeVK)
. W allpaper
... W n H e x
., X-W ays Forensics
Shell Then.Fnd
l Boot.Media

Create USB [10A]

Create USB (GPTUEFI)
T - r r r TÜÜ--------------------
ÏA CIS
• Mini-WinFE Builder will start processing the selected scripts
/ W in B u ild e r (082] □

Processing scripts...
A ! selected scripts are being processed, please w ait until this sequence is completed. After it concludes this step you can view more detaied
^ informations inside the log tab.

S c rip t
'< -* # C o re FSes -
j O Essential
Core Files [Core.script]
* RleM anager

p ' BCDEdit
, O-ID Here
L . Keyboard Layout
Netw ork
¡ j SaeenRes 2 / 20 M isty v. 1
Programs
WinFE
Messages
3 F-AU-
. . FTK Imager Lite
H \W O Extracting files from install.wim...
. LinuxReader
. ivT Password Edit
Progress
O pera
Sumatra PDF Ret
;; Virtual Keyboard
r. WaBpaper
> - Q SheH.Then.End , o
• When you see the inform ation window below, click [YES] to continue

Confirm X

Detected the following settings from the source files -

- Architecture=x86
- Language = en-US
- Build = 6.3.9600

Following two settings are user defined -

- Imaged = 2 On boot.wim)
- Method = INJECT

Select YES to CONTINUE - or NO to ABORT

 o I f you are using Windows 7 and prior to create your WinFE CD — this is the version
of Windows that will be on the CD (in our case it is the evaluation version of
Windows 8 ) you will see an information window (below ) explaining that WinFE
builds of Windows7 and prior operating systems will write a disk signature to any
hard drives it encounters that have not had a disk signature written to it. In
testing by the Mini-WinFE Builder creator, this does not happen if the CD is built
using Win8x source files. The Examiner must be aware of this possibility.

o Press [Y E S ] to confirm and continue

• I f this is not the first tim e you are creating a Mini-WinFE CD you will see the message below stating
that a previously created cache file exists. To Continue, press [YES]

• When the script processing is done, the "Processing Scripts" window will change and return you to
the Mini-WinFE Builder window you were on when you pressed the Play button.
• At this point, your CD ISO image has been created and is stored in the
o C:\Mini-W inFE\W inFE.Project.Output folder as shown below:

I 0 t W inFE.Project.Output

File Home Share View

<r - T This PC > A cer(C :) > Mini-W inFE > WinFE.Project

A

A N am e
/S k OneDrive

ISO.ROOT
□ This PC
ROOT
l y l Destaop
LJ WinPE.iso
j js ] Docum ents

4 ' Downloads

• Exit the Mini-WinFE Builder by pressing the [X ] on the top right of the window.
O ------- ■ ' N
IAC1S
Tr>e W em aùonal Association o f
Computer Invesfcçatrvc Speoafcsts

Step 3: Burning a CD from the M ini-W inFE ISO

• Insert a blank CD into your laptop
• W indowslO has the ability to burn a CD from an ISO image w ithout the need for any specialized CD
burning software.
• Open Windows Explorer - the icon is on the bottom left of the taskbar and looks like a file folder
• Navigate to the C:\Mini-W inFE\W inFE.Project.Output folder
• Right+Click the ISO file and choose "Burn Disc Im age" from the sub-menu

WmFE.ProjectOutput Disc !...

Share View Manage

« Mini... > WinFE.Pr... >

A Name

ISO.ROOT
ROOT

3 WinPE.iS'
its M oun t

ds Burn disc image •

[H I Open with Brackets

7-Zip

CRC SHA

a Edit with Notepads-»

C CyoHash

• Do * n o t* verify. You can do that in your lab when you create your field CD.
• On the Image Burner window that opens, click [Burn]

V Windows Disc Image Burner X

Disc image file: WinPE.iso

Disc burner DVD R Drive (F:) ^

Status

To start burning the disc image, click Bum.

□ Verify disc after burning

Bum Cancel

• Once the CD has been successfully created, close all windows

• Perform a Full Shutdow n of W indow s (this m eans keeping the SH IFT key pressed as you
click the Shutdow n button).

• Close the CD-ROM drawer with the CD th a t you created still in it.
• There should be no USB drives connected to the laptop.
o — >
IACIS
Tíic IrtfcrrHrtíonal Association of
Computer Investigative SpecaSs»

How to Change Setup Settings To A llow Laptop To Boot to USB or CD /D VD

The steps in the text box are only for the BCFE O rlando Stu den t Laptops.

As was mentioned in the instruction block, Windows uses the Secure Boot option of a UEFI
enabled laptop to prevent any an unauthorized OS from booting the machine. This
obviously presents a problem in the field and for our practical exercise.

To allow the student laptop to boot to another operating system, the following changes have
to be made to the Setup.
• Ensure that CD-ROM and USB Boot options are enabled
• Change Boot Mode from UEFI to Legacy
• Disable Secure Boot
• Change the boot order to allow a USB or CD to boot prior to the Hard drive
NOTE: Th ese setting s m ay be differen t for oth er m akes and m od els of laptops!

To make the change to SETUP:

a) Power on the laptop and press ESC key to pause startup
b) Press F10 to enter the Setup Menu
c) Using your arrow keys to navigate to SYSTEM CONFIGURATION
d) Arrow down to Boot Options and press [ENTER]
a. Ensure th a t CD-ROM BOOT and USB BOOT are <Enabled>;
if not enable them both

b. Highlight LEGACY BOOT and press [ENTER] an select [ENABLED]

i. Select [YES] on the Warning Window

c. The previous step will autom atically Disable Secure Boot, but if it does not,
Highlight SECURE BOOT and press [ENTER] and select [DISABLED]

d. Under UEFI Boot Order, Arrow down to:

i. Internal CD/DVD ROM Drive and press [F6] to make it Priority 1
ii. USB Diskette on Key/USB and press [F6] to make it Priority 2
iii. USB CD/DVD ROM Drive and press [F6] and make it Priority 3

e. Under Legacy Boot Order, Arrow down to:

i. Internal CD/DVD ROM Drive and press [F6] to make it Priority 1
ii. USB Diskette on Key/USB and press [F6] to make it Priority 2
iii. USB CD/DVD ROM Drive and press [F6] and make it Priority 3

e) Once you are done, Press [F10] to Save and Exit

The laptop w ill now boot and as a secu rity m easure w ill stop m id-boot and tell you
that som eon e has changed the Secu re Boot Mode and to e n ter a code to accept the
change. ENTER THE CODE to com plete the change.

As soon as the laptop boots, press the [ESC] key to get the Boot Menu
G --------->
TAOS
The Internationa: Association of
Cemputer in ve stitiv e S c * « * * »

Step 4: Boot Laptop with W inFE CD

• Power the laptop with the CD in the drive.
• Press F9 to access the Boot Menu (or [ESC] to get the Boot Menu)
• Select Internal CDROM as your boot device
• I f the laptop powers up into the local version of Windows (and not the CD), either the CD was not
created properly or the BIOS settings for boot priority has the hard drive higher than the CD-ROM.
• An Examiner m ust always check the BIOS settings before trying to boot a suspect laptop using a
CD or USB

Step 5: Bootinq M ini-W inFE

Unfortunately there is no indication th a t WinFE is loading (like a spinning wheel or sliding bar), but
after a couple of minutes the screen will change.

• The first screen you should see is this______________________________________________

W A R N IN G

Warning - This write protection tool does not use a kernel mode filter driver
to perform the write protection.

Therefore, it is entirely possible to remove the read-only status of disks by

using other tools or applications.

Known problematic tools and applications that should be avoided are:

Diskpart
Device Manager (Scan for Hardware Changes)
Disk Management

As with any Forensic Boot CD, common sense should be applied at all
times!

OK

This is an warning screen from Colin Ramsden's utility. Read it © and CLICK OK
O ------ '■ ' >
IACIS
The ímematxxiai Assoaa'-oo oí
Ccmpu» invefiigairve Speoafists

• The next screen is the WinFE W rite Protect Tool Management Console Screen [11] (Ramsden's
u tility). It shows you inform ation on the physical storage devices on the com puter
o The status of all attached storage media. Notice th a t they are NOT mounted [12] and they
are set to READ-ONLY [13] from the start
o The buttons on the right [14] will let you manage these devices. You can manage the
devices from this screen but for the purposes of the practical we will do it later
o DiskO is generally the internal HD on the suspect computer. For the practical it will be the
internal HD on your laptop.
o D iskl (assuming there is only 1 hard drive on the suspect machine) will be your external
HD. For the practical, it will be the external USB HD you will connect to your laptop later

• While using WinFE to boot a suspect computer, it is always a good idea to not have any
external drives initially connected to it (like we did). This will give you an idea of how
many hard drives are present in the computer before you connect your "Destination"
hard drive.

• Press CONTINUE [15] to continue with the boot process

o
Iè
lr>o m ier
Composer

• When complete you will see the WinFE desktop

• The desktop is originally em pty, but RIGHT+CLICKing any area on the desktop will give you the
menu as shown below

• Connect the external HD to the laptop once WinFE is done booting.

• This will be known as your DESTINATION drive for the purposes of this practical.

STEP 8: M ounting Su spect & D estination D rives

The first drive you mount will generally be given the drive le tter C:
Since most of us are used to seeing the internal hard drive as C: we will m ount the Suspect Drive (internal
drive) first as Read-Only and then m ount our Destination Drive (in this case the USB Drive) as Read-
Write.
• Open the Menu (Right+Click mouse on the desktop)
• Select FORENSIC TOOLS and then WRITE PROTECT TOOL
• The program window should open. This is Colin Ramsden's W rite Protect Utility

• Notice all disks (in our case DiskO and D is k l) are both Unmounted and Read-Only
1ACIS
The iruematcnai Association o '
C o rn ie r Investigas*# Speoaiists

• Select DiskO (this is your laptop's internal drive - thin k of it as the suspect's internal drive)
o You can click the DETAIL DISK button [16] to see inform ation about the disk if you want
o Make sure the Read-Only Status says YES and click Mount [17]
o Click YES at the warning
o The Mount Status will change to YES

• Select D iskl (in this case, this is the USB drive or the destination drive where you will store any
evidence or your image)
o In an active environm ent, depending on the num ber of drives on the suspect machine your
destination drive may be another Disk number
o Click the Read/Write button [18] so we can w rite to it
o Click YES at the warning
o The Readonly Status should say NO
o Now click the Mount [17] button to m ount the drive
o Click YES at the warning
o The Mount Status should now say YES

Your window should show the disk inform ation as in the image below.
Click Close [19] to close the window.
o -------- >
TAOS
Tro :-!!•-•: ■
.
Canpcr.er Investigative S p eo & ss

STEP 9: Exploring The Su spect Drive

• Right+Click the desktop to get the Menu

• Click on File Manager

C:\

• Notice the drive structure [ 2 0 ]

o NOTE: Y our laptop drive inform ation will d iffe r from the exam ple above
• For the student laptop
o Drive C: is OS partition of the internal drive of the laptop - this is due to the fact that you
mounted that drive first. Had you mounted your destination drive first, it would have been
given the Drive C: label
o Drive D: is your WinFE Boot CD
o Drive E: is the RECOVERY partition of the laptop drive
o Drives F: is the Windows Recovery Environm ent partition on the local drive
o Drive G: is the destination drive (which is mounted Read/W rite)
o Drive X: is the RAM drive th a t contains the WinFE Boot
• Try to create a file on Drive C. I f you properly w rite-protected this drive, you will not be able to.
o (Right+Click on the right column of Drive C. Choose NEW and then TEXT FILE)
• Please do NOT try to delete a file. T h is could cause problem s if you did not p roperly
w rite -p ro tect yo u r C: D rive © ©
• Now try to create a new folder or te xt file for your Destination Drive
o (Right+Click on the right column after Drive G: is selected and choose New and then Text
File or Folder. You should be able to make changes to that drive

• I f you know how to use FTK Im ager, you can Right+Click the desktop and get the Menu and choose
Forensic Tools and then FTK Im ager.
o I f you do not know how to use FTK Im ager, you will learn it later on in the BCFE and you
can try it afte r that.
 • Once the practical is done, Right+Click the desktop to get the Menu and choose SHUTDOWN
• The CD should eject prior to your system shutting down.
• I f the CD does not eject, you will get a chance to eject it when we return the laptop into Windows
UEFI boot mode.

• Once shut down, unplug your external hard drive

• Instruction s below w ill show you how to return the Stu den t Laptop back to W indow s
UEFI boot m ode.

The steps in the text box are only fo r the BCFE O rlando Student Laptops.

R eturning Laptop Boot to UEFI

We need to revert the changes we made to the SETUP to allow us to boot from the CD or
USB back to UEFI-Boot so that you can boot from the Hard Drive.

To make the change to SETUP:

• Boot the Laptop
• Press the [ESC] key and select BIOS SETUP [F10]
• Arrow over to SYSTEM CONFIGURATION
• Arrow down to BOOT OPTIONS
o DISABLE Legacy Support and select [YES] at the warning
o This should autom atically Enable Secure Boot. I f not,
o ENABLE Secure Boot

• Eject the CD from the drive and remove the USB drive if still connected

• Once you are done, choose [F10] (Save and Exit)

The laptop should now reboot to the Hard Drive operating system

Few Points To N o te:

• Mini-WinFE has been tested in various environm ents and operating systems, however, as with any
new tool the Forensic Examiner must test and validate the findings including the performance of
the tools used within this environm ent.
• As of this w riting, Mini-WinFE Builder and the Window 8 Evaluation Versions are free to download
and use and may be used in testing. The Examiner is responsible for m aintaining proper licensing
for all software that is used in an active work environm ent.
• Windows Secure Boot may sometimes prevent the machine from booting to any operating system
other than the one installed on the com puter This can cause the Examiner to contam inate the
evidence. The Examiner needs to be aware of the suspect hardware and OS if possible.

C o n clu sio n :
As is evident, this is another very powerful tool in the Forensic Examiner's kit. Being able to boot into a
forensically sound Windows environm ent, preview a suspect com puter or run FTK imager and other select
programs gives the Examiner a great deal of flexibility and com fort to work with an operating system that
he/she is fam iliar with. H ow ever, and we cannot stre ss th is e n o u g h .... You m ust test and
valid ate every tool and th is one is no e x ce p tio n .
IAGIS
The International Association of
Computer Investigative Specialists
Numbering Systems
Computer Fundamentals

C ontents
I. Synopsis........................................................................................................................................................1
II. Learning Objectives......................................................................................................................................1
III. Bits, Nybbles (Nibbles) and Bytes..........................................................,.................................................... 2
IV. Numeric Systems..................................................... 4
V. Binary Arithmetic and Bitwise Operations.................................................................................................. 11
VI. Advanced Data Types................................................................................................................................ 19
VII. Endianness................................................................................................................................................ 24
VIII. Byte Sweeping........................................................................................................................................... 25

Synopsis

Computer forensics professionals often deal with data at its most basic level. For example, there are times
when one must know the data values at specific locations within data files. There are, in addition, times
when one will need to directly examine the logical structures on a piece of electronic storage media.

Knowing how to work with data at such a level has importance beyond enabling one to perform a proper
computer forensic examination: it also enables one to explain what happens behind the scenes, as it were,
when certain file operations take place. This, in turn, lays the foundation for ones expertise in recovering
data and explaining data recovery processes in legal proceedings.

II. Learning Objectives

At the conclusion of this course the student should be able to:

• Explain the various numbering systems used in computer forensics.

• Perform basic mathematical operations in the numbering systems used in computer forensics.
• Explain the different types of data.
• Understand how to properly interpret data as it is stored in memory and on storage media.
III. Bits, Nybbles (Nibbles) and Bytes

This topic can be quite challenging for those with limited exposure to the field of computer forensics.
However, once the basic principles have been grasped, other topics such as FAT and NTFS, will make
more sense and will be easier to follow. Terms like bit, byte, nybble (pronounced ‘Nibble’), hexadecimal,
Xor, signed, floating-point, twos compliment and bit shift will become second nature.

If in doubt, the Microsoft® Calculator program included with Windows provides programmer calculator
functionality. Just remember to enable the programmer mode.

Calculator -

X
J_______________ k
Select Mode = PROGRAMMER
r

0
HEX 0

DEC 0

O CT 0

BIN 0

i| : v Q W O RD MS

Lsh Rsh Or Xor Not And

M od CE C <3

7 8 9 X

4 5 6 -

1 2 3 +

( ) ± 0 =

Caution: Programmer mode does not provide multiplication or division results as fractional
numbers there is no decimal point, and results are rounded.
-

Almost all conversions performed in this paper can be verified by using Microsoft® Calculator.

The Hex, Dec, Oct and Bin buttons can be used to choose the numeric system used and also convert
between the numeric systems. The And, Or, Xor and Not buttons perform the bitwise operations that their
names suggest. Lsh and Rsh perform left and right bit shifting. After pressing these buttons, you need to
specify the number of binary digits you would like to shift the number.

To start our discussion, the first term we will need know is BIT. A BIT is a Binary digit, and is represented
by either a 1 or a 0. Computers deal only in absolutes. Everything is black or white, right or wrong, left or
right, up or down, on or off, and especially true or false. A nybble is a collection of 4 bits and a byte is a
collection of 8 bits. A classic example of the logic behind bits is a DIP switch.
A dual in-line package (DIP) switch is designed to be used on a printed circuit board along with other
electrical components and is commonly used to customize the behavior of an electronic device.

The pictured DIP switch consists of four switches each capable of being set to either on or off. It’s a
mathematical fact that this DIP switch can be configured in 16 unique positions by manipulating the
switches. Two positions, four switches, 24 = 16. So, with a range of 16, this DIP switch could be used to
represent a number between 0 and 15 or, for example, a letter of the alphabet between A and P.

All switches (or bits) set to off, is represented in binary as 0000 and all switches set to on, as 1111. A
collection of 4 bits can be referred to as a Nybble, or a Nibble (Nybble is used by some to match the spelling
of Byte). The table below illustrates each of the 16 possible bit combinations in a nybble and examples of
some possible numeric and alphabetic values that could be assigned.

Bits Number Letter Bits Number Letter

0000 0 A 1000 8 I

0001 1 B 1001 9 J

0010 2 C 1010 10 K

0011 3 D 1011 11 L

0100 4 E 1100 12 M

0101 5 F 1101 13 N

0110 6 G 1110 14 O

0111 7 H 1111 15 P

So, a nybble (4 bits) is quite limited. Only 16 numbers or letters can be represented by 4 bits. How many
numbers or letters could be represented by 8 bits?

A collection of 8 bits, or two nybbles is commonly referred to as a byte. 28 = 256, therefore a byte can be
used to represent 256 different values.

A standard 3.5 inch floppy diskette contains 1,474,560 bytes of data and yet by today’s standards is widely
considered too small and obsolete. Referring to the capacity of a hard disk in bytes can become rather
 chaotic. The solution is to group together a standard number of bytes together into a larger unit of
measurement.

Name (Symbol) Size in bytes Relative Capacity

Kilobyte (KB) 210 bytes 1024 bytes

Megabyte (MB) 220 bytes 1024 kilobytes

Gigabyte (GB) 230 bytes 1024 megabytes

Terabyte (TB) 240 bytes 1024 gigabytes

Petabyte (PB) 250 bytes 1024 terabytes

Exabyte (EB) 260 bytes 1024 petabytes

Zettabyte (ZB) 270 bytes 1024 exabytes

Yottabyte (YB) 280 bytes 1024 zettabytes

It is far easier to state that a floppy diskette contains 1440 kilobytes or approximately 1.4 megabytes of
data. Today, hard disk drives are measured in terabytes.

IV. Num eric Systems

It is no surprise the decimal numbering system (base 10) is widely used today, considering the fact humans
have 5 digits on each hand: 5 x 2 = 10. Base 10 means that the digits 0-9 are used to express any single
digit in a decimal number. For example, the digits 5 and 4 together express the number fifty-four. Base
10 and the metric system are widespread in our community but if the choice were made again today, would
the world choose base 10 again?

The table below illustrates the four numeric systems referenced in this paper, binary, octal, decimal and
hexadecimal as well as their base and all possible values for any single digit.

Numeric
Base Possible values
System

Binary 2 0, 1

Octal 8 0,1,2,3,4,5,6,7

Decimal 10 0,1,2,3,4,5,6,7,8,9

Hexadecimal 16 0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F
 Humans might find the decimal numbering system quite manageable. Computers on the other hand prefer
to deal in absolutes, for example, on & off, positive & negative or in the case of binary: 1 & 0.

Furthermore, ail measurements in the computer world derive from the base of 2. For example, a single
sector on a hard disk is made up of 512 (or 29) bytes. A kilobyte is made up of 1024 (or 210) bytes. The
typical cluster size used by an NTFS volume is 4096 (or 212) bytes. A 32 gigabyte hard disk comprises of
34,359,738,368 (or 235) bytes.

Although it may not seem the case at the user level, a computer deals only in 1s and Os. The binary
numeric system can be used to express any number in the decimal world using only 1s and Os.

For example, the year 2007 expressed in binary is 11111010111. The user may see the value 2007 on
screen but at the lowest level the computer sees 11111010111.

The octal and hexadecimal numeric systems are a convenient method of representing unmanageable long
binary expressions. Looking back to the earlier reference to 512, 1024, 4096 and 34,359,738,368 decimal
numbers - why would the computer deal with such odd numbers? These numbers are only odd to humans
familiar with the base 10 numeric system. When expressed in hexadecimal, these values are 0x200,
0x400, 0x1000 and 0x800000000 respectively. Suddenly these values begin to make more sense.

This paper looks at binary, octal, decimal and hexadecimal and explains the techniques uses to convert
values to and from these numeric systems.

Decimal Numeric System (Base 10)

The decimal numeric system is used by everyone, every day.

In order to completely understand numeric systems other than base 10 its necessary to unlearn some of
what has been learned about decimal. Reading 54 as “five four decimal” instead of “fifty-four” prepares
ourselves for dealing with other numeric systems.

The next step is to break the value down into its individual digits. Create a table and populate the column
headings from right to left with 10°, 101, 102, etc. One column per digit is required but a few extra columns
help to illustrate the process.
CM
O

1 0 3 1 0 1
O

Many might find it easier to expand these values as illustrated in the second row. For example 103 = 10 x
10 x 10 = 1000 and 102 = 10 x 10 = 100.

103 102 101 10°

1000 100 10 1
 Now, using the value of 54 from right to left, insert one digit in each column. In this example, the digit “4"
is inserted in the rightmost column and the digit “5” is inserted in the column to its left. Zeros are inserted
into the remaining columns.

103 102 101 10°

1000 100 10 1
0 0 5 4

The formula for converting this table back into decimal is as follows:
= (0 x 103) + (0 x 102) + (5 x io 1) + (4 x io°)
= (0 x 1000) + (0 x 100) + (5 x 10) + (4 x 1)

= 50 + 4
= 54 (decimal)

So what has been achieved by this example? Not a lot. The starting value was 54 and so was the final
value. This example demonstrates the process of breaking down numbers into single digits. Everyone
takes for granted that the value of 50 is 10 times larger than the value 5. However, if a numeric system
other than base 10 was being used in this example, this would not have been the case. This technique
will be used extensively when converting between the binary, octal and hexadecimal numeric systems.

Binary Numeric System (Base 2)

The Binary numeric system uses a base of 2. This means that only the digits 0 and 1 can be used to
express numbers. The expression 1010 in the binary numeric system would be pronounced as “one zero
one zero binary”. Determining the decimal value for 1010 binary is very simple when using the conversion
table. Just as before in the decimal example the column headings are populated, this time using 2°, 21,
22, etc. Four columns are required to display 1010.

23 22 21 2°
8 4 2 1
1 0 1 0

This table once expanded reads:

= (1 X 23) + (0 x 22) + (1 X 21) + (0 X 2°)
= (1 x 8) + (0 X 4) + (1 X
2) + (0 X 1)
= 8 + 2
= 10 (decimal)

The same concept is reversed when converting a decimal number into binary. Taking 245 (decimal) as an
example, the first step is to determine how many boxes are needed in the conversion table. Repeatedly
dividing 245 by a factor of 2 until the result is less than 1 reveals 8 repetitions. This is verified because 28
= 256 which is greater than 245. So, a table with 8 columns is required.

27 26 25 24 23 22 21 2°
128 64 32 16 8 4 2 1
 Working with our value of 245, from left to right, if the boxed number can be subtracted from our value then
place a “1" in the box and subtract that number from our value,
eg. 2 4 5 - 128 = 117; 1 1 7 -6 4 = 53; etc. Repeat for all.

128 64 32 16 8 4 2 1
1 1 1 1 1 1

Now, simply fill in the zeros into the blank boxes

128 64 32 16 8 4 2 1

1 1 1 1 0 1 0 1

Finished. The binary representation of the decimal number 245 is 11110101.

This process is complex and is difficult to perform quickly without a calculator. This is because no factor
of 2 equals 10. eg. 23 = 8; 24 = 1

Octal Numeric System (Base 8)

The Octal numeric system uses a base of 8. This means that only the digits 0 through 7 can be used to
express numbers. Octal numbers are often prefixed with a zero as shorthand for octal. The expression
0273 (in octal) should be pronounced as ‘‘two seven three octal” and using the table below, its value in
decimal is determined to be 187.

83 82 81 8°
512 64 8 1
0 2 7 3

= (0 x 83) + (2 x 82) + (7 x 81) + (3 x 8°)

= (0 x 512) + (2 x 64) + (7 x 8) + (3 x 1)
= 128 + 56 + 3
= 187 (decimal)

Binary numbers can be unmanageably long and although perfect for a computer to process can be
extremely difficult for a human to comprehend. Octal can be used instead. Remember that binary uses a
base of 2 and octal a base of 8, so the conversion process from binary to octal is relatively simple, because
23 = 8 .
Hexadecimal Numeric System (Base 16)
The Hexadecimal numeric system uses a base of 16. This is not surprising, as hexa is the Greek root for
6 and deci is the Latin root for 10. Hexadecimalutilizes the decimal digits0 through 9 as well as the first
6 alphabetic characters A through F. It isnecessary to utilize Athrough Fbecause otherwise it is
impossible to represent 10 through 15 with a single digit/character for each.
 Decimal Hex. Decimal Hex.

0 0 8 8

1 1 9 9

2 2 10 A

3 3 11 B

4 4 12 C

5 5 13 D

6 6 14 E

7 7 15 • • F

Hexadecimal digits are often prefixed with the characters “Ox" or suffixed with the character “h” as
shorthand for hexadecimal. The expression 0x3C8F (in hexadecimal) should be pronounced as “three C
eight F hexadecimal” and using the table below, its value in decimal is determined to be 15503.

163 162 161 16°

4096 256 16 1
3 C 8 F

= (3 x 163) + (C x 162) + (8 x 161) + (F x 16°)

= (3 x 4096) + (C x 256) + (8 x 16) + (F x 1)
= (3 x 4096) + (12 x 256) + (8 x 16) + (15 x 1)
= 12288 + 3072 + 128 + 15
= 15503 (decimal)

Long binary numbers are commonly expressed in hexadecimal format as it is far more compact and
readable. Remember that binary uses a base of 2 and hexadecimal a base of 16, so the conversion
process from binary to hexadecimal is relatively simple, because 24 = 16.

Binary/O ctal Conversion

A single binary digit has 2 possible values (0 and 1) and a single octal digit has 8 possible values (0 through
7). This means that a single octal digit can represent three (3) binary digits ( 23 = 8 ). The following
example converts the binary number 1001101010011 to octal, resulting in the value 011523 (octal).

The first step is to break the number into trios (groups of three), from the right.

001 001 101 010 O il

Next, use a three column conversion table for each of the five trios as shown below. Then substitute the
values from the five trios above into the appropriate slots. Treat this step as five individual conversions of
only 3 bits each.

22 21 2° 22 21 2° 22 21 2° 22 21 2° 22 21 2°

4 2 1 4 2 1 4 2 1 4 2 1 4 2 1

0 0 1 0 0 1 1 0 1 0 1 0 0 1 1

Then, expand each trio, resulting in 5 single octal digits.

(0x4)+ (1x4)+ (0x4)+ (0x4)+

(0x4)+ (0x2)+ (0x2)+ (1x2)+ (1x2)+
(0x2)+ (lxl) = (lxl)= (0xl) = (lxl)=
(1 x 1) =

1 1 5 2 3

Resulting in an octal value of 011523.

Converting back to binary is also very simple. Each octal digit can be converted into three binary digits
making the mathematics simple enough to perform without a calculator. For example the octal value
062534. Insert each octal digit in the table below, then, working left to right, one trio at a time, express the
three digital binary equivalent of each octal digit, eg. 6 = 110; 2 = 010; etc.

6 2 5 3 4

4 2 1 4 2 1 4 2 1 4 2 1 4 2 1
1 1 0 0 1 0 1 0 1 0 1 1 1 0 0

The final binary number is 110010101011100.

B in a r y /H e x a d e c im a l C o n v e rs io n
A single binary digit has 2 possible values (0 and 1) and a single hexadecimal digit has 16 possible values
(0 through 9 and A through F). This means that a single hexadecimal digit can represent four (4) binary
digits ( 24 = 16 ). The following example converts the binary number 1001010101101111 to hexadecimal,
resulting in the value 0x956F (hexadecimal).

Firstly, break the number into nybbles (groups of four), from the right.

1001 0101 0110 1111

Next, substitute the values into the conversion table. Four separate conversions each with four bits will
take place.

23 22 21 2° 23 22 21 2° 23 22 21 2° 23 22 21 2°

8 4 2 1 8 4 2 1 8 4 2 1 8 4 2 1

1 0 0 1 0 1 0 1 0 1 1 0 1 1 1 1

Then, expand each nybble, resulting in four hexadecimal digits.

(1x8)+ (0x8)+ (0x8) + (1x8) +

(0x4)+ (1x4)+ (1x4)+ (1x4)+
(0x2)+ (0x2)+ (1x2)+ (1x2)+
(lxl) = (lxl)= (0xl)= (lxl)=

9 5 6 F

Resulting in a hexadecimal value of 0x956F. Note: the last block totals 15 (decimal) which is expressed
in hexadecimal as “F”.
 Converting the example 0xE38A into binary is achieved by reversing the process. Convert each
hexadecimal digit into its binary equivalent.

E 3 8 A

8 4 2 1 8 4 2 1 8 4 2 1 8 4 2 1
1 1 1 0 0 0 1 1 1 0 0 0 1 0 1 0

Therefore, the binary expression of 0xE38A is 1110001110001010.

V. Binary A rithm etic and B itw ise O perations

Arithmetic can be performed on binary values just as on decimal values. The following table summarizes
some of the available arithmetic functions, operators, etc that can be used to manipulate binary values.
Also included is the abbreviation and symbols commonly used to represent each function.

Operation Name Abbreviation Symbol

Addition ADD +
Binary
Arithmetic
Subtraction SUB -

Logical Conjunction AND &

Logical Disjunction OR I
Bitwise
Logical
Operations
Exclusive Disjunction (Exclusive OR) XOR A

Negation NOT ~ or !

Left Shift LSH <<

Bit
Shifting
Right Shift RSH >>
Binary Addition
Adding binary numbers is very simple and very logical. When the decimal numbers 7 and 8 are added,
the answer is 15 but it is necessary to carry the 1 over to the next decimal column. Carrying is also
necessary in binary addition. This example adds the binary numbers 101001 and 1011100. From right to
left, one digit at a time, perform the addition remembering the following rules.

0 +0 =0
0 +1 =1
1 +0 =1
1 +1 =10 (0 and carry 1 to the left)
1 + 1 + 1 = 11 (1 and carry 1 to the left) **

** Note: 1+ 1+1 occurs only when 1 is present in both of the above cells AND when 1 is carried over from
previous column.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

0 0 1 0 1 0 0 1
0 0 1 1 0 0 1 1

Starting with Bit 0, the first operation is 1 + 1 = 10. The 0 is installed in the current cell and the 1 is carried
over to Bit 1.
1

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

0 0 1 0 1 0 0 1
0 0 1 1 0 0 1 1

Repeating this step, whilst remembering to include the carried value results in the following:
1 1 1

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

0 0 1 0 1 0 0 1
0 0 1 1 0 0 1 1

0 1 0 1 1 1 0 0

So, the result of 101001 + 110011 equals 1011100. To confirm this result, convert all three binary numbers
to decimal resulting in the following equation: 41 + 51 = 92.
Binary Subtraction
Subtracting binary numbers works in much the same way as addition. When subtracting decimal numbers
it is often necessary to “borrow 1”. The same is true for binary numbers. This example will subtract the
binary numbers 1101101 and 1010110. From right to left, one digit at a time, perform the subtraction
remembering the following rules.

0 - 0 = 0
0 - 1 = 1 (after borrowing)
1 - 0 = 1
1 - 1 = 0
*0 - 0 = 1 (after borrowing again)
*0 - 1 = 0 (after borrowing again)
*1 - 0 = 0
*1 - 1 = 1 (after borrowing again)

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

0 1 1 0 1 1 0 1
0 1 0 1 0 1 1 0

Starting with Bit 0, the first operation is 1 -0 = 1. The 1 is installed in the current cell. Moving to Bit 1, the
second operation is 0 - 1 = 1 (and borrowing is required). The 1 is installed in the current cell and a *
character is placed above Bit 2 to indicate that borrowing has occurred. The table below reflects these
first two operations.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

0 1 1 0 1 1 0 1
0 1 0 1 0 1 1 0

1 1

Using the rules above the process is repeated for the remaining digits. The * is included, where present,
in the calculations.
★ * *

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

0 1 1 0 1 1 0 1
0 1 0 1 0 1 1 0

0 0 0 1 0 1 1 1

So, the result of 1101101 -1010110 equals 10111. To confirm this result, convert all three binary numbers
to decimal resulting in the following equation: 109 - 86 = 23.
Operator: AND
A single byte consists of 8 bits or 8 on/off switches. Imagine, as a simple example, an employee database
that stores the days of the week each employee is scheduled to work. A single byte can store a true or
false bit value for each day of the week with one bit to spare. Employee X is scheduled to work Monday
through Friday, as illustrated below.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

Free Sun Mon Tues Wed Thurs Fri Sat

0 0 1 1 1 1 1 0

The hexadecimal representation of this binary number is 0x3E. As part of the database function, the
computer needs to check if employee X is scheduled to work on Wednesday. The computer needs a
method of isolating Bit 3 (or Wednesday) from the binary number 00111110.

This can be achieved by using the AND operator and the appropriate bitmask. A bitmask is simply a series
of bits set to either true or false as appropriate. To isolate Bit 3 (Wednesday) in the above example the
bitmask needed would be 00001000. All bits other than bit 3 are set to zero (or false).

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

Data 0 0 1 1 1 1 1 0

Bitmask 0 0 0 0 1 0 0 0

Result ? ? ? ? ? ? ? ?

The AND operator follows the following simple and logical rules:

0 AND 0 = 0 False AND False = False

0 AND 1 = 0 Or False AND True = False
1 AND 0 = 0 True AND False = False
1 AND 1 = 1 True AND True = True

When these rules are applied to each column the result is determined.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

Data 0 0 1 1 1 1 1 0

Bitmask 0 0 0 0 1 0 0 0

Result 0 0 0 0 1 0 0 0

The resulting value equals 00001000. If employee X was not scheduled on Wednesday the result would
have been 00000000. Therefore, in this example, the AND operator and the bitmask 00001000 have been
utilized to isolate Bit 3 - Wednesday. The same principle can be applied to isolate any single bit or any
combination of bits as required.
Operator: OR
The OR operator functions similar to the AND operator. It is used in conjunction with a bitmask. The OR
operator follows these rules:

0 OR 0 = 0 False OR False = False

0 OR 1 = 1 Or False OR True =True
1 OR 0 = 1 True OR False = True
1 OR 1 = 1 True OR True = True

To continue the scenario used in the AND example, imagine employee X currently works on Tuesday and
Thursday only. X is now required to work on the weekend as well so by using the appropriate bitmask, its
possible to set the weekend bits to true without altering the state of the bits for the weekdays. Employee
X’s roster looks as follows:

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

Free Sun Mon Tues Wed Thurs Fri Sat

0 0 0 1 0 1 0 0

The bitmask needed will have all weekday bits set to false and all weekend bits set to true: 01000001.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

Data 0 0 0 1 0 1 0 0

Bitmask 0 1 0 0 0 0 0 1

Result ? ? ? ? ? ? ? ?

By following the rules above, the result will be true if either of the bits are true. The result will be false only
if both bits are false.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

Data 0 0 0 1 0 1 0 0

Bitmask 0 1 0 0 0 0 0 1

Result 0 1 0 1 0 1 0 1

The result of the OR operation is 01010101. Bits 6,4, 2 and 0 are set to true. These bits equate to Sunday,
Tuesday, Thursday and Saturday.
Operator: XOR
The XOR operator is the same as the OR operator with one exception. XOR is shorthand for exclusive OR
meaning one or the other but not both. The rules for XOR are as follows:

0 XOR 0=0 False XOR False = False

0 XOR 1= 1 Or False XOR True = True
1 XOR 0=1 True XOR False = True
1 XOR 1=0 True XOR True = False

Revisiting the employee database scenario yet again, imagine the boss has declared that all employees
must now work Saturday and Sunday. However, anyone already scheduled on for the Saturday or Sunday
is not required to work on that day. Imagine, employee X is currently scheduled to work Wednesday
through Saturday. Employee X's roster would be 00001111.

Using the correct bitmask and the XOR operator, employee X's roster can be updated in one step. The
required bitmask is 01000001, as shown below.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

Data 0 0 0 0 1 1 1 1

Bitmask 0 1 0 0 0 0 0 1

Result ? ? ? ? ? ? ? ?

Using the rules above, the result bit will be true if either of the bits are true but not true if both bits are true.
If both bits are false the result will still be false.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

Data 0 0 0 0 1 1 1 1

Bitmask 0 1 0 0 0 0 0 1

Result 0 1 0 0 1 1 1 0

The good news is that employee X doesn’t need to work Saturday as Bit 0 is now false. The bad news is
employee X has to work Sunday as Bit 6 is true. All other bits are untouched so employee X is still
scheduled on for Wednesday through Friday. XOR is also completely reversible. Applying the same
bitmask to the result above will return the original value.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

Data 0 1 0 0 1 1 1 0

Bitmask 0 1 0 0 0 0 0 1

Result 0 0 0 0 1 1 1 1

Magic! XOR is crucial to encryption. A document (plain text) can be XOR’ed with a bitmask (encryption
key) resulting in an encrypted document (cipher text). The encrypted document can then be XOR’ed with
the encryption key again, resulting in the original document.
Operator: NOT
The NOT operator differs significantly from AND, OR and XOR because it does not require a bitmask. The
NOT operator simply reverses the state of each bit. The rules for NOT are extremely simple. If the bit is
true make it false, if the bit is false make it true.

NOT 0 = 1 Or NOT False = True

NOT 1 = 0 NOT True = False

The boss in the employee database scenario is having a mid life crisis. He has decided that all shifts will
be reversed. Every day that employee X is scheduled on, he will be scheduled off and vice versa. X’s
current roster is Monday, Wednesday and Friday or 00101010.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

Before
0 0 1 0 1 0 1 0
Not

After
1 1 0 1 0 1 0 1
Not

Throughout this scenario using the days of the week, all 8 bits have not been utilized. There are only 7
days in a week and 8 bits in one byte. Therefore Bit 7 has not been utilized yet. Note that after applying
the NOT operator Bit 7 is now set to true. This behavior may be less than desirable. An alternative to
using NOT in this scenario would be to use a bitmask of 01111111 and the XOR operator.

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

Data 0 0 1 0 1 0 1 0

Bitmask 0 1 1 1 1 1 1 1

Result 0 1 0 1 0 1 0 1

The XOR operator and a bitmask of 01111111 provide the same result except that Bit 7 remains
unchanged. This is a better choice in this scenario because only 7 of the 8 bits are utilized. The NOT
operator is also fully reversible. However, the NOT operator would not be a very safe or secure encryption
method.
Bit Shifting
Bits can be shifted in either the left or right direction. Shifting bits left effectively doubles the value of a
number. Shifting bits right effectively halves the value of a number. An example of shifting left is shown
below.

□ □ □ □ □ □ □ □
Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO
□ □ □ □ □ □ □
0 1 0 1 1 0 1 0

1 0 1 1 0 1 0 0

The value before shifting left is 01011010 or 90 in decimal. After shifting one position left the result is
10110100 or 180 decimal. An example of shifting right is shown below.

c c c c c c c o

Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 BitO

□ □ □ □ □ □ □ □
1 1 0 1 1 0 0 1

□ □ m □ m □ ^ D □ □ Ä □
0 1 1 0 1 1 0 0

The value before shifting right is 11011001 or 217 decimal. After shifting one position right the result is
01101100 or 108 decimal. The value has been halved and Bit 0 from the starting value has been discarded.
217 / 2 = 108 remainder 1. The remainder is discarded.

What happens to Bit 7 in the first example and Bit 0 in the second example? There are several different
shifting methods to govern those scenarios. These are not covered in this paper. For further information
see: http://en.wikipedia.org/wiki/Bitwise operation
VI. Advanced Data Types

Nybbles and bytes work great for representing small integer values in binary form. A problem exists when
it is necessary to represent a large integer value, floating point value, or a date and time. More advanced
data types are needed with an increased bit width and an increased value range. Below is a summary of
some of the categories of data types commonly used, together with their corresponding bit widths and
value ranges.

Data Type Width Lowest Value Highest Value

Unsigned Byte 8 bit 0 255

Unsigned Unsigned Short 16 bit 0 65,536

Integer
Values Unsigned Long 32 bit 0 4,294,967,296

Unsigned Quad 64 bit 0 = 1.8 x io 19

Signed Byte 8 bit -128 127

Signed Signed Short 16 bit -32,768 32,768

Integer
Values Signed Long 32 bit -2,147,483,648 2,147,483,647

Signed Quad 64 bit ==-9.2 x 1018 = 9.2 x io 18

Single Precision 32 bit = -3.4 x io 38 = 3.4 x io 38

Floating-Point
Values
Double Precision 64 bit = -1.8x10308 = 1.8x10308

Unix Time 32 bit Year 1970 Year =2038

Date & Time
Values
FILETIME 64 bit Year 1601 Year =20,000

The first group is the unsigned integer values. Unsigned byte (8 bit) values have already been addressed.
Unsigned short uses two bytes to represent its value increasing the limit from 255 to 65,536. Unsigned
long and unsigned quad work with four and eight bytes respectively to further increase the value range.

The second group is the signed integer values. They correspond directly to their unsigned namesakes
except that their range is halved with one half allocated to positive values and the other half to negative
values. See Negative Integers.

The next group is the floating point values. Integer data types are fine for representing whole numbers but
an alternative is needed for fractions and decimal places. For further information on Single Precision and
Double Precision see Floating Point Values.

The last group is the date & time values. Two of the most common types are listed here, Unix Time and
FILETIME. See Dates and Times.
 ASCII and Unicode Text
The examples so far have demonstrated the grouping of bits into nybbles and bytes. By utilizing the full
capacity of one byte it is possible to store any single value within the range of 0 and 255. The English
Alphabet has 52 standard characters [A-Z, a-z], 10 digits [0-9] and numerous punctuation, special
characters and symbols. A standard is needed to govern which character is assigned to which binary
code.

In 1967, ASCII (American Standard Code for Information Interchange) was published as a standard.
ASCII, generally pronounced [’aeski], was later updated in 1986. ASCII currently defines codes for 128
characters. The compact table below displays these 128 characters and the hexadecimal representation
of the binary value for each. For example, the hexadecimal code for the ASCII character ‘M’ is 0x4D (row
4 and column D).

0 1 2 3 4 5 6 7 8 9 A B C D E F

0 NUL SOH STX ETX EOT ENQ ACK BEL BS HT LF VT FF CR SO SI

1 DLE DC1 DC2 DC3 DC4 NAK SYN ETB CAN EM SUB ESC FS GS RS US

2 SP ! it # $ % & i
( )
★ + - • /
•

3 0 1 2 3 4 5 6 7 8 9 i < = > ?

4 @ A B C D E F G H 1 J K L M N 0

5 P Q R S T U V W X Y Z [ \ ]
A
—

6 - a b c d e f h i k 1 m n 0
g j

7 P d r s t u V w X y z { 1 } - DEL

The ASCII standard, as widespread as it is, has one major downfall - it does not cater for languages other
than English. It is not possible to accommodate every character in every language in the world within 128
or even 256 values. So, what if two bytes (16 bits) were utilized for each character? Two bytes means 216
= 65,536 possible values.

The Unicode Consortium, based in California, develops the Unicode standard. The Consortium first
published the Unicode Standard in 1991, and continues to develop standards based on that original work.
Unicode version 9.0 was released June, 2016.

Unicode implements multiple methods of encoding characters for storage to disk. UTF-8 and UTF-16 are
the most common encodings encountered. UTF-8 uses one to four 8 bit values for characters and has
compatibility with ASCII. UTF-16 uses one or two 16 bit values and is the standard format for the Windows
API, Java and the .NET environments.

For further information about the Unicode standard refer to: http://en.wikipedia.org/wiki/Unicode
Negative Integers
There are several ways for binary to represent negative values, all of which utilize the most significant bit
as a sign bit. So, an 8 bit unsigned value effectively becomes a signed 7 bit value. The three techniques
in this example are Sign and Magnitude, One’s Complement and Two’s Complement. All three implement
positive numbers in exactly the same way but they each differ when implementing negative numbers.

Sign and Magnitude implements negative values in exactly the same way as positive values with the only
difference being the sign bit set to 1. So, the 8 bit number +14 using Sign and Magnitude would be
00001110 and -14 would be 10001110. The side effect is being able to represent negative zero. Positive
zero would be expressed as 00000000 and negative zero as 100000000. In reality, zero is neither positive
nor negative.

One’s Complement works in the exact reverse to Sign and Magnitude. Instead of negative zero being
represented by all bits set to 0 (except the sign bit) they are all set to 1. See the table above.

Two’s Complement is identical to One’s Complement with one exception - the negative zero. Instead of
beginning at negative zero, the negative range begins at -1 and is increased by 1. So the range of an
unsigned 8 bit value is 0 through 256 but the range of a signed 8 bit value using Two’s Complement would
be -128 through +127. Two’s Complement is by far the most popular method of representing negative
values and the most likely encountered.

The table above is a scaled down example. Instead of an 8 bit range, this example uses a 3 bit range so
the unsigned range is 0 through 7. Note how Two’s Complement begins at -1 instead of -0 and is able to
represent -4 whereas Sign and Magnitude and One’s Complement both cannot.
Floating Point Values
The Single Precision data type is 32 bits wide and is capable of representing floating point values within
a substantial range with high precision. Single Precision consists of three sections. The first 23 bits (0
through 22) are called the mantissa, the next 8 bits (23 through 30) are called the exponent, and the final
bit (bit 31) is the sign bit. The example below graphically illustrates these sections.

« (8 bits) (23 bits)

exponent mantissa

31 30 23 22 (bit index) 0

The following steps explain how to represent a floating point value in binary and then for simplicity, in
hexadecimal. The value of -462.5625 is used throughout as an example.

1. Determine the sign bit. If the value is negative, the sign bit is set to 1 otherwise the sign bit is
set to 0. Record the sign bit, then discard the sign so the value is always positive.
Sign Bit = 1 ; Value = 462.5625 (decimal)
2. Split the value at the period (7)so thatthe first of the two new values (A) comprises of the digits
to the left of the period and the second new value (B) comprises of the period itself and all digits
to the right.
A = 462 (decimal) ; B = .5625 (decimal) ; Sign Bit = 1
3. Convert value A into binary.
A = 111001110 (binary) ; B = .5625 ; Sign Bit = 1
4. Converting value B into binary is a little more difficult. Double the value of B repeatedly until B
becomes a whole number without any digits to the right of the period and record how many times
B was doubled as value
A = 111001110 ; B = 9 (decimal) ; C = 4 ; Sign Bit = 1
5. Convert value B into
A = 111001110 ; B = 1001 (binary) ; C = 4 ; Sign Bit = 1
6. A new value, (D) will be created using the values of A, B, and C. Append the period to the end
of B and then move the period to the left C times. Next add the value of A.
D = 111001110.1001 ; Sign Bit = 1
7. Next, relocate the period in D to immediately behind the first digit, noting how many positions the
period has moved (E). The value of D is then expressed in the format 1.fraction x 2E and
therefore the value of D has not actually changed - it has merely been written using a different
notation.
D = 1.110011101001 x 2 e ; E = 8; Sign Bit = 1
8. The digits of D to the right of the period become the mantissa bits. Append as many extra Os to
the right as necessary so that the mantissa is 23 bits long.
Mantissa = 11001110100100000000000 ; E = 8; Sign Bit = 1
9. All that remains is the exponent bits. The exponent bits for 32-bit single precision values are
calculated by adding the exponent bias, 127, to the value of E and converting the result to binary.
Sign Bit = 1; Exponent = 10000111; Mantissa = 11001110100100000000000

Now, simply install the Sign Bit, Exponent bits and Mantissa bits into the correct locations illustrated below.
 (8 bits) (23 bits)
S exponent mantissa
+i .......... ..... ..... ..... ..... ..... .................................................. ......................................................................
1 1 0 0 0 0 1 1 1 1 1 0 0 1 1 1 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0

31 23 22 (bit index) 0
30

10. Finally, convert the 32 bit binary string into hexadecimal for improved readability.
11000011 11100111 01001000 00000000 = 0 x C3E74800

The Double Precision data type is 64 bits wide and is capable of representing floating point values with a
far greater range and with far greater precision than single precision. The only differences between the
two, apart from the bit width are:

• There are 52 mantissa bits instead of 23.

• There are 11 exponent bits instead of 8.
• The exponent bias is 1023 instead of 127.

Dates and times

There are a number of ways to represent a date and time using binary digits. Over the years many different
formats have been created with different bit widths and different date ranges. Two of the formats most
likely to be encountered are Unix Time and FILETIME.

The Unix Time date & time format, as the name suggests, is used throughout Unix systems. Unix Time
is 32 bits wide and is measured in 1 second increments from 1sl Jan 1970. The maximum representable
date is 19th Jan 2038. This means that any Unix machines still using this format in the year 2038 will
experience difficulties similar to the y2k problems of 1999.

The FILETIME date & time format is used throughout the Microsoft® Windows Operating System and
applications including the NTFS file system, Windows Registry, Internet History Files, etc. FILETIME is 64
bits wide and is measured in 100 nanosecond increments from 1st Jan 1601. The maximum representable
date exists somewhere around the year 20,000. FILETIME is far more precise than Unix Time and the
range extends much further in both directions.

Converting dates and times into binary digits and back again requires knowledge of the Gregorian calendar
and must factor in the differing number of days per month and leap years. Manual conversion is beyond
the scope of this paper and unfortunately the Microsoft® Calculator program does not support date and
time conversions.

DCode Date is a free download that can be used to perform this function. See below.
 Other date and time formats likely to be encountered are SYSTEMTIME and the DOS date and time format.
The DOS date and time format is used by FAT12/16/32 file systems.

VII. Endianness

Different processor architectures store data in memory in different ways. Motorola processors found in
SPARC machines, SYSTEM/370 machines and older Apple Macintosh machines use Big Endian byte
ordering. Intel x86 processors used in PCs and Intel Macintosh machines use Little Endian byte ordering.

Big Endian uses MSB (Most Significant Byte), storing one byte at a time, starting with the most significant.
Most significant simply means the byte that if changed would alter the value the greatest. In the example
0x12345678, the most significant byte would be the first, ie. 0x12 byte and so the bytes would be stored in
memory in the order 0x12, 0x34, 0x56, 0x78.

Little Endian uses LSB (Least Significant Byte), storing one byte at a time, starting with the least significant
ie. the byte which if changed would alter the value the least. Using the previous example of 0x12345678,
the least significant byte would be the 0x78 byte and so the bytes would be stored in memory in the order
0x78, 0x56, 0x34, 0x12. An important distinction to make is that this value is NOT stored as 0x87654321.
Little Endian means the bytes are stored in the reverse order but the individual bits or nybbles within each
byte do not reverse.

The table below illustrates values of different bit widths and how they would be recorded using big endian
and little endian.

Width Value Big Endian Little Endian

8 bit B5 B5 B5

16 bit 9D27 9D 27 27 9D

32 bit F28B63C0 F2 8B 63 CO CO 63 8B F2

4E72A160CF275
64 bit 4E 72 A1 60 CF 27 5C 58 58 5C 27 CF 60 A1 72 4E
C58

Why does it matter? It matters because after the data is written to memory and in turn written to a digital
media, the user examining the media needs to allow for the endianness in order to correctly interpret the
value.
VIII. Byte Sweeping
Byte sweeping is a process that is commonly used in the Forensic field when conducting in depth analysis
of specific data at the byte level and involves the use of a forensic tool that allows the examiner to highlight
a group of bytes to interpret the value of the bytes. The concept of byte sweeping requires the
understanding of Hexadecimal, Endianness and Based 16 counting, (as described above), as well as
offsets, which will be explained in further detail.

For the purpose of this segment, we will be using WinHex to demonstrate byte sweeping, however most
of the forensic tools on the market today can also be used for this process. This segment is designed to
give you an overview of offset and byte sweeping and not intended to be an instructional document on how
to use WinHex.

Offset(s)

What is an offset? The simplest explanation for an offset is it the address location of a particular byte of
data that is counted relative to the start of the data you are analyzing. For example, if you were looking for
a byte at offset OxOF of a directory entry then you would start counting from the first byte of that particular
entry to OxOF. Always keep in mind the first byte is offset 0x00 and we always count in hex using the base
16 system.

Let's take a look at the beginning of a drive using a Hex viewer.

!'. frei
O ffs e t 0 1 2 3 4 5 6 7 8 9 A B c D E F ' J ® *
m Y MSDOSC; n n
F.-.T
la : is 00000010 02 00 00 00 00 F 8 00 00 3 F 00 FF 00 00 00 00 00 a ? y
00000020 00 E 8 03 00 C9 03 00 00 00 00 00 00 02 00 00 00 e £
00000030 01 00 06 00 00 0 0 00 0Ü 00 0 0 00 00 0 0 00 00 00
00000040 80 00 29 D7 F 5 25 0E 4E 4 F 20 4E 41 4D 4E 20 20 1 ) x o X HO H A K E
a ign a
00000050 20 2 0 46 41 54 3 3 32 20 20 20 3 3 C 9 8E D1 B C F4 FAT32 3 £ liJ* 6
c 00000060 7B 8 E Cl 8E 0 9 BD 00 7C 88 4E 0 2 8A 5 6 4 0 B4 41 { l A l t O i | IN | V ® ’ A
n/ë 00000070 B 3 ÀÀ 55 CD 13 72 1 0 81 FB 55 ÀÀ 7 5 0À F6 C l 01 >>*Ul r u U * u oA
00000080 74 05 F E 46 02 EB 2D 8A 56 40 B4 0 8 C D 13 73 05 t t>F e - I T # ' I s
00000090 B9 F F FF 8A F I 66 OF B6 C6 40 66 O F B 6 D1 80 E2 ■ y y ln £ H*®£ T i J l a
OOOOOOÀO 3F F 7 E2 86 C D CO ED 06 41 66 OF B7 C 9 66 F 7 El ? - r £ l 1 A i A£ ££^6
n/a
000O00B0 66 89 46 F8 83 7 E 16 0 0 75 36 83 7 E 2A 0 0 77 32 £ IF e l~ u 8 l~ * v2
sectb'
ooooooco 66 8B 46 1C 6 6 83 CO oc BB 00 60 B9 01 00 E 8 2B f 1F f 1A » 1 1 e +
000000D0 00 E 9 2C 03 A0 FA 7D B4 7D 8B F0 A C 84 CO 74 17 e. u > '} l6 - | A t
n ao: 000000E0 3C F F 74 09 B4 0 E BB 07 00 CD 10 EB EE
AO FB 7D <yt » 1 e i u>
000000F0 EE E 5 A0 F9 7D E B EO 98 CD 16 CD 19 66
60 80 7E e a u } e a | I 1 f ‘ C~
1.0 K£ 00000100 02 00 OF 84 20 00 6 6 6A 00 66 50 06 53
66 68 10 1 fj £P S £ h
i byte: 00000110 00 01 00 B4 42 8A 56 40 8B F4 CD 13 66
58 66 58 'B | V # | 6 l £X £X
00000120 66 5 6 66 58 EB 33 66 3B 46 F8 72 03 F9
EB 2A 66 £ X £ X e 3 £ ;F e r u e *£
21 ME 00000130 33 D2 66 OF B7 4 E 18 66 F7 FI FE C2 8Â
CA 66 8B 30 £ H £-8HJj A | £ £ 1
: byte: F 7 76 1A D f A 6 -i-v | 0 | V @ | e A
00000140 DO 66 Cl EA 10 86 D6 8A 56 40 8Â E8 CO
25 ME 00000150 E4 06 3A CC B8 01 02 C D 13 66 61 OF 82 75 FF 81 a I, I f a lu y
j bvte: 00000160 C3 00 02 66 40 4 9 75 94 C3 42 4F 4F 54 4D 47 52 l £ @I u 1A b o o t m g r
00000170 20 20 20 20 00 00 00 00 00 00 00 00 00 0 0 00 00
1 02*: 00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
23 93! 00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
23.53- 000001A0 00 00 00 00 00 00 00 00 00 00 00 0 0 OD 0A 52 65 Re
000001B0 6D 6 F 76 65 20 64 69 7 3 6B 73 2 0 6 F 72 20 6F 74 m ove d i s k s o r o t
5 i; 000001C0 68 65 72 20 6D 65 64 6 9 61 2 E F F 0D 0A 44 6 9 73 h e r B s e d i a .y D is
¡7.8QE O O O O O ID O 6B 20 65 72 72 6 F 72 F F 0D 0À SO 7 2 65 73 7 3 20 k errory P ress
£15. 000001E0 61 6E 79 2 0 6B 6 5 7 9 20 74 6 F 30 72 65 73 74 61 any key to re s ta
000001F0 72 74 0D 0A 00 00 00 00 00 A C C B D8 00 00 55 AA rt -E 0 U*

Notice the Offset column in the black box on the left. The first row is all zeros and then the next row is 0x10
and the next is 0x20 and so on. Now look at the values in the top box that start at 0x00 and end with OxOF.
We know the decimal value of OxOF is 15 but there are 16 values listed because we always start at zero.
Likewise the offset for the start of the second row Is 0x10 which has a decimal value of 16.

Most tools will display the offsets the same way you see them above, displaying the row offsets to the left
and the column offsets on the top. This allows you to use the offsets like a grid to navigate to the offset
you are looking for. Note the ASCII values for the data is listed in the column to the right.

So using the same example, if I were to tell you that the file system type that is recorded in the volume can
be located at offset 0x52 and is 5 bytes in length, how would you go about finding the data?

O ffs e t 0 1 2 3 4 5 6 7 8 9 A B C D E F

OO
O O
FAT32 00000000 EB 58 90 4D 53 44 4F S3 35 2E 30 02 02 6E 18 ëX M SD O S5 0 n
IACIS 00000010 02 00 00 00 00 F8 00 00 3F 00 FF 00 00 00 00 0 ? ÿ
00400020 00 E8 03 00 C9 03 00 00 00 00 00 00 02 00 00 00 è E
O o fc p ° 3 0 01 00 08 00 0 0 0 0 00 00 00 00 00 00 00 00 00 00
80 OO r\*? r*r 0c nr 4P 20 4E 4D IF 20 20
original
poooVso 20 20 41 54 33 Æ I20 20 20 33 C9 8E D1 BC F4 I f AT32| 3 Ê |H *4 ô
0 l£ 0 t/ 0 6 0 7B 8t U
TT /C 88 4E 02 8A 56 40 B4 41 { R T T W lltl 1 Vi? ' A
n/a OoVo070 BB hh 55 CD 13 72 10 81 FB 55 AA 75 0A F6 Cl 01 »äül r ûü *u ÖÄ
00 I 00080 74 0 5 FE 46 02 EB 2D 8A 56 40 S4 0 8 C D 13 73 05 t bF ë-iv<r l s
00000090 B9 FF FF 8À F I 66 OF B6 C6 40 66 OF B6 D1 80 E2 ‘ ÿ ÿ ln f fR lâ

Now let’s look at the root directory for a volume.

1 2 3 4 5 6 7 8 9 A B c D E F -
1 °
(¿1 4 0 0 0 0 0 1 41 43 49 S3 20 20 20 20 20 20 08 00 00 00 00 IA C IS
1 49
1 00 00 00 0 0 00 A 9 00 61 6F 3D 0 0 00
0 0 00 0 0 00 @ao= □
00400020 E5 41 43 20 2 0
49 53 20 4À 50 4 7 20
10 14 B6 61 â A C IS JP G ïa
00400030 6F 3D A2 3 E 00 C 7 00 58 4F 3C 03 00 6 C C 2 0 0 00 obc> ÇXO< IA
00400040 E5 55 00 20 00 6 E 00 61 00 6D 0 0 OF 0 0 43 65 CD âe n a » Ce
00400050 2E 00 74 0 0 78 00 74 00 00 00 00 00 F F F F FF FF . t x t yyyy
00400060 E5 69 00 6 3 00 61 00 6C 00 20 00 OF 00 43 6C 00 a i c a 1 Cl
00400070 6F 00 6E 00 6 7 00 20 00 66 00 00 00 69 00 6C 00 0 n g f i 1
00400080 ES 54 00 6 8 00 69 00 7 3 00 20 00 OF 00 43 69 00 àT h i s Ci
00400090 73 0020 00 61 00 20 00 74 00 0 0 00 79 00 70 00 s a t y p
004000A0 ES 4849 53 49 53 7 E 3 1 54 58 54 20 00 Â7 19 64 à H IS IS - lT X T S d
004000B0 30 3 E 30 3E 0 0 00 91 6 1 30 3E 34 00 54 I B 00 00 0>0> 'a 0 > 4 T
004000C0 00 00 00 00 00 CO 00 00 00 00 00 00 0 0 00 00 00
004000D0 00 00 00 00 00 00 00 00 00 00
00 00 0 0 00 00 00
nnannnrn nn nn nn nn nn nn nn nn nn nn nn nn n n nn nn nn

Note the offset to the root directory is 0x400000. This offset value is from the start of the volume.

If a directory entry is 32 bytes how many entries are listed in this volume? I count 6 (see below)
 O ffs e t 0 1 2 3 4 5 6 7 8 9 A B c D E F ' ai -
00400000 49 41 43 4 9 53 20 20 20 20 2020 08 00 00 00 00 IA C IS
00400010 00 00 00 00 00 00 À9 61 6F 3D 00 00 00 00 00 00 ôao* □
00400020 E5 41 43 49 53 20 20 20 4À 5 0 4 7 20 10 14 B6 61 à A C IS JPG la
00400030 6F 3D A 2 00 3E 00 C 7 58 4 F 3C 0 3 00 6C C 2 00 00 o -O cxo< IA
00400040 E 5 65 00 20 00 6E 00 61 00 6D 00 OF 00 4 3 6 5 00 âe n a a Ce
00400050 2 E 00 74 00 7 8 00 74 00 00 00 00 00 FF FF FF FF . t x t yyyy
00400060 E 5 b9 00 6 3 00 61 00 6C 00 20 0 0 OF 00 436C 00 à i c a i C l
00400070 6F 00 6E 00 6 7 00 20 00 66 00 00 00 69 00 6C 00 o n g £ i 1
00400080 E5 54 00 68 00 6 9 00 7 3 00 20 00 O F 00 4 3 6 9 00 a T h i Ci S

00400090 73 00 20 00 61 00 20 00 74 00 00 00 7 9 00 7 0 00 s a t yp
004000À0 E5 48 49 53 49 53 7E 31 54 5 8 54 20 00 A 7 1 9 64 â H I S I S ' 1 T X T § d
004000BO 30 3E 00 00 9 1 6 1
30 3E 30 3 E 34 00 54 IB 00 00 0>0 > ' a 0 >4 T
004000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
004000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

If I were to tell you that the file creation time for the second entry is located at offset OxOE and is two bytes
long, how would we locate the data?

Keeping in mind that the offset given OxOE is from the start of the directory entry, we would locate the start
of the second directory entry 32 bytes in to the root, at offset 0x20 and then from there start counting to
offset OxOE. (see below)

O ffs e t 0 1 2 5 6 7
3 8 9 À B c D E F
4 ' ai - *
00400000 49 41 43 20 20 20
49 20 20 20 00 00 00 00 00
53 IA C IS
O
O

n n N m n in
[0 0 4 0 & B 2 0
00 00 00 00 00 A9 61
E5 41 4 3 49 53 20 20 20
6F 3D 00 00 00 O IL
4À 5 0 4 7 20 10 £ B6
n
à A C IS JP G 51a
6F 3D . A2 3E 00 C 7 584 F 3C 0 3 00 6C c r w
O
O

U Ü V Î0 0 3 0 o * c > ÇXO < IA

00400040 E5 65 00 20 00 6E 00 61 00 6D 00 0F 00 43 6 5 00 àe n a a Ce
00400050 2 E 00 74 00 7 0 00 74 00 00 00 00 00 F F F F F F F F . t x t yyyy
00400060 E5 69 00 63 00 61 00 6C 00 20 00 0 F 00 43 6C 00 ài c a 1 Cl
00400070 6F 00 6E 00 6 7 00 20 00 66 00 00 00 6 9 00 6C 00 o n g f 11
00400080 E5 54 00 6 0 00 69 00 73 00 20 00 Or 00 4 3 69 00 ¿ T h i s Ci
00400090 7 3 00 20 00 61 00 20 00 74 00 00 00 7 9 00 7 0 00 s a t y p
004000AO E5 4 8 49 53 49 53 7E 31 54 58 54 20 00 A7 19 64 â H IS IS ~ lT X T S d
004000BO 30 3 E 3 0 3E 00 00 91 61 30 3 E 34 00 54 I B 00 00 0>0> a0>4 T
004Û 00C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
n ru n n n n n nn nn nn nn nn nn nn nn nn nn nn nn nn nn nn nn

Now that we have located the date and time data in the directory entry we need to interpret the data using
the byte sweeping process.
Byte Sweeping

When you are byte sweeping you are basically highlighting data with a mouse and allowing the forensic
tool to interpret the data. The catch is the direction that you sweep the data will determine if the data is
interpreted in Big Endian (left to right) or Little Endian (right to left).

Using WinHex with the Data interpreter tool turned on lets sweep the same bytes 2 bytes at offset OxOE
and OxOF. Because the this data has to be interpreted in little endian we have to sweep the bytes from
right to left starting at OxOF to OxOE. (see below)

00400000 49 41
43 49 53 20 20 20 20 20 0820 00 00 00 00 IA C IS
00400010 00 00
00 00 00 00 A9 61 6F 3D 0000 00 no nn nn ©ao =
00400020 E5 41
43 49 S 3 20 20 20 4A 50 2047 10 14 B6 61 ¿AC I S JP G Ha
00400030 6F 3D
¿2 3E 00 00 C 7 58 4F 3C
0 3 00 6L L2 VJU UU o=e> CXO< 1Â
00400040 E5 65 00 20 00 6E 00 61 00 6D 00 OF 00 43 &5 00 âe n a m Ce
00400050 2E 00 74
0Q Data Interpreter DO 00 00 FF FF FF FF . t X t yyyy
00400060 E 5 69 00 63 20
00 OF 00 6C43 00 ài c a 1 Cl
8 Bä (t): -74
00
00400070 6F 00 6E DO 00 00 69 00 6 C 00 o n g £ i 1
16 Bä (i): 25014
00400080 E5 54 00 68 pn 00 OF 00 6943 00 ¿ T h i s Ci
00400090 73 00 20
LXJo U3îe. II/IO/^UIU
CO 00 00 79 00 70 00 s a t yp
004000A0 E5 48 49 sl '
B3 54
12:13:44 20 00 A7 19 64 ¿H ISIS ~ 1 T X T § d
004000B0 30 3E 30 3E 3E 34 00 54
I B 00 00 0 >0 > ' a O >4 T
004000CO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Notice the DOS date in the Data Interpreter indicates a value of 11/15/2010 which means date this file was
created was November 15th of 2010. How these two bytes represent this date is explained in detail in the
FAT File System segment of this manual.

Now let’s sweep the same two bytes from left to right or (big endian) and see what value we have get.

00400000 49 41 43 49 53 20 20 20 20 20 20 08 00 00 00 00 IA C IS
00400010 00 00 00 00 00 00 A9 61 6F 3D 00 00 00 nn nn
on
00400020 E5 41 43 49 53 20 20 20 4A 50 47 20 10 B6 61 |a A C IS JP G Ha
00400030 6F 3D À2 3E 00 00 C 7 58 4F 3C 03 00 bL 1 UU UlL 1Â
A
V
0
o

O
X
c

00400040 E5 65 00 20 00 6E 00 61 00 6D 00 OF 00 43 65 00/ âe n a m Ce
004000S0 2E 00 74 00 Data Interpreter (ÏÏ) DO 00 00 FF FF FF FF . t x t yyyy
00400060 ES 69 00 63 20 00 OF 00 43 6C 00 ai c a 1 Cl
00400070 6F 00 6E 00 8 Bä (±): 37 bo 00 00 69 00 6 C 00 o n* g f i 1
16 Bä (»): 28513
00400080 E5 54 00 68 20 00 OF 00 43 69 00 ¿ T h i s Ci
37 fit .1 * 7 3 0 3 7 ^
00400090 73 00 20 our po 00 00 79 00 70 00 s a t yp
o
o

004000A0 E5 48 49 5J 3S 54 20 A7 19 64 ¿H ISIS~ 1 T X T § d
1 V.-: hr. —
004000B0 30 3E 30 3E 3E 34 00 54 I B 00 00 0>0> a0>4 T
nn a nnnr'n nn nn nn nn nn nn nn nn nn nn nn n n nn nn n n nn

Note the date is 01-29-2061 which is not likely correct.

While this is one use for byte sweeping the are many other uses for it depending on what you are trying to
achieve. For example if you want to mark or highlight a segments of data with different colors for reference
or if you need to carve a segment data from an area of the disk and copy it out as its own file then you
would use this method.

As previously mentioned each forensic tool has its own features that use byte sweeping in one form or
another and it is important to learn what each tool is capable of.
Convert the following binary values to decimal values
128 64 32 16 8 4 2 1 Decimal Value
10110101 1 0 1 1 0 1 0 1 181
01101010 0 1 1 0 1 0 1 0 106
11110000 1 1 1 1 0 0 0 0
01010111
11111101
00000011
10000001
00110011
11001100
01011111
01011110
01111111
00111000
11100001
01000010
01000100
11000010
00100010
10000000

Convert the following decimal values to binary.

128 64 32 16 8 4 2 1 Binary Value
73 0 1 0 0 1 0 0 1 01001001
126 0 1 1 1 1 1 1 0 01111110
52 0 0 1 1 0 1 0 0
199
231
92
108
81
66
117
45
129
184
212
36
222
99
12
255
Convert the following Hexadecimal decimal values to binary and decimal.
Binary Decimal
Hex 128 64 32 16 8 4 2 1
Value Value
0x73 1 0 0 1 0 1 1 1 10010111 115
0x10 0 0 0 1 0 0 0 0 00010000 16
0x52 0 1 0 1 0 0 1 0
OxOF
0x18
0x24
0x36
0x47
0x5A
0x6E
0x70
0x84
0x91

2048 1024 512 256 128 64 32 16 8 4 2 1 Binary Dec

0x124 0 0 0 1 0 0 1 0 0 1 0 0 100100100 292
0x104
0x212
0x348
0x571
0x609
0x780
0x857
0x9FA
 In trod uctio n to Forensic Explorer
File Systems

C ontents
I. Synopsis........................................................................................................................................................ 1
II. BCFE Learning Objectives............................................................................................................................1
III. Forensic Explorer Graphical User Interface..................................................................................................2
IV. Forensic Explorer Basics..............................................................................................................................2

I. Synopsis

Forensic Explorer is a forensic software tool for the analysis of digital evidence. It is a tool that will be used
throughout the Disk Structure and File System blocks of BCFE. Forensic Explorer is a versatile tool that
can be used to view the content of an object, such as a physical disk, a volume, or an individual file.

II. Learning Objectives

The aim of this block is to familiarize students with the Forensic Explorer application, and be comfortable
with the following concepts:
• Setting Options
• Changing between Hex and Decimal Views
• Locating specific information through Byte Sweeping
• Bookmarking

Forensic Explorer has many more advanced features, such as searching and file recovery. Some of these
features will be used during the second week of the BCFE course. More information can be found in the
Forensic Explorer manual which is downloadable at http://www.forensicexplorer.com/support.php
The figure below shows the main structure of the Forensic Explorer GUI.

The Home Module is used to create cases and add evidence.

The File Systems Module allows you to browse the contents of selected evidence, in a manner somewhat
similar to Windows Explorer. This module uses a Hierarchal View system, where:

1. The Selection in Folders View controls what is displayed in List View.

2. The item that is selected in the List View will have its contents displayed in the Data View.

There are two selection options in the Folders View:

1. Single Folder View
2. Home Plate Selection, which gives a recursive view. This will display the contents of a folder and
any sub-folders contents also.

When using Home Plate Selection, multiple Folders and Items can be selected at the same time.
Forensic Explorer is a powerful tool, with a wide array of functions. As an introduction to Forensic Explorer,
this block will concentrate on how to manipulate an object to locate specific information within it.

Forensic Explorer has a fairly in-depth manual which can assist in understanding the many different
features of the program. To access this manual, select the '?’ icon on the top bar of the application and it
will automatically be opened as a PDF file.

Installation
Forensic Explorer has limited installation options - in that it is not possible to change all the default paths
at the time of installation. A variety of application data will be saved into folders in the User profile:
C:\Users\%user_fo/der%\Documents\Forensic Explorer. This is referred to as the Working Folder - if you
delete it, the program will not run correctly.

Creating A New Case

Select ‘New Case’ when Forensic Explorer loads up. Populate the ‘New Case’ window with the required
details. You are then taken to the ‘Evidence’ pane where the desired piece of evidence is added. The
‘Evidence Processor’ pane opens and you are able to select and run automated processing tasks.

Or you can enable "Preview” mode in options, and select preview and add evidence to look at an item
quickly.

It is a good idea to save your case to - that allows you to return to it easily. @

Adding Evidence
After a case or Preview has been initiated, the actual items that are going to be examined need to be
added to the case. They can be:

• Device - a physical disk/drive/volume attached to the computer

• Image - a file that can be interpreted as a disk (*.E01, *.E01x, *.VMDK, *.VHD, etc)
• File - a file that will be read as an object (no interpretation like, simply shows Hexadecimal data)

After the evidence has been added to the case, it will be processed, which is a variety of tasks that can be
executed over the evidence by Forensic Explorer which may assist the analysis. Specifics of some of
these tasks will be taught over the next two weeks. Details can be found in the FEX User Manual.
 Evidence Processor [Image: 2gb Teat U5B.EÖI]

(DEFAULT) V
U

Tasks Enabled
B Q FileSystem 0
0 Process in Parallel 0
:> Verify Device Hashes -5> □
0 [,T Search for Known MBRs 0
0 :. r- Search for FileSystems 0
Signature Analysis □
. = Expand Compound Files -5> □
0 <o: Process in Parallel 0
j~ & Triage J 0
¿»}> Hash Files -og* □
¿0= Extract Metadata 3 □
File Carve □
Cache Thumbnails □

Adjust Time Zone Settings

TimeZone: Local Time

TimeZone Name: GMT Standard Time (0 mins)

Daylight Savings: GMT Daylight Time (-60 mins)

STD/DLSBias: 0 /1-60 minutes

Start Cancel

Once the case has been processed select 'File System’ from the Module Ribbon and you are able to
navigate through the various folders and sub-folders of the evidence item you added, much like Windows
Explorer.

The “File List’’ pane shows the contents of a folder. There are different View Options for this Pane, for
example “Gallery View” which shows the pictures within the selected folder (or Folders).
Because of the power of this tool, it will display System Files that you would never encounter in Windows
Explorer. We will learn about many of these over the next two weeks.
 Q File System Keyword Search D Index Search (5) Email [U D Bookmarks

1
Evidence [ g Registry D Rep°

\ i a Q H & © (3 ¡¿3 □
Recover File Shadow Signature Expand Extract Analysis "riage Hash H3Sh * Hash Project Live Boot
Folders Carve Copy Analysis Files Metadata Programs Files Match Set Create VIC

[£] FoWsrs (TI Categories □ N eust Ü3 Gaiery View ^ Disk View Category Graph

Filter: No FSter a ° -(¡ename Logical Si: Physicals X Created ;x Modified

D D ä NTFS Test (1) [Local True] Filename Logical Sue Physical Size Created Modified
9 D D 3 NTFSTest.EOl (3) [LocalTme] D 1 (_. Orphaned 0 0
S D D *3 Partition® 62(11) Q D 2 i_ Root 0 0 23-OCM7 8:23:53 AM 23-Oct-l? 8:25:43 AM
r>l I Orphaned (8)
D D 92 92 28-Oct-17 8:23:58 AM 28-Oct-17 8:25:48 AM

1
3 Root~{S50)
B DDL Root (29) D 4 D Root~S!30(S90) 56 56 23-Oct-17 8:23:58 AM 23 Oct-17 8:25:43 AM
ΠDD SExtend (13)
D 5 □ Root~SS30(SA0) 4,096 4,096 23-Oct-17 8:23:58 AM 23-Oct-17 8:25:43 AM
DD System Volume Information (2)
D 6 D Root~5!30(560) 8 8 23-Oct-17 8:23:5S AM 28-Oct-17 8:25:43 AM
D 7 □ Root~irkF.DATA(5!00) 56 56 23-Oct-17 8:23:58 AM 28-Oct-17 8:25:43 AM
D 3 Unallocated dusters on NTFS vol... 2,041,442,304 2,041,442,304
D 9 1— . Lost OS Clusters 512 512
D 10 Q NTFS Volume Boot Record 512 512
n 44 •
C- - — r —■ >1’ - C41 C4-5
<
11 of 11 Visible[1.90GB]

0 1 -
0 Highlighted [Ob

3 5 c 7 3 5 A 2 c D r A
Jl
Ds
0 00 0:00 00 É2 52 so 4£ 54 4€ 53 20 20 20 20 00 02 03 00 00 |«R. NTFS
0 00 0:00 10 00 00 00 00 00 00 3F 00 FF 00 3Z 00
o
o

?3 00 00 . .o. >. - .

1
? -y
0 00 0:00 20 00 00 00 00 so 00 00 00 42 3c 3D 00 00 00 00 00 A t-
. 0 00 0:00 30 ZD SC 02 00 00 00 00 00 02 00 00 00 00 00 00 00 !..
000 0 :0 0 4 0 Ft 00 00 01 00 00 00 C5 70 S3 8C AA S3 3C 2A 6. . *-P* *1 *
0 00 0:00 50 00 00 00 00 FA 33 CO 20 3C 00 ~c pa €3 CO 07 .Ú3A LûhA.,-----------

Branch Plate
One of the Forensic Explorer’s features is the “branch plate”. When a branch plate is selected, all items
beneath that plate are displayed as a single list in List view. For example, this action can be used to display
the contents of a folder and all its sub folders and files.

To branch plate, click the required plate with the mouse. When the plate turns orange, it is active.

To plate multiple branches;

1. Click the first required plate with the mouse;
2. Hold down the CTRL key and click the other required plates.

©2018 IAC IS Introduction to Forensic Explorer Page 5 of 12

To switch off the branch plate function right click in the File System module Folders View, and select Branch
Plating > Branch Plate Off. When branch plating is turned off the tree works in a similar fashion to Windows
Explorer.

Highlighted and Checked Items

In Forensic Explorer actions are performed on “items”. An item is an addressable piece of data. An item
can be a device (e g. physical drive, logical drive or image file), a file, folder, partition, metadata entry, FAT,
MFT, VBR, MBR, unallocated clusters, directory entry, or other such data.

Highlighted Items
A highlighted item is one that has been selected with the mouse and the item has changed color. It is
possible to highlight one or more items.

To highlight multiple items, you can select the desired files while holding down the Shift key for consecutive
items or hold down the Ctrl key for non-consecutive items.

The information bar at the bottom of the list view identifies the number of highlighted items currently visible
in the File List.
 I File List ▼

83 •= * r * Filename * j- w Ext File Signati

Filename Extension File Signature

□ 25 Q . . A

□ 26 African Elephant.jpg jpg

□ 27 Bottle BrushJPG JPG
□ 28 t ] Buffalo.jpg jpg
□ 29 tj] Canyon JPG JPG
□ 30 Chrysanthemum.JPG JPG
□ 31 i t~] downfish.jpg ] jpg
□ 32 Daisy JPG JPG V

< >
62 of 62 Visible [5.84 GB] 3 Highlighted [2.5 MB] FAT32-Photos.E01\Partition @ t

Checked Items
Individual or multiple files and or folders are checked by ticking its selection box by using the mouse or
Space Bar (and Ctrl or Shift key if required for multiple files).

Pressing the Space Bar will turn the check ticks on or off.

0 User checked item;

m A folder in which not all items inside that folder (or its sub-folders) have
been checked.

Methods of Viewing the Files Content

The bottom of the Data View provides various ways of viewing the content of the item selected in the List
View file, or information about that file. Not all of these will be used during the course.

BE Hex -=: te x t -=- Info JJ_ Bookmark Bvte Plot Display -=■ Filesystem Record ^ File Metadata File Extent

Change Between Hex and Decimal Views

In the Lower pane as shown below, Forensic Explorer will display either hex or decimal values. This setting
will affect the entire program - all other values in the Status bar and Menus will display the same as in the
main pane.

To Switch between Hex and decimal view, simply click the right mouse button in the hex view and select
'Show gutter in decimal’. A tick will appear indicating decimal has been selected, clicking 'Show gutter in
decimal’ again will deselect it and the view will revert to hex. Alternatively, double clicking in the gutter will
change the view between decimal and hex.
 Ö 1 3 4 5 C 7 3 s
1> 10 11 1C 13 14 15
0 ZB 52 90 4Z 54 48 53 CO CO CO 00 02 03 00 00 e R .W T F S
o
1€ 00 00 00 00 00 F3 00 00 3F 00 FO 00 00 C3 03 00 ............... c . . ? . a . . ( . .
3: 00 00 00 00 80 00 30 00 Ar DC 8C 3B 00 00 00 00 ....................... , ~ 0 . ; . . . .
48 00 00 0c 00 00 00 00 00 02 00 00 00 00 00 00 00
€4 :6 00 00 00 01 00 00 00 14 15 BE 63 4D BB 63 cc Ö ................... . . . » h M » h ,
80 00 00 00 00 rA 33 CO 3Z DO 3C 00 7C FB c8 CO 07 . . . . Ü 3A . B- i. lü h Ä .
56 IF IZ €8 66 00 C3 38 18 oz 00 68 81 33 03 00 4Z . . h f . 3 . ____ f . > . . N

IACIS teaches in Hex. It pays to regularly check along the top of the data pane and check that the top row
ends in OxF. If it ends in 15, then you need to change back to Hex mode. Navigating through records is
helped greatly if the data pane is 16 bytes long and sometimes 32 bytes is more useful, you can set these
widths automatically by again right clicking in the data pane and selecting ‘Width 16 bytes’ or Width 32
bytes’.

ULÜJUÜ'UiU ■ w T T ■ w U‘J uu « ~ III Mil 41 Mil U! 1 Mil Mil s . ... 1 a. . : .

0 0 0 0 :00C0 00 00 00 00 30 Bookm ark... > . . .~i
0 0 0 0 :0 0 3 0 00 00 o c 00 00
0 0 0 0 :0 0 4 0 F6 00 00 00 01 M ove to first bookm ark .........
0 0 0 0 :0 0 5 0 00 00 00 00 : A 3 A . B*
0 0 0 0 :0 0 8 0 I F 13 63 66 00 G o to ...
Hi---.
0 0 0 0 :0 0 7 0 54 4 € 53 75 15 Carve selection... ' A » *1
0 0 0 0 :0 0 3 0 55 AA 75 06 r 7 A. .u .
0 0 0 0 :0 0 5 0 13 €3 1A 00 34 H.
Show gutter in decim al
0 0 0 0 :00A0 5F 83 C4 13 53 X.ra;
1>

0 0 0 0 :00B0 OF 00 C l OF Use Decoder > . . . 2c

I'l

0 0 0 0 :00C0 66 r r 06 11 00
0 0 0 0 :00D0 43 00 2B C3 77 Copy as Hex C trkC 'i , . » -
0 0 0 0 : 0030 66 31 TP. 43
0 0 0 0 : 00F0 63 07 BB 16 68 C o p y as Text Sh ift* Ctrl* C
ip . . h .
0 0 0 0 : 0100 55 16 16 16 63 . fa .
0 0 0 0 :0 1 1 0 10 35 D3 OF Width 8 bytes
Cl
CO

ü ö ä e
0 0 0 0 :0 1 C 0 0€ 66 Ä1 11 00 Width 16 bytes
0 0 0 0 : 0130 00 6 6 50 06 53 fh . . h .
0 0 0 0 : 0140 00 16 I F 33 F 4 W idth 32 bytes ii . fY i
0 0 0 0 :0 1 5 0 OF 16 00 66
CO
( 1

y . . . .
C ustom width
0 0 0 0 : 0160 OZ 16 00 7 5 3C .. .fa;
Byte Sweeping
Many files that are encountered in digital forensics are very complex, and hold multiple pieces of
information. The ability to locate specific pieces of information is one of the most important and transferable
skills in this field. When searching across known data structures, there will be tables in the manual that
give an “offset” and a “length" for a discrete piece of information.

An Offset is the amount or distance that something is from a specific location (normally the beginning of a
file or data structure under analysis). So the offset value within a table refers to the distance to go in bytes
from the beginning to locate a specific piece of information (field).

The length is how many bytes are used to store that particular piece of information.
Offset = Where (to start) Length = How Long

The “sweep” is to simply hold the left mouse button down, and “sweep” across the length of data. This will
highlight the hex values.

00000030 | 05 00 00 00 00 00 05 00 3 A O A A 2 B 9 B D 4 F D 3 0 1

Forensic Explorer will also allow you to bookmark the highlighted hex values. To do this, right click on the
highlighted sweep/block of hex values and select 'Bookmark’ and thereafter select one of the options
shown below:

as Hex/ASCII...
as ASCII text...
as Hexadecimal

as FileTime...
as DOS Date...
as DOS Time...

If the Navigation panel is set to 16 bytes in length it assists when sweeping in hexadecimal. If you needed
to sweep 11 bytes (OxB) you would sweep to offset OxA (bearing in mind the count starts at offset 0x0, not
0x1). And if it was 0xB6 (182) bytes you would sweep from offset 0x0 counting down the hexadecimal pane
until you reached OxB then continue sweeping into 0x5. As shown below, underneath the hex pane,
Forensic Explorer shows the starting offset of 0x0 and the sweep was for 0xB6 (182) bytes
 0 1 2 3 4 5 6 7 8s A 2 C " d" 2 F
0000000000 SB 52 90 4S 54 46 53 20 2020 20 00 02 08 00 00
0000000010 00 00 00 00 00 F8 00 00 3F00 FO 00 00 28 - - £ ; a . . <—

CO
o

o
o
0000000020 00 00 00 00 80 00 80 00 AF
D2 8C 3B 00 00 00: 00 .. 6.; ... .
0000000030 00 Ö0 OC 00 00 00 00 00 0200 00 00 00 00 00 00
0000000040 F6 00 00 00 01 00 oo,.öo 1415 BB 68 4D BB €8 2C ö . . . . . . . . . » H M » li,
0000000050 00 00 00 00 FA 33 CO 8E EC 00 7C
DO FB 68 CO 07 . . . . Ü 3 Ä . B V « . | ühÄ .
0000000060 IF lie . .68. 66 00 CB 88 16 OE00 66 81 3E 03 00 4E . . h f . E . . . . f . > . .N
0000000070 54 46V-53: 75 15 B4 41 55 AA55 CD 13 72 OC 81 FB T F S u . ' A » a TJI . r . . 6
0000000080 55 RA 75 06 F7 Cl 01 00 7503 E S DD 00 IE 83 EC D a u . - ^ Ä . . u . e Y ___ i
0000000090 18 68 1A 00 B4 43 8A 16 OE00 8B F4 16 IF CD 13 ,h.. 'H--...6.-1-
ooooooooao SF S 3 C4 18 9E 58 I F 72 El3B 06 OB 00 75 DB A3 . r ä ; . . .uÖ£
0000000020 OF 00 C l 2E OF 00 33 DB 29 00 20 22 C8 . . a __
_________ Z3U1. +2
0 0 0 0 0 0 ooco €3 FF Oc 11 00 03 16'" OF 00 ~Sr7 »FF 06 16 00 23 fy....... Äy. .-e
0 00 00 0 0 ODO 4B 00 22 C3 77 EF 23 00 22 CQy E 23 CO 75 2D K .+ 2 w i, . » I . f#Äu-
Sector: 206848 Offset: 0 (xOO) Selection: 182 (xB6)i Test SSD.E01\Partition @ 20634S
V. Practice Exercise - fex Practice dat

1. Navigate to offset, sweep length (hold left mouse button down)

2. Click on beginning of block and note value in Data Interpreter, record if necessary.
3. Right Click on swept block, select Bookmark
4. Assign a color & bookmark name & folder
5. Click OK21
5
4
3

Length Length
Offset Data Type Value
Decimal Hex

0x110 1 0x01 Number (8 bit) Rugby World Cup wins for South Africa = 2

0x113 1 0x01 Number (8 bit) Rugby World Cup wins for New Zealand = 3

0x130 2 0x02 Integer (16 bit) Number of people who care =

Offset to next data value:

0x150 4 0x04 Number (32 bit)
The paper chase - data is often a pointer to other info

8 0x08 Integer (64 bit) Phone number for translator:

0x0B1 37 0x25 ASCII Why do we use Hex offsets?

Packed byte
0xF1 1 0x01
(binary)

0x1 B0 197 0xC5 Unicode

0x290 4 Ox DOS Date

0x298 8 0x08 FILETIME

0x2B0 16 0x10 GUID

Examine data patterns based on entry length - 16 bytes

0x316 253 OxFD
16 bytes per line aids navigation: OxFD = 15 Lines down, 13 bytes across
32 bytes - What keeps instructors going! I
0x4 8F 720 0x2D0
Change Hex View to 32 bytes per line - Options > General
4 bytes
0x7AC 100 0x64
Change Hex View to 4 bytes per line - Options > General

1. Reset Hex View to 16 bytes per line (easier for navigation)

2. Open Position Manager by clicking Navigation Menu > Position Manager, or by pressing CTRL+M.

Hint: This is where bookmarks can be edited if you make a mistake.

3. Select all bookmarks.
4. Delete all bookmarks.
5. Close Position Manager by clicking on target Icon above ASCII view.
Answer Key

Length Length
Offset Data Type Value
Decimal Hex

0x110 1 0x01 Number (8 bit) Rugby World Cup wins for South Africa = 2

0x113 1 0x01 Number (8 bit) Rugby World Cup wins for New Zealand = 3

0x130 2 0x02 Integer (16 bit) Number of people who care = -1

0x150 4 0x04 Offset to next data value: 0x/170 (3 6 8 )

Number (32 bit)
The paper chase - data is often a pointer to other info
Phone number for translator:
8 0x08 Integer (64 bit)
-1 1 ,2 7 0 ,8 3 5 ,5 6 7 ,1 1 2
Why do we use Hex offsets? C o u n tin g Io n # ¡w eepy
0x0 B1 37 0x25 ASCII
in lln e y ( a n d /p o r tU n c y ) n o tb y t& y
Packed byte
0xF1 1 0x01 10100101
(binary)
T h iy Ly w h a t U n ic o d e *., liy te rV u n fy to - T e jta y
0x1 B0 197 0xC5 Unicode
d ra w l/!

0x290 4 Ox DOS Date 7 F e b ru a ry 20 1 7 15:14:48

0x298 8 0x08 FILETIME 7 F e b ru a ry 20 1 7 15:14:55

15 Je o n 20 1 7 0 8 :0 2 :1 7 +0, Seq: 9190, MAC:

0x2B0 16 0x10 GUID
A26037951F10
Data patterns based on entry length - 16 bytes: New Z e a la n d /M a p
0x316 253 OxFD
16 bytes per line aids navigation: OxFD = 15 Lines down, 13 bytes across
32 bytes - What keeps instructors going! NZ W in e '
0x4 8F 720 0x2D0
Change Hex View to 32 bytes per line - Options > General
4 bytes - USA
0x7AC 100 0x64
Change Hex View to 4 bytes per line - Options > General
 Disk Structures
Partitioning Schemes

Contents
I. Synopsis........................................................................................................................................................2
II. PhysicalDisk Internals.................................................................................................................................. 3
III. Sectors......................................................................................................................................................... 4
IV. Logical Block Addressing (LBA)................................................................................................................... 6
IV. Hidden Sector Data...................................................................................................................................... 7
V. Drive Capacity and "Lost” Drive Space........................................................................................................8
VI. Partitioning....................................................................................................................................................9
VII. Extended Primary Partitions....................................................................................................................... 15
VIII. What is GUID?............................................................................................ .•............................................. 32
IX. GPT Partitions.............................................................................................................................................32
X. Host Protected Areas and DriveConfiguration Overlays............................................................................44
XI. Conclusion................................................................................................................................................. 45
XII. Appendix A - MBR file system type values................................................................................................46
XIII. AppendixB - GPT partition type GUIDs......................................................................................................54
XIV. Appendix C - Class Exercises................................................................................................................... 56
XV. Glossary..................................................................................................................................................... 61
 Synopsis

In 1956, IBM shipped the world's first hard disk drive, or HDD, in the RAMAC 305 system. The drive used
50 24-inch (61-centimeter) platters, stored a meagre 5 megabytes of data and took up more room than two
refrigerators. Oh, and the cost? Just $50,000 ($421,147 in today’s dollars). How things have changed,
today a home user is able to buy a 8 Terabyte capacity drive for under $200 (Dec. 2017).

The term “physical drive” or “physical disk" refers to the hard disk drive itself fresh out of the box including
the pre-formatted organisation characteristics placed on it by the manufacturer. The term “logical drive" or
“logical volume” is the logical structure placed on it during the formatting process so that an operating
system can read and interpret the organisational structure of the data. Users often refer to “C drive" when
in fact it is not a physical “drive", rather it should be the “C Volume” as it is a logical partition placed on the
physical hard drive.

Examiners need to understand how the ‘low-level’ physical structures are laid out on a hard drive, in order
to have a greater understanding of the ’higher-level’ logical structures contained within the Master Boot
Record and the Partition Table. During this paper we will examine both the physical and logical structures
of the hard drive. Having an understanding of how these structures are laid out and more importantly, how
they work together is essential for building a strong foundation in computer forensics.

Learning Objectives
This module will examine in detail the Master Boot Record and Master Partition Table in order to help our
understanding of how data is organized on a physical piece of media. We will then examine in detail
Extended Partitions and how they operate before finally examining the GUID partitioning scheme, which is
becoming more popular.

Upon completion of this module, students should be able to:

• Explain physical disk components

• Explain the difference between SATA and SSD
• Understand Sectors
• Understand the MBR partition system
• Locate and interpret the Master Boot Record & Master Partition Table
• Understand partitions and the difference between a Primary and an Extended partition
• Understand the GPT partition system
• Understand HPA and DCO
 P hysicalD isk Internals

In every memory storage device, the data is written in the form of a magnetic field or electrical charge that
represents an “on" or “off’ value, which we know of as a binary digit or bit.

Hard Disk Drive (HDD)

Traditional hard drives will make use of spinning platters made of rigid
aluminium or glass coated with various forms of a magnetic substrate.
A Hard Disk Drive will be comprised of several platters, which have a
read/write head on each side on an Actuator arm, as shown in Figure
1. The actuator swings across the platter at very high speeds placing
the read or write head in the correct position on the platter allowing the
activity to take place. When the drive is powered off, the Actuator arm
moves the heads away from the platters.
Volee Coll
The mechanical nature of this type of drive limits the speed of data Actuator

read and writes (I/O), and is prone to failure. These drives are easily
H csQ
damaged by movement or mechanical shock. Currently, there are only •Mm»*
three manufacturers of hard disk drives, Western Digital, Seagate
(including its subsidiary brands Maxtor and Samsung), and Toshiba. Figure 1 - Hard Disk Drive

In writing data, positive and negative charges are used to create a controlled magnetic field. Microscopic
pins are either raised or lowered to indicate a zero or one. In reading data, the electrical resistance is read
from the pin to the head to indicate either a 1 or 0 (Figure 2).

Figure 2 - Bits on Hard Disk Drive

Solid State Drive (SSD)

□

Newer physical disks have no moving parts and are

comprised of non-volatile memory chips that retain
information even when they have no power, the same as
USB flash drives. A Solid State Drive (SSD), shown in
Figure 3, has several advantages over the traditional
magnetic hard drive as they do not have any moving
parts.

While a traditional hard drive has ‘drive motors’ to spin

up the magnetic platters and the drive heads, all the
storage on a solid state drive is handled by flash memory Figure 3 - Solid State Drive
chips. This provides four distinct advantages:
 • Less Power Usage
• Faster Data Access
• Higher Reliability
• Light Weight

Solid state drives provide some challenges for forensic examiners in that the semi-conductor chips have
individual erasable segments which become unreliable after a certain number of writes and erasures. To
combat this, the controller on SSDs is programmed with features to improve efficiency and decrease
access times and latency.

A process named WEAR LEVELLING may run. This attempts to evenly spread writes across the chips
employed within the device. This process may take place in the background when the drive is powered,
such as adding power to a drive in order to create a forensic image of it with forensic software.

Other issues with SSD drives are caused by TRIM which identifies areas of the memory chips are no longer
in use and can wipe it at the disk level prior to new writes taking place. This means that areas of unallocated
space can be deleted by the disk.

GARBAGE COLLECTION is another process that may run on an SSD. Data is written in ‘pages’ but it is
deleted in ‘blocks’, which are larger in size and made up of a number of pages. If the drive identifies pages
in a block which are no longer allocated it may write the allocated pages elsewhere and free up the block.
Unlike traditional hard drives, data on SSDs cannot be written to an area unless that area has been
previously deleted.

While these processes allow for built-in storage efficiency, they also interfere with what we have known as
forensically sound methodology when imaging hard drives. These processes are independent of the
operating system. As these processes are programmed on the controller of the SSD, connecting the SSD
to a write blocker will not prevent them from occurring. Therefore, data can be deleted or moved around
without the knowledge of the examiner.

A forensic examiner has an increased probability of MD5 Hash values being mismatched because of these
processes that take place as soon as power is added to the device. It is important that an examiner be
aware of these processes and is able to explain them if such a situation arises. More information on the
above can be found in the Hashing and Hashsets block.

III. Sectors

In order to make data storage device useable, some form of order needs to be applied to it, which we refer
to as the Logical Disk Structure. The Logical Disk Structure allocates areas of the storage device into
individual blocks.

In order to write data to a hard drive there are three processes that must have been undertaken.

• Low-level formatting - organizing the storage area into blocks, called sectors.
• Partitioning.
• High level formatting (Covered in the file system blocks).
When the physical disk is manufactured, the data storage area is divided into equally sized data blocks,
called sectors. A sector is:

• Fixed in size.
• The smallest writeable unit of a physical disk.
• The smallest addressable unit of a physical disk.
• The smallest allocable unit of a physical disk.

Sector Size is Fixed

It is impossible for the user to change the size of a physical disk’s sector, as (in the case of a hard disk
drive) the sector is built into the drive at time of manufacture. In the past, the typical sector size has been
512 bytes, but as data storage has grown, sector sizes have started to grow too. These drives are referred
to as “Advanced Format drives”, and typically have a Sector size of 4096 bytes. They are identified by
either of the labels below.

RDVRNCED

Figure 4 - Advanced Format Drive labels

Smallest Writable Unit

A physical disk will write data in blocks to the storage medium. It will never write a single bit - even if only
one bit of data has been changed. If a physical disk Sector size is 512 bytes, the smallest amount of data
that the disk can write is 512 bytes.

Smallest Addressable Unit

In order to locate data on a physical disk, there needs to be a method of finding where it is placed. Each
Sector is given a unique address on the drive. Older drives used an addressing system called Cylinder
Head Sector (CHS), which was a description of where the sector was physically located within a hard disk
drive, based on the drive’s physical construction. This method was limited to 8 gigabytes.

The CHS size limit has been overcome by what is referred to as Logical Block Addressing (LBA), where
every Sector is given a sequential number, starting at zero. The LBA address is often referred to as the
Physical Address or Physical Sector number of the disk.
Smallest Allocable Unit
Data on a physical disk has to reside in a sector, which we know is fixed in size. If a piece of data is only
one byte in size, it will be allocated to an entire sector. That same sector cannot be used for any other
data, as it is already allocated.

IV. Logical Block A ddressing (LBA)

Logical Block Addressing (LBA) solved the problem for larger capacity drives and is the primary addressing
method. LBA translation is performed by the physical disk controller and the BIOS. It simply treats the
sectors as being linear and numbers each one in sequential order; however, that number is not always
related to its physical location within the physical drive. The LBA numbering system commences at zero
(0); the first Physical Sector on any hard drive is always zero (0), often written as PS 0.

LBA method makes allocating a physical sector much easier because the software does not need to know
the disk geometry only the LBA number.

In order to make this easier to understand, a good analogy is:

• A large warehouse represents the entire hard drive.

• Within the warehouse there are many rows of shelving (racking). Each shelf is fixed in size, and has
its own unique number, allowing for a person to know where everything is stored.

• The number on the shelf will be the equivalent to the LBA address/number.

• Only one “box” can exist on each shelf.

Figure 5 - Sector Representation

Figure 5 above represents the shelving with each sector being numbered. A Sector is the smallest physical
storage unit that is writeable to a hard drive. The most common physical sector size for hard disks is 520
bytes (total), although only 512 bytes are used for the storage of data. The remaining eight bytes are used
for error checking.
 Due to the fact that most files are larger than 512 bytes, it is up to the file system to allocate sectors to
store the file's data.

IV. Hidden Sector Data

The advertised Sector size of a drive (512 bytes, 4K) is not quite completely accurate, as there is also
some additional bytes that are used by the physical disk itself. These additional bytes are invisible to the
user.

A sector is actually comprised of a Sector Header, Data Area, and Error Correcting Code (ECC), as shown
in Figure 6.

• Sector Header- this may contain synchronization bytes, address identification, and an error flag
• Data Area - User viewable storage Area
• Error Correction Code - Contains algorithm result to determine validity of Data Area Content.

Legacy 512Byte Sectors Sector Gap

512B 512B 512B

512B
1 __ £ f 11>12B 512B 512B

4k Advanced Format (with data density equal to current legacy sectors)

a
4096 Bytes (4KB) I* — » 7-11% saving

Key:| = Sync/DAM Data = ECC

Figure 61 - On Disk Sector Structure

Another form of Hidden Sector Data are the “spare" sectors that are within an SSD. Most SSDs will have
more sectors than advertised, which are utilized to replace damaged or faulty sectors. These are invisible
to the user and are entirely managed by the drive controller itself.

The key thing to look for with working with physical disks is to ensure the number of sectors that are
viewable match the disk drive label and manufacturer’s information for that disk.

1http://www.bit-tech.net/hardware/storage/2010/04/01/the-facts-4k-advanced-format-hard-disks/1

© 2018 IACIS Disk Structures Page 7 of 63

V. Drive Capacity and “ L ost” Drive Space

When a manufacturer labels a physical disk, they provide Model and Serial numbers to identify the disk,
and its size in bytes and total sectors. However, when a computer “reads” that disk, the reported size will
be less than what the label advertises. That is due to the manufacturer using a multiple of 10, whereas a
computer calculates data size with a multiplier of 2.

The manufacturer will create a drive and then divide the total size by 1000 to determine how many kilobytes
it can store. However, data is not divided by powers of ten - one kilobyte of binary data is 1024, which is
the value a computer uses to determine how many kilobytes. This difference brought about the unit byte
for digital information standard, which called the binary prefix, and is shown in Table 1.

Decimal Value Metric Prefix Binary Digits Binary Prefix

1 0 *1 0 *1 0 ... 2 * 2 * 2 ...
1,000 kilobyte (kB) 1,024 kibibyte (KiB)
1,000,000 megabyte 1,048,576 mebibyte (MiB)
(MB)
1,000,000,000 gigabyte (GB) 1,073,741,824 gibibyte (GiB)
1,000,000,000,000 terabyte (TB) 1,099,511,627,776 tebibyte (TiB)
1,000,000,000,000,000 petabyte (PB) 1,125,899,906,842,624 pebibyte (PiB)
1,000,000,000,000,000,000 exabyte (EB) 1,152,921,504,606,846,976 exbibyte (EiB)
Table 1 -Binary Prefix

For example, a drive that says it is 1.0 TB in size will actually

be reported as 931.51 Gb by a computer. 1.0TB WD10EADS
llllllllilllllllllllllllllllllllllllllllllllll
S A T A /3 2 M B Cache

S/N : WCAU48336737
• The drive label in Figure 7 shows that it is a 1.0 TB drive jL-npe-ed ars 1ard 2 cab« SSC (Scread SpedfumCock 19)
with 1,953,525,168 sectors. J*r»Mpns3a-d4era:BPUIS(Pwe'Up 'Standby)
Junpe*ecpins5and6enables1.SG8PHY

• Each Sector is 512 bytes, so the drive size is SAUPCWM S iR U C C A H

M D L : W D 1 0 E A D S -0 0 L 5 B 1
FACTORY 4JMPER
* TT* W
1,953,525,168 * 512 = 1,000,204,886,016 bytes inniiiiiiiiiiiiiiiDiiiiiiiiiiiiii
Product warranty w ill be void it seat, Do not cover
label or cover it removed or damaged. any drive bolet.

• Manufacture Size
WWN:50014EE1AC4DB5EB
DATE:20MAR 2009 5VDC :0.70A
1.000. 204.886.016 / 1,000,000,000,000 = 1 TB DCM :DHRNHT2MFN 12VDC:0.55A

I
LBA:1953525168 R/N:701590
U S. Patent*: 6 17 80 5 6.5 95 6 1 96,626948 4. 6263459
956196,628946
Product ol Thailand
• Computer Size Canada ICES - 003 C lata I

1.000. 204.886.016/ 1,073,741,824 = 931.513GiB .......................

NMB - 003 C laate B R oH S I

1.000. 204.886.016/ 1,099,511,627,776= 0.90968 TiB S C M * # c€ WOT-701610(8)

Figure 7 - Drive Label

This difference has caused a lot of confusion, to the point that customers thought that they were being
ripped off by manufacturers. Several lawsuits were brought against storage manufacturers and resulted in
the manufacturer admitting wrongdoing and agreed to clarify their advertising statements and/or add a
disclaimer.

The difference has also been used to try and trip up a computer forensic expert as they give evidence in
court.
VI. Partitioning
The second step in being able to read / write data to a physical drive is called Partitioning. This involves
logically dividing the physical drive into a number of pieces called Partitions. A partition is used to divide
one Physical Drive into multiple Logical Volumes. There are a number of ways to create partitions on a
hard disk, this can involve the use of standard tools such as ‘Diskpart’ within MS Windows or third party
tools (of which there are many) such as PowerQuestPartitionMagic. The remainder of this instruction block
will explore partitions in detail.

Windows Disk Initialisation

Before a user can interact with a physical disk, Windows requires it to be “Initialised". This process is
writing a unique number to identify the disk, called a Disk Signature. This will be written to the Master Boot
Record of a drive, and is why it is important to always use write protection when examining an exhibit.

Master Boot Record (MBR)

The first sector of a drive, commonly called Physical Sector zero (PSO), contains the Master Boot Record
(MBR).The MBR is a critical data structure on the disk that is created when the disk is partitioned.

The MBR contains data needed by the computer to continue operating after the system BIOS finishes
executing its instructions. The MBR contains programming “boot code” and without a MBR, the computer
would stop after the BIOS finished executing its data because it wouldn’t know where to go next to find its
instructions about what to load next. During a computer start-up process, the BIOS loads the MBR into
memory.

The MBR begins in the very first physical sector of the hard drive, PS
O.Typically, the MBR will only fill one sector or 512 bytes of information;
the remaining 62 sectors in the track are reserved, as illustrated in the
picture Figure 8, which relates to a Physical Disk Drive not a Solid State
Drive.

The first 440 bytes (0 to 439) of information is drive identification and

actual programming code or "boot code". This programming code
instructs the system on how to continue the boot process. The code will
vary depending upon the operating system used to setup the MBR.

The next 64 bytes is the Partition Table. The master boot code scans the
Figure 8 - Hard Disk Reserved
partition table for the active partition, locates the starting sector of the
Area
active partition, loads a copy of the boot sector from the active partition
into memory and transfers control to the executable code in the boot sector.

If the master boot code cannot complete these functions, the computer displays a message similar to one
of the following:•

• “Invalid partition table.”

• "Error loading operating system.”
• “Missing operating system.”
The Disk Signature is four bytes long and located at offset 440 (0x1 B8). It identifies the disk to the operating
system. The next 64 bytes consist of the “Master Partition Table" (MPT) (four, 16-byte entries). The last
two bytes of the sector are always hexadecimal 55 AA (0x55AA) (bytes 510 and 511).
For example, a ten-gigabyte hard drive is purchased with the computer. The drive will be setup so that the
entire 10-gigabyte is addressed as a single volume. The details of that partition are stored in the 'Master
Partition Table’, and the operating system would assign “drive letter” such as “C:”.

It is also possible to divide the drive up into multiple sections or partitions. If each partition had a file system
installed, it will be treated by the operating system as a separate ‘Logical Drive’ or ‘Volume’ and a drive
letter will be assigned. They will appear to the user as separate volumes, but in reality, there is only a single
physical drive in the computer. There can be up to twenty-four partitions on a single drive.

Below is a view of the entire Master Boot Record (MBR) in Hexadecimal (Figure 9).

0000000 yilo 33 CO 8E : i BC 00 7C FB- 50 07 ", IF FC BE IB 7C 3A DV 1uF F uV 1 “ A

ooooooc no Br IS 06 50 . . . E5 01-F3 A4 CB BD BE 07 ! I 04 i PV‘ & on£S\i *
0000000 320 r'E 00 7C 09 75 13 83-C5 10 E2 F4 CD 18 8E F5 8n 1 u A àôt 5
0000000 330 83 C6 10 49 74 19 38 2C-74 F6 AO E5 C7 E4 07 8B X I t 8, to u
ooooooc 340 F AC 3C 00 74 FC BB 07-00 B4 OE CD 10 EB F2 ee 6-d tu» 1 to
0000000 350 4E l ■ K. 46 00 7) 2A FE-46 10 80 7E 04 OB 74 OB N eF s'D F - t
ooooooc 360 80 7E 04 OC 74 05 AO B6-07 75 D2 to 46 06 8! - t f UÔ F
ooooooc 370 46 08 i ’ 83 56 OA 00 E8-21 00 73 05 « B6 07 EB F v è' s ï- e
ooooooc 380 BC 81 3E FE 71 55 AA 74-OB 80 7E in 00 74 - t AO U >J>!U*t - tÉ
ooooooc 390 E7 07 EB A'.- 8B r ' IE •57-8B F5 CB BF 05 00 A ( ♦ il U 5Ê<-
ooooooc DaO 00 B4 08 CD : 3 72 23 8A-C1 . •; y • A DE 8A FC 1 i l AC ? l u Bo o t c o d e :
0000000 ObO 43 F7 E3 1 D1 86 D6 B l-0 6 D2 EE 42 F7 E- 39 56 C-& f i Û± ÔÎB-A9V
ooooooc OcO OA 77 23 72 05 39 46 08-73 1C B8 1 1 02 EB 00 7C W # L 9F 3 . » 1
ooooooc DdO 8B 4E 02 8B 56 00 CD 13-73 51 4F 74 4E E4 ■A N V i sQ0tN2a
ooooooc OcO 56 00 CO 13 EB E4 ' A 56-00 ' ■ ‘ i BB AA 55 E4 41 CD V i « V ->,*U AI
0000000 Of 0 13 72 36 81 FB 55 AA 75-30 F6 Cl 01 74 2B •: >.i r6 ùU*uOo t+a
ooooooc 100 6A 00 6A 00 FF 76 OA FF -76 08 6A 00 68 00 7C 6A M F yv J h 11
ooooooc 110 01 6A 10 B4 42 -1 F4 CD-13 61 61 73 OE 4F 74 OB 3 B ¿1 a a î Ot
ooooooc 120 E4 8A 56 00 CD 13 EB-D6 61 F9 C3 49 6E 76 61 2a V i eOaùÂInva
ooooooc 130 6C 69 64 20 70 61 72 74-69 74 69 6F r'F 20 74 61 l i d p a r t it io n ta
ooooooc 140 62 ’ " 65 00 45 72 72 6F-72 20 6C 6F 61 64 69 6E b le Ercor loodin
ooooooc 150 67 20 6F 70 65 72 61 74-69 6E 67 73 79 73 74 <j o p e r a c m g ? y s t
ooooooc 160 65 6D CO 41' 69 73 73 69-6E 67 20 6F 70 65 72 61 e t M i 3 3 i n g o p é r a
ooooooc 170 74 69 6E 67 20 73 79 73-74 65 6D 00 00 00 00 00 t in g systca
ooooooc 180 00 00 00 00 00 00 00 00-00 00 , 00 00 00 00 00
0000000 190 00 00 00 00 00
oooooooKo_ 00 00 00
OOOOOOOlbO 00 00 00
00 00
00 00
00 00 00-00 00
00 00 00-00 00
2 f 44 63-DE IS
00 00 00 00
00 00 00 00
41' 72 00 00
00
00
80
00
00
01
J
OOOOOOOlcO 01 00 07 FE FF FF 3F SÏT-oTT00 38 49 2C 13 00 00 hyy? si.
OOOOOOOldO 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 MPT -
OOOOOOOlcO 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00
OOOOOOOICO 00 00 00 00 00 00 00 00-00 00 00 00 00 00 55 AA „.Ma ster Partition Table

Figure 9 - Physical Sector 0 M B R components

The area highlighted (above) represents the offset 446 - 509 (64 Bytes) and relates to the 'Master Partition
Table’ (MPT) entries, and the MBR ends with 0x55 OxAA.

Master Partition Table

The Master Partition Table (MPT) is 64 bytes in length, and contains four 16 byte entries. The MPT
conforms to a standard layout that is independent of the operating system. A MPT is shown in Figure 10,
where each striped line of 16 bytes in length represents a single partition table entry.

This allows for up to four ‘Primary Partitions’ on a drive - a Primary Partition is a partition that can contain
the computer boot files (i.e. is bootable). To overcome the limitations of only having four partitions, a
different type of partition is allowed, this is known as an 'Extended Primary Partition’, explained later.

o
CO
o

CO
o
OOOOOOOlbO CD 10 3C 75 F4 C3- 6C 6C 00 00 80 01 Î --< uöÄ 1 •1 •

O
AC
OOOOOOOlcO 01 00 07 FE FF FF 3F 00--00 00 EC 68 58 13 00 FE ■fcÿÿ?•• •ihX •
OOOOOOOldO FF FF 83 FE FF FF 00 70--58 13 00 A0 0F 00 00 FE ŸŸ •hŸŸ-pX- •■1?
OOOOOOOleO FF FF 8E FE FF FF 00 10--68 13 00 48 B4 09 00 00 ŸŸ t>ŸŸ- h- •H'
OOOOOOOlfO 00 00 00 00 00 00 00 00--00 00 00 00 00 00 55 AA •U1

Each stripe represents a single partition entry

0x80 - 0x13
0x00 - 0x00
0x00 - 0x09
0x00 - 0x00
Three partition entries with the fourth being empty

Figure 10 - Master Partition Table

There must be at least one ‘Primary partition’ within the MBR and only primary partitions are bootable (can
be used to boot the computer to an operating system). The ‘Extended Primary Partition’ can then be further
split into several smaller partitions, thus allowing up to a total of twenty-four partitions, each partition
assigned an alphabetical drive letter (Drive letters A and B are reserved for floppy disk).

Master Partition Table Entry Structure

Each partition table entry has a specific structure, defining the type of partition to which it refers, where the
partition is located, and its size. The data structure is given in Table 2, and is only applicable to the Master
Partition Table.

Byte
Description
Offset Length
0x00 1 Boot Indicator (0 = Non-Bootable / 80 = Bootable)
0x01 3 Starting CHS value address (redundant)
0x04 1 Partition type
0x05 3 Ending CHS address (redundant)
Start Sector - LBA sector that partition begins
0x08 4
(read little endian)
Total Sectors - number of LBA sectors in partition
OxOC 4
(read little endian)
Table 2 - Master Partition Entry Structure
The Boot Indication byte can be set to either 0x00 or 0x80. If the partition were Active or “Bootable", the
Boot Indicator byte for that partition entry would be set to 0x80. If the partition were “Non-Bootable”, the
boot indicator would be set to 0x00. There can only be one ‘Active Partition' on a drive at any one time.

The Cylinder, Head and Sector (CHS) values are legacy values, for very old and small drives. Modern
hard drives have a large capacity and therefore use Logical Block Addressing (LBA) values, contained in
offset 8 and offset 12 (total 8 bytes).

Relative Sectors is the offset from the beginning of the disk to the beginning of the volume, counting by
sectors. For primary partitions this is relative to the start of the physical disk and for extended partitions
this is relative to the start of the Extended Logical Partition.

Total Sectors is the total number of sectors in the volume.

The System Indicator or Partition Type represents the file system type designated for the partition. These
codes are not completely standardized, but a fairly complete list from Andries Brouwer is listed in Appendix
A, at the end of this paper. Some of the common codes are listed Table 3.

Value File System Type

0x04 DOS FAT 16 (up to 32MB)
0x05 DOS Extended Partition, CHS
0x06 FAT 16 (up to 2 Gig)
0x07 NTFS
OxOB FAT 32
OxOC FAT 32x (LBA of FAT 32 Extended)
OxOF Extended partition, LBA
0x83 Linux
Table 3 - Partition Type Codes

It is possible to create a partition that will be hidden; an operating system may see it, but will not display it
to the user. Table 4 has a list of HIDDEN partition identifiers.

Byte File System Type

0x14 Hidden DOS FAT 16 (up to 32 MB)
0x15 Hidden DOS Extended Partition
0x16 Hidden DOS FATA 16 (up to 2 Gig)
0x1 B Hidden FAT 32
0x1 C Hidden FAT 32x (LBA)
0x1 E Hidden FAT 16, 32 MB-2GB, LBA
0x17 Hidden Windows NT NTFS
Table 4 - Hidden Partition Codes
It should be noted that the value representing the “total sectors" in the partition (Offset OxOC in the PT entry
-Table 2 above) is not the location for the end of the partition, it is just the size of the partition. The examiner
needs to add the number of sectors preceding the partition (63 in this case) to find the end of the partition
and minus 1 from this value to allow for absolute zero counting (i.e. commencing at 0 instead of 1).

Therefore the partition commences at physical sector 63 and concludes at (324,561,132+ 63)-1 i.e. partition
concludes at (324561195 - 1) which is Physical Sector 324,561,194.

To summarize what has been covered so far there are a series of graphical representations to assist the
reader. Figure 12 depicts a newly purchased hard disk, full of empty sectors with no logical structures
applied.

W iT H 'n i n ir ir m T T T T T TTTT r i ■i"H' i H IM VT I ITT x m

Physical Drive (HDD / SSD)

Figure 11 - Physical Drive

Figures 13 through 16 below show four different representations of the same hard disk drive after 1 partition
through 4 partitions were created. The rows of smaller boxes (pink) at the top of each partition represent
the MBR and the reserved sectors of the first track.

• One Logical Volume

:* i i " i i i i i i i i i i i i i i ............ ................... .. 1 1 1 1 1 1 1 1 1 1 1 1

P R IM A R Y P A R T IT IO N

Figure 1211 - Single Primary Partition

• Two Logical Volumes

J i l l ...................... Ml M l ' TTTTTTTTTT-

P R IM A R Y
P R IM A R Y PA R T IT IO N
PA RTITIO N

Figure 123- Two Primary Partitions

• Three Logical Volumes

L L L i. 1 1 1 1 1f 1 1 1 1 1 1 1 I I 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

P R IM A R Y P R IM A R Y
P R IM A R Y PA RT ITIO N
P A R T IT IO N PART ITIO N

Figure 134 - Three Primary Partitions

 Four Logical Volumes

M i l l ................... LI I I I I [... I I I I I II T H T I M I Tl TTTTT

PRIMARY PRIMARY PRIMARY PRIMARY

PARTITION PARTITION PARTITION PARTITION

Figure 145 - Four Primary Partitions

Only one of the primary partitions can be marked as "bootable", also referred to as the active partition, this
is signified by the first byte being set to 0x80. The partition entry slots can be used in any order and it is
not uncommon to see an MPT with a missing entry in the middle of the table.

Master Boot Record Versus Volume Boot Record

A Master Boot Record is only found on a Physical Disk, at PS 0. Each partition will have a Volume Boot
Record (VBR) written to the first sector in the partition Logical Sector 0. A Volume Boot Record VBR will
also be present on a non-partitioned storage device (i.e. Floppy- disk, USB device) where it will be located
in the first sector of the device, instead of the MBR. The Volume Boot Record (VBR) should not be
confused with the Master Boot Record (MBR).

• The Master Boot Record (MBR) is located in the zero sector of the physical drive and contains the
Master Boot Code and Master Partition Table. During the boot process the Master Boot Code
receives control of the boot process from the system BIOS. During the execution of this simplistic
boot code, the partition table is examined to determine if there is an active (bootable) partition listed
in the Master Partition Table. If there is, then the boot process is handed off to the Volume Boot
Record for the active partition. If there isn’t, then the error codes contained within the Master Boot
Code notify the user that the boot process will stop. There is only one MBR on a physical disk.

• The Volume Boot Record (VBR) is always located in the zero sector of the logical volume. The
VBR is created during the high level formatting process of the volume and must be present for a
volume to be assigned a drive letter within the OS. The VBR of a primary partition will contain boot
code needed to continue the boot process if that partition is set as the active primary partition. There
is one VBR for each Logical Volume.•

• It is important to note that removable media (floppy drives, thumbdrives) does not always have an
MBR, in fact, smaller media commonly have only a VBR. In these cases the zero sector of the
physical disk is the same as the zero sector of the logical volume i.e. the first sector on these disks
is the volume boot sector.
VII. Extended Primary Partitions
The concept of only having four partitions on a hard drive is very restrictive. To overcome this problem the
concept of "Extended Primary Partition" was developed. An Extended Primary Partition (EPP) acts as a
container that be further divided into multiple partitions, called Extended Logical Partitions (ELP). This
allowed for a far greater number of partitions and logical drives for the user.

Only one Extended Primary Partition can be created per disk. The partition entry for the EPP is located
within the Master Partition Table (MPT) held within the MBR.

By making use of extended partitions, the hard disk drive can be separated into multiple smaller partitions
but due to the number of letters in the English alphabet (26), only a limited number of ‘Logical Drives’ can
be represented.
The letters “A” and "B” are reserved for floppy drives so the maximum number of ‘Logical Drive’ letters
(including one for the Master Primary Partition) is limited to 24. If a CD-ROM or DVD-ROM device is
installed in the machine, the number of these types of devices reduces the number of available drive letters.
Using Figure 14 above, the maximum number of drive letters that could be assigned within the Extended
Partition would be 22 (26 letters minus the reserved “A” and “B” letters minus the two Primary Partitions
leaves only 22 available letters). It’s also important to know that whilst there MUST be at least one Primary
Partition, only one Extended Partition can exist in the Master Partition Table.

Figure 16 shows a hard drive that has two primary partitions and an extended partition. The Master Boot
Record is shown in PS 0, and each Primary Partition has a Volume Boot Record in the first sector of the
partition.

iiiiiiii ii iiiiim iiiiiic : -L-L.L1J 1..1. I l l 111

H I M ........... I I ........... ■ ai i l ' n i I III I III
PRIMARY
PRIMARY PARTITION EXTENDED PARTITION
PARTITION
—
Figure 156 - Extended Partition (two logical Volumes)

The Extended Primary Partition does not have a Volume Boot Record in the first sector. In order for the
user to make use of the Extended Primary Partition (EPP), it must be divided into smaller (or a single)
Extended Logical Partition(s). This will then allow the user to have a single or multiple Logical drives, as
illustrated in Figure 18.

Figure 167 - Extended Partition with three logical drives (Five logical Volumes)

An Extended Primary Partition does not have its own partition table to designate where each Logical Drive
begins and ends. Instead, each Extended Logical Partition has a pointer to itself and the next ELP, as
demonstrated in Figure 18. The effect is referred to as ’’daisy-chaining”.
 Figure 178 - Daisy chain linking of Logical Partitions in Extended Primary Partition

An Extended Logical Partition will begin with a partition table. There are only two entries in this partition
table, and it has the same data structure as the partition table in a MBR.

The first entry in an ELP partition table points to itself - this is where the Logical Drive begins and there
will be a Volume Boot Record. It also provides the size of the logical drive within the ELP.
The second entry in an ELP partition table points to the next ELP, and provides the size of the entire ELP.

An Extended Logical Partition can be thought of as a Partition Table and a Logical Drive or Volume, as
demonstrated in Figure 19.

1st Extended Partition Current

Table Entry
2nd Extended Partition - Next
F ir s t- Table Entry - Extended Extended
Extended Logical Not Partition Boot
Partition Drive 3rd Extended Partition -
Used Table Record
Table Entry
4th Extended Partition - Not
Table Entry Used
End of Sector Marker - 0x55AA
(Signature Word) Boot
Sector
Data
---- 1st Current M— 1
2nd Next - Extended Extended
3rd Not Used Partition Boot
Second - 4th Not Used Table Record
Logical 0x55AA
Drive
Boot
Sector
Data
Current
---- l s t Not Used
2nd - Extended Extended
3rd Not Used Partition Boot
Last - Table Record
4th Not Used
Logical 0x55AA
Drive
Boot
Sector
Data
 Extended Logical Partition Table

Each Extended Logical Partition table (ELP) contains a Partition Table. The fields in each entry of the
extended partition table are identical to the MBR master partition table entries explained earlier. The
Partition table will have 64 bytes allocated to it (like the MBR MPT) but the entries will differ.

The first entry in an extended partition table refers to itself, detailing the relative offset to its own VBR and
the size of the logical volume. The second partition table entry provides information as to the location of
the next Extended Logical Partition (ELP) within the overall Extended Primary Partition container. Figure
19 illustrates this linked effect. The third and fourth entries in an extended partition table will always consist
of zeros.

Table 5 shows the content of these extended partition table entries.

EPT
Contents
Entry
First entry contains information about the current logical volume in the
extended partition i.e. points to itself.
This includes information on the relative offset to Volume Boot Record.
Note: This offset is relative to the beginning of the extended primary partition
1s' Entry
and not the beginning of the physical drive.
It also provides the total sector size of the logical drive within the ELP. The
value is the number of sectors from the ELP volume boot sector to the end of
the logical drive.
If present this entry contains information about the next logical volume in the
2nd Entry
extended partition i.e. points to next ELP.
3rd Entry Not used
4th Entry Not Used
Table 5 - contents of extended partition table entries

Example of Investigating Extended Partitions

Using the 'DISKPART' command within Windows 10, a user can easily create an EPP within the MBR.

To create an EPP, the command 'Create partition extended size=nnnn' is used. An example is: -
Create partition extended size=61440 (note: Size in MB, so for 60GB - 60*1024=61440MB)

2https://technet.microsoft.com/en-us/library/cc739412%28WS.10%29.aspx#w2k3tr_basic_how_fgkm

© 2018 IACIS Disk Structures Page 17 of 63

A screenshot of the disk is given in Figure 20 of a Physical Drive with six Logical Drives. There are two
'Primary' partitions and one 'Extended' partition containing four Extended Logical partitions, as displayed
through the Disk management utility (note, the Green outline around the Extended Primary Partition).

prinury (K:) New partition lb) EXTENDED ( M l extended 2 Ift) EXTENDED H U ] T E ST N G (P:)
3.05 GB NTFS 3.05 GB NTFS 3.05 GB FAT 3.05GB 14.77GB NTFS 19.60GBFAT32 19.53 GBFAT32 399.63GB
Healthy (Pnmsry Par Healthy (Primary Par Healthy (logical Drr Free space Healthy (Logical Owe) Healthy(logical Drive) Healthy (logical Drive) Unallocated

; Extended primai)1partition containing four logical volum es

Two primary partitions

Figure 180 - Disk Management GUI view of Partitions

In order to further investigate the 'Extended' Primary Partition (as shown above), in this example the
examiner must begin at PS 12,789,760, which is the first sector within the Extended Primary Partition
(EPP) on this drive.

Figure 21 shows the content of PS 12,789,760. There is a partition table located at offset 446, similar to
the Master Boot Record (MBR). It has the capacity to hold a maximum of four partitions but will only ever
hold two, entries three and four are filled with zeros.

y
Of f w t 0 1 4. 3 4 5 6 7 8 9 A B c p E F _ ü
0106500120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
o m s o o n o 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0186500140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1st partition entry relation
0186500150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 to itself (highlighted in
0186500160 00 00 00 00 00 nr 00 00 00 00 00 00 00 00 00 00 Pink)
0106500170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0106500100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0186500190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01665001710 00 00 00 00 00 00 00 00 00 00 00 00 00 oa 'oo
01865001 BO 00 00 00 00 00 00 00 00 00 00 00 00 00 o(r 00 40 «
01865001C0 E5 1C 06 FE FF FF 00 0$ 00 00 00 90 61 00 00 , * byy 9 b 2nd Partition entry relating to the
01C650Ü1D0 F F F F 05 F E F F FF 00 30 C3 00 00 98 DO 01 00 0 ? y y byV u * — next logical dine
01865001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01B65001K0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA u»

Figure 191 - Extended Primary Partition table

The areas highlighted represent two partition table entries, and is the same structure as an MBR partition
entry. The main point to note is the offset refers to the beginning of the Extended Primary Partition and not
the beginning of the physical drive (i.e. Physical sector 0).

Extended Logical Partition 1

First partition table entry: (relating to itself, the first Extended Logical Partition)
• Partition Type =0x06, FAT16 partition.
 • Sectors preceding partition 1 = 2,048. The Logical Drive begins at Sector 2048, relative to the start
of the EPP. (2048 sectors reserved between the beginning of the ELP and the VBR)

The Physical Sector Address for the VBR for the Logical Drive will be at 12,789,760+2,048 =12,791,808.
The VBR is located physical sector 12,791,808 - Physical Sector means relative to the start of the drive
(LBA).

• Sectors in Partition 1 = 6,393,856sectors in the Logical Drive. The entire Extended Logical Partition
is 6,393,856 + 2,048 = 6,395,904 sectors.

In summary, the first Extended Logical Partition (ELP) commences at Physical Sector 12,789,760 and
stops at PS 191,856,663 (12,789,760+2048+6,393,856 - 1).

Figure 23 below is a screenshot showing the VBR located at PS 12,791,808.

cb l 8 6 5 £ £ £ e 0 6 A 4E I S AD B 7 ID 3C 7 5 - C 1 2 0 E 3 57 BD E 6 7C 8A J N -< u  S U H ë !
01865££££0 9 4 A F 5A A l F 8 9 8 1 7 A l - D E 9 S AB 1A 6 6 6 F I F 6D ~ Z ,e ■ ■¡P « t o B
0 1 8 6 6 0 0 0 0 0 EB 3C 9 0 4D S 3 4 4 4 F S 3 - 3 S 2E 3 0 0 0 0 2 8 0 0 8 0 0 é < H S D 0 S 5 .0 ..............
0186600010 0 2 0 0 0 2 0 0 0 0 F8 C 4 0 0 - 3 F 0 0 F F 0 0 0 0 0 8 0 0 0 0 ..............« À ? ÿ ...............
0186600020 0 0 9 0 6 1 0 0 8 0 0 0 2 9 3 1 - 4 F 8 3 7 6 4E 4 F 2 0 4E 4 1 a - ) 1 0 v N 0 HA
0186600030 4D 4 S 2 0 2 0 2 0 2 0 4 6 4 1 - S 4 31 3 6 2 0 2 0 2 0 3 3 C9 HE FA T 1 6 3É
0186600040 8E D1 B C F0 7B 8E D9 B 8 - 0 0 2 0 8E CO F C BD 0 0 7C N *6{ Ù , Àü*4 I
0186600050 38 4E 2 4 7D 2 4 8B C l 9 9 - E 8 3C 01 7 2 1C 8 3 E B 3A 8 H « } i  è < r ë:
0186600060 66 A l 1C 7 C 2 6 66 3B 0 7 - 2 6 8 A S 7 FC 75 06 80 C A £ j ■I « £ ; s H ü u ■ Ê
0186600070 02 88 56 02 80 C3 10 7 3 -E B 33 C9 8A 46 10 98 F 7 • V - I - S Î 3 É F - ■+
0186600080 66 16 0 3 46 1C 13 5 6 I E - 0 3 4 6 0E 13 D I 8B 7 6 11 £ ■ F • - V ■ F ■ H V ■
0186600090 60 89 4 6 FC 8 9 5 6 FE B 8 - 2 0 0 0 F 7 E 6 8B 5E 0B 03 ' F ü -V )),
01866000a0 C3 4 8 F 7 F 3 0 1 4 6 FC 1 1 - 4 E FE 61 B F 0 0 0 0 E 8 E 6 Â H -Ô F ü N R a j • t i t P h y s ic a l S e c to r
01866000b0 0 0 7 2 3 9 26 3 8 2D 7 4 17-60 B 1 0B B E A 1 7D F3 A 6 r 9 s 8 - t • -± ■ * ; )61 12791808
01866000C0 61 74 32 4E 74 09 83 C 7 - 2 0 3B FB 7 2 E6 EB DC A0 a t 2 H c - Ç ;û r * ë Ü
0186600000 FB 7D B 4 7D 8B F0 AC 9 8 - 4 0 7 4 0C 4 8 74 13 B 4 0E Û ) ' } 6 -, 8 t H t '
0 1 8 6 6 0 0 0 e 0 BB 07 00 CD 10 EB E F A 0 -F D 7D EB E 6 A0 FC 7D EB » Î ë i ÿ ) ë * ü )ë
01866000£0 E l CD 1 6 CD 19 26 8B 5 5 - 1 A 5 2 B 0 0 1 BB 00 00 E8 â t Î i O R ’ ■» • è
0186600100 3B 0 0 7 2 E 8 5B 8A 5 6 2 4 - B E 0B 7 C 8B FC C 7 4 6 F0 ; r è [ V f * | Ü ÇF6
0186600110 3D 7D C 7 4 6 F 4 29 7D 8 C -D 9 8 9 4E F 2 8 9 4E F 6 C 6 » ) Ç F ô ) ) Ù Ho HÔJE
0186600120 06 9 6 7D CB E A 03 0 0 0 0 - 2 0 0 F B 6 C 8 6 6 8B 4 6 F8 • ) Ê ê - - 9È£F»
0186600130 66 0 3 4 6 1C 6 6 8B DO 6 6 - C 1 E A 10 EB 5E 0 F B 6 C 8 £ - F -£ D £ Â ê ë * S È
0186600140 4A 4A 8 A 4 6 0D 3 2 E 4 F 7 - E 2 0 3 4 6 FC 1 3 5 6 FE EB J J F - 2 â + â Fü VRë
0 1 8 6 6 0 0 1 5 0 4A 52 5 0 0 6 5 3 6A 01 6 A - 1 0 91 8B 4 6 1 8 9 6 9 2 3 3 J R P - S J - J • F ■•-3
0 1 8 6 6 0 0 1 6 0 D2 F7 F 6 9 1 F 7 F6 4 2 8 7 - C A F7 7 6 I A 8A F 2 8A E 8 t)*ô *ÔB t * v ■ ô è
0 1 8 6 6 0 0 1 7 0 C 0 CC 0 2 0 A CC B 8 0 1 0 2 - 8 0 7E 0 2 0E 7 5 0 4 B 4 4 2 À î • i , -----------U 'B
0 1 8 6 6 0 0 1 8 0 8B F 4 8 A 5 6 2 4 CD 1 3 6 1 - 6 1 7 2 OB 4 0 7 5 0 1 4 2 0 3 ô V il aar 0 u -B •
0 1 8 6 6 0 0 1 9 0 5E OB 49 7 5 0 6 F 8 C 3 4 1 -B B 0 0 0 0 6 0 6 6 6A 0 0 E B * I u b  A » • • " £ J ë
0 1 8 6 6 0 0 1 a 0 BO 42 4 F 4 F 5 4 4D 4 7 5 2 - 2 0 2 0 2 0 2 0 OD OA 5 2 6 5 "BOOTH GR Re
01866001b0 6D 6 F 76 65 20 64 69 7 3 -6 B 73 20 6 F 72 20 6 F 7 4 m ove d i s k s or o t
01866001C0 68 6 5 7 2 2 0 6D 6 5 6 4 6 9 - 6 1 2E F F OD OA 4 4 6 9 7 3 h e r m e d i a .y - D i s
01866001d0 6B 2 0 6 5 7 2 7 2 6 F 7 2 F F -O D OA 5 0 7 2 65 73 73 20 k e r r o r ÿ - P r e s s
01866001e0 61 6E 7 9 2 0 6B 6 5 7 9 2 0 - 7 4 6 F 2 0 7 2 65 73 7 4 61 a n y k e y c o r e s t a
0 1 8 6 6 0 0 1 £ 0 ¡7 2 7 4 OD OA 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 A C CB D 8 5 5 A A r t ..............................-Æ 0 U *
0186600200 oo oo oo oo oo oo ôo oo-oô’ oo oo oo 6o oo ' 66' bo !
Figure 22 - First Sector of Logical Volume in ELP 1 - PS 12,791,808

The Second partition table entry(pointer to the second Extended Logical Partition)- as shown in figure 21

• “Partition Type’ - 0x05, DOS Extended partition.

• "Sectors preceding partition 2” = 12,791,808. The second ELP is located at offset 12,791,808 logical
sectors from the beginning of the Extended Primary Partition (EPP)

The Extended Primary Partition (EPP) commences at PS 12,789,760. The second ELP is located
12,791,808 sectors from this position in Physical Sector(PS) 25,581,568 (PS 12,789,760 + 12,791,808 =
25,581,568).
 Knowing that the offset for the second Extended Logical Partition is located at Physical Sector 25,581,568
we are able to navigate there and also able to locate the VBR for the second ELP.

• “Sectors in Partition 2” = 30,971,904 sectors. This value is the entire size of the ELP, including the
partition table and the Logical Drive.

Extended Logical Partition 2

Figure 23 is a screenshot of the actual contents of PS 25,581,568, which is the first sector of Extended
Logical Partition 2. The process begins again and repeats until all ELPs have been located, and interpreted.

32 31 8C 4 B DB I F 4F 4E 6E 7A AD 31 66 5A 46 33 2 1 IK O 0 N n z - l £ Z F 3
87 79 3A 9 9 56 5 5 E l AD D B 0A 90 48 03 03 3 E 4D I y : IV U a -0 H >M
FE B9 DE iA 7C CE 61 8D B F E0 77 97 C D E 6 E 2 OE b 1*5 I l a ¿ a w l l a a
F9 B0 0A 43 39 B 2 15 C A 54 43 54 5B 9C F0 E F B5 u* C 9 S £TCT[ I S ijj
8E 93 B 3
IB 89 A9 5D C D 45 C B 4B 06 D5 A 3 E 8 C 6 11» I© ] lE E K fo e E
6 3 8B 3 3 C B 07 96 2 0 4A 3D 86 04 77 F B 2 F 9 C 5 6 c l3 E I J= l v u / |V
38 25 8E 33 A1 09 98 BA 22 55 FF 76 7 C C S A A 3 8 8 *1 3 i I - "U y v |k - 8
9C 94 48 OC C8 C E 32 AC 15 83 81 3C E2 85 B B 79 IIH £12- I < a |» y
F4 2F 5D DD E 6 7 F 4B 94 80 4 8 A4 64 97 26 4F 3D o / ]7 * K l|H B d |& 0 =
41 DA 89 81 D E 5B 9A E A D4 A E A3 75 22 5F 04 40 AO I b [|e 0 ® £ u "_ @
4A 0B 01
A C 15 9 0 7 8 C l EB 35 22 5E E C 8F 4CFF J - xA e5 "*i Ly
31 3B 8 C D8 BD 7 3 C A 6 B CF 18 34 11 9D 3 9 1 0 A B 1 ; l0 H s £ k I 4 9 «
12 0A 9 E ED 37 E8 62 78 AD B 7 4D 34 D B 6 E '6 9 7 3 Ii7 e b x - M 4 tn is
FE 34 53 DE E2 B3 87 AE 38 5E I F A9 71 I F 5A 46 fc>4St>a» |© 8 /' ©q Z F
E7 82 35 C A 3 E 35 49 A6 DB 6D B 7 CC 3E 66 C A A B g l5 £ > 5 Ii0 m -1 > f£ «
83 95 2 3 DD A0 F 9 54 6C 29 B 9 5A E A 45 1C 40 A9 I|# 7 u T l) ‘ ZeE @@
B1 AF BF 55 ED 44 5F 99 C8 4D D4 71 39 17 A8 61 ± —¿ U i D _ l £ M d q 9 "a
Actual contents of
74 C 4 8A D B C F 2C 18 FD 86 F C 19 EF F5 OC 7 8 5B t A10 1 . y lu i5 x[ Physical sector
22 F7 B7 98 9C 8 5 9 C 65 C7 54 38 EA 37 98 EA 2A " - r i l l |e C T 8 e 7 |e *
25581568.
AB 4B 6C C8 8D E E AC 4E AD 47 C 7 7E 4E 23 AD F 3 « K l£ i-N -G C ~ H # -o
2B 88 DD 27 8 F A8 8F 12 4D 6 F C 8 45 67 CO C 7 B A + ! ’? • " M o tE g A g ?
The Partition Table has
2C 4 F B3 E4 03 E D 74 FF 32 09 0D 87 0A 8 C 6 B 4 E ,0 ’ a ity 2 I Ik N been highlighted
07 50 48 35 53 38 78 F 7 B1 A2 F5 97 B B 6D 9 0 2D P H 5 S 8 x -f± e o |» m -
5D 99 B 1 5 F B E F B 4D 5 B 98 8D 62 B E 3D 55 D F D5 ] l± _ & u M [ I b *=U J3& -
70 D3 14 3 B 7 F 3D 85 F D 53 C E 3B 11 79 6E 9D 36 p d ; = ly S T > ''y n 6
D B 99 C D 71 C 5 46 66 5 B 56 6D 58 7 E 11 AB 9 F E E O llq ^ F fT V m X " « | i
ED 09 D 3 2B C 9 19 A0 C E 2A 85 1A 94 64 54 D F 6 E i^ C I+ E 1*1 Id T B n
6D 7A F I 91 D2 2B E 6 F5 57 76 B7 6A E 6 5F 00 F E n i z n 'O + a o U v jae_ f
FF FF 07 FE FF FF 00 08 00 00 00 90 D8 01 00 FE yy byy 0 b
FF FF 05 FE FF FF 00 C 8 9B 02 00 38 73 02 00 00 yy byy £l 8s
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA U*

Figure 23 - Extended Logical Partition table pointing to itself and next Partition - PS 25,581,568

The first partition table entry (pointing to itself, the second Extended Logical Partition):
• “Partition type indicator” = 0x07, NTFS partition.
• “Sectors preceding partition 1" = 2048. The Volume Boot Record (VBR) begins 2048 logical sectors
from the ELP (2048 sectors reserved between the beginning of the ELP and the VBR).

The Physical Sector Offset for the VBR will be at 25,581,568+2,048 = 25,583,616. The VBR is located
physical sector 25,583,616.

• The “Sectors in Partition 1” = 30,969,856 sectors in the Logical Drive.

In summary, the second Extended Logical Partition commences at PS25,581,568 and stops at PS
56,553,471 (25,581,568+2,048+30,969,856-1).

• The second partition table entry (pointer to the third Extended Logical Partition (ELP))
“System Indicator" = 0x05, DOSExtended partition.
• “Sectors preceding partition 2” = 43,763,712. The third ELP is located at offset 43,763,712 logical
sectors from the beginning of the Extended Primary Partition (EPP) PS 12,789,760.

The Extended Primary Partition (EPP) commences at sector 12,789,760. The third ELP is located at
43,763,712 sectors from this position in Physical Sector (PS) 56,553,472 (PS 12,789,760 + 43,763,712 =
56,553,472).

• “Sectors in Partition 2” = 41,105,408 sectors in the next ELP (third ELP).

Extended Logical Partition 3

Knowing that the offset for the third Extended Logical Partition is located at Physical Sector 56,553,472 we
are able to navigate there and also able to locate the VBR for the ELP. Figure 25 shows the actual contents
of the PS 56,553,472.

“DC 7C B4 97 C2 22 27 F9 22 87 6D OD B5 F8 EF 6C | 1A " ' ù " 1a p a i l

AC 8F 62 B6 33 C8 CB BA 9E 57 88 73 E3 94 9E 65 - b H 3 È E 2 | U | s S l l e
33 29 4D 6A 03 E2 C4 IE B5 0A 09 82 09 F7 9B 81 3 )M j â A . 1 -|
EE 7F D2 91 9D 8C 74 CA 8D C4 CO 98 7F F7 3E DD i 0 ’ i t E A A i -r>7
AS E8 07 A8 5À 3A E4 B4 Cl 98 FF C2 55 OF AC A8 ¥ è " Z : a ' A l ÿ Â U
CD 62 3C F0 56 FC SC 2E 26 A9 4B 14 B5 F2 42 48 lb < S V ü \ .& @ K poBH
79 81 62 68 ID DE 5C 28 C9 95 56 F9 68 E6 AE BE y b h fc>\(É|Vùhæ«fc
11 6F 71 SE 56 07 8D 27 CB 8F 0E A8 08 55 6C D7 oq~ V 'Ë " U lx
D6 8E EB 9F 34 56 FD D1 A8 7A 7A 70 AB 80 4D FA Ô | ë | 4 V ÿ ï ï z z p « | M û
91 7F E6 8E 4F 4F B7 26 75 F3 0C 97 ID 7D 7D 02 * IO O &uô 1 } }
SD ED CA C6 C7 CC 2B 9B 25 FE 17 SC 7E EC D3 58 J i Ê Æ Ç Î + | X b \ ~ iÔ X
99 DC A6 07 6À 98 EC CF CC 25 B3 B1 63 FI D8 F9 IÜ | j l i ï î X 5± c n 0 ù
9A IB 70 52 :e 99 97 4F FI FE 22 B9 59 42 6B ID 1 pR 1 lO H b " 1YB k
OD FE 38 94 39 58 73 EA 74 E6 5E 65 3E 09 82 2À Jd8 1 9 X s ê tæ ^ e > | »
A9 B8 60 F7 00 AE C3 24 60 44 27 20 3E 76 16 IF €>X$'D' >v Actual contents of PS 56553472
24 12 97 BD 3D B8 10 21 77 32 70 9F F3 39 0E 7B $ !v 2 p lo 9 {
CA C3 A0 D7 52 CB 48 EF 41 86 SC 10 A7 80 D8 B7 E S x R Ë H ïA | \ § 1 0 -
3D 3F 65 3A 3C 97 E0 B7 2B 09 EB 8E F3 98 5D C3 = ? e : < l à + ë | o l ] î
D2 53 ID D5 DD 1A 66 86 68 59 65 D7 7C ED C4 B0 Ô S 0 Ÿ f l h Y e x | i  ’
SD B7 AE El DC 35 47 2A 85 DC 02 77 B1 50 EC B1 ] ® ± Ü S G » |t! w ± P i± The Partition table has been
IF DD B6 ED BB FF 9B E3 41 3E 9B E6 63 2F C3 38 Ÿ H i» ÿ lS A > la c / Î8 highlighted
42 B0 CO DB CB E9 D7 D1 D8 72 26 A6 8F 04 E3 96 B " À Û Ëéx$(0r& 1 à l
D2 F3 FB 1C 0B 3E 4B 7D 45 C9 99 9F 8B A9 D8 B6 Ô ôû > K } E É I 1 |© 0 JK ’
21 Cl DB 97 AA 59 49 E7 89 30 C9 A2 OC IE 89 27 ! A 0 14Y I ç l O É j / l '
ID C7 CC 47 46 9A F8 41 42 05 FA B5 E0 BD 64 DO Ç ÎG F |0 Â ^ 1 Îp à H d D
EB FI 17 DF 2F 27 EF 98 B7 6F 97 CC 1C D8 4F 10 e n B / > Ÿ V o l I 0 0
CE A3 63 6E DA IF 28 26 3E 7F 79 94 DF B0 89 89 Ild it T (&> y lB ‘ 11
76 3F 82 60 9A EB 93 7E 66 4A 4F 2A 41 11 00 FE * ? l lë l~ f J O * A b
FF FF 0B FE FF FF 00 08 00 00 00 30 73 02 00 FE ÿ ÿ b ÿ ÿ 0s b
FF FF 05 FE FF FF 00 00 OF 05 00 00 71 02 00 00 ÿ ÿ fcÿv q
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA U*
-i r.
Figure 24 - Extended Logical Partition 3 first sector - P S 56,553,472

The first partition table entry (pointing to itself, the third Extended Logical Partition):
• The “Partition type indicator” value = 0x08, FAT32 partition.
 • The "Sectors Preceding partition 1” = 2048. The Volume Boot Record (VBR) begins 2048 logical
sectors from the ELP (2048 sectors reserved between the beginning of the ELP and the VBR).

The Physical Sector Offset for the VBR will be at 56,553,472+2,048 = 56,555,520. The VBR is located
physical sector 56,555,520

• “Sectors in Partition 1” = 41,103,360 sectors the Logical Drive

In summary, the third Extended Logical Partition commences at PS 56,553,472 and stops at PS
97,658,879 (56,553,472 + 2,048 + 41,103,360 - 1).

The VBR is located at PS 56,555,520 (i.e 56,553,472+2,048)

The second partition table entry (pointer to the fourth Extended Logical Partition (ELP):
• “System Indicator” byte = 0x05, DOSExtended partition.

• “Sectors preceding partition 2" = 84,869,120 sectors from the beginning of the Extended Primary
Partition (EPP) to the fourth ELP.

The Extended Primary Partition (EPP) commences at sector 12,789,760. The fourth ELP is located
84,869,120 sectors from this position in Physical Sector (PS) 97,658,880 (12,789,760 + 84,869,120)

• “Sectors in Partition 2” = 40,960,000 sectors in the fourth ELP.

Extended Logical Partition 4

Knowing that the offset for the fourth Extended Logical Partition is located at Physical Sector 97,658,880
we are able to navigate there and also able to locate the VBR for the ELP, as shown Figure 25.
 BD A4 F 8 B3 41 3B 31 B4 83 37 87 3 F 42 CD 2D E 5 H**0’ A ; l ' l 7 l ? B l - à
C C 63 05 C 6 CO F E 2 F 25 5A 18 14 7 C 8D 4 B 6D AA l e Æ Afc/XZ | Km*
9À 4 A 6 C 88 D1 2D A2 D5 E l 4 8 A C 56 78 5 7 3 F 5A |Jl|H -e Ô â H -V x W ? Z
9F 5E 23 55 57 37 47 9F OF AD CD 97 D3 6C À6 56 r # U U 7 G l - 1 IÖ 1 |V
B4 D2 07 B6 DB 34 78 88 2 C F 8 A E D3 DB 4D 92 27 'Ö f l Û 4 x | .0 © Ô Û M '1
F8 46 9 F 1C 54 A F 76 42 6 F E0 A6 6 E 77 3 5 DA 10 aF| T "v B o à |n w 5 Û
D3 4 C E C 6 F 97 C l 61 15 26 8D A9 2 E 93 23 4D 87 Ô L i o l  a & © . |# M |
82 BD 5À A9 EA 5 E 99 7F 59 72 65 21 68 11
64 F 2 |) iZ © é ''l Y r d à e lh
88 35 11 B7 14 B8 F 8 50 5B C F94 CD C 2 AE 54 77 15 • ,0 P [ ï | Î Â ® T v
4D F4 C F 9D 79 06 B4 AD DD DB 36 E7 49 A9 B9 EA M ôï y ‘ - Ÿ Û 6 • I@ ‘ é
E6 2 C 7 F 4D 3C 33 05 2E B4 35 E B 19 3A 37 22 96 æ. M<3 . *5ë :7 "I
67 66 E 3 19 82 6B 10 64 F5 F 3 99 79 D9 D5 SO
A4 g fS Ik d 5 ö H ly Ü Ö P
D9 1A D6 B3 30 5B 50 84 26 14 B E 8 C C 4 F8 A7 E9 0 Ö * 0 [ P 1& f c | Â 0 § é
BA 4 F A5 D6 B3 E4 C 7 94 14 AD C F 89 76 E4 C 5 D F 20¥0>âÇI -ÏIv â  fi
9 E 3D 96 F3 B5 2 F E 2 3B E3 96 28 C S 65 A F 77 5A l = l ô i J / â ; S l (A e ~ v Z
C3 9C 3C 28 B4 DB 6D 3D 36 E F C 9 AD F0 54 57 C 9 2 | < ( 'Û m = 6 iÉ - 5 T V É
5E A2 E5 E 5 B1 DD I D B2 C8 18 E2 E 6 34 22 6B A F ~ càà± Ÿ 5È â æ 4 " k —
2F 3C 36 D3 F0 58 DE 0F 2C 3E 69 4B EE D2 2F Fl /<6ÔSXP . > iK îÔ /n Actual contents of PS 97658880
6F 9B 76 D3 A6 F6 6C EF FC 48 94 B2 7A AF Cl 3C o lv ö l ö l i ü H l , z ~ k <
9E BD EF DD F0 8A A6 F7 2E 1F 2A B3 FA FB E5 FA IH ÏŸ 6 I |-r. * 5üûâü Note: The partition entry has been
67 52 0A 8D 5E F6 BB A0 90 7D 99 CF 04 C3 D5 69 gR 'ö » } 1 ï SÔi highlighted
53 6F 89 BA C2 29 B3 53 B6 AB 49 5F C6 37 DF 3C S o |2 Â )5SH«IJE7fi<
57 2F 97 E8 BC 26 08 B7 9B 09 DD 30 A5 C9 B7 DI tï/|è)4i< 1 ŸOiÊ-H There is only one entry for the
A4 F6 45 C7 F9 F9 70 97 Cl 19 15 BE CE 52 02 27 H ô E Ç ù ù p lA Ü ÎR 1 current partition
57 36 57 C l 35 53 9D A6 36 FB 8C 31 33 C2 F8 82 W6UÂSS \ 6 û i l j k p t ^ '
02 2A 53 E5 2A E3 01 26 4C D3 AC 5A 04 EF 99 87 * S â » S k L é " 'Z i 11
EF À6 50 C9 21 C9 DD 33 27 FF EA 83 DI 4F 04 B0 Ï^ P É T É frÿ ê liïO '
F7 27 32 23 6E 51 3E 29 A3 50 E4 FF E3 35 00 FE -r' 2#nQ>)£PâÿS5 f
FF FF 0B FE FF FF 00 08 00 00 00 F8 70 02 00 00 ÿÿ byÿ ep
"00' 00 00 00 '00 00 00 00 00 00 Ö0 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA U*
V

Figure 205 - ELP 4 Partition Table - P S 97,658,880

Note that there is only a single partition entry within this table. This indicates that this is the last partition
within the Extended Primary Partition (EPP), no others are to follow this. It would be accurate to summarize
that we are examining a DOS based partition and it is the last, therefore it would be the logical drive named
“Testing" as shown in Figure 26.

E X T E N D E D (M :) e x t e n d e d 2 (O :) E X T E N D E D 1 (N :) T E S T IN G CP:)
3.05 GB F A T 3.0 5 GB 1 4 .7 7 GB N T F S 1 9 .6 0 GB F A T 3 2 19.53 G B F A T 3 2
H e a lth y (L o g ic a l Drh Free sp a ce H e a lth y (L o g ic a l D riv e ) H e a lth y (L o g ic a l D riv e ) H e a lth y ( L o g ic a l D riv e )

Î
Figure 26 - Extended Primary Partition and Four Extended Logical Volumes in Disk Management GUI

For the purposes of our investigation the partition table entries relate to ELP 4 (information about itself).
There are no other Extended Logical Partition details present

The first partition table entry (pointing to itself, the fourth Extended Logical Partition):
• “Partition type indicator" = 0x08, FAT32 partition
 • "Sectors Preceding partition 1” = 2048 logical sectors from the ELP to the VBR.

The Physical Sector Offset for the VBR will be at 97,658,880+2048 = 97,660,928. The VBR is located
physical sector 97,660,928

• “Sectors in Partition 1" = 40,957,952 sectors in the Logical Drive

In summary, the fourth (and final) Extended Logical Partition commences at PS 97,658,880 and stops at
PS 138,618,879 (97,658,880 + 2048 + 40,957,952 - 1).

The FAT32 VBR is located at PS 97,660,928 (i.e. 97,658,880 +2048).

Therefore from all the information from the MBR and the EPP tables, we can document the Logical
Structure of the disk, as shown in Table 6.

Partition Logical
Primary / File Size
Start Disk start Partition End (LBA)
Extended system (in sectors)
(LBA) (VBR)

Partition 1 Primary NTFS 2048 2048 6393856 6395904

Partition 2 Primary NTFS 6395904 6395904 6393856 12789759

Partition 3 Extended 12789760 138618880

Partition4 Extended FAT 12789760 12791808 6393856 19185663
Partition 5 Extended NTFS 25581568 25583616 30969856 56553471
Partition 6 Extended FAT32 56553472 56555520 41103360 97658879
Partition 7 Extended FAT32 97658880 97660928 40957952 138618879
Table 6 - Table of Logical Disk Structure

In conclusion the term 'daisy chain' is often used when referring to multiple Extended Logical Partitions
within an Extended Primary Partition (container). This as we have shown is correct in some way because
each EPT holds information about itself and the next EPT. The examiner must take care when interpreting
the values in the EPT's in order to identify volumes and ensure partitions are not missed.

However, the hiding of partitions is relatively easy for a competent individual.

Summary of ELP -r- «_o m
IT
û l. LT1
O 2 H

Extended Primary Partition begins at PS12,789,760 (From Partition table in PS 0 - MBR) g- 5

~ rn
o 5 O
• Partition Table Entry 1 (ELP 1) »fi ­
o Sectors preceding Extended Logical Partition = 2,048
o Sectors in Partition = 6,393,856

Partition Table
re <-n
P.S. 12,789,760 CT>
ELP 1 VBR = PS 12,791,808 - Last Sector = PS 19,185,663 —
Figure 23
• Partition Table Entry 2 (ELP 2)
o Sectors preceding Extended Logical Partition = 12,791,808
o Sectors in Partition = 30,971,904

I T* It
EPP 2 begins at PS 25,581,568 re ^ x
'vl
• Partition Table Entry 1 (ELP 2) "J Œ
v<”
X c £d reO.
o Sectors preceding Extended Logical Partition = 2,048 ^ — Q.
O N)
o Sectors in Partition = 30,969,856 -r .
Partition Table n
g. M S
U
P.S. 25,581,568 O w
ELP 2 VBR PS 25,583,616 - Last Sector = PS 56,553,471
=

Figure 26 <
• Partition Table Entry 2 (ELP 3)
o Sectors preceding Extended Logical Partition = 43,763,712
o Sectors in Partition = 41,105,408 T —1 m
re ^ X
01 ct> 3
7* o m
■5” £T> ^
X
^ CD_ Om
EPP 3 begins at PS 56,553,472 o > o
• Partition Table Entry 1 (ELP 3) -I -»
r> £ _
o Sectors preceding Extended Logical Partition = 2,048 SL ^ 2
O —
o Sectors in Partition = 41,103,360 <"
Partition Table
P.S. 56,553,472
ELP 3 VBR PS 56,555,520 Last Sector PS 97,658,879
= - - =
Figure 28
• Partition Table Entry 2 (ELP 4) I —* —)
re ^ rn
aI ui
o Sectors preceding Extended Logical Partition = 84,869,120 w —<
o Sectors in Partition = 40,960,000

EPP 4 begins at PS 97,658,880

• Partition Table Entry 1 (ELP 4)
o Sectors preceding Extended Logical Partition = 2,048
o Sectors in Partition = 40,957,952 Partition Table
P.S. 97,658,880
ELP 4 VBR = PS 97,660,928 Last Sector = PS 138,618,879 Figure 31
• Partition Table Entry 2
o No entries, no more ELP
Hiding Partitions
There are numerous ways a person could hide partitions on a hard drive. Theseinclude the removal of an
assigned drive letter, the use of encryption such as Truecrypt, entering the appropriate value within the
'Systemldentifier' bytes in the partition table, and/or manipulating values pointing to the next logical
partitions.

M e th o d 1 - H id d e n P a rtitio n ty p e id e n tifie r

Each Partition is identified by a Partition Type. This can be used to inform the operating system not to
display a partition to the user. Figure 27 is a screenshot showing the partition type identified as 0x07
(NTFS).

□
Partition Table Entry #2
1CE 80 = active partition 00
1CF Start head 32
IDO Start sector 19
1D0 Start cylinder 398
1D2 Partition type indicator (hex) 07
1D3 End head 32
1D4 End sector 4
1D4 End cylinder 796
1D6 Sectors preceding partition 2 6395904
IDA Sectors in partition 2 6393856

Partition 2 - Primary partition

Details are held in the Master Boot Record (MBR)

The highlighted are indicated the Partition Type value in hex

Figure 27 - MBR Partition Type

Below is the same information, as above shown within the MBR partition table entry (Figure 29).

"65 6D 00 00 00 63 7B 9A--27 19 A5 27 00 00 80 20
21 00¿ 07 20 52 8E 00 08--00 00 00 90 61 00 00 20
53 8E 07 20 C4 1C 00 98--61 00 00 90 61 00 00 20
C5 1C OF FE FF FF 00 28--C3 00 00 00 80 07 00 00
00 00 00 00 00 00 00 00--00 00 00 00 00 00 55 AA
Figure 28 - Partition Type Identifier

The byte circled above (0x07) indicates that the file system is NTFS. If this byte were to be changed to
0x17, this would denote a hidden NTFS partition.

Figure 29 is a screenshot of the logical volumes attached to this computer before changing the byte value
above. The appropriate volume is highlighted.
 K Desktop
Documents
£ Download;
Music

i Pictures
3 Videos
¡ ¿ i Local Disk (C:)
RECOVERY (D:)

Removable Disk (G:>

L j primary (K;)
i « New partition (L:)
^ EXTENDED (M:)
u EXTENDED 1 (N:)
i - extended 2 (0:)
i_ , TESTING (P:)

Figure 29 - Logical Drives displayed in Windows Explorer

The system indicator byte value was changed to 0x17, as shown below in Figure 31.

65 6D 00 00 00 63 7B 9A 27 19 À5 27 00 00 80 20
21 00 .07 20 52 8E 00 08 00 00 00 90 61 00 00 20
53 8 E 17 20 C 4 1C 00 98 61 00 00 90 61 00 00 20
C5 1C OF F E F F FF 00 28 C3 00 00 00 80 07 00 00

Figure 210 - Hidden Partition type Identifier

The screen was refreshed and the volume labelled 'New partition' was hidden from the view of the user,
as can be seen below in Figure 31.

S This PC
p le Desktop
p D ocum ents
p jk Downloads
p Jf» M usic
p - Pictures
p 3 Videos
p ^ Local Disk (C:)
p RECOVERY (D:)
Note the volume is
p Removable Disk (G:)
now missing from
p prim a ry (K:)
view
p EXTENDED (M :)
p EXTENDED 1 (N:)
p extended 2 (0 :)

TESTING (P:)

Figure 31 - Partition Hidden in Windows Explorer

This method is called 'changing the system indicator from a standard system indicator to a “hidden” system
indicator'. Some common hidden system indicators are shown in Table 7 below, there are many more.
 Byte File System Type
0x11 Hidden DOS FAT 12
0x14 Hidden DOS FAT 16 (up to 32 MB)
0x15 Hidden DOS Extended Partition
0x16 Hidden DOS FATA 16 (up to 2 Gig)
0x1 B Hidden FAT 32
0x1C Hidden FAT 32x (LBA)
0x1 F Hidden FAT 32 Extended
0x17 Hidden Windows NT NTFS
Table 7 - Hidden Partition Identifiers

M e th o d 2 - B re a k in g th e “D a is y - C h a in ” to h id e a p a rtitio n

Another way to hide a partition is either by removing the specific partition from the partition table or by
amending the specific partition table entry in order to point to another.

For example, in the preceding chapter, we have examined ELP's in great detail. We have determined that
two entries are always present and that the first contains information about itself whilst the second relates
to the next EPT, the “daisy-chain”. If the daisy-chain was deliberately broken, a partition could be passed
over, and then in effect Hidden, as visually demonstrated in Figure 32.

Figure 222 - Graphical view of ELP 1 pointing to ELP 3, hiding ELP 2

If the hexadecimal byte values were amended in the partition table of an Extended Logical partition to miss
the next logical partition, then this would be hidden from view.

Table 8, shows the values that would be used to hide Partition 6.

 VBR
Primary / File Partition Size
Volume Partition End
Extended system Start (in sectors)
start
Partition 1 P NTFS 2048 6393856 6395904
Partition 2 P NTFS 6395904 6393856 12789759
E
Partition 3 12789760 138618880
(container)
Partition4 E FAT 12789760 12791808 63938560 191856664
Partition 5 E NTFS 25581568 25583616 30969855 563334710

Partition 6 E FAT32 56553472 56555520 41103360 97658880

Partition 7 E FAT32 97658880 97660928 40957952 138618880
Table 8 - ELP Partition Table Values changed to hide Partition 6

If the values held in Partition 5 (Figure 33) relating to partition6 were amended to point to partition 7, then
the existence of partition6 would not be known.

70 D314 3B 7F 3D 85 FD-53 CE 3B 11 79 6E 9D 36 pÖ •; = ÿSÎ; yn 6

DB 99CD 71 C5 46 66 5B-56 6D 58 7E 11 AB 9F EE Û ÎqÀFffVmX- « î
ED 09D3 2B C9 19 AO CE-2A 85 1A 94 64 54 DF 6E i Ô+É Î* ■ dTßn
6D 7A FI 91 D2 2B E6 F5-57 76 B7 6A E6 5F 00 FE mzn Ö+aeöUv •j*_ fc
jX-E^-63- FE FF FF 00 00 ■00 -&Q-0ÛJQD8 01 00 FE ÿÿ &ÿÿ..... 0 - p
FF FF 05 FE FF FF 00 C8-9B 02 00 38~73^52 00 00 ÿÿ fcÿÿÈ • • 8s ■••
- m - a a nn fin nn h n 'n n nn-nn rin QjQ -ftfr-ftrrn n oo 00 .............
00 00 00 00 00 00 00 00-00 00 00 00 00 00 55 AA .......... U*
oo n or en oo r o r, o du oo ao o o et, ne 10 eo o o . 3 / 'A Î l •• o

Logical partition entry relating to

the next partition (i.e partition 6)

Figure 33 - ELP 5 partition table correct values

In order for this to be achieved then the values must be amended to 0x00 0x00 OxOf 0x05 and 0x00 0x00
0x71 0x02 (representing the offset from the beginning of the Extended Primary Partition and the sector
size) (i.e. PS 9765880 and 40960000 sectors), as shown in Figure 34.

6D 7À F l 91 D2 2B E6 F 5 57 76 B7 6À E 6 5F 00 F E
FF F F 07 F E FF FF 00 08 00 00 00 90 D8 01 00 F E
FF F F 05 F E FF FF 00 00 0F 05 00 00 71 02 Eo 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 A À
8B F 7 B E 60 E 8 C3 A8 BÀ 8B A E E 8 6A 75 1E 6 E B2

Figure 234 - ELP 5 partition table 5 altered to hide ELP 6

After the changes had been made to the partition table the volume was removed from the users view (i.e.
the volume named Extended 1 was removed) and the area within disk management console was marked

©2018 IACIS Disk Structures Page 30 of 63

as "free Space". This method is an approach that suspects could take to conceal important data / illegal
material

Below are screenshot of the volumes as seen through explorer and the Disk Management console (figure
35).

This PC
_ □
1 C om p uter V ie w v ©

t ► This PC v O Search Th... p

Am ». .-W.VMW . MVWS
1C Desktop A £15» A ;

Documents
mm Local Disk (C:)
4 Downloads
.Music 774 GB free of 910 GB

r Pictures RECOVERY (D:)

3 Videos
‘5 ^ / ’’’ 2.44 GB free of 20.1 GB
Local Disk (C:)
C J RECOVERY (D:) ¿k 4
¿ ¡a DVD RW Drive (E:)
^ Removable Disk (6:)
After amending the
1 „ primary (K:)
partition table entry the
i - New partition (L:) Removable Disk (F:) volume 'Extended T has
EXTENDED (M:) been removed from the
■ view of the user and the
, « extended 2 (0:) *
area has been marked as
_ — - Removable Disk (G:)
TESTING (P:) 'free' within Dsk
V V Management
2 0 it e m s
n a 1
|| U B illM l
EXTENDED (MO extended 2 (OO TESTING (P0
3.05 GB FAT 3.05 GB 14.77 GB NTFS 19.60 GB 19.53 GB FAT32
Healthy (logical Drh Free space Healthy (logical Drive) Free space Healthy (logical Drive)

Figure 35 - Partition hidden from user

Possibly the most simple of ways is to remove the drive letter assignment in the Disk Management window.
This will remove the drive letter assigned for that partition and will remove it from view in Windows Explorer
or from the command line. Anyone with access to the system can simply go in Disk Management and see
the partition by reassigning a drive letter to it. So it is not a real good method for hiding a partition unless
you restrict access to the Management console

In conclusion suspects will go to enormous lengths to conceal information from the Police. By having just
a small about of knowledge and a Hex-editor, entire volumes can be concealed from view.

It is important for examiners to document the entire disk geometry on every case to ensure all material is
examined.
VIII. W hat is GUID?

GUID stands for Globally Unique Identifier. It is a 128 bit value used to uniquely identify items or entities in
computer systems. GUIDs can also be referred to as UUIDs or Universally Unique identifiers. There is no
central authority to guarantee uniqueness but due to the length of the value it is highly unlikely to be
repeated. UUIDs were originally used in the Apollo Network Computing System and later in the Open
Software Foundation’s (OSF) Distributed Computing environment (DCE). GUIDs are the Microsoft
implementation of the Distributed Computing environment (DCE) universally unique identifier (UUID). As
there is no centralized authority required to administer UUIDs, generation on demand can be automated
and used for a variety of purposes.

A GUID is notated in hexadecimal in 5 groups in a 8-4-4-4-12 format. For example:

00112233-4455-6677-8899-aabbccddeeff

The binary encoding of UUIDs varies between systems. Some systems use a big-endian format whereas
others use a mixed-endian format. For example, the GUID for the GUID Partition Table (GPT) partitioning
scheme described in the next section uses such a mixed-Endian format. Groups 1-3 are little endian, while
groups 4-5 are in big endian.

GUIDs come in different versions and variants. RFC 1422 defines 5 versions of GUID as follows:

• Date-Time & Mac address

• Date-time and MAC address, DCE Security version
• MD5 hash & namespace (Generated by hashing a namespace)
• Ramdon
• SHA-1 hash & namespace

IX. GPT Partitions

After more than 30 years of supremacy, BIOS — the PC's ‘Basic Input Output System’ — has been
replaced. Taking its place is UEFI, a specification that began as the Intel Boot Initiative back in 1998.Since
then the Initiative became EFI, and in 2005 Intel donated EFI to the newly-formed UEFI Forum, a
consortium made up of the AMD, Apple, IBM, Intel, Microsoft, HP and others. (More information can be
found at www.uefi.org.)

UEFI, or Unified Extensible Firmware Interface, is the complete re-engineering of a computer boot
environment and as such it has almost no similarities to the PC BIOS that it replaces. While the 'BIOS’ is
fundamentally a solid piece of firmware, UEFI is a programmable software interface that sits on top a
computer’s hardware and firmware (and indeed UEFI can and does sit on top of BIOS). Rather than all of
the boot code being stored in the motherboard’s BIOS, UEFI sits in the EFI directory or in some non-volatile
memory.

As a result, UEFI almost resembles a light-weight operating system. A computer boots into UEFI, an
arbitrary set of actions are carried out, and then it triggers the loading of an operating system. All of this
 boot data is stored on NAND flash or on a hard drive, which means that there’s a lot more space for things
like language localization, boot-time diagnostics (putting an end to POST beeps), utilities (backup, restore,
malware scanners), and so on.

The fact that UEFI is entirely software-based is what makes it unified. So far UEFI has been used by almost
every combination of 32-bit and 64-bit ARM, Intel, and AMD chips, and in each case the boot code just
had to be compiled for the target platform. Every major desktop (OS X, Windows) and server OS (Linux)
supports UEFI boot today.

UEFI uses a partition system called the GUID Partition Table (GPT). GUID stands for Globally Unique
IDentifier. Drives partitioned with Windows 8 will use GPT.

• The GPT partition table can support up to 128 partitions and uses 64-bit LBA addresses (although
only approx. 124 partitions are available for “user data”). The GPT system has the ability to support
very large hard drives, which are becoming increasingly available and cheap to purchase. It is
believed that the GPT can accommodate partition sizes up to 9.4 ZB (Zetabytes) or 1 billion TB
(terabytes)3

• Each Entry is 128 bytes long

• Backup copies of the important data structures are held at the end of the drive in case of failure, thus
making the data on the disk more easily recoverable.

3(source http://en.community.dell.eom/techcenter/extras/w/wiki /2838.aspx)

 There are five major parts to the GPT partitioned disk, as shown in figure 36.
• The ‘Protective MBR’
• Primary ‘GUID partition Table’ (GPT) header
• ‘GUID partition entries’ (1 to max. 128)
• Partition area
• Backup Area, containing copies of the Primary GUID partition Table (GPT) header and GUID partition
entries (1 to max. 128)

LBA 0 P rotective MBR

LBA 1 Primary GPT Header

i-
Ol
LBA 2 Entry 1 Entry 2 Entry 3 Entry 4 O
>■ £CD
E
LBA 3 to 33 Entries S W m IL

LBA 34 —

Partition 1

Remaining partitions <r

4Source:http://technet.microsoft.com/en-us/library/cc739412%28WS.10%29.aspx#w2k3tr_basic_how_fgkm

©2018IACIS Disk Structures Page 34 of 63

 Protective MBR
The Protective MBR exists on a GPT partition disk to protect the GPT when legacy software tools are used
to explore or repair the MBR. The legacy tools could interpret a missing MBR as an un-partitioned diskand
render a GPT system unbootable. Both Windows XP and Server 2003 can read or write data to a GPT
disk but XP 32-bit cannot boot from a GPT partition. Windows Vista, Windows 7, Windows 8 and Server
2008, can read write and boot from a GPT disk.

The 'Protective MBR’is still located at the very beginning of the disk, Physical Sector 0 (zero), and like the
previous system it is usually 512 bytes in length. There will be no Boot Code present in the Protective
MBR sector.

Below is an example of a Protective MBR, Figure 37.

O
O
o
o
o
o
OOOOOOOlaO 00 00 00 00 00 00 00--00 00 00 00 00
o
o

OOOOOOOlbO 00 po 00 00 00 00 00 00--40 2E 84 2D 00 00 00 00
OOOOOOOlcO 02 ^00 EE FF FF FF 01 -00 00 AF 6D 70 74 00 00
o o
o o

OOOOOOOldO 00 00 00 00 00 00 00 -00 00 00 00 00 00 00 00
OOOOOOOleO 00 00 00 00 00 00 00 00--00 00 00 00 00 00 00 00
OOOOOOOlfO 00 00 00 00 00 00 00 00--00 00 00 00 00 00 55 AA
Figure 37 - Protective M B R partition table

The area highlighted above denotes the 64 bytes Master Partition Tables commencing at offset 0x1 BE
(446).On a GPT drive there will only be a single entry present spanning the entire disk. The partition type
OxEE (circled) denotes that this is a GPT partitioned disk.

Table 9 is a breakdown of the information contained within the partition entry.

Byte Value
Information
Offset Length
0x00 1 00 Not bootable
0x01 3 00 02 00 Starting CHS value address (redundant)
0x04 1 EE Indicates GPT partitioned Disk (W7 ‘EF’ = EFI MBR)
0x05 3 FF FFFF Starting CHS value address (redundant)
0x08 4 01 00 00 00 Start Sector (LBA) of partition
AF 6D 70 74 This denotes the partition size. (1,953,525,167)
OxOC 4
Windows 7 will enter FF FFFFFF,
Table 9 - Protective M B R values

From the information contained in the partition table we can see that the partition starts at Physical Sectorl
(PS1).

Primary GUID Partition Table (GPT) header

The GPT header will always immediately follow the MBR in Physical Sector 1, although this information
should always be checked within the MBR.
 The GPT header always begins with the 8-byte EFI "signature" string: " 0x45 0x46 0x49 0x20 0x50 0x41
0x52 0x54" (ASCII: "EFI PART"); declared in the UEFI Specification as the 64-bit Hex constant:
"0x5452415020494645”

At present a GPT header is limited to 92 bytes in length, although it is not restricted to this size and may
grow in the future. Figure 38 is a screen shot of a GPT header present in PS 1 (the “signature" has been
highlighted)
0000000200 45 46 49 20 50 41 52 54- 00 01 00 5C 00 00 00 EFI PART ••••V--

o
O
0000000210 OF D1 71 F5 00 00 -01 00 00 00 00 00 00 00 ■Hqo---

o
o
o o o
o o o
0000000220 AF 6D 70 74 00 00 -22 00 00 00 00 00 00 00 m p t •• • •".............

o
O
0000000230 8E 6D 70 74 00 00 00 -IF FE 74 89 13 F0 D4 4F ■mpt ■■■■ fet • 600
0000000240 92 31 2E 00 3B 22 4E D9--02 00 00 00 00 00 00 00 •1. ■; r,NÙ
0000000250 80 00 00 00 80 00 00 00- 56 F9 45 00 00 00 00 VÙE •• • ■

CO
0000000260 00 00 00 00 00--00 00 00 00 00
o
O

00

o
o
o
o
o
o

o
n n n n n n n o i n n n n n n n n n n n n n o
n n n n n n n n n n n n n n n n n n n n

Figure 38 - GPT Header.

Using the information contained above within the GPT header it is possible for an examiner to determine
the layout of the disk. This includes the location of the partition table, partition data areas and backup
copies of the GPT Header / partition table, provided in Table 10.

Bytes
.Value Information
Offset Length
0x00 8 45 46 49 20 50 41 52 54 Denotes the signature string (ASCII “EFI PART”)
Revision number for this header. Not related to the
0x08 4 00 00 01 00
UEFI version number.
GPT header size (in bytes). UEFI states that the
OxOC 4 5C 00 00 00
header must be at least 92 bytes. (Decimal 92)
CRC32 checksum of the GPT header. This value is
0x10 4 OF D1 71 F5 calculated with these bytes set to 00 at the time of
calculation
0x14 4 00 00 00 00 Reserved
0x18 8 01 00 00 00 00 00 00 00 LBA of the current GPT Header structure (Sector 1)
LBA of Backup copy of GPT
0x20 8 AF 6D 70 74 00 00 00 00 Note: the GPT Header will have its own unique CRC32
checksum. Sector
0x28 8 22 00 00 00 00 00 00 00 LBA of start of partition area.
LBA of end of partition area. The last useable LBA
0x30 8 8E 6D 70 74 00 00 00 00
partition sector.
1FFE748913F0D44F92312E00 DISK GUID (Global Unique Identifier) for this particular
0x38 16
3B224ED9 disk
LBA of the start of the partition tables. Most often this
0x48 8 0200000000000000
is sector 2,but may vary
Number of partition entries in partition table. This is
0x50 4 80000000
usually set to 128 which is the maximum but may vary
Size of each entry in the partition table (in bytes)
0x54 4 80000000
Note: usually set to 128 bytes but may have in size.
0x58 4 8F56F945 CRC32 checksum of the partition table.
0x5C ~ Reserved
Table 10 - GPT Header Content
One sector contains 512 bytes.
There are 128 partitions and each ‘Partition Entry’ is 128 bytes in length.
A total of 32 sectors is needed for the Partition Tables.
 GUID Partition Entries (1 to max. 128)
Using the information in the GPT header we can locate the partition tables

The partition tables are usually located in Physical Sector 2, although this may vary and should be checked
by the examiner. Each partition entry is 128 bytes in length and the entry provides much information about
the partition. Figure 39 shows the 128 bytes comprising of GPT partition entries.

0000000400 A4 BB 94 DE D 1 06 40 4D-A1 6A BF DS Ol 79 Do AC w» eWiDcO-yO—

0000000410 FA 38 AF B5 7C B4 F7 45-B7 3E 9A 8 E 2 2 BO CD OD Û 8 ~ u l '-E > " “I
0000000420 OO OS OO OO OO OO OO OO-FF 37 OC OO OO OO OO OO .............y ...........
0000000430 Ol OO OO OO OO OO OO 80-42 OO 61 OO 73 OO 69 OO B a s -x
0000000440 63 OO 2 0 OO 64 OO 61 00-74 OO 61 OO 2 0 OO 70 OO c d a t a p
0000000450 61 OO 72 OO 74 OO 69 00-74 OO 69 OO 6F OO 6 E OO a c c.-i. c i o n
0000000460 OO OO OO OO OO OO OO 0 0 - 0 0 OO OO OO OO OO OO OO
0000000470 OO OO OO OO OO OO oo 0 0 - 0 0 OO OO OO OO OO OO OO
0000000480 28 73 2A Cl IF F8 D2 11 —B A 4B OO AO C9 3E C9 3B (s*Â e>ö ° K É>É :
0000000490 FB 94 CO 67 36 72 13 4C-A1 91 03 7A E9 D6 7D 9D O A <3 c L ; - -c * 0 }
00000004a0 OO 8 8 oc OO OO OO OO OO-FF A7 14 OO OO OO OO OO .............y s ..........
000000041.0 OO OO oo oo OO OO OO 80-45 OO 46 OO 49 OO 2 0 OO E F I
00000004c0 73 OO 79 oo 73 OO 74 00-65 OO 6 D OO 2 0 OO 70 OO 3 -y -s -c -e o p
0000000440 61 OO 72 oo 74 OO 69 00-74 OO 69 OO 6F OO 6 E OO a - r -ci. -c -x -o r»
00000004*0 OO OO OO oo OO OO OO 0 0 - 0 0 OO OO OO OO OO OO OO
00000004C0 OO OO OO oo OO OO OO 0 0 - 0 0 OO OO OO OO OO OO OO E a c h e n t r y is 128
0000000500 16 E3 C9 E3 sc OB B8 4D-81 7D F9 2D FO 0 2 15 AE aÉS\ .II > - 6 b y t e s in le n g t h
0000000510 63 FA 76 93 A4 EE 33 4D-A7 C3 94 E9 14 E3 4C SD cûv n i 3M S A * SL3
0000000520 OO A3 14 OO OO OO OO OO-FF A7 18 OO OO OO OO OO ....... y s
0000000530 OO OO OO oo OO OO OO SO-4D OO 69 OO 63 OO 72 OO M i c e
0000000540 6 F OO 73 oo 6 F OO 66 00-74 OO 2 0 OO 72 OO 65 OO o -s o C c- -r *
0000000550 73 OO 65 oo 72 OO 76 00-65 OO 64 OO 2 0 OO 70 OO s e -r v -e d - p
0000000560 61 OO 72 oo 74 OO 69 00-74 oo 69 OO 6F OO 6E OO a r c. x-c. x o r»
0000000570 OO OO OO oo OO OO OO 0 0 - 0 0 oo OO OO OO OO OO OO
OOOOOOOS8 O A2 AO DO EB E 5 B9 33 44-87 CO 6 8 B6 B7 26 99 C7 « D e â * 3DÀ1Y3I ■ £ . Ç
0000000590 13 C4 4F 46 F9 FE B9 44-38 43 62 SO AE D8 89 E7 AOFÜ»J}»D H D P jcO ç
OOOOOOOSq O OO AS 18 OO OO OO OO OO-FF EF EC 71 OO OO OO OO yïxcj
OOOOOOOSbO OO OO OO OO OO OO OO 00-42 OO 61 OO 73 OO 69 OO .............B a s ■ 1 •
OOOOOOOScO 63 OO 2 0 OO 64 oo 61 00-74 OO 61 OO 20 OO 70 OO c- ■cl a c •a -p-
00000005(10 61 OO 72 OO 74 oo 69 00-74 oo 69 OO 6 F OO 6 E OO a -r - C i -c i o r»
00000005*0 OO OO OO OO OO oo OO 0 0 - 0 0 oo OO OO OO OO OO OO
OOOOOOOSCO OO nr. nn nn OO oo OO on-nn 9? OO OO OO on nn

Figure 39 - GPT Partition Entries

In order to truly understand how the GPT system works it is important to know what is contained within the
partition entries. Table 11 breaks down the 128 bytes that are used for the partition tables.

Bytes Information
Offset Length
0x00 16 Partition Type GUID (See Table 12)
0x10 16 Unique partition GIUD (Global Unique IDentifier)
0x20 8 Starting LBA of the partition
0x28 8 Ending LBA of the partition
0x30 8 Partition Attribute Flags (see Table 13)
0x38 72 Partition Name in Unicode
Table 11 - GPT Partition Entry Structure
Partitions on a GPT disk are used to hold both system information and file system information. To
accommodate this vendors are asked to assign specific values to their partitions. Table 12 shows the most
common used by Microsoft. (Appendix B has a more comprehensive list.)

Partition Type GUID Information

PARTITION_ENTRY_UNUSED There is no partition.

J3UID
00000000-0000-0000-0000-
000000000000

PARTITION_SYSTEM_GUID The partition is an EFI system partition.

c12a7328-f81f-11d2-ba4b- Contains bootmgr.exe, winload.exe and winresume.exe.
00a0c93ec93b Approx. 100MB is size.

PARTITION_MSFT_RESERVE The partition is a Microsoft reserved partition.

D_GUID Used to store temporary files and data.
e3c9e316-0b5c-4db8-817d- Every GPT disk MUST contain a MSR partition (Windows only).
f92df00215ae Size will vary up to 16Gb, depending upon the size of the disk
drive.

PARTITION_BASIC_DATA_GU The data partition type that is created and recognized by

ID Windows.
ebd0a0a2-b9e5-4433-87c0- Only partitions of this type can be assigned drive letters, receive
68b6b72699c7 volume GUID paths, host mounted folders (also called volume
mount points).
Basic data partitions correspond to primary MBR partitions 0x6
(FAT), 0x7 (NTFS), or OxB (FAT32). Each basic partition can be
mounted using a drive letter NTFS is recommended on all basic
data partitions and all dynamic volumes

PARTITION_LDM_METADATA The partition is a Logical Disk Manager (LDM) metadata partition

_GUID on a dynamic disk. This value can be set only for dynamic disks.
5808c8aa-7e8f-42e0-85d2-
e1e90434cfb3

PARTITION_LDM_DATA_GUI The partition is an LDM data partition on a dynamic disk. This

D value can be set only for dynamic disks.
af9b60a0-1431 -4f62-bc68-
3311714a69ad

PARTITION_MSFT_RECOVER The partition is a Microsoft recovery partition. This attribute can

Y_GUID be set for basic and dynamic disks.
de94bba4-06d 1-4d40-a 16a-
bfd50179d6ac

Table 12 - Partition Type GUIDs

The Attribute Flags field is 64 bit packed Binary data:
• Bit 0 - The lowest part is set to 1 to indicate that the system cannot function without this partition and
prevents the user from being able to delete or amend it.
• Bits 1-47 - undefined.
• Bits 48 - 63 are used to indicate if a drive letter is automatically assigned to the partition, shown in
Table 13.

Bit Meaning
GPT Attribute Platform required -
0
The partition is required for a computer to function properly.
60 Read only
Shadow Copy -
61
The partition a shadow copy (backup) of another partition.
Hidden partition -
62
Partition is not mounted, inaccessible by user.
No Drive letter -
63
No drive letter is assigned to the partition
Table 13 - Attribute Flags

Figure 40 is a single 128 byte GPT partition Entry broken down to show the various component parts.

M BB 94 DE Dl 06 40 4D-À16À BF D5 01 79 D6
FÀ 38 ÀF B5 7C B4 F7 45-B7 3E 9Ä 8E 22 BO CD OD — “ ÜT.q.iraiW 'G UlD
00 08 0000 00 00 00 00-FF 87 0C 00 00 00 00 00,
01 00 0000 00 00 00 80-42 00 61 00 73 00 69 00
Start lBA(secör 2048) LBA Frsrt (sector S21^47)
Attfcrts
63 00 2000 64 00 61 00-74 00 61 00 20 00 70 00 c- d a t a p-
Reqjrsä ts function (01) 61 00 7200 74 00 69 00-74 00 69 00 6F 00 6EOoV t I - H I I H t ~ ür.ieoo€Nstî
No Drive fetter aaijnedß]
00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ..........
28 73 2À Cl 1F F8 D 2 11-BÀ 4B 00 Â0 C9 3E C9 3B (s»Â ?Ô cK- É>É;
AAAAAAA4AA m A4 AA An AA HA IA 4A t t Al AA n i BA AA AA AA 1„ T . _' »

Figure 40 - GPT Partition Entry

NTFS is recommended on all basic data partitions. Windows Setup and the Disk Management will only
offer to format the partition to NTFS. Flowever, you can still use FAT16 and FAT32 on these partitions as
well. To circumvent this, the partition or volume must be formatted explicitly by using the Format tool such
as Diskpart.exe from the command line.

EFI system partition - this contains files that are needed to boot the system. It can be approx. 200MB in
size.EFI system partition can be installed using the command line utility within Windows called
Diskpart.exe, although it is not a good idea. The partition should be located either first within the partition
area or second. If second, this is usually because of the windows recovery partition being placed first by
the manufacturer.

An EFI partition can be present on a MBR disk, although it will not recognize the filesystem identifier in the
partition table entry, and will not boot. The UEFI specification actually states that this should be possible
but it is not supported by windows.

The file systems used within the EFI partition is either FAT12, FAT16 or FAT32, as seen in the Figure 41
this was obtained from a 2013 Windows 8 HP Pavilion G6:-
CO
Cn

EB 58 90 4D 53 44 4F 53- 2E 30 00 02 08 FE IB ëX HSD0S5 .0 • • Jd •
i

02 00 00 00 00 F8 00 00--3F 00 FF 00 00 88 OC 00 .... 0 • •? Ÿ ....

00 20 08 00 01 02 00 00--00 00 00 00 02 00 00 00
01 00 06 00 00 00 00 00--00 00 00 00 00 00 00 00
80 00 29 D1 0B F2 DA 4E--4F 20 4E 41 4D 45 20 20 ••)N •ÔÜN0 NAME
20 20 46 41 54 33 32 20--20 20 33 C9 8E D1 BC F4 FAT32 3É -H*ô
7B 8E Cl 8E D9 BD 00 7C--88 56 40 88 4E 02 8À 56 { - A - f t a - 1 •’ 7 0 n • - v

40 B4 41 BB ÀÀ 55 CD 13--72 10 81 FB 55 AA 75 0A 6 'A»aUÎ -r • û U au •
Figure 41 - Partition V BR

Microsoft Reserved Partition (MSR) - Every GPT disk running Windows MUST have a MSR partition
present in order to function. The MSR must be created before the data partitions in order to secure the
amount of space needed. The MSR secures is used by the operating system, this includes for retaining
some temporary files. The MSR can be up to 128 MB or greater and is dependent upon the size of the
hard drive. In testing the MSR was 128MB in size when placed on a 1TB (terabyte) hard drive running
Windows 8 (64-bit).

GPT Backup
One of the advantages of using a GUID partition structure is the additional resilience it provides. Located
at the end of the disk is an entire backup of the Primary partition entries and the GPT header

The GPT header (located at the beginning of the disk (PS1)) contains details of where the backup is located
at bytes offset 32-39.

When navigating to this location of the backup, the examiner will notice that the backup partition tables are
placed before the GPT header and not after, as at the beginning of the drive. This effectively places a
mirror on the disk showing the reflection.
 The GPT Backup is located within the last sector of the drive. In order to locate the partition tables navigate
back up the drive approximately 32 sectors.

Comparison of MBR and GPT disks

We have seen that disks can use either the master boot record (MBR) or GUID partition table (GPT)
partitioning style. The following figure 42 compares a basic MBR disk to a basic GPT disk. 32 bit
architecture (x86-based) computers use disks with the MBR partitioning style and 64 bit architecture
(Itanium-based) computers use disks with the GPT partitioning style.

Basic MBR D isk Basic G P T Disk

■ M aster Boot Code M aster Boot Code

1st Partition Table 1st Partition Table
Entry Entry
2nd Partition Table 2nd Partition Table
Entry ________ Entry________
Master Partition - - Protective
Boot Table 3rd Partition Table 3rd Partition Table MBR
Record Entry Entry
4th Partition Table 4th Partition Table
Entry Entry
0x55 AA 0x55 AA
Prim ary GUID
Prim ary Partition (C:) Partition Table
Header
GUID Partition Entry 1
Prim ary Partition (E :)
GUID Partition Entry 2
GUID Partition Entry n - P rim ary
GUID
P rim ary Partition (F:) GUID Partition Entry Partition
128 Entry Array

Logical Drive (G:) Prim ary Partition (C:)

Extended — Logical Drive (H :) P rim ary Partition (E:)

Partition

Logical Drive n Prim ary Partition n

GUID Partition Entry 1

GUID Partition Entry 2
GUID Partition Entry n - Backup
GUID
GUID Partition Entry Partition
_________ 128________ Entry Array
Backup GUID
Partition Table Header
5https://technet.microsoft.com/en-us/library/cc739412%28WS.10%29.aspx#w2k3tr_basic_how_fgkm

©2018IACIS Disk Structures Page 43 of 63

X. Host Protected Areas and Drive C onfiguration Overlays

Host Protected Area (HPA) was introduced by the ATA-4 specifications T13, 2001. It is defined as a special
area reserved on a hard disk that can be used to store information which cannot be modified, changed or
even accessed by the User, the BIOS / UEFI or the operating system. The sort of information that will be
stored in this area can ranges from HDD manufacturer tools to recovery and diagnostic tools. The size of
this area is configurable using the ATA command

Drive Configuration Overlay (DCO) was introduced with ATA-6 standard. The initial intention was to allow
manufacturers to build different products from standard components i.e. they purchase similar hard drives
from different manufacturers and then make them all have the same number of sectors. The DCO allows
for different sized hard drives to be used and then configured with the same number of sectors. An example
would be that of an 80GB hard drive that has a DCO to make the drive appear as a 60GB drive. Like the
HPA above, information stored within the DCO is not accessible to the BIOS, OS or Users.

There are a number of tools and commands available that would allow user to access and modify these
areas, so therefore it is very important for computer forensic examiners that we are aware of these hidden
areas and we must ensure that through our process of validation that our imaging tools capture the contents
of the HPA and DCO.

It is often good practice for examiners to examine the outside label of the hard drive and then conduct
research with the manufacturer to gain a better understanding of the capability of the drive. Most modern
hard drives will support ATA-4 and ATA-6. Therefore there is a potential that the drive being examined will
contain a HPA and DCO

A number of years ago HPA and DCO’s were causing issues for forensic examiners because the imaging
software was not identifying the areas during the imaging process. It is always good practice for examiners
to test and verify their tools and manually conduct the maths based on the drive information from the
outside of the disk and the manufacturers' websites to ensure they have all sectors accounted for within
their image.

The key thing to look for with working with physical disks is to ensure the number of sectors that are
viewable match the disk drive label and manufacturer’s information for that disk. Then no data is being
overlooked.
XI. C onclusion

The physical characteristics of hard drives are changing from Platter to semi-conductors. The sector size
used to store data is increasing from 512 to 4096KB. Hard drive capacity is increasing. Logical Block
addressing (LBA) is the primary method for addressing sectors within the hard drive.

A Logical Disk Structure allocates areas of the storage device into individual blocks. The Master Boot
record is vitally important to a hard drive even when using the GPT scheme.

The GPT partition scheme is far more resilient than the older Master Partition Table, and Extended Primary
Partition systems. The number of partitions a hard disk can hold is dependent upon the scheme being
used but ranges from 24 to 126.

The ability to understand and manually interpret the information contained within the Partition Tables is
vitally important to help an examiner locate user data. This understanding of Logical Disk Structure can
be vital when there is damage to the MBR, as that understanding of residual structures on the drive can
be used to find volumes that were thought to be deleted.
XII. A ppendix A - MBR file system type values

Byte File System Type

00 Empty
01 DOS 12-bit FAT (up to 15 M)
02 XENIX root
03 XENIX/usr
04 DOS 3.0+ 16-bit FAT (up to 32M)
05 DOS 3.3+ Extended Partition
06 DOS 3.31+ 16-bit FAT (over 32M)
07 OS/2 IFS (e.g., HPFS)
07 Windows NT NTFS
07 Advanced Unix
07 QNX2.X pre-1988
08 OS/2 (vl.0-1.3 only)
08 AIX boot partition
08 SplitDrive
08 Commodore DOS
08 DELL partition spanning multiple drives
08 QNX 1.x and 2.x ("qny")
09 AIX data partition
09 Coherent filesystem
09 QNX 1.x and 2.x ("qnz")
0a OS/2 Boot Manager
0a Coherent swap partition
Oa OPUS
Ob WIN95 OSR2 32-bit FAT
Oc WIN95 OSR2 32-bit FAT, LBA-mapped
Oe WIN95: DOS 16-bit FAT, LBAmapped
Of WIN95: Extended partition, LBA-mapped
10 OPUS (?)
11 Hidden DOS 12-bit FAT
12 Configuration/diagnostics partition
Byte File System Type
14 Hidden DOS 16-bit FAT <32M
16 Hidden DOS 16-bit FAT >=32M
17 Hidden IFS (e.g., HPFS)
18 AST SmartSleep Partition
19 Unused
1b Hidden WIN95 OSR2 32-bit FAT
1c Hidden WIN95 OSR2 32-bit FAT, LBA-mapped
1e Hidden WIN95 16-bit FAT, LBA-mapped
20 Unused
21 Reserved
21 Unused
22 Unused
23 Reserved
24 NEC DOS 3.x
26 Reserved
31 Reserved
32 NOS
33 Reserved
34 Reserved
35 JFS on OS/2 or eCS
36 Reserved
38 THEOS ver 3.2 2gb partition
39 Plan 9 partition
39 THEOS ver 4 spanned partition
3a THEOS ver 4 4gb partition
3b THEOS ver 4 extended partition
3c PartitionMagic recovery partition
3d Hidden NetWare According to Powerquest.
40 Venix 80286
41 Linux/MINIX (sharing disk with DRDOS)
41 Personal RISC Boot
41 PPC PReP (Power PC Reference Platform) Boot
Byte File System Type
42 Linux swap (sharing disk with DRDOS)
42 SFS (Secure Filesystem)
42 Windows 2000 dynamic extended partition marker
43 Linux native (sharing disk with DRDOS)
44 GoBack partition
45 Boot-US boot manager
45 Priam
45 EUMEL/Elan
46 EUMEL/Elan
47 EUMEL/Elan
48 EUMEL/Elan
4a Mark Aitchison's ALFS/THIN lightweight filesystem
4a AdaOS Aquila (Withdrawn)
4c Oberon partition
4e QNX4.x 2nd part
4f QNX4.x 3rd part
4f Oberon partition
50 OnTrack Disk Manager (older versions) RO
50 Lynx RTOS
50 Native Oberon (alt)
51 OnTrack Disk Manager RW (DM6 Aux1)
51 Novell
52 CP/M
52 MicroportSysV/AT
53 Disk Manager 6.0 Aux3
54 Disk Manager 6.0 Dynamic Drive Overlay
55 EZ-Drive
56 Golden Bow VFeature Partitioned Volume.
56 DM converted to EZ-BIOS
57 Drive Pro
57 VNDI Partition
5c Priam EDisk
Byte File System Type
61 SpeedStor
63 Unix System V (SCO, ISC Unix, UnixWare,
64 PC-ARMOUR protected partition
64 Novell Netware 286, 2.xx
65 Novell Netware 386, 3.xx or 4.xx
66 Novell Netware SMS Partition
67 Novell
68 Novell
69 Novell Netware 5+, Novell Netware NSS Partition
70 DiskSecure Multi-Boot
71 Reserved
73 Reserved
74 Reserved
74 Scramdisk partition
75 IBM PC/IX
76 Reserved
77 M2FS/M2CS partition
77 VNDI Partition
78 XOSLFS
7e Unused
7f Unused
80 MINIX until 1.4a
81 MINIX since 1.4b, early Linux
81 Mitac disk manager
82 Prime
82 Solaris x86
82 Linux swap
83 Linux native partition
84 OS/2 hidden C: drive
84 Hibernation partition
85 Linux extended partition
86 Old Linux RAID partition superblock
Byte File System Type
86 NTFS volume set
87 NTFS volume set
8a Linux Kernel Partition (used by AiR-BOOT)
8b Legacy Fault Tolerant FAT32 volume
8c Legacy Fault Tolerant FAT32
8d Free FDISK hidden Primary DOS FAT12 partition
8e Linux Logical Volume Manager partition
90 Free FDISK hidden Primary DOS FAT16 partition
91 Free FDISK hidden DOS extended partition
92 Free FDISK hidden Primary DOS large FAT16 partition
93 Hidden Linux native partition
93 Amoeba
94 Amoeba bad block table
95 MIT EXOPC native partitions
97 Free FDISK hidden Primary DOS FAT32 partition
98 Free FDISK hidden Primary DOS FAT32 partition
98 Datalight ROM-DOS Super-Boot Partition
99 DCE376 logical drive
9a Free FDISK hidden Primary DOS FAT16 partition (LBA)
9b Free FDISK hidden DOS extended partition (LBA)
9f BSD/OS
aO Laptop hibernation partition
a1 Laptop hibernation partition
a1 HP Volume Expansion (SpeedStor variant)
a3 Reserved
a4 Reserved
a5 BSD/386, 386BSD, NetBSD, FreeBSD
a6 OpenBSD
a7 NEXTSTEP
a8 Mac OS-X
a9 NetBSD
aa Olivetti Fat 12 1.44MB Service Partition
Byte File System Type
ab Mac OS-X Boot partition
ab GO! partition
ae ShagOS filesystem
af ShagOS swap partition
bO BootStar Dummy
b1 Reserved
b3 Reserved
b4 Reserved
b6 Reserved
b6 Windows NT mirror set (master), FAT16 file system
b7 Windows NT mirror set (master), NTFS file system
b7 BSDI BSD/386 filesystem
b8 BSDI BSD/386 swap partition
bb Boot Wizard hidden
be Solaris 8 boot partition
cO CTOS
cO REAL/32 secure small partition
cO NTFT Partition
cO DR-DOS/Novell DOS secured partition
c1 DRDOS/secured (FAT-12)
c2 Reserved for DR-DOS 7+
c2 Hidden Linux
c3 Hidden Linux swap
c4 DRDOS/secured (FAT-16, < 32M)
c5 DRDOS/secured (extended)
c6 DRDOS/secured (FAT-16, >= 32M)
c6 Windows NT corrupted FAT16 volume/stripe set
c7 Windows NT corrupted NTFS volume/stripe set
c7 Syrinx boot
c8 Reserved
c9 Reserved
ca Reserved
Byte File System Type
cb reserved for DRDOS/secured (FAT32)
cc reserved for DRDOS/secured (FAT32, LBA)
cd CTOS Memdump?
ce reserved for DRDOS/secured (FAT16, LBA)
dO REAL/32 secure big partition
d1 Old Multiuser DOS secured FAT12
d4 Old Multiuser DOS secured FAT16 <32M
d5 Old Multiuser DOS secured extended partition
d6 Old Multiuser DOS secured FAT16 >=32M
d8 CP/M-86
da Non-FS Data
db Digital Research CP/M, Concurrent CP/M
db CTOS (Convergent Technologies OS -Unisys)
db KDG Telemetry SCPU boot
dd Hidden CTOS Memdump?
de Dell PowerEdge Server utilities (FAT fs)
df DG/UX virtual disk manager partition
df Bootlt EMBRM
eO Reserved by STMicroelectronics for ST AVFS.
e1 DOS access or SpeedStor 12-bit FAT extended partition
e3 DOS R/O or SpeedStor
e4 SpeedStor 16-bit FAT extended partition < 1024 cyl.
e5 Tandy DOS with logical sectored FAT
e5 Reserved
e6 Reserved
eb BeOS
ed Reserved for Matthias Paul's Spryt*x
ee Indication that this legacy MBR is followed by an EFI header
ef Partition that contains an EFI file system
fO Linux/PA-RISC boot loader
f1 SpeedStor
f2 DOS 3.3+ secondary partition
Byte File System Type
f3 Reserved
f4 SpeedStor large partition
f4 Prologue single-volume partition
f5 Prologue multi-volume partition
f6 Reserved
fa Bochs
fb VMware File System partition
fc VMware Swap partition
fd Linux raid partition
fe SpeedStor> 1024 cyl.
fe LANstep
fe IBM PS/2 IML (Initial Microcode Load) partition
fe Windows NT Disk Administrator hidden partition
 fe Linux Logical Volume Manager partition (old)
ff Xenix Bad Block Tab

Source - http://www.win.tue.ni/~aeb/partitions/partition_types-1 .html

XIII. A ppendixB - GPT partition type GUIDs

00000000000000000000000000000000) system='Unused entry';;

41ee4d02e733d3119d690008c781f39f) system='MBR partition scheme';;
28732ac11ff8d211ba4b00a0c93ec93b) system-EFI System partition';;
4861682149646f6e744e656564454649) system='BIOS Boot partition';;

## GUIDs that are not unique for one OS ##

a2a0d0ebe5b9334487c068b6b72699c7) system='Data partition (Windows/Linux)';;
c38c896ad21db21199a6080020736631) system='ZFS (Mac OS X) or/usr partition (Solaris)';;

## Windows GUIDs##
16e3c9e35c0bb84d817df92df00215ae) system-Microsoft Reserved Partition (Windows)’;;
# Same GUID as old GUID for "Basic data partition (Linux)"
# a2a0d0ebe5b9334487c068b6b72699c7) system='Basic data partition (Windows)';;
aac808588f7ee04285d2e1e90434cfb3) system-Logical Disk Manager metadata partition (Windows)';;
a0609baf3114624fbc683311714a69ad) system='Logical Disk Manager data partition (Windows)';;
a4bb94ded106404da16abfd50179d6ac) system-Windows Recovery Environment (Windows)';;
90fcaf377def964e91c32d7ae055b174) system-IBM General Parallel File System (GPFS) partition
(Windows)';;

## HP-UX GUIDs##
1e4c8975eb3ad311b7c17b03a0000000) system='Data partition (HP-UX)';;
28e7a1e2e332d611a6827b03a0000000) system='Service Partition (HP-UX)';;

## Linux GUIDs ##
# Same GUID as "Basic data partition (Windows)" GUID
# a2a0d0ebe5b9334487c068b6b72699c7) system-Data partition (Linux)';;
# New GUID to avoid that Linux partitions show up as unformatted partitions in Windows.
af3dc60f838472478e793d69d8477de4) system='Data partition (Linux)';;
0f889da1fc053b4da006743f0f84911e) system='RAID partition (Linux)’;;
6dfd5706aba4c44384e50933c84b4f4f) system-Swap partition (Linux)';;
79d3d6e607f5c244a23c238f2a3df928) system='Logical Volume Manager (LVM) partition (Linux)';;
3933a68d0700c060c436083ac8230908) system='Reserved (Linux)';;

## FreeBSD GUIDs##
9d6bbd83417fdc11be0b001560b84f0f) system='Boot partition (FreeBSD)';;
b47c6e51 cf6ed6118ff800022d09712b) system='Data partition (FreeBSD)';;
b57c6e51 cf6ed6118ff800022d09712b) system-Swap partition (FreeBSD)';;
b67c6e51 cf6ed6118ff800022d09712b) system-Unix File System (UFS) partition (FreeBSD)';;
b87c6e51 cf6ed6118ff800022d09712b) system='Vinum volume manager partition (FreeBSD)’;;
ba7c6e51 cf6ed6118ff800022d09712b) system='ZFS partition (FreeBSD)';;

## Mac OS X GUIDs ##
005346480000aa11aa1100306543ecac) system='Hierarchical File System Plus (HFS+) partition (Mac OS X)';;
005346550000aa11aa1100306543ecac) system='Apple UFS (Mac OS X)’;;
# c38c896ad21db21199a6080020736631) system='ZFS (Mac OS X)’;;
444941520000aa11aa1100306543ecac) system='Apple RAID partition (Mac OS X)';;
444941524f5faa11aa1100306543ecac) system='Apple RAID partition offline (Mac OS X)';;
746f6f420000aa11aa1100306543ecac) system='Apple Boot partition (Mac OS X)';;
6562614c006caa11aa1100306543ecac) system='Apple Label (Mac OS X)';;
6f6365526576aa11aa1100306543ecac) system='Apple TV Recovery partition (Mac OS X)';;

## Solaris GUIDs##
45cb826ad21db21199a6080020736631) system='Boot partition (Solaris)';;
4dcf856ad21db21199a6080020736631) system='Root partition (Solaris)';;
6fc4876ad21db21199a6080020736631) system='Swap partition (Solaris)';;
2b648b6ad21db21199a6080020736631) system -Backup partition (Solaris)';;
# c38c896ad21db21199a6080020736631) system='/usr partition (Solaris)';;
e9f28e6ad21db21199a6080020736631) system='/var partition (Solaris)';;
39ba906ad21db21199a6080020736631) system='/home partition (Solaris)';;
a583926ad21db21199a6080020736631) system='Alternate sector (Solaris)';;
3b5a946ad21db21199a6080020736631) system='Reserved partition (Solaris)';;
d130966ad21db21199a6080020736631) system='Reserved partition (Solaris)';;
6707986ad21db21199a6080020736631) system='Reserved partition (Solaris)';;
7f23966ad21db21199a6080020736631) system-Reserved partition (Solaris)';;
c72a8d6ad21db21199a6080020736631) system='Reserved partition (Solaris)';;

## NetBSD GUIDs ##
328df4490eb1 dc11b99b0019d 1879648) system='Swap partition (NetBSD)';;
5a8df4490eb1dc11b99b0019d1879648) system='FFS partition (NetBSD)’;;
828df4490eb1dc11b99b0019d1879648) system=’LFS partition (NetBSD)’;;
aa8df4490eb1 dc11b99b0019d1879648) system='RAID partition (NetBSD)';;
C419b52d0fb1dc11b99b0019d1879648) system='Concatenated partition (NetBSD)';;
ec19b52d0fb1dc11b99b0019d1879648) system='Encrypted partition (NetBSD)';;

## ChromeOS GUIDs ##
5d2a3afe324fa741b725accc3285a309) system="ChromeOS kernel";;
02e2b83c7e3bdd478a3c7ff2a13cfcec) system="ChromeOSrootfs";;
3d750a2e489eb0438337b15192cb1b5e) system="ChromeOS future use";;

Source https://gist.github.com/integ3r/4462902
XIV. Appendix C - Class Exercises

Exercise 1

Create Virtual Hard Disk (VHD)

• Run Disk Management - Right Click Start Icon, Select Disk Management
• On right of screen select "More Actions”
• From menu select "Create VHD"
- Location: ‘‘Desktop\MBR.vhd”
- Size: “2 GB”
- Format: “Dynamically Expanding”

View VHD in Disk Management

Open Disk in Forensic Explorer

• Run Forensic Explorer
• Create a new case.
• Click on Add Device
• Select the Virtual Disk e.g. HD1 (2.0GB)
• Click on File System and Highlight HD1
• Observe Blank Disk (0x00)

Go back to Disk Management Window

Initialize Disk
• Right click on “Disk 1" (2,00 GB)
• Initialize Disk
• Select “MBR”
• Click “OK”

Go Back to Forensic explorer and Refresh

Notice the changes made by initialize disk

Run Disk Management (if closed) and re-Attach VHD (if necessary)

• On right of screen select “More Actions”

• From menu select “Attach VHD”
• Browse to “Desktop/MBR.vhd”

Examine in Forensic Explorer - Disk View

Highlight regions as follows

• Offset 0x0, for 0x1 b8 bytes Y E L L O W - B o o t Strap

• Offset 0x1 b8, for 0x4 bytes R E D - D isk Sign atu re
• Offset 0x1be, for 0x10 bytes G R E E N - Partition Table entry 1
• Offset 0x1 ce, for 0x10 bytes B lue - Partition Table entry 2
• Offset Oxide, for 0x10 bytes O ra n ge - Partition Table entry 3
• Offset 0x1 ee, for 0x10 bytes B row n - Partition Table entry 4
• Offset 0x1 fe, for 0x2 bytes Purple - Boot Sector Signature

aS Hex
0 2 4 3 5 6 7 e 5 X 3 c D z ; 10 11 12 13 14 15 16 17 IS
0000:0000 33 CO B£ BCDO 00 7C B£ CO 3£ D3 3£ 00 7C 3F 00 06 35 00 02 FC F3 A4 50 63
3&.S«c. 1.k .B M . I j . . » . . üeaPh
0000:0015 1C 06 C3 35F3 04 3D 3£ 07 80 7£ 0Ô 00 7C 03 OF 35 0£ 01 33 CS 10 £2 FI
. . ¿ ü 1. . h k . . I ...............A. in
0000:0032 CD 13 33 0056 55 C6 46 : : 05 C6 46 10 00 34 41 33 XX 55 CD 13 5D 72 OF 31
i . .V . U £ £ . . £ £ .. .
0000:0043 F3 55 XX 0575 F7 Cl 01 00 74 03 TZ 46 10 66 60 SO 7£ 10 00 74 26 66 63 00
üü**u. -¡-A. . t . f c F . f * .tsfh.
0000:0064 00 00 00 FF66 76 05 63 00 00 63 00 7C 63 01 00 €3 10 00 34 42 3X 56 00 33
. . .fy v .h ..h .Ih ..h .. '3.V ..
0000:0070 F4 CD 13 335F C4 10 3£ £3 14 33 01 02 33 00 7C 3X 56 00 BA 76 01 5X a 4£ 02 i . _____» . I . V . . V . . H .
0000:0056 SX €£ 03 13CD 66 61 73 1C ÎT 4£ 11 75 OC 30 7£ 00 30 OF 34 3X 00 32 . n . i . £ a s . £ N . u . . ~ ...............‘ . e
30 £3
0000:00X1 54 55 32 5X£4 56 :: CD 13 5D £3 9£ 31 3£ F£ 7D 55 XX 75 €£ FF 76 00 £3
■U 2 * . V . i . ] * . .> J> }0 » u n Jv .i.
BD
0000:00C8 :: 75 17 =:FX D1 £6 64 £3 33 :: s: or £6 60 Z3 7C 00 30 7T £6 64 £3 75 00
. u . a ' K a d e . . f 5 s * e 1 . 'yedeu.
0000:0011 F3 33 00 CD33 IX 66 23 CO 75 33 66 31 F3 54 43 50 41 75 32 31 F9 02 01 72
u , . » I . f * X u ; f . üTCPAu2.ü. .r
0000:00FX 2C €6 €3 3307 00 00 66 63 00 02 00 00 66 63 03 00 00 :: 66 53 66 53 66 55
, f b . » . . f b ----- f h ------ f S f S f O
0000:0113 €6 €8 00 0000 00 66 63 00 7C 00 00 66 61 63 00 00 07 CD IX 5A 32 F6 IX 00
£h_____f h . 1. . £ » h . . ,i .Z 2 S e .
0000:0120 7C 00 00 ISCD xo 37 £3 : e XO 36 07 £3 03 XO 35 07 32 £4 05 00 07 33 F0
I . . i . • . « . S . e . u . 2& . . . . 3
0000:0145 xc 3C 00 0574 33 07 00 34 0£ CD :: £3 F2 F4 £3 FD 23 C9 £4 64 £3 00 24
- < .z 02 1 . e c c ey +i ad e. 5.
0000:015- £0 F3 24 C302 45 €£ 76 61 6C 69 64 :: 61 72 74 65 74 65 6F 6£ 20 74 61
a o S . X l nv a l i d p a r t i t i o n ta
0000:0177 €2 6C 65 4500 72 72 6F 72 20 6C 6F €1 64 65 61 67 20 €T 70 65 72 61 74 65
b l e . Z r r c r lo a d in g eper a t i
0000:0150 6£ €7 20 7573 73 74 65 €D 00 4D 65 73 73 65 6£ €7 20 6F 70 65 72 61 "4 65
ng s y s te s .M is s in g eper a t i
0000:01X5 €£ €7 20 7573 73 74 65 6D 00 00 00 63 73 SX 70 7F C5 S3 00 00 00 00 00 00
r.g s y s t e s . . . c { . p . A [ ..............
0000:01C2 00 00 00 0000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
....................................................................
1

0000:0123 00 00 00 00 00 00 00 00 00 00 00 00 00 00 oo
0
ol

.................................................m m
0000:01F4 00 w 00 OS 03 00 00 00 00 : : XX 00 00 00 00 00 00 00 00 00 00 00 00 00 m m m » ..................................

Create 3 Partitions in VHD

• Diski -> Unallocated Region ->Right Click -> New Simple Volume
• Next
• 100mb->Next
• Do not assign drive letter -> Next
• Do not format -> Next

• Repeat the above to create Second Partition of size 200MB

• Repeat the above to create Third Partition of size 300MB

■-J Disk 1
Basic
2.00 GB 103 MB RAW 200 MB RAW 300 MB RAW 1.41 GB
Online Healthy (Primar)' Parti Healthy (Primary Partitior Healthy (Primary' Partition) Unallocated

Examine in Forensic Explorer

• Locate and highlight each of the four partition entries

Exercise 3

Create 2 more Partitions in VHD

• Fourth Partition: Right click on unallocated -> New Simple Volume

• Size: 400 MB
• Do not assign drive letter
• Format as FAT

• Repeat above steps to create Fifth Partition: 500MB

^ Diski
Basic
2.00 GB 100 MB RAW 200 MB RAW 300 MB RAW 400 MB RAW 500 MB RAW 546 MB
Online Healthy (Prim Healthy (Priman Healthy (Primary Healthy (Logical C Healthy (Logical Dr Free space

- b -----------------------

Examine in Forensic Explorer

Locate the partition entry for the first extended partition (partition table entry 4)

Interpret the LBA offset

• Hint: it’s in sectors

Inspect the partition entries in 1st Extended Partition

Partition First Table Entry 1 Pointing to itself i.e. 4tri Partition/1st Extended Partition
1st Extended Logical Partition Starting Sector:
PS 1,228,928 + 128 = PS 1,229,056
1st Extended Logical Partition Ending Sector
PS 1,229,056 + 819,200 (Total Sectors) - 1 = PS 2,048,255
(Total Sectors = Offset OxOC for length 4 bytes in Partition Entry - Hex 00 OC 80 00 = 819,200 decimal)

Locate the partition entry for the next extended partition (Partition Table Entry 2)

Second Partition Entry Pointing to Next Extended Partition i.e. 5th Partition /2nd Extended Partition

Interpret the LBA offset

• Hint: it’s in sectors AND it’s relative to the start of the first extended partition (the value we wrote
down)

ELP2 - Preceding Sectors Interpreted (819,328)

PS 1,228,928 + 819,328 = PS 2,048,256

i.e. ELP2 is located at PS 2,048,256

Inspect the partition entries

One Partition Table Entry (points to itself) i.e no further extended partitions)

ELP2 - Total Sectors Interpreted (1,024,128)

ELP2 ends at PS 2,048,256 + 1,024,128 - 1 = PS 3,072,383

Partition Template for Extended Logical Partitions

Create a new VHD
• Save to “Desktop/GPT.vhd”
• Size: 2 Gb
• Format: Dynamically Expanding

Initialize Disk
• Right click -initialize -> GPT

Examine in Forensic Explorer

Add partition
• Right click on unallocated -> New Simple Volume
• Size: 200mb
• Do not assign a drive letter
• Do not format

Examine in Forensic Explorer

Inspect Protective MBR at PS 0

Inspect GPT Header at PS 1

Inspect the Partition Entries starting at PS 2.

XV. G lossary

EIDE - Short for Enhanced IDE, a newer version of the IDE mass storage device interface standard
developed by Western Digital Corporation. It supports data rates of between 4 and 16.6 MBps, about three
to four times faster than the old IDE standard. In addition, it can support mass storage devices of up to 8.4
gigabytes, whereas the old standard was limited to 528 MB. Because of its lower cost, enhanced EIDE
has replaced SCSI in many areas.

SCSI - An abbreviation for Small Computer System Interface, SCSI is a standard interface for connecting
a wide variety of devices to a computer. Although the most popular SCSI devices are disk drives, SCSI
tape drives and scanners are also common.

Serial ATA - Often abbreviated SATA or S-ATA, an evolution of the Parallel ATA physical storage interface.
Serial ATA is a serial link -- a single cable with a minimum of four wires creates a point-to-point connection
between devices. Transfer rates for Serial ATA begin at 150 MBps and SATA II 300MBps. One of the main
design advantages of Serial ATA is the thinner serial cables facilitate more efficient airflow inside a form
factor and also allow for smaller chassis designs. In contrast, IDE cables used in parallel ATA systems are
bulkier than Serial ATA cables and can only extend to 40cm long, while Serial ATA cables can extend up
to one meter.

Platter- Drives will have one or more spinning platters made of rigid aluminium or glass coated with various
forms of a magnetic substrate. Floppy disks, in contrast to hard drives, are composed of a flexible Mylar
platter coated with iron oxide material. Each side of the platter has a read/write head fixed over it. The
head measures the resistance changes that occur due to transitions in the magnetic flux.

Cylinders - The identical tracks on each side of the platters combined are called CYLINDERS. If there
were three platters in the drive, there would be six sides each with a track 1. These six tracks would be
referred
collectively as cylinder 1. The hard drive numbering scheme actually labels the first cylinder, track and
head as 0 instead of 1.

Heads - The platters spin over the fixed head and the data is aligned accordingly. When reading, the head
determines the polarity changes that occur and more importantly, it measures the timing between the
changes and between the data cells.

Drive Sectors - Tracks can contain a considerable amount of data and are subsequently broken down
into the smaller units known as SECTORS. Sectors are generally made up of 512 bytes of accessible data.
If it were possible to have other sized sectors they would be not be readable by a DOS/Windows system.
Unlike tracks, cylinders, or heads, the sectors are numbered beginning with 1 and not 0. Along with the
512 bytes of accessible data there are also 59 additional bytes used for error checking and synchronization.

Low Level Format - During the low-level format process the tracks are laid out and split into a set number
of sectors. Each sector on the disk is given a three-dimensional address indicating which cylinder (C) it is
located on, which head (H) or platter and side it is on, as well as a number for that sector (S). This is
referred to as the CHS reference. The data area of each sector is then filled with a constant data value.

Zone Recording - A method which made better use of the space by varying the number of sectors per
track. The drives are split into zones and each zone has a different number of sectors.
Logical Block Addressing (LBA) - LBA manipulates the CHS values. It simply treats the sectors linearly
and numbers each one of them consecutively.

EFI - Extendible Firmware Interface - software interface being used to replace old legacy BIOS to control
boot up of computer systems, originally developed by Microsoft and now replaced by UEFI.

Extended Primary Partition(EPP) - This is an Extended Partition that is referenced to in the Master
Partition Table. The EPP acts like a container holding details of the Extended Logical Partition (ELP). The
container can then be split into several smaller partitions, thus allowing up to a total of twenty- four
partitions.

Extended Logical Partition(ELP) - There must be at least one ELP within an EPP. The ELP will contain
a Volume Boot Record (VBR) as well as a number of reserved sectors. The ELP partition table will only
contain two entries, although it will have room for four. The first partition entry will relate to itself, the second
entry will relate to the location of the next ELP (if present).

GPT - GUID Partitioning Table scheme

GUID partition table (GPT) disks use primary and backup partition structures to provide redundancy. These
structures are located at the beginning and the end of the disk. GPT identifies these structures by their
logical block address (LBA) rather than by their relative sectors.

GUID - Global Unique IDe.ntifier

Logical Disk- Logical drives (often called “volumes") are divisions of a physical hard disk drive. They
exist at the operating system level meaning that depending on how the user has prepared the physical
media the operating system might see 1 or many “volumes,” all of which are part of one single physical
device. Logical drives or volumes are most commonly referred to by letter (as in a “drive letter” such as
C:, D:, etc.).

Master Boot Record- MBR - A Master Boot Record (MBR) consists of data that is loaded onto the first
physical sector of a disk (Physical Sector 0) that contains key information needed by the computer to
continue operating after the system BIOS finishes executing its instructions. The MBR contains
programming “boot code” that tells the computer how many partitions are on the media as well as what
type of filing systems are used for each partition (Partition Table). Without a MBR, the computer would
stop after the BIOS finished executing its data because it wouldn’t know where to go next to find its
instructions about what to load next.

Master Partition Table- This refers to the partition table located in the MBR of a hard disk that dictates
how the disk is partitioned and includes information such as the size and location of the partitions, which
file system each partition uses, and which partition is bootable or not.

Primary Partition- A Primary Partition is a partition on a piece of media that can either be set to “bootable”
or “non-bootable”. A hard disk drive must contain at least one Primary Partition.

Protective MBR- The Protective MBR has the same format as an existing MBR, and it contains one
partition entry with a System ID value of OxEE.

Physical Disk- Physical drives are, as the name implies, the actual physical device (that would contain
the logical drives or volumes). Typically, physical drives are referred to by number (i.e. drive 0, drive 1).
It is of note that some software will address the first physical hard drive as “drive 0” while others will address
the same device as “drive 1 Moreover, the BIOS will identify hard disk drives as drive BIOS drives 0x80,
0x81,0x82, etc.

Solid State Drive/ Disk- Often referred to as a SSD, this is a high performance plug and play storage
device. It contains no moving parts and uses non-volatile flash memory to store data. They produce very
high read/write (referred to as I/O) speeds.

V B R -Volume Boot Record - The 1st sector of a formatted partition, used to define the file system contained
within the partition.

UEFI - Unified Extendible Firmware Interface. - Replaced EFI and is a standardized specification to replace
BIOS.
 FAT File System
IACIS
The International Association of
Windows File Systems
Computer Investigative Specialists

Contents
I. Synopsis....................................................................................................................................................... 1
II. Learning Objectives..................................................................................................................................... 2
III. Historical Overview of the FAT File Systems...............................................................................................2
IV. Components of the FAT File System...........................................................................................................4
V. Volume Boot Record.................................................................................................................................... 5
VI. Directory Entries......................................................................................................................................... 10
VII. 32-Byte SFN Directory Entry...................................................................................................................... 11
VIII. File Allocation Table (x2)............................................................................................................................ 21
IX. Cluster Chaining......................................................................................................................................... 24
X. Contiguous vs. Fragmented files................................................................................................................27
XI. Data Area................................................................................................................................................... 28
XII. Formatting a FAT File System...................................................................................................................30
XIII. File Creation and Deletion.......................................................................................................................... 31
XIV. Recovering Deleted Files........................................................................................................................... 31
XV. File Recovery with a Hex Editor.................................................................................................................32
XVI. Long Filename Entries............................................................................................................................... 37
XVII. Recovering of Long File Names.................................................................................................................41
XVIII. File Slack.................................................................................................................................................... 42
XIX. Volume Slack............................................................................................................................................. 48
XX. Recommended Resources......................................................................................................................... 49
XXI. Answer Key................................................................................................................................................ 50

Synopsis

FAT is by far the most simplistic of the file systems supported by the Windows family of operating systems.
The FAT file system is characterized by the File Allocation Table (FAT), which is a flat table that tracks
usage of the volume’s data area. For redundancy, two copies of the FAT are kept in the event that one
becomes damaged. In addition, the FAT tables, the root directory, and Volume Boot Record must be
stored in known locations so that the system's boot record and files can be correctly located.
 Learning O bjectives

This module describes how the FAT Filing System organizes data. Understanding the rules of a FAT
volume will aid the students with locating and recovering evidence that has otherwise been hidden to the
casual user. At the conclusion of this lesson the student should understand:
• The history of the FAT file system
• Basic concepts of the FAT file system
• How to manually recover data from a FAT file system

III. H istorical O verview o f the FAT File System s

The File Allocation Table (FAT) file system got its start in 1977 but became most known with MS-DOS 1.0
in the early 1980’s. FAT was originally developed as a simple file system for floppy disk support, but over
time it has grown to support larger media, it is important to know all the FAT file systems were developed
for IBM or PC architecture, meaning the data is read by the processor in little endian. Currently there are
four common FAT file system sub-types: FAT12, FAT16, FAT32 and exFAT.

FAT12

FAT12 was the first FAT file system introduced in 1977, and used 12 bits to address the total number of
Clusters. The use of 12 bits to address the total number of Clusters meant the file system had several
limitations: for example, using only 12 bits to address the total number of Clusters on a disk limited the size
of the disk to 4,096 Clusters, minus a few reserved Clusters. FAT12 was commonly found on floppy
diskettes and some removable media but today is rarely seen on anything other than a 3.5 floppy diskette.

FAT16

FAT16 was introduced in 1984 and used 16 bits (2 bytes) to address the total number of Clusters allowing
for 2GB volume sizes. During the 1990s hard disk drives increased dramatically in size and the 2GB
limitations of the FAT16 file system quickly became an issue. The larger Cluster sizes needed to address
these newer drives led to a large amount of wasted space on the hard disk drive. For example, with a
Cluster size of 32KB, a typical link or shortcut file (size = about 1KB) would have 31KB of wasted space.
If there were 400 link files that would amount to 12.4 MB of wasted space just in link files.

Up until this point, file naming was limited to the 8.3 file naming system now known widely as a DOS short
file name. This will be discussed in greater detail later in this lesson.
 VFAT

With the initial release of Windows 95A, Microsoft introduced a new enhancement to FAT known as the
Virtual File Allocation Table (VFAT). VFAT is an extension of the FAT16 file system that maintains
backward compatibility with previous versions while providing several enhancements such as support for
long file names and additional file date/time tracking. In short, VFAT allowed a user to place up to 255
characters into a file name, including upper and lower case letters. This is known as the Long File Name
(LFN) and will be discussed in more detail later in this block.

FAT32

Microsoft created FAT32 to overcome the FAT 16 size limitations and wasted space issues. FAT32 allowed
single partitions to be written to very large hard disk drives. It also allowed for smaller Cluster sizes, which
reduced wasted space. Unlike the two previous versions of FAT12 and FAT16, FAT32 uses 28 bits for
Cluster addressing in the File Allocation Table. This increased the addressable volume size to 2.2
Terabytes however, Microsoft implemented size restrictions through their operating systems, limiting the
maximum volume size to 32GB and maximum file size to 4GB. FAT32 is commonly seen on removable
storage devices.

Version Bits / FAT Entry Maximum Clusters Usage

FAT12 12 2 " = 4,096 Floppy Disks, Media up to 32 Mb

FAT 16 16 210 = 65,536 Volumes smaller than ~4 Gb

FAT32 32 2za = 268,435,456 Volume Greater than ~4 Gb

(4 bits reserved)
Figure 1: FAT Versions

exFAT

Extensible File Allocation Table will be discussed in a separate module.

IV. C om ponents o f the FAT File System

The FAT file systems contain the same four basic regions:
1. Reserved Region (Contains the Boot Record)
2. FAT Region (Contains FAT 1 and FAT 2)
3. Root Directory Region (Eliminated as a separate region in FAT32 and became part of the data region)
4. File and Directory Data Region

The 4 regions of this file system are divided into two groups called, system area and a data area. The
regions contained within the two groups will vary based on the version of the FAT file system. Generally
speaking, the System Area allows the operating system to find files and directories stored in the Data Area.
The regions in the System Area are a fixed size based on the version of FAT.

In FAT12/FAT16 versions, the regions are combined into the two areas as seen in Figure 2:
BOOT ROOT
iZ PAT 2!!! FAT FILES & SUBDIRECTORIES
RECORD DIRECTORY

V
SYSTEM AREA DATA AREA
F ig u re 2: F A T 12 /F A T 16 com ponents

In the FAT32 these components are broken down into the two areas as follows in Figure 3:
BOOT ROOT
RECORD
3 ^ fat 21?. FAT FILES & SUBDIRECTORIES
DIRECTORY

SYSTEM AREA DATA AREA

F ig u re 3: F A T 3 2 com ponents

Although there are other differences between the various flavors of the FAT file system, the relocation of
the Root Directory to the Data Area in FAT32 allows for the Root Directory to expand beyond the size
allowable within the System Area. This also means that the Root Directory can become fragmented since
it can now occupy more than one Cluster on the media.
V. Volum e Boot Record

There are two types of Boot Records for a partitioned and formatted drive:

1. The Master Boot Record (MBR) as discussed in the Disk Structures section. Located in Physical
Sector 0 (PS 0) of the physical disk and contains the Master Boot Code and Master Partition Table.

2. The Volume Boot Record (VBR) is always located in Logical Sector 0 (LS 0) of the logical volume. The
VBR is created during the high level formatting process of the volume, and contains information about
the volume. The VBR of a primary partition will contain boot code needed to continue the boot process
if that partition is set as the active primary.

It is important to note: removable media does not always have an MBR, in fact, smaller media commonly
have only a VBR. In these cases, Physical Sector 0 of the physical disk is the same as the Logical Sector
0 of the logical volume. (Physical related to the disk, Logical relates to the Volume)

Microsoft refers to the VBR for volumes formatted with a FAT file system as a Boot Sector with a BPB
(BIOS Parameter Block). According to Microsoft, ever since MSDOS 2.x, all FAT volumes must have a
BPB. The BPB contains data fields that allow the file system drivers to understand and support the volume
correctly. Note in Figures 4 and 5 below the BPB data fields are consistent for each FAT version.

As the different FAT versions were developed progressively allowing for larger disk sizes, the BPB fields
also changed to allow for more sectors but in a way that allowed for backwards compatibility. For example,
in Figures 4 and 5 there are two Total Sectors data fields in the BPB located offset 0x13 and 0x20. Offset
0x13 is the MSDOS 2.x legacy version with a 16-bit count for the total sectors on the disk, including the
system area. This allowed for a maximum sector count of 65,535.

The data field at offset 0x20 was introduced in MSDOS 3.x with Window 95 service release 2 with the
introduction of FAT32. This field uses a 28-bit count for the total sectors. Note in Figures 4 and 5 the value
at offset 0x13 is zero because the volumes are larger than 32MB and the total sectors is addressed for this
volume at offset 0x20. The reverse would be true if the volume size was less than 32MB. For more
information regarding the BPB and compatibility issues, refer to the resources listed at the end of this
lesson.

The last two bytes of each boot sector contain the values 0x55 OxAA. These bytes are located at sector
offsets 0x1 FE (510) and 0x1 FF (511) and are signature bytes that indicate the sector is a boot sector. This
signature can be found in sectors reserved for boot sectors or back up boot sectors and partition tables.
^ 'B o o t Sector FAT. Base Offset: 0 ? ? B o o t S e c t o r F À T 3 7 . B a s e O f fs e t :

Offset Title Value Offset Title Value

0 JMP instruction EB3C90 0 JMP instruction E8 5890
3 OEM MSDOS5.0 3 OEM MSDOS5.0

BIOS Parameter Block I BIOS Parameter Block

B Bytes per sector 512 B Bytes per sector 512
D Sectors per duster 4 D Sectors per cluster 2
E Reserved sectors 4 E Reserved sectors 6254

10 Number ot FATs 2 10 Number of FATs 2

11 Root entries 512 11 Root entries (unused) 0

Sectors (under 32 MB) 0 13 Sectors (on small volumes) 0

13
15 Media descriptor (hex) F8
15 Media descriptor (hex) F8
16 Sectors per FAT (small vol) 0
16 Sedors pet FAT 250
18 Sectors per track 63
18 Sedors pet track 63
1A Heads 255
1A Heads 255
1C Hidden sectors 0
1C Hidden sectors 0
20 Sectors (on large volumes) 256000
20 Sedors (ovet 32 MB) 256000

I FAT32 Section
24 BIOS drive (hex, HD*8x) 80
24 Sectors per FAT 969
25 (Unused) 0
28 Extended flags 0
26 Ext. bod signature (29h) 29
28 FAT mirroring disabled? 0
27 Volume serial number (decimal) 1914074921 2A Version (usually 0) 0
27 Volume serial numbet (hex) 29 77 16 72 2C Root dir 1st cluster 2
2B Volume label NO NAME 30 FSInfo sector 1
36 Fie system FAT16 32 Backup boot sector 6
1FE Signature (55 AA) 55 AA 34 (Reserved) 00 00 00 00 00 00 00 00 00

40 BIOS drive (hex, HD=8x) 80

41 (Unused) 0
42 Ext boot signature (29h) 29
Figure 4: FAT 16 Boot Record Template 43 Volume serial number (decimal) 237368731
43 Volume serial number (hex) D7 F5 25 0E
47 Volume label NO NAME
52 File system FAT32

1FE Signature (55 AA) 55 AA

Figure 5: FAT32 Boot Record Template

 Figures 6, 7, and 8 list the byte by byte locations of the Volume boot sectors for each FAT file system.
Figure 6 lists the first 36 bytes of the Volume boot sector, which are values consistent in each Volume boot
sector for FAT 12, FAT 16 and FAT32 and include the Bios Parameter Block (BPB).

Offset Size Name Description

(Hex) (bytes)
0x00 3 JMP Instructions The jump instruction continued from the MBR.
0x03 8 OEM ID String of characters that can indicate the OS used during format.
MSWIN4.0 = Windows 95 pre-OSR2.
MSWIN4.1 = Windows 95 OSR2 through Windows 98
MSDOS5.0 = indicates Windows 2000 and newer.
0x0 B 2 Bytes Per Sector Start of the BPB, can contain values of 512, 1024, 2048, and 4096.

OxOD 1 Sectors Per Represents the number of sectors assigned to a single allocation
Cluster unit. Must be a power of 2. *
OxOE 2 Number of FAT12, FAT16 should be a value of 1 and FAT32 a value of 32,
Reserved however MS indicates larger values are supported. *
Sectors
0x10 1 Number of FAT's Should always be a value of 2. *
0x11 2 Root Entries Number of 32-byte directory entries in the Root directory region.
For FAT32 this value is 0 as the Root is contained in the data area.
*
0x13 2 Total Sectors Count of all sectors on the volume including system areas. For
volumes where the total sector count can be represented using no
more than 16 bits. *
0x15 1 Media Descriptor Legal values for this field are OxFO, 0xF8, 0xF9, OxFA, OxFB, OxFC,
OxFD, OxFE and OxFF. The two most common values are 0xF8 for
fixed media and OxFO for removable media. *
0x16 2 Sectors Per FAT Count of sectors occupied by one FAT for FAT12 and FAT16
(16) volumes. On a FAT32 volume this value is zero, and the value is
represented at offset 0x24. *
0x18 2 Sectors Per This field is only relevant for media that have disk geometry with
Track CHS (Cylinder, Head, Sector). *
0x1 A 2 Number of Only relevant for disks with CHS geometry. *
Heads
0x1 C 4 Hidden Sectors Count of hidden sectors preceding the partition containing the FAT
volume. Part of BPB
0x20 4 Total Sectors Count of total sectors for the volume, including system areas. For
volumes where the total sector count exceeds the value that can
be stored in 16 bits. *
F ig u re 6: F irst 36 com m on bytes o f Boot R e co rd - * Indicates value is part o f B P B
Offset Size Name Description
(Hex) (bytes)
0x24 1 Bios Drive Number Supports MS-DOS bootstrap and is set to the interrupt 13 drive
number of the media. 0x00 for floppy disks, 0x80 for hard disks.
This field is operating system specific.
0x25 1 Reserved Reserved byte should always be set to zero for FAT volumes.
0x26 1 Ext. Boot Extended boot signature indicates the following three fields are
Signature present. Value 0x29
0x27 4 Volume Serial A 32-bit value usually generated from the date and time. Used for
Number tracking removable media. This value can often be found in Link
files in Windows artifacts. Forensic software can display this value
in both hex and decimal.
0x2 B 11 Volume Label Represents the 11-byte volume label recorded in the Root
Directory. If no volume label is provided, then "NO NAME" is the
default value. Examiners should be aware of how different
operating systems populate this field, during format or volume
name modification.
0x36 8 File System Type Although this field generally represents the file system formatted
on the volume, it is an informational field only and is not used by
FAT drivers to determine the FAT system type. Note this field is
not part of the BPB.
F ig u re 7: Rem aining bytes in the boot sectors f o r F A T 12/16 starting at offset 0x24.
Offset Size Name Description
(hex) (bytes)
0x24 4 Sectors Per FAT Number of sectors occupied by one FAT for FAT32 volumes. For
(32) FAT12 and FAT16 volumes this value is zero, and the value is
represented at offset 0x16. *
0x28 2 Extended Flags Bits 0-3 Zero based number of active FAT. Only valid if mirroring
is disabled. Bits 4-6 are reserved. Bit 7, a value of 0 means the
FAT is mirrored. A value of 1 means only one FAT is active and is
referenced in the first 3 bytes. Bits 8-15 are reserved.
0x2A 2 FAT Version The high byte is the major revision number and the low bit is the
minor revision number. Supports future extensions of FAT32
while allowing backwards compatibility. *

0x2C 4 Root Directory Points to the starting Cluster for the Root Directory. This is usually
Cluster Cluster 2 but is not required to be Cluster 2. *
0x30 2 FS Info Sector The sector number of FSINFO structure in the reserved area of
the FAT32 volume. Usually set to 1. *
0x32 2 Back up Boot If not 0, the value represents the sector number of the copy of the
Sector boot sector in the reserved area. Generally set to 6. *
0x34 12 Reserved Reserved for future expansion. Value should always be zero.

0x40 1 Bios Drive Number Supports MS-DOS bootstrap and is set to the interrupt 13 drive
number of the media. 0x00 for floppy disks, 0x80 for hard disks.
This field is operating system specific.
0x41 1 Reserved Reserved byte should always be set to zero for FAT volumes.

0x42 1 Ext. Boot Extended boot signature indicates the following three fields are
Signature present. Value 0x29
0x43 4 Volume Serial A 32 bit value usually generated from the date and time. Used for
Number tracking removable media. This value can often be found in Link
files in Windows artifacts. Forensic software, can display this
value in both hex and decimal.
0x47 11 Volume Label If no volume label is provided then "NO NAME" is the default
value. Examiners should be aware of how different operating
systems populate this field, during format or volume name
modification.
0x52 8 File System Type Although this field generally represents the file system formatted
on the volume, it is an informational field only and is not used by
FAT drivers to determine the FAT system type.
F ig u re 8: Rem aining bytes in a F A T 3 2 volum e starting at offset 0x24
 All directories are organized in exactly the same way: as a series of 32-byte records or entries that have a
very specific format. The operating system reads down this list of entries until it reaches an entry that
starts with the hex value 0x00 and then stops. Note: As a result, it is possible to store and hide data in a
directory area if the first byte is the hex value 0x00. The operating system simply ignores that portion of
the directory. See Figure 9.

Offset 0 1 2 3 4 5 6 7 8 9 À B C D E F \
H j -1
0003F000 E9 41 43 49 53 20 20 20 20 20 20 08 00 00 00 00 IÀCIS
0003F010 00 00 00 00 00 00 6À 5E 6F 3D 00 00 00 00 00 00 .......... i > = _
/*
0003F020 49 41 43 49 53 20 20 20 4À 50 47 20 10 40 Al 5E IÀCIS JPG .er Directory Entry 1
0003F030 A 6F 3D 6F 3D 00 00 C7 58 4F 3C 02 00 6C C2 00 00 o=o=. ,ÇXO<.. iâ ..
0003F040 E5 4E 00 65 00 77 00 20 00 46 00 0F 00 DD 6F 00 âN.e .v . .F .. ,Ÿo. Directory Entry 2
0003F050 6C 00 64 00 65 00 72 00 00 00 00 00 FF FF FF FF 1 . d . e . r . . . . ¿y^y 2 _
0003F060 iE5 45 57 46 4F 4C 7E 31 20 20 20 10 00 76 71 25 âEWFOL~l . vq y. Directory Fntry 3
0003F070 V.25 3E 25 3E 00 00 72 25 25 3E IB 00 00 00 00 00 x>y.> rxy.>..........
0003F080 42 72 00 79 00 00 00 FF FF FF FF 0F 00 6F FF FF B r .y . . . ÿÿÿÿ ■ oÿÿ
0003F090 FF FF FF FF FF FF FF FF FF FF 00 00 FF FF FF FF yyyyyyyyyy• •yyyy
0003F0À0 ¡01 44 00 69 00 72 00 65 00 63 00 OF 00 6F 74 00 .D . i . r . e . c . . .Ot .
Directory Entry 5
0003F0B0 «6F 00 72 00 79 00 20 00 65 00 00 00 6E 00 74 00 o.r.y. e . . n. t .
Û003F0C0 44 49 52 45 43 54 7E 31 20 20 20 10 00 76 71 25 DIRECT! . .vq/C
OOD3FODO 25 3E 25 3E 00 00 72 25 25 3E IB 00 00 00 00 00 . r*y.>. Directory Entry 6
0003F0E0 41 54 00 65 00 73 00 74 00 31 00 OF 00 2E 00 00 A T .e . s . t ! .
0003F0F0 J .FF FF_FF FF_FF IL FF FF FF FF 00 00 ü FF I I FF ÿVYVyVYVyy. .yvvv Directory Entry 7
0003F100 00 45 53 54 31 20 20 To 20 20 20 10 00 AA 7D 28 |.EST1 | ■ .*>(
0003F110 25 3E 25 3E 00 00 80 28 25 3E 1C 00 00 00 00 00 *>;<>. i (y>.
0003F120 41 48 00 &%lothina below the 0x00 byte&5 00 OF 00 45 6E 00 A H . i . d . d . e . ..En.
0003F130 00 00 FF FF wB be seen by the OS FF 00 00 FF FF FF FF • • yyyyyyyy• yyyy
0003F140 48 49 44 44 45 4E 20 20 20 20 20 10 00 9F 86 28 HIDDEN ii(
0003F150 25 3E 25 3E 00 00 87 28 25 3E 1D 00 00 00 00 00 y.>y.>,. i (y.>.

F igu re 9: H idden D irecto ry

The Root Directory depicted in Figure 9 shows several directory entries that include a picture file and
several subdirectories, including long file names. Note the 0x00 byte at offset 0x3F100 marked in red.
Because this byte is 0x00 the file system thinks this is the end of the directory entries and ignores the
remaining entries. Every entry below this byte will not be read by the file system when viewing the contents
of the disk.

There are two data structures used by a 32-byte directory entry. The Short File Name (SFN) and Long
File Name (LFN) directory entries.
 The SFN structure is used for short file names that have no more than 8 ASCII characters for the name
and three for the file extension. It Is also used for the volume label, which can be no more than 11 ASCII
characters in length. Figures 10 and 11 shows the first two directory entries of the Root Directory on a
FAT32 volume. Note the first entry is a volume label (TEST) and the second is the directory entry for a file
named IACIS.JPG.

0 1 2 3 4 5 6 7 8 9 À B c D E F 1 -9J "•* I“
54 45 53 54 20 20 20 20 20 20 20 08 00 00 00 00 TEST
00 00 00 00 00 00 À5 89 D4 3C 00 00 00 00 00 00 ............ ¥ | 0 < .
*4 9 41 43 49 53 20 20 20 4Ä 50 47 20 10 3C 39 8À IA C IS JPG . <91
D4 3C 6F 3D 00 00 C7 58 4F 3C 02 00 6C C2 00 00 ô < o = . . ÇXO<. 1 Â . .
F ig u re 10: D irecto ry Entry show in g volum e la b el and highlighted entry f o r f ile nam ed I A C I S .J P G

S3 48 4F 52 54 20 20 20 54 58 54 20 10 82 2B 57 SHORT TXT I+W

54 44 55 44 00 00 20 59 55 44 02 00 55 00 00 00 TDUD YUD U
00 00 00 00 0 0 00 0 0 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 0 0 00 00 00 00 00 00

F ig u re 11: D irecto ry Entry f o r a f ile nam ed S H O R T . T X T

Figure 12 provides the data structure for a directory entry on a FAT32 system.

Offset (Hex) Size (Bytes) Description

0x00 8 Filename (padded with spaces if required)
0x08 3 File Extension (padded with spaces if required)
OxOB 1 File Attribute Byte
OxOC 1 Reserved for use by Windows NT
Millisecond stamp at file creation time. Value range 0-199 records tenths
0x0 D 1 of a second to supplement the file creation time stamp that has a
granularity of 2 seconds. (*May not used in FAT 12/Fat16)
OxOE 2 File creation time
0x10 2 File creation date
0x12 2 Last accessed date
0x14 2 High word of the entries starting Cluster. Always 0x00 for FAT12/16
0x16 2 Time of Last Write to File (last modified or when created)
0x18 2 Date of Last Write to File (last modified or when created)
0x1 A 2 Low word of the entries starting Cluster
0x1 C 4 File Size (set to zero if a directory)
Figu re 12: Byte structure f o r F A T32 32-byte d irectory entry

Note that offset OxOC through 0x14 were originally reserved in FAT12 and FAT16 and so these dates and
times were not recorded. Testing has shown more recent operating systems will record these dates and
times.
VFAT was an enhancement of the FAT file system that maintained backward compatibility with earlier
versions and is used in the FAT32 based file system. Among the enhancements were the ability to maintain
the date and time a file was created, the date a file was last accessed, larger starting Cluster numbers,
and support for long file names. In order to provide these enhancements, Microsoft utilized the unused
bytes (offset 0x0C-0x14) of the 32-byte directory entry along with some other changes. While unused in
previous FAT file systems, Microsoft has reserved offset OxOC for use by Windows NT (filenames in NT
may be upper OR lower case and this byte is used to keep track of the file's case). Offset 0x0E-0x11 now
holds the file’s creation date and time. Offset 0x12-0x13 contain the file’s last access date.

For FAT32 volumes, offsets 0x14-0x15 contain the second bytes of the starting Cluster number (only 12
of the 16 bits are actually used). The number of Clusters possible on a FAT32 volume (228) exceeds the
number that can be held in offsets 0x1A-0x1B (216). Thus, the field was added to allow for the expanded
number of possible Clusters. For FAT12 and FAT16 volumes, offsets 0x14-0x15 should always be 0x00
0x00. In FAT32 the two bytes at offsets 0x14 and 0x15 are known as the High Word. The two bytes at
0x1 A and 0x1 B are known as the Low Word. By combining the two Words FAT32 can address many more
Clusters.

Offsets 0x16-0x18 still hold the date and time the file was last written. Offsets 0x1A-0x1B still hold the
file’s starting Cluster number. However, for FAT32 volumes this value contains only the first 2 bytes of the
value the remaining 2 bytes are contained in offsets 0x14-0x15 as explained above. Finally, offsets 0x1C-
0x1 F contain the logical size of the file.

Directory Entry Status Byte

The first byte of a VFAT/FAT32 directory entry is called the “status byte". Depending on the value of this
byte, the directory entry will be read differently by the operating system.

• If the first byte is a legal character for a filename, then the directory will be read as a normal directory
entry and the status byte will be read as the first character of the filename.

• If the first byte is 0xE5 (indicates a deleted directory entry), then the directory entry will be ignored
by the operating system.

• If the first byte is 0x00 (indicates an empty directory entry), then the directory entry (and all
subsequent directory entries) will be ignored by the operating system. See Figure 9 above.

• The first byte may also be read as the sequence byte, which indicates a Long File Name (LFN).

DOS File Name & DOS File Extension

A valid DOS File Name, also known as the Short File Name, must conform to specific rules. These rules
are:

1. One to eight characters are allowed for the filename. Names with less than eight (8) characters always
start at offset 0x00 and are padded with a space (0x20).
 2. Zero to three characters are allocated for the file extension. As with the DOS File Name, File
Extensions with less than three (3) characters always begins at the left (offset 0x08) and are padded
with a space (0x20).

3. Spaces are not allowed, and the following DOS reserved characters are forbidden: “+ * , . / : ; < = >?
m i

The filename is always stored in uppercase. The periods that are typed to separate the filename from the
extension are not actually stored in the directory entry as show in Figure 13. Also notice the last three (3)
unused bytes of the short file name are padded with 0x20.
□
0 1 2 3 4 5 6 7 8 9 À B c D E F s \£i - |
49 41 43 49 53 20 20 20 20 20 20 08 00 00 00 00 IA CIS
00 00 00 00 00 00 A9 61 6F 3D 00 00 00 00 00 00 © a o = ................... 1— 1
49 41 43 49 53 20 20 20 <£k 50 47>20 10 14 B6 61 IA CIS ( J P G ) . . Ha
6F 3D ^ F 3D 00 00 C 7 58 4F 3C o i v 00 6C Ç2- -Ç ÎO < . . 1Â . .

0
h
0
S
00 00 O ix 00 00 00 00 00 00 00 qipW ucf 00 00 00

Short File Name Extension'

F ig u re 13: D O S F ile Nam e and F ile Extension

Attribute Byte

The attribute byte at OxOB is a ‘packed byte' and consists of eight (8) 1-bit flags that the operating system
uses to control and determine certain aspects of the file. Each flag is represented by a specific bit and is
activated or deactivated by setting its value to 1 or 0 respectively. See Figure 15 for the individual flags.

0 1 2 3 4 5 6 7 8 9 A B C D E F rsr
4E 41 43 49 53 20 20 20 20 20 20 08 00 00 00 00 IÀ CIS ................
00 00 00 00 00 00 À9 61 6F 3D 00 00 00 00 00 00 ................... © a o = ..................... D
49 41 43 49 5 3 2 0 20 20 4À 50 47 ( 2 0 ) 1 0 14 B 6 61 IÀ CIS JP G ..H a
6F 3D 6 F 3D 0 0 00 C7 58 4F 3C 0y M 6 C C 2 00 00 o=o=.. ÇXO<. . 1 Â ..
00 00 00 00 00 00 00 00 00 0^x6o 00 00 00 00 00
Attribute byte
F ig u re 14: Attribute Byte

Binary Hex Description

0000 0001 0x01 Read Only
0000 0010 0x02 Hidden
0000 0100 0x04 System
00001000 0x08 Volume Label
0001 0000 0x10 Directory
0010 0000 0x20 Archive ON
0100 0000 0x40 Reserved (used for VFAT)
1000 0000 0x80 Reserved (used for VFAT)
F ig u re 15: Attribute Byte In divid u a l F la g s

Figure 14 value is OxOF = 0000 0110 =, Hidden and System flags are on.
FAT dates and times are recorded in two (2) packed byte groups and have to be broken down from
hexadecimal to binary in order to interpret the data. The examples below cover how to calculate the file
creation time in the FAT directory entry.

The file creation time is stored at offset OxOE and OxOF of the Directory Entry.
0 1 2 3 4 5 6 7 8 9 À B C D E F ^ I
4Ë 41 43 49 53 20 20 20 20 20 20 08 00 00 00 00 IACIS ....
00 00 00 00 00 00 À9 61 6F 3D 00 00 00 00 00 00 ...................© a o = ..................... G
49 41 43 49 53 20 20 20 4A 50 47 20 10 14 B6 61 IA CIS JP G ..H a
6F 3D 6F 3D 00 00 C7 58 4F 3C 03 00 6C C2/00 00 o=o=. . ÇXO<. . 1Â..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
File Creation Time
F ig u re 16: F ile Crea tion Time

Reverse the byte order to Read Little Endian (this needs to be done for every Integer in FAT).

F ig u re 1 7: R everse Byte O rd er

Split nibbles and convert Binary.

Hex 6 1 B 6
Binary
8 4 2 1 8 4 2 1 8 4 2 1 8 4 2 1
Markers
Binary 0 1 1 0 0 0 0 1 1 0 1 1 0 1 1 0
F ig u re 18: B inary C on version

Split Binary String into Hours (5-bit), Minutes (6-bit), Seconds (5-bit).

The decimal value for the last seconds is multiplied by 2 as it only increments every two seconds - there
were not enough bits for 60 seconds! This is the reason DOS times have even numbered seconds.

Binary
16 8 4 2 1 32 16 8 4 2 1 16 8 4 2 1
Markers
Binary 0 1 1 0 0 0 0 1 1 0 1 1 0 1 1 0
Decimal 8+4 8+4 +1 (16+4+2 )*2 j
H:m:s 12 Hours 13 Minutes 44 Seconds
F ig u re 19: Time C alcu la tion
 The file creation date is stored in the two bytes of the Directory Entry immediately following the file creation
time.

0 1 2 3 4 5 6 7 8 9 À B C D E F
4E 41 43 49 53 20 20 20 20 20 20 08 00 00 00 00 IÀCIS ....
00 00 00 00 00 00 À9 61 6F 3D 00 00 00 00 00 00 ..... © a o = ......
49 41 43 49 53 20 20 20 4A 50 47 20 10 14 B6 61 IA C IS JP G ..Ha
6F 3D 00 00 C7 58 4F 3C 03 00 6C C2 00 00 o = o = ..Ç X O < . .1Â . .
00 00 CJTKQO 00 00 00 00 00 00 00 00 00 00 00
00
File Creation Date
F ig u re 20: F ile Crea tion D ate

Reverse Byte Order to Read Little Endian, then split into Nibbles and convert to Binary

Hex 3 D 6 F
Binary
8 4 2 1 8 4 2 1 8 4 2 1 8 4 2 1
Markers
Binary 0 0 1 1 1 1 0 1 0 1 1 0 1 1 1 1
F ig u re 21: B inary C on version

Split the Binary String into Year (7-bit), Month (4-bit), Day Sections (5-bit).

The decimal year value is the amount of years from 1980.

Binary 64 32 16 8 4 2 1 8 4 2 1 16 8 4 2 1
M arkers
Binary 0 0 1 1 1 1 0 1 o 1 1 0 1 1 1 1
Decim al (16 + 8 + 4\ + 2) + 1980 8+2 + 1 8 +4 + 2 + 1
Y/m/d 2010 11 15
Figure 22: Dale C alculation

The result can be compared to the values in the Created date/time column within the directory browser
view of forensic software as shown in Figure 23:
D_________________________________________________________________________________
Name - I Bd| Size [ Created | Modified I Accessed | rttr. | 1st s e c to r!"
(Root directory) 1.0 KB 8132
Q lads jpg jpg 48.6 KB 11/15/2010 12:13:44jQ2/15/2010 11:06:1411/15/2010 A 8194
Ml- — —

F ig u re 23: Date/time show n in D irecto ry B row ser View

 Starting Cluster

The Starting Cluster is an unsigned integer representing the Logical Cluster Number that the file starts in.

Example One

Offsets 0x1 A and 0x1 B, following the Last Written date and time byte groups, is the starting Cluster byte
group.
0 1 2 3 4 5 6 7 8 9 À B c D E F / 1 41 - A

4Ë 41 43 49 53 20 20 20 20 20 20 08 00 00 00 00 IACIS
00 00 00 00 00 00 À9 61 6F 3D 00 00 00 00 00 00 ..... © a o = . . L
49 41 43 49 53 20 20 20 4À 50 47 20 10 14 B6 61 IACIS JPG .fa

D
GJ
C
O
C
6F 3D 6F 3D 00 00 C7 58 4F 3C 6C C2 00 00 o = o = ..Ç X 0 < ..l A ..

D
D

D
C

C
00 00 00 00 00 00 00 00 00 00 00 00 00
O

O
Starting Cluster
F ig u re 24: Starting C lu ster

Read little endian, the value is 0x00 0x03, which in decimal gives us a starting Cluster of 3.

Example Two

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 49 41 43 49 53 20 20 20 20 20 20 08 00 00 00 00 IACIS
00000010 00 00 00 00 00 00 À9 61 6F 3D 00 00 00 00 00 00 ©ao=
00000020 49 41 43 49 53 20 20 20 4A 50 47 20 10 14 B6 61 IACIS JPG fa
00000030 6F 3D 6F 3D 00 00 C7 58 4F 3C *3A 2B 6C C2 00 00 0 =0 = ÇX0<:+1Â
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
F ig u re 25: Starting C lu ster

Reverse Byte Order to Read Little Endian, and split into nibbles and convert to Binary

Decimal 2 B 3 A
Binary 8 4 2 1 8 4 2 1 8 4 2 1 8 4 2 1
Markers

Binary String 0 0 1 0 1 0 1 1 0 0 1 1 1 0 1 0
F ig u re 26: B inary C on version
 Add the Decimal Values in the Resulting Binary String

Binary 32768 16384 8192 4096 2048 1024 512 256 128 64 32 16 8 4 2 1
Markers
Binary 0 0 1 0 1 0 1 1 0 0 1 1 1 0 1 0
Decimal 8192 + 2048 + 512 + 256 + 32 + 16 + 8 +2
Starting 11066
Cluster
F ig u re 27: D ecim a l C on version

The starting Cluster number can also be found using a calculator. The Programmer view in Windows
calculator allows conversion between hexadecimal, decimal and binary. Inputting 0x2B 0x3A with the
option ‘Hex’ selected gives us the decimal value 11066 for the starting Cluster.

Calculator — □ X

= PROGRAMMER

2B3A
HEX 2B3A
DEC 11.066
OCT 25 472

BIN 0010 1011 0011 1010

•0
°o* QW ORD MS M'

Lsh Rsh Or Xor Not And

1 M od CE c «3

A B 7 8 9 X

C D 4 5 6 -

E F 1 2 3 +

( ) ± 0 =

F ig u re 28: M S C a lcu la to r (Program m er View)

Example Three

FAT32 can use both a high word and a low word value to store the starting Cluster information.
 Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 49 41 43 49 53 20 20 20 20 20 20 08 00 00 00 00 IACIS
00000010 00 00 00 00 00 00 A9 61 6F 3D 00 00 00 00 00 00 ©ao*
00000020 49 41 43 49 2SL 20 20 4Â 50 _iZ_^ 0 10 14 B6 61 IACIS JPG fa
00000030 6F 3D 6F 3D h i 00 |C7 58 4F 3C 02 0016C C2 00 00 ÇXO< 1Â

0
M
O
■
00000040 00 00 00 00/00 00 00 00 00 00 00 oa oo 00 00 00
y
High Word Low Word
Figure 29: FAT32 Start Cluster Values

In the event the high word value was populated as shown in Figure 29, the way to calculate the starting
Cluster would be as follows:

Use the same process as described in example 2 to get the decimal value for the low word, as shown in
Figure 30.

Hex 0 0 0 2
Binary 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0
Binary
32768 16384 8192 4096 2048 1024 512 256 128 64 32 16 8 4 2 1
Markers
Decimal
2
Value
Figure 30: Low Word Conversion

Convert the High Word Binary String to a Decimal Value. The Binary Markers for the High Word Binary
String Continue Upwards from the last Low Word Binary Marker. The High Word uses the binary values
that continue from the Low Word value - the Low Word uses binary values 0 - 32,768 and the High Word
uses binary values 65,536 - 2,147,483,648

Hex 0 0 0 1
Bin 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1
2147483648

1073741824

268435456
536870912

134217728

67108864

16777216

00
33554432

4194304

1048576
2097152

524288

o
131072
262144

65536
Binary CD
00
Markers 00
CO
00

Decimal
65536
Value

Figure 31: High Word Conversion

Add the High Word Decimal Value to the Low Word Decimal Value to get the Starting Cluster:

65536 + 2 = 65538.
The starting Cluster for the file is 65538.
 File Size
The last four bytes of the directory entry show the size of the file in bytes. Figure 32 highlights the four file
size bytes.

0 1 2 3 4 5 6 7 8 9 A B C D E F ' I ai -
4E 41 43 49 53 20 20 20 20 20 20 08 00 00 00 00 IÀCIS ....
00 00 00 00 00 00 À9 61 6F 3D 00 00 00 00 00 00 ..... © a o = ...... c
49 41 43 49 53 20 20 20 4A 50 47 20 10 14 B6 61 IACIS JPG ..Ha
6F 3D 6F 3D 00 00 C7 58 4F 3C 03 00 |6C C2 00 00 o=o=. . Ç X O < . . 1 Â . .
00 00 00 00 00 00 00 00 00 00 00 Op^OO 00 00 00
File Size
F ig u re 32: F ile Size H e x Values

Read the Value in Little Endian, then convert the binary string to decimal to get the file size:

Hex C 2 6 c
Binary
16384
32768

Markers
4096

1024
8192

2048

128
CO
256
512

CD
04
CO 00 ■'tf C\J -

Binary 1 1 0 0 0 0 1 0 0 1 1 0 1 1 0 0
File Size 32768 + 16384 + 51 2 + 6^ + 32 + 8 + 4
= 4 9 7 7 2 byte!S

F ig u re 33: F ile Size D ecim a l C onversion

Calculator — □ X

= PROGRAMMER

C26C
HEX C26C

DEC 49.772

OCT 141 154

BIN 1100 0010 0110 1100

2S QW ORD MS M"

Lsh Rsh Or X or N et And

1 Mod CE c <«i -+

A B 7 8 9 X

C D 4 5 6 -

E F 1 2 3 +

( ) ± 0 =

F ig u re 34: M S C a lcu la to r Program m er view o f F ile Size

 Practical 1
Mount FA T .V H D w ithout a s s ig n in g drive letters.

1. Open FAT folder

2. Create copy of FAT.VHD on Desktop
3. Remove write protection from FAT.VHD
4. Open Command.txt and copy command line
5. Open Command Prompt (Windows Key + R > cmd > Enter)
6. Paste command > Enter
7. Open Disk Management
8. Check that VHD has no drive letters - note Disk number assigned for FEX...
9. Bring on-line if necessary

Open FEX and add VHD

Parse directory entries of SFN files, using FAT Practical 2018.vhd, Partition 1.

File 1: File 2:

Filename Filename

File Extension File Extension

Attributes Attributes A f C- U,
Create Ms. Create Ms.
%. H
Created Created X . Z. .ze/tl
Last accessed Last accessed
^ ? £ > /3"
Modified Modified
Start Cluster Start Cluster

File Size File Size

Is there a Hidden directory entry?

VIII. File A llocation Table (x2)

The File Allocation Table (FAT) is a flat table containing information about the location and status of file
data within the partition’s Clusters. The FAT is necessary to track file data locations, so it automatically
creates a secondary copy, referred to as FAT2. Normally, any change made to the primary FAT will be
immediately recorded in the secondary FAT.
The FAT exists as a mapping table that records the locations (Clusters) of a file’s content being stored.

The FAT is responsible for tracking all of the Clusters on that volume.

FAT Entry basics

The size of each entry within the FAT is determined by the FAT version - the number after FAT is actually
the number of bits used by the File Allocation Table for each entry. FAT 16 = 16 bits for each entry, FAT32
= 32 bits for each entry. The FAT version defines how many Clusters the volume can address.

Media Descriptors
The first entry in the FAT table is the “Media Descriptor”, which can be seen in Figure 35, and gives an
indication as to the type of media the FAT Filing System is located on as well as the type of FAT being
used.
• OxFO - 3.5" single sided Floppy Disk.
• 0xF9 - 3.5” double sided Floppy Disk
• 0xF8 - Hard Disk Drive

The next bits of information (in hexadecimal view) give an indication as to the type of FAT filing System
itself (Fat12/16/32). In a FAT 12 File System, the remaining 4 bits after the media descriptor byte will be 1,
represented as OxF. In a FAT16 File System, the next eight bits following the media descriptor byte will be
1 represented as OxFF. In a FAT32 File System, the next twenty bits following the media descriptor byte
will be 1 represented as OxFFOF. After the media descriptor and FAT Type descriptor bits, the “End of
Cluster Chain” marker is stored. The Cluster mapping values start after these two entries and begin at
Cluster 2.
O
o

F8 FF FF F F i 03 04 00 05 00 06 00 07 00 08 00 o ÿ ÿ ÿ ..
09 ool OA 0 0 O B \0 0 OC 00 OD 00 OE 00 OF 00 10 00 .......
11 00 12 0 0 13 '00 14 00 15 00 16 00 17 00 18 00 .......
19 0 0 1A 00 F F F F 00 on 00 00 00 00 00 00 00 00 ....ÿÿ
00 00 0 0 00 0 0 00 00 00 00 00 00 00 00 00 00 00 .......
00 00 00 0 0 00, 00 00 00 00 00 00 00 00 00 00 .......
r-> n ,2? rk r. r> r. n r> ri rt r> r» «—>

M edia D e sc rip to r
First a d d re s s a b le clu ste r

Figure 35: File Allocation Table fo r FAT 16

FAT Tables are composed of four different types of entries:

1. Unallocated Cluster, meaning ‘available’, are represented as 0x00.

2. Allocated Cluster, represented by the Hex value of the next Cluster the file is located in.

3. Allocated Cluster - End of File, also known as EOF, normally represented as 0xF8 or OxFF, depending
on the OS writing to the FAT.
 4. Marked as bad, normally 0xF7.

Figure 36 provides a breakdown of the four different symbolic hex values seen in the FAT after being
converted in little endian.

Symbolic Dec Value Dec Value Dec Value Description

Value (FAT12) (FAT16) (FAT32)
Unallocated 0x000 0x0000 0x00000000 Indicates an unused Cluster that is available
for storage.
Next Cluster 0x002 - 0x0002 - 0x00000002 - A numerical value indicates that the Cluster
OxFEF OxFFEF OxFFFFFFEF is in use and what Cluster the next part of
the file is located at.
End of File 0xFF8 0xFFF8 0xFFFFFFF8 Indicates the last Cluster in the file or that the
OxFFFF OxFFFFFFOF file only requires one Cluster for data.
Bad Cluster 0xFF7 0xFFF7 0xFFFFFFF7 Indicates the Cluster is bad (corrupt) and will
not be used by the operating system. Each
sector is verified to ensure it’s able to hold
512 bytes of information. If the sector is
unable to hold 512 bytes of data, the sector
is marked BAD and will not be considered
available for file storage. A Cluster marked
as BAD survives a quick format. Data of
evidentiary value can be hidden in Clusters
marked BAD in the FAT; therefore all
Clusters should be examined in detail when
possible.
F ig u re 36: Sym b olic hex values f o r F A T table entries

The File Allocation Table tracks files located in the Data Area of the disk structure. Figure 37 shows a hex
view of a FAT32 File Allocation Table.

Offset 0 1 2 3 4 5 6 7 8 9 A B c D E F
00203400 F8 FF FF OF FF FF FF FF 4 F f FF FF OF T)4 00 00 00
00203410 t>5 00 00 00 t> 6 00 00 00 07 00 00 00 00 00 00

M:T
00203420 Q * Ç 0 00 00 00 00 OB 00 00. T)C 00 00 00
00203430 0D iJE 00 00 00 . ■ tfo 00 l e 00 00 00
00203440 11 00 00 00 12 00 00 00 13 00 00 00 14 00 00 00
00203450 15 00 00 00 16 00 00 00 17 00 00 00 18 00 00 00
00203460 19 00 00 00 1A 00 00 00 IB 00 00 00 1C 00 00 00
00203470 ID 00 00 00 IE 00 00 00 IF 00 00 00 20 00 00 00
00203480 21 00 00 00 22 00 00 00 23 00 00 00 24 00 00 00
00203490 25 00 00 00 26 00 00 00 27 00 00 00 28 00 00 00
002034A0 29 00 00 00 2 A 00 00 00 2B 00 00 00 2C 00 00 00
002034B0 2 D 00 00 00 2E 00 00 00 2F 00 00 00 30 00 00 00
002034C0 31 00 00 00 32 00 00 00 33 00 00 00 I t f FF FF OF
F ig u re 37: F ile A lloca tion Table f o r F A T 3 2
Media Descriptor and Cluster 2
First, note the End of File marker in relative offset 0x08 thru OxOB, highlighted in green. This represents
Cluster 2, which, for a FAT32 volume, contains the Root Directory. Compare this to the FAT16 File
Allocation Table in Figure 35.

In the FAT16 volume the first addressable Cluster is Cluster 2, while on the FAT32 volume the first
addressable Cluster is still 2; it is just used by the Root Directory and can grow as needed. In FAT12 and
FAT16, the Root Directory is located in the System Area, while in FAT32, the Root Directory is located in
Data Area and now takes the first addressable Cluster.

Cluster Chain
The first red highlight in Figure 37 shows the hex pointer representing Cluster 3, which tells the File System
to look to Cluster 4 for the next sector of data for this file. The FAT as chained above shows this is a
contiguous file that continues through Cluster 51. Notice the End of File marker circled in red
(OxFFFFFFOF) at Cluster 51. This marker tells the File System this is the last Cluster allocated to this file.
But what if the file is fragmented and not contiguous? A file becomes fragmented in several ways. When
files are deleted the FAT table is cleared telling the File System that these Clusters are now available for
use. When the next file is written, the File System may write the new file to some of the Clusters that were
recently cleared. If the file is too large for these Clusters, then it will continue writing the rest of the file in
the next available Clusters.

A file can also be fragmented by a Cluster that is marked as a bad Cluster. Generally speaking, when an
operating system scans a disk during a full format, it tests the Clusters to ensure they are readable and
not damaged. If the Cluster is determined by the operating system to be damaged it will mark the Cluster
in the FAT with the above mentioned 0xF7 marker. When a Cluster is marked bad, the File System will not
try to write data to it. However, if data resides in these Clusters it will remain there untouched unless a new
scan determines the Cluster is usable. As mentioned in Figure 45, Clusters can be marked as bad by a
user to hide data from average users. Therefore, it is important to examine all Clusters that are marked
bad.
IX. C luster Chaining

Perhaps the most important concept in FAT is how a file stored in multiple Clusters is “put together”. The
process is called Cluster chaining, where the FAT provides a road map with each Cluster entry either
pointing to the next Cluster that contains the file content or representing the end of the file. Below is the
FAT for a FAT32 volume. In our example, there is only a root directory and entries for two files, TEXT FILE
1 which occupies four Clusters and TEXT FILE 2 which occupies one Cluster.

Each entry within the FAT is the same size, as determined by the FAT version. When manually interpreting
FA T entry values, it becomes easier by changing the width of each line in Hex view to the number of bytes
in each entry.

O ffset, 00 01 02 03
000203400 *F8 FF FF OF Media Descriptor
000203404 FF FF FF FF FA T Type Descriptor
000203408 If f ff ff of Cluster 2 ,
000203412 04 00 00 00 Cluster 3
000203416 IÖ5 00 00 00 Cluster 4 ^
000203420 Ö 6 ” o ( T oT) T x T Cluster 5
000203424 [f f f f f f o f Cluster 6 ,
000203428 FF FF FF 0F Cluster 7
000203432 Î00 00 00 00 Cluster 8 f

Figure 38: File Allocation Table fo r FAT32

Figure 39 shows Clusters 0 and 1 occupied by media descriptor.

O ffset 0 1 2 3
00203400 ;F8 FF FF 0F Media - Fixed Disk ;
00203404 f F F 1TFTF t f FAT Type - 32
00203408 VF T " " E T " F F - O T . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . '
0020340C 04 00 00 00
00203410 05 00 00 00

Figure 39: Media Descriptors

 O ffse t 0 1 2 3
00203400 °F8 F F F F OF
00203404 £F F FF F F FF
002 034 08 - F F FF F F OF Cluster 2 - End of File
0020340C 04 00 00 00 pat 1C l u s t e r 2 : e n d
00203410 05 00 00 00 ( R o o t d ir e c to r y )

Figure 40: Cluster 2 Allocated, end o f File (Root Directory)

Figure 41 shows Cluster 3 pointing to Cluster 4 for the next part of the file. (FILE 1.TXT)

O ffse t 0 1 2 3
0 0203400 °F8 FF FF OF
00203404 °FF FF FF FF
00203408 FF FF OF J Cluster 3 - Allocated,
0 0 2 0 34 0 C ^ 4 00 00 00 Go to Cluster 4 for next
0 0203410 05 00 00 00 Cluster of file
00203414 06 00 00 00
002034 18 FF FF FF OF
002 0341C FF FF FF OF FAT 1 Cluster 3

Figure 41: Cluster 3 points to Cluster 4

Figure 42 shows Cluster 4 pointing to Cluster 5 for the next part of the file. (FILE 1.TXT)

O ffset 0 1 2 3
0 0203400 “F8 FF FF OF
002034 04 °FF FF FF FF
00203408 “FF FF FF OF
0 0 2 0 34 0 C t)4 00 00 00 - 1Cluster 4 - Allocated, Go
0 0203410 ‘b s 00 00 00 to Cluster 5 for next
002034 14 06 00 00 00 Cluster of file
002034 18 FF FF FF OF
002 0341C FF FF FF OF FAT 1 Cluster 4 - 5
FILE 1.TXT

Figure 42: Cluster 4 points to Cluster 5

 O ffse t 0 1 2 3
002 0 34 0 0 fc8 FF FF OF
0 0203404 £ f FF F F FF
002034 08 FF FF OF
0020340C $ 4 00 00 00 - 1 Cluster 5 - Allocated, Go
0020 34 1 0 $ 5 00 00 00 to Cluster (3for next Cluster
of file
00203414 t)6 00 00 00
00203418 FF FF FF OF
002 0341C FF FF FF OF FAT 1 Cluster 5 — 6
FILE 1.TXT

Figure 43: Cluster 5 points to Cluster 6

Figure 44 shows Cluster 6 is occupied and is the end of the file “FILE 1.TXT".

O ffse t 0 1 2 3
002 0 34 0 0 £ 8 FF FF OF
0 0203404 FF FF FF
0 0203408 °FF FF FF OF 1
0020340C *t)4 00 00 00 Cluster 6 - Allocated,
0020 34 1 0 t)5 00 00 00 End of File
0 0203414 *t) 6 00 00 00
0 0203418 °FF FF FF OF FAT 1 Cluster 6: end
0020341C FF FF FF OF FILE 1.TXT

Figure 44: Cluster 6 represents end o f file

Figure 45 shows Cluster 7 occupied by FILE 2.TXT and end of file marker.

O ffse t 0 1 2 3
0 0 2 0 34 0 0 °F8FF FF OF
002 0 34 0 4 °FF FF FF FF
0 0203408 “FF FF FF OF
0020340C “04 00 00 00 Cluster 7 - Allocated,
0 0 2 0 34 1 0 fl05 00 00 00 EndofFl|e
002 0 34 1 4 °06 00 00 00
002 0 34 1 8 °FF FF FF OF FAT 1 Cluster 7: end
0 0 2 0 3 4 1 C °FF FF FF OF FILE2.TXT

Figure 45: Cluster 7 represents end o f file (TEXT FILE2)

X. C ontiguous vs. Fragmented files

Windows uses a “First available/best fit algorithm when allocating space on a volume. The data for a file
is contiguous when the Clusters that contain the data are in sequential order (one after the other). If there
is insufficient space available to store the entire file in one contiguous block, the file becomes fragmented
when it requires more than one Cluster and they are not stored in sequential order (not all are next to each
other). For example, a contiguous file would be located in Clusters 2,3,4,5,6,7 while the same file could be
fragmented and be in Clusters 2,3,4,10,11,12. This can often occur when a file size changes.

Practical 2
Examine Cluster Chain of files

File 1: WORDS.TXT

Start Cluster: ----------------------------------------------------------------------------

2— End Cluster: ^
-----------------------J----------------------------------------------------------

File 2: FACES.TXT

Fragment 1 Start Cluster: End Cluster:

Fragment 2 Start Cluster: End Cluster:
Fragment 3 Start Cluster: End Cluster:
XI. Data Area

The data area of a hard disk drive is reserved for data storage. As stated above, unlike FAT12 and FAT16,
the data area of a FAT32 file system holds the Root Directory entries starting at Cluster 2 (within the Data
Area).

The data area consists of sectors grouped into clusters. The number of sectors per cluster is dependent
upon the size of the hard disk drive and how the operating system organized the hard disk drive during the
formatting session. The number could be as small as one sector per Cluster (as in the case of diskettes)
or up to 64 sectors per Cluster on a large hard drive. The number of sectors per Cluster can also be
determined by the user at the time of format. There are two types of objects that can be found in the data
area - files and directories.

1. Files are objects used to store data on the media. The files can contain data created by a user or can
contain programming code. The size of a file is not fixed and can change as the file changes. As
such, it may occupy more than one cluster on a drive. If it uses multiple clusters it is possible that
those clusters will be next to one another (contiguous), it is also possible they may be spread out over
many clusters and these may not all be next to one another (non-contiguous).

2. Directories provide a simple but powerful way of organizing and retrieving the files stored on computer
media. A directory consists of a set of 32-byte data entries that contain information about the files
stored on a FAT partition. There are two basic types of directories: the root directory and
subdirectories.

• Root Directory: There can only be one root directory on a FAT volume. The root directory location
is different in FAT12 and FAT16 than in FAT32 volumes. Flowever, all root directories function in the
same way.

• Subdirectories. Subdirectories on all FAT volumes are located in the data area and linked to the
FAT like any other file. Therefore, like the root directory on a FAT32 volume, subdirectories can grow
in size, allowing for unlimited directory entries. Subdirectories can also be fragmented like a file.

Other distinguishing characteristics of a subdirectory are its dot (.) and dot dot (..) entries. The first two
entries of a subdirectory contain special values in the name attribute. These entries are:
• 0x2E 0x20 0x20 0x20 0x20 0x20 0x20 0x20, which is referred to as the dot (.) entry
• 0x2E 0x2E 0x20 0x20 0x20 0x20 0x20 0x20, which is referred to as the dot dot (..) entry.

These entries are depicted as ‘.’and respectively by the File System when a directory listing is viewed
as text. Further, when the File System begins to read a file with the directory attribute set (except for the
root directory), it expects to find the dot and dot dot entries as the first two entries. If these values for the
subdirectories listed above are missing, the File System may not read the entries. The “dot” entry points
to itself (the Starting Cluster is the current Cluster) while the “dot dot” entry points to its parent’s starting
Cluster. Figure 46 shows a screen shot of the dot and double dot in the first two directory entries of a
subdirectory, while Figure 47 shows the parent directory's Cluster number.
□
Offset o 1 2 3 4 5 6 7 8 9 A B C D E F | £) , | A

00Û4F800 2Ë 20 20 20 20 20 20 20 20 20 20 10 00 76 71 25 [ _ J . vqZ
0004F810 25 3 E .2 5 3E 00 00 72 25 25 3E IB 00 00 00 00 fiÚ *>*>. . r X * > ..............
0004F820 2E 2E g O , 20 20 20 20 20 20 20 20 10 00 76 71 25 F7~\ . vq'/.
0004F830 25 3 E ^ 5 SE 00 00 72 25 25 3E 00 00 00 00 00 0.0' T > Z > . ..............
0004F840 00 00 00 00 00 00 00 00 00 00 00 00 0 0 .00 00 00 ................................
O0O4F85O 00 00 00 00 00 00 00 00 00 00 00 00 GO 00 00 00 ..........................................
0004F860 00 00 00 00 00 00 00 00 00 00 00 00 0 0 0 0 00 00 ................................
0004F870 00 00 00 00 00 00 00 00 00 00 00
/ 00
* 00 00 00 00 ................................
and Double Dot

Figure 46: Subdirectory (top level as only points down)

1 ." ■— ■ -
Offset 0 1 2 3 4 5 6 7 8 9 A B c D E F / j Ü1 "»

00402000 2E 20 20 20 20 20 20 20 20 20« 20 10 00 98 81 8B 1 1
00402010 3F 44 3F 44 00 00 82 8B 3F 44 04 00 00 00 00 00 ?D?D ll?D
00402020 2E 2E 20 20 20 20 20 20 20 20« 20 10 00 98 81 8B 1 1
00402030 3F 44 3F 44 00 00 82 8B 3F 44 03 00 00 00 00 00 ?D?D 11 ?D
nn^non^n A O n A nn C TT nn *7n nn 1 O nn OTT nn mr nn on nn nn TO*. ^ ~ ' n
Figure 47: dot points to Cluster 4, dot dot points to Cluster 3, parent folder.

Practical 3

Examine Sub-directory directory entries:

NZ PHOTO

File Name Attribute byte Start Cluster:

(in root)
entry
entry

BEACH

File Name Attribute byte Start Cluster:

entry
entry
XII. Form atting a FAT File System

The process that is typically used to create a file system on a piece of electronic media is called
"formatting”. There are two primary types of formatting - high level and low level. Low-level formatting
actually creates the sector layout and sequencing on the electronic media and is normally only done at the
factory. High-level formatting can be done in the Windows GUI or in the Command Line Interface (CLI)
environment. Most often in today’s world a disk or drive is formatted through the Windows GUI
environment. This segment will briefly talk about formatting in both environments.

In CLI, the command used is FORMAT.COM. This command can use switches to provide more control
over the process. There are three different switch options:
. FORMAT A: "Normal” format
• FORMAT A: /Q “Quick” format
• FORMAT A: /U “Unconditional” format

Each one of these formatting options does things just a little differently. For a “Quick” format:

1. The Boot Record will be verified and updated with at least a new OEM ID, VOLUME SERIAL NUMBER,
and VOLUME LABEL.

2. The FAT entries that contain a Cluster number or EOF marker will all be changed to a 0x00; Clusters
marked as BAD will not be changed.

3. The ROOT DIRECTORY entries will all be overwritten with 0x00. Note that if this is FAT32, then the
ROOT DIRECTORY is located in the Data Area and can span multiple Clusters. In this case, only the
first Cluster (Cluster 2) of the Root Directory is overwritten with 0x00.

For a “Normal” format, everything above occurs, with the following additions:

1. Each sector that isn’t marked as BAD in the FAT is checked for read errors.

2. Any newly discovered BAD sectors are updated in the FAT as BAD.

In an “Unconditional” format, several other things happen:

1. Every sector on the media is verified as GOOD or BAD.

2. The FAT is updated to reflect the current status of that Cluster.

3. Sectors previously marked as BAD in the FAT are rechecked and updated accordingly.

4. On removable media only, every byte in the DATA AREA is overwritten with a value such as 0xE6,
0xF6 or 0x00 since the command will perform both a read and a write test for each sector.

When formatting a drive in the Windows GUI environment there is only two options, Quick Format and
Normal. The end result will be the same as listed above without an unconditional option. It is important to
note that all entries in the ROOT DIRECTORY are lost (See note above concerning FAT32 ROOT
DIRECTORIES). This includes any sub-directories that are located in the ROOT DIRECTORY, but the
contents of those sub-directories are left intact, and can be easily recovered.
XIII. File Creation and Deletion

Three things happen when a file is created:

1. A directory entry is created containing all information relating to that file.

2. The actual data is written to the first available cluster as identified by the FAT.

3. Entries are made in the FAT to represent the allocation status of the clusters storing the file.

Only two things happen when a file is deleted:

1. first character of the directory entry is changed to 0xE5 to denote that the file is deleted.

2. The chain of clusters in the FAT is zeroed out to show that the cluster(s) are un-allocated, and therefore
available to be written to.

The actual data in the file is not overwritten or changed during a normal deletion process.

Deleted File Entries

When a file is deleted, the operating system writes the hex value 0xE5 in the first byte of the file’s directory
entry to annotate that this is a deleted file. Thus, when the file system reads down a list of directory entries,
if it encounters an entry starting with the hex value 0xE5, it ignores that entry and moves on to the next
entry. The hex value 0xE5 is represented by different ASCII characters depending upon what hex editor
program is used. The actual ASCII character for 0xE5 is the lower case sigma character.
Directory and subdirectory entries are linked to the FAT, just like all files. Therefore, during a format the
data associated with the entries stays intact. Flowever, the links to the FAT and root directory are deleted.

XIV. Recovering Deleted Files

Recovering deleted files is probably one of the more frequently used “buzz phrases” when talking about
data recovery, and one of the more essential steps in processing a case. To understand file recovery in
the FAT file system, it is necessary to understand how the files were initially stored.

The File Allocation Tables (two of them for redundancy) document linked clusters on the volume storing
file data. The FAT, in conjunction with the file’s original directory entry, allows the system to tell what file
starts where and which Clusters are holding its data.

When a file is "deleted”, the computer is about speed - so rather than empty (overwrite) all the actual data
from the clusters that are linked together (there could be hundreds or more), the computer will simply mark
it with a “0” in the FAT. This way, the system knows it can later use that specific cluster for storage again.
In addition, the directory entry’s first character is changed to the 0xE5 value. The 0xE5 tells the system to
not display this entry. It also tells the system this directory entry can be re-used.
 To "undelete” the file, “re-link” the FAT and replace the character representing 0xE5 with a valid DOS
character. Note the original character does not have to be known or used to recover the file. To accomplish
this, three pieces of information are required from the Directory Entry:
1. The first cluster of the file.
2. The size of the file being recovered. (This is listed in its directory entry).
3. The size of the clusters in the volume. (Listed in the boot record).

Something to consider: What would be an appropriate character to replace the 0xE5 in the deleted
directory entry? Rather than picking a letter that may bias recovery, use something that isn’t regularly
used in file naming. By using a dash (-) or an underscore (_), there is no biasing (or guessing) the resulting
recovered name.

XV. File Recovery w ith a Hex E ditor

The following is a step by step process for recovering a deleted file with an intact deleted directory entry
using a Hex Editor.

Figure 48 shows the deleted directory entry in the Root. The Hex Editor being used will need to be placed
in Edit mode. Edit mode allows the user to make changes within the Hex Editor. For some Hex Editors
the changes are written to disk at the time the user makes these changes, but for others the changes are
not written to the disk/file until the user selects Save. Check how to save the changes within your hex
editor.

D isk E d ito r 6.0 x64

F ile E d it N a v ig a te V ie w W in d o w H e lp

T e m p l.> U n d o Ctrl * 2
FAT32** Redo Ctrl+Y D00 V
Nam e Revert changes

B e g in n in g o f B lo c k Ctrl+1

U t* E n d o f B lo ck C trl+ 2
^ BIO
S e le c t A ll C trl+ A
B>
. Clear selection Esc

r] F " lb lo c l:
■¿C?ind._ C trl+ F

(u .2Find Next F3
J^rind Previous Shift+F3
M
Ctrl+C
(U c ° p y
5C Copy Formatted Ctrl+Shift+C
N,-' Paste Ctrl+V

* A llo w E d it C o n te n t C tri+ A lt+ E

49 41 43 49 S3 20 20 20 20 20 20 08 00 00 00 00 IACIS
4M, 00 00 00 00 00 À9 61 6F 3D 00 00 00 00 00 00 © a o = .....
E5 41 43 49 53 20 20 20 4À 50 47 20 10 14 B6 61 fÜACIS JPG ..Ha
II

Ç X O < .. l i . .
h

6F 3D 6F 3D 00 00 C7 58 4F 3C 03 00 6C C2 00 00
O
0

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Figure 48: Deleted Directory Entry, and Disk Editor Edit Mode

Once in edit mode, Change the 0xE5 it to and 0x5F (_). When completed, it should look like Figure 49.
 00 00 00 00 00 00 ¿9 61 6F 3D 00 00 00 00 00 00 ........... ©ao=............
B5F 41 43 49 53 20 20 20 4Ä 50 47 20 10 14 B6 61 _ACIS JPG . . f a
6F 3D 6F 3D 00 00 C7 58 4F 3C 03 00 6C C2 00 00 o= o = . .ÇXO<. . 1 Â . .
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Figure 49: 0xE5 replaced by 0x5F in Directory Entry to recover file

Determine the start cluster from the directory entry, as shown in Figure 49. 0x0003 will be Cluster 3.

Determine the size of the file from the last four bytes of the directory entry. Figure 50 has 0x0000C26C
shown in MS Calculator.

Determine how many sectors are in a cluster, which is found in the Boot Record. Once the record is
displayed, look for the data located at offset OxOD. In this case, the number of sectors per Cluster is two,
which is 1024 bytes.
o—
Calculator — □ X

= PROGRAMMER

C26C
HEX C26C

DEC 49,772
OCT 141154
BIN 1100 00100110 1100

Figure 50: File

Calculate how many clusters the file will occupy. Take the file size and divide it by the cluster size. Only
whole clusters can be allocated so the value must be rounded up; therefore 49,772 bytes will require 49
clusters. The FAT can then be rechained from the first cluster, Cluster 3. The media descriptors of the FAT
show that it is a FAT32 volume, meaning each cluster is addressed with 4 bytes.

Remember that the data recorded in the FAT is stored in little endian with the least significant byte on the
left.

Navigate to the FAT, and select the entry relating to the first cluster of the file(in this case, 3). Some
forensic software provides functionality to go directly to a specific FAT entry from the user interface, while
in others the user will have to manually locate the relevant FAT entry. The FAT begins immediately after
the reserved sectors. The number of reserved sectors can be found by looking at offset OxOE of the Volume
Boot Record for a length of 2 bytes(see Figure 6). The size of each entry within the FAT is determined by
the FAT version. FAT32 uses 32 bits(4 bytes) for each entry. So the FAT entry for cluster 3 begins at
offset 12(0x0C) from the start of the FAT. Cluster (3) x bytes per FAT entry (4).
 Offset: ___ 12j M in:-4,104

use Ox p re fix fo r hexadecim al values Max: 251,654,135

O from beginning

(•) from current position

(use negative num ber to go back)

O from end

OK Cancel

F igu re 51: G o to O ffset in D isk Editor

The red box in Figure 52 is at offset 12 of the FAT - the entry relating to cluster 3. Figure 52 shows the
FAT has been zeroed as a result of the file being deleted. This would indicate that the file was stored
contiguously, or together in one block of clusters on the volume.

U U O £ U X 7 0 0 uu uu uu uu uu uu uu uu uu uu uu uu uu uu uu uu
003201984 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
003202000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
003202016 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
003202032 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
003202048 F8 FF FF OF F F FF FF FF FF FF FF OF 00 00 00 a yy.yyyyyyy
H
003202064 00 00 00 00 00 00 00 00 00 00 00 00 w 00 00 00
003202080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
003202096 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
003202112 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
003202128 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
n n o o n o ia a nn r>r> nn nn nn nn nn nn nn nn nn nn nn nn nn nn
F ig u re 52: F A T 1, C lu ster 3 first byte highlighted

While still in edit mode, chain the FAT and point each cluster to the next cluster where the data resides.
Cluster 3 will point to Cluster 4. Cluster 4 will point to Cluster 5, and so on. This will continue for the next
49 Clusters, until the last cluster, where an end of file marker will be placed to indicate that this is the end
of the file, which will be Cluster 51. Recall from earlier in this material, the end of file marker is OxFF OxFF
OxFF OxOF, as shown in Figure 53.

F8 FF FF OF FF FF FF FF FF FF FF OF 04 00 00 00 o y y .y y y y y y y .
05 00 00 00 06 00 00 00 07 00 00 00 08 00 00 00
09 00 00 00 0À 00 00 00 0B 00 00 00 oc 00 00 00
0D 00 00 00 0E 00 00 00 0F 00 00 00 10 00 00 00
11 00 00 00 12 00 00 00 13 00 00 00 14 00 00 00
15 00 00 00 16 00 00 00 17 00 00 00 18 00 00 00
19 00 00 00 1À 00 00 00 IB 00 00 00 1C 00 00 00
ID 00 00 00 IE 00 00 00 IF 00 00 00 20 00 00 00
21 00 00 00 22 00 00 00 23 00 00 00 24 00 00 00 i .S . . .
25 00 00 00 26 00 00 00 27 00 00 00 28 00 i
00 00 *...&. . ( . ..
29 00 00 00 2À 00 00 00 2B 00 00 00 2C 00 00 00
2D 00 00 00 2E 00 00 00 2F 00 00 00 30 00 00 00 . .. / . . n
31 00 00 00 32 00 00 00 33 00 00 00 FF FF FF 0F 1...2. . .3. . yyy
F ig u re 53: C lu ster C h a in rebuilt until end o f fd e
Don't forget to save so the changes, if needed, so that they are written to the disk. (It is not absolutely
necessary to copy FAT 1 to FAT 2 because Windows will update FAT 2 to match FAT 1 on mounting the
volume.) If working on ‘live’ disk, it may need to be disconnected and re-mounted in Windows to update.
When recovering files manually like this, the larger the cluster number the more complicated the hex value.
Hex converter tools, such as Numerimal, make it easy to convert between hex and decimal. When using
these hex conversion tools, be sure to convert the hex to little endian before recording it in the FAT.

Allocated Clusters and Fragmented Files

When re-chaining the FAT, should a FAT entry be marked “in use” before the entire number of Clusters for
the file are chained, it can be an indication of two different scenarios:

• Fragmented File: The file is not stored in contiguous Clusters

• Over-written File: When the original file was deleted, the Clusters were marked available. New file
data has subsequently been saved to those Clusters.

When either of these scenarios occur, the content of the Clusters will need to be analysed to determine if
the file content can be matched to the content of the next unallocated Cluster. To do this, navigate to the
actual cluster

F ig u re 54: Navigate > G o To Sector - U se C lu ster F ie ld

 Practical 4
Recover deleted files from SFN volume

Make a back-up copy of the evidence (FAT Practical 2018.vhd).

Turn off write protection on working copy.

1. Locate directory entries in root marked as deleted and undelete by replacing 0xE5 with

File 1: i File 2:

Filename _ Filename _
Attributes Attributes

Create Ms. Create Ms.

Created Created

Last accessed Last accessed

Modified Modified

Start Cluster Start Cluster

File Size File Size

2. Find Volume Cluster size: k m fn

3. Find FAT type:. ¿ 6 - 7 - _ bytes per entry

4. Determine how many Clusters each file requires: (File size divided by Cluster size)

File 1: File 2:

5. Determine how many Clusters each file requires, remap, and save changes: Hint - Remember hex
converter tool Numerimal from http://www.xyntec.com/numerimal.htm

File 1: Fragments = File 2: Fragments =

Start Cluster: End Cluster: Start Cluster: End Cluster:

Start Cluster: End Cluster:

File 1 FAT Entries changed:

Offset(From Start of Volume) Cluster Entry Number Value

Ox Oxs
Ox Oxs
 File 2 FAT Entries changed:

Offset(From Start of Volume) Cluster Entry Number Value

Ox 0)o
Ox O)o
Ox O)o

XVI. Long Filename Entries

If the user creates a long filename Windows will automatically generate a second file name known as a
DOS Allas. A long filename is considered any name that does not conform to the DOS 8.3 naming standard
as previously discussed. That means even if the name is short (8+3) but contains lowercase characters it
is not DOS compliant - this behaviour may vary between Operating Systems. A long filename is still limited
to 255 characters (252 in the name and 3 in the extension). VFAT uses the following process to create an
equivalent 8.3 DOS Alias:

1. The first three (3) characters after the last dot in the long filename become the DOS alias’s extension.

2. The first six (6) characters of the long filename (excluding spaces which are ignored) are converted to
uppercase and become the first six characters of the DOS alias. If any of these characters are illegal
under the 8.3 DOS filename standard (i.e. “ + * , . / ; : < = > ? [ \ ] |), VFAT converts them into
underscores.

3. VFAT adds the two characters ~1 as the seventh and eighth characters of the DOS alias. If the ~1
results in a name conflict, then ~2, -3, etcetera will be used as necessary.

The creation of the long filename: “This is a really long filename.txt", results in the creation the DOS alias
of THISIS-1 .TXT. (Note that the DOS alias is in all uppercase.)

The DOS alias entry is the SFN, where the file size, starting Cluster, true attribute byte, file dates/times,
and other file information are stored.

Directory Entry Set

Figure 55 shows the 32-byte directory entry for the SFN ‘THISIS~1TXT’. This entry contains the location,
size, and date information. There are then three 32-byte directory entries for the LFN This is a really long
filename.txt’. Combined, these are known as a directory entry set.
o
O

43 65 00 20 00 6E 61 00 6D 00 OF 00 43 65 00 C e . .n .a .m .. .C e .
2E 00 74 00 78 00 74 00 00 00 00 00 FF FF FF FF . .t .x .t yyyy
02 69 00 63 00 61 00 6C 00 20 00 OF 00 43 6C 00 .i .c .a .1. .. .Cl.
6F 00 6E 00 67 00 20 00 66 00 00 00 69 00 6C 00 o .n .g . .£ ...i .1.
01 54 00 68 00 69 00 73 00 20 00 OF 00 43 69 00 .T.h.i. s . .. .Ci .
73 00 20 00 61 00 20 00 74 00 00 00 79 00 70 ooJ s . .a . .t .. ■ V P
54 48 49 53 49 53 7E 31 54 58 54 20 00 À7 TÎ4 THISIS- 1TXT .§.d
30 3E 30 3E 00 00 91 61 30 3E 34 00 54, 00 00 0>0> . .'aO >4 .T. . .

LFN entries DOS Alias

Figure 55: Long File Name
 IMPORTANT: The 32-byte entries for the Long Filename only hold the LFN information and are not needed
for the operating system to access or use the file.

The first byte of a long file name is called the sequence byte. The sequence byte is used to track multiple
long file name directory entries. The right nibble is a sequence number for the multiple entries for one
LFN. See Figure 56.
°[43] 65 00 20 00 6E 00 61 00 6D 00 OF 00 43 65 00 C e. .n .a .m. . . Ce .
2E 00 74 00 78 00 74 00 00 00 00 00 FF FF FF FF . . t . x . t . . . . y y y y
69 00 63 00 61 00 6C 00 20 00 OF 00 43 6C 00 . i . c . a . 1. . . . C l .
6F 00 6E 00 67 00 20 00 66 00 00 00 69 00 6C 00 o . n . g . . f . . . i . l .
(0Ï) 54 00 68 00 69 00 73 00 20 00 OF 00 43 69 00 . T . h . i . s . . . .C i .
73 00 20 00 61 00 20 00 74 00 00 00 79 00 70 00 s . . a . . t . . • y p-
54\ 48 49 53 49 53 7E 31 54 58 54 20 00 À7 19 64 THISIS~1TXT . §. d
30^3E 30 3E 00 00 91 61 30 3E 34 00 54 IB 00 00 0 > 0 > . . ' aO >4 .T. . .

Sequence bytes
F ig u re 56: Sequence bytes

The 0x43 in the red square of Figure 61 is the sequence byte of the last entry. While the right nibble (3)
represents the third LFN entry, the left nibble (4) represents the Nth entry or the last LFN entry. The value
for the left nibble is a bit based flag (0100) that marks the last long name entry. Binary 0100 = 0x04. It is
important to remember that this value is 0x4 not decimal 4.

But what happens when there are more than 15 LFN entries? Although this is rare, it is still possible. The
Table in Figure 57 is an example of how the sequence for the last LFN entry is calculated based on the
flags hex value.

Directory Hex Values of the Sequence Byte

Entry
1 0x41
2 0x01 0x42
3 0x01 0x02 0x43
4 0x01 0x02 0x03 0x44
5 0x01 0x02 0x03 0x04 0x45
6 0x01 0x02 0x03 0x04 0x05 0x46
7 0x01 0x02 0x03 0x04 0x05 0x06 0x47
8 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x48
9 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x49
10 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x4A
11 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 OxOA 0x4B
12 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 OxOA OxOB 0x4C
13 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 OxOA OxOB OxOC 0x4D
14 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 OxOA OxOB OxOC OxOD 0x4E
15 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 OxOA OxOB OxOC OxOD OxOE 0x4F
16 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 OxOA OxOB OxOC OxOD OxOE OxOF 0x50
F ig u re 57: L F N Sequ en ce Num bers
An example of this happening can be seen in Figure 58.

m 72 00 20 00 6C 00 69 00 6D 00 OF 00 IF 69 00 P r . .1.i .m .. . .i .
JA 00 20 00 2E 00 74 00 78 00 00 00 74 00 00 00 t . . . .t .x . ..t . . .
of 65 00 20 00 32 00 35 00 35 00 OF 00 IF 20 00 .e. .2.5.5.
63 00 68 00 61 00 72 00 61 00 00 00 74 00 65 00 c .h .a .r .a . ..t .e .
0E 20 00 74 00 6F 00 20 00 67 00 OF 00 IF 65 00 . .t .o . .g .. . .e .
74 00 20 00 74 00 6F 00 20 00 00 00 74 00 68 00 t . .t .o . . ..t .h .
0D 67 00 20 00 61 00 73 00 20 00 OF 00 IF 70 00 .g . .a .s . .. . ,p.
6F 00 73 00 73 00 69 00 62 00 00 00 6C 00 65 00 o .s .s .i .b . ..1. e .
OC 61 00 6B 00 65 00 20 00 69 00 OF 00 IF 74 00 .a .k .e . .i .. . .t .
20 00 61 00 73 00 20 00 6C 00 00 00 6F 00 6E 00 a s . .1.. .o .n .
OB 67 00 6F 00 61 00 6C 00 20 00 OF 00 IF 77 00 .g .o .a .1. .. . .w .
61 00 73 00 20 00 74 00 6F 00 00 00 20 00 6D 00 a .s . .t .o . .. .m .
0À 79 00 20 00 65 00 6E 00 74 00 OF 00 IF 72 00 .y. .e.n.t.. . .r .
69 00 65 00 73 00 20 00 6D 00 00 00 79 00 20 00 i .e .s . .m . . •y • •
09 20 00 4C 00 46 00 4E 00 20 00 OF 00 IF 64 00 . .L.F.N. .. . .d.
69 00 72 00 65 00 63 00 74 00 00 00 6F 00 72 00 i .r .e .c .t . ..o .r .
08 74 00 68 00 65 00 20 00 6E 00 OF 00 IF 75 00 .t .h .e . .n .. . .u .
6D 00 62 00 65 00 72 00 20 00 00 00 6F 00 66 00 m .b .e .r . . ..o .f .
07 20 00 62 00 79 00 74 00 65 00 OF 00 IF 20 00 . .b .y .t .e .
74 00 72 00 61 00 63 00 6B 00 00 00 73 00 20 00 t .r .a .c .k . ..s . .
06 20 00 74 00 68 00 65 00 20 00 OF 00 IF 73 00 . .t .h .e . . . . .s .
65 00 71 00 75 00 65 00 6E 00 00 00 63 00 65 00 e .q .u .e .n . ..c .e .
05 6C 00 6C 00 69 00 73 00 74 00 OF 00 IF 72 00 .1.1. i .s .t .. . .r .
61 00 74 00 65 00 20 00 68 00 00 00 6F 00 77 00 a .t .e . .h . ..o .w .
04 65 00 20 00 74 00 6F 00 20 00 OF 00 IF 74 00 .e . .t .o . .. . .t .
72 00 79 00 20 00 74 00 6F 00 00 00 20 00 69 00 r .y . .t .o . .. .i .
03 76 00 65 00 72 00 79 00 20 00 OF 00 IF 6C 00 .v .e .r .y . .. . .1.
6F 00 6E 00 67 00 20 00 6E 00 00 00 61 00 6D 00 o .n .g . .n . ..a .m .
02 73 00 61 00 76 00 65 00 64 00 OF 00 IF 20 00 .s .a .v .e .d .
n 00 69 00 74 00 68 00 20 00 00 00 61 00 20 00 w .i .t .h . . ..a . .
(01) 54 00 68 00 69 00 73 00 20 00 OF 00 IF 66 00 .T .h .i .s . .. . .f .
6li 00 6C 00 65 00 20 00 69 00 00 00 73 00 20 00 i .1. e . .i . ..s . .
54 48 49 53 46 49 7E 31 54 58 54 20 00 ID 19 63 THISFI~1TXT . . .c
30 3E 30 3E 00 00 E9 62 30 3E 34 00 54 IB 00 00 0 >0 >. .ébO >4 .T. . .
F ig u re 58: L F N with 15 directory entries

There are several things to take note of about the LFN entries. The long file name is recorded in Unicode
requiring two bytes per character. Unicode for the LFN starts following the Sequence Byte. Only 13 bytes
of the 32-byte entry are used to store the file name in part because of Unicode but also because there are
a few other bytes that are used for error checking and to record attributes.

The attribute byte at offset OxOB, of each LFN entry contains the hex value OxOF, which designates it as
an LFN entry. OxOF is the flags all turned on for Read only, Flidden, System, Volume Label - see Figures
59 and 60.
 Binary Hex Description
0000 0001 0x01 Read Only
0000 0010 0x02 Hidden
0000 0100 0x04 System
0000 1000 0x08 Volume Label
0001 0000 0x10 Directory
0010 0000 0x20 Archive ON
0100 0000 0x40 Reserved (used for VFAT)
1000 0000 0x80 Reserved (used for VFAT)
0000 1111 OxOF LFN Entry
F ig u re 59: F la g Values f o r S F N entry

43 65 00 20 00 6E 00 61 00 6D 00 [QE 00 43 65 00 Ce. .n a .m ...C e .

2E 00 74 00 78 00 74 00 00 00 00 00 FF FF FF FF ..t .x . ■yyyy
02 69 00 63 00 61 00 6C 00 20 00 Io f I00 43 6C 00 .i .c .a i . ...Cl.
6F 00 6E 00 67 00 20 00 66 00 00 m 69 00 6C 00 o .n .g . .f.. .i.l.
01 54 00 68 00 69 00 73 00 20 °9 OF 00 43 69 00 T.h.i s . ...Ci .
73 00 20 00 61 00 20 00 74 00 /tfo 00 79 00 70 00 s . .a . .t .. ,y p.
54 48 49 53 49 53 7E 31 54 54 20 00 À7 19 64 THISIS~1TXT .§ .d
30 3E 30 3E 00 00 91 61 3CK dE 34 00 54 IB 00 00 0>0>. . aO >4 .T. ..
Attribute byte

F ig u re 60: Attribute byte in L F N entries

The checksum byte located at offset OxOD is the checksum value generated from the Short File Name
(SFN). The Table listed in Figure 61 shows the byte break down of the LFN directory entry.

Offset Length Byte Usage

0x00 1 Bits 0-5 give the LFN sequence number, bit 6 (i.e. 40h) is set if this is the last entry for
the file (this is how the 40h + sequence number is derived).
0x01 10 1st 5 letters of LFN entry.
0x0 B 1 OFh (RSHV attributes are all set). Called the “flag” byte
OxOC 1 Reserved set to 0
OxOD 1 Checksum generated from SFN
OxOE 12 Next 6 letters of LFN entry
0x1 A 2 Always 0 (zero)
0x1C 4 Last 2 letters of LFN entry
0x01 10 1st 5 letters of LFN entry.
OxOB 1 OFh (RSHV attributes are all set). Called the “flag” byte
OxOC 1 Reserved set to 0
OxOD 1 Checksum generated from SFN
OxOE 12 Next 6 letters of LFN entry
0x1 A 2 Always 0 (zero)
0x1 C 4 Last 2 letters of LFN entry
F ig u re 61
XVII.Recovering of Long File Names
When recovering the LFN it is important to link it to the SFN - as the SFN directory entry is the one that
contains the actual file information (dates, times, starting cluster, attributes, etc). The LFN(s) and SFN are
linked together by a Checksum byte (byte 14 of the 32-byte directory entry) that is calculated by running
an algorithm on the values of the SFN. For this reason, the first character of the short file name that is
changed to 0xE5 upon deletion must be restored to its original short file name. The original character will
be the first character in the LFN entry at offset 0x01, capitalised if the LFN character is in lower case. See
Figure 62.

E5 65 00 20 00 6E 00 61 00 6D 00 OF 00 43 65 00 â e . .n a .m. .C e .
2E 00 74 00 78 00 74 00 00 00 00 00 FF FF FF FF . .t .x . yyyy
E5 69 00 63 00 61 00 6C 00 20 00 OF 06 43 6C 00 a i .c .a 1. -. .Cl.
6F 00 6E 00 67 00 20 00 66 00 00 00 69 00 6C 00 o .n .g . .£ . . i.l.
E5 54 00 68 00 69 00 73 00 20 00 OF 00 43 69 00 M • h •i s . . .Ci.
n 00 20 00 61 00 20 00 74 00 00 00 79 00 70 00/'s. .a. . t . . y p-
E5\ 48 49 53 49 53 7E 31 54 58 54 20 00 À7 19 v i ] I h i s i s ~ i t x t .§ .d
30i 3E 30 3E 00 00 91 61 30 3E 34 00 54 IB 00/V 0 > 0 > . . aO >4 T. . .
nn ! nn nn nn nn nn nn nn nn nn nn nn nn nn mrvTin
Change 0xE5 to sequece bytes Match SFN to 1st char of LFN
F igu re 62: L F N recovery

The LFN directory entries also need to be recovered by changing the 0xE5 to the appropriate sequence
values. Once this is done, the FAT can be re-chained to fully recover the file.

Practical 5

Examine directory entries of LFN files, using FAT Practical 2018.vhd, Partition 1.

Why does Words.txt need a LFN entry?_________________________________________________

Note the deleted directory entry set for Dusky Dolphins.jpg, and the directory entry set for Renamed -
Dusky Dolphins Kaikoura.jpg.

Why is there a new directory entry for the same file?_______________________________________

XVIII. File Slack
Slack space is the area of the last cluster a file is allocated that is not required to store the logical file - it
is space that is greater than the logical file size. This may consist of data that was previously located in
that cluster. The important aspect of slack data is that the Operating System ignores the slack data as it
is only interested in the logical file data within the assigned cluster. File Slack is the area from the end of
the logical file to the end of the last cluster assigned to hold the data. File slack is a term that represents
the total slack space in a file. File Slack is comprised of RAM Slack and Residual Slack.

RAM Slack
The area from the end of the logical file to the end of the sector. Because the sector is the smallest writable
unit, if the last sector to be written does not require the full 512 bytes, then something still must be written
there. In former years this excess data was pulled from RAM hence the name RAM Slack. Because of this,
the FtAM Slack could contain anything in the memory buffer that the computer was storing at the time to
include directory structures, passwords, web sites, documents and so forth. After Windows 95b (Windows
95 Service Pack 1), Microsoft changed how RAM Slack was handled and started padding the Ram Slack
with 0x00. For example, if a Cluster contained two sectors (1024 bytes) but the file that occupied the
cluster only took up 400 bytes, the space from the end of the file to the end of the sector (112 bytes) would
be considered RAM Slack.

For example, Figure 63 is a cluster from a FAT12 volume which has a one sector cluster size.

F ig u re 63: 512 byte cluster

A file is written to the cluster which is 100 bytes in size, as depicted in Figure 64.

F igu re 64: 100 byte f ile

The cluster is 512 bytes in size and the operating system must write 512 bytes, as depicted in Figure 65.
The operating system used to take the extra data needed from RAM and write it to disk, in this case 412
bytes. This was recognized as security vulnerability as anything could be present in that data including
passwords. As of the release of Windows 95 Service Pack 1 that slack space is padded with 0x00.
 F ig u re 65: R A M Sla ck area p a d d ed with 0x00

On a volume with a one sector cluster size the only slack present will be RAM slack and on operating
systems from Windows 95b it will be padded with 0x00.

Drive / Residual Slack

The area from the end of the RAM Slack to the end of the cluster that the file occupies. Residual Slack can
contain data from files that resided in the same cluster prior to the time when the new data overwrote the
old data, hence it is often referred to as Drive Slack. This Residual Slack can provide an examiner with
evidence in many forms such as incriminating documents, photographs, chat history, Internet history and
so forth. Because the type of data that can be located in Residual Slack is incomplete data, the examiner
must take caution when formulating opinions about the slack data, as the entire file is not available. This
would be like walking into the room and only hearing the last sentence of a conversation. Without knowing
what the entire conversation was, the last sentence could easily be taken out of context. For example, if
a cluster contained two sectors (1024 bytes) but the file that occupied the cluster only took up 400 bytes,
the space from the end of the file to the end of the first sector (112 bytes) would be considered RAM Slack.
But the space from the end of the first sector to the end of the cluster, sector two (512 bytes), would be
considered Residual Slack.

Figure 66 below illustrates a logical file, and highlights RAM and Residual Slack. In green is the very end
of the logical allocated file contents located in Cluster 51. Cluster 51 contains two sectors. Highlighted in
red is the RAM Slack area, which goes from the end of the logical file to the end of the first sector of Cluster
51. The RAM slack value is 0x00.

Highlighted in blue is second sector in Cluster 51, the last cluster of our example file. Notice this sector
has data in it that is left over from a previous file. This is called residual slack and may contain valuable
information. On larger drives there are up to 64 sectors in a single cluster, the amount of data contained in
residual slack could be substantial.
 0 1 2 3 4 5 6 7 8 9 À B C D W E F I
77 20 72 6 l 6D 20 61 6E 64 20 72 65 73 69 64 75 v ram and résidu
SI 6C 20 ' 73r6C~ST 63TT6B ' 2E 54 68 69 73 20 66 69 BSHBIroEIÏfiïE^ File
6C 65 20 68 6F 70 65 66 75 6C 79 20 73 68 6F 77 le hopefuly show
20 72 Ü M i M 20 72 65 73 69 64 75 61 ran and residua
6C 20 73 60 61 63 6B. 2E 00 00 00 00 00 00 CE 1 slack.
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 0 0 00 00 00 00 00 Ram Slack
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 EE
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 0 0 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00
7F 4F 23 F4 74 FF 00 39 EA D7 FE 85 51 2D
97 91 D5 87 4à B3 28 65 D4 EC BA 72 1C DB I nfclBKÏÏBCTJE Residual Slack
CD 60 ¿6 8F 47 OF À7 7À 9B 2A 66 5D 39 6F Fem H t S T Dfc'EESF
BE 8F À3 6D 7F À6 F5 6C AB D5 À9 IF IF 17
F ig u re 66: Ram and R esid ua l Sla ck

Take an example take a four-sector cluster as illustrated in Figure 67.

Four sector cluster

Each sector 512 bytes

Cluster 2048 bytes in size

F ig u re 67: F o u r secto r C lu ster

A file named RED is written to the cluster. RED is 1900 bytes in size, a four sector cluster is 2048 bytes
in size. This means RED fully occupies the first three sectors but does not fully occupy the fourth sector.
From the end of the file to the next sector boundary is RAM slack. In this instance the next sector boundary
is also the end of the Cluster. The only slack present in this Cluster at that point in time is 148 bytes of
RAM slack, as depicted in Figure 68.
 Occupied by RED file 1900 in size
148 bytes not needed for file

File data RAM Slack

Figure 68: RAM Slack in Final Cluster

Now what happens when the file RED is deleted? The status byte of the Directory Entry changes to 0xE5
and the FAT is zeroed but the data is not affected. This means the file data is still sitting in the cluster.

Now imagine that a new file is written named GREY and as the cluster previously assigned to RED is
available it is now allocated to GREY, as shown in Figure 69. The new file GREY is 600 bytes in size, it
occupies the whole of the first sector and writes 88 bytes to the second sector. The end of the file to the
next sector boundary is RAM slack and padded 0x00. Sector three and four are not changed or written to
and contain data residual from the file RED. Sector four contains 364 bytes of data residual from the file
RED and 148 of RAM slack from when RED was written to disk.

New GREY file written to cluster

600 bytes in size

Figure 69: Grey File written with RAM Slack, last two sectors are untouched.
 Practical 6
Recover deleted files/directories from LFN volume - only File 1 in class time
1. Locate directory entries in root marked as deleted, and undelete by replacing 0xE5 with first letter of
file name.
File 1 File 2

SFN Filename SFN Filename

Attributes Attributes

Create Ms. Create Ms.

Created Created

Last accessed Last accessed

Modified Modified
Start Cluster - Start Cluster -
high word high word
SC - low word SC - low word

File Size File Size

2. Undelete Long File Name Directory Entries

File 1 File 2
Offset(From Start of Volume) Value Offset(From Start of Volume) Value
Ox Ox Ox Ox
Ox Ox Ox Ox

3. Find Volume Cluster size:

4. Determine how many Clusters each file requires: (File size divided by Cluster size)
File 1: File 2:

5. Find FAT type:_______= ___________ bytes per entry

6. Determine how many Clusters each file requires, remap, and save changes: HINT - remember Hex
converter tool...

File 1: Fragments = File 2: Fragments =

Start Cluster: End Cluster: Start Cluster: End Cluster:
Start Cluster: End Cluster: Start Cluster: End Cluster:

Start Cluster: End Cluster:

Start Cluster: End Cluster:

FAT Entries

File 1
O ffset(From Start of Volum e) C lu ste r Entry N um ber Value
Ox Ox
Ox Ox
Ox Ox
Ox Ox

File 2
Offset(From Start of Volum e) C lu ste r Entry N um ber Value
Ox Ox
Ox Ox
Ox Ox
Ox Ox
Ox Ox
Ox Ox
Ox Ox
Ox Ox
XIX. Volume Slack
An area at the end of the partition which is not part of the Volume - it is the unused space between the last
cluster of file system and end of the partition in which the file system resides. If the Volume has a cluster
size of eight sectors and the Volume size is not divisible by eight, there will be sectors left over which are
part of the partition but not within the volume. In this instance the Volume Slack will be less than eight
sectors. If the drive had been used previously and partitioned again there may be data present from a
previous volume.

Figure 70 is the Directory view of a FAT32 volume with a 16 sector cluster size (this is not normal and was
defined when formatting for demonstration purposes). Volume slack will always be smaller than the cluster
size and in this case consist of 8 sectors.

(Root directory) 8.0 KB

Q File slack.txt tx t 0,8 KB 29/01/2014 14:46:19.2
X Interesting File.txt tx t 1.8 KB 29/01/2014 14:34:19.8
_J Long File N am e.txt txt 1.4 KB 29/01/2014 14:34:18.8
] SHORT.txt txt 1.1 KB 29/01/2014 14:34:19.3
| B oot sector 3.1 MB
Q fa ti 483 KB
□ fat 2 483 KB
] Free space ' net) 965 MB
| Idle space
V o lu m e slack 3.5 KB
Figure 70: showing Volume slack
XX. Recommended Resources
Brouwer, Andries. "The FAT File System”. September 20, 2002.

https://www.win.tue.nI/~aeb/linux/fs/fat/fat.html#tod

Carrier, Brian (2005). FAT Data Structures. File System Forensic Analysis. Upper Saddle River, NJ.
Pearson Education.

Casey, Eoghan (2004). Forensic Examination of Windows Systems. Digital Evidence and Computer
Crime; Forensic Science, Computers and the Internet. Academic Press.

http://support.microsoft.com/kb/140365 MS default Cluster sizes

XXI. Answer Key
Practical 1

Parse directory entries of SFN files, using FAT Practical 2018.vhd, Partition 1.

File 1: File 2:

Filename w onvs Filename FACES

File Extension TKT File Extension TKT

Attributes A rc h iv e / (0 * 2 0 ) Attributes A rchives (0 * 2 0 )

Create Ms. 130 (0 * 8 2 ) Create Ms. 34 (0 * 2 2 )

Created 3 /fe h /2 0 1 7 10:04:04 ams Created 3 /F e h /2 0 1 7 11:01:18 ams

Last accessed 3 /fe b /2 0 1 7 Last accessed 3 /F e h /2 0 1 7

Modified 3 ife h rf2 0 1 7 1 1 :0 8 :4 4 ams Modified 3 /F e h /2 0 1 7 14:20:22 ams

Start Cluster 2 Start Cluster 4

File Size 4 ,4 6 7 b y te * File Size 31,919 b y te *

TEKAPO.JPG is a hidden file as its directory entry is (several entries) below an unused directory entry that
begins with 0x00.

File 3:

Filename TEKAPO

File Extension JPG

Attributes A rchives (0 * 2 0 )

Create Ms. 35 (0 * 2 3 )

Created 7 /F e h /2 0 1 7 11:17:18

Last accessed 7fF e h /2 0 1 7

Modified 7 /F e h /2 0 1 7 1 1:16:14

Start Cluster 31

File Size 16,951 b y te *

Practical 2

Examine Cluster Chain of files

File 1: WORDS.TXT
Start Cluster:___________ 2_______________ End Cluster:______________3

File 2: FACES.TXT
Fragment 1 Start Cluster 4____________ End Cluster:__________ 6 _
Fragment 2 Start Cluster 20___________ End Cluster:__________ 22
Fragment 3 Start Cluster 11__________ End Cluster:__________ 12

BONUS:

File 3: TEKAPO.JPG
Fragment 1 Start Cluster:________ 31____________ End Cluster:__________ 35_

Practical 3

Examine Sub-directory directory entries for:

NZ PHOTO

File Name Attribute Byte Start Cluster:

(in root) ■D ire c to ry (OyAO) 10 (O yA A )
entry D ire c to ry (OyAO) 10 (O yA A )
entry D ire c to ry (OyAO) r o o t ( OyßO)
MOUNTN D ire c to ry (OyAO) 36 (O yA ^)
■BEACH D ire c to ry (OyAO) 37 ( 0yA 5)
_ITY D ire c to ry (OyAO) 13 (O yA D )

BEACH

File Name Attribute Byte Start Cluster:

entry D ire c to ry (OyAO) 37 (O y/25)
entry D ire c to ry (OyAO) 10 (OyO A)
P IH A JP G A rc h iv e / (OyAO) 7 (0yJ07)
M OEKAKl.JPG A rc h iv e / (OyAO) 24 (O y/18)
TASMAN .JPG A rc h iv e / (OyAO) 57(O yA 9)

Practical 4

Recover deleted files from SFN volume

1. Locate directory entries in root marked as deleted

 File 1: File 2:

Filename _K C V K M T.TX T Filename _KCVKME2.TXT

Attributes A rc h iv e / (0 x/2 0 ) Attributes A rc h iv e / (0 x/2 0 )

Create Ms. 191 (O XBT) vA- Create Ms. 130 (0 x 3 2 )

Created 7 /T e h /2 0 1 7 0 9 :3 6 :3 4 a m j Created 7/T e h /2 0 1 7 1 0 :1 1 :3 0 a m /

Last accessed 7 /T e h /2 0 1 7 Last accessed 7/T e h /2017

Modified 7/T e h /2 0 1 7 0 9 :3 6 :2 0 a m / Modified 7/T e h /2 017 1 1 :00:44 a m /

Start Cluster 18 (0 X 1 2 ) Start Cluster 29 (OX.1V)

File Size 4 ,895 byte File Size 12,288 b y te *

2. Find Volume Cluster size: 4,096 b y te *

3. Find FAT type: 16 = 2 bytes per entry

4. Determine how many Clusters each file requires: (File size divided by Cluster size)

File 1: File 2:

2 3

5. Determine how many Clusters each file requires and remap:

File 1: Fragments = 1 File 2: Fragments = 2

Start
18 End Cluster: 19 Start Cluster: 29 End Cluster: 30
Cluster:
Start Cluster: 38 End Cluster: 38

File 1 FAT Entries changed:

O ffset(From Start of Volum e) C lu ste r Entry N um ber Value

0x1024 18 0 x0 0 1 3
0x1026 19 O xfTTT

HINT - Don’t forget Little Endian - 0x0013 looks like “13 00" in hex view

File 2 FAT Entries changed:

Offset(From Start of Volum e) C lu ste r Entry N um ber Value

0x103A 29 OxOOlE
0x103C 30 0x0 0 2 6
0x104C 38 O xfTTT
 6. Save changes, refine volume snapshot / refresh view, mount in Windows to view.

BONUS

U n h id e T E K A P O .J P G

TEKAPO.JPG is not a deleted file, it is hidden because of the prior directory entries that start with 0x00.
Replace the first byte of previous directory entries with a legal character that will allow the file system to
ignore the remainder of the directory entry (0xE5). (offset 0x3D0C0). Save Changes.

Practical 5
Examine directory entries of LFN files, using FAT Practical 2018.vhd, Partition 1.
v ■. ■ * -
Why does Words.txt need a LFN entry? I t h a y lower cate/ ctuvraxtery which/ cere-- vuyt 8.3 VOS
com pliant.

Note the deleted directory entry set for Dusky Dolphins.jpg, and the directory entry set for Renamed -
Dusky Dolphins Kaikoura.jpg.
Why is there a new directory entry for the same file? T T w c h y u y t^ im le w jd d v o fth & lo ru ^ R le /n a m ie /
required/ a differem t a m o u n t o f dtrectcn'v entries,
/ cv new d irecto ry en try %et way
created/.

Practical 6
Recover deleted files/directories from LFN volume - only File 1 in class time.
1. Locate directory entries in root marked as deleted, and undelete by replacing 0xE5.

File 1: File 2:
SFN Filename KECO VE~l.TXT SFN Filename N E E V M O ~l.TX T

Attributes A rc h iv e / (0 x/2 0 ) Attributes A rc h iv e / ( 0 k 2 0 )

Create Ms. 187 (O kS B ) Create Ms. 134 ( 0>c86)

Created 7 ffe b /2 0 1 7 1 1 :3 3 :3 8 a m / Created 7 ffe b f2 0 1 7 1 1 :3 9 :3 4 a m /

Last accessed 7 /fe tr/2 0 1 7 Last accessed 7 /fe b /2 0 1 7

Modified 7 ffe h /2 0 1 7 1 1 :3 5 :2 4 a m / Modified 7 ife k rf2 0 1 7 12:45:02pvyv

Start Cluster - Start Cluster -
0 0
high word high word
SC - low word 9 ( 0 yj0 9 ) SC - low word 152 ( 0 k9 8 )

File Size 8,192 h yte y File Size 16,382 h ytey

Long File Name Directory Entries:

 File 1 File 2
O ffset(From Start of Volum e) Value Offset(From Start of Volum e) Value
0x400100 0x01 0x4001 CO 0x01
0x4000E0 0x42 0x4001A0 0x42

2. Find Volume Cluster size: 2,048 bytes__________________

3. Determine how many Clusters each file requires: (File size divided by Cluster size)

File 1: File 2:

4 8

4. FAT type: 32 = 4 bytes per entry

5. Determine how many Clusters each file requires, remap, and save changes:

File 1: Fragments = 2 File 2: Fragments = 4

Start Cluster: 9 End Cluster: 10 Start Cluster: 152 End Cluster: 155
Start Cluster: 102 End Cluster: 103 Start Cluster: 181 End Cluster: 182

Start Cluster: 248 End Cluster: 248

> 1952 h a s data from another deleted file < Start Cluster: 1999 End Cluster: 1999

FAT Entries changed:

File 1
O ffset(From Start of Volum e) C lu ste r Entry N um ber Value
0x302C24 9 OxOOOOOOOA
0X302C28 10 0x00000066
0x302D98 102 0x00000067
0x302D9C 103 0xOFFFFFFF

File 2
O ffset(From Start of Volum e) C lu ste r Entry N um ber Value
0x302E60 152 0x00000099
0x302E64 153 0xOOOOOO9A
0x302E68 154 0x00 0000 93
0x302E6C 155 0x00 0000 35
0x302ED4 181 0x00 0000 36
0x302ED8 182 0X000000F8
0x302FE0 248 0xOOOOOJCf q f.
0X304B3C 1999 o xo ffffffV
HINT - Don’t forget Little Endian - OxOOOOOOIA looks like "1A 00 00 00” in hex view

This is a trap that is easy to fall into, and even leading forensic tools will show Cluster 1952 as part of the
recovered file. It is important to check that the Cluster content truly represents what may have been the
original file. In reality, only the first Cluster can be guaranteed (and even then not its content), the
remainder is subjective.

Bonus Level Exercises

Additional File/Folder Recovery SFN Volume

Folder 1:

Name _ITY

Attributes V tre c to ry (O v lO )

Create Ms. 171 ( OvAB)

Created 7/Feb-/2 017 0 8 :3 1 :04 cmv

Last accessed 7ffe h -flO l 7

Modified 3 /f& b /2 0 1 7 13:42:04

Start Cluster - high word O

SC - low word 13 (O vO V)

File Size O byte*

File 1:

Name H(D33IT_1.TPG

Attributes A rchive^ (OyJZO)

Create Ms. 139 (0>c83)

Created 7 /fe b /2 0 1 7 1 0 :ll:1 9 a « w

Last accessed 7 ffe k /2 0 1 7

Modified 3 /fe b /2 0 1 7 12:35:34

Start Cluster - high word O

SC - low word 2 6 (0 V IA )

File Size 11,219 byte*

 File 2:

Name .O B B IT .2 J P G

Attributes A rc h iv e / (0 x 2 0 )

Create Ms. 108 (0 x 6 C )

Created 7/F e h /2 0 1 7 0 8 :3 3 :0 3 a m ,

Last accessed 7 /fe h /2 0 1 7

Modified 3 /fe h /2 0 1 7 12:35:48

Start Cluster - high word 0

SC - low word 1 6 (0 )0 .0 )

File Size 7,530 byte&

File 3:

Name AUCKLAND JPG

Attributes A rc h iv e , (0 x 2 0 )

Create Ms. 6 (0 x 0 6 )

Created 7ip e h /2 0 1 7 0 8 :3 1 :3 6 a m ,

Last accessed 7f f e h /2017

Modified 3 /fe h /2 0 1 7 1 2:32:40

Start Cluster - high word 0

SC - low word 1 4 (0 x 0 6 )

File Size 6,416 byte&

FAT Changes
F A T Entry O ffset(From Start of C lu ste r Entry N um ber Value
File/Folder Nam e V olum e)
JT Y 0x101A 13 OxFF
AUCKLAND.JPG 0x101C 14 0x0 F
AUCKLAND.JPG 0x101E 15 OxFF
_OBBIT_2.JPG 0x1020 16 0x11
_OBBIT_2.JPG 0x1022 17 OxFF
HOBBIT_1.JPG 0x1034 26 0x1 B
HOBBIT_1.JPG 0x1036 27 0x1 C
HOBBIT_1.JPG 0x1038 28 OxFF
IACTS
The International Association of
New Technology File System
Windows File Systems
Computer Investigative Specialists

Contents
I. Synopsis....................................................................................................................................................... 1
II. BCFE Learning Objectives........................................................................................................................... 2
III. History of NTFS............................................................................................................................................ 2
IV. NTFS Essentials................................................................................................... 3
V. Volume Boot Record.................................................................................................................................... 4
VI. Master File Table......................................................................................................................................... 6
VII. File Records................................................................................................................................................. 7
VIII. Attributes.................................................................................................................................................... 11
IX. Attribute Types..................... •.................................................................................................................... 14
X. SStandardJnformation Attribute - 0x10.................................................................................................... 15
XI. Attribute with Non-ResidentContent........................................................................................................... 27
XII. Indexing Structures in NTFS...................................................................................................................... 38
XIII. Reparse Points........................................................................................................................................... 45
XIV. Named Stream (Alternate Data Stream)....................................................................................................46
XV. File Deletion and Recovery........................................................................................................................ 48
XVI. Volume Format........................................................................................................................................... 50
XVII. Volume Recovery....................................................................................................................................... 51
XVIII. SLogFile..................................................................................................................................................... 51
XIX. $USN Journal............................................................................................................................................. 52
XX. The Future of NTFS................................................................................................................................... 54
XXI. Compiled Tables........................................................................................................................................ 55
XXII. Answer Key................................................................................................................................................ 67

Synopsis
New Technology File System (NTFS) is the default file system currently used by Microsoft Operating
Systems for fixed disks. Microsoft needed a file system that was more reliable, more efficient and with
more administrative controls (i.e. security, and quotas) to remain competitive, particularly in the server
 market. Additionally, disk drive size exponential growth has gone beyond the addressing capability of FAT,
which required Microsoft to develop a new file system from the ground up.

The added features and robust file system that is NTFS quickly became the file system of choice for all of
Microsoft’s Operating Systems after Windows ME. NTFS is also an extensible file system, and can be
easily modified to respond to the continued growth of drive and volume sizes. This block will address in
detail three aspects of NTFS which correspond (roughly) to the FAT file system; file allocation,
fragmentation, file name information, metadata such as dates and times recorded fora file, and file deletion.

II. BCFE Learning Objectives

This module describes the data structures that NTFS uses to store and retrieve data that is saved within
the volume. Understanding the data structures of NTFS will aid in locating and recovering evidence that
would be hidden to the casual user. At the conclusion of this lesson, the student should:
• Recognize the different versions of NTFS.
• Understand Master File Table records in order to locate and interpret metadata and data associated
with a file.
• Understand how the NTFS stores dates and times.
• Understand what occurs when a file is created and deleted on an NTFS volume.
• Recognize “Orphan” files.

This manual includes much more information about the New Technology File System than what will be
taught in the Basic Computer Forensic Examiner class. The manual and BCFE NTFS.vhd file provided in
class work together to explain basic and advanced concepts that may be encountered during a forensic
examination.

III. History of NTFS

NTFS was developed in the 1990’s as a replacement for FAT - it has undergone four upgrades from the
original release. To date, each upgrade has been released with a new version of the Microsoft Windows
operating system family. Later releases of Microsoft Windows operating system have not made changes
to the on-disk structure of the NTFS file system, but have utilised more features that were previously unused
and therefore generally unknown.

NTFS v1.0-v1.1
NTFS was first released with the Windows NT 3.1 operating system in July 1993. There were two early
versions of NTFS, which are largely ignored as they are incompatible with v1.2 and were not in common
use due to the low uptake of Windows NT at that time.

NTFS v1.2
NTFS v1.2 is considered the first major version of NTFS. It was released with Windows NT 3.51 operating
system in May 1995. NTFS v1.2 became more common due to the prevalence of the Windows NT 3.51
and Windows NT 4 operating systems. NTFS v1.2 supported compressed files, alternate data streams,
and used access control lists for security. The NTFS v1.2 file system is sometimes incorrectly referred to
as NTFS 4.0 - the "4.0” actually refers to the version of the file NTFS.sys, which is the NTFS driver inside
the operating system.
 NTFS v3.0
The second major version of NTFS, v3.0, was released with Windows 2000 operating system in February
2000. This version greatly expanded administrative controls through disk quotas, encryption and reparse
points. It added resilience through journaling writes to the file system, and restructured file security to make
it more efficient. The version of NTFS driver was NTFS.sys 5.0.

NTFS v3.1
There has been a minor change to the file system, NTFS v3.1, which was released with Windows XP in
August 2001. This version added some information to the file system to make it easier to recover damaged
data. The NTFS driver version was NTFS.sys 5.1.

With the release of the Vista and Windows 7 operating systems, NTFS structure was unchanged. There
were changes in what on disk data survived a full format, and partition resizing was added. However, this
was additional functionality that was given to the operating systems through upgraded NTFS driver.
Windows Vista used NTFS Driver version NTFS.sys 6.0 and Windows 7 had NTFS.sys 6.1.

Windows 8 & 10, N T F S v3.1-80?

The release of new Windows OS versions has seen some minor changes. The on-disk area where the
version number of NTFS is written has been changed to v3.1.80, where it previously was v3.1. (This does
not occur when the format is part of the install process.) This change is an indication that the volume has
been modified by Check Disk. Windows is using new metadata files (parts of the NTFS file system) to
create more precise and faster data recovery processes, which reduces volume down time. The other
notable change is that if a volume is formatted with Windows 8+ graphical user interface (GUI), there is no
backward compatibility for the DOS 8.3 file name convention. The version of the NTFS driver in Windows
8 is NTFS.sys 6.2.

Windows 10 made some minor changes, related to the Encrypting File System (EFS) security in NTFS.
These changes have made it more difficult for forensic examiners to see the content of EFS encrypted files.

A forensic investigator should be aware of the version differences when interpreting data at the
hexadecimal level. The key difference between versions is the length and content of a File Record
Header. An understanding of how different operating systems utilise functions within the NTFS file
system will give additional clues of a volume’s interaction with multiple computers.

IV. NTFS Essentials

It is important to remember that Windows, and therefore NTFS, was designed for Intel based processors,
which use Little Endian byte ordering. Therefore, the least significant byte is read first in a group of bytes.

Data Structures
When working with NTFS, it can appear that a huge amount of information is all placed together, however,
it is actually organised in groups called “data structures”. Most values used within the NTFS structure are
signed integers, and can have a positive or negative decimal value.

When navigating data structures, the offset resets to zero (0) at the start of each different data
structure - the offset is relative to the start of the data structure being parsed.
 Everything is a File
An NTFS formatted partition does not have a reserved system area that is distinguished from a data area.
In NTFS, all data is stored in files, including system data. System data files are referred to as Metadata
Files. Metadata is loosely defined as “data about data”. Metadata files are what actually make up the
NTFS File System. They are files that are hidden to users on a live NTFS volume, and are not accessible
logically through the file system itself. The most important metadata file in an NTFS volume is the Master
File Table ($MFT). NTFS uses the $MFT to track and store all information about every file within the volume
- including itself. NTFS uses additional metadata files to track storage space allocation, security issues,
accessibility permissions, quota functions, journaling and encryption.

V. Volume Boot Record

Like all other Microsoft file systems, the first sector of an NTFS formatted volume contains a Volume boot
record. The Volume Boot Record (VBR) is actually a system file called $Boot, and the first 16 sectors of
the volume are allocated to it. The $Boot file serves the same purpose as other VBR, in that it contains
vital volume and file system parameters, pointers to file system components, and computer boot (bootstrap)
code. The key entries in the $Boot indicate the cluster size, the size of the volume, the location of the
Master File Table, and the location of the back-up copy of the Master File Table. The VBR is so important
that a second copy is located at the end of the volume. Figure 1 gives the data structure of the first 512
bytes of the $Boot file.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 3 Jump Instruction Jump instruction to Boot Code Field
0x03 3 8 OEM ID ASCII - NTFS
OxOB 11 2 B y te s per Se cto r T hese tw o fie ld s c o m b in e d p ro v id e C lu s te r
0x0 D 13 1 S e c to rs per C luste r s iz e
OxOE 14 2 Reserved sectors 0x00
0x10 16 5 Not used by NTFS Must be 0x00
From Windows Server 2003, this field is not used
0x15 21 1 Media Descriptor
- always 0xF8
0x16 22 2 Not used by NTFS Must be 0x00
0x18 24 4 Not used by NTFS Legacy BPB information
0x1C 28 4 Hidden Sectors Sectors before start of Volume
0x20 32 4 Not used by NTFS Must be 0x00
0x24 36 4 Not currently used by NTFS Always 0x80 00 80 00
Total S e c to rs on the
0x28 40 8 V o lu m e S ize
volum e
0x30 48 8 $ M F T starting extent L o g ic a l C lu s te r N u m b e r (LC N ) fo r M a s te r F ile
0x38 56 8 $MFTMirr starting extent T able a n d M a s te r F ile T able M ir r o r
Positive value = clusters per record
C lu ste rs per $ M F T
0x40 64 1 Negative value = Record size in bytes,
Record.
2 raised to the absolute value of x
0x44 68 1 Clusters per Index Buffer Size of Index Buffer
0x48 72 8 Volume Serial Number
0x50 4 Checksum Boot Sector Checksum
0x54 84 426 Bootstrap Code Boot-strapping instructions
0x1 FE 510 2 Boot Signature 0x55 OxAA
Figure 1 - $Boot Data Structure (first 512 bytes)
Much of the information within the $Boot file is legacy and not required by a computer to mount the volume
or for a forensic examination. The key values are shown in bold in the table Figure 1.
 Figure 2 shows an entire $Boot sector, with the translated values provided below.

J SBoot 8.152 13/12/2012 12:24:00 13/12/2012 12:24 00 13/12/2012 12:24:00 13/12/2012 12:24:00

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F /j Al -~v )
00000000 gB 52 90 4E 54 46 53 20 20 20 20 00 02 08 00 00 eR NTFS
00000010 00 00 00 00 00 F8 00 00 3F 00 FF 00 00 08 00 00 0 ? y
00000020 00 00 00 00 80 00 80 00 FF FF 7C 00 00 00 00 00 1 1 yy |
00000030 00 00 04 00 00 00 00 00 02 00 00 00 00 00 00 00
00000040 F6 00 00 00 01 00 00 00 45 B1 C4 3A F6 C4 3A FA o E±A:oA:u
00000050 00 00 00 00 FA 33 CO 8E DO BC 00 7C FB 68 CO 07 U3AIDM |uhA
00000060 IF IE 68 66 00 CB 88 16 OE 00 66 81 3E 03 00 4E hf El f > N
00000070 54 46 53 75 15 B4 41 BB AA 55 CD 13 72 OC 81 FB TFSu 'A»^Ui r u
00000080 55 AA 75 06 F7 Cl 01 00 75 03 E9 DD 00 IE 83 EC U§u ^A u eV li
00000090 18 68 1A 00 B4 48 8A 16 OE 00 8B F4 16 IF CD 13 h 'HI 16 I
OOOOOOAO 9F 83 C4 18 9E 58 IF 72 El 3B 06 OB 00 75 DB A3 IIA IX ra; uU£
OOOOOOBO OF 00 Cl 2E OF 00 04 IE 5A 33 DB B9 00 20 2B C8 A. Z3U1 +E
ooooooco 66 FF 06 11 00 03 16 OF 00 8E C2 FF 06 16 00 E8 fy lAy e
000000D0 4B 00 2B C8 77 EF B8 00 BB CD 1A 66 23 CO 75 2D K +Ewi, »i f#Au-
000000E0 66 81 FB 54 43 50 41 75 24 81 F9 02 01 72 IE 16 f uTCPAu$ u r
000000F0 68 07 BB 16 68 52 11 16 68 09 00 66 53 66 53 66 h » hR h fSfSf
00000100 55 16 16 16 68 B8 01 66 61 OE 07 CD 1A 33 CO BF U h, fa 1 3Ad
00000110 OA 13 B9 F6 OC FC F3 AA E9 FE 01 90 90 66 60 IE ‘6 ii6§eh f'
00000120 06 66 A1 11 00 66 03 06 1C 00 IE 66 68 00 00 00 fi f fh
00000130 00 66 50 06 53 68 01 00 68 10 00 B4 42 8A 16 OE fP Sh h *B1
00000140 00 16 IF 8B F4 CD 13 66 59 5B 5A 66 59 66 59 IF lot fY[ZfYfY
00000150 OF 82 16 00 66 FF 06 11 00 03 16 OF 00 8E C2 FF 1 fy lAy
00000160 OE 16 00 75 BC 07 IF 66 61 C3 A1 F6 01 E8 09 00 uW faAio e
00000170 A1 FA 01 E8 03 00 F4 EB FD 8B FO AC 3C 00 74 09 iu e 6eyl6->< t
00000180 B4 OE BB 07 00 CD 10 EB F2 C3 OD OA 41 20 64 69 » i eoA A di
00000190 73 6B 20 72 65 61 64 20 65 72 72 6F 72 20 6F 63 sk read error oc
000001A0 63 75 72 72 65 64 00 OD OA 42 4F 4F 54 4D 47 52 curred BOOTMGR
000001BO 20 69 73 20 63 6F 6D 70 72 65 73 73 65 64 00 OD is compressed
000001C0 OA 50 72 65 73 73 20 43 74 72 6C 2B 41 6C 74 2B Press Ctrl+Alt+
00000 IDO 44 65 6C 20 74 6F 20 72 65 73 74 61 72 74 OD OA Del to restart
OOOOOIEO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001F0 00 00 00 00 00 00 8A 01 A7 01 BF 01 00 00 55 AA 1 § d U3
Figure 2 - SBoot (first sector)

Figure 2 shows the first sector of a SBoot file, which is translated as:

OEM ID-NTFS. • $MFTMirr Start Cluster - 0x02.

Bytes per Sector - 0x200 = 512. • $MFT Record size -0xF6 (-10)
Sectors per Cluster - 0x08. 210 = 1024 bytes.
Hidden Sectors - 0x800 (2048). • Clusters per Index Buffer - 0x01.
Total Sectors 0x7CFFFF (8,191,999). • Serial Number - FA3AC4F63AC4B145.
$MFT Start Cluster - 0x040000 (262144).

In Windows, the Volume Serial Number is only partially displayed. If the command “vol” was entered at the
command prompt, the Volume Serial Number would be shown as “3AC4-B145” for the volume boot record
shown in Figure 2.
 NTFS uses the Master File Table to track every file within the volume. It does this by having (at least) one
entry for each file, called a File Record, which is given a unique number. The first file record listed in the
$MFT is for the $MFT itself, which describes its location and size on the NTFS volume. Therefore, the
$MFT needs to be processed in order to know its own size and location on the disk. All files on an NTFS
volume, including the root directory, have a record entry in the $MFT describing their size and location in
the same manner. The $MFT is so crucial to the system that a backup copy of the first four records is
stored in the $MFTMirr, which is the second file entry in the $MFT. Normally, 12% of the volume is reserved
for the $MFT. On a volume containing an operating system, it is very common for the $MFT to become
badly fragmented. Should that volume be reformatted, parts of the previous $MFT may be located in
Unallocated Space.

Within the $MFT, files and directories (folders) are treated in the same manner. Hence, file system
files, user files, and all directories are considered “files” - to NTFS, everything is a file.

The first 26 file entries in the Master File Table are metadata files. These metadata files have different
roles within the NTFS, and are listed within the $MFT in the order shown in Figure 3.

Metadata File Name Record Purpose of the File

Master File Table SMFT 0 Contains a record of every file on the volume
MFT Mirror SMFTMirr 1 Contains a backup of the first four records of the MFT
Log File SLogFile 2 Used for recovery in the event of a corrupt file system
Volume SVolume 3 Volume information - volume label, NTFS version & flags
Attribute Definitions SAttrDef 4 Lists attribute names, numbers, and descriptions
Root File Name
5 The root directory (also referred to as the root index)
Index
Cluster Bitmap SBitmap 6 Representation of allocated and unallocated clusters
Boot Sector $Boot 7 Boot sector and additional bootstrap loader code (VBR)
Bad Cluster File SBadClus 8 Sparse file that contains bad clusters in the volume
Security File Index of unique security settings which can be applied to files
SSecure 9
within a volume
Upper case Table SUpCase Converts lowercase characters to matching Unicode uppercase
10
characters
Extended Attributes Directory that contains optional extensions: SObject ID, SQuota,
SExtend 11
(EA) SReparse, SRepair, and $USN Journal
12-15 Reserved for future use
16-23 Unused
Quota SQuota 24 $Extend\$Quota - Tracks file quotas. Unused until NTFS 5.0.
Records users rights on disk space usage
Object Identifier $Extend\$Objld - Index of all unique IDs given to files and
SObjld 25
directories within the volume
Reparse SReparse 26 $Extend\$ Reparse - An index of all reparse points in the
volume.
Figure 3 - Metadata Files
 The Master File Table lists each file in individual entries called File Records. Every file record has its own
record number, which is used as an identification number for the file that the file record refers to. As files
are added to the volume, a record for each file is added in sequential order within the $MFT. If a file is
deleted, the file record that was used to track that file becomes unused; the $MFT will reuse “deleted”
records before creating new records. As a result, “deleted" MFT records can be over-written very quickly.

Currently, the length of each record in the $MFT is 1024 bytes. This value is found in the boot sector, and
may change with a future revision of NTFS. File records have a variety of specific data structures that are
used to contain information about a file and the file data itself.

A File Record is divided into separate blocks of data that contain information about the file record itself, and
the file or directory to which that file record points to. Information about the file record itself is stored in
what is called the “File Record Header". Information about the file or folder is stored in discrete blocks
called “Attributes”. Each attribute stores a certain type of information about the file.

The signature (beginning) of a file record is “FILE"; the end a File Record’s content is marked with OxFF FF
FF FF.

The structure of the Master File Table and the structure of an individual File Record could be visualized as
shown in Figure 4.

Master File Table

File Record 2
A
FILE
File Record 0
(1024 bytes)
FILE
File Record 1
(1024 bytes)
1024
FILE
File Record 2 bytes
(1024 bytes)
FILE
File Record 3
(1024 bytes)
FILE
File Record ... k v
(1024 bytes)
Figure 4 - $MFT & File Record Structures
 File Record Header
Every file record begins with a record header, which provides information about that record. One of the
significant differences between NTFS revisions is the size of record header. In NTFS v1.x, a file record
header is 48 bytes in length. In NTFS v3.x, the file record header is 56 bytes in length. The additional
information in NTFS v3.x is the file record’s own $MFT record number, which is useful when analysing a
“recovered” file record. The data structure of a file record header is provided in Figure 5.

Offset Length
Data Description
Hex Dec (bytes)
0x00 0 4 Signature FILE (or BAAD if fix-up error detected)
0x04 4 2 Offset to fix up array Byte offset to locate fix up values
0x06 6 2 Entries in the fix up Array Number of 2-byte entries in fix up Array
0x08 SLogFile Sequence
8 8 Transaction entry number in SLogFile
Number
0x10 16 2 Sequence count Count of times record has been “deleted”
0x12 18 2 Hard Link count Count of file name attributes
0x14 20 2 Offset to the first attribute Length of Record Header
Allocation status flags 0x00 = Deleted File, 0x01 = Allocated File. 0x02 =
0x16 22 2 Bit 0 = Allocated status Deleted Directory,
Bit 1 = Directory status 0x03 Allocated Directory.
Logical size of $MFT
0x18 24 4 How many bytes are used in the file record
Record
Physical size of $MFT
0x1 C 28 4 Length of Record in Bytes
Record
File reference to base
0x20 32 8 Used when Record is longer than one SMFT entry
record
Next attribute identificationCount of attributes in record - includes deleted
0x28 40 2
attributes
0x2a 42 - Fix-up Array and attributes NTFS 3.0
0x2c 44 4 $MFT File Record Number NTFS 3.1 +
0x30 48 - Fix-up Array and attributes NTFS 3.1 +
Figure 5 - File Record Header Data Structure

Every File Record in the $MFT starts with the Signature “FILE”. This is used as a search term by automated
forensic tools to recover “lost" files and folders.

F ix -u p A r r a y

An error checking “feature” that is used by NTFS to detect single sector corruption or failure. To do this, a
“check” value is generated, which is two bytes long. The “check” value is written to the last two bytes of
each sector in that file record, and is the first entry in the fix-up array. The values that would normally be
at the end of each sector (but have been replaced with the “check” value) are written into the fix-up array
in respective order immediately after the “check” value. On a volume with a sector size of 512 bytes, and
a file record size of 1024 bytes, the fix-up array will have three entries; the “check" value and the “original"
values from offsets 0x01 FE, 0x01 FF (510, 511) and 0x03FE, 0x03FF (1022, 1023).

When manually parsing through an $MFT File Record, it is important to exchange the check value
with the fix-up values. NTFS automatically does this in the background when the volume is
mounted. The fix-up values are changed regularly; It appears that each time a file record is read by
the file system the fix-up values are checked and then changed.
 If the check value does not match, this would indicate an error within that file record. The signature “FILE"
may be changed to “BAAD” (Windows XP), and/or the entry will be ignored by the file system. In Windows
8, the entry will be deleted.

$LogFile Sequence Number

A logical sequence number that identifies the record written to the SLogfile for the last NTFS transaction
relating to that file record. NTFS maintains a log to allow for recovery if there is, for example, a power
failure part way through a transaction. The log allows the incomplete transaction to be undone, thus
restoring the file system to a healthy state. The SLogFile will only recover the file system data, not the
actual content of the file. It works by writing the changes to the SLogFile before making the changes to
NTFS metafiles. A transaction would be considered complete when the change is actually written to the
disk from the Disk Cache (disk write caching is a process of storing writes to disk in flash memory to improve
performance). A more detailed explanation of the SLogFile is provided later in this manual.

Sequence Count
The Sequence Count shows the number of times a File Record entry has been used. When the SMFT file
is created, every sequence value is set to 0x01. The sequence count then increments each time the record
is marked as unused in the SMFT - in other words, it is incremented when the file is deleted. This count
restarts at 0x01 when it progresses past OxFFFF (65,535).

Next Attribute Identification

The identification number that will be given to the next attribute that is written to the File Record. This
number is incremental only, therefore is a “count" of all attributes that have been written to the File Record
for this file. The count includes current and previous attributes, as attributes that are no longer required
will be deleted.

File Reference to Base Record

Sometimes, a single entry in the SMFT is not enough to contain all the information about a single file,
generally when a file becomes very fragmented. There is only one Record in the SMFT that is used to
actually reference the file, which is called the “Base Record”. The remaining entries that store the extended
information are called “Extension Records”. An extension record has the SMFT number of the base record
in the header. If the File Reference Address to Base Record value is zero, then it is the base record.

$M FT File Record Number

The additional entry in a NTFS v3.1 File Record Header is its own SMFT File Record Number. This is very
useful for forensic examiners when analysing old SMFT records that have been recovered.

It is important to note that the information in the File Record relates only to the current file it
references. When an SMFT record is reused, all unused areas (record slack) are over-written with
0x00. Therefore any file record slack can only relate to one file.

An example of a file record header is shown in Figure 6.

 Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 46 49 4C 45 30 00 03 00 EB 49 00 03 00 00 00 00 FILE0 ël
00000010 01 00 01 00 38 00 01 00 70 02 00 00 00 04 00 00 8 P
00000020 00 00 00 00 00 00 00 00 05 00 00 00 23 00 00 00 #
00000030 14 00 6E 63 00 00 00 00

Figure 6 - File Record Header, NTFS v3.1

Figure 6 shows the File Record Header for the file "01 Resident Content.txt”, which is located on the first
partition on BCFE NTFS.vhd. Please use WinHex to fill in the blanks below:

• Signature - • File Reference - 0 (Base record).

• SLogFile Sequence # - 0x30049EB (50,350,571 ) • Fix-up check value -

• Sequence Count - • Fix-up value Sector 1 -

• Allocation Flag - • Fix up value Sector 2 -

• Logical Size - • MFT Record -

• Physical Size - • Next Attribute Id - 0x05.

 The $MFT stores information about each file within the file record, contained within “Attributes” which
immediately follow the file record header. Attributes come in different types and contain different
information about the file, or the file content itself. Attributes have their own data structure, which comprise
of headers and content.

A visual representation of the internal structure of an attribute is shown on the right in Figure 7. The attribute
headers and content are all discrete blocks of data and have to be interpreted individually to determine
what information the attribute hold about the file. The content of each attribute varies in length; in some
instances, the content of an attribute may not be within the attribute, due to the limited size of an $MFT file
record - as depicted by the third attribute in Figure 7. When this occurs, only the Attribute Headers are
contained within the File Record, and the Attribute Content is written to another part of the volume.

M aster File Table File R e co rd 2

FILE
File Record 0 File Record Header
(1024 bytes)
| Attribute Headers
FILE
File Record 1
Attribute Content
(1024 bytes)

FILE 1024
File Record 2 ' Attribute Headers
bytes
(1024 bytes)
Attribute Content
FILE
File Record 3
(1024 bytes)
Attribute Headers
F IL E

File Record ...

FF FF FF
(1024 bytes)
V

Figure 7 - $MFT & File Record Structures

 Every attribute begins with a 16-byte header that contains information about the attribute itself. This
includes the attribute identifier, the entire length of the attribute, whether the content of the attribute is
resident or non-resident, and information about the stream name (if used). The data structure of an
attribute header is provided in Figure 8.

Offset Length
Name Description
Hex Dec (bytes)
0x00 0 4 Attribute Type Identifier
0x04 4 4 Length of the attribute Length in bytes
0x08 8 1 Content Non-Resident Flag 0x00 = Resident, 0x01 = Non-resident
Length of the “stream”
0x09 9 1 Number of Unicode characters
name
OxOA 10 2 Offset to the “stream” name From beginning of Attribute
0x0001 Compressed,
OxOC 12 2 Flags 0x4000 Encrypted,
0x8000 Sparse
OxOE 14 2 Attribute Identifier In sequential order Attribute added
Figure 8 - Attribute Fleader Data Structure

Figure 9 shows an attribute header that doesn’t contain a stream name - a detailed explanation of a named
stream (Alternate Data Stream) is given later in this manual.

Offset 0 1 2 3 4 5 6 7 8 9 À B c D E F
00000000 10 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00 '+

Figure 9 - Attribute Header

The Attribute Header in Figure 9 is translated as:

• Attribute Type Id- 0x10 00 00 00. • There is no stream name.

• Attribute Length - 0x0060 (96 bytes). • Flags - 0x00 = not set.
• Resident Flag - 0x00 = Content resident. • Attribute Identifier - 0x00 = first attribute added to
File Record.
 Currently, each $MFT file record is only 1024 bytes long, and is therefore constrained in the amount of
information that it may contain. If there is too much information, parts may be moved to another area of
the volume. This introduces the concept of what is known as “Resident” and “Non-Resident” Attributes.
An attribute is said to be “Resident" if the content of that attribute is contained entirely in the $MFT record.
The more correct terminology would be a “Content Resident Attribute”, but is generally referred to as a
“Resident Attribute”. The distinction is that the Headers of every attribute will always be contained
within the $MFT, but the content may not be.

If the content of an attribute is resident, there is a Resident Header data structure after the Attribute Header.
The Resident Header contains the length of the resident data and the offset to the data - relative to the
start of the attribute. Figure 10 shows the offsets and data found in a resident attribute’s header.

Offset Length Name Description

Hex Dec (bytes)
0x00 0 16 Attribute Header See Table in Figure 8
0x10 16 4 Size of the content Attribute Content size in bytes
0x14 20 2 Offset to the content Offset relative to start of attribute in bytes
Figure 10 - Content Resident Header

Figure 11 shows a content resident attribute that does not have a stream name.

O ffse t 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 10 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00 +
00000010 J 48 00 00 00 18 00 00 00 59 00 32 DB 73 DA C C 01 H t Y 2Û sO Î
00000020 14 4B 2 k EF 73 DA C C 01 14 4B 2A E F 73 DA C C 01 < TK*ï s 0 Î <T K *ïsO Ï
00000030 ID C F B7 E0 73 DA C C 01 20 00 00 00 00 00 00 00 Ï •à s Ü Ï
00000040 00 00 00 00 00 00 00 00 00 00 00 00 08 01 00 00
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Figure 11 - Content Resident Attribute, no stream name

The Attribute Header and Content Resident Headers in Figure 11 are translated as:

Attribute Header Content Resident Header

• Attribute Type Id - 0x10 00 00 00. • Size of Content - 0x48 (72 bytes).
• Attribute Length - 0x0060 (96 bytes). • Offset to Content - 0x18 (24 bytes).
• Resident Flag - 0x00 = Content resident.
• There is no stream name. Attribute content is Highlighted.

Attribute with Non-Resident Content

It is possible for the content of any attribute to grow to the point where it is too large to fit within the limitation
of the $MFT file record size. In this situation, the content is saved else-where on the volume and is
commonly referred to as a “Non-resident attribute”. The attribute header remains in the $MFT file record,
so only the content is non-resident. For the purpose of teaching NTFS concepts, the content non-resident
attribute data structure will be discussed after the $Data attribute, as this is the most common attribute to
have non-resident content.
 Attributes come in a variety of different types and contain information about different aspects of the file -
the attribute content. A file record will contain a variety of attribute types, depending on the file or directory
status. Figure 12 contains a list of the attributes and their names in order of the attribute identifier. Each
attribute type has a unique data structure for its content, and most can have their content non-resident.

Attribute Identifier Attribute Name Description

C o n ta in s F ile p e rm is s io n s , tim e s ta m p s , s e c u rity ,
10 00 00 00 $Standard_lnformation
a n d a d m in is tra tiv e in fo rm a tio n - a lw a y s re s id e n t
Locations o f all attributes that do not fit in a single file
20 00 00 00 $Attribute_List
record entry
30 00 00 00 $File_Name The n a m e o f th e file - a lw a y s re s id e n t
40 00 00 00 $Volume_Version Volume Version (NTFS v1.x only)
Contains a Globally Unique Identifier (GUID - unique
40 00 00 00 $Object_ ID
16-byte identifier) for the file (NTFS v3.x)
Access control and security properties of the file
50 00 00 00 $Security_Descriptor
(Metadata files only in NTFS v3.x)
These two attributes are only used in the SVolume
60 00 00 00 $Volume_Name
metadata file and contain the volume label and NTFS
70 00 00 00 $Volume_lnformation version information
80 00 00 00 SData The a c tu a l f ile ’s data or p o in te r s to th e f ile ’s data
The top-level entry of a sorted tree that lists a directory’s
90 00 00 00 $lndex_Root
child files - always resident
Points to the location of the Index Buffers of a large
A0 00 00 00 $lndex_Allocation
directory
Tracks the allocation status of a location or an entity,
B0 00 00 00 SBitmap
dependant on file record entry type
CO 00 00 00 $Symbolic_Link Soft link information (NTFS v1.2)
CO 00 00 00 $Reparse_Point Similar to a soft link (NTFS v3.x)
DO 00 00 00 $EA_lnformation Allows compatibility with HPFS
E0 00 00 00 $EA Allows compatibility with HPFS
Contains information and keys for encrypted attributes
00 01 00 00 $Logged_Utility_Stream
(NTFS v3.x)
Figure 12 - Attribute Types

The NTFS BCFE Class concentrates on the $Standard_lnformation, $File_Name and $Data attributes,
which are always used by a file. Details of the remaining attributes are included in the manual for reference.
X. $Standard Information Attribute - 0x10
A standard information attribute exists for each file record and folder (directory) record. The main
information in this attribute is the file time stamps. In addition, there is security and accessibility information
such as DOS type attributes. The data structure is shown in Figure 13, and the content is always resident
within the File Record.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 4 Attribute Type Identifier 0x10 00 00 00
0x04 4 4 Length of the attribute Length in bytes
0x08 8 1 Content Non-Resident Flag 0x00 = Resident, 0x01 = Non-resident
0x09 9 1 Length of the stream name Num ber o f Unicode characters
OxOA 10 2 Offset to the stream name From beginning o f Attribute
OxOC 12 2 Flags Compressed, Sparse, Encrypted
OxOE 14 2 Attribute Identifier In sequential order Attribute added
"0x1 Ö ' ' T6“ 'Size o f tfrecontenT ~7\ttribu7e~Content size~m b yie s~
0x14 20 2 Offset to the content O ffset from start o f attribute in bytes
Stream Name If applicable
0x00 0 8 Create time Date/Time file created on volume
0x08 8 8 File modified time Date/Time file content changed
0x10 16 8 $MFT modified time Date/Time SMFT content changed
0x18 24 8 Last accessed time Date/Time file accessed
0x20 32 4 File type Flags See Table in Figure 14
0x24 36 4 Maximum number of versions Max versions allowed - 0x00 = disabled
0x28 40 4 Version number This file's version
0x2C 44 4 Class ID
0x30 48 4 Owner ID Owner ID for quota
(version 3.0 +) Reference into SSecure which
0x34 52 4 Security ID
is an index of permission settings
0x38 56 8 Quota Charged (version 3.0 +) Bytes from user’s quota
Update sequence number
0x40 64 8 (version 3.0 +) Index to $USN Journal
(USN)
Figure 13 - $Standard_lnformation Attribute data structure

The red box around the top seven rows is the Attribute Header data structure, which is the same for every
attribute. The green box around the next two rows is the Resident Content Header data structure, which
is the same for every attribute with resident content. The remaining rows are the data structure for the
$Standard_lnformation Attribute content.

Note that the offset restarts at zero (0x00) for the content data structure, as it is considered a
separate entity from the Headers.

The file type flags use packed bytes, where each bit is a flag. Therefore, the flags can be any combination
of the above; for example, a file can be Read Only and Hidden. Using the table in Figure 14, this would
translate to a file type flag value of 0x0003.
 Hex Binary Description
0x0001 0000 0000 0000 0001 Read only
0x0002 0000 0000 0000 0010 Hidden file
0x0004 0000 0000 0000 0100 System file
0x0020 0000 0000 0010 0000 Archive
0x0040 0000 0000 0100 0000 Device
0x0080 0000 0000 1000 0000 Normal
0x0100 0000 0001 0000 0000 Temporary
0x0200 0000 0010 0000 0000 Sparse file
0x0400 0000 0100 0000 0000 Reparse point
0x0800 0000 1000 0000 0000 Compressed file
0x1000 0001 0000 0000 0000 Offline
0x2000 0010 0000 0000 0000 Content not indexed
0x4000 0100 0000 0000 0000 Encrypted
Figure 14 - File Type Flags

N T F S date and Time

NTFS stores date and times in what is called a “FILETIME” structure. FILETIME is a 64-bit unsigned value
representing the number of 100-nanosecond intervals since January 1, 1601 in Co-Ordinated Universal
Time (UTC). All file dates and times are written to the NTFS file system in UTC.
When the operating system (or a forensic tool) reads FILETIME, it will add (or subtract) from UTC in order
to display the local time zone, which is set by the user. This is the reason you may need to know the time
zone setting when viewing an image. If your forensic tool is not set to the same time zone as the imaged
evidential computer, the date/time displayed will be inaccurate.

Date and time Definitions

Created: When the file/directory was created on the volume.
File Modified: When the file content was changed (e.g. user accessible content).
SMFT Modified: When the content of the $MFT File Record was changed.
Last Accessed: When the file was accessed (by user, application, or system activity).

It is useful to be aware that since Windows Vista, the last accessed time is not updated by default apart
from Microsoft Office files, which is an unusual exception. It should also be noted that although Windows
XP updates last accessed time by default, a registry setting can be applied by the user to disable last
access time updates.

A $Standard_lnformation attribute is shown in Figure 15.

O ffse t 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 10 00 00 00 60 00 00 00 00 00 00 00 00 00 00 00 '
00000010 48 00 00 00 18 00 00 00 55 09 3F DO BF D8 CD 01 H U ?D 40i
00000020 CO B 1 B 1 EA 61 D8 CD 01 17 51 39 19 FD DB CD 01 A ±±ea0l Q9 y ü i
00000030 55 09 3F DO B F D8 CD 01 20 00 00 00 00 00 00 00 U ?D d0l
00000040 00 00 00 00 00 00 00 00 00 00 00 00 05 01 00 00
00000050 00 00 00 00 00 00 00 00 CO 12 00 00 00 00 00 00 A
Figure 15 - SStandard Jnformation Attribute

The $StandardJnformation attribute content in Figure 15 is from the file “01 Resident Content.txt”, which
is located on the first partition on BCFE NTFS.vhd. Please use WinHex to fill in the blanks below:

Header Content
Attribute Type -
Created -
Attribute Length -
File Modified -
Resident Flag -
$MFT Modified -
“Stream” name - no stream name.
Accessed -
Flags - 0x00 = not set.
Flags - Ox =
Attribute Identifier - 0x00
Security Id -0x0105 (261).
Size of Content -
USN - 0x12C0 (4800).
Offset to Content -

Every attribute immediately follows the previous attribute (or Record Header if it is the first Attribute),
and they will be written in the File Record in order of their Attribute Type Identifier.

Attributes will always start (and end) at a multiple of eight bytes from the start of the File Record.
To ensure this occurs, an attribute may contain padding after its content.
Similarly, an attribute’s content will begin on an eight-byte boundary - even if an attribute has a
stream name. There may be padding at the end of the stream name. This makes it easy to identify
and traverse attributes in a Hex Editor if the display width is set to 16 bytes.
 An $MFT file record is fixed in size; however, the amount of file metadata that is stored within a file record
often exceeds that size. When this occurs in the first instance, an attribute’s content may become non­
resident. However, not all attributes can have non-resident content. When there are many attributes in
use for a file and/or the mandatory content resident attributes are very large, there can be insufficient space
for the attribute headers within a single file record.

In this situation, an $Attribute_List attribute will be located in the base $MFT file record, and will provide
the $MFT file record number(s) that contain the remaining attributes for that file. The most common
example of this attribute is where a file has become so badly fragmented, the data runs will not fit into a
single $MFT file record. The content of the $Attribute_List attribute can be resident or non-resident and
the data structure is provided in Figure 16.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 16 Attribute Header Standard Attribute 16-byte header
0x10 16 8 Content Resident Header Content Resident 8-byte header
or
Content Non-Resident
0x10 16 Content Non - Resident header
Header
Stream Name If applicable
0x00 0 4 Attribute Type Attribute Type Identifier
0x04 4 2 Record Length Length of this list entry
0x06 Attribute Stream Name
6 1 Num ber o f Unicode characters
Length
0x07 7 1 Offset to Name From beginning o f Attribute Entry
0x08 8 8 Starting VCN in attribute Attribute with multiple data runs
0x10 16 8 $MFT File Record Reference $MFT record that contains attribute
0x18 24 2 Attribute Identifier
0x1A 26 - Attribute Stream Name If applicable
- Next Attribute entry Restart at 0x00 on 8-byte boundary
Figure 16 - $Attribute_List Attribute data structure

The data structure in the content area of Figure 16 is for an individual entry. There will be an entry in the
list for every attribute that is required for the file. Each entry will start on an eight-byte boundary.
 The file name attribute is used to store the file’s name. There may be more than one $File_Name attribute
in a single file record. The data structure of a $File_Name attribute is given in Figure 17.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 4 Attribute Type Identifier * 0x3000 00 5b ”
0x04 4 4 Length of the attribute Length in bytes

0x08 8 1 Content Non-Resident Flag 0x00 = Resident, 0x01 = Non-resident |

0x09 9 1 Length of the stream name Num ber o f Unicode characters I
OxOA 10 2 Offset to the stream name From beginning o f Attribute 1
OxOC 12 2 Flags Compressed, Sparse, Encrypted
[ 0x0 E 14 2 Attribute Identifier In sequential order Attribute added
0x10 16 4 Size of the content Attribute Content size in bytes
■ 0x14 20 2 Offset to the content O ffset from start o f attribute in bytes
Stream Name If applicable
$MFT Record number of the
0x00 0 6 Record for directory in which the file “resides"
parent directory
Sequence number of the
0x06 6 2 How many times parent record has been used
parent directory
0x08 8 8 File name creation time
Not reliable, only updated if file renamed or
0x10 16 8 File name modification time
moved (This only applies to $File_Name
0x18 24 8 $MFT modification time
attributes in the $MFT, not in INDX records)
0x20 32 8 Last access time
0x28 40 8 Allocated size of the index
Only if the record is an index
0x30 48 8 Actual size of the index
0x38 56 4 File type flags See Table in Figure 14
Used by Extended Attributes or Reparse type
0x3C 60 4 Reparse value
(mutually exclusive)
0x40 64 1 File name length Unicode characters
0x00 = POSIX, 0x01 = Win32 (LFN),
0x41 65 1 File name type (Namespace)
0x02 = DOS (SFN), 0x03 = Win32 & DOS
0x42 66 Varies File name
Figure 17 - $File_Name Attribute data structure

Parent $M FT Record
The file’s parent directory $MFT Record Number and sequence number are recorded to help build the
directory structure. This will be discussed in detail in the File Recovery section.
Time stamps
Besides simply storing the file name, the file name attribute contains a copy of the date and time stamps
contained in the standard information attribute. These dates and times relate to the file name attribute only,
not the file content.

Testing shows that they are only updated when the either the file name is changed, or the location
of the file is changed. (The parent $MFT Record and sequence numbers are updated).

File Name NameSpace

With various versions of Microsoft operating systems, the rules that apply for file names have changed. A
file name can be up to 254 characters long and contain mixed case letters. The file name can also contain
special characters, but there are some reserved characters (/ \ : * ? “ < > |.). This applies to Win32 and
POSIX file names. The difference between Win32 and POSIX file names is that POSIX recognises the
capitalisation - ‘Matt’ and ‘matt’ are two different file names and can co-exist in the same directory. A
Win32 file name will treat ‘Matt’ and ‘matt’ as the same file name and will not allow it to exist twice in the
same directory.

In early computing, file names had to be a short file name (SFN), which used the MS-DOS 8.3 rule; eight
capital letters for the name, a and three capital letters for the extension. NTFS allowed backward
compatibility for older applications by having multiple $File_Name attributes if a file name was not
compatible with MS-DOS. If a file name complied with 8.3 length conditions, but contained lower case
characters, it would be considered an MS-DOS com patible file name and would have the file name type
0x03. The conversion from lower-case to upper-case is done through the metadata file SUpCase.

When an MS-DOS compliant (SFN) is generated in NTFS, the first six characters of the LFN are used and
then a tilde (~) and number are appended to the name, and the same extension is used. Should a situation
occur where there are five or more files in the same directory with a LFN that result in the same or duplicate
SFN, the fifth and subsequent files will only have the first two letters of the long file name. The next four
letters of the SFN are generated by mathematically manipulating the remaining letters of the long file name.
“-1" is appended (or another number, if necessary, to avoid a duplicate file name) to the result.

Windows 8+
In a NTFS volume formatted with the Windows 8 or newer Graphical User Interface (NTFS v3.1-80), a file
with a long file name will only have a single $File_Name attribute, using POSIX namespace. The POSIX
namespace allows 254 characters, mixed case letters, and special characters. Windows 8 still has the
same reserved characters as a Win-32 LFN.
 Hard Links
Another reason for there to be multiple $File_Name attributes is a Hard Link. A hard link is a bit like a
Windows short-cut - except it isn’t! The hard link effectively allows a file to exist in more than one parent
directory, but there is only one copy of the actual file content. Each hard link is contained within its own
$File_Name attribute, containing its own file name and parent directory $MFT record details. The file is
only deleted when the last link is removed - the original $File_Name attribute may be deleted, but Hard
Link $File_Name attributes will mean the file will continue to exist. A file name attribute also contains some
redundant information including the allocated size and physical size; these are only used if it is an index.
A $File_Name attribute is shown in Figure 18.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 30 00 00 00 88 00 00 00 00 00 00 00 00 00 03 00 0 1
00000010 70 00 00 00 18 00 01 00 05 00 00 00 00 00 05 00 P
00000020 55 09 3F DO BF D8 CD 01 56 F2 E9 D6 74 D9 CD 01 U ?D20l VöeÖtÜi
00000030 56 F2 E9 D6 74 D9 CD 01 55 09 3F DO BF D8 CD 01 VöeÖtÜi U ?B¿0i
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000050 20 00 00 00 00 00 00 00 17 00 30 00 31 00 20 00 0 1
00000060 52 00 65 00 73 00 69 00 64 00 65 00 6E 00 74 00 Res i dent
00000070 20 00 43 00 6F 00 6E 00 74 00 65 00 6E 00 74 00 C o n tent
00000080 2E 00 74 00 78 00 74 00 . t X t

Figure 18 -$File_Name Attribute

The $File_Name attribute content in Figure 18 is from the file “01 Resident Content.txt”. Please use WinHex to fill
in the blanks below:
Content
Header
• Parent $MFT Record -
Attribute Type -
• Parent Sequence -
Attribute Length -
• Created -
Resident Flag -
• File Modified -
“Stream" name - no stream name.
• $MFT Modified -
Flags - 0x00 = not set.
• Accessed -
Attribute Identifier - 0x03
• Flags - Ox =
Size of Content -
• File Name Length -
Offset to Content -
• File NameSpace - Ox

• File Name =
 The $Object_ID attribute was introduced with Windows 2000 - 0x40 was previously the $Volume_Version
attribute. It contains information for tracking a files’ location history by using different GUIDs - if the file is
moved, it can still be located by its GUID. The data structure of the $Object_ID is given in Figure 19. This
attribute is commonly found since Windows 7, although it appears only the Object ID GUID entry is currently
used.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 16 Attribute Header Standard Attribute 16-byte header
Content Resident
0x10 16 8 Content Resident 8-byte header
Header
Stream Name If applicable
0x00 0 16 Object ID GUID Unique Id for file
0x10 16 16 Birth volume GUID Id of volume on which file was created
0x20 32 16 Birth Object GUID First object id assigned to this MFT record
0x30 48 16 Domain GUID ID of Domain in which file created
Figure 19 - SObjectJD Attribute data structure

An example of an $Object_ID attribute is given in Figure 20.

O ffs e t 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 40 00 00 00 28 00 00 00 00 00 00 00 00 00 04 00 @ (
00000010 10 00 00 00 18 00 00 00 4F 8A B6 EB FB 43 E2 11 01 ilëûCâ
00000020 AF A5 00 50 56 CO 00 08 —¥ PVÀ
Figure 20 - SO bject lD Attribute

The SObjectJd attribute content in Figure 20 is translated as:

Header C ontent
Attribute Type - 0x40 = Object Id. EBB68A4F-43FB-11E2-AFA5-005056C00008.
Attribute Length - 0x28 (40) bytes.
Resident Flag - 0x00 = Content resident. A GUID is broken into five separate blocks:
There is no “stream” name. 4 bytes - 2 bytes - 2 bytes - 2 bytes - 6 bytes. Blocks
Flags - 0x00 = not set 4 and 5 are big Endian.
Attribute Identifier - 0x09 = tenth attribute added.
Size of Content - 0x10 (16) bytes. Date: 12/12/2012, 01:33:24.
Offset to content - 0x18 (24) bytes. Clock Sequence: 12197.
MAC: 00-50-56-C0-00-08.

The GUID in the SObjectJd attribute is used to locate the file, even if the filename and/or path (saved
location) is changed. The first nibble in block 3 indicates the version number. A version 1 GUID is
generated from the date/time and MAC address of the source computer. This provides enormous forensic
value for tracing a file back to its source. If the first nibble in block 3 begins with a “4”, then the GUID is a
random number. For more information on GUID structure, see http://www.ietf.org/rfc/rfc4122.txt.
 The $Security_Descriptor attribute was widely used in NTFS v1.1 & v 1.2 to list the security settings for an
individual file. The content of the attribute would contain access control lists that would allow or deny users
access to the file. The problem with this method was that most permissions were the same, which was
inefficient when it came to reading them for every file access.
Since NTFS v3.0, this role has been taken by the Metadata file SSecure. SSecure is an index of types and
groups of permissions, which are given a unique code. The permission group is applied to the file through
the Security ID field in the $Standard_lnformation attribute. However, the $Security_Descriptor attribute is
still in use for NTFS Metadata and Reserved $MFT file records.

$Volume_Name Attribute 0x60

The name that is given to a volume - either at format or later - is the only content of the $Volume_Name
attribute. The volume name is stored in Unicode with a maximum length of 127 characters. This attribute
is only found in the $MFT record for SVolume metadata file.

$Volume_lnformation Attribute 0x70

The SVolumeJnformation attribute stores the NTFS version of the volume and its state. This attribute is
only found in the $MFT record for SVolume metadata file. Figure 21 provides the data structure for the
SVolumeJnformation attribute.

Offset Length
Name Description
Hex Dec (Bytes)
i 0x00 0 16 Attribute Header Standard Attribute 16-byte header
ii
Content Resident
1 0x10 16 8 Content Resident 8-byte header \
l Header
Stream Name If applicable
0x00 0 8 Unused 0x00
0x08 8 1 Major Version Number
0x09 9 1 Minor Version Number
0x0001 - Dirty
0x0002 - Resize SLogFUe
0x0004 - Upgrade volume next mount
OxOA 10 2 Flags 0x0008 - Mounted in NT
0x0010 - Deleting USN journal
0x0020 - Repair Object Ids
0x8000 - Modified by check disk
Figure 21 - SVolume Information Attribute data structure
 The data attribute simply contains the data (content) of the file, or pointers to where the data is located on
the volume. All other attributes are used to define properties of a file. This attribute - whether the content
is resident or non-resident - is the file data itself. The file system is designed to locate the file content at
the request of the operating system or an application, and protect that content from corruption and security
violations.

If the data attribute content is resident, we only use the attribute header and the resident content header.
The resident content of the attribute is the file’s data. Only very small files have a resident data attribute;
typically, any file size over 600 bytes will become non-resident content. This is dependent on the file name
length, the number of $File_Name attributes and if there is an $Object_ld attribute. Figure 22 shows the
structure of a $Data attribute with resident content.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 4 Attribute Type Identifier 0x80 00 00 00
0x04 4 4 Length of the attribute Length in bytes
Content Non-Resident
0x08 8 1 0x00 = Resident, 0x01 = Non-resident
I Flag
Length of the stream
0x09 9 1 Num ber o f Unicode characters
I name
Offset to the stream
1 OxOA 10 2 From beginning o f Attribute
1 name
1 OxOC 12 2 Flags Compressed, Sparse, Encrypted
1 OxOE 14 2 Attribute Identifier In sequential order Attribute added
0x10 16 4 Size of the content Attribute Content size in bytes
: 0x14 20 2 Offset to the content O ffset from start o f attribute in bytes
Stream Name /
0x18 24 - File data
Attribute Content
Figure 22 - Attribute Header & Content Resident Header data structures
 Figure 23 shows a data attribute where the content is resident. The content of this attribute crosses a
sector boundary, which means that the two Check bytes will need to be replaced with the Fix-up values
from the File Record header.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 80 00 00 00 98 01 00 00 00 00 18 00 00 01
00 00 I I
00000010 7C 01 00 00 18 00 00 00 45 76 65 72
79 74 68 69 | Everythl
00000020 6E 67 20 69 73 20 61 20 66 69 6C 65
2E 0D 0A 45 ng is a file. E
00000030 76 65 72 79 20 66 69 6C 65 20 68 61
73 20 61 20 v e r y file has a
00000040 72 65 63 6F 72 64 20 69 6E 20 74 68 65 20 24 4D record in the $M
00000050 46 54 2E 0D 0A 0D 0A 45 76 69 64 65 6E 63 65 20 FT. Evidence
00000060 45 76 69 64 65 6E 63 65 20 45 76 69 64 65 6E 63 Evidence Evidenc
00000070 65 20 45 76 69 64 65 6E 63 65 20 45 76 69 64 65 e Evidence Evide
00000080 6E 63 65 20 45 76 69 64 65 6E 63 65 20 45 76 69 nee Evidence Evi
00000090 64 65 6E 63 65 20 45 76 69 64 65 6E 63 65 20 45 dence Evidence E
000000A0 76 69 64 65 6E 63 65 20 45 76 69 64 65 6E 63 65 v i d e n c e Evidence
000000B0 20 45 76 69 64 65 00 00 65 20 45 76 69 64 65 6E Evide e Eviden
ooooooco 63 65 20 45 76 69 64 65 6E 63 65 20 45 76 69 64 ce Evidence Evid
OOOOOODO 65 6E 63 65 20 45 76 69 64 65 6E 63 65 20 45 76 ence E v idence Ev
000000E0 69 64 65 6E 63 65 20 45 76 69 64 65 6E 63 65 20 idence Evidence
000000F0 45 76 69 64 65 6E 63 65 20 45 76 69 64 65 6E 63 Evidence Evidenc
00000100 65 20 45 76 69 64 65 6E 63 65 20 45 76 69 64 65 e Evidence Evide
00000110 6E 63 65 20 45 76 69 64 65 6E 63 65 20 45 76 69 nee Evidence Evi
00000120 64 65 6E 63 65 20 45 76 69 64 65 6E 63 65 20 20 dence Evidence
Figure 23 - Data Attribute, content resident

The $Data attribute content in Figure 23 is from the file “01 Resident Content.txt”, which is located on the first
partition on BCFE NTFS.vhd. Please use WinHex to fill in the blanks below:

Header ' Content

• Attribute Type - • File content.

. Attribute Length - _ A text file (*.txt)

• Resident Flag -

• “Stream" name - no stream name.

• Flags - 0x00 = not set.

• Attribute Identifier-0x01

• Size of Content -

• Offset to Content -
 A complete File Record can be found in Figure 24.
• Note the fix up values, and how they affect the data on disk. When the file record is read, the values
are automatically replaced by the NTFS file system driver. If check the values match, then the content
of offset 0x1 FE and 0x1 FF (510 and 511) is virtually replaced with 0x6E and 0x63 (nc) by the NTFS
driver before it is passed to the operating system.

• Note the $MFT slack at the end of the record.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 46 49 4C 45 30 00 03 00 2E 21 00 01 00 00 00 00 FILEO .!
00000010 01 00 01 00 38 00 01 00 70 02 00 00 00 04 00 00 8 p
00000020 00 00 00 00 00 00 00 00 05 00 00 00 23 00 00 00 #
00000030 OA 00 6E 63 00 00 00 00 10 00 00 00 60 00 00 00 nc
00000040 00 00 00 00 00 00 00 00 48 00 00 00 18 00 00 00 H
00000050 55 09 3F DO BF D8 CD 01 CO B1 B1 EA 61 D8 CD 01 U ?D60i A±±ea0i
00000060 56 F2 E9 D6 74 D9 CD 01 55 09 3F DO BF D8 CD 01 VoeOtUi U ?D60i
00000070 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000080 00 00 00 00 05 01 00 00 00 00 00 00 00 00 00 00
00000090 60 07 00 00 00 00 00 00 30 00 00 00 88 00 00 00 0 1
OOOOOOAO 00 00 00 00 00 00 03 00 70 00 00 00 18 00 01 00 P
000000B0 05 00 00 00 00 00 05 00 55 09 3F DO BF D8 CD 01 U ?D60i
ooooooco 56 F2 E9 D6 74 D9 CD 01 56 F2 E9 D6 74 D9 CD 01 VoeOtUi VoeOtUi
000000D0 55 09 3F DO BF D8 CD 01 00 00 00 00 00 00 00 00 U ?©c0l
OOOOOOEO 00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00
000000F0 17 00 30 00 31 00 20 00 52 00 65 00 73 00 69 00 0 1 R e s i
00000100 64 00 65 00 6E 00 74 00 20 00 43 00 6F 00 6E 00 d e n t C o n
00000110 74 00 65 00 6E 00 74 00 2E 00 74 00 78 00 74 00 t e n t . t x t
00000120 40 00 00 00 28 00 00 00 00 00 00 00 00 00 04 00 @ (
00000130 10 00 00 00 18 00 00 00 4F 8A B6 EB FB 43 E2 11 OlfeuCa
00000140 AF A5 08 00 27 94 AB DE 80 00 00 00 20 01 00 00 ~¥ '1«b1
00000150 00 00 18 00 00 00 01 00 07 01 00 00 18 00 00 00
00000160 45 76 65 72 79 74 68 69 6E 67 20 69 73 20 61 20 Everything is a
00000170 66 69 6C 65 2E OD OA 45 76 65 72 79 20 66 69 6C file. Every fil
00000180 65 20 68 61 73 20 61 20 72 65 63 6F 72 64 20 69 e has a record i
00000190 6E 20 74 68 65 20 24 4D 46 54 2E OD OA OD OA 45 n the $MFT. E
000001A0 76 69 64 65 6E 63 65 20 45 76 69 64 65 6E 63 65 vidence Evidence
000001B0 20 45 76 69 64 65 6E 63 65 20 45 76 69 64 65 6E Evidence Eviden
000001C0 63 65 20 45 76 69 64 65 6E 63 65 20 45 76 69 64 ce Evidence Evid
000001D0 65 6E 63 65 20 45 76 69 64 65 6E 63 65 20 45 76 ence Evidence Ev
000001E0 69 64 65 6E 63 65 20 45 76 69 64 65 6E 63 65 20 idence Evidence
000001F0 45 76 69 64 65 6E 63 65 20 45 76 69 64 65 OA 00 Evidence Evide
00000200 65 20 45 76 69 64 65 6E 63 65 20 45 76 69 64 65 e Evidence Evide
00000210 6E 63 65 20 45 76 69 64 65 6E 63 65 20 20 45 76 nee Evidence Ev
00000220 69 64 65 6E 63 65 20 45 76 69 64 65 6E 63 65 OD idence Evidence
00000230 OA 75 73 70 65 63 74 73 20 66 6F 72 20 6F 66 66 uspects for off
00000240 65 6E 63 65 20 61 72 65 3A OD OA 41 6C 61 6E 2C ence are: Alan,
00000250 OD OA 44 6F 6E 6E 79 2C OD OA 47 65 72 72 79 2C Donny, Gerry,
00000260 OD OA 4D 61 72 6B 2C 20 FF FF FF FF 64 20 4D 61 Mark, yyyyd Ma
00000270 74 74 2E OD OA 00 00 00 FF FF FF FF 00 00 00 00 tt. yyyy
Figure 24 - Complete File Record

© 2017 IACIS NTFS Page 26 of 74

 A file record is fixed in size, and will have (at least) three attributes. Sometimes, the content of an attribute
is too large to fit the available space within a file record. When this occurs, the content of that Attribute is
moved to another part of the volume, and it is commonly called a “Non-Resident Attribute”. However, the
Attribute header remains in the File Record, and only the content is relocated so it is actually a Content
Non-Resident Attribute.

Once an attribute’s content is non-resident, it can never become resident again. That is to say, if
an attribute content grows too large to be contained in the $MFT record, even if it shrinks to a logical
size small enough to be resident, it remains a non-resident attribute. The exception is when an
NTFS volume is connected to a Linux OS, which will allow a non-resident attribute to become
resident again. This is due to how the NTFS driver has been configured on the Linux OS.

If the content of an attribute is non-resident, a Non-resident Content Header will immediately follow the
attribute header. The non-resident content header data structure shows where the attribute content is
located on the volume, (called data runs) and the content size. Figure 25 shows the data structure of non­
resident content header.

Offset Length
Name Description
Hex Dec (bytes)
i-oxDcr D 4 ÄUrTbüTeTypeTdentTTier
0x04 4 4 Length of the attribute Length in bytes
Content Non-Resident
0x08 8 1 0x00 = Resident, 0x01 = Non-resident |
Flag
Length of the stream
0x09 9 1 Number of Unicode characters I
name
I OxOA 10 2 Offset to the stream name From beginning of Attribute |
I OxOC 12 2 Flags Compressed, Sparse, Encrypted |
' OxOE 14 2 Attribute Identifier In sequential order Attribute added
t. _

; 0x10 16 8 Starting VCN of the run list Virtual Cluster Number (VCN) - relative to
j 0x18 24 8 Ending VCN of the run list start of data itself
i 0x20 32 2 Offset to the run list Bytes from start of Attribute
! 0x22 34 2 Used for compression
! 0x24 36 4 Unused
i 0x28 40 8 Allocated size Physical size of the content in bytes
: 0x30 48 8 Actual size Logical size of the content in bytes
; 0x38 56 8 Initialized size Initialized size of the content in bytes
Stream Name and/or Run
: - - ~
List
Figure 25 - Attribute Header & Content Non-Resident Header
 Virtual Cluster Numbering
When a volume is formatted, the sectors are combined into groups called Clusters. Each cluster is given
an address, relative to its location within the volume - this is called a Logical Cluster Number (LCN).
Clusters can also be viewed relative to a file. Every cluster allocated to a file is given a Virtual Cluster
Number (VCN), which is relative to its location within the file. Virtual cluster numbering "re-numbers” the
clusters containing the file.

Often large files are not able to be written contiguously (sequentially) in the volume. When this occurs, it
is fragmented or broken into different chunks (fragments) which are saved in separate areas of the volume.
The virtual cluster number assigned to cluster (LCN) that a file occupies allows the file to be reconstructed
in the correct order, regardless of the logical order of the file fragments.

This becomes more important in files that are very badly fragmented. It is not uncommon for a single File
Record to be too small to contain an entire run list of the actual file content. In this situation, there would
be additional $MFT File Records that would hold $Data attributes containing run lists. When these run lists
are parsed, it is imperative that we know which part of the file the run list is pointing to, so that it when we
put the file back together the fragments are placed in the right order, relative to the other run lists.

The VCNs represent the offset (in clusters) relative to the beginning of the file. VCNs are used to map data
locations in the file, whereas LCN map data within the volume, as shown in Figure 26.

f VCN 3 VCN 4 VC:N 5 i

LCN 0 LCN 1 LCN 2 LCN 3 LCN 4 LCN 5 LC N 6 LC N 7
_ VC N_6__________
r ’ 1
L C N 8 _________ LCN 9 L C N IO LCN 1.1 LCN 12 LCN 13 _ L C N 1 4 ______ L C N 1 5 ___________ •
IK_E_B _E_
! VCN 0 VCN VC N 2 VCN 3 VCN 4 VCN 5 :
IC N 1 6 LCN 1 7 LCN 1 8 LCN 19 LCN 20 LCN21 LCN23
LCN22 VCN 6 •

f VCN 0 VCN 1 VCN .

LCN 24 LCN 25 L C N 26 LC N 27 LCN 28 2 j LCN 29 LCN 30 LCN 31

Figure 26 - Cluster Numbering

For the example in Figure 26, the grey shaded boxes are allocated (in use), the clear boxes are un­
allocated, and there are two allocated files:
• The file 'orange' ( _ . _ . ) is fragmented:
o Fragment 1 is located at Logical Cluster Number 26 - 28, which is Virtual Cluster Numbers
0 - 2.
o Fragment 2 is located at LCN 4 - 1 5 , and has VCN 3 - 14.

• The file 'purple' (................ ) is contiguous, and starts at LCN 16 and ends at LCN 22, VCN 0 - 6.

A Physical number relates to the entire disk - Physical sector 0 is the start of the disk.
A Logical number relates to the volume - Logical Cluster 0 is the start of an NTFS volume.
A Virtual number relates to an entity such as a file - Virtual Cluster 0 is the start of the file.
 Allocated Size
The smallest allocable or addressable unit on a volume is the cluster, which is a fixed size set at format. A
cluster can only be allocated to one file. The amount of clusters a file needs is the allocated size, commonly
called physical size.

Actual Size
The size of the file’s actual content in bytes, commonly called logical size. Most files are not going to be
equally divisible by the cluster size, which means there will be a difference in size between the actual file
content, and the allocated clusters.

File Slack
Any unused space between the end of the logical file and the end of the allocated space is handled in two
different ways. A sector is the smallest writable unit in a volume - currently 512 bytes.
• The space between the end of the file’s content and the end of the sector is padded with zeros (0x00),
commonly called RAM Slack.

• The remaining sectors within the cluster are left untouched - the content in this area belonged to a
file that previously used the cluster and has since been deleted. It is commonly called Residual or
Drive Slack, and is not part of the current file.

Initialized Size
Sometimes when a file is created, not all the actual content is available - for example, a file downloaded
from the Internet. When a file is created, space is reserved on the volume without writing actual content.
The purpose of this feature is to prevent unnecessary read/writes, thereby improving performance. NTFS
has to track what part of that space contains valid file data. The data in the uninitialized space is the same
as residual slack.

Figure 27 depicts the file size and File Slack concepts: Actual size of 2,660 bytes; Allocated size of 4,096
bytes (eight sectors); Initialized size 1,024 bytes. When the entire file is initialized, the remainder of Sector
85 will be written with 0x00. Sectors 86 and 87 will not be written to at all.

NTFS Volume - 4 sectors per cluster. Sector Size = 512 bytes - Cluster size = 2048 bytes
Sector 64 ¡Sector 65 ¡Sector 66 ¡Sector 67 Sector 68 Sector 69 Sector 70 ¡Sector 71

Sector 72 I C lu s te r 1 0 ; Sector 76 Cluster 11 i 1

♦
Allocated = 4096 \
jifw S J T lS T _ 1 Actuf - 2660
l RAM
• (Sector 80 I Sector 84 Drive Slack - Residual \
■ Slack
•1 «Cluster 12 1 ■ Un-initialized Space Cluster 13
0x00 Data ;
- > k - ........-> < ■ ------------- i--------------- >:
^ _________________ F
♦

Sector 88 : Cluster 14j Sector 92 Cluster 15 i

Figure 27 - Definitions ol File Size and File Slack
When File Data is saved to Clusters in a Volume, it may become fragmented. NTFS creates a list of where
all the parts of the file, which is called a run list. The run list is comprised of one or more entries, which
provide the offset and length for each fragment. The Starting Extent is a signed integer and can be a
negative value to move earlier in the volume. The offset is called a Starting Extent, as it’s relativity changes.

The first fragment (VCN 0) Start Extent is relative to Logical Cluster Number 0.
Any subsequent fragment’s Start Extent is relative to the First Cluster of the previous fragment.

Imagine a disk of 80 Clusters, and we save a red file to it. The run list will have one entry, the Start Extent
is relative to LCN 0:

We then add more data to the file, and it fragments. A second entry is added to the run list, where the Start
Extent is relative to the FIRST Cluster of the previous fragment - in this case LCN 30.

We then add more data to the file, and it fragments again. A third entry is added to the run list, where the
Start Extent is relative to the Second Cluster of the previous fragment - in this case LCN 58.
 Run Lists
A run list is a collection of pointers to data, specifically, where to find attribute content. Each pointer (called
a run list entry) points to a block of contiguous content (a fragment). It does this by providing the length of
the fragment in clusters, and the starting extent (offset) of the fragment. Each entry within a run list has a
header and content. The header is one byte long and tells how long the entry content is by using each
nibble to represent the number of bytes in the length and offset fields:
• Left Nibble + Right Nibble = bytes in run entry content
• The left nibble in the header represents how many bytes the Starting Extent field uses.
• The right nibble in the header represents how many bytes the Length field uses.

The end of a run list is represented by a header of 0x00. Table 28 shows the data structure of a run list -
note that the relativity of the starting extent is different in the first run from all remaining runs in the run list.

Run List Entry 1 Run List Entry 2...

Header Content Header Content
Header Length Starting Extent Header Length Starting Extent
Clusters Clusters Offset relative to firs t
SE | L Offset relative to SE j L
in in cluster of p re v io u s
bytes > bytes LCN 0 bytes i bytes
Fragment Fragment extent
Figure 28 - Run List data structuré (SE = starting extent, L = length)

The relativity of the starting extent is often confused, as only the first run list entry has a value that correlates
to the Logical Cluster Number of the volume (relative to Cluster 0). The remaining starting extents are
relative to the previous starting extent - each previous starting extent has to be added together to obtain
the Logical Cluster Number of the start of the fragment. It is believed this is used to reduce the entry size
for very large volumes. Figure 29 gives a graphical view of how to combine the starting extents.

Run 1 = Start Extent Run 2 - Start Extent Run 3 - Start Extent Run 4 - Start Extent

Relative to LCN 0 F r a g 1 LCN + R u n 2 SE F r a g 2 LCN + R u n 3 SE F r a g 3 LCN + R u n 4 SE

L o g ic a l C lu s te r
= F r a g m e n t 2 LCN = F r a g m e n t 3 LCN = F r a g m e n t 4 LCN
N um ber

Figure 29 - Starting Extent Relativity

The Starting Extent can be a positive or negative value, and therefore is a S ig n e d In te g e r.

 Of f s e t 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 80 00 00 00 50 00 00 00 01 00 40 00 00 00 01 00 1 P
00000010 00 00 00 00 00 00 00 00 7F 03 00 00 00 00 00 00
00000020 40 00 00 00 00 00 00 00 00 00 38 00 00 00 00 00 8
00000030 76 F3 37 00 00 00 00 00 76 F3 37 00 00 00 00 00 vo 7 vo7
00000040 31 04 00 00 OC 32 7C 03 04 00 F4 00 80 FA FF FF 1 2| 6 |uy
Figure 30 - Non-Resident Attribute

The attribute in Figure 30 is translated as:

1. Header 1 Content N o n -R e sid e n t Header

2.
• Attribute Type - 0x80 = Data. • Start VCN - 0 = First Cluster of file.
• Attribute Length - 0x50 (80) bytes. • End VCN - 0x37F (895).
• Resident Flag - 0x01 = Content non-resident. • Offset to Run List - 0x40 (64) bytes.
• There is no “stream” name. • Allocated size - 3,670,016 bytes.
• Flags - 0x00 = not set. • Actual size - 3,666,806 bytes.
• Attribute Identifier - 0x01 = second attribute • Initialized size - 3,666,806 bytes,
added.

The run list from Figure 30 is: 31 04 00 00 0C 32 7C 03 04 00 F4 00

R u n List Entry 1

1. The header of the first run 0x31 gives the length of run: 3 + 1 = 4 bytes.
o The first run content is 04 00 00 0C.

2. The right nibble shows how many bytes to use for the fragment length = 1.
o 0x04 clusters long.

3. The left nibble shows how many bytes for starting extent (offset) = 3.
o OxOCOOOO = Logical Cluster Number 786,432.

Length
Start Extent Start LCN End LCN
Entry 1 (Clusters)
4 786,432 786,432 786,435

The last cluster is determined by adding the length in clusters to the start LCN and then subtracting 1. We
subtract 1 as the Start LCN is the first cluster in the fragment, as illustrated below.

LCN 786,432 LCN 786,433 L C N 786,434 LCN 786,435

LCN 786,431 LCN 786,436
1 2 3 4
 4. The next byte is the header of the second run: 3 + 2 = 5 bytes.
o The second run content is 7C 03 04 00 F4.

5. The right nibble shows how many bytes to use for the fragment length = 2.
o 0x037C (892) clusters long.

6. The left nibble shows how many bytes for starting extent (offset) = 3.
o 0xF40004 = -786,428.

7. Cluster 786,432 + (-786,428) = Fragment 2 starts at Logical Cluster Number 4.

Length Start Extent Start LC N En d L C N

Entry 2
892 -786,428 4 895

R u n List Entry 3

8. The next byte is the header of the third run, 0x00, indicating the end of the run list.

It is far easier to manually resolve a run list in a Forensic Tool or Hex Editor that can interpret variable
length signed values. Most other calculators will require padding (OxFF, and/or OxF).

The Final Cluster...

It is most unlikely that a file’s actual size will perfectly match the allocated size; therefore, the last cluster
that the file occupies is only partially in use. It is important to differentiate between file content and slack
space to avoid incorrectly attributing data in to a file. To determine how much of the last cluster is actually
in use by the file, subtract the Actual size from the Allocated size. The result will be the amount of slack
space in the last cluster in bytes. Subtract this value from the Cluster size, which will show how many bytes
of the file are in the final cluster.

1. Allocated - Actual = slack

2. Cluster Size - slack = file bytes in last cluster

File Allocated Size: 3,670,016 bytes

File Actual Size: 3,666,806 bytes
Cluster Size: 4,096 bytes

• Slack in final cluster: 3,670,016 - 3,666,806 = 3,210 bytes

• How much of file in the final cluster: Cluster size 4,096 - 3,210 = 886 bytes in the last cluster.

Length Final C luste r

Start Extent Start L C N En d L C N
Entry 2 (Clusters) B y te s
892 -786,428 4 895 886
Fill in the blanks below to interpret the $Data attribute for
in the first partition on BCFE NTFS.vhd:

Header Content Non-Resident Header

i

• Attribute Type - • Start VCN -

• Attribute Length - • End VCN -

• Resident Flag - • Offset to Run List -

• “Stream” name - no stream name. • Allocated size -

• Flags - 0x00 = not set. • Actual size -

• Attribute identifier - • Initialized size -

The run list is:

Run List Entry 1

1. The header of the first run:________________Length of run:__________________ bytes.

o The first run content is :_____________________________________________

2. The right nibble shows how many bytes to use for the fragment length = _________________

o Fragment one is ________________clusters long.

3. The left nibble shows how many bytes for starting extent (offset) = ______________________

o Fragment one starting extent Ox______________Dec_________________________

4. Fragment 1 starts at Logical Cluster Number___________________________

Start Extent
Length Start LCN End LCN
(Clusters)
Entry 1
 5. The header of the second run:________________Length of run:__________________ bytes.

o The second run content is :___________________________________________

6. The right nibble shows how many bytes to use for the fragment length = __________________

o Fragment two is ________________clusters long.

7. The left nibble shows how many bytes for starting extent (offset) = ______________________

o Fragment two starting extent Ox_________________Dec_______________________

8. Fragment 2 starts at Logical Cluster Number_______________+_______________ = _ _ _ _ _

Length Start Extent Start LCN End LCN

Entry 2

R u n List Entry 3

9. The header of the third run:______________Length of run:_____________________ bytes.

o The third run content is :________________________________

10. The right nibble shows how many bytes to use for the fragment length = __________________

o Fragment three is ________________clusters long.

11. The left nibble shows how many bytes for starting extent (offset) = _______________________

o Fragment three starting extent Ox_______________Dec________________________

12. Fragment 3 starts at Logical Cluster Number_____________+___________= _____________

13. Last Cluster - Allocated Size_____________- Actual size___________ = ________________ bytes

o Cluster Size (4096) - Slack_______________ = _____________bytes of file content.

Final Cluster
Length Start Extent Start LCN End LCN
Bytes
Entry 3

Run List Entry 4 - The header of the fourth run:

Additional Practice for Labs/self-study:
Manual Run List:
Allocated size: 603,160,576 bytes Actual size: 603,155,340 bytes__________

Run List:
11 0A 74 21 76 B4 74 32 02 10 FC DB FF 23 00 00 01 F9 45 22 1A OF 4B F0 00 19 C8

Length Start Extent Start LCN End LCN

Entry 1
Ox Ox

Length Start Extent Start LCN End LCN

Entry 2
Ox Ox

Length Start Extent Start LCN End LCN

Entry 3
Ox Ox

Length Start Extent Start LCN End LCN

Entry 4
Ox Ox

Final Cluster
Length Start Extent Start LCN End LCN
Bytes
Entry 5
Ox Ox

Cluster size can be calculated by dividing File Allocated size by the total number of clusters.

Total clusters =_________. Allocated size =_______________ . Cluster Size =_____ bytes (___sectors)
File: 03 Run List Practice.txt

Allocated size:_______________________________ Actual size:

Run List:___________________ ___

Length Start Extent Start LCN End LCN

Entry 1

Length Start Extent Start LCN End LCN

Entry 2

Final Cluster
Length Start Extent Start LCN End LCN
Entry 3 Bytes

File: 04 Run List Practice.txt

Allocated size:___________________Actual size:___________________ Initialised Size:

Run List:______________________________________________ _____

Length Start Extent Start LCN End LCN

Entry 1

Length Start Extent Start LCN End LCN

Entry 2

Length Start Extent Start LCN End LCN

Entry 3

Length Start Extent Start LCN End LCN

Entry 4

Final Cluster
Length Start Extent Start LCN End LCN
Bytes
Entry 5
XII. Indexing Structures in NTFS
In the FAT file system, the directory tree format was used to show parent-child relationships between a
directory (folder) and its content - each directory contained a list of its content in no particular order. In
NTFS, the $MFT is a flat file where each $MFT record contains the record number of its parent - a one­
way lookup. Both are inefficient methods for listing and searching large directory structures.

To improve efficiency NTFS uses indexes. An index uses a tree structure that maintains the entries in a
hierarchical order to speed up search operations. The NTFS tree structure is based on a Binary search
tree, commonly called a B-tree. A B-tree is a means of sorting data and is a concept derived from
databases.

A B-tree structure is comprised of nodes. Each node has a maximum number of allocated entries, called
elements. When these elements are used, additional nodes are created. There is a parent (Root) node,
and there can be multiple child nodes that are added in a growing tree structure.

The key concept of a B-tree:

If a value is smaller, it goes to the left - if a value is larger, it goes to the right.

The content within the nodes of a B-tree is constantly sorted and resorted every time the content is
changed. This maintains the values in correct order and the tree in “balance". A balanced tree structure
means a search for the smallest entry will take the same number of steps for the highest entry - there is
the same number of nodes on the left-hand side as on the right-hand side from the root. An example is
given Figure 31 of how a B-tree stores data and grows or shrinks as required to keep the tree balanced.

• B-tree root node. ¡r «

3 element node.•

• N e w ‘file’ added “F ”. ° ° p
Element filled and sorted.

□ □

New ‘file’ added “Y ”. F

Root node is full, two child nodes created to
keep tree balanced, data sorted.
□ □ □

• ‘File’ “F ” deleted.
Child nodes removed, elements E K Y
sorted.
Figure 31 - B-tree Example

In NTFS, the node size is set by the number of clusters per node, which is found in the $Boot. There are
several types of index in NTFS, which are identified by a stream name, as shown in Figure 32. This section
will cover the $130 stream or Directory Index structures only.
 Stream Name Index Content Utilized by
$130 File Names Directories
$SDH Security Descriptors $Secure
$SII Security Identifiers SSecure
$0 Object Identifiers SObjld
$0 Owner Identifiers SQuota
$Q Quotas $Quota
$R Reparse Points $Reparse
Figure 32 - NTFS Index types

In NTFS, an index is the content of (up to) two file attributes, the $lndex_Root attribute and
$lndex_Allocation attribute.

$lndex_Root Attribute 0x90

The Index Root Attribute is a B-tree head node. The data is always resident. As more entries are added
than the node can store, it will refer to child nodes (in which case the Index Allocation Attribute will exist).
The will also be a stream name for the attribute; if is it a Directory Index, the stream name will be $130.

The Index Attribute content contains three data structures. The first is the Index Root, which lays out the
B-tree parameters. The next data structure is the Index Node Header, which provides information about
the specific B-tree node in which it resides (in this case the root), and then there are the actual index entries.
A graphical view of the data structures is given in Figure 33.

Attribute Headers
Attribute Header I
i ____________________________________ j
Resident Content Header

Attribute Content

s Index R o o t- 16 bytes
I

Index Node Header - 16 bytes

Index Entries - variable length

Figure 33 - $lndex_Root depiction

 Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 16 Attribute Header Standard Attribute 16-byte header
0x10 16 8 Content Resident Content Resident 8-byte header
Stream Name Identifies type o f Index
0x00 0 4 Attribute type Type of Attribute stored in Index
0x04 4 1 Collation Sorting rule Method of sorting index - 0x01 - Filename
0x08 8 4 Size of index record Size of Index Buffer in bytes (child nodes)
OxOC 12 1 Clusters in index record Size of Index Buffer in clusters
0x10 16 16 Node Header See Table in Figure 35
Figure 34 - $lndex_Root data structure

The first part of the $lndex_Root content sets the rules of the B-tree, indicating what is contained in each
element; in this case a $File_Name Attribute. It then sets out how the table will be sorted, and the maximum
size of each child node, called an Index Buffer in NTFS.

The next data structure is the Node Header. Every node in an NTFS index will have a node header,
including the root node. The node header contains information about the node itself. The data structure
for a Node Header is given in Figure 35.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 4 Offset to index entry list Relative to Node Header in bytes
0x04 4 4 Offset to end of used area Actual size Index Buffer
0x08 8 4 Offset to end of Index Buffer Allocated size of the Index Buffer
0x00 = no child nodes, 0x01 = child node(s)
0x00 12 4 Flags
present
Figure 35 - Node Header data structure

After the Node Header, the node elements begin. Each element is a $File_Name Attribute for a file or sub­
directory that is contained in the directory. The data structure of an entry is in Figure 36.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 8 $MFT Record Number of entry Record number & sequence count
0x08 8 2 Length of this entry Length in bytes
OxOA 10 2 Length of attribute content $Fiie_Name attribute content length
0x00 = no child nodes, 0x01 = child node(s)
OxOC 12 2 Flags
present
0x10 16 Varies $File_Name attribute- content only, see Table
Attribute
in Figure 17 for data structure
8 VCN of child node If child node, then VCN in Index Buffers
Figure 36 - $130 Index Entry data structure

Only the content of the $File_Name attribute is contained in the Index Entry. In NTFS v3.1, there will be
two entries for files that have long file names; Win32 (LFN) followed by the DOS (SFN) entry. In NTFS
v3.1-80, there will only be a single entry using POSIX namespace.
 The file date and time stamps in the Directory Index $File_Name attribute relate to the file content,
not the file name; the date and time stamps in the Directory Index match the date and time stamps
in the $Standard_lnformation attribute for the file.

Each entry immediately follows the previous within the node, on an 8-byte boundary. An example of an
$lndex_Root attribute is given in Figure 37.

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 90 00 00 00 20 01 00 00 00 04 18 00 00 00 01 00 -1f
00000010 00 01 00 00 20 00 00 00 24 00 49 00 33 00 30 00 $ 1 3 0
00000020 30 00 00 00 01 00 00 00 00 10 00 00 01 00 00 00 0 -

00000030 10 00 00 00 F0 00 00 00 F0 00 00 00 00 00 00 00 5 S
00000040 3C 0D 00 00 00 00 03 00 68 00 54 00 00 00 00 00 < L h T
00000050 32 0D 00 00 00 00 OF 00 DC 4B E0 7B 40 DB CC 01 2 v ÜKä{@Üi
00000080 27 C5 C3 IB 40 DB CC 01 DC 4B E0 7B 40 DB CC 01 ÜKä{@0I
00000070 DC 4B E0 7B 40 DB CC 01 08 00 00 00 00 00 00 00 ÜKä{@ÜI
00000080 04 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 J

00000090 09 03 61 00 61 00 61 00 61 00 61 00 2E 00 74 00 -a a a a a . t
oooonoAO 78 00 74 00 00 00 00 00 3D 0D 00 00 00 00 03 00 x t = L
000000B0 68 00 54 00 00 00 00 00 32 0D 00 00 00 00 OF 00 h T 2 5
ooooooco FD 99 E0 7B 40 DB CC 01 12 9D BA 23 40 DB CC 01 y|a{@01
000000D0 FD 99 E0 7B 40 DB CC 01 FD 99 E0 7B 40 DB CC 01 yla{@0i y |ä{@ÜI
000000E0 08 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00
000000F0 20 00 00 00 00 00 00 00 09 03 62 00 62 00 62 00 •bbb
00000100 62 00 62 00 2E 00 74 00 78 00 74 00 00 00 00 00 b b . t x t
00000110 00 00 00 00 00 00 00 00 10 00 00 00 02 00 00 00 T T

Figure 37 - $lndex_Root Attribute

The $lndex_Root attribute content in Figure 37 is translated as:

Header Content
• Attribute Type - 0x90 = Index Root. > Index R oot
• Attribute Length - 0x120 (288) bytes. Attribute type - 0x30 = $File_Name.
• Resident Flag - 0x00 = Content resident. Collation sort rule - 0x01.
• Stream name - $130. Index size - 0x1000 (4096) bytes.
• Flags - 0x00 = not set. Index size - 0x01 cluster.
• Attribute Id - 0x01 = Second attribute added.
• Size of Content - 0x100 (256) bytes. > Index N ode Header
• Offset to content - 0x20 (32) bytes. Offset to entries - 0x10 (16) bytes.
Offset to end of entries - OxFO (240) bytes
Offset to end of node - OxFO (240) bytes.
Flags - 0x00 = no child nodes.

> Index Entries

• $MFT Record Number of Entry - 0xD3C (3388), Sequence count - 0x03.
• Length of entry - 0x68 (104) bytes.
• Length of $File_Name content - 0x54 (84) bytes.
• Flags -0x00 = No child nodes.
• $File_Name Attribute Content - note the file dates and sizes are valid.
• The next Index Entry starts at offset 0xA8 in this example.
 The size of a directory (folder) grows as more sub-files/folders are added to it. The on-disk size of the
parent directory grows because the Directory Index has to list every file/folder within the parent. This growth
will cause child nodes to be spawned from the Index Root.

The content of the $lndex_Allocation attribute is the child nodes of the directory index, called Index Buffers.
An Index Buffer (child node) is too large to be resident, so the content of the $lndex_Allocation attribute is
always non-resident. The $lndex_Allocation attribute can be parsed using the attribute header and non­
resident content attribute data structures (Table in Figure 25), and the run list gives the location(s) of the
Index Buffer(s). It will have a stream name that matches the $lndex_Root attribute for that index type.

Each index buffer begins with a header to identify it, then the Index entries. The data structure for and
index buffer header is given in Figure 38 - the index entries use the same structure as the index entries in
the Index Root node (Figures 35 - 36).

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 4 Signature INDX
0x04 4 2 Offset to fix-up array Normally 0x28 - 40 bytes
0x06 6 2 Entries in fix-up array Depends on sector & INDX buffer sizes
0x08 8 2 $LogFile sequence number Transaction entry number in SLogFile
0x10 16 8 VCN of this child node
0x18 24 16 Node Header Table in Figure 35
0x28 40 Fix-up array
0x50 80 Index Entries Table in Figure 36 - starts on 8-byte boundary
Figure 38 - Index Buffer Header data structure

An Index Buffer uses the same error checking system as the Master File Table - a check value at the end
of each sector within the Index Buffer. Due to the size of the node, there will be more fix-up values in the
array.

Each index entry will start on an eight-byte boundary, much the same as individual attributes in an $MFT
file record. This will often require padding between each entry.
 Of fset 0 1 2 3 4 5 6 7 8 9 A B C B E F
00000000 49 4E 44 58 28 00 09 00 75 98 3B 04 00 00 00 00 INDX( u |;J
00000010 00 00 00 00 00 00 00 00 28 00 00 00 A8 02 00 00
00000020 E8 OF 00 00 00 00 00 00 02 00 CC 01 00 00 00 00 èr- 1 Î
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040 3F 0D 00 00 00 00 03 00 68 00 54 00 00 00 00 00 ? i h T
00000050 34 0D 00 00 00 00 06 00 C3 4B 81 87 40 DB CC 01 4 - 2M|@ÛÎ
00000060 27 C5 C3 IB 40 DB CC 01 D4 74 81 87 40 DB CC 01 'ÂS-@0ï Ot|@ÛÎ
00000070 C3 4D 81 87 40 DB CC 01 08 00 00 00 00 00 00 00 ÏM|@ÛÎ =
00000080 04 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00 J
00000090 09 03 61 00 61 00 61 00 61 00 61 00 2E 00 74 00 La a a a a . t
000000A0 78 00 74 00 00 00 00 00 40 0D 00 00 00 00 03 00 >: t @
Figure 39 - Index Buffer

The Index Buffer ($lndex_Allocation attribute content) in Figure 39 is translated as:

Header
Signature - INDX. Fix up Array
Offset to Fix Up Array - 0x28 (40) bytes. Check Value = 0x02 0x00
Entries in fix up array - 0x09. Fix-up Values = OxCC 0x01, 0x00 0x00, 0x00
SLogFile Sequence # - 71,014,517. 0x00...
VCN of this node - 0x00.
Index Entries

Index Buffers are constantly being reshuffled as they are sorted in the form of B-tree. This can
cause a deleted e ntry to be over-w ritten quite quickly. This causes w hat a pp e a r to be m ultiple entries
for the same file; they are caused by the reshuffling process & slack space within the node.

The forensic value of Index Buffers are somewhat limited as they only contain the $File_Name
attribute and the $MFT record number of a file. The pointers to the content of a file are only located
in the $MFT. At best, the Index Buffer will only allow a Forensic Investigator to say “A file with the
name ‘X YZ’ was located in this folder/volume".
 A SBitmap attribute shows the allocation status of an entity. Depending on the size of the bitmap, the
content may be resident or non-resident. An example of the $Bitmap attribute is in the $MFT file record for
the $MFT itself (Record 0), where the bitmap represents the allocation status of every file record within the
$MFT. The Bitmap uses one bit to represent each entity; a value of 0 means the entity is not allocated, a
value of 1 means it is allocated. The bitmap is the only content of the SBitmap Attribute, and an example
is given in Figure 40.

Of fset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 B0 00 00 00 28 00 00 00 00 04 18 00 00 00 09 00 * ( J|
00000010 08 00 00 00 20 00 00 00 24 00 49 00 33 00 30 00 : $ 1 3 0
00000020 01 00 00 00 00 00 00 00
Figure 40 - SBitmap Attribute

The SBitmap attribute content in Figure 40 is translated as:

Header Content
• Attribute Type - OxBO = Bitmap. • 0x01 - 0000 0001 = 1 Child Node (Index Buffer).
• Attribute Length - 0x28 (40) bytes.
• Resident Flag - 0x00 = Content resident.
• Stream name - $130.
• Flags - 0x00 = not set.
• Attribute Identifier - 0x09 = tenth attribute added.
• Size of Content - 0x08 bytes.
• Offset to content - 0x18 (24) bytes.

The SBitmap attribute in Figure 40 has a stream name o f‘'$130”, which indicates it is bitmap for a Directory
Index. In this situation, the SBitmap data shows how many child nodes are allocated within the Directory
Index tree structure.
XIII. Reparse Points

Reparse points were introduced into the Windows operating system as part of the NTFS, but not utilized
until the release of Windows Vista. A reparse point is a link or pointer to another location. There are three
different types of NTFS reparse points that can be used by applications, the operating system, or created
by user:
• Hard Link - additional link to file. Only one copy of the file exists on the volume, but it may appear in
multiple directories. A hard link may also have a different file name than the target file. Hard Links
must be on the same volume as the target file.

• Junction - same as Hard Link, but points to a directory.

• Symbolic Link - Can point to a Volume or remote location. In this type of reparse point, a GUID will
be used by the system to identify the mount point, not the path.

Junctions are used in Windows Vista and later versions to maintain backward compatibility for legacy
applications to locate user profile data. For example; user profiles in Windows XP were stored in the
C:\Documents and Settings folder; in whereas later versions use C\:Users. There is still a Documents and
Settings $MFT record entry in the later versions; however, it is a junction that points the User's folder.

$Reparse_Point Attribute OxCO

A reparse point has its own $MFT file entry, which will contain $Reparse_Point Attribute; the attribute
content will point to the target by a path or GUID. The reparse point file entry will also contain
$Standard_lnformation and $File_Name attributes, that relate to the reparse point itself. The data structure
of a $Reparse_Point attribute is given in Table 41.

Offset Length
Name Description
Hex Dec (Bytes)

0x10 16 8 Content Resident Content Resident 8-byte header

Stream Name If applicable
0x20000000 is Alias
0x68000005 Native Structured Storage
0x68000007 Single Instance Storage
Reparse type flags 0x68000008 Distributed File System
0x00 0 4
(not all types listed) 0x80000000 Is Microsoft
0x88000003 Mount point
0xA0000003 Symbolic link
OxA8000004 Hierarchical Storage Management
0x04 4 2 Reparse data length # of bytes
0x08 8 2 Offset to target name Relative to byte 16 of Reparse content
OxOA 10 2 Target name length # of bytes
OxOC 12 2 Offset to print name Relative to byte 16 of Reparse content
OxOF 21 2 Print name length # of bytes
Figure 41 - $Reparse_Point Attribute data structure

A non-Microsoft reparse point may contain a GUID at offset 0x08, in which case the reparse data offsets
will be additional 16 bytes. An example of a $Reparse_Attribute is given in Figure 42.
 Offset 0 1 2 3 4 5 6 7 8 9 A B c D E F
00000000 CO 00 00 00 58 00 00 00 00 00 00 00 00 00 04 00 A X J
00000010 3C 00 00 00 18 00 00 00 03 00 00 A0 34 00 09 00 < t L 4
f - A\ ? ? \

o
O
00000020 00 00 18 00 1A 00 10 00 5C 00 3F 3F 00 5C 00
00000030 43 00 3A 00 5C 00 55 00 73 00 65 00 72 00 73 00 C : \ U s e r s
00000040 00 00 43 00 3A 00 5C 00 55 00 73 00 65 00 72 00 C : \ U s e r
00000050 73 00 00 00 00 00 00 00 s

Figure 42 - $Reparse_Point Attribute

The $Reparse_Point attribute content in Figure 42 is translated as:

Header Content
• Attribute Type - OxCO = Reparse Point. • Reparse type - OxA0000003 = Symbolic Link.
• Attribute Length - 0x58 (88) bytes. • Reparse data length - 0x34 (52) bytes.
• Resident Flag - 0x00 = Content resident. • Offset to target name - 0x00 bytes.
• No stream name. • Target Name Length - 0x18 (24) bytes.
• Flags - 0x00 = not set. • Offset to Print Name - 0x1 A (26) bytes*.
• Attribute Identifier - 0x04 = Fifth attribute added. • Print Name Length - 0x10 (16) bytes.
• Size of Content - 0x3C (60) bytes. • Target Name - \??\C:\Users.
• Offset to content - 0x18 (24) bytes. • Print Name - C:\Users.

XIV. Named Stream (Alternate Data Stream)

Some operating systems and applications have a requirement to store additional information about a file -
but this information is not part of the file content. The information is stored in what is called an “alternate
data stream” (ADS). Alternate Data Streams are a file system function that allows multiple data resources
to be stored at the file system level for a file.
The content of a file is stored in a $Data attribute that does not have a stream name. If an application
wanted to store additional metadata about that file, it will be in an additional $Data attribute, which has a
stream name. Hence an alternate data stream (ADS) is often called a “named stream”, and Microsoft refer
to it as a named data stream. A named stream may exist for any attribute, but ADS are normally only seen
in a data attribute.
The ADS is not displayed to the user, and is not included in the file content size. As a result, they can also
be used to hide malicious or evidential data. Any attribute that is a named stream is parsed using the
appropriate data structure for the attribute type. An example of this is given in Figure 43.

On a Windows computer, the most common ADS would have the stream name “Zone.Identifier”. The
purpose of this alternate data stream is to identify the source of a file that has been saved to the computer
using an e-mail client or web browser. This ADS identifies that the file has been downloaded from an
external source, and what the trust level of that source is.

In Figure 43, there are two $Data attributes for the downloaded file "casenotes-lite.zip”. The first $Data
attribute’s content is the actual Zip file content - the size of this data is what is recorded as the file size.
The second SData attribute has a stream name “Zone.Identifier". The content of this data attribute is the
alternate data stream. The size of this attribute’s content does not affect the displayed file size value. If
the file is copied between NTFS volumes, this alternate data stream is copied with the file. If the file is
copied or moved to a FAT volume, the ADS is “lost” as FAT does not support ADS.
 N am e Ext. S ze C reated M odified A ccessed R e co rd u p d a te
j_ c a s e n o te s -lite .z ip zip 3S3.G57 1 3 /1 2 /2 0 1 2 1 2 :2 5 :3 7 1 3 /1 2 /2 0 1 2 1 2 :2 5 :3 7 1 3 /1 2 /2 0 1 2 1 2 :2 5 :3 7 1 3 /1 2 /2 0 1 2 1 2 :2 5 :3 7

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 80 00 00 00 48 00 00 00 01 00 00 00 00 00 03 00 1 H
0 0 0 00010 00 00 00 00 00 00 00 00 58 00 00 00 00 00 00 00 X
0 0 0 00020 40 00 00 00 00 00 00 00 00 90 05 00 00 00 00 00 @
0 0 0 00030 89 8C 05 00 00 00 00 00 89 8C 05 00 00 00 00 00 11 11
0 0 0 00040 31 59 30 FE 03 00 FF 00 1Y0J? ÿ

O ffset 0 1 2 3 4 5 6 7 8 9 A B c D E F
00000 0 0 0 80 00 00 00 58 00 00 00 00 OF 18 00 00 00 04 00 1 X

o
o
00000 0 1 0 1A 00 00 00 38 00 00 00 5A 6F 00 6E 00 65 00 8 Z o n e
00000 0 2 0 2E 00 49 00 64 00 65 00 6E 00 74 00 69 00 66 00 . I d e n t i f
00000 0 3 0 69 00 65 00 72 00 00 00 5B 5A 6F 6E 65 54 72 61 i e r [ZoneTra
00000 0 4 0 6E 73 66 65 72 5D 0D 0A 5A 6F 6E 65 49 64 3D 33 nsfer] ZoneId=3
00000 0 5 0 0D 0A 00 00 00 00 00 00 FF FF FF FF yyyy
Figure 43 - Alternate Data Stream (Named Stream)

The Attribute Header in Figure 43 is translated as:

• Attribute Type - 0x80 = Data. • Offset to Stream Name - 0x18 (24) bytes from
• Attribute Length - 0x58 (88) bytes. start of Attribute.
• Resident Flag - 0x00 = Content resident. • Flags - 0x00 = not set.
• Length of Stream Name - OxOF (15) Unicode • Attribute Identifier - 0x04 = fifth attribute added
characters. to File Record.
• Stream Name - Zone.Identifier

The content of this attribute is [ZoneTransfer] Zoneld=3. This indicates the file content has been downloaded
from the Internet.

ZonelD Values:

0. My Computer
1. Local Intranet Zone
2. Trusted Sites Zone
3. Internet Zone
4. Restricted Sites Zone
 When a file/directory is created, the following series of steps occur (ignoring transaction logging features,
which are discussed later):
1. It is assigned a file record in the $MFT.
2. The bitmap for the $MFT is changed to show that this record is allocated.
3. The record header allocation status flag identifies it as an allocated file/directory.
4. Attributes are written to the $MFT file record.
5. If there are Content Non-Resident Attributes, the $Bitmap file is updated to represent the clusters
allocated to store the content.

When a file/directory is deleted, the following series of steps occur (ignoring transaction logging features,
which are discussed later):
1. The record header sequence count is incremented by one.
2. The record header allocation status flag identifies it as an unallocated file/directory.
3. The bitmap for the $MFT is changed to show that this file record is un-allocated.
4. If the file content is non-resident, the SBitmap file is updated to represent the clusters used to
store the file content are now unallocated.

The remainder of the file record is left unchanged and untouched until the file record is re-used. To recover
a single file, it is simply a matter of reversing the deletion steps. If the content of the file is resident, then it
can be recovered until the file record is reused. If the data content of the file is non-resident, then the
content can be recovered until its clusters are over-written by the content of another file. It is quite common
for the data content of a file to remain on a volume long after its file record has been re-used.

Orphaned Files
As the $MFT is a list of all files in the volume, when a folder and its content is deleted, and until those $MFT
records are re-allocated, the entire directory structure can be recovered. Testing shows that the allocation
of an $MFT record is done on a top down basis. As a new record is needed, a search for the next available
record is conducted from the top of the $MFT until an available entry is found. If one is not found, a new
entry is created by increasing the size of the $MFT. Even if the $MFT file record of a parent directory is
overwritten, the child file record(s) remain in the $MFT and can be recovered.

During file recovery, it is possible to recover a file without being be able to recover its parent directory.
These files are termed an orphaned, as the parent child relationship is broken. Orphaned files can be
recovered; they just cannot be forensically associated with their parent folder. During manual file recovery,
it is important to check that the parent-child relationship still exists; otherwise a file may be associated with
the wrong directory. Forensic tools do this automatically by checking the $MFT file record sequence
numbers.

A file record $File_Name attribute contains the $MFT record number and sequence number of its parent
directory. The sequence number of the parent’s $MFT file record and the allocation status are used to
determine if the content of that record is the still the parent directory, or if the record has been over-written.
There are four potential scenarios that can be encountered when this comparison is made:

© 2017 IACIS NTFS Page 48 of 74

 1. Sequence numbers match.
> The parent record is still allocated and the parent-child relationship between the two $MFT
records is still valid.

2. The sequence number in the parent $MFT record is incremented by one (1), and the allocation
status of the parent is “deleted directory” (0x02).
> The parent record has been deleted, however it has not been over-written. The parent-
child relationship between the two $MFT records is still valid.

3. The sequence number in the parent $MFT record is incremented by one (1), and the allocation
status flag is set - “file” (0x01) or “directory" (0x03).
> The parent record has been deleted and over-written. The parent-child relationship
9 between the two $MFT records is broken.

4. The sequence number in the parent $MFT record is incremented by more than one.
> The parent record has been deleted and over-written multiple times. The parent-child
relationship between the two $MFT records is broken.

Figure 44 summarizes how to determine whether the lineage of a file is legitimate or not

Parent sequence number Parent allocation status Parent-child relationship status

Match Allocated Valid
+1 Un-allocated Valid (parent deleted)
+1 (or more) Allocated (or unallocated) Broken (orphan)
Figure 44 - Rules for Orphan files

The concept of orphan files can be demonstrated on a newly formatted volume through the steps below:
1. Create a Directory called “Parent”.

2. Inside the folder “Parent”, create a text file called “Child.txt”.

3. Navigate to the $MFT record for the child and traverse to the $File_Name attribute. Note the
parent $MFT record number and sequence.

4. Navigate to the parent $MFT record from step 3, and check the sequence count in the file record
header of this $MFT record to determine parent-child relationship status.

5. Delete the folder “Parent”.

6. Create a directory called “Not the Parent” .

7. Go back to the parent $MFT record from step 3, and check the sequence count in the file record
header of this $MFT record to determine parent-child relationship status.

Many exhibits examined will have multiple users accessing them - it is important that deleted and orphaned
files that are relevant to the investigation are associated with the correct user. What if, in the situation
shown in above, the folder names were computer users’ names?
 Every allocated $MFT entry begins with the signature “FILE”. This can be used as part of a search term to
locate unallocated entries. The search would also need to check the allocation status of the file; therefore,
a GREP expression can be used to limit results to deleted entries only:
• \x46\x49\x4C\x45.{18}[\x00\x02] - deleted entries
• \x42\x41\x41\x44.{18}[\x00\x01\x02\x03] - all entries marked “BAAD”

Forensic tools search for deleted entries already, for example EnCase during the “Recover Folders”
process. The other place that an entry for a deleted file can be located is in directory index entries, which
begin with the signature “INDX”. A directory index entry only contains the $MFT record number, sequence
number and $File_Name attribute, but may provide useful indicators of user interaction with evidential files.
Depending on the type of investigation, it may not be necessary to recover the file data if the evidence can
show that the file previously existed on the volume.

XVI. Volum e Format

The behaviour of NTFS during a volume format varies between operating systems, and the type of format
selected. There are two types of format - quick and full.

Quick Format
In all versions of Windows operating systems, a quick format will over-write the allocated area of the new
$MFT (which is determined by cluster size) with 0x00. Previous $MFT records are available for recovery
outside the current $MFT. (If the volume is the same size, the location of the $MFT will not change, and
previous $MFT records will be over-written.) The format process will also over-write the $Boot file, reset
the $Bitmap file to show all clusters are unallocated, and leave the remaining data intact.
The notable difference between operating systems is the allocated size of the $MFT after format - in testing
an XP formatted $MFT was 32,768 bytes (8 clusters) and a Vista + formatted $MFT was 262,144 bytes (64
clusters).
There are also some minor differences in how the unused $MFT file records are written - in Windows XP,
only the first two bytes are written to the file record, which are the Fix-up check entry. In Windows Vista +,
the unused file records have a record header followed by OxFF FF FF FF.

After quick format, it is possible to locate $MFT content from previous format by searching for the signature
“FILE”, as they may have been contained in a transaction log entry, or from $MFT fragmentation.

Full Format
In Windows XP, a full format will do exactly the same as a quick format, and will also read from every sector
in the volume. There is no other data over-written in a full format.
In Windows Vista/7+, a full format over-writes every sector in the volume (instead of just reading every
sector), and then re-writes the NTFS metadata files to construct the volume file system.

Be aware that format behaviour may change between versions of the NTFS driver (NTFS.sys), even
in the same operating system (OS Updates).
 In the situation of a corrupted or (deliberately) destroyed $Boot record, the first step is to search for the
backup copy. This can be done by searching for the VBR signature (0x55 OxAA). If that is insufficient for
recovery purposes, then there are some clues from other metadata file locations. For example, the
$MFTMirr is always straight after the $Boot (normally sector 16). Even without the $Boot information
searches for file records will still be useful, but some analysis and testing would be required before data
recovery to determine cluster size.

XVIII.SLogFile
NTFS is a transaction based file system, which means it creates a log of every write operation that makes
a change to a file system file. The file in which these transactions are recorded is called the $LogFile, and
is commonly referred to as a transaction log. A transaction is a disk operation in which every step must
be executed, or every step not occur at all (a partial transaction would be undone). In NTFS, the SLogfile
is particularly important due to the extensive use of write-back caching.
While a computer is use, files and file content is constantly changing. Due to their mechanical nature, it
takes on average ten milliseconds for a hard disk drive to write the data; meanwhile the system has to wait
for the hard disk to commit the changes (called write-through). Write-back caching is where the changes
are written to volatile memory, and then actually written to the physical platters in the background. The
operating system/application continues, while the file system tracks the changes until they are committed
or written to the hard disk drive. However, as write-back caching is in volatile memory, if there is a system
crash, disk failure, or media removal, the changes are not committed and the disk will be in what is called
an “inconsistent state".
The SLogfile only records NTFS metadata transactions, not user data (unless it is resident in the $MFT.
Microsoft TechNet provides the following information of how a transaction is first logged then committed to
the physical disk. “To ensure that a transaction can either be completed or rolled back, NTFS performs
the following steps for each transaction:

1. Records the metadata operations of a transaction in a log file cached in memory.

2. Records the actual metadata operations in memory.
3. Marks the transaction in the cached log file as committed.
4. Flushes (commits) the log file to disk.
5. Flushes (commits) the actual metadata operations to disk.

Steps four and five occur in a lazy fashion after the transaction is completed, meaning that the flush
operations are not tied to the transaction itself. Instead, NTFS modifies the log and metadata quickly in
memory, and then flushes later at a convenient time to boost performance.” (How NTFS Works, 2003). If
you hear the expression ‘lazy writes’ this is what is being referred to.
The SLogFile can be used by NTFS to allow for faster recoverability after a transaction error or system
crash. The whole disk does not require error checking, instead the $LogFile is reviewed. All transactions
marked complete are redone; all transactions marked incomplete are undone. This function is made even
faster by system checkpoints. Every five seconds a checkpoint is created into the $LogFile, which
guarantees all previous transactions were complete.
The log file has two main areas, the restart area and the infinite log file. The restart area has a signature
RSTR (0x52 53 54 52), and records information about the last checkpoint operation. Due to the importance
of this information, there are two copies of the restart area. The infinite logging area is actually a percentage
of the volume size, but is a circularly reused file.
The infinite logging area is comprised of 4096 byte Records with the signature RCRD (0x52 43 52 44).
Each record has a logical sequence number, but they may not appear in logical order within the log file, as
 it depends on space availability at the time the record was created. The $LogFile Sequence Number is
also recorded in the $MFT file record header for the file it relates to.
A record will contain redo information, which is what the transaction is going to do, and undo information.
Typically, the information that will be of interest in a SLogFile is an MFT entry of an evidential file. While
EnCase has a script to parse SLogFile entries, an authoritative source on the data structure of a SLogFile
record has not been identified.

There is also a very good and free tool for examining SLogfile (and $USN Journal) records called NTFS
Log Tracker. It is created by Junghoon Oh and can be downloaded from
https://sites.google.com/site/forensicnote/ntfs-log-tracker. It is discussed further in the next section.

XIX. $USN Journal

The SUSN Journal (Update Sequence Number Journal) is a change journal for files and directories;
however, it doesn’t journal the file content that was changed. The SUSN Journal consists of records that
give the name of a file being changed, the time of the change and the type of change. This makes the
SUSN Journal useful if an examiner wants to determine user interaction with a file. The file/directory name
is stored in Unicode, so it can be found through keyword searching.
The SUSN Journal is actually stored in \$Extend and has two data streams, SMax and $J. The SMax stream
stores size information about the Journal, and the lowest USN (Update Sequence Number) it stores. The
$J stream contains the journal entries, called records. The length of each record is dependent on the length
of the file/directory name. The data structure for a SUSN Journal record is given in Figure 45.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 4 Size of entry
0x04 4 4 Version 2 bytes major, 2 bytes minor
0x08 8 8 SMFT record number of file
SMFT record number of File/directory that caused this entry
0x10 16 8
parent
0x18 24 8 USN for entry USN from USN in File Record Fleader
0x20 32 8 Timestamp
0x28 40 4 Change Reason Flags See Table in Figure 47
0x2C 44 4 Source Information Source of change (can be application)
0x30 48 4 Security ID of file
0x34 52 4 File Attributes
0x38 56 2 Size of file name
0x3A 58 2 Offset to file name Normally 0x3C
% File Name
Figure 45 - SUSN Journal Record data structure

The record contains a lot of information that is duplicate from the SMFT.
An example of a SUSN Journal Entry is in Figure 46.
 Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 70 00 00 00 02 00 00 00 80 F4 00 00 00 00 38 00 P i €0 8
00000010 CD DO 01 00 00 00 09 00 E8 ÂE EF 35 00 00 00 00 ÎB è®ï5
00000020 F2 6F EE EÀ E3 DF CC 01 02 01 00 00 00 00 00 00 ôoîêâBÎ -
00000030 00 00 00 00 20 20 00 00 30 00 3C 00 4D 00 6F 00 0 < M o
00000040 64 00 75 00 6C 00 65 00 20 00 34 00 20 00 2D 00 d u 1 e 4
00000050 20 00 4E 00 54 00 46 00 53 00 2E 00 64 00 6F 00 N T F S . d o
00000060 63 00 78 00 2E 00 4C 00 4E 00 4B 00 00 00 00 00 c x . I N K

Figure 46 - $USN Journal Entry

The record in Figure 46 is translated as:Record Length - 0x70 (112) bytes.

• MFT # of file - 62592, Sequence 56. • Change Reason - 0x02 01 00 00 =

• MFT # of parent - 118989, Sequence 9. 0x00000100 - File/directory created
• Entry USN - 904900328. 0x00000002 - Default $Data attribute extended.
• Timestamp - 31 Jan 2012, 6:45:27. • File Name - Module 4 - NTFS.docx.LNK

Figure 47 contains the change reason values Microsoft Development Centre.

Value Reason
0x00000001 Default $Data attribute was overwritten
0x00000002 Default $Data attribute was extended
0x00000004 Default $Data attribute was truncated
0x00000010 A named SData attribute was overwritten
0x00000020 A named SData attribute was extended
0x00000040 A named SData attribute was truncated
0x00000100 The File/directory created
0x00000200 The File/directory deleted
0x00000400 Extended attributes changed
0x00000800 Security descriptor changed
0x00001000 Name changed - this entry has old name
0x00002000 Name changed - this entry has new name
0x00004000 Content Indexed status change
0x00008000 Basic attributes changed
0x00010000 Hard link created/deleted
0x00020000 Changed compression status
0x00040000 Changed encryption status
0x00080000 Object ID changed
0x00100000 Reparse point value changed
0x00200000 Named SData attribute created/deleted/changed
0x80000000 File/directory closed
Figure 47 - $USN Journal change reason

Ironically, the $USN Journal reportedly was created “to allow companies or law enforcement to check a
full, complete log of everything that happened on the volume”, according to Visual Basic NTFS
Programmer’s Guide from RELSOFT Technologies. In reality, due to the restriction on maximum log size,
the $USN Journal will not be an entire record and it is only enabled by default on the system volume.
 However, it is an under-utilized resource in computer forensic examinations. It can be interacted with at the
command line interface using the command ‘fsutil’.

NTFS Log Tracker

An excellent free tool developed by Junghoon Oh can be used to examine both $Log File and $USN
Journal. It is available at https://sites.qooqle.com/site/forensicnote/ntfs-log-tracker. This tool provides a
very readable view of the entries in both the Log and Journal, and can export the results into a *.csv. This
tool has been proven very useful in malware examinations where source code would write itself to the
volume on shut-down, then on restart load itself into RAM and delete the file.

NTFS Log Tracker has also been successful in creating timelines of user activity as it contains records of
files deleted, even after the File Record for the deleted file has been re-used. It’s worth a look! More
information can be found here: http://forensicinsiqht.org/wp-content/uploads/2013/06/F-INSIGHT-NTFS-
Loq-TrackerEnqlish.pdf.

XX. The Future of NTFS

Microsoft refers to NTFS as “the most widely used, advanced, and feature rich file system in broad use”.
Currently, Microsoft Windows operating systems must be installed on an NTFS volume, which will continue
to see NTFS widely used.
NTFS is fully scalable, as most data structures have headers which provide the size of that structure. This
makes it easy for a future version of NTFS to make changes that are backward compatible - for example,
the size of an $MFT record could be increased by changing the "Clusters in $MFT” field in the $Boot file,
which defines an $MFT record size. This scalability will allow NTFS to be in use for a long time. Microsoft
is continuing to develop more resilient features of data protection and recovery in NTFS, which will
contribute to its continued popularity.
Microsoft have released a new file system with Windows 2012 (Windows 8 Server) called Resilient File
System (ReFS). Perhaps the most notable thing about Windows 2012 for this module is that the operating
system must be installed on an NTFS file system. NTFS will continue to be the required file system on the
volume that Microsoft operating systems are installed on, which is the volume that most user related
evidential items are located.
XXL Compiled Tables
Boot Sector
Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 3 Jump Instruction Jump instruction to Boot Code Field
0x03 3 8 OEM ID ASCII - NTFS
OxOB 11 2 Bytes per Sector Thesetwofieldscombinedprovide
OxOD 13 1 Sectors per Cluster Clustersize
OxOE 14 2 Reserved sectors 0x00
0x10 16 5 Not used by NTFS Must be 0x00
From Windows Server 2003, this field is not
0x15 21 1 Media Descriptor
used - always 0xF8
0x16 22 2 Not used by NTFS Must be 0x00
0x18 24 4 Not used by NTFS Legacy BPB information
0x1 C 28 4 Hidden Sectors Sectors before start of Volume
0x20 32 4 Not used by NTFS Must be 0x00
0x24 36 4 Not currently used by NTFS Always 0x80 00 80 00
0x28 40 8
Total Sectors on the
volume
VolumeSize
0x30 48 8 $MFT starting extent LogicalClusterNumber(LCN)forMaster
0x38 56 8 SMFTMirr starting extent FileTableandMasterFileTableMirror
Positive value = clusters per record
Clusters per SMFT
0x40 64 1 Negative value = Record size in bytes,
Record.
2 raised to the absolute value of x
0x44 68 1 Clusters per Index Buffer Size of Index Buffer
0x48 72 8 Volume Serial Number
0x50 4 Checksum Boot Sector Checksum
0x54 84 426 Bootstrap Code Boot-strapping instructions
0x1 FE 510 2 Boot Signature 0x55 OxAA
Figure 1 - $Boot Data Structure (first 512 bytes)
 Recor
Metadata File File Name Purpose of the File
d
Master File Table $MFT 0 Contains a record of every file on the volume
MFT Mirror SMFTMirr 1 Contains a backup of the first four records of the MFT
Log File $LogFile 2 Used for recovery in the event of a corrupt file system
Volume information - volume label, NTFS version &
Volume SVoiume 3
flags
Attribute Definitions SAttrDef 4 Lists attribute names, numbers, and descriptions
Root File Name Index 5 The root directory (also referred to as the root index)
Cluster Bitmap SBitmap 6 Representation of allocated and unallocated clusters
Boot Sector $Boot 7 Boot sector and additional bootstrap loader code (VBR)
Bad Cluster File SBadClus 8 Sparse file that contains bad clusters in the volume
Index of unique security settings which can be applied
Security File SSecure 9, to files within a volume
Converts lowercase characters to matching Unicode
Upper case Table SUpCase 10
uppercase characters
Directory that contains optional extensions: SObject ID,
Extended Attributes (EA) SExtend 11
SQuota, SReparse, SRepair, and SUSN Journal
12-15 Reserved for future use
16-23 Unused
$Extend\$Quota - Tracks file quotas. Unused until
Quota SQuota 24
NTFS 5.0. Records users rights on disk space usage
$Extend\$Objld - Index of all unique IDs given to files
Object Identifier $Objld 25
and directories within the volume
$Extend\SReparse - An index of all reparse points in the
Reparse SReparse 26
volume.
Figure 3 - Metadata Files
 Offset
Length Data Description
Hex Dec
0x00 0 4 Signature FILE
0x04 4 2 Offset to fix up array Byte offset to locate fix up values
0x06 6 2 Entries in the fix up Array Number of 2-byte entries in fix up Array
0x08 8 8 SLogFile Sequence Number Transaction entry number in $LoqFile
0x10 16 2 Sequence count Count of times record has been “deleted”
0x12 18 2 Hard Link count Count of file name attributes
0x14 20 2 Offset to the first attribute Length of Record Header
Allocation status flags 0x00 = Deleted File, 0x01 = Allocated File. 0x02
0x16 22 2 Bit 0 = Allocated status = Deleted Directory,
Bit 1 = Directory status 0x03 Allocated Directory.
0x18 24 4 Logical size of $MFT Record How many bytes are used in file record
0x1C Physical size of $MFT
28 4 Length o f Record in Bytes
Record
File reference to base record Used when Record is longer than one SMFT
0x20 32 8
entry
Next attribute identification Count of attributes in record - includes deleted
0x28 40 2
attributes
0x2a 42 >0 Fix-up Array and attributes NTFS 3.0
0x2a 42 2 Zero Padding NTFS 3.1 +
0x2c 44 4 $MFT File Record Number NTFS 3.1 +
0x30 48 >0 Fix-up Array and attributes NTFS 3.1 +
Figure 5 - File Record Header Data Structure

Attribute Header
Offset Length
Name D e scrip tio n
Hex Dec (bytes)
0x00 0 4 Attribute Type Identifier
0x04 4 4 Length of the attribute L en g th in b yte s
Content Non-Resident
0x08 8 1 0 x0 0 = R esident, 0x01 = N o n -re s id e n t
Flag
Length of the “stream”
0x09 9 1 N u m b e r o f U nicode c h a ra cte rs
name
Offset to the “stream”
OxOA 10 2 F ro m b e g in n in g o f A ttrib u te
name
0x0001 - C o m pressed,
OxOC 12 2 Flags 0 x4 0 0 0 - E ncrypted,
0 x8 0 0 0 - S parse
OxOE 14 2 Attribute Identifier In s e q u e n tia l o rd e r A ttrib u te a d d e d
Figure 8 - Attribute Header Data Structure
 Offset Length Name D e scrip tio n
Hex Dec (bytes)
0x00 0 16 Attribute Header See Table in F ig u re 8
0x10 16 4 Size of the content A ttrib u te C o n te n t size in b yte s
0x14 20 2 Offset to the content O ffs e t re la tive to s ta rt o f a ttrib u te in byte s
Figure 10 - Content Resident Header

Attribute Types
Attribute Identifier Attribute Name Description
ContainsFilepermissions, timestamps, security,
10 00 00 00 $Standard_lnformation
andadministrativeinformation- alwaysresident
Locations of all attributes that do not fit in a single file
20 00 00 00 $Attribute_List
record entry
30 00 00 00 $File_Name Thenameofthefile- alwaysresident
40 00 00 00 $Volume_Version Volume Version (NTFS v1.x only)
Contains a Globally Unique Identifier (GUID - unique
40 00 00 00 $Object_ ID
16-byte identifier) for the file (NTFS v3.x)
Access control and security properties of the file
50 00 00 00 $Security_Descriptor
(Metadata files only in NTFS v3.x)
These two attributes are only used in the SVolume
60 00 00 00 $Volume_Name
metadata file and contain the volume label and NTFS
70 00 00 00 $Volume_lnformation version information
80 00 00 00 SData Theactualfile’sdata pointerstothefile’sdata
or
The top-level entry of a sorted tree that lists a directory’s
90 00 00 00 $lndex_Root
child files - always resident
Points to the location of the Index Buffers of a large
A0 00 00 00 $lndex_Allocation
directory
Tracks the allocation status of a location or an entity,
B0 00 00 00 SBitmap
dependant on file record entry type
CO 00 00 00 SSymbolicJJnk Soft link information (NTFS v1.2)
CO 00 00 00 $Reparse_Point Similar to a soft link (NTFS i/3.x)
DO 00 00 00 $EA_lnformation Allows compatibility with HPFS
E0 00 00 00 $EA Allows compatibility with HPFS
Contains information and keys for encrypted attributes
00 01 00 00 $Logged_Utility_Stream
(NTFS v3.x)
Figure 12 - Attribute Types
 Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 16 Attribute Header Standard Attribute 16-byte header
0x10 16 8 Content Resident Header Content Resident 8-byte header
Stream Name If applicable
0x00 0 8 Create time Date/Time file created on volume
0x08 8 8 File modified time Date/Time file content changed
0x10 16 8 $MFT modified time Date/Time $MFT content changed
0x18 24 8 Last accessed time Date/Time file accessed
0x20 32 4 File type Flags See Table in Figure 14
Maximum number of
0x24 36 4 Max versions allowed - 0x00 = disabled
versions
0x28 40 4 Version number This file’s version
0x2C 44 4 Class ID
0x30 48 4 Owner ID Owner ID for quota
(version 3.0 +) Reference into SSecure which is
0x34 52 4 Security ID
Index of permissions
0x38 56 8 Quota Charged (version 3.0 +J Bytes from user’s quota
Update sequence number
0x40 64 8 (version 3.0 +) Index to $USN Journal
(USN)
Figure 13 - $Standard_lnformation Attribute data structure

File Type Flags

Hex Binary Description
0x0001 0000 0000 0000 0001 Read only
0x0002 0000 0000 0000 0010 Hidden file
0x0004 0000 0000 0000 0100 System file
0x0020 0000 0000 0010 0000 Archive
0x0040 0000 0000 0100 0000 Device
0x0080 0000 0000 1000 0000 Normal
0x0100 0000 0001 0000 0000 Temporary
0x0200 0000 0010 0000 0000 Sparse file
0x0400 0000 0100 0000 0000 Reparse point
0x0800 0000 1000 0000 0000 Compressed file
0x1000 0001 0000 0000 0000 Offline
0x2000 0010 0000 0000 0000 Content not indexed
0x4000 0100 0000 0000 0000 Encrypted
Figure 14 - File Type Flags
 Offset Length
Name Description
Hex Dec (Bytes)
i 0x00 0 16 Attribute Header Standard Attribute 16-byte header
0x10 16 8 Content Resident Header Content Resident 8-byte header
or
\ Content Non-Resident
j 0x10 16 - Content Non - Resident header
Header
Stream Name If applicable

0x00 0 4 Attribute Type Attribute Type Identifier

0x04 4 2 Record Length Length of this list entry
0x06 Attribute Stream Name
6 1 Num ber o f Unicode characters
Length
0x07 7 1 Offset to Name From beginning o f Attribute Entry
0x08 8 8 Starting VCN in attribute Attribute with multiple data runs
0x10 16 8 $MFT File Record Reference $MFT record that contains attribute
0x18 24 2 Attribute Identifier
0x1A 26 ~ Attribute Stream Name If applicable
- Next Attribute entry Restart at 0x00 on 8-byte boundary
Figure 16 - $Attribute_List Attribute data structure
 Offset Length
Name Description
Hex Dec (Bytes)
0x00 i 0 i 16 Attribute Header Standard Attribute 16-byte header
0x10 I 16 i 8 Content Resident Header Content Resident 8-byte header
Stream Name If applicable
$MFT Record number of the
0x00 0 6 Record for directory in which the file “resides”
parent directory
0x06 Sequence number of the
6 2 How many times parent record has been used
parent directory
0x08 8 8 File name creation time
Not reliable, only updated if file renamed or
0x10 16 8 File name modification time
moved (This only applies to $File_Name
0x18 24 8 $MFT modification time
attributes in the $MFT, not in INDX records)
0x20 32 8 Last access time
0x28 40 8 Allocated size of the index
Only if the record is an index
0x30 48 8 Actual size of the index
0x38 56 4 File type flags See Table in Figure 14
0x3c Used by Extended Attributes or Reparse type
60 4 Reparse value
(mutually exclusive)
0x40 64 1 File name length Unicode characters
0x00 = POSIX, 0x01 = Win32 (LFN),
0x41 65 1 File name type (Namespace)
0x02 = DOS (SFN), 0x03 = Win32/DOS
0x42 66 Varies File name
Figure 17 - $File_Name Attribute data structure

0x40 00 00 00
Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 16 Attribute Header Standard Attnbute 16-byte header
I Content Resident I
i■ 0x10 16 8
Header
Content Resident 8-byte header ;

Stream Name If applicable

0x00 0 16 Object ID GUID Unique Id for file
0x10 16 16 Birth volume GUID Id of volume on which file was created
0x20 32 16 Birth Object GUID First object id assigned to this MFT record
0x30 48 16 Domain GUID ID of Domain in which file created
Figure 19 - SObjectJD Attribute data structure
0x70 00 00 00
Offset Length
Name Description
Hex Dec (Bytes)
0x00 o 16 Attribute Header Standard Attribute 16-byte header
Content Resident
0x10 16 8 Content Resident 8-byte header
Header
Stream Name If applicable
0x00 0 8 Unused 0x00
0x08 8 1 Major Version Number
0x09 9 1 Minor Version Number
0x0001 - Dirty
0x0002 - Resize SLogFile
0x0004 - Upgrade volume next mount
0x0a 10 2 Flags 0x0008 - Mounted in NT
0x0010- Deleting USN journal
0x0020 - Repair Object Ids
0x8000 - Modified by check disk
Figure 21 - $Volume Information Attribute data structure

Content Resident Headers

Offset Length
Name Description
Hex Dec (Bytes)
r *0x00 ' “ O' " 4 ' "Attribute Type identifier 0 x 8 0 00~00~00
0x04 4 4 Length of the attribute L e n g th in b yte s
Content Non-Resident
0x08 8 1 0 x0 0 = R e sid en t, 0x01 = N o n -re s id e n t
Flag
Length of the stream
0x09 9 1 N u m b e r o f U n ico de c h a ra cte rs
name
Offset to the stream
OxOA 10 2 F ro m b e g in n in g o f A ttrib u te
name
OxOC 12 2 Flags C o m p re ssed , S parse, E n c ry p te d
OxOE 14 2 Attribute Identifier In s e q u e n tia l o rd e r A ttrib u te a d d e d

0x10 16 4 Size of the content A ttrib u te C o n te n t size in byte s

; 0x14 20 2 Offset to the content O ffse t fro m s ta rt o f a ttrib u te in b yte s

Stream Name /
0x18 24 ~ F ile data
Attribute Content
Figure 22 - Attribute Header & Content Resident Header data structures
 Offset Length
Name D e scrip tio n
Hex Dec (bytes)
0x00 0 4 Attribute Type Identifier 0 x8 0 00 00 00
0x04 4 4 Length of the attribute L e n g th in b yte s
Content Non-Resident
0x08 8 1 0 x0 0 = R esident, 0x01 = N o n -re s id e n t
Flag
Length of the stream
0x09 9 1 N u m b e r o f U nicode c h a ra cte rs
name
OxOA 10 2 Offset to the stream name F ro m b e g in n in g o f A ttrib u te
OxOC 12 2 Flags C om p re ssed , S parse, E n c ry p te d
OxOE 14 2 Attribute Identifier In s e q u e n tia l o rd e r A ttrib u te a d d e d

"o xîcT " -" Î6 " T Starting VCN of the run list V irtu al C lu s te r N u m b e r (V C N ) - re la tive to
0x18 24 8 Ending VCN of the run list sta rt o f d ata its e lf
0x20 32 2 Offset to the run list B yte s fro m s ta rt o f A ttrib u te
0x22 34 2 Used for compression
0x24 36 4 Unused
0x28 40 8 Allocated size P h y s ic a l size o f the co n te n t in b yte s
0x30 48 8 Actual size L o g ic a l size o f the co n te n t in b y te s
0x38 56 8 Initialized size In itia liz e d size o f the co n te n t in b yte s
Stream Name and/or Run
List
Figure 25 - Attribute Header & Content Non-Resident Header

Run Lists
Run 1 Run 2...
Header Length Starting Extent Header Length Starting Extent
SE I L Clusters Offset relative to SE i L Clusters Offset relative to first
bytes i bytes in Frag. LCN 0 bytes j bytes in Frag. cluster of p re v io u s extent
Figure 28 - Run List data structure
(SE = starting extent, L = length)
INDX types
Stream Name Index Content Utilized by
$130 File Names Directories
$SDH Security Descriptors SSecure
$SII Security Identifiers SSecure
$0 Object Identifiers $Objld
$0 Owner Identifiers SQuota
$Q Quotas SQuota
$R Reparse Points SReparse
Figure 32 - NTFS Index types

0x90 00 00 00

Offset Length
Name Description
Hex Dec (Bytes)
0x00 o 16 Attribute Header Standard Attribute 16-byte header
0x10 16 8 Content Resident Header Content Resident 8-byte header
Stream Name Identifies type o f Index
0x00 0 4 Attribute type Type of Attribute stored in Index
0x04 4 1 Collation Sorting rule Method of sorting index - 0x01 = Filename
0x08 8 4 Size of index record Size of Index Buffer in bytes (child nodes)
0x00 12 1 Clusters in index record Size of Index Buffer in clusters
0x10 16 16 Node Header See Table in Figure 35
Figure 34 - $lndex_Root data structure

INDX Node Header

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 4 Offset to index entry list Relative to Node Header in bytes
0x04 4 4 Offset to end of used area Actual size Index Buffer
0x08 8 4 Offset to end of Index BufferAllocated size of the Index Buffer
12 4 0x00 = no child nodes, 0x01 = child node(s)
OxOC Flags
present
Figure 35 - Node Header data structure

INDX entry
Offset Length
Name Description
Hex Dec (Bytes)
$MFT Record Number of
0x00 0 8 Record number & sequence count
entry
0x08 8 2 Length of this entry Length in bytes
OxOA 10 2 Length of attribute content $File Name attribute content length
OxOC 12 2 Flags 0x00 = no child nodes, 0x01 = child node(s)
present
0x10 16 Varies Attribute $File_Name attribute - content only, see Table
in Figure 17 for data structure
8 VCN of child node If child node, then VCN in Index Buffers
Figure 36 - Index Entry data structure
 Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 4 Signature INDX
0x04 4 2 Offset to fix-up array Normally 0x28 - 40 bytes
0x06 6 2 Entries in fix-up array Depends on sector & INDX buffer sizes
0x08 8 2 SLogFile sequence number Transaction entry number in SLogFile
0x10 16 8 VCN of this child node
0x18 24 16 Node Header See Table in Figure 35
0x28 40 Fix-up array
See Table in Figure 36 - starts on 8-byte
0x50 80 Index Entries
boundary
Figure 38 - Index Buffer Header data structure

OxCO 00 00 00
Offset Length
Name D escription
Hex Dec (Bytes)
! 0x00 0 16 Attribute Header S tandard A ttribute 16-byte hea de r
0x10 16 ____8____ Content Resident Header C ontent R esident 8-byte header
or
Content Non-Resident
j 0x10 16 ~ C ontent Non - R esident h ea d e r
Header
Stream Name If applicable
0x20000000 Is Alias
0x68000005 Native Structured Storage
0x68000007 Single Instance Storage
Reparse type flags 0x68000008 Distributed File System
0x00 0 4
(not all types listed) 0x80000000 Is Microsoft
0x88000003 Mount point
0xA0000003 Symbolic link
0xA8000004 Hierarchical Storage Management
0x04 4 2 Reparse data length # o f bytes
0x08 8 2 Offset to target name R elative to byte 16 o f R eparse content
OxOA 10 2 Target name length # o f bytes
0x00 12 2 Offset to print name R elative to byte 16 o f R eparse content
OxOF 21 2 Print name length # o f bytes
Figure 41 - $Reparse_Point Attribute data structure

Rule of Orphans
Parent sequence number Parent allocation status Parent-child relationship status
Match Allocated Valid
+1 Un-allocated Valid (parent deleted)
+1 or more Allocated or unallocated Broken (orphan)
Figure 44 - Rules for Orphan files
$USN Journal entry
Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 4 Size of entry
0x04 4 4 Version 2 bytes major, 2 bytes minor
0x08 8 8 $MFT record number of file
File/directory that caused this entry
0x10 16 8 $MFT record number of parent
0x18 24 8 USN for entry USN from USN in File Record Header
0x20 32 8 Timestamp
0x28 40 4 Change Reason See Table in Figure 47
0x2C 44 4 Source Information Source of change (can be application)
0x30 48 4 Security ID of file
0x34 52 4 File Attributes
0x38 56 2 Size of file name
0x3A 58 2 Offset to file name Normally 0x3C
% File Name
Figure 45 - $USN Journal entry data structure

$USN Journal entry reason

Value Reason
0x00000001 Default SData attribute was overwritten
0x00000002 Default $Data attribute was extended
0x00000004 Default SData attribute was truncated
0x00000010 A named SData attribute was overwritten
0x00000020 A named SData attribute was extended
0x00000040 A named SData attribute was truncated
0x00000100 The File/directory created
0x00000200 The File/directory deleted
0x00000400 Extended attributes changed
0x00000800 Security descriptor changed
0x00001000 Name changed - this entry has old name
0x00002000 Name changed - this entry has new name
0x00004000 Content Indexed status change
0x00008000 Basic attributes changed
0x00010000 Hard link created/deleted
0x00020000 Changed compression status
0x00040000 Changed encryption status
0x00080000 Object ID changed
0x00100000 Reparse point value changed
0x00200000 Named SData attribute created/deleted/changed
0x80000000 File/directory closed
Figure 47 - $USN Journal change reason
XXII.Answer Key

File record Header, page 11

• Signature - FILE File Reference - 0 (Base record).

• $LogFile Sequence # - 0x30049EB (50350571 ) Fix-up check value - 0x14 0x00.
• Sequence Count - 0x01 (first time used). Fix-up value Sector 1 - 0x6E 0x63.
• Allocation Flag - 0x01 (Allocated File). Fix up value Sector 2 - 0x00 0x00.
• Logical Size - 0x270 (624) bytes. MFT Record - 0x23 (35).
• Physical Size - 0x400 (1024) bytes. Next Attribute Id - 0x05.

Standard Information Attribute, page 18:

i
Header Content
• Attribute Type - 0x10 = Standard Information. Created - 12/12/2012, 23:24:20.
• Attribute Length - 0x60 (96) bytes. File Modified - 12/12/2012, 12:12:12.
• Resident Flag - 0x00 = Content resident. $MFT Modified -17/12/2012, 02:20:36.
• There is no “stream” name. Accessed -12/12/2012, 23:24:20.
• Flags - 0x00 = not set. Flags - 0x20 = Archive.
• Attribute Identifier - 0x00 = first attribute added. Security id - 0x0105 (261).
• Size of Content - 0x48 (72) bytes. USN - 0x12C0 (4800).
• Offset to content - 0x18 (24) bytes.

© 2018 IACIS NTFS Page 67 of 74

 Header Content
• Attribute type - 0x30 = File Name. • Parent $MFT Record - 0x05 = Root.
• Attribute Length - 0x88 (136) bytes. • Parent Sequence - 0x05 = used 5 times.
• Resident Flag - 0x00 = Content resident. . Created - 12/12/2012, 23:24:20.
• There is no “stream” name. • File Modified - 13/12/2012, 21:00:10.
• Flags - 0x00 = not set. . $MFT Modified - 13/12/2012, 21:00:10.
• Attribute Identifier - 0x03 = fourth attribute added. • Accessed - 12/12/2012, 23:24:20.
• Size of Content - 0x70 (112) bytes. • Flags - 0x20 = Archive.
• Offset to content - 0x18 (24) bytes. • File Name Length - 0x17 (23) Unicode
Characters.
• File NameSpace - 0x00 = POSIX.
• File Name = 01 Resident Content.txt.

Data Attribute - content Resident, page 27:

Header Content

• Attribute Type - 0x80 = Data. File content.

• Attribute Length - 0x198 (408) bytes. A text file (*.txt)

• Resident Flag - 0x00 = Content resident.

• “Stream” name - no stream name.

• Flags - 0x00 = not set.

• Attribute Identifier - 0x01 = Second Attribute

added.

• Size of Content - 0x17C (380) bytes.

• Offset to Content - 0x18 (24) bytes.

• Attribute Type - 0x80 = Data. • Start VCN - 0 = First Cluster of file.
• Attribute Length - 0x50 (80) bytes. • End VCN - 0x08 = nine clusters in file.
• Resident Flag - 0x01 = Content non­ • Offset to Run List - 0x40 (64) bytes.
resident. • Allocated size - 0x9000 (36,864) bytes.
• There is no “stream” name. • Actual size - 0x8175 (33,141) bytes.
• Flags - 0x00 = not set. • Initialized size - 0x8175 (33,141) bytes.
• Attribute Identifier - 0x03 = fourth attribute
added.
 (2 l)0 3 jD A Q D (^ j)o ij4 A F 2 ^ T )0 5 jb 5 FE 03 (0 0 )E A A E

Run List Entry 1

1. The header of the first run:_____21 Length of run:________3_________bytes.

o The first run content is: 03 DA 0D___________________________

2. The right nibble shows how many bytes to use for the fragment length = ______1

o Fragment one is _____ 3________clusters long.

3. The left nibble shows how many bytes for starting extent (offset) = _______2________

o Fragment one starting extent Ox ODDA_______Dec______ 3,546_________

4. Fragment 1 starts at Logical Cluster Number_______3,546____________________

Length
Start Extent Start LCN End LCN
(Clusters)
Entry 1
3,546 3 3,546 3,548

Run List Entry 2

5. The header of the second run:_____21______ Length of run:______ 3___________ bytes.

o The second run content is: 01 4A F2______

6. The right nibble shows how many bytes to use for the fragment length = ______1________

o Fragment two is _____1_________clusters long.

7. The left nibble shows how many bytes for starting extent (offset) = ______2_____________

o Fragment two starting extent Ox F24A_____Dec -3,510_______________

8. Fragment 2 starts at Logical Cluster Number 3,546______+ -3,510 = _____36

6.
Start Extent Length Start LCN End LCN
Entry 2
-3,510 1 36 36
Run List Entry 3

9. The header of the third run: 31_______ Length of run:______ 4___________bytes.

o The third run content is: 05 65 FE 03____________

10. The right nibble shows how many bytes to use for the fragment length = _____1________

o Fragment three is 5_________clusters long.

11. The left nibble shows how many bytes for starting extent (offset) = 3______________

o Fragment three starting extent Ox 03FE65_____Dec_____ 261,733__________

12. Fragment 2 starts at Logical Cluster Number 36 + 261,733 = 261,769

13. Last Cluster - Allocated Size 36,864 - Actual size 33,141 = 3,723 bytes

o Cluster Size (4096) - Slack 3,723______ = ______373________bytes of file content.

7.
Start Extent Length Start LCN End LCN Bytes
Entry 3
261,733 5 261,769 261,773 373

Run List Entry 4 - The header of the fourth run: 00 = End of Run List
Additional Practice for Labs/self-study
Manual Run List:
Allocated size: 6 0 3 ,16 0,576 bytes_________ Actual size: 6 0 3 ,15 5,340 bytes
Run List:

@ 0 A j H © 7 6 j| B 4 7 4 0 0 2 lO jF C DB F F 0 O O 00 0 1 ;F9 4 5 @ 1 A 0FÍ4B F 0 © 19
Lemgth Start Extent Start LCN End LCN
Entry 1
OxOA 10 0x74 116 116 125

Length Start Extent Start LCN End LCN

Entry 2
0x76 118 0x74 B4 29,876 29,992 30,109

Len<gth Start Extent Start LCN End LCN

Entry 3
0x1002 4,098 OxFFDBFC -9,220 20,772 24,869

Lemgth Start Extent Start LCN End LCN

Entry 4
0x10000 65,536 0x45F9 17,913 38,685 104,220

Final Cluster
Length Start Extent Start LCN End LCN
Bytes
Entry 5
2,956 file data
0xF1A 3,866 0xF04B -4,021 34,664 38,529
5,236 slack

Cluster size can be calculated by dividing File Allocated size by total number of clusters.

Total clusters = 73,628. Allocated size = 603,160,576. Cluster Size = 8,192 bytes (16 sectors)
Allocated size: 52,563,968 bytes____________ Actual size: 52,560,731 bytes_____

Run List:

(32)20 10 F6 00 05<32)A3 21 25 00 FC ( 0 5 E FC 5F 07 01

Length Start Extent Start LCN End LCN

Entry 1
4,128 327,926 327,926 332,053

Length Start Extent Start LCN End LCN

Entry 2
8,611 -262,107 65,819 74,429

Final Cluster
Length Start Extent Start LCN End LCN
Entry 3 Bytes

94 483,324 549,143 549,236 859

Allocated size: 52,563,968

Actual Size:__________ 52,560,731
Slack space = 3,237 bytes slack (unused space in the last cluster)

Cluster size: 4,098 bytes

Slack Space:________ 3,237

File uses 859 bytes of final cluster
Allocated size: 78,614,528 Actual size:_____ 78,611,105 Initialised size: 200____
Run List:

@ 3D 42 2D O A 0O 2 FD F5@ F5 07 EC 60 O 8 0 7 F 7E 91 F 8 0 4 6 5B B3 0 6 @

Length Start Extent Start LCN End LCN

Entry 1
16,957 2,605 2,605 19,561

Length Start Extent Start LCN End LCN

Entry 2
2 -2,563 42 43

Length Start Extent Start LCN End LCN

Entry 3
2,037 549,100 549,142 551,178

Length Start Extent Start LCN End LCN

Entry 4
127 -487,042 62,100 62,226

Final Cluster
Length Start Extent Start LCN End LCN
Entry 5 Bytes

70 439,131 501,231 501,300 673

Only the first 200 bytes in Fragment 1 of this file have been initialised (written) to the disk. The remainder is all
slack space - including fragments 2 - 5 .

©2018 IACIS NTFS Page 74 of 74

IAC IS
The International Association of
Computer Investigative Specialists
Extensible FAT
Windows File Systems

Contents
I. Synopsis......................................................................................................................................................1
II. Learning Objectives................................................................................................................................... 2
III. History of exFAT........................................................................................................................................ 2
IV. Regions of the exFAT File system............................................................................................................. 2
V. ExFAT Volume Format Options................................................................................................................. 5
VI. Data Region............................................................................................................................................... 9
VII. Volume Label Directory Entry.................................................................................................................. 13
VIII. Allocation Bitmap Directory Entry............................................................................................................. 14
IX. UpCase Table Directory Entry................................................................................................................. 15
X. Volume GUID Directory Entry.................................................................................................................. 16
XI. TexFAT Padding Directory Entry............................................................................................................. 17
XII. Windows CE Access Control Table Directory Entry................................................................................. 17
XIII. File Directory Entry................................................................................................................................... 18
XIV. Stream Extension Directory Entry............................................................................................................ 22
XV. File Name directory entry......................................................................................................................... 24
XVI. File creation, Deletion, and Recovery...................................................................................................... 27
XVII. Consolidated Tables................................................................................................................................ 32

Synopsis
Extended File Allocation Table (exFAT) is the successor to FAT32 in the Microsoft FAT family of file
systems. The exFAT file system is designed to overcome file and volume size limits that exist in the
previous FAT versions, and allow for future proofing. The exFAT file system also bridges the gap between
FAT, which is a very simple file system with little overhead, and NTFS, which is a very complex file system
with a large amount of data structure overhead. The current revision of exFAT is 1.00, which is what this
module is based on.
 Learning Objectives
This module describes how the exFAT file system organizes data. Understanding the rules of an exFAT
volume will aid with locating and recovering evidence that would be hidden to the casual user. At the
conclusion of this lesson, the student should understand:
1. The data structures of the exFAT file system.
2. The file creation and deletion process.
3. How to manually recover data from an exFAT file system.

III. History of exFAT

Portable computing devices have become increasingly popular as technology innovations have created
faster and more powerful systems in smaller packages. These innovations are not limited to just personal
computers and laptops. Smart phones, digital cameras, in fact any portable device, are now creating and
utilising very large files in order to create a more "life-like” user experience. These devices generally rely
on portable (removable) media to store data.

To cope with larger file sizes and the development of increasing storage device capacity, Microsoft
determined that a file system with greater flexibility in its format was required. Current file systems do not
provide the flexibility of being suitable for removable media, are not capable of handling very large files,
or capable of controlling very large volumes, do not allow fast and efficient access.

FAT32 has a file size limit of 4 GigaBytes, where exFAT has a theoretical maximum file size of 16

r ExaBytes. The exFAT file system was first supported by WindowsCE, which was released November
2006 (Tilley, 2009). In February 2010, Sandisk shipped the first 64 GigaByte Secure Digital card, which
Q uses exFAT (Sandisk Corporation, 2010).

The exFAT file system has been developed and registered for patent by Microsoft. Its name would
suggest that it has been built on FAT principles, and certainly there are some components of the FAT file
system that have been carried over. However, in addition to new terminology, the actual implementation
and use of those principles have been so significantly changed that the exFAT file system needs to be
examined in isolation to FAT.
The exFAT file system can be used with the following Microsoft operating systems:
• Windows XP, Service Pack 2 with KB955704 applied
• Windows Server 2003 with KB955704 applied
• All versions from Windows Vista

IV. Regions of the exFAT File system

The exFAT file system is comprised of four main regions. Each region contains a variety of components
that have their own data structure. The main regions are:
1. Main Boot Region
2. Backup Boot Region
3. FAT Region
4. Data Region
The first three regions are used by the file system; however the data area also contains files that comprise
part of the actual file system, much like NTFS. The physical locations of the file system area are fixed
according to the exFAT specification, and are graphically shown in Figure 1.

Main Boot Backup Boot

FAT Region Data Region
Region Region

Y
FILE SYSTEM AREA

Figure 1 - exFAT Regions

Main Boot Region & Backup Boot Region

The Main Boot Region and the Backup Boot Region have the same sub-regions and data structure. On
an exFAT volume, the Backup Boot Region immediately follows the Main Boot Region, and is an identical
copy of the Main Boot Region. This chapter provides the data structure of both regions and will refer to
them both as the Boot Region.
The Boot Regions are created when the volume is formatted, and can be further broken down to five
separate data structures called sub-regions. Each sub-region name is preceded by "Main" or “Back-up”
depending on whether it is in the Main Boot Region or Backup Boot Region respectively. The list of Boot
Region sub-regions is:
1. Boot Sector
2. Extended Boot Sectors
3. OEM Parameters
4. Reserved
5. Boot Checksum

What used to be called the Volume Boot Record (VBR) in FAT has been re-labelled the Boot Sector in
exFAT. As with all other versions of Microsoft file systems, exFAT also retains the Boot Signature of
0xAA55. The following two sub-regions allow more space for boot strapping instructions and the ability
for a manufacturer to include specific OEM parameters. The exFAT file system specification provides
fixed lengths for each sub-region. Figure 2 provides a graphical overview of the Boot Region layout.

Main Boot Region Backup Boot Region

Main Boot Sector 0 Backup Boot Sector 12

Main Extended Boot Sectors 1 Backup Extended Boot Sectors 13

Main OEM Parameters 9 Backup OEM Parameters 21

Main Reserved 10 Backup Reserved 22

Main Boot Checksum 11 Backup Boot Checksum 23

Figure 2 - Boot sub-Regions with Sector Address

 The Main Boot Sector is located at Sector 0 of the volume. The Main Boot Sector contains boot-strapping
code and fundamental exFAT parameters that provide the volume definitions. Figure 3 gives the data
structure for the Main Boot Sector.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 0x03 Jump boot Jump instruction to Boot Code Field
0x03 3 0x08 File system name A S C II-exFA T
OxOB 11 0x35 Must be zero Replaces FAT BIOS parameter block
0x40 64 0x08 Partition offset Sectors from start of media
0x48 72 0x08 Volume length Total sectors in volume
0x50 80 0x04 FAT offset Logical start sector of FA T
0x54 84 0x04 FAT length Length of FAT table in sectors
0x58 88 0x04 Cluster heap offset Logical start sector of cluster heap
0x5C 92 0x04 Cluster count Number of clusters in cluster heap
0x60 96 0x04 First cluster of root directory Root directory start cluster
0x64 100 0x04 Volume serial number
0x68 104 0x02 File system revision M ajor/ minor
0x6A 106 0x02 Volume flags See Table in Figure 4
Power of 2 value for bytes per sector - range 9
0x6C 108 0x01 Bytes per sector shift
- 12 (512 - 4096 bytes)
Power of 2 value for sectors per cluster - range
0x6D 109 0x01 Sectors per cluster shift
0 -2 5 (1 -3 3 ,5 5 4 ,4 3 2 )
0x6E 110 0x01 Number of FATs 0x00 = FAT 1, 0x01 = FAT 2
0x6 F 111 0x01 Drive select Extended INT 0x13 drive number
0x70 112 0x01 Percent in use 0x00 - 0x64. OxFF = not available
0x78 120 0x186 Boot code Boot-strapping instructions
0x01 FE 510 0x02 Boot signature 0xAA55
0x0200 512 Excess space (If sector >512 bytes)
Figure 3 - Boot Sector Data Structure

Bit Name Description

0 Active FAT Which FAT and Bitmap are in use 0 = first FAT, 1 = second FAT
1 Volume dirty 0 = volume consistent, 1 = potentially inconsistent
2 Media failure 0 = any known failures marked “bad” clusters, 1 = media reported failures
3 Clear to zero No significant meaning in Revision 1.00
4 Reserved Bits 4 - 1 5 Reserved
Figure 4 - Boot Sector Volume Flags

The Boot Sector Signature 0xAA55 will always be at offset 0x01 FE regardless of the sector size. For
example, if the sector size was 1024 bytes, the signature would not be relocated to the end of sector 0.
Therefore it is important to read the bytes per sector field of the Boot Sector in an exFAT volume.

Figure 5 shows an exFAT Boot Sector which can be interpreted with Figures 3 and 4.
 Of fset 0 1 2 3 4 5 6 7 8 9 A B C D E F / .
00000000 EB 76 90 45 58 46 41 54 20 20 20 00 00 00 00 00 ev EXFAT
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000040 00 00 00 00 00 00 00 00 00 04 IE 00 00 00 00 00
00000050 80 00 00 00 00 01 00 00 80 01 00 00 0A 78 00 00 1 1 X
00000060 04 00 00 00 25 EE A8 76 00 01 00 00 09 06 01 80 y.iv i
00000070 00 00 00 00 00 00 00 00 33 C9 8E D1 BC F0 7B 8E 3E|fT>s6{l
00000080 D9 A0 FB 7D B4 7D 8B F0 AC 98 40 74 OC 48 74 0E 0 u > ' } | 6 ' l @ t Ht
00000090 B4 0E BB 07 00 CD 10 EB EF A0 FD 7D EB E6 CD 16 » 1 ei y}e#I
000000A0 CD 19 00 00 00 00 00 00 00 00 00 00 00 00 00 00 I
000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ooooooco 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000000F0 00 00 00 00 00 00 00' 00 00 00 00 00 00 00 00 00
00000100 0D 0A 52 65 6D 6F 76 65 20 64 69 73 6B 73 20 6F Remove disks o
00000110 72 20 6F 74 68 65 72 20 6D 65 64 69 61 2E FF 0D r other media.y
00000120 0A 44 69 73 6B 20 65 72 72 6F 72 FF 0D 0A 50 72 Di s k e r r o r y Pr
00000130 65 73 73 20 61 6E 79 20 6B 65 79 20 74 6F 20 72 e s s a n y k e y to r
00000140 65 73 74 61 72 74 0D 0A 00 00 00 00 00 00 00 00 estart
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
000001B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF yy
000001C0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF yyyyyyyyyyyyyyyy
000001D0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF yyyyyyyyyyyyyyyy
000001E0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF yyyyyyyyyyyyyyyy
000001F0 FF FF FF FF FF FF FF FF FF FF FF 00 IF 2C 55 AA yyyyyyyyyyy . U-

Figure 5 - Boot Sector Hex View

V. ExFAT Volume Format Options

There are a variety of values available for the Main Boot Sector fields, depending on what options were
selected when the volume was formatted. The exFAT file system was specifically designed for large files
and volumes; Microsoft states a theoretical maximum of 64 Zb and a recommended maximum volume
size of 512 TB. (Microsoft, 2015). The specifications from the exFAT file system Patent provided the
Main Boot Sector value ranges, which equate to:
• Sector size range: 512 - 4096 Bytes. (MBS field Bytes per sector shift.)
• Cluster size range: 1 - 33554432 Sectors. (MBS field Sectors per Cluster shift.)
• Volume Size (calculated from max cluster size, noting the 4 byte limit in FAT addressing):
• Maximum Sector size = 4096 bytes - 212
O Maximum Cluster size = 33,554,432 sectors - 225.
o Maximum Clusters in Volume = 4,294,967,296 - 232.
o Maximum volume = 212*2 25 * 232 = 269 - 590,295,810,358,705,651,712 bytes.
 Default Cluster Size.
While testing, a variety of different volume sizes were formatted with exFAT in order to determine default
cluster size settings relative to volume size. Microsoft support provides a table of default cluster size,
which is referenced in Figure 6. The third column shows the results of testing with Windows 7.

Microsoft Support Table - Windows

Volume Size Windows 7 testing Volume Size
XP, Vista, Server 2008
7 MB-256 MB 4 KB
256 MB-32 GB 32 KB 32 Kb 1 Gb
32 GB-256 TB 128 KB 128 KB 32 Gb - 511 Gb
256 Kb 512 Gb - 1023 Gb
> 256 TB Not supported 512 Kb 1024 Gb - 2 Tb
Figure 6 - Default Cluster Size

While testing, it was noted that a volume on a hard disk drive needed to be 32 GB or larger in order to
format with exFAT file system when using the Graphical User Interface (GUI). USB flash drives that were
smaller than 32 GB could be formatted exFAT through the GUI. It was also noted that a USB flash drive
had a Master Boot Sector written to it when reformatted exFAT from NTFS.

Extended Boot Sectors

The Extended Boot Sectors comprise the next eight sectors and are used to store large boot programs.
Each sector has the same structure and may hold distinct-boot strapping instructions. The last four bytes
of the sector hold the Extended Boot Signature, which is 0xAA550000, regardless of the sector size. For
example, if a sector size was 1024 bytes, the last four bytes would hold the Extended Boot signature,
which is the opposite of what occurs with the Boot Sector Signature.

In developing this module, no Extended Boot Sector code has been observed.

O EM Parameters
The OEM Parameters sub-regions are designed to contain manufacturer specific information. The data
structure allows for ten parameters that are 48 bytes long. Each parameter field immediately follows the
previous, as shown in Figure 7.

The first 16 bytes of a Parameters field contains the Parameter GUID. This is then used to determine
how the rest of that field is structured.

After 480 bytes, the remainder of the sector is unused. The exFAT specification states that all used
Parameters should fill the beginning of the array, and all unused structure are consolidated at the end of
the array.
In developing this module, no OEM Parameters have been observed.
 o r GUID Parameter
Main Boot Sector 0 „ ="32 bytes
1 GUID Parameter
Main Extended Boot Sectors 1
GUID Parameter
Main OEM Parameters 9
9 GUID Parameter
Main Reserved 10
Remainder of cluster unused
Main Boot Checksum 11

Figure 7 - OEM Parameters Structure

Checksum
The Checksum sub-region contains a four byte (32 bit) checksum of the contents of all the other sub-
regions of the Boot Region. The “volume flags” and “percentage in use fields” are not included in the
checksum calculation. The checksum value is repeated through the entire Checksum cluster, as shown
in Figure 8.

Offset 0 1 2 3 4 5 6 7 8 9 À B C D E F
00001600 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 è )Sfrè )îfrè )îfrè )Hr
00001610 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 è )îfrè )îfrè )îfrè )îfr
00001620 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 è )îfrè )îfrè )îfrè )îfr
00001630 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 è )îfrè )îfrè )îfrè )îfr
00001640 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 è )îfrè )îfrè )îfrè )îfr
00001650 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 è )îfrè )îfrè )îfrè )îfr
00001660 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 E8 29 D1 72 è )îfrè )îfrè )îfrè )îfr

Figure 8 - Checksum Hex View

FAT Region
Sector 24 of an exFAT volume marks the beginning of the FAT region. The File Allocation Table (FAT)
is a flat table containing information about the location of file data within the volume. The exFAT file
system does not operate the FAT in the same way as the FAT32 file system. There are two major
changes:
• The exFAT file system does not utilise the FAT for cluster allocation status - this is now done by a
Bitmap file.•

• The exFAT file system utilises the FAT for fragmented files only; if a file is located in contiguous
clusters (not fragmented) the FAT is unused for that file. This is determined by the flags in the
directory entry for that file which will indicate if the file is contiguous or fragmented. It does however
have entries for the two system files.
 Although Sector 24 is the start of the FAT region, the first FAT will not necessarily be located at the
beginning of the FAT region. Microsoft describes First and Second FAT sub-regions, and the Boot Sector
“FAT offset field" provides the start cluster for the first FAT.

The current version of exFAT only contains one FAT sub-region. The second FAT sub-region is only
used in the Transaction-Safe exFAT (TexFAT) version. The TexFAT file system is designed specifically
to provide transaction-safety for data stored on a disk, and requires a hardware-specific driver designed
for the type of media on which the TexFAT volume resides. (Microsoft Developer Network, 2008) The
Boot Sector shows how many FATs the volume contains and which FAT is currently active if more than
one is present (in use).

Normally in exFAT we see one FAT table and it only records fragmentation of the non-system files. The
allocation status of the clusters is recorded in a Bitmap file.

FA T Table Values
The exFAT file system uses four byte values for each entry within the FAT table, which is unchanged
from FAT32.
• The first entry in the FAT table (FAT Entry 0) is the “Media Type”, which should always be FF FF
FF F8.
• The second entry (FAT Entry 1) only exists due to historical precedence and should always be
OxFFFFFFFF.

The remaining entries are used to describe file cluster pointers in the same manner as FAT32. Some
entry definitions have been modified from FAT32 and are shown in Figure 9.

Symbolic Value Hex Value Description

Media Type FFFFFFF8 Pre-determined value.
0x00000003 -
Next Cluster Numerical value indicating the next cluster for a fragmented file.
0xFFFFFFF6
End of File OxFFFFFFFF Last cluster within a cluster chain.
Corrupt Cluster. If a cluster is marked bad, the media failure flag will
Bad Cluster 0xFFFFFFF7
also be set in the Boot Sector.
Figure 9 - FAT Table Values

One of the key changes shown in Figure 9 is that 0x0000000 has no meaning. As the FAT is no longer
used to track cluster allocation, 0x00000000 could indicate either the cluster is unallocated or the cluster
contains a file that is not fragmented.

Although the FAT is only utilized for files that are fragmented, testing has shown that the FAT is still valid
and utilized for file system files and for the Root Directory, regardless of whether they are fragmented or
not. In fact, the FAT is the only way to determine the size and location of the Root Directory. The FAT
as shown in Figure 10 has been taken from a volume with a cluster size of 32KB, containing 28 folders
and 155 files that add up to 1.03 GB; however the FAT only shows entries 2 - 4 in use.
 Of f s e t 0 1 2 3 4 5 6 7 8 9 À B c D E F 1
00010000 F8 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF oyyyyyyyyyyyyyyy
00010010 FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 yyyy
00010020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00010030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00010040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00010050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00010060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00010070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00010080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00010090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Figure 10 - FAT Hex View

VI. Data Region

Traditionally, the data region is where the directory tree and user related file content would be located in
a FAT file system. In an exFAT file system, the data region contains the Cluster Heap, which manages
space for file system structures, directories, and files.

The most significant changes are that there are ten different types of Directory Entry, no support for DOS
compliant file names, the addition of two system files - which come with their own specific type of directory
entry, and no dot or double-dot directory entries. This section will explain the system files that are located
within the Data Region and then examine directory entries in detail.

Allocation Bitmap
The first system file in the Cluster Heap is the Allocation Bitmap. The purpose of this file is to record the
allocation state of clusters within the Cluster Heap. The current version of exFAT only has one Allocation
Bitmap, but TexFAT will have two, which works in conjunction with the second FAT to enable transactional
logging of file system alterations.

An Allocation Bitmap uses packed bytes - one bit is a flag to record the status of each cluster within the
Cluster Heap; a zero indicates that the cluster is unallocated, and a one indicates that the cluster is
allocated (in use). Each byte within the Allocation Bitmap shows the allocation status of eight clusters.
The Bitmap represents clusters starting from the Logical Cluster Number (LCN) 2, as Clusters 0 and 1
are reserved, in keeping with previous versions of FAT. When an exFAT volume is formatted, the
Allocation Bitmap is created, typically starting in Cluster 2, and the Bitmap field for that cluster (and any
others in use) is changed to 1.

To locate the allocation bit for a sector, divide the sector number by 8. The whole number will be how
many bytes in the Allocation Bitmap before the desired packed byte. Multiply the whole number by 8 and
add 2 to determine the sector number of the first Bit of the next byte, and count through the Bits to the
desired Cluster number.

For example, locate the allocation flag for Cluster 35: 35/8 = 4.375. 4*8 = 32 + 2 = 34.
Byte 5 (Offset 0x04) of the Allocation Bitmap represents Clusters 34 - 41, 00000010 - Cluster 35 is
allocated.
UpCase Table
The second system file in the Cluster Heap is the UpCase table. The exFAT file system uses only Unicode
characters for file names in directory entries. In addition, exFAT is case insensitive and case preserving.
During search operations, file names are only searched in their upper-case format, so exFAT needs to
be able to convert the file names to upper-case during search operations. The UpCase Table is actually
just a list of Unicode characters. (NTFS.com)

The UpCase table is typically found in Cluster 3 on volumes with a large cluster size, but could be
relocated anywhere in the volume, or could be pushed further down if the Cluster Bitmap requires more
than one cluster. The UpCase table is just under 6 KB in size. Should the volume be formatted with a
very large cluster size, there will be a large amount of slack space. This slack area could potentially be
used to hide evidence.

The Allocation Bitmap and the UpCase table files do not have a file name recorded on-disk.

Root Directory
The exFAT file system has maintained the directory tree approach to manage sub-directory and file
structures, starting with the Root directory. The starting cluster of the Root directory is normally located
in the next cluster after the UpCase Table. The Root directory acts like a file in that it will grow in size
and may become fragmented, which is tracked through the FAT. The Main Boot Sector provides the start
cluster of the Root directory, but not its size. The FAT must be consulted in order to determine if the Root
directory is greater than one cluster.

When an exFAT volume is formatted, the first cluster of the Root directory is overwritten with 0x00, while
the remaining clusters are not changed.

Directory Entries
There are currently ten different types of directory entry within the exFAT file system, each with their own
role and data structure. An individual file can have up to 19 directory entries to describe its status; this is
called a directory entry set.

This section will explain how to identify each directory entry type and the data structure of the directory
entry.

Microsoft used two new names for file sizes in their patent application being ‘‘Data Length” and
“Valid Data Length", which correlate to “Initialized Size", and “Actual Size" respectively.
Allocated Size is not recorded, similar to previous FAT versions.
 As the exFAT file system has ten different directory entries, there needs to be a way of determining what
type of directory entry is being examined. This is the role of the first byte of every directory entry, and is
called the Entry Type. The entry type contains four components, represented by binary bits, as shown in
Figure 11.

Bit Length Description

0 5 Type Code.
5 1 Type Importance - 0 = Critical, 1 = Benign.
6 1 Type Category - 0 = Primary, 1 = Secondary.
7 1 In Use - 0 - not in use, 1 = in use.
Figure 11 - Entry Type Field Structure

The first five bits are the type code, which determines what is the actual purpose or role of the directory
entry, and what kind of information the directory entry will contain. The remaining three bits are flags
which indicate Type Importance, Type Category and In Use status.

Im portance
Microsoft gave exFAT directory entries a hierarchical structure to classify the importance and category of
each entry, as shown in Figure 6. These “classifications” are divided into two parts, being Importance
and Type. There are two levels of directory entry importance, Critical or Benign.

A Critical directory entry contains information that is deemed critical for the management of an exFAT
volume. If critical entries are missing, the volume will not mount.

A Benign entry is optional. If a benign directory entry is in an unrecognized format, then it will be ignored
- if it is part of a directory entry set, the entire set will be ignored. This “feature” makes benign entries
important in a forensic sense, in that they could be used to hide data. Should an unrecognized benign
entry be part of a directory entry set for an evidential file, that file would not be displayed as exFAT will
ignore it.
 There are also two levels of entry type; Primary or Secondary.
Every file has one primary directory entry. The primary directory entry is always the first directory entry
for a file. A single file may have up to 19 directory entries (called a directory entry set). Secondary
directory entries are the additional directory entries that come immediately after the primary directory
entry.

□
Directory Structure

a
Primary Directory Entries
l

□
- Critical Primary Entry Types
□
- Benign Primary Entry Types

□
- Secondary Directory Entries
i
□
- Critical Secondary Entry Types
n
- Benign Secondary Entry Types

Figure 12 - Entry Type hierarchy (USA Patent No. US 2009/02654000 A 1 ,2009)

In use
The final bit is the "in use" flag of a directory entry type and relates only to the directory entry, not
necessarily the file content. An in use flag value of zero may be an indication that a file has been moved
or deleted or it may mean the file content is referenced by a new directory entry. For example, consider
two directory entries with entry types of 0x85 and 0x05, they are the same type, but one is in use, the
other is not:

0x85 (binary 1000 0101)

• Type Code - 00101
• Importance - 0, Critical
• Category - 0, Primary
• In use - 1, In use

0x05 (binary 0000 0101)

• Type Code - 00101
• Importance - 0, Critical
• Category - 0, Primary
• In use - 0, Not in use
A directory entry type of 0x00 represents the end of directory marker. The key thing to remember when
parsing directory entries is that the directory entry type defines the data structure for the remainder of that
directory entry. The ten-different type of directory entries currently used by exFAT are listed in Figure 13.
 Identifier (In Use) Directory Entry Type Identifier (Not in Use)
0x81 Allocation Bitmap 0x01
0x82 UpCase Table 0x02
0x83 Volume Label 0x03
0x85 File 0x05
OxAO Volume GUID 0x20
0xA1 TexFAT Padding 0x21
0xA2 Access Control Table 0x22
OxCO Stream Extension 0x40
0xC1 File name 0x41
Figure 13 - Directory Entry Types

The first three entry types are used for “system files" and the Volume label. The File entry type, the
Stream Extension, and the File Name entry types are used in conjunction as a directory entry set for user
related or “non-system” sub-directories and files. The Volume GUID, TexFAT and Access Control types
are not currently in use. Detailed explanation is provided of each directory entry type in the following
sections.

VII. Volume Label Directory Entry

The first directory entry in the root of an exFAT volume is the Volume Label, which is a critical primary
directory entry. The Volume Label is a Unicode string of up to eleven characters to allow the user to
recognise the volume. This directory entry will exist even if the volume has not been assigned a label.
The data structure is shown in Figure 14.

Offset Length
Name Description
Hex Dec (Bytes)
0x83 - Label assigned
0x00 0 0x01 Entry type
0x03 - No volume label
0x01 1 0x01 Character count Number of Unicode characters in label
0x02 2 - Volume label Volume label in Unicode
0x18 24 0x08 Reserved
Figure 14 - Volume Label directory entry structure

The entry types need to be examined in binary format to understand what is happening with the directory
entry.
Entry type 0x83 (binary 1000 0011)
• Type Code - 00011, Volume Label
• Importance - 0, Critical
• Category - 0, Primary
• In use - 1, In use

Entry type 0x03 (binary 0000 0011)

• Type Code - 00011, Volume Label
• Importance - 0, Critical
• Category - 0, Primary
• In use - 0, Not in use
The type code for a Volume Label directory entry is unchanged; the only difference is whether or not it is being
used, as shown in Figure 15.

FormatOI root directory

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F S3
000A0000 83 08 46 00 6F 00 72 00 6D 00 61 00 74 00 0 00 I F o r la a t 0
000A001G 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1

(Root drectory) root drectcxy

Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F Al
00040000 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00040010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Figure 15 - Volume Label directory entries

VIII. Allocation Bitmap Directory Entry

The exFAT Allocation Bitmap is located within the Cluster Heap as a file, therefore requires its own
directory entry. The second directory entry in the root of an exFAT volume is the record for the Allocation
Bitmap, and is a critical primary directory entry. There is an Allocation Bitmap Directory entry for each
Bitmap that exists within the Cluster Heap - this only applies to TexFAT. One of the unique things about
this system file is that it doesn’t have a file name. The data structure for the Allocation Bitmap directory
entry is shown in Figure 16.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 0x01 Entry type 0x81
1 Bit value - 0 = Bitmap 1,
0x01 1 0x01 Bitmap flags
- 1 = Bitmap 2
0x02 2 0x12 Reserved
0x14 20 0x04 First cluster Starting LCN of Allocation Bitmap
0x18 24 0x08 Data length (Actual Size) Length of Allocation Bitmap in bytes
Figure 16 - Allocation Bitmap directory entry structure

The entry type 0x81 (binary 1000 0001) is interpreted as:

• Type Code - 00001, Allocation Bitmap
• Importance - 0, Critical
• Category - 0, Primary
• In use - 1, In use

The Bitmap flag field identifies which Bitmap the directory entry is pointing to. In exFAT v1.00, it will
always be 0x00.

The first cluster field gives the starting cluster number of the Bitmap. Generally, this will be Cluster 2, but
it could be re-located within the volume.
The data length field describes the size of the data in bytes (logical file size).
 The Allocation Bitmap is one of the system files that has valid FAT entries, regardless of whether it is
fragmented or not. An example of an Allocation Bitmap directory entry is given in Figure 17.

(Root drectory) root directory

O ffset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00040020 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00040030 00 00 00 00 02 00 00 00 02 OF 00 00 00 00 00 00

Figure 17 - Allocation Bitmap directory entry

IX. UpCase Table Directory Entry

The UpCase Table is another system file located within the Cluster Heap, therefore requires its own
directory entry, but does not have a file name directory entry. The next directory entry in the root of an
exFAT volume is the record for the UpCase Table, and is a critical primary directory entry. This system
file also doesn’t have a file name. The data structure for the UpCase Table directory entry is shown in
Figure 18.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 0x01 Entry type 0x82
0x01 1 0x03 Reserved
0x04 4 0x04 Table checksum 32-bit checksum of table contents
0x08 8 0x1C Reserved
0x14 20 0x04 First cluster Starting LCN of UpCase Table
0x18 24 0x08 Data length Length of UpCase Table in bytes
Figure 18 - UpCase Table directory entry structure

The entry type 0x82 (binary 1000 0010) is interpreted as:

• Type Code - 00010, UpCase Table
• Importance - 0, Critical
• Category - 0, Primary
• In use - 1, In use

The table checksum is provided to verify that the contents of the UpCase table are valid. Microsoft
requires exFAT implementations to do this check prior to using the UpCase Table to convert filenames to
upper case for searching. The UpCase Table is one of the system files that has valid FAT entries,
regardless of whether it is fragmented or not. An example of an UpCase Table directory entry is given in
Figure 19.

(Root directory) root directory'

O ffse t 0 1 2 3 4 5 6 7 8 9 A B C D E F /
00040040 82 00 00 00 0D D3 19 E6 00 00 00 00 00 00 00 00 I 0 «
00040050 00 00 00 00 03 00 00 00 CC 16 00 00 00 00 00 00 1
Figure 19 - UpCase Table directory entry
 The Volume Globally Unique Identifier (GUID) directory entry contains a GUID that allows the operating
system to uniquely distinguish volumes. This directory entry does not actually point to a file, but contains
the GUID within itself. It is a benign primary entry and should only be in the root directory, if it exists at
all within the volume. The data structure for the Volume GUID directory entry is shown in Figure 20.
During testing, no Volume GUID directory entries were encountered.

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 0x01 Entry type OxAO
0x01 1 0x03 Secondary Count Number of secondary directory entries - always 0
0x02 2 0x02 Set Checksum Checksum of directory entry set
0x04 4 0x02 General Primary Flags See Table in Figure 21
0x06 6 0x10 Volume GUID
0x16 22 OxOA Reserved
Figure 20 - Volume GUID directory entry structure

The entry type OxAO (binary 1010 0000) is interpreted as:

• Type Code - 00000
• Importance - 1, Benign
• Category - 0, Primary
• In use - 1, In use

The General Primary Flags is a set of flags that are used by multiple types of directory entry. Figure 21
provides an explanation of the General Primary Flags.

Bit Length Name Description

Allocation Possible 0 = shows the start LCN & size fields are not used,
1 1
1 = start LCN & size fields are used
2 1 No FAT chain 0 = FAT chain is valid, 1 = File is contiguous
3 6 Unused
Figure 21 - General Primary Flags

The first bit shows whether or not the directory entry is pointing to actual file data contained within the
Cluster Heap. If it is 0, then the First Cluster and Data Length fields are unused, and can be redefined
for another purpose. If it is 1, then the directory entry is pointing to allocated data.

In order to improve performance, exFAT allows for FAT chaining to be ignored if the file is contiguous.
The second bit indicates whether or not the FAT is valid for the data. If the value is 0, then the FAT must
be used. If the file is contiguous, the value will be 1.
 This is a benign primary directory entry, would only be found in the first cluster of a directory, and would
occupy every directory entry within the cluster (padding). It is used as part of the Transaction-safe exFAT
file system. Version 1.00 of exFAT does not support these entries, and will treat them as unrecognised
benign entries, therefore ignore them. The data structure for the Volume GUID directory entry is currently
unknown, apart from the Entry Type of 0xA1.

The entry type 0xA1 (binary 1010 0001) is interpreted as:

• Type Code - 00001, TexFAT Padding Directory Entry
• Importance - 1, Benign
• Category - 0, Primary
• In use - 1, In use

During testing, no Windows CE Access Control Table directory entries were encountered.

XII. Windows CE Access Control Table Directory Entry

This is a benign primary directory entry in the root directory, which is used to provide support for Windows
CE applications. Version 1.00 of exFAT does not support these entries, and will treat them as
unrecognised benign entries, therefore ignore them. The data structure for the Volume GUID directory
entry is currently unknown, apart from the Entry Type of 0xA2.

The entry type 0xA2 (binary 1010 0010) is interpreted as:

• Type Code - 00010, Windows CE Access Control Table
• Importance - 1, Benign
• Category - 0, Primary
• In use - 1, In use

During testing, no Windows CE Access Control Table directory entries were encountered.
The details of the directory entries listed above are related to file system artefacts. The following directory
entry types that are explained in this section are used for user files and directories.
 File directory entries are used to describe files and directories that exist within the volume. They are
critical primary directory entries and are the first entry of a directory entry set for each file or directory.
The data structure of a File directory entry is shown in Figure 22.

Offset Length
Name Description
Hex Dec (Bytes)
0x85 - in use
0x00 0 0x01 Entry type
0x05 - not in use
0x01 1 0x01 Secondary count Number of secondary directory entries
0x02 2 0x02 Set checksum Checksum of directory entry set
0x04 4 0x02 File attributes
0x06 6 0x02 Reserved
0x08 8 0x04 Create time stamp
OxOC 12 0x04 Modified time stamp 32-bit DOS date time format
0x10 16 0x04 Last accessed time stamp
0x14 20 0x01 Create 10ms increment Unsigned integer. Valid range of 0-199, added to
0x15 21 0x01 Modified 10ms increment time stamp
0x16 22 0x01 Create UTC differential
7-bit signed integer, representing 15 minute
0x17 23 0x01 Modified UTC differential
intervals
0x18 24 0x01 Last accessed UTC differential
0x19 25 0x07 Reserved
Figure 22 - File directory entry structure
The entry types of 0x85 and 0x05 are interpreted below.

Entry type 0x85 (binary 1000 0101)

• Type Code - 00101, File
• Importance - 0, Critical
• Category - 0, Primary
• In use - 1, In use

Entry type 0x05 (binary 0000 0101)

• Type Code - 00101, File
• Importance - 0, Critical
• Category - 0, Primary
• In use - 0, Not in use

If a File directory entry type is set as not in use, it is possible that the file has been deleted. It is also
possible that another directory entry is being used as the file record. For example, the file has been
renamed with a longer file name, and a new directory entry set is required to hold the record for the file.

A File directory entry is not deleted when the file is deleted; it is simply flagged as unused in the entry
type.
 The file attributes are similar to previous versions of FAT, as shown in Figure 23. A file or directory’s
attributes can be any combination of the values below.

Bit Name Example

0 Read only Read only file = 0x01 (binary 0000 00001)
1 Hidden Hidden file = 0x02 (binary 0000 0010)
2 System System file = 0x04 (binary 0000 0100)
4 Directory Directory (folder) = 0x10 (binary 0001 0000)
5 Archive Archive On = 0x20 (binary 0010 0000)
Figure 23 - File attribute flags

The File Attribute directory flag is the only thing that differentiates whether the directory entry is
for a file or folder. There are no "dot” and “double-dot" entries in a folder’s content in exFAT.

Time Stamps
The exFAT file system has continued to use the 32-bit DOS time format from previous versions of FAT.
The values are converted to binary format and then divided into individual fields to ascertain each
component of the time stamp, summarized in Figure 24.

37 8À BB 3C Time Values 0x8A37, Date Values 3CBB

Time
H ex Values 8 A 3 7
B in ary 1 0 0 0 1 0 1 0 0 0 1 1 0 1 1 1
Hour s Mi n u t e s Se c onds (x2)
Time
17 (5 p. m. ) 17 4 6 ( 2 3 x 2)

Date
H ex Values 3 C B B
B inary 0 0 1 1 1 1 0 0 1 0 1 1 1 0 1 1
Y e a r (+1980) M o n th Day
Date
2 0 1 0 (30 + 1 9 8 0 ) 5 27

Figure 24 - Interpreting 32-bit time format

Time Stamp increm ent

The exFAT file system has improved on the two second accuracy for Create and Modified times by adding
a ten millisecond field. This is an unsigned integer, and has a range of 0 - 199, representing 0 - 1990
milliseconds, which is added to the time stamp

The Microsoft Patent application states that there is a ten millisecond increment field for all three time
stamps, but testing has shown that this is not the case in exFAT 1.00. Only two ten millisecond increment
fields have been observed for the created and modified time stamps. To calculate the differential, convert
the hex value to decimal - if the value is under 100, append the decimal value as milliseconds to the time.
If the decimal value is over 100, add one second to the time. Subtract 100 from the decimal value and
append remainder as milliseconds.
 For example:
• 0x53 = 83. Multiplied by 10, this represents 830 milliseconds added to the time. hh:mm:ss.83
• 0x85 = 133. Multiplied by 10, this represents 1,330 milliseconds, or 1.33 seconds added to the time.
hh:mm:01.33

Time Stamp UTC Differential

The exFAT file system records the time zone that an operating system is set to when it interacts with files
on the volume. FAT and exFAT record the time stamp as local time, however exFAT has a new field in
the directory entry which records the time zone offset from Coordinated Universal Time (UTC) for each
time stamp.

The UTC differential is broken into 15 minute intervals. The field is a 7-bit signed integer, which is then
multiplied by 15 minutes to get the time zone offset from UTC in minutes. To calculate the UTC differential
in Microsoft Excel with use this equation

• =(MOD(HEX2DEC(%Hex%)+64;128)-64)*15
The %Hex% is the UTC differential value (or cell that the value is pasted to).

The calculation is demonstrated in Figure 25, which shows the UTC differential calculation for New
Zealand daylight saving time. A table of Time Zone Differentials is provided on the next page, Figure 27.

Input - UTC Differential Field Input (8-bit) Output - UTC Differential (7-bit)
Hex Binary Decimal Decimal Minutes Hour
0xB4 10110100 180 52 780 13 (NZDT)
Figure 25 - UTC differential calculation

l__
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E
3
Ui

00040940 85 02 Â0 CA 20 00 00 00 33 77 93 3F D6 7C 94 3F |i E 3w| ?Ö| 1?

00040950 D6 7C 94 3F 63 00 B4 B4 B4 00 00 00 00 00 00 00 0 | |? c " '
Figure 26 - File directory entry

Figure 26 shows a File directory entry, which provides the following information:
• There are two secondary entries (three entries in the directory set).
• The directory set checksum.
• The directory references a File, Archive is on.
• Created 19 Dec 2011, 14:57:38.99.
• Modified 20 Dec 2011, 15:38:44.00.
• Accessed 20 Dec 2011, 15:38:44.
• Create 10ms increment = 990ms - (Create time stamp unchanged)

UTC Differential +13 hours - New Zealand Daylight Time. Table of Standard time zones included in
Figure 27.
 Tim ezone O ffset UTC O ffset Time Zone Name
OxDO UTC-12:00 Dateline Standard Time

0xD4 UTC-11:00 Samoa Standard Time

0xD8 UTC-10:00 Flawaii Standard Time

OxDC UTC-09:00 Alaska Standard Time

OxEO UTC-08:00 Pacific Standard Time

0xE4 UTC-07:00 Mountain Standard Time

0xE8 UTC-06:00 Central Standard Time

OxEC UTC-05:00 Eastern Standard Time

OxFO UTC-04:00 Atlantic Standard time

0xF2 UTC-03:30 Newfoundland Standard Time

0xF4 UTC-03:00 Greenland Standard Time

0xF8 UTC-02:00 Mid-Atlantic Standard Time

OxFC UTC-01:00 Azores Standard Time

0x80 UTC Greenwich Standard Time

0x84 UTC+01:00 Central Europe Time

0x88 UTC+02:00 Eastern Europe Standard Time

0x8C UTC+03:00 Moscow Standard Time

0x90 UTC+04:00 Arabian Standard Time

0x94 UTC+05:00 West Asia Standard Time

0x98 UTC+06:00 Central Asia Standard Time

0x9C UTC+07:00 North Asia Standard Time

OxAO UTC+08:00 North Asia East Standard Time

0xA4 UTC+09:00 Tokyo Standard Time

0xA8 UTC+10:00 West Pacific Standard Time

OxAC UTC+11:00 Central Pacific Standard Time

OxBO UTC+12:00 New Zealand Standard Time

0xB4 UTC+13:00 Tonga Standard Time

Figure 27 - 7-bit integer value to Time Zone Differential from UTC (NTFS.com, 2016)
 For a File directory entry to be valid, it must have at least two other directory entries, one of which is the
Stream Extension directory entry. This is a critical secondary directory entry, and must immediately follow
the File directory entry. The Stream Extension directory entry contains information about where the file
is physically located in the Cluster Heap and how long the file name is. The data structure of a Stream
Extension directory entry is shown in Figure 28.

Offset Length
Name Description
Hex Dec (Bytes)
OxCO - in use
0x00 0 0x01 Entry type
0x40 - not in use
0x01 1 0x01 General secondary flags See Table in Figure 29
0x02 2 0x01 Reserved
0x03 3 0x01 Name Length Unicode characters in file name
0x04 4 0x02 Name hash Used for searching
0x06 6 0x02 Reserved
0x08 8 0x08 Valid data length Initialized File Size
0x10 16 0x04 Reserved
0x14 20 0x04 First cluster (LCN) Starting LCN of file/directory
0x18 24 0x08 Data Length (Actual Size) Logical Size of file/directory dàta in bytes
Figure 28 - Stream Extension directory entry structure

The entry types of OxCO and 0x40 are interpreted below.

Entry type OxCO (binary 1100 0000)

• Type Code - 00000
• Importance - 0, Critical
• Category - 1, Secondary
• In use - 1, In use

Entry type 0x40 (binary 0100 0000)

• Type Code - 00000
• Importance - 0, Critical
• Category - 1, Secondary
• In use - 0, Not in use

The general secondary flags are used to indicate whether the file has been allocated space in the Cluster
Heap (up to a theoretical file size of 16 ExaByte-1), and if the file is contiguous or if the FAT needs to be
consulted in order to determine the cluster in which the file resides. Figure 29 shows how the flags are
defined.

Bit Length Name Example

0 1 0 = shows the start LCN & size fields are not used,
Allocation possible
1 = LCN & size fields are used - this is the only valid value
1 1 No FAT chain 0 = FAT chain is valid, 1 = File is contiguous
2 6 Custom defined No set definition - does not appear to be utilised in v.1.00
Figure 29 - General Secondary Flags
 Name Hash
The ExFAT file system creates a 16-bit hash of the uppercase version of each file name. The primary
purpose for this is quick comparison when searching for a file name. The name hash also provides
verification of a file name mismatch.

Valid Data Length

The valid data length field is used to record how much the allocated file space (logical size) is currently
being utilized. This relates to file initialization, which is a feature in exFAT and NTFS file systems used
to improve I/O by pre-allocating space to a file. To help understand the concept, start with the three sizes
that are associated with a file/directory:
• Allocation size - the amount of clusters reserved (Physical size).
• Actual size - the number of bytes being used (Logical size).
• Valid data length - the number of byte that have been written to disk (Initialized Size).

File initialization is a process used by exFAT (and NTFS) when a new file is created. The exFAT file
system allocates the clusters for the file, but in certain circumstances, the file content may only be partially,
or even not at all, written to those clusters. The area between the valid data length and the logical size
may contain data that does not belong to the file - it is the content of the previous file that occupied the
cluster. Any reads in the uninitialized space are returned as zero (Microsoft). Figure 30 provides a
graphical explanation of valid data length.

Valid Data Length (Initialized Size

1

File Content Written to disk Uninitialized Space File Slack

L_
~1
Logical Size

Physical Size

Figure 30 - File size definitions

A common example of this occurring is Peer-2-Peer (P2P) bit torrent clients. When download is
requested by the user, the P2P client requests that the file system creates a file of a certain size, but
doesn’t write any data to that file. As the requested file content downloads, the content is written into the
actual file. The physical and logical sizes remain unchanged, but the valid data length (or initialized size)
will increment. When the entire file content is downloaded and saved, the valid data length will match the
logical size.

The data length is the Logical size; for a directory, the maximum size is capped at 256MB. Figure 31
shows a Stream Extension directory entry which is interpreted below.
 O ffset 0 1 2 3 4 5 6 7 8 9 A B c D E F ✓ j Osj i
CO 03 00 0B 54 00 00 62 61 00 00 00 00 00 00 A IT ba

00
l/)
00040960
00040970 00 00 00 00 08 00 00 00 62 61 00 00 00 00 00 00 ba
Figure 31 - Stream Extension directory entry

The Stream Extension directory entry provides the following information:

The file utilizes allocated space and is contiguous - (binary 0000 0011).
• The file name is 11 Unicode characters long.
• The file name hash is 0x5485.
• The valid data length is 24,930 bytes (0x6162).
• The file content starts at logical cluster number 8.
• The logical file size is 24,930 bytes (0x6162)

The Stream Extension directory entry is the first of two directory entry types required within a directory
entry set for it to be valid. So far, the examined directory entry set for a file appears as shown in Figure
32.

O ffset 0 1 2 3 4 5 6 7 8 9 A B C D E F ^ |

00040940 85 02 A0 CA 20 00 00 00 33 77 93 3F D6 7C 94 3F 1 Ê 3w|?0
00040950 D6 7C 94 3F 63 00 B4 B4 B4 00 00 00 00 00 00 00 Ô| 1?c ' * *
00040960 CO 03 00 0B 85 54 00 00 62 61 00 00 00 00 00 00 A IT ba
00040970 00 00 00 00 08 00 00 00 62 61 00 00 00 00 00 00 ba
Figure 32 - First two entries within a File directory entry set

XV. File Name directory entry

The final directory entry type to examine in this set is the File Name entry. This is a critical secondary
entry, and is required to make a File directory entry set valid. In the exFAT file system, file names are
stored as Unicode, and can be up to 255 characters. A single File Name directory entry holds up to 15
characters; therefore a File directory entry set may have up to 17 File Name directory entries. The data
structure for a File Name directory entry is shown in Figure 33.

Offset Length
Name Description
Hex Dec (Bytes)
0xC1 - in use
0x00 0 0x01 Entry type
0x41 - not in use
0x01 1 0x01 General secondary flags See Table in Figure 29
0x02 2 0x1 E File Name Catenate every 15 characters
Figure 33 - File Name directory entry structure

The entry types of 0xC1 and 0x41 are interpreted below.

Entry type 0xC1 (binary 1100 0001)
• Type Code - 00001
• Importance - 0, Critical
• Category - 1, Secondary
• In use - 1, In use
Entry type 0x41 (binary 0100 0001)
• Type Code - 00001
• Importance - 0, Critical
• Category - 1, Secondary
• In use - 0, Not in use

Long file names are catenated into 15 character chains, which are then written into the directory entry set
in logical order, directly after the previous entry. To “catenate” is to form something into a series of chains;
to “concatenate” is to connect separate units into a linked system. The exFAT file system will concatenate
the file name from each File Name directory entry within the set and display it correctly.

The general secondary flags in this entry are there to indicate that offset 0x14 does not contain a first
cluster address for the data - it resides within the field itself. The value that was always observed while,
developing this module was 0x00.

The file names and continue to have their special meaning, but are not permitted to be stored in a
File Name field. They are not written physically into a directory, but are available to be used as a concept
through the operating system.

Figure 34 shows a File Name directory entry for the file "Tables.xlsx”.

O ff s e t 0 1 2 3 4 5 6 7 8 9 A B C D E F /
00040980 Cl 00 54 00 61 00 62 00 6C 00 65 00 73 00 2E 00 k T a b 1 e s
00040990 78 00 6C 00 73 00 78 00 00 00 00 00 00 00 00 00 x 1 s X
Figure 34 - File Name directory entry

By working through the three different types of directory entry, we now have a complete directory entry
set, and all the file system metadata about the file. When examining a File directory entry, it is important
to note the “Secondary Entries” field, as this tells the examiner how long the directory entry set is. Figure
35 contains a file directory entry set that has a long file name.
 Offset 0 1 2 3 4 5 6 7 8 9 A B c D E F / I ^1
i
00040D20 85 09 cs 9C 20 00 00 00 B8 4A 29 40 BD 4A 29 40 1 Al
00040D30 BD 4A 29 40 60 00 B4 B4 B4 00 00 00 00 00 00 00 *

00040D40 CO 03 00 71 65 E9 00 00 04 00 00 00 00 00 00 00 A qee
00040D50 00 00 00 00 06 00 00 00 04 00 00 00 00 00 00 00
00040D60 Cl 00 54 00 68 00 69 00 73 00 20 00 77 00 61 00 A T h i s V a
00040D70 73 00 20 00 61 00 20 00 4E 00 65 00 77 00 20 00 s a N e w
00040D80 Cl 00 54 00 65 00 78 00 74 00 20 00 44 00 6F 00 A T e X t D o
00040D90 63 00 75 00 6D 00 65 00 6E 00 74 00 20 00 74 00 c u m e n t t
00040DA0 Cl 00 68 00 61 00 74 00 20 00 68 00 61 00 73 00 A h a t h a s
00040DB0 20 00 62 00 65 00 65 00 6E 00 20 00 72 00 65 00 b e e n r e
00040DC0 Cl 00 6E 00 61 00 6D 00 65 00 64 00 20 00 77 00 A n a m e d w
00040DD0 69 00 74 00 68 00 20 00 61 00 20 00 72 00 69 00 i t h a r i
00040DE0 Cl 00 64 00 69 00 63 00 75 00 6C 00 6F 00 75 00 A d i c u 1 o u
00040DF0 73 00 6C 00 79 00 20 00 6C 00 6F 00 6E 00 67 00 s 1 y 1 o n g
00040E00 Cl 00 20 00 66 00 69 00 6C 00 65 00 20 00 6E 00 A f l 1 e n
00040E10 61 00 6D 00 65 00 20 00 69 00 6E 00 20 00 61 00 a m e i n a
00040E20 Cl 00 6E 00 20 00 65 00 78 00 46 00 41 00 54 00 A n e X F A T
00040E30 20 00 66 00 69 00 6C 00 65 00 20 00 73 00 79 00 f i 1 e s y
00040E40 Cl 00 73 00 74 00 65 00 6D 00 2E 00 74 00 78 00 A s t e in t X
00040E50 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 t
Figure 35 - Complete File directory set

For the ease of viewing these entries, convert hex view to 32 bytes per line. Below, Figure 36 depicts
complete file directory sets in this view.

a
0 1 2 3 4 5 6 7 e o A 5 c D E J* 10 i : • 2 13 14 15 1 6
17 18 19 1A 15 : c ID IE • r L J~ *
£5 5S IB 71 20 00 00 00 69 1 3€ 4A 35 “ 4 26 4A 69 54 3 6 4« 5B OO S4 B4 B4 00 OO 00 OO OO 00 00 _ •••
CO 01 00 OD C4 13 00 OO : : OO OO OO 00 OO OO 00 00 OO OO OO 00 00 OO : : OO OO OO OO OO OO 00 OO i ;
C l 3D 31 00 54 00 €5 00 7£ OO “ 4 OO €€ OO €9 OO 6Z OO €5 OO 2E CO “ 4 00 78 OO 74 OO OO OO 00 OO i I T - x t i i l e . t x : •

i s OJ 62
2A 20 CO 00 OO 69
84 3« 4A 4 S e4 4A 36 69 84 36 4A 9B OO 84 84 84 OO OO OO OO OO OO OO _ t * 1_< J T _<J l _ < J » j
t o o : OO IS 62
so 00 OO OO OO : : OO OO OO OO OO : : : : OO OO OO OO OO OO OO OO OO OO OO : :• OO OO A tr |
111 00 32
: : 40 00 OO47 OO €7 00 6t s OO 72 OOt 20 OO 66OO 69 OO 6C
OO 6S : : 20 OO 61
OO 61 OO ¿ 2 1 c n g f i f i l e r. a
£0_6 02 _00_ 2*
op - I 4— 0 2. IS CO_ 22 cp op IP _00_ £P _____
OO op _________________ 1

0 4 4 5 6 9 $ 1 c ID IE IF J i
69 0
¡0
¡0

fss ¡02 IB 20 OO OO OO ) OO OO OO _ n
*1 i^6J5„€ui„€J > '*'
¡01 OO OD C4 13 CO OO Q -K
n
o

OO 1 OO OO OO 00 A
•Cl ^00 2'"• 54 OO €5 OO 7 0
0 ) “ OO OO OO 1 T A X Z 1 1 1 * . : x t

03 62 2m 20 OO OO 00 69 8 OO OO OO OO t* JZ~ 1 m- €0 >
Ico Oi OO 15 62 •
50 OO OO OO O ) OO OO OO OO #6 fcp
ICi OO 32 OO •1C OO er OO i t O ) 6E OO 61 OO #44 2 1 c " v c r S i 1 e r. a
« 1 OO 6D OO 65 ° 9 2 Z OO 74 0 OO OO 09 09 A s e . t x t

Figure 36 - Complete File directory sets in 32 byte view

XVI. File creation, Deletion, and Recovery
When a file or directory is created on an exFAT file system, the process begins by the file directory entry
set being created. The bitmap is examined to locate available clusters to store the data. Should there be
sufficient space to store the file without fragmentation, the directory entry set will be written with the file
dates, size, and start cluster. The general secondary flags will be set to show that the FAT has not been
used for this file. When discussing directory entries in this section, file is synonymous with directory, as
the only distinction is a one-bit flag in the directory entry.

If the file requires fragmentation to fit in the volume, the representative fields in the FAT will be updated
in order to chain together the clusters that hold the data fragments. The general secondary flags will be
set to show that the FAT needs to be used to access the file.

File Rename
Testing has shown that anytime the secondary directory entry count field has to be changed, a complete
new directory entry set is created for the same file. If the length of a filename is increased so that it
requires additional File Name directory entries, a complete new directory entry set is created. If a file
name is shortened so that it requires less File Name directory entries, a complete new directory entry set
is created. Whenever this occurs, the new file directory entry copies the file Created, Modified and
Accessed dates from the original entry, and the original directory entry set is flagged “Not in Use”.

Similarly, each time a Microsoft Office file is opened, a new directory entry set is created. This is useful
to the forensic examiner for data recovery purposes and for building timelines, particularly given the way
exFAT utilises directory space, as explained below.

File dates
The file created and modified dates appear to operate the same as previous version of Microsoft file
systems. However in exFAT, the last accessed date does not get updated when the file is accessed,
either by opening it or viewing the file properties. If a file is changed, the last modified date is changed.
The last accessed date is also changed to match the last modified date. This has been observed in
Windows XP, Windows 7, and Windows 10 operating systems.

Directory utilisation
A characteristic that has been observed in the exFAT file system is that it doesn’t appear to re-use
directory entries until the entire cluster has been used. For example, imagine a directory that has five
directory entry sets that are currently in use, and two that are not in use. If a new file is created in that
directory, the directory entry set will not re-utilise the area that is occupied by the directory entry sets
flagged not in use. Instead, any new directory entry sets will be added below the previous, until the end
of the cluster is reached. Once the end of the cluster has been reached, the next directory entry set will
be placed within space occupied by those flagged not in use. If there is insufficient space, another cluster
will be assigned to the directory. This trait is quite useful for the forensic examiner, as it improves the
possibility of file recovery, particularly given the large cluster sizes that exFAT uses.

It is also important to remember that the Root directory utilizes the FAT. There are no fields in the exFAT
file system that show the actual size of the root directory, only its starting cluster. The FAT needs to be
consulted to see if that cluster is represented with an end of file marker or if the FAT is pointing to another
cluster, which holds the next fragment of the Root directory.
File deletion process
When a file is deleted, two things happen:
1. Each entry in the directory entry set has the "In use” flag cleared.
2. The Allocation Bitmap file is updated to reflect that the clusters used to hold the file data are
now unallocated.

The file content is unchanged. If the file/directory was fragmented the FAT chaining is not changed when
the file was deleted, which improves the chances of full recovery.

A directory entry set that is not flagged “In use" doesn’t necessarily mean the file is deleted - it
may have been renamed.

File Recovery Process

To recover a file in the exFAT file system, the process undertaken during deletion is reversed. First, the
directory entry set is changed to show that it is in use. The Stream Extension directory entry provides the
starting cluster and size, and whether or not the file was fragmented. If the file was not fragmented, then
the file size can be divided by the cluster size and rounded up to a whole number. This number is the
amount of clusters that are required to hold the file content.

The second step is to change the fields in Allocation Bitmap that represent those clusters to show that
they are now allocated. When re-chaining the file fragments in the Allocation Bitmap, if a cluster has
already been set as allocated, then the file that is being recovered has had its content over-written by a
new file.

If the file was fragmented, then the first fragment location is provided by the Stream Extension directory
entry, and specific keyword searches may find remaining fragments. The advantage of exFAT over FAT
is that the directory entry set informs the forensic examiner that the file is fragmented, which can reduce
the risk of associating invalid data to an evidential file.
Shown below are GREP expressions to search for directory entry sets flagged "not in use” for a file (up
to first File Name entry):

• EnCase-
\x05... [\xOO\x01 \x02\x03\x04\x05\x06\x07\x20\x21 \x22\x23\x24\x25\x26\x27] ,{27,27}\x40[\x01\x03].{
30,30}\x41\x00.{30,30}

• Winhex / X-Ways -
\x05...[\x00\x01\x02\x03\x04\x05\x06\x07\x20\x21\x22\x23\x24\x25\x26\x27].{27}\x40[\x01\x03].{30}
\x41\x00.{30}

In WinHex or X-Ways, change the “Search Window" value to 190 bytes.

Sub-Directory Deletion Process

When a folder is deleted, two things occur:
1. Each entry in the directory entry set for the folder only has the “In use” flag cleared.
2. The Allocation Bitmap file is updated to reflect that the clusters used to hold the folder and all
sub-directory/file data are now unallocated.
The content of the folder is not changed - all child directory entries of the deleted folder (its content) are
left unchanged.
When recovering a directory, the process is exactly the same as for a file. However, after changing the
directory entry set and Allocation Bitmap entries for the deleted directory, the forensic examiner will then
need to view the cluster that the directory was assigned, and recover the contents of that directory and/or
any sub-directories.
Shown below are GREP expressions to search for directory entry sets flagged “not in use" for a directory
(up to first File Name entry):

• EnCase -
\x05... [A\x00\x01\x02\x03\x04\x05\x06\x07\x20\x21 \x22\x23\x24\x25\x26\x27] ,{27,27}\x40[\x01\x03],
{30,30}\x41\x00.{30,30}
• Winhex / X-Ways -
\x05...[A\x00\x01\x02\x03\x04\x05\x06\x07\x20\x21\x22\x23\x24\x25\x26\x27].{27}\x40[\x01\x03].{30
}\x41\x00.{30}

In WinHex or X-Ways, change the “Search Window” value to 190 bytes.

Sub-D irectory Tree Recovery Lim itations

As the dot, double-dot directory entries do not exist in exFAT, it is not possible to search for deleted
folders perse; we can only search for directory entries as discussed above.
• Any directory entries flagged as a directory that are located in Unallocated Clusters that do not have
the "In use” flag set indicate that the folder for these entries may have been deleted.

• Any directory entries flagged as a directory that are located in Unallocated Clusters that do have
the “In use’’ flag set indicate that the parent folder for these entries was deleted.

It will not be possible to determine the lineage (location in the folder tree structure) of the recovered folder,
unless the directory entries from the root and any other sub-directories in the original path can also be
recovered. It is no longer possible to “reverse look-up” as the on disk content of the folder does not point
to the parent.

Post-Format File Recovery

When an exFAT volume is formatted, in addition to rewriting the Boot Sectors, the Allocation Bitmap and
the UpCase Table, the first cluster of the root directory is over-written with 0x00. This occurs with both
Windows XP and Windows 7. The root directory is the only directory where this applies; all other clusters
in the cluster heap are left intact. Any data that was referenced in the first cluster of the root will have to
be carved from unallocated space. All sub-directory content can be reconstructed manually, as they are
left intact, apart from the name of any directory that had a parent-child relationship with the root directory.
Directory entries can be located with searches using global regular expressions (GREP). The only parts
of the FAT that are over-written is the representative entries for the system files and Root directory, the
remainder are left intact.

The format process does not change the “in use” flag of directory entries. To recover files after a format
process, searches will be required for both “not in use” and “in use" directory entry sets.

The GREP expressions to search for directory entry sets flagged “In use" are (up to first File Name entry):
• EnCase - \x85.{31,31}\xC0[\x01\x03].{30,30}\xC1\x00.{30,30}
• Winhex or X-Ways - \x85.{31}\xC0[\x01\x03].{30}\xC1\x00.{30)
In Winhex or X-Ways, change the “Search Window” value to 190 bytes.
 The GREP expression to search for all file directory entries is (up to the first File Name entry):
• EnCase - [\x85\x05].{31,31}[\xC0\x40][\x01\x03].{30,30}[\xC1\x41]\x00.{30,30}

The GREP expressions to search directory entry sets flagged “Not in use” are (up to the first File Name
entry)
• EnCase - \x05.{31,31}\x40[\x01\x03].{30,30}\x41\x00.{30,30}
• Winhex or X-Ways - \x05.{31}\x40[\x01\x03].{30}\x41\x00.{30}
In WinHex or X-Ways, change the “Search Window” value to 190 bytes.

The file attributes will need to be checked in order to determine if the directory entry set is for a file or a directory.
 Works Cited
Casey, E. (2010, March 17). The Pitfalls o f File Initialization for Forensic Analysts. Retrieved January 9,
2011, from cmdLabs: http://blog.cmdlabs.com/tag/ntfs/

Microsoft. (2009, August 14). Default cluster size for NTFS, FAT, and exFAT. Retrieved January 9, 2012,
from Microsoft Support: http://support.microsoft.com/kb/140365

Microsoft. (2009). Unites States of America Patent No. US 2009/02654000 A l.

Microsoft. (2015,10 12). Description of the exFAT filesystem driver update package. Retrieved from
Microsoft: https://support.microsoft.com/en-us/kb/955704

Microsoft Developer Network. (2008, August 28). Transaction-Safe Extended FAT File System . Retrieved
January 4, 2012, from Microsoft: http://msdn.microsoft.com/en-us/library/cc907927.aspx

Microsoft, (n.d.). Microsoft Windows XP - fsutil: file. Retrieved January 9, 2012, from Microsoft:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-
us/fsutil_file.mspx?mfr=true

NTFS.com. (2016, 02 21). exFAT Timestamp Format. Retrieved from NTFS.com: http://ntfs.com/exfat-
time-stamp.htm

NTFS.com. (n.d.). exFAT. UpCase Table. Retrieved January 4, 2012, from NTFS.com:
http://www.ntfs.com/exfat-upcase-table.htm

Sandisk Corporation. (2010, February 22). SANDISKSHIPS ITS HIGHEST CAPACITYSD CARD EVER, the 64
GB SANDISK ULTRA SDXC CARD. Retrieved December 21, 2011, from Sanddisk:
http://www.sandisk.eom/about-sandisk/press-room/press-releases/2010/2010-02-22-
sandisk-ships-its-highest-capacity-sd-card-ever,-the-64gb-sandisk-ultra-sdxc-card

Tilley, C. (2009, October 9). The History of Microsoft Windows CE - Windows CE 6.0 & into the future.
Retrieved December 21, 2011, from HPC Factor:
http://www.hpcfactor.com/support/windowsce/wce6.asp

Bibliography
Microsoft. (2009). Patent No. US 2009/0164440 A1 . Unites States of America.

Microsoft. (2009). Patent No. US 2009/02654000 A1 . Unites States of America.

Microsoft. (2009). Patent No. US 7,163,738 B2. Unites States of America.

Shullich, R. (2009). Reverse Engineering the Microsoft Extended FAT File system (exFAT). InfoSec Reading
Room, SANS Institute.
XVII.Consolidated Tables

Boot Sector
Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 0x03 Jump boot Jump instruction to Boot Code Field
0x03 3 0x08 File system name A S C II-e xF A T
OxOB 11 0x35 Must be zero Replaces FAT BIOS parameter block
0x40 64 0x08 Partition offset Sectors from start of media
0x48 72 0x08 Volume length Total sectors in volume
0x50 80 0x04 FAT offset Logical start sector of FA T
0x54 84 0x04 FAT length Length of FAT table in sectors
0x58 88 0x04 Cluster heap offset Logical start sector o f cluster heap
0x5C 92 0x04 Cluster count Number o f clusters in cluster heap
0x60 96 0x04 First cluster of root directory Root directory start cluster
0x64 100 0x04 Volume serial number
0x68 104 0x02 File system revision M a jo r/ minor
0x6A 106 0x02 Volume flags See Table in Figure 4
Power o f 2 value for bytes per sector - range 9
0x6C 108 0x01 Bytes per sector shift
- 12 (5 1 2 -4 0 9 6 bytes)
Power o f 2 value for sectors per cluster-range
0x6D 109 0x01 Sectors per cluster shift
0 - 2 5 (1-33,554,432)
0x6E 110 0x01 Number of FATs 0x00 = FAT 1, 0x01 = F A T 2
0x6 F 111 0x01 Drive select Extended INT 0x13 drive number
0x70 112 0x01 Percent in use 0x00 - 0x64. OxFF = not available
0x78 120 0x186 Boot code Boot-strapping instructions
0x01 FE 510 0x02 Boot signature 0xAA55
0x0200 512 Excess space (If sector > 512 bytes)
Figure 3 - Boot Sector Data Structure

Bit Name Description

0 Active FAT Which FAT and Bitmap are in use 0 = first FAT, 1 = second FAT
1 Volume dirty 0 = volume consistent, 1 = potentially inconsistent
2 Media failure 0 = any known failures marked “bad" clusters, 1 = media reported failures
3 Clear to zero No significant meaning in Revision 1.00
Figure 4 - Boot Sector Volume Flags
FAT values
Symbolic Value Hex Value Description
Media Type 0xFFFFFFF8 Pre-determined value.
0x00000003 -
Next Cluster Numerical value indicating the next cluster for a fragmented file.
0xFFFFFFF6
End of File OxFFFFFFFF Last cluster within a cluster chain.
Corrupt Cluster. If a cluster is marked bad, the media failure flag will
Bad Cluster 0xFFFFFFF7
also be set in the Boot Sector.
Figure 9 - FAT Table Values

Directory Entry “ entry type” field bit values

Bit Length Description
0 5 Type Code.
5 1 Type Importance - 0 = Critical, 1 = Benign.
6 1 Type Category - 0 = Primary, 1 = Secondary.
7 1 In Use - 0 = not in use, 1 = in use.
Figure 11 - Entry Type Field Structure

Directory Entry Types

Identifier (In Use) Directory Entry Type Identifier (Not in Use)
0x81 Allocation Bitmap 0x01
0x82 UpCase Table 0x02
0x83 Volume Label 0x03
0x85 File 0x05
OxAO Volume GUID 0x20
0xA1 TexFAT Padding 0x21
0xA2 Access Control Table 0x22
OxCO Stream Extension 0x40
0xC1 File name 0x41
Figure 13 - Directory Entry types

Volume Label directory entry

Offset Length
Name Description
Hex Dec (Bytes)
0x83 - Label assigned
0x00 0 0x01 Entry type
0x03 - No volume label
0x01 1 0x01 Character count Number of Unicode characters in label
0x02 2 OxOB Volume label Volume label in Unicode
0x18 24 0x08 Reserved
Figure 14 - Volume Label directory entry structure
 Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 0x01 Entry type 0x81
1 Bit value - 0 = Bitmap 1,
0x01 1 0x01 Bitmap flags
- 1 = Bitmap 2
0x02 2 0x12 Reserved
0x14 20 0x04 First cluster Starting LCN of Allocation Bitmap
0x18 24 0x08 Data length Length of Allocation Bitmap in bytes
Figure 16 - Allocation Bitmap directory entry structure

UpCase Table directory entry

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 0x01 Entry type 0x82
0x01 1 0x03 Reserved
0x04 4 0x04 Table checksum 32-bit checksum of table contents
0x08 8 0x1 C Reserved
0x14 20 0x04 First cluster Starting LCN of UpCase Table
0x18 24 0x08 Data length Length of UpCase Table in bytes
Figure 18 - UpCase Table directory entry structure

Volume GUID directory entry

Offset Length
Name Description
Hex Dec (Bytes)
0x00 0 0x01 Entry type OxA0
0x01 1 0x03 Secondary Count Number of secondary directory entries - always 0
0x02 2 0x02 Set Checksum Checksum of directory entry set
0x04 4 0x02 General Primary Flags See Table in Figure 21
0x06 6 0x10 Volume GUID
0x16 22 OxOA Reserved
Figure 20 - Volume GUID directory entry structur

Bit Length Name Description

Allocation Possible 0 = shows the start LCN & size fields are not used,
1 1
1 = start LCN & size fields are used
2 1 No FAT chain 0 = FAT chain is valid, 1 = File is contiguous
3 6 Unused
Figure 21 - General Primary Flags
 Offset Length
Name Description
Hex Dec (Bytes)
0x85 - in use
0x00 0 0x01 Entry type
0x05 - not in use
0x01 1 0x01 Secondary count Number of secondary directory entries
0x02 2 0x02 Set checksum Checksum of directory entry set
0x04 4 0x02 File attributes See Table in Figure 23
0x06 6 0x02 Reserved
0x08 8 0x04 Create time stamp
OxOC 12 0x04 Modified time stamp 32-bit DOS date time format
0x10 16 0x04 Last accessed time stamp
0x14 20 0x01 Create 10ms increment
Valid range of 0-199, added to time stamp
0x15 21 0x01 Modified 10ms increment
0x16 22 0x01 Create UTC differential
7-bit signed integer, representing 15 minute
0x17 23 0x01 Modified UTC differential
intervals
0x18 24 0x01 Last accessed UTC differential
0x19 25 0x07 Reserved
Figure 22 - File directory entry structure

Bit Name Example

0 Read only Read only file = 0x01 (binary 0000 00001)
1 Hidden Hidden file = 0x02 (binary 0000 0010)
2 System System file = 0x04 (binary 0000 0100)
4 Directory Directory (folder) = 0x10 (binary 0001 0000)
5 Archive Archive On = 0x20 (binary 0010 0000)
Figure 23 - File attribute flags
 Offset Length
Name Description
Hex Dec (Bytes)
OxCO - in use
0x00 0 0x01 Entry type
0x40 - not in use
0x01 1 0x01 General secondary flags See Table in Figure 29
0x02 2 0x01 Reserved
0x03 3 0x01 Name Length Unicode characters in file name
0x04 4 0x02 Name hash Used for searching
0x06 6 0x02 Reserved
0x08 8 0x08 Valid data length Initialized File Size
0x10 16 0x04 Reserved
0x14 20 0x04 First cluster (LCN) Starting LCN of file/directory
0x18 24 0x08 Data Length Logical Size of file/directory data in bytes
Figure 28 - Stream Extension directory entry structure

Bit Length Name Example

0 = shows the start LCN & size fields are not used,
0 1 Allocation possible
1 = LCN & size fields are used - this is the only valid value
1 1 No FAT chain 0 = FAT chain is valid, 1 = File is contiguous
2 6 Custom defined No set definition - does not appear to be utilised in v.1.00
Figure 29 - General Secondary Flags

File Name directory entry

Offset Length
Name Description
Hex Dec (Bytes)
0xC1 - in use
0x00 0 0x01 Entry type
0x41 - not in use
0x01 1 0x01 General secondary flags See Table in Figure 28
0x02 2 0x1 E File Name Catenate every 15 characters
Figure 33 - File Name directory entry structure
 First Responder I Planning
ÏACJS
The International Association of
and II Crime Scene
Forensic Acquisition and Methodology
Computer Investigative Specialists

Contents
I. Synopsis.......................................................................................................... .1
II. Learning Objectives...................................................................................... .. 1

III. Search Warrant Planning and Search Execution....................................... .2

IV. Identifying Potential Evidence...................................................................... .4

V. Triage Procedures.......................................................................................... .5
VI. Collection and Preservation (Bag & Tag).................................................... 11
VII. SUMMARY CHECKLIST FOR SEIZURE OF ELECTRONIC EVIDENCE 13

I. Synopsis

This module begins with a big picture look at the overall computer forensic process, and quickly becomes
a basic discussion of crime scene techniques as they relate to digital evidence. It is designed to assist
you in developing protocols and procedures for your agency and the seizure and forensic examination of
computer systems and related media.

The module is designed to aid first responders in all phases of collection and storage of digital evidence
to the point of creating a forensic image. Many situations may necessitate calling a knowledgeable
examiner to the scene to complete the imaging or more extensive triage procedures at the scene. This
module is intended to address only the situations that do not require the immediate onsite imaging of
media, but rather, the situations that allow for the collection of devices by a first responder for transport to
an established evidence storage location where proper forensic imaging may be completed. It is also
intended to train the first responder in identifying situations which may necessitate an on-scene response
for imaging and the possible acquisition of memory.

A computer forensic examiner should expect that a personal computer (or multiple computers and related
media) is likely to be seized for examination in virtually any type of crime, including domestic assault, ID
theft, fraud, forgery, drugs, homicide, child pornography, threats, harassment, gambling, etc.

II. Learning Objectives

At the conclusion of this block of instruction, students should have a basic understanding of:
• Search Warrant Planning and Execution
• Note taking and retention
 Identification of Potential Evidence
Triage of evidence and encryption detection
“Bag & Tag” of the Evidence

III. Search W arrant Planning and Search Execution

All of the standard protocols involving a search warrant scene apply - officer safety is paramount. Follow
established protocols to ensure your safety and that of your warrant/seizure team.

In addition to gathering standard intelligence information, such as physical location and layout of the
scene, other information to "know ahead” when possible is:
• Will the search be of a business, or a private residence?
• What kind of computer setup can you expect on-scene? Network? Cloud?
• Technical experience of the individual? Computer literate? Computer inclined? Computer Expert?
• If it is a business, do you have an employee count? 1 employee = 1 or 2 computers

A business may utilize only a single user PC, several PCs, or even hundreds of PCs all configured on a
network. While the majority of residential environments will typically yield one or two standalone PCs, it is
not unheard of to encounter a scenario with a multi-computer or multi-network setup in the garage,
courtesy of the resident geek. Be aware and be prepared for anything.

You will want to consider establishing protocols and procedures critical to successful warrant execution
for the seizure of computers and related media. In your pre-warrant briefing, assign specific areas of
responsibility.
• Know who is operating as the search team leader.
• Who will conduct the suspect interviews?
• Who will operate as the search team once on site?
• Who will be responsible for the seizure of the computer and related media?
o Be certain this is someone who has been trained in the best practices for electronic media
search & seizure.
• Who will photograph and/or take video once onsite?
If you have an informant, ask lots of questions about what to expect at the scene.

Equipment Considerations
An agency/department specific equipment list should be created and routinely updated in order to assist
the investigator with appropriate equipment while onsite. This list could include required actions like
charging cameras, wiping destination hard drives, updating firmware, etc.

Adding to the basic search and seizure principles you received in law enforcement training and through
on-the-job experience, there are other considerations for conducting a search of a crime scene and
collecting the computer(s) and related electronic evidence.

Equipment considerations should include such items as:

• A screwdriver with every type of head imaginable
• Brown paper evidence bags
• Antistatic storage bags
• Manila folders
• Evidence tags
 • Flashlight
• Evidence tape and packaging tape
• Permanent marking pens (Sharpie)
• Labels
• Rubber Gloves
• Rubber bands (or twist ties)
• The list can go on & on...

Additional consideration should be given to on-site processing of electronic evidence instead of

collection. The decision to acquire devices on-scene can help reduce unnecessary exhibit seizure and
limit business interruption liability. Logistical issues may be another reason to process on-scene.

Equipment considerations for on-scene processing should include such items as:
• Write-blockers
• Adequate Sanitized Storage
• Adapters
• Laptop/Processing Platform
• Mobile Device Forensic Platform

Note Taking and Retention

Every agency should have a Note Taking Policy in place which includes Note Retention requirements.
Agencies without such a policy should consider implementing a consistent Note Taking and Retention
Policy immediately. Such a policy will aid in future prosecutions, appeals and other litigation.

Notes taken contemporaneously by the on-scene investigators will provide a manner or method for
recollecting observations, statements, conditions, activities, equipment and system topology. Notes
greatly assist an investigator who may need to reconstruct the systems months after the initial seizure.

Standardized forms can assist the on-scene investigator with the collection of notes for individual
systems. Recognizing significant evidence is important, but documenting it in the field notes can be
equally as important.

Notes can be compiled and retained for later use in future prosecution or litigation. Local, State and
Federal laws regulate the release of investigative notes. As a standard, the notes should be complete,
accurate and contemporaneous. The notes should be retained in accordance to agency rules and
governing laws.

At the Scene
The number one rule in warrant execution regarding computer evidence:

Move everyone away from the area where the com puter is located...DO NOT ALLO W ANYONE
(especially the suspect) TO TOUCH THE KEYBOARD.

Be aware of technology (such as wireless devices) that could allow the suspect to have remote access to
the system. The possibility exists for destructive programs or some type of electronic booby trap on the
computer. Although quite rare, these types of scenarios do occur. A careful examination of the system
and the area surrounding it are important before touching anything. By ensuring that no one touches the
keyboard, you will prohibit the inadvertent (or purposeful) initiation of any sequence of events that could
damage the volatile data on the system.
 Computer savvy suspects could use a destructive batch file to destroy files or wipe a drive. If you see
something like this processing on the screen, you're going to want to pull the power FAST.

Traps & Bombs

A “hot key" bomb is an assigned keystroke combination designed to execute a command or series of
commands.
A “Booby Trap” is a program that appears to do one thing, but is actually doing something different.
A “Terminate and Stay-Resident” (TSR) is a program that stays resident, sitting in the background and
waiting for something to happen, like a timeout.

IV. Identifying Potential Evidence

As with any criminal investigation, probable cause to execute the warrant (or an exception to the warrant
requirement) must be established...
Your probable cause to seize computers and related evidence might include the following:
• The computer Is contraband or fruits of a crime.
• The computer system contains evidence of a crime.
• The computer is a tool of the offense.
• The computer is both the instrument and storage device of a crime.

While walking the scene or search site, it is important to develop a keen eye for devices that, to an
untrained eye, may not be apparent as a potential source of electronic evidence. Router Interrogation
can lead to the discovery of Small Scale Devices not previously known to the seizure team. A scan for
wireless networks can assist the first responder in identifying hidden networks and wireless storage
devices.

Consideration should be given for small scale devices that may contain electronic evidence. Examples
of these devices are listed below:
• Skimmers
• Key Loggers
• GPS devices
• Unmanned Aircraft Systems (drones)
• Home Artificial Intelligence (Al) devices (eg. Google Home™, Amazon Echo™)
• Vehicle infotainment and telematics systems (eg. Microsoft SYNC™, MyFord Touch™, OnStar™)
• Home Security (eg. Nest™, Ring™)
• Gaming Consoles
• Wearable Technology
• Closed-Circuit Television Cameras

Protocols
This subsection is a brief discussion of some general best practices that should be followed at the scene
of a computer search.

Operational computer systems at the scene of a search are in one of three general states. The systems
are either off, on, or in a state where they appear to be off but are actually on (hibernated).
 If the computer is off, leave it off. The computer should be collected in accordance with established
procedures. Turning the computer on (booting the computer from a powered down state to an
operational state) will alter several files on the computer system. If determined that the computer can be
collected by virtue of it being powered off, unplug the power connection directly from the back of the
computer and NOT from the wall. Be aware...make sure the computer is truly off, not just
appearing to be off.

Although a computer may appear to be off, it could just be in “sleep mode” or fully operational with the
monitor off or disconnected. Always check to ensure the monitor is plugged in and powered on.

To determine if a computer is in “sleep mode”, slightly move the mouse or hit the “SHIFT” key on the
keyboard (do not the ENTER key or click the mouse) to “wake” it.

If the computer is on, photograph what is on the screen as a means of capturing what the suspect may
have been doing prior to the seizure. At this point, the trained first responder will want to consult with a
skilled examiner and have them respond or conduct a minimally invasive triage procedure as outlined in
the next module.

It should be noted that in the case of an operational business or operational network situation, shutting
down a running computer may not be acceptable. In these scenarios, a shutdown could severely
damage the system and/or render data unrecoverable. It could disrupt legitimate business operations
and create the potential for officer and department liability. The computer may contain information
important to the continued operation of the business. Seizing it may be inappropriate and may make it
impossible for the business to continue to function normally. Co-mingled businesses are also a
consideration for the disruption of a legitimate business.

In these exceptional cases, a p ro pe r shutdow n o f the system may be required. It Is advisable at

this p o in t to sum m on a specialist fam iliar with the proper shutdow n procedure fo r the p articula r
network type encountered.

V. Triage Procedures

BACKGROUND
This section may be a significant departure from previously taught protocols. The end goal of collecting
computer evidence is to ultimately obtain or produce a forensic image that can be analyzed in place of
the original evidence. It is generally not acceptable to alter the original evidence in circumstances where
such an alteration can be avoided. In years past, first responders and forensic examiners were trained to
pull the plug from the back of the computer case without respect to harvesting memory (RAM) or
conducting a triage for the presence of encrypted disks or volumes. The presence of a full disk
encryption scheme was typically very low in most circumstances and the very small data capacity of
RAM in earlier machines were discounted as an “acceptable loss" when a running system was
encountered.

Forensic specialists now operate in an environment where harvesting original evidence without minimal
alteration is simply not possible in many instances. With the introduction and proliferation of
sophisticated full disk encryption (FDE) and full volume encryption (FVE) technology that exists today,
"pulling the plug” on these systems can result in encrypted evidence that cannot be decrypted in the
examiners lifetime. A simple triage procedure causing minimal system changes may be used to detect
these encryption schemes while encrypted evidence is mounted (in a decrypted format) and still
recoverable by forensically acceptable methods. When changes are intentionally performed, document
your actions. Actions conducted systematically and carefully, can be demonstrated to be minimal and do
not “create” evidence. You should be prepared to articulate why these changes were made to the
system.

Serious consideration should be given to whether the data contained in RAM should be captured, as
standard RAM capacities have increased. It is not uncommon, at the time of this whitepaper, to see “off
the s h e lf computer systems containing 8 - 1 6 Gigabytes of RAM with much more RAM possible. No
trained investigator would think it is acceptable to simply destroy and thereby omit an item of physical
evidence in a conventional case. Think of a homicide detective searching the home of a suspect and
leaving the suspects 2000 page personal diary behind without ever scrutinizing it for traces of motive,
opportunity, or intent. Even worse, think of a detective knowing of the diary’s existence, never opening it,
and simply throwing the diary into a roaring fire where it is entirely consumed and the information in the
diary is rendered forever unrecoverable.

When we encounter a running system with 4 GB of RAM and we decide to simply power down the
system prior to harvesting this volatile information we have effectively done the same. One (1) Gigabyte
can hold over 677,000 pages of textual information so in the case of electronic evidence, the implications
could be much than our diary example. The RAM on a running computer system can and frequently
does contain passwords, usernames, and almost any information that can be input to a computer system
or called into RAM by the operating system. In essence, it is no longer considered an acceptable course
of action to simply “pull the plug" on a running, standalone windows system. It is not acceptable to fail to
diligently try to recover relevant evidence in a criminal case.

WHEN THE SYSTEM IS ON

In the cases where a target system is running when encountered by first responders, the task becomes
more involved in determining the next course of action. It should be noted that not all computers involved
in every offense has to be subjected to seizure and examination. What role the system is suspected of
playing in the overall scheme of things will help determine if seizure is necessary.

For example, in a case where a victim has received a threatening email or an email enticing them into a
scam, it may be a perfectly acceptable procedure to allow the owner of the system or the investigating
officer to open the mail service, select the appropriate options to view and print the full message header
with the message, and then print a hard copy of the email and leave the scene with that as evidence.
Consultation with a trained examiner should provide a first responder with proper guidance as to whether
a system should be seized at all.

When triaging a running computer system, consider whether the system is a business or personal
system. Business systems, and even systems with information that is to be published, enjoy some
special protections under the law. If the running system is obviously fulfilling the role of a network
server on a business network then the first responder should stop before attempting to power
down the system and contact a trained examiner and/or someone knowledgeable in the proper
shutdown procedures for the network.

The improper shutdown of a business network server can corrupt data in transit and cause big problems
in trying to restore the network to operational status. The officer can incur personal liability and/or
expose his or her department to liability.
In a home or business system that is not fulfilling the role of a business server, the first responder should
determine if the powered on system has any destructive processes running. Any wiping utility or
formatting utility that may be running may be a D
deliberate attempt to destroy data. To recognizing
every destructive process will not be possible. In Tuesday, February 11, 2003
some obvious cases the first responder may see a 5:30:52 PM
FC007343 Windows 2000
message that says “Wiping” and display a percentage
F:\ WipeAll.exe /DO /D1
of disk space that has been wiped (see Figure 1). If a
This w ill wipe all hard drives in the
destructive process is detected on a home system, system.
the first responder should act swiftly and decisively to Are you sure ? Y
pull the plug from the back of the computer case to Please wait...
preserve as much evidence as possible. The reason ....wiping DRIVE0
to believe a destructive process was running should ....completed
be documented, along with what actions were taken to ....wiping DRIVE!
prevent further destruction of potential evidence. ....completed...

WIPEDRIVE
If it is determined that no destructive processes are
Figure 1 - Wiping Process
running then the first responder should ascertain if the
system is connected to a network. The target system
may be physically connected to a network by cabling like CAT5, or connected wirelessly through an
internal or external wireless card. Generally, an antenna would be an indicator of the wireless capability.
However, an external antenna is no longer required for a wireless connection. Modern desktop
computers, laptops, and mobile devices, may be connected to a network using an internal wireless or
internal cellular modem that is impossible to detect via visual inspection of the computer chassis.
Computers may have attached cellular telephones that serve to connect them to the network. This is
also known as a “Cellular Hot Spot”. The main concept here is that a system connected to a network can
possibly be manipulated remotely. Small icons may be visible in the bottom right or "systray” area of
Windows PCs that indicate whether or not the machine has a network connection, simply by looking at
the state of these icons or conducting a mouseover of the icon.

If a network connection is present then consideration should be given to any active processes such as an
ongoing “copy" or movement of data from the subject machine to some other location. Visual inspection
of the screen may reveal this ongoing movement of relevant data from the target system to a networked
location. A typical “copying” window displays where the data was being moved from and the destination
to where it is being moved. The screen contents should be documented to memorialize these details.
Allowing such an operation to complete before isolating it from the network should be considered.

The first responder should also observe the mouse pointer or cursor to ensure that the system is not
currently under the control of a remote user. If this is the case then the computer should be isolated from
the network by physically disconnecting the Ethernet cable or opening up the network icon by double
clicking and choosing “disconnect” from the menu choices. These actions should also be thoroughly
documented. In these limited instances, isolating the subject computer from the network prevents any
intentional tampering with evidence, but the mere act of disconnecting makes little appreciable relevant
change to the running system.

Once determined that there are no destructive processes running on a system, no active data transfers,
and that the machine has been isolated from the network, additional consideration should be given to
applications running on the system.

If the investigation involves chat clients and there is a chat client or instant messing application on the
screen, there may be relevant data residing in memory that may not yet be committed to the physical
disk. It may be desirable to leave the isolated machine in this state and contact a trained examiner and
inquire how best to proceed with preserving the volatile data in RAM, or if a proper shutdown is
warranted instead of pulling the plug.

A highly skilled examiner may be familiar with the chat client, how the various settings affect the storage
of information to disk and may be able to advise the best course of action. If determined that imaging the
system memory is the best course of action, then it should only be undertaken by a trained examiner.
There are a variety to software tools and methodologies available to harvest memory from a live system
but these are beyond the scope of this module.

The following minimally invasive triage methods are just as the name implies, invasive (causing
changes). These changes are very minimal and are viewed as acceptable in the current forensic
environment if evidence is to be obtained. To begin triage, the first responder should make a precise
notation of the time displayed on the target system in the system clock display at the bottom right of the
screen area (on Windows based PC’s). This notation of exact time in the triage notes will assist an
examiner in identifying any file changes made as a result of the triage activity, should it become
necessary to enumerate those changes at a later date.

Finally, if anything looks out of the ordinary or unfamiliar, a call to a trained examiner may be in order. A
simple consultation may mean the difference in recovering evidence or rendering it unrecoverable. First
responders should not hesitate to ask for, or seek guidance from, forensic personnel when questions
arise. As the proliferation of technology continues it will prove impossible to have a trained examiner
respond to every scene where digital evidence must be collected. First responders must accept the
notion that simply remaining in the dark about digital evidence issues is no longer acceptable.

A flow chart for the trained first responder has been attached as an appendix to this whitepaper and is
available as a companion to this section.

WHEN THE SYSTEM IS OFF

If the computer system is off, leave it off. The first responder may then photograph the computer in its
native environment, including close-ups photos of the setup, the various peripheral connections, and any
obvious defects or damage that exist on the computer system or peripheral equipment. It is also
permissible and preferable to pull the plug from the back of the computer case and document the
connections and associated devices in a diagram and/or by labelling the connections with a marker, tape
or tag. Such diagrams can prove invaluable in cases where the system must later be displayed in court
just as it was at the scene. Evidence can then be properly bagged or labelled as evidence and secured
properly for transport.

Do not power up the system to determine if it is operational and do not browse files on scene
unless there is a genuine threat of loss of life or bodily harm is imminent if the files are not immediately
browsed. Indiscriminate browsing of files will likely render the evidence altered from its original condition
and may cause the evidence to be inadmissible in court. A trained forensic examiner will know that files
were accessed after investigating officers gained control of the system. In any event, whatever a
responding officer does to a computer system and why such action was taken should be documented in
great detail.

In cases where an officer is called to a scene by a concerned party that has inadvertently viewed
improper content on a third-party computer it is not uncommon for the concerned party to offer to power
up the computer and “show the officer" what is there. If the concerned party can describe to the officer
what they saw, then there is no real need for the system to be powered on. In the interest of preserving
the integrity of the evidence and the evidence itself, the system is best left powered down until properly
previewed and triaged by a trained examiner or until a proper forensic image can be harvested.

Passwords
If the suspect reveals that full volume or full disk encryption is being utilized on a system then you do not
want to let the system power down, "sleep", or hibernate. A third party device like a “mouse jiggler” can
also be used to prevent these circumstances from occurring. The easiest way to recover the encrypted
data is to image the machine while it is live, logically. To power down the machine may render the data
unrecoverable. If the encrypted volume is not mounted then even a logical image may not be helpful. It
may be necessary to use the suspect’s password to mount the volume and decrypt the data within for
imaging.

If the suspect is not willing to provide passwords, other materials may be present at the scene that will
help to break them, if necessary. A list of words commonly used by the suspect can be added to some
password cracking programs to help speed up the process of brute forcing the passphrase for encrypted
files. Most forensic tool suites provide a capability for exporting word lists for this purpose.

Passwords are often “hidden in plain sight” or stored in other easily accessible areas such as on Post-it™
note under the keyboard (see Figure 2) or even stuck to
the monitor. They may be written in the margins of the
operating manual where the instructions for using the
passwords appear. Look for handwritten notes near the
computer and during the search look carefully for clues to
passwords or the actual passwords themselves. If
possible, question the suspect closely about passwords. Figure 2 - Sticky Note

Be sure to ask for more than just “ the password.” The suspect may have both a user and an
administrative password for the BIOS boot-up; there may be multiple passwords for different email
accounts, encrypted files, and a different password for their system logon. By obtaining this information,
whenever possible, you could save hours or days of forensic processing (and headaches).

Prior to questioning the suspect, some agencies use a form to garner information that may contain clues
to his or her pass phrases. This form includes information such as pet names, names of kin, dates of
birth of children and spouses and other pertinent information that may yield clues to the passwords used
by the suspect.

Considerations for finding a password when encryption is involved:

• The volatile memory (RAM) of the running system.
• A printed scrap of paper that says something like “BitLocker Recovery Key.”
• A USB Drive or removable media that has a file with a “.BEK” or other unfamiliar extension.
• A smartphone, or mobile device.
• A sticky note or other handwritten notes.
• The underside of a blotter or calendar or notes inside a planner.
• The suspect, spouse, or confidant.
• The windows registry (if the same password is used in other applications)
• Files encrypted at a much lower level (if broken may yield the password)
• Data on file at an ISP
Interviewing the Suspect
Some general interviewing tips -
• Do not reveal to the suspect your level of expertise - you may choose pretend you have only a
basic knowledge of computers and act “fascinated" with the suspect’s system and their level of
“computer genius.”
• Act impressed - the suspect may like to brag about their expertise.
• You can play a “Big Brother/Big Sister” - “I only want to understand...” role.
• Never let them near the computer - even if they want to “show you” how something works or where
files are stored. Rather, have them explain these things to you or direct you while at the keyboard.

Cell Phones, Tablets, and Mobile Devices

If the phone is off, leave it off. If the phone is on, leave it on.

When seizing powered devices such as cellular/smart phones, it is important to also seize the power
supply/charger/AC Adapter.

In older phones, if the battery dies, data is lost. Plug the device into a power supply as soon as possible.

Mobile devices should be isolated from communication signals as soon as feasible to avoid remote
wiping or alteration.

Look for the phone’s service provider connection pack (may contain relevant information).

Ask the suspect for the PIN number, test it and write it down.

Mobile Device and Cell Phone field kit should include:

• Cables, cables, cables.
• Universal battery charger
• Bluetooth adaptors
• ...and maybe RF isolation (Faraday) bags?

On-Scene Documentation
Document the system beyond the “before and after” photographs; take note of the status of the
computer, whether it was on or off, and the condition and type of all the peripherals.

Document any electronic devices that are not taken from the scene.

Consider developing a standardized “scene checklist” form for your officers to utilize at the scene.
VI. C ollection and Preservation (Bag & Tag)

The seizure of computers and other related evidence also bears additional critical responsibilities,
including:

1. Use of appropriate collection techniques so as not to alter or destroy evidence.

AND

2. Forensic examination of the computer and related media completed by trained personnel, with
expert testimony available at trial.

Disable or disconnect the system from any outside communication (internal modem, cable, DSL, etc.);
this is done to ensure no communication continues between the seized machine and the outside world.
The system could still be accessed through a connection if powered on. Do not forget to try to identify
the phone number of any phones connected to the computer system; it may be a different line than is
used for voice communications.

Record and mark the location of unfamiliar cables.

Note the make, model, and serial number of the system.

Collect any software, manuals, notes, and any other written documentation found at the scene. An
examiner may need to install any unfamiliar or proprietary software used by the suspect onto the forensic
computer in order to examine the evidence in a native format.

Don’t just take the computer case. That funny looking box next to the computer may be an external
storage device that is essential evidence.

Don’t overlook small but important data storage devices, such as PDAs, digital camera media and thumb
drives. Remember, some storage devices can be disguised as benign items.

If seizure includes loose storage media such as DVD’s, CDs, floppy disks, or tapes, be sure to collect the
peripheral required to read that media.

Collect and carefully label hardware and other potentially evidentiary peripherals attached to the
computer.

Take special care in labelling any loose media such as 3.5” disks, CDs, etc. Use a non-solvent marking
pen (not any sort of ballpoint) as damage or interference with reading the media might occur.

When packaging electronic evidence for transport, it must be protected against unusual sources of
damage. These items are susceptible to damage from electromagnetic sources such as radios, speaker
magnets, and cell phones. They should also be stored in an area of the evidence room that is protected
from moisture, electromagnetic interference, heat and cold, and critters.

As a precaution, extra packing and protective filler should be used to pack hard drives, computers and
other peripherals. A physically damaged hard drive will likely yield no evidence. Treat sources of
electronic evidence as if it is very fragile.
Do NOT use standard plastic bags (such as Ziploc™ type bags) for packaging/storage of any electronic
media; use only paper bags, cardboard boxes, or antistatic bags and other containers made specifically
for electronic media.

Document, document, document!

Use a basic inventory worksheet for use at the search warrant site; it’s a great tool to assist those who
are new at seizing electronic evidence. Q

Use evidence tape to cover openings to disk drives,

CD/DVD. (see Figure 3)

Bag cables/cords, keyboards, mice, small peripherals

together, if seizing.

Bag loose media such as USB sticks, DVDs, CDs, etc.,

together.

Use original packing material when available.

Use paper bags or antistatic wrap for diskettes and exposed media.

Transport away from extremes - heat/cold/magnetic/radio frequency sources.

Do’s and Don’ts

Do...photograph the computer setup - “big picture” and close-ups.
Do...label and diagram the connections to/from the computer.
Do...use a scene checklist form.
Do...use paper bags or static-free bags for storage media.
Do...call for assistance if you encounter multiple systems networked together, business systems, or
require assistance determining what to seize and what to leave behind.

Don’t...allow anyone near the computer.

Don’t...browse through the computer files.
Don't... turn the computer on if it was off.
Don’t...allow the computer to be ’’shutdown’’ normally (remember there are exceptions!).
Don’t...use plastic baggies for storage media such as hard drives, zip disks, floppy disks, etc.
Don’t... pretend to know everything - ask for help if needed.

Make Use of Standardized Forms

Record chain of evidence custody and details:
• Where the evidence came from?
• When it was obtained?
• Who obtained it?
• Who secured it?
• Who has had control of it?
• Where it is stored?
 Special note regarding laptops: When seizing a laptop, remove the battery first - then
disconnect the power supply; this ensures complete disconnection of all power sources to
the laptop. Be sure to seize the power supply for any laptop - power supplies are often
proprietary to the manufacturer, and may be required in order to access the laptop for
further analysis.

Fingerprint Evidence
One thing to consider that is not often discussed in the world of computer forensics is fingerprints. Don’t
forget to consider the potential need for fingerprinting the evidence. In many cases, a defense argument
against a particular crime like child pornography is that the suspect didn’t put it there. Fingerprints on
USB sticks and DVDs may be helpful to your case in these instances. Any potentially destructive
fingerprinting methods should be conducted after the imaging of the evidence is completed.

DNA / Other Types of Evidence

Be aware that in some instances, a forensic examiner may experience a situation where computer
equipment seized/to be seized has the potential to expose personnel to communicable diseases (i.e.
blood spatter, body fluid, etc.). Blood and body fluid precautions must be taken with all evidence
contaminated by blood or other bodily fluids. To minimize risk of exposure, be sure to wear/use the
necessary personal protective equipment, to include: gloves, face masks, gowns, eye protection, and
necessary cleaning and disinfecting supplies.

Training
In many cases, you may be the only person at your agency trained in seizing electronic evidence.
Consider organizing a training program, with handouts, for personnel at your agency upon return from
this conference. The program could be broad-scale (annual training for the agency), or limited training
(detectives and crime scene personnel who may have the opportunity to seize digital evidence). This will
make your job easier, and help ensure the integrity of the evidence.

Summary
The protocols and procedures outlined in this chapter will help ensure that seized electronic evidence is
in pristine condition for the forensic examination and is admissible in court. Carefully plan each computer
related search warrant so as to anticipate needs and resources prior to arriving on scene. Label and tag
evidence per your agency’s established procedures to ensure the validity of evidence in court. Protect
the evidence and make sure it is stored safely so future examination will capture all relevant data.

VII. SUMMARY CHECKLIST FOR SEIZURE OF ELECTRONIC EVIDENCE

• Remove everyone (especially the suspects!) away from the computer and data storage area.
• Photograph the screen and decide if immediate power cut is necessary.
• Photograph connections and the entire area around the computer.
• Disable the power to the system.
• Disable or disconnect the modem/cable connection/LAN.
• Disconnect the power to the printer and other peripherals.
• Remove disks, CDs, DVDs, optical disks, flash memory cards, etc. from drives and process as
evidence; place a strip of evidence tape over drive openings.
• Interview suspects/contacts regarding the computer evidence and possible password formation.
• Diagram and label all connections to/from the computer for reassembly later.
• Search the scene specifically for passwords or other related information.
• Seize all books, manuals, disks, software, hardware, and information related to the system.
• Carefully package and transport evidence keep away from all electromagnetic fields.
• Photograph the area when search is completed.
 Introduction to Forensic Analysis
The International Association of Pre-Exam / Legal
Computer Investigative Specialists

Contents
I. Synopsis
II. Learning Objectives
III. Pre-processing and Legal Issues
IV. Data Recovery
V. Analysis of Specific Recovered Data
VI. Reporting and Presentation
VII. Conclusion
VIII. Recommended Resources

I. Synopsis
The purpose of this block is to provide new or inexperienced examiners with forensic exam strategies and
critical thinking ideas to aid with planning their exams and to maximize efficiency and thoroughness. Since
every case is different, what may be the best strategy for one exam may not be the best for another. You,
the examiner, have to take each exam on a case-by-case basis. The use of an examination checklist is
almost impossible because each investigation has its own criminal elements that have to be considered
and each computer user will utilize their computer and store data differently than the next, which means
that no two computers or their examinations will be the same.

This course will not focus on the in-depth details of the different types of processes to conduct during the
exam, but instead on what the examiner needs to consider for each phase of the investigation, from the
pre-processing all the way through to the report-writing phase. It is important for you to understand that it is
this critical thinking and strategizing that separates the CFCE certified examiner from the average data
recovery technician.

II. Learning objectives

At the conclusion of this course, the student should understand:
• How pre-planning will aid the examination
• General critical thinking concepts
• Basic strategies to carry the exam from start to finish
III. Pre-processing and Legal Issues
The case preparation is the information gathering process prior to ever turning your forensic machine on.
Before an exam can be conducted, you will need some basic information regarding the type of investigation
that will help you answer several key questions.
• What is the case about?
• What digital evidence can you expect to recover?
• What is your legal limitation?
• Who are the subjects involved and what is their role?

You could compare the exam and strategy process to the approach you may take to constructing a jigsaw
puzzle. When you first get the puzzle, there are several things you need to know about it, such as how
many pieces are in the box?; What is the difficulty level?; What is its finished size?; also, what is the final
puzzle going to look like when completed (the big picture)...a landscape, portrait, or some other scene?
These questions will help you decide how you are going to start the puzzle.

Likewise, you need this type of basic information for your exam. What kind of case is it - fraud, harassment,
child exploitation, theft, stalking, murder, etc.? How much hard drive space will be required to process the
case? Is there more than one item of evidence? Are there limitations to your exam and what kind of digital
evidence do you expect to recover?

For some of this information your best source may be the investigator, the police reports, and the search
warrant affidavit. For some agencies the examiner is also the investigator, but the questions to be
considered are still relevant. Have a detailed conversation with the investigator to find out how the items of
evidence were seized and if there were photos taken prior to seizure, as they may lead to the answers that
may have been missed by the seizing party.

What other questions need to be asked?

• Was the computer on or off?

• Were any notes or paperwork recovered that could contain passwords?
• Was an interview with the suspect done? If so, was he/she asked about the crime?
• Did the suspect provide any passwords?
• What is suspect/user’s computer literacy?
• Was encryption involved?
• Was the evidence preview or “Looked At” by officers on scene and documentation of what they
did?
• Is this a case of consent and was the party advised of how to revoke consent 24/7?

Many obstacles that an examiner encounters can be answered by asking the right questions of a
cooperative subject. Unfortunately, many times the examiner gets the case long after these interviews are
done and you may only have the investigator and/or reports to answer many of these questions.

Some other key things you may want to know is:

• Why this particular item of evidence was seized?
• Does the investigator suspect it contains evidence of a criminal nature, or is it to be used as
exculpatory evidence?
• How many people had access to the item?
• Was it located in a common area or was it in a locked room?
• Are dates and times a factor in the case?
• Are there any time limits placed on the examination?

In many cases the computer may have been taken just because it is always taken in search warrants to
“see what might be on it.” With rising numbers of backlogged cases and the tendency for courts to limit
searches, a review of this policy would be certainly be in the best interests of the department.
 One big question that must be asked is under what authority can I conduct this search? You should make a
habit of reviewing the search warrant or consent form on every case prior to conducting the exam. You
must know if there are any limitations that are imposed on you by the court, such as only being able to look
at images and not documents or spreadsheets; also, examining only one of the user accounts. If you find
yourself with certain limits, you must be able to develop a strategy that works within them. It is incumbent
on you, the examiner, to know the scope of the search and stay within its boundaries.

Finally, you need to consider the other side of the investigation. What pitfalls can you expect? Is there
anything about the case that you will need assistance with? In other words, know the limits of your training
and experience. What resources do you have at your disposal to overcome these limits? The strategy you
employ to obtain the necessary evidence and build your puzzle will depend heavily on the answers to these
questions. Just as a person may start a 1000 piece landscape puzzle differently than a 500 piece portrait
puzzle, an exploitation case would be approached differently than a harassment case. The difference here
is that with a jigsaw puzzle, you can look at the box and see what the final outcome will look like. However,
in the forensic exam you will use this information to formulate an idea of the final product, but you will
ultimately let the evidence paint the final portrait.

Okay, so now you’re ready to turn on your computer and get started, right? What about the physical
evidence you are getting ready to process? Which piece of evidence seized has the highest priority? Have
you maintained a proper chain of custody? Have you documented in detail the condition of the item, the
peripherals, serial numbers, devices, etc.? Have you checked the BIOS for the date and time settings or
boot order? How important would it be if the suspect had written his name on the thumb drive where
exploitive images were located? Detailed examination planning such as this can sometimes be the hinge
point in the case.

IV. Data Recovery

For the data recovery segment of an examination, the assumption is that you have properly write-protected
in order to created a forensic image of the evidence you are working with; and that you are not working
from the original evidence.

Referring to the jigsaw puzzle analogy again, when you open the standard puzzle box, it contains every
puzzle piece needed to create the final product. The computer exam is like opening a box with multiple
puzzles inside, which requires you to locate and identify only the pieces of evidence needed to build the
case as laid out by the investigator.

The strategy process is much the same as one would use with a jigsaw puzzle. Which piece has the
correct colors and shapes that identify it with the big picture? Some like to start a puzzle by building the
edges first, partially because they are pieces that are easy to identify and locate. Likewise, on an
exploitation case one may want to look at the images first. It could give you a quick idea of what the
suspect was up to. Often the examiner is going to go where the evidence is most likely to be located,
whether it is in the “My Documents" folder, "My Pictures,” etc. Then you begin to broaden the search,
maybe looking for hidden files, or examining the swap file and unallocated space.

As you begin to go through the box of puzzle pieces, comparing the evidence to the elements of your case,
you will flag or group certain evidence files together to be looked at closer as the exam continues. In the
exploitation case you may group obvious images and then group other items of interest as they fit into your
total investigation or puzzle picture, such as suspicious emails, internet history, chat logs, etc.

This isolation or recovery process is where most data technicians end their exam. They have identified and
isolated all the evidence that they believe is relevant to the puzzle and give the investigator the pile of
pieces for him or her to put together. This is where the IACIS Examiner is different since you will be
building the puzzle so that the investigator will get a clear picture.
V. Analysis of Specific Recovered Data
Now the real work begins. Identifying evidence for the most part is easy, but explaining the evidence in a
manner that a layman can understand is the challenge, just as putting a complex puzzle together is a
tedious task. This requires looking closely at each piece to determine its shape, size, and color and
determine, based on your findings, the location this puzzle piece plays in the big picture.

Likewise you, the examiner, have to closely look at each piece of evidence for information that explains its
relevance to the case or how it supports another piece of evidence. This often involves looking for other
artifacts that support your evidence or prove your analysis. For example, you recovered several exploitive
images in a folder. The images are the evidence, but what additional supporting information would help the
investigation?

• What other images are in the same folder?

• Are the images categorized?
• What is the user account that is associated with the folder?
• Is the account password protected?
• Who had access?
• What about metadata for the image files and how does it correlate to the investigation?
• Can we tell where the images came from?
• Did they come from the Internet, email, or maybe peer-to-peer?
• Is the image a thumbnail or is it full size?
• Is there EXIF metadata associated with the images that could link the suspect to them?
• How does the EXIF data relate to other EXIF data from other non-evidentiary images?
• Does the hash value match a known database for exploited images?

These questions can be asked about all files, not just images, but also word documents, spreadsheets, and
any other files that could be evidentiary. A word document can sometimes provide information about the
document that ranges from who the author was to the company the program was registered to. These can
sometimes create additional leads, which the investigator was initially unaware.

You are the investigator at this point and need to be able to ask yourself the same questions about the
evidence that you would expect a defense attorney to ask you.

• Can you prove the suspect knew the images were there?
• Can you reasonably show the suspect had knowledge?
• Can you prove or disprove a virus is responsible?

On the latter point there are many ways to do this, which will be and have been discussed throughout this
training. Some of which are finding artifacts in the operating system that support your opinion, i.e., registry
keys, link files, EXIF data, metadata, etc. Another way to prove or disprove something is to do research
and testing to determine the behaviors of a particular program, such as, how does it save files? Does it
rename them? What are the default settings and how do they compare to the evidence? Finally does the
program complete a particular task with or without the user’s input?

As you can see, there are hundreds of questions, which are case specific that can be asked about digital
evidence that is found, also as you ask and answer the questions, you will likely find information gaps. Just
like when building a jigsaw puzzle where you need to connect one portion of the puzzle to another, you
have to try to determine what information is missing and go find it. It could be in the details of the digital
evidence itself, like metadata and EXIF data, or in other supporting factors, such as logs, registry entries,
link files, etc.
 The bottom line is the evidence alone does not make the puzzle or complete the picture. The digital
evidence must be analyzed closely to determine its place in the case or the big picture along with a report
that ties all the digital evidence and other findings together to build the final picture.

VI. Reporting and presentation

The report writing phase of the investigation is the final step in the process and should draw together all of
the critical thinking that aided you with the data recovery and analysis. The report is the masterpiece, the
final picture of the puzzle and the final product of the exam.

The report should flow and be easy to read and worded in such a way that your average reader can
understand the picture you have put together. Just as a person can look at a completed jigsaw puzzle and
see the image, the reader of your report should have a good understanding of the case and the
conclusions you draw.

The report should follow an order that lays out what you were tasked to do, what evidence you examined;
what tools you used; finally, what digital evidence was located and how it pertains to the investigation. It
should be a narrative of your findings pointing to the evidence and artifacts for reference to support your
narrative.

This is where you explain the evidence and the supporting metadata and draw your conclusions based on
your findings. Be careful that your conclusions are based in fact and research and are not a guess.
Remember, many people from your command staff to the suspect and his attorneys as well as other
experts, will read your report. Use professional terms while being careful not to be too technical.

VII. Conclusion
In conclusion, critical thinking and pre-planning must start at the beginning of the investigation and continue
all the way through the report-writing phase. You, the examiner, have to be able to look at each exam and
determine the different types of evidence and supporting artifacts needed to prove or disprove the case,
while understanding that the digital evidence alone does not tell the complete story.

Training and experience will help you fine-tune the strategies that work for you and your forensic tools, but
be careful not to get drawn into a checklist for forensic exams. Remember your resources, as you will find
you never stop learning new ideas and techniques, especially in a field such as computer forensics.

VIII. Recommended Resources

• Becoming a forensic investigator

http://www.sans.org/reading_room/whitepapers/forensics/forensic_investigator_1453
Maher, M SANS Institute Reading Room Site (2004)

• Computer Forensic Field Triage Process Model,

http://www.macforensicslab.com/index.php?main_page=document_general_info&cPath=11&products_i
d=228&zenid=175fed7bf34e8e163b520cafbe66d76c
Debrota, S. Goldmen, J. Mislan, R. Rogers, M. Wedge, T.
MacForensicLab, (2006)•

• File System Forensic Analysis; Carrier, Brian. Upper Saddle River, NJ: Addison Wesley-2005
 2018 BCFE
SPI
SCENARIO
DOCUMENTS
AND
PHOTOS
- 18-14

Status Pending

Contact Assigned
To

Created 24 January 2018 Opened

15:19

Classification None Crime Type Death Investigation

Level Suspicious

Case Number 2017-00300127

Submission Score 10 Priority

— Case Details

— Requested Analysis

_ Search contents o f the computer. A ttem pt to determine ownership. A ttem pt to determine who is responsible fo r the
drug related death o f 17-year-old Zachary Morris on 09/14/2017.
Suspect - Tommy Russell.
— Suspect - Xander Cage.
Victim - Zachary Morris.
Sticky note found on com puter with the following inform ation handwritten on it:
Abcd1234*
Goodies
— It'sAIIGood
Iw antA llofltzip

— A ttem pt to show the sale o f drugs to Zachary Morris.

A ttem pt to show interactions between Tommy Russell, Xander Cage, Zachary Morris, and any other person to
_ establish Tommy Russell as a drug user and dealer.
A ttem pt to identify any possible accomplices in the sale o f drugs to Zachary Morris.
A ttem pt to identify other persons associated with Tommy Russell for future interviews.
Case Agent

First Name Todd

Last Name Guthrie

Cell Phone 541-948-1961

Email Address

Search A uthority

Type o f A uthority Search Warrant

Restricted Scope N ot Restricted

Beginning o f Scope

End o f Scope

Suspect Information

First Name Tommy

Last Name Russell

Vicitm Information

First Name Zachary

Last Name Morris

Case Exhibits

Evidence Item Reference TG-01 -Ausus Laptop Evidence Item Type Laptop

Property Number TG-01

Description o f Exhibit
Make Asus

Model TravelMate P228 Series - N15W1

Serial Number NYVBPAA00164908FC86600

Passwords / Passcodes Unknown

Notes
 o r O f,
CITY OF BEND POLICE DEPARTMENT case # 2017-00300127
ČASE REPORT C O N N E C TE D # 1
L •, 5 5 5 N E 1 5 th S t. C O N N E C TE D U 2
» M IH '
B en d , O R 97701 C O N N E C TE D « 3

REPORTED D AT E/H H c OCCURRED W C D tN T TYPE

I- 09/14/2017 15:35 Other

s OCCURRED FROM Da T I/D M E OCCURRED THRU OATE/TWE LOCATION OF OCCURRENCE

720 NW R iverside BLVD

09/14/2017 15:35 09/14/2017 15:35 Bend

DISTRIBUTION

□ KARL V s LA W □ DA □ DHS □ JUSTICE C O U R T

□ MDT □ JUVENILE □ KID S C E N TE R □ c iR C u r r court

□ USE o f F O R C E □ OMV □ DETEC TIVES □ MENTAL HEALTH

□ P U R S U rr □ O LC C □ ME □ ENVIRONMENTAL HEALTH

□ K-9 O th e r.

CTS STA-HJIXOESCRPTCN A T T E M P T /C O U U iT

U) 163.145
UJ
< />
Crim Neg Homicide Committed
z
UJ 475.854 (F)
U_ 1 Drugs - PCS - Heroin Felony Committed
LL
o
A 475.850
1
Drugs - DCS - Heroin Committed
ueHCrrvsc H A U L tlA S T . T R S T U C C U SUF7C- : P R U A P v ^ 0 ? l£
Cellular
1 Victim Morris, Zachary Scott (541)948-1621
ACCESS CTV S ’ ATÎ.ZP; PHONE 12

720 NW Riverside BLVD Home

DOB AC E C' AGS R a n g e SEX RACE H 0G H T o r RANGE W EJSHTorRAJfG E HAP EYE

08/23/2000 17 Male W hite 5 6 130

DL KUKBCR/STATE AUA.S LA ST. FRST, MDOUE

EMPLOYER H AUE A N D ADORE5 5 EM R .OYER PHONE NUMBER

M A V I (LA S T . FR ST. UOOLE SVFFI* p m i A f i v oh ONE

Cellular
2 Suspect Russell, Tommy Andrew (541)948-1637
- “ O R£C$ (STREET. C H Y . STATE Z P
15 S Gilchrist ST
Bend, OR 97701-
DOB AGE w AG C RANQE sex RACE HECHT o r RANGE W E C K T o r RANGE HAP EYE

05/09/1975 42 Male W hite 6 200 Brow n

OL NUKBER/STATE AL IA S (LAS T . FR ST. MDOLE)

9020567 OR
EMPLOYER N AME A N D A D O R tS S EMPLOYER PHOME NUMBER

SUBJECT TN- PE NAV£ (LAST, FRST. UOCLE SUFFD ; P R g tA R Y PHONE

Cellular
2 Suspect Cage, Xander William (541)948-7729
A2C RE SS (STREET, e r r . STATE ZP>
740 NW Riverside BLVD
Bend, OR 97701-
006 ACE o r A G E RANGE SEX RACE HEC H T o r RANGE W E C H T o r RANGE HAR EYE

07/29/1991 26 Male W hite 5 11 180 B lack Green

D L NUMBER/STATE AL IA S (L A S T . FR ST. M O O L I)

EMPLOYER MAUS a i .O ADDRESS EMPLOYER 3HÛN6 NUMBER

REPORTING OFFICER DATE REVE WED B Y

Guthrie, Todd 3S20 10/01/2017

 sore,.
CITY OF BEND POLICE DEPARTMENT
ČASE REPORT č a s EU 2017-00300127
5. • 555 NE 15tfi St
W ?
Bend, O R 97701

NARRATIVE

Narrative:

On 09/14/2017, at 1535 hrs, I responded to 720 NW Riverside Blvd on a report of an unconscious juvenile male (Zachary
(Zack) Morris) at that location. Upon arrival, Patrol Officer Maniscalco was already on scene and I could see him carrying a
medical AED into the residence. I was directed to a bedroom upstairs by a person later identified as Zack's mother (Rema
Morris).

I saw Zack was lying in the middle of the floor on his back. His eyes were closed and Officer Maniscalco was checking his
pulse and listening for breaths. Officer Maniscalco advised Zack was not breathing and he could not feel a pulse. I
assisted Officer Maniscalco with setting up the AED. I followed instructions provided audibly by the AED and applied
probes to Zack's chest and side. Officer Maniscalco delivered an electrical pulse to Zack's heart and then another one
shortly thereafter as directed audibly by the AED device. Officer Maniscalco then began chest compressions as the
ambulance arrived and medics responded within the room, taking over the life saving effort.

Rema Morris told me she heard a thump on the upper floor from where she was standing in the kitchen and called out to
her son to be sure he was OK. She did not get a response and headed upstairs to check on Zack. She found him lying on
the floor and immediately called for an ambulance. She stated he was breathing at that time, but it was erratic. She further
advised she has had problems with Zack taking illegal drugs in the past.

I looked around the room while medics were working on Zack. I could see an end table next to the bed that had an
approximate two foot long piece of rubber tubing upon it. There was a syringe lying on the ground at the base of this end
table that appears to have been used. I could see a spoon and a used piece of cotton batting in the spoon. There was an
open piece of tin foil on the end table exposing a small chunk of black substance I believed to be tar heroin. There was a
butane lighter lying on the bed. Based upon my training and experience, I believed this to likely be a drug overdose. I
informed the medics of this. The medics loaded Zack into the ambulance while continuing to provide life saving
techniques along the way. They transported Zack to St Charles Medical Center.

I continued to look through the room and located an LG cell phone on a dresser across the room from Zack's bed. The
phone was powered on and was not locked.

I placed the phone into airplane mode and turned Wifi off. I viewed the phone's settings and found a screen lock was set
to lock after 30 minutes. I changed this setting to 'Never'. I manipulated the phone by reviewing all open applications. I
found Facebook Messenger was active. I reviewed an open chat thread with a Messenger user identified as Tom Russell.
In this thread, Zack is making plans to meet with this person to buy drugs. The date and time showing for these messages
are 09/12/2017 through 09/14/2017. The messages are listed as follows:

09/12/2017 at 1523 hrs

• Zack: 'What’s up Tommy, my name is Zack and I heard you could hook me up’

• Zack: '1 am Xander's neighbor. He told me you had some stuff coming in that would blow me away. I've got
money.... he told me to send you a message on Facebook.... he didn't tell you?'

09/13/2017 at 1538 hrs

• Tom Russell: '300 for g. Very potent. You won't be disappointed.'

REPORTING OFFICER OATE REVEWED BY

Guthrie, Todd 3S20 10/01/2017

 ^ '<j CITY OF BEND POLICE DEPARTMENT
t © 1 CASEREPORT case # 2017-00300127
555 NE 15th St.

Bend, O R 97701

NARRATIVE (Continuation)

Tom Russell requests a picture from Zack and Zack sends him a picture of himself wearing a jersey with the number 6 on
the front.

09/14/2017 at 0936 hrs

An agreement is made to meet in Drake Park at 1130 hrs.

09/14/2017 at 1116 hrs

• Tom Russell: 'Don't park in Mirror Pond p-lot. There is an undercover cop car parked there at the moment. Grey
Ford Escape 243FZW.'

• Zack Morris: '1 will park across the bridge at Harmon park, will be there in 3 minutes, just passing the court house.'

• Tom Russell: 'I'm walking there now from Starbucks.’

• Zack Morris: 'thanks a million, I am pumped to try it after school.'

I spoke with Zack's family and was advised that Xander Cage is the neighbor residing next door. They are unaware of
anybody by the name of Tom Russell. I contacted Detective Morin and had him do a local database search for Xander
Cage. Detective Morin advised Xander has previous local arrests for drug related activity. I provided Detective Morin with
the details of the investigation. I requested Detective Morin write a search warrant for Xander’s residence located at 740
NW Riverside Blvd. Due to the nature of events unfolding in eyesight of Xander's residence, I recommended Detective
Morin obtain a telephonic search warrant.

I advised Officer Maniscalco to obtain photographs of Zack's bedroom and to seize the rubber tubing, syringe, spoon, black
substance in tin foil, butane lighter, and LG cell phone. Refer to Officer Maniscalco's report for details. At 1600 hrs, I was
contacted by Sgt Pacheco of the Bend Police Department and advised that Zack Morris died at the hospital.

Xander Cage's residence:

On 09/14/2017, at 1630 hrs, I served the search warrant at Xander Cage's residence. Xander answered the door and
officers searched the residence in accordance with the search warrant restrictions. I seized Xander's cell phone which he
was holding in his hands upon contact with him at the front door. The phone is unlocked. I handed the phone to
Detective Lewis and requested he secure the phone by placing it into airplane mode, removing any screen locks, etc.

I read to Xander his Miranda Warning and he advised he understood his rights and had no questions about them. I began
questioning Xander about his contact with Zack and further inquired about the identity of Tom Russell. Xander stated he
felt it would be in his best interest to cooperate with this investigation but wanted assurance that he would not get into
any trouble if he helped out. I advised him I would provide the details of his cooperation to the District Attorney but could
not make specific promises of any kind.

Xander was at first reluctant to provide information, but then decided to cooperate. Xander advised Tommy Russell is a
friend of his. Xander stated Zack asked him about getting his hands on some heroin and he advised Zack to contact Tommy
Russell and provided him with Tommy's Messenger information. Xander says he has no further involvement what-so-ever
and does not know what transpired since this time.

I turned the interview over to Detective Lewis who was present during the entirety of the interview thus far. I contacted

S P O R T IN G OFFICER DATE REVEW ED BY

Guthrie, Todd 3S20 10/01/2017

 CITY OF BEND POLICE DEPARTMENT
ČASE REPORT 2017-00300127
(i *7,
č a se #
555 N E 15tti S t.
-*■
B e n d , O R 97701

NARRATIVE (Continuation)

Detective Hartley of the Central Oregon Drug Enforcement team and provided Tommy Russell's information. Detective
Hartley advised Tommy Russell is a known drug user and heroin dealer in the region. There have also been contacts with
him in the past with Xander Cage. I provided this information to Detective Morin and requested he prepare a search
warrant for Tommy Russell's residence located at 15 NW Gilchrist, Bend, Oregon.

Tommy Russell's residence:

On 09/14/2017, at 1803 hrs, I served a search warrant at Tommy Russell's residence. Upon knocking and announcing our
presence, Tommy was seen peering out of a living room window briefly. Tommy then quickly moved out of the way of the
window as if to hide. Officers forced entry through the front door. Tommy was taken into custody in the living room of
his residence. There were two suitcases packed in the living room near the front door. It appears Tommy Russell was
preparing to leave the area. Within Tommy's front right pants pocket, I located an aluminum foil ball containing a black tar
substance believed to be heroin. Later testing by Detective Lewis confirmed this. I read to Tommy Russell the search
warrant and then read to him his Miranda Warning. Tommy Russell advised he wanted an Attorney. No questions were
asked of him from that point forward. I had Officer Nelson transport Tommy Russell to the Deschutes County Jail.

Additional items related to the packaging and sales of heroin, such as a digital scale, packaging materials, and small plastic
Ziploc baggies containing small quantities of heroin, in addition to a large sum of cash (approximately $16,000) were found
within the suitcases near the living room front door.

During the course of the search of Tommy Russell's residence, officers located an Acer laptop computer open and running
in the master bedroom of this residence. There was a sticky note affixed to the laptop at the corner just below the
keyboard. There was handwriting on the sticky note as follows:

• Abcdl234*

• Goodies

• ItsAIIGood

• lwantAlloflt.zip

Digital Forensic Detective Kansky was able to obtain a digital RAM (memory) data dump prior to our seizing the computer.
He advised this would preserve important data that would otherwise disappear once the computer is shut down.
Detective Lewis later submitted this computer into evidence as Item TG-01. I submitted a forensic request to analyze this
computer.

Refer to Detective Lewis' supplemental report covering the details of the search warrants served and evidence seized.
Refer to Detective Morin's supplemental reports reflecting the search warrants written in this case.

Disposition:

Case cleared by arrest. Investigation is ongoing. Awaiting forensic analysis of evidence item TG-01.

REPORTING OFFICER DATE REVEW EO BY

Guthrie, Todd 3S20 10/01/2017

2017-00300127 Item TG-01 Tommy Russel's laptop

17-300127 (Item TG-01) 002 17-300127 (Item TG-01) 003

17-300127 (Item TG-01) 004 17-300127 (Item TG-01) 005

TravelMate P27Bseries
MODEL N O .(B 2 «l:N 15 W 1
DC RATING( ■ X H 3 " ): 1 9 V ~ 2.37 A
Ac*f InCQrpoatfed
z Kinn.'i:
Product of Ac«r Inc >c«r . . . ^
*ml logo ora raglitared
trademarks of A w Inc CAN ICES*3(D)/NMB*31B)
■Factory ID:CQ Mod* In Chlna/BuaUn China
| lows

17-300127 (Item TG-01) 006 17-300127 (Item TG-01) 007

Page: 1 / 2
- 2017-00300127 Item TG-01 Tommy Russel's laptop

17-300127 (Item TG-01) 010 17-300127 (Item TG-01) 011

Page: 2 / 2
 Hashing & Hashsets
IACIS
The International Association of
Media Examination & Analysis

Computer Invest-gative Specia ists

Contents

I. Synopsis
II. Learning Objectives
III. What Is Hashing?
IV. Hashing Algorithms
V. Forensic Uses Of Hashing
VI. Hash Sets
VII. Problems With Hashing
VIII. Hashing and Solid State Drives (SSD)
IX. Programs That Utilize Hash Functions
X. Recommended Resources
XI. Glossary
XII. Conclusion

i. Synopsis

Admissibility of scientific evidence in a court of law is dependent on whether or not it is valid and
reliable. In digital forensics, data validation is verifying that forensic images or copies of the original
evidence are exact representations of that original evidence. The hashing algorithm is a widely
adopted tool to perform this function in digital forensic world. Examiners can use hashing algorithms to
verify forensic image files of suspect media, a particular file, a set of files, or a string of text.

The goal of this block of instruction is to explain the concept of hashing, the types of hashing algorithms
and the forensic uses of hashing. At the end of this block, you will understand what a hash "collision"
means, know about available hash sets, and be able to introduce to some software tools available for
hashing.

II. Learning Objectives

At the conclusion of this course, the student should be able to:•

• Define the concept of hashing.

• List popular hashing algorithms.
• List different uses of hashing in digital forensic analysis.
• Understand the concept of hash collision.
• Explain the importance of using Hash Sets in digital forensic analysis.
III. What Is Hashing?
In digital forensics, hashing is a way to represent a piece of digital data with a unique alphanumeric
value by applying a mathematical algorithm to the data. It is simply a mathematical representation of a
variable length input; whether it is a sector, individual bytes, text, single file, group of files, partition, or
entire hard drive. The result is a fixed length value. Two files with exactly the same bit patterns should
hash to the same value using the same hashing algorithm. A popular analogy is to compare hashing to
fingerprinting, in that each distinct pattern of data has its own unique hash value similar to each
person's fingerprints.

Hashing is an excellent way to verify the integrity of a pattern of data and has been adopted for use in
digital forensics for several purposes. A hash value is a unique and extremely compact alphanumeric
representation of a piece of data. The value produced from the hashing function is considered a one­
way function; in that, under current mathematical and computing capabilities, you cannot take a hash
value and reverse the process to produce the original data that created the hash value. This one-way
function has been very beneficial to law enforcement; they can share the hash values of evidentiary
files, such as child exploitation material - CEM, (also known as child pornography) without having to
exchange the actual images. This avoids the obvious complications that might arise from the sharing of
such files, but still allows law enforcement to collaborate on investigations

IV. Hashing Algorithms

There are three types of algorithms that are commonly use in the digital forensics field: CRC, MD5, and
SHA. The objective is the same with each algorithm application - to certify with some degree of
accuracy that the data presented is without error and is in fact a true and accurate copy.

Cyclic Redundancy Check (CRC) - comes in 16- or 32-bit variations. It was developed to ensure
data integrity and is still used for that purpose. An example of this is sector checking, ensuring a
sector’s data is good by running a CRC against the data held in the sector. CRCs are also used to
validate data sent by modem transmissions. As a validation hashing tool, it is old and considered quite
weak; because of this, its use in the digital forensics field, generally speaking, has been discontinued
for file verification.

An example of a CRC 32 bit hash run against a single file as seen in Figure 1.

o a.- & a- 3 e* » - -e • « ► M
TlXJJ.&S*«. i«J

1 1 ME» Ot n c n r r
1 00000000 ?v
a: vao? «4 44 71» 31 2 E 33 or* 2 V E7 E ) C F D3 O f CA -P T F -i 3 *¿5X0
OO0 0 0 0 1 0 3) 70 30 70 t r 67 6 A nr> 3C 3 C 7 0 o n 7 r 4c 17 3 O o b ) <« 'I.
00000020 17 IK «.4 Cl 77 6 9 7A «.V 14 70 31 7 0 O O 7 F 4P 70 *r.«» 1 'O
0 0 0 0 0 0 )0 : 32 )V 7 0 Ot* 2 F 4 » 70 20 31 30 31 70 36 S2S H [ 110: 6
20
ï
00000040 39 30 VO 70 0 0 7F 4C 31 3V 33 36 39 31 90 J 'L 11V3699
ooaoooça 70 OB 7 1' 4' . 7 0 3 3 3 0 36 37 37 33 70 on 7F 4 »: 70 -K 306771 'H
O O O O üGcû a : 34 70 Ot* 2» S i 2 0 a: 31 3 S 31 3& 31 39 20 0£> 14 'I 1161119
00000070 3E 3E 70 OO 6 5 6 E 64 6F 20 20 20 20 20
0^0»o-* >»*• 2/1 0/2004
I Ci *4 S2
oooooooo 70 70 70 20 20 7 0 7 0 70 20 20 20 20 20 70 20 20
O OO O O O I O 70 70 70 70 70 70 70 70 70 70 70 70 70
•*»#■!r»* OUOO OOA O 70 70 70 70 70 70 70 70 77 cS term
O OO C O O B O 66 0C> 31 32 ) 3 30 30 30 30 30 1 1 2 3 32 0( 30 00 0
oooooc»:o
concooro
30
30
30
30
31
30
34 20
30 30
0016 00000 00 u
GOOOOOL.Ü 70 OO 30 3 0 JU
O OO OO OF O 30 30 70 6E 20
0 0 0 0 0 :0 0 30 30
00000:: a 70
37
30
37
30
37 31 7 0
00000)20 30 30 30 30 37
O O O C O l)0 70 OD 30 3 0 30
0 0 0 0 0 :4 0 30 30 70 6 E 20
oooooiso 70 30 30 30 30
30 30 3? 34 7 0
ooooo:7o 30 30 30 31 ) ? 30 30 30 2 0 6 E 00017606 00000 «
ooooo:«o 70 OO 30 30 3 0 32 20 3 0 3 0 30 0 0 0 0 017712 000
onaco*. *»n 30 30 70 (C 70 30 30 30 37 35 3 7 3 1 31 OO n 00000767**!
00000 n UUU002
GU0CU1AO 70 30 30 3U JO 20 0X> 30 30 30 30 JO 32
ooooo: bo 3S 3) 31 34 2 0 30 30 20 6E 20 O B 30 30 S 3 1 4 0 0 0 0 0 t. 00
oooeoico 30 30 30 3 3 37 20 30 30 30 30 30 2 0 6 E 00032744 00000 n
• N301D0 70 on 30 30 30 37 70 30 30 30 OOOOC 3 7 7 0 7 0 0 0
0 0 00 0:i.Ci 30 30 70 Cti 70 33 39 3S 34 J S OU r. C000 0 26S4S

Figure 1
M e s s a g e D ige st 5 (M D5) - is an algorithm for computing a condensed representation of a dataset or a
file. The condensed representation is of fixed length and is known as a message digest or hash value.
It has been in use for quite some time in the digital forensics filed, and is a highly popular hash
algorithm. The MD5 was developed by Professor Ronald L. Rivest In 1994. It is a 128-bit (16 byte)
message digest. It is a relatively fast and simple implementation. There is a FAQ regarding the MD5 at
http://www.faqs.org/rfcs/rfc1321 .html. For example, if we run a MD5 hash against a text file that
contains the letters “abc” the resulting value generated is:

900150983CD24FB0D6963F7D28E17F72 - a 128-bit message digest.

It does not matter that the MD5 hash Is run against a file, a partition or an entire drive as the resulting
value will be a unique 128-bit message digest. The probability of creating a file or dataset to match a
given MD5 value is approximately 2 . It is highly unlikely, though not impossible, for two sets of data
to have the same hash value.

Mathematically, 2128= 3.4028 x 1038or 340,282,366,920,900,000,000,000,000,000,000,000,000.

Therefore, for a computer to have two dissimilar files with the same hash value, it would potentially
have to contain 340,282,366,920,900,000,000,000,000,000,000,000,000 + 1 files. Flowever, in March
2005, researchers at a University in China were able to create two files that differed in their contents
that had the same MD5 hash value. This became to be known as a "Collision" which is described a bit
later in this paper.

Figure 2 shows an example of a MD5 hash run against a single file.

p¿u a f ff r fcQfe» mt k - -5 ) ^ ¿2< ► M $

2<03_&V$tf
XO.GSPSfd
C 'D o itfn a 'fi and Scrtn^UeCTSW ^
¿ad
11 M| 01 ! set 0 1 2 3 4 5 4 7 1 7 1 l C D E F
11 H C ttt»* 00000000 2 5 ?o « 44ID 31 2E 3) er> 25
E2 E ) CF C>3 CD Cl 1 X M IO
2X3 G‘ l K f ooooooto 31 3 : 33 :o30 20 4F 42 i k or>
k 3C 20 CD 2F 4C 123 0 o b j << /1
C0000020 47 4E 45 4172 47 n 45 44 20 31 20 CD 2F 4F 20 iz**d 1 /0
JtXVll 00000030 31 ) : 35 ;oCD :f 4 1 20 5B 20
31 31 30 31 20 34 125 ' l ( 1101 4
00000040 I f ) l :o 5D:o CD : f 4C 20 31
31 35 31 34 37 31 78 ) /1 1153471
UrtitWvd 0 cocoocso :o CD ;r 45;o 33 31 34 32 3237 20 CD 2F 4E 20 ' Z 314227
rJ* OOOCOOiO 31 34 :o «■:r 54 :o 31 31 3531 31 31 37 20 CD 14 /T 1151117
00000078 3E 3E :o CD45 CE CD :o 20
44 4F 42 4 ; 20 20 20 >> er/lclo
C * ahy.tr* 2/lOttW 00000018 : : :o :o :o:o :o :c :o 20 2020 20 20 20 20 20
1044 5? 00000070 :o :o :o :o:o :o :e 20 20 2020 20 20 20 20 20
Lai H ti vr«r 09000010 :o :o :c :o:o :o :o 20 20 2020 20 20 71 72 45 we
104455 OOOCOOiO 44 CO 31 323) 20 33 32 20 CD30 30 30 30 30 30 ! 123 12 DC0900
OOOOOOCO 30 30 31 34:o 30 30 30 30 3020 4E 20 CD 30 30 0314 C 0X 0 L 00
4 000000(0 30 38 30 3030 37 37 31 20 3030 30 30 30 20 4E 0X09773 09009 t
0 09CC99E0 ¿0 CD 30 3030 30 30 30 31 37
37 37 20 30 30 30 C09C0317W 900 M0)(WIN)
OM COOf» 30 30 20 lE:o CD 30 30 30 30
31 i t 32 30 31 tt 03 a 0X0902917
1 cooco:co 20 30 30 3« 30 30 20 4E 20 CD30 30 30 to tt to OCOM s OCOtCO
Me of m n j m 1 C 0089U0 t : 3 : 3: 31to 30 10 30 30 10
1« 4E 20 Ct' to tt t i l l c o m n CO tv*
Huh coooo::o 38 30 30 303? 32 34 32 20 3030 30 30 30 20 4E 0X02242 0 X 0 9 r> < t( n w i M i * i t « i w o c a inr,n
AM$U$0l 000001)0 I f cd 30 30 30 30 31 35 20
30 30 32 32 30 30 30 000009220$ X 0
Of»»«! 00000140 1« 30 ;o 4E;o CD 30 30 3D 30
30 31 30 30 35 31 09 n 03C091C951
&/•» r * w 4 3 H «* 000001(0 ;o 30 30 30 30 30 :c 4E 20 CD30 30 30 30 30 31 0C09C ft 9C09CT I 0w |
09000140 I f 30 37 34:o 30 30 30 30 30
20 4E 20 CD 30 30 0974 C 0X 0 t. 00
O fttw i 00000170 30 30 30 3137 34 31 37 20 30
30 30 30 30 20 4E 09C174I7 O X CD r.
coco 0 : 1 0 :o CD 30 30 30 30 30 31 :• 37
31 32 20 30 30 30 C0X017712 X O
a« J j t US 30 30 :o 4E:o CD 30 30 30 39
39 32 35 32 37 31
'0rll ■'.“‘f T. 09 » 09C0925271
30 30 30 30 30
•III !)» C0CC31BD 35 33 31 34 :o 30 30 30 I I 39 20 4E 20 CD 30 30 5314 C 0X 0 l 00
IK K |i) 20517 09CC01C0 I I 30 30 33 32 37 34 34 I f 30 30 30 30 30 20 4E 0X32744 0 X 0 3 b
32 E* lit 1170382035 000001(0 :o or- 30 30 30 30 30 3) 32 37 31 37 20 30 30 30 00 X 0 )2 7 0 7 X 0

Figure 2

Se c u re H a sh A lgorithm (S H A ) - newer than MD5, SHA an algorithm for computing a condensed

representation of a set of data or a file. It is a 160-bit message digest and very popular. SHA was
developed by NIST (National Institute of Standards and Technology); it is specified in the Secure Hash
 Standard (SHS, FIPS 180). SHA-1 is a revision to this version that was published in 1994.2 An
undisclosed security problem prompted the NSA (National Security Agency) to release an improved
SHA-1 in 1995. Florent Chabaud and Antoine Joux later discovered a differential collision attack
against SHA in 1998. For many years, it was thought that SHA-1 could not be broken, until early 2017
when researchers from Google and CWI Amsterdam posted a SHA-1 collision (see section on
Collisions later in this paper). SHA-1 produces a 20-byte message digest as opposed to the smaller
16-byte MD5 hash. Although slower than MD5, this larger digest size makes it a stronger hash
algorithm. For example, if we SHA hash a file that contains “abc” the resulting value generated is:

A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D

An example of a SHA-1 hash run against a single file as seen in Figure 3.

SHA-2 was the next hashing algorithm to be developed and included significant changes from SHA-1.
While most just refer to it as "SHA-2", it is actually a family of hash functions with hash values that are
224, 256, 384 and 512. The most popular of which are SHA-256 and SHA-512, which are computed
with 32-bit and 64-bit values respectively (https://en.wikipedia.org/wiki/SHA-2).

In 2012, after a competition held by the US National Security Agency (NSA), an algorithm known as
"Keccak" (pronounced "Catch-Ack") was chosen as the next SHA hashing algorithm and was called
SHA-3. In 2015, NIST released SHA-3 as a cryptographic hashing standard.
(http://www.nist.gov/itl/csd/201508_sha3.cfm). While not widely used by the forensic community, it may
become a forensic hashing standard in the near future.

V. Forensic Uses of Hashing

Since the advent of increasingly larger capacity storage media, and hard drives in excess of 10 TB, the
number of files on any piece of computer storage media is quite unmanageable. An investigator could
spend many unproductive hours perusing files that have no evidentiary value. Additionally, there are
many different versions of operating systems - within Microsoft alone there are numerous versions.

2 SH A I Secure Hash Algorithm Version 1.0. Retrieved November 6. 2007. from

http://www.w3.org/PlCS/Dsig/SHAl_l_0.html.
 Each version has many editions like Home, Pro and Ultimate, which may have unique files according to
the specific edition. Many software programmers will include files with their applications so that their
programs will run on multiple operating systems. Furthermore, with today’s inexpensive storage space
and memory, many software packages are "bloated” with optional files. Hashing is a way to eliminate
all those installed software files that contain no pertinent user data or potential evidence.

Additionally, hashing can help you identify the "needle in the haystack” - one file existing among
thousands of other files - and the only one that holds the evidence that the investigator needs.
Sometimes just finding a matching sector of a file which was part of a file being sought is enough to tip
off the investigator that the file exists or existed on the computer system.

Hash analysis can be a useful and time saving tool for law enforcement digital forensic investigations
through:

• Verification: Can be used to show that a data object (file, partition, disk drive, media device) has
not changed - been altered or modified - during the forensic process. It can also provide positive
confirmation that the data object is forensically sterile media i.e. the media has been overwritten
with a single, known value. For example: overwriting the target media with a known value of 0x00
will result in a Checksum64 result of all 0’s.

• Hash Value Match for File Exclusion: Hash analysis can be used to "eliminate” files - such as
operating system and application program files - from the examination. This greatly reduces the
number of files to be examined by the investigator. These would be files that the investigator can
safely ignore; it is sometimes referred to as "Negative Hashing" or "De-NISTing".

• Hash Value Match for File Flagging: A list of hash values for known and sought out files can be
compiled and used to search for and identify files of interest to the investigator - files such as
existing images of child exploitation material, a watermarked file sent in an undercover capacity,
or a document containing proprietary data. Matches on these files should alert the investigator to
potential evidence; it is sometimes referred to as “Positive Hashing”.

• Clone Authentication: Under appropriate circumstances, a hash of an original device can be

compared to a cloned version of that media (or a restored image file) and the hash values
compared to confirm an exact duplicate, forensically sound copy was made. This can only be
done against an image when the resulting clone is unadulterated by index values, period
checksums, or other additions to the resulting clone. Additionally, any variation in the calculation
of the hash value, such as varying partition size and the like, will alter the resulting value.

VI. Hash Sets

“Hash Sets” are lists, or databases, of hash values. They are generally:

1. files an investigator will seek to eliminate from the media to be examined because they are
common files that will not hold data of interest, or

2. files that the investigator is interested in identifying on a particular system.

There are several hash sets available to law enforcement. However, it is also possible for any
investigator to create their own hash sets from any file or files that they have available. For example,
investigators frequently working CEM cases may find it useful to compile and share hash-lists of known
CEM images with other investigators focusing on these investigations. It is possible to link subjects
who have images in common although they may be targets of different investigations in different
jurisdictions -- without having to transmit the CEM material to the other Investigator.

Most digital forensic software tools come with the capability to use hash sets from a variety of sources.
Although there may be some overlap in hash sets, there are also many unique values that make each
hash set worth the time to acquire. Some of the hash sets available include:
 PROJECT VIC - For Law Enforcement Only - The purpose of Project Vic is to create a method of
information and data sharing amongst law enforcement to help fight crimes against children. They have
a robust set of hash values that help identify and/or eliminate images during the examination.

NIST NSRL - the National Institute of Standards and Technology maintains a National Software
Reference Library (NSRL) that contains over 11 million unique SHA-1, MD5 and CRC32 values for 43
million plus files. You can go to this web site for more information about the sets available for download:
http://www.nsrl.nist.gov.

VII. Problems with Hashing

Collision:

MD5 produces 128-bit hash values. It was once considered to be computationally improbable to find
two distinct inputs that hash to the same value. In August 2004 at the Crypto2004 Conference,
Chinese researchers, Weng, Feng, Lai and Yu announced that they had discovered a method to
"break" a number of hashing algorithms including MD5. According to their paper, they were able to
produce two different files have the same hash value. This was known as a “collision”. Using two
1024-bit files differing by 6-bits they were able to produce the same hash value using the MD4, MD5,
HAVAL-128 and RIPEMD algorithms. This theory is commonly known as the “birthday attack.3"
(originally named after the birthday problem in probability theory - where in a set of n randomly chosen
people, some pair of them will have the same birthday - https://en.wikipedia.org/wiki/Birthday_problem).
It should be noted that they were not able to produce a collision using known files such as system or
application files. The common thought is that investigators should start including the use of either SHA-
1 or both MD5 and SHA-1 in their case analysis and reports. NIST stated that since 1994 the Federal
standard set forth in FIPS 180-2 is SHA-1 and by 2010 NIST planned on phasing out of SHA-1 in favor
of using SHA-224, SHA-256 SHA-384 and SHA-5124.

In early February 2017, researchers and academics from Google and CWI Amsterdam (a research
center in the field of mathematics and theoretical computer science) announced that they had
successfully collided the SHA-1 hash algorithm. They successfully created two PDF files, both with an
embedded JPG image and were able to get the same SHA-1 hash value. The entire research project
took, 9,223,372,036,854,775,808 SHA-1 computations
6500 years of CPU time, and
110 years of GPU time.

More information on the SHA-1 collision and how Google and CWI Amsterdam created this can be
found at
https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html, and
http://shattered.io/

3 Originally named after the birthday problem in probability theory - where in a set of n randomly chosen people,
some pair of them will have the same birthday - https://en.wikipedia.org/wiki/Birthday_problem.
4 How to Break MD5 and Other Hash Functions. Retrieved November 6.2007 from
“ http://www.infosec.sdu.edu.cn/iiploadfile/papers/How to Break MD5 and Other Hash Functions.pdf’
 All hash values have the potential to suffer from collisions, especially if the sampling of data objects is
large enough to exceed the number of unique values producible by the result group. In other words,
there is always the probability that two different files can produce the same hash value, but the
probability of that occurring is exceedingly low. For example, if you are using MD5 to generate your
hash values, there are 2 128 different values that the MD5 can generate. That is 3.4028 x 10 38 or over
340 b illio n b illio n b illio n b illio n (3.4 Undecillion) unique values5.

This SHA-1 collision announcement was bound to happen because of the computing power that we
now have available to us to let someone create that collision in a controlled environment. While it is
improbable that a Forensic Examiner may find two dissimilar files of evidentiary value that have the
same SHA-1 or MD5 hash value, it is even more improbable for those files to have the same SHA-1
and MD5 values. Many Examiners and forensic software will create MD5 and SHA-1 hashes of files
that are being examined. While this does create a big processing overhead, it may be something an
Examiner might want to consider if they are concerned about collisions.

Does the discoveries of "collision" mean we in the digital forensics field should never use MD5 or SHA-
1 algorithms? Probably not. They have a more significant effect in the cryptographic world where
Digital Certificate Signatures, Software Vendor Certificates, PGP Signatures etc rely on these "blind-
verifications." As Forensic Examiners, we always trust but verify. If we find two files have the same
hash value (let's assume containing CEM), we would open both files to verify their content. Would the
use of MD5 and SHA-1 change in the future - possibly but for now, an Examiner should have a firm
understanding what collisions mean.

Other Hashing Issues:

Implementing hashing in digital forensic examinations can introduces various challenges. First, hashing
is a time consuming function. If you are hashing a 200GB hard drives, the hash process can take
upwards of half an hour or more. What about a 1,2, or 4 TB drive seen in many computers today?

Another issue that does occur is that hash values run against the same data object (hard drive, file,
partition) result in different values. Assuming that no modifications to the data on these objects took
place, there are other reasons why hashes fail to match.

There have been documented examples of faulty memory chips inside the computer resulting in the
computation of different hash values. Read errors on the data media, such as bad sectors, can also
result in varying hash values.

Sometimes, user errors occur where the first hash was conducted on the physical level, and the second
pass run only on a partition or logical level. There are also times when hashing programs will "pad”
data to the end of a file. Furthermore, some programs that create image files of cloned devices add
information to the file this will results in different hash values between the file and the media.

Another common user error is hashing different sizes of physical drives. For example, some
applications will "see” the last sector of a drive while others will not see it. The user must be careful
when initiating the hash to ensure that the proper number of sectors are read to get a proper
comparison.

Using carving functions of different forensic software tools may result in different hash values. One tool
may hash the logical file while the second is hashing the physical file - this has been noted when
carving image files from unallocated space.

5 http://www.forensicfocus.com/unique-file-identification-nsrl-l
 In cases of a hash mismatch, the Examiner must take steps to eliminate all outside criteria and rehash
that data-set. For example, use a different computer, a different operating system or a different hashing
program and compute the value again. This would help the Examiner to determine if the dataset is
corrupt or tampered, or if the mismatch was caused by other factors mentioned above.

VIII. Hashing and Solid State Drives (SSD)

Solid State Drives were introduced to the market in 2007; these drives contain no moving parts and are
intended to speed up access to the data. An SSD also has built-in storage efficiency; however, this
built-in "intelligence” is in turn, changing the way Forensic Examiners approach and image process.

The controller on SSDs are programmed with features such as “garbage-collection” and “wear-leveling".
While each of these features are used to improve efficiency and decrease access-times and latency,
the same features also interfere with what we have always known as forensically sound methodology.

“Garbage-collection” is the process used by SSDs to relocate data so that the original area can then be
deleted. SSD data areas are broken into “blocks". Each block contains a smaller area called “pages”.
When data is written to an SSD, it can be written onto the smaller area (i.e. a page). However, only a
full block can be deleted. Unlike standard platter-based hard drives, data on SSDs cannot be written to
an area unless that area has been previously deleted. So, if a block has all pages except one not in
use, the SSD will relocate that one page in that block so the block can be erased to make way for new
data.6

Each block on an SSD has a certain “life-cycle” for the number of times it can be written to and erased.
This is generally thought to be around 3,000 to 100,000 cycles. In an effort to make sure each area is
uniformly written to over the life of the SSD, the controller implements a feature called “wear-leveling.”
Wear-leveling will move data from a possibly more-used area to another to lesser-used area.

There are two types of wear-leveling that are of importance to us;

Dynamic: where only the blocks that undergo rewriting are moved and blocks that have read-only data
in them are not moved to new locations.
Static: Same as dynamic wear-leveling with the exception that even blocks that contain static (read­
only) data are also periodically moved so that these blocks which are seldom being written to can also
participate in the wear-leveling process, thereby even out the use of all blocks in the SSD.

These SSD features are independent of the operating system or the computer. These features have
been known to activate when a SSD drive is in use, idle or a few minutes after power-on. Since these
features are resident on the controller of the SSD, connecting the SSD to a write-blocker will have no
effect on preventing them from carrying out their duties.

This presents a dilemma for the Forensic Examiner. Due to garbage-collection and wear-leveling data
is deleted and moved around without the knowledge of the Examiner. This can result in deleted files
being unrecoverable almost minutes (in some cases) after deletion7. It can also result in data being
found more than once - once in the current location and possibly in the block that was set for garbage
collection but which has not taken place yet. Another issue facing the Examiner would be the hash-
mismatch on drive images. If a drive is acquired, imaged and hashed successfully, it is possible that
the same drive under exact same conditions, will produce a very different hash value at a later time.
This is due to the features explained above and is something an Examiner may encounter and should
be able to explain should he or she be asked.

6 Smith, Kent, Garbage Collection and TRIM in SSD s Explained, 2012

' Bell, Graeme and Boddington, Richard, Solid State Drives: The Beginning o f the End fo r Current Practice in Digital
Forensic Recovery, 2010
Programs That Utilize Hash Functions
There are numerous programs available to the forensic examiner that utilize hash functions. WinHex,
Zimmerman Hasher, Jacksum, and CyoHash are some programs that will hash different data sets.

WinHex http://www.x-ways.net/winhex/
When WinHex is loaded, and “Open Disk” tab is selected the following screen appears as seen in
Figure 4.

Edit Disk

E ££•: Logical Drive Letters

(C:),HD0
^ ^ (D:)
j- HP.TOOLS (E:). HDO
¿a Removable medium (F:), RM 1
HP_RECOVERV (G:), HDO
IACIS (l:).HD2
- 4 (Ft)
É Physical Media
s HDO: Hitachi HTS727575A9E (0.7 TB)
RM1 : KingstonDT 100 G2 (3.7 GB. USB)
HD2: Seagate FreeAgent GoFlex (466 GB. USB)
Optical drive 0
Optical drive 1

Cancel Help

Figure 4

Select the physical device you want to perform the hash function
(In this example, the Kingston 4GB USB flash drive is selected).
Select “Checksum (64 bit)” as seen in Figure 6

1 2 Compute hash m 12 13 14 1

0 00 00 00 00 0
0 00 Compute hash 00 00 00 0
0 00 Checksum (64 bit) 00 00 00 0
0 00 Checksum (8 bit) J 00 00 00 0
o 00 Checksum (16 bit) 0
00 00 00
Checksum (32 bit)
0 00 Checksum (64 bit) 00 00 00 0
0 00 TTU UTT CRC16 (16 bit) uu UU 00 00 00 0
CRC32 (32 bit)
0 00 00 00 00 00 00 00 00 0
M D 5 (128 bit)
0 00 00 00 SHA-1 (160 bit) 00 00 00 00 00 0
0 00 00 00 SHA-256 (256 bit) 00 00 00 00 00 0
RipeMD-128 (128 bit)
0 00 00 00 RipeMD-160 (160 bit) 00 00 00 00 00 0
0 00 00 00 M D4 (128 bit) 00 00 00 00 00 0
ed2k (128 bit)
0 00 00 00 UV V ■_>«_> c u <_><-■ 00 00 00 00 00 0
0 00 00 00 00 00 00 00 00 00 00 00 00 00 0
n aa aa AA n n n n n n nn nn n n n n n n AA n n r>

Figure 6
 0000000016 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ;

0000000032 nn nn nn nn nn nn nn on nn nn nn nn nn r 0 00 00
0000000048
1 C h e cksu m (6 4 bit)
■ x j 0 00 00
0000000064 0 00 00
0000000080 ...for KingstonDT 100 G 2 0 00 00
_
0000000096 In n x M firifi'Y iiV ififM -B 0 00 00
*
0000000112 0 00 00
0000000128 0 00 00
Close
0000000144 — * 0 00 00
0000000160 w "TJiJ on on on on on o rr— crrr-iT cr -ortr-xrcr' W “ C 0 00 00
0000000176 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Figure 7

MD5 hash result for same device is shown in figure 8. Using an MD5 hash, it is difficult to look at the
value and assert that this media was overwritten with the known value “0x00”.

0000000016 00 00 00 00 00 00 00 00 00 00 00
0000000032 MD5 (128 bit) 0 00 00
x]
0000000048 0 00 00
0000000064 ...for KingstonDT 100 G 2 0 00 00
0000000080 0 00 00
OE44C6A06B474812F96BE2A9A.379338
0000000096 0 00 00
0000000112 0 00 00
0000000128 Close 0 00 00
0000000144 0 00 00
0000000160 00 00 00 00 00 00 00 00 00 00 00

Figure 8
 Zimmerman Hasher
Written by former FBI Agent Eric Zimmerman, an IACIS Member. The tool is available on the IACIS
Memkber Site. The software allows the user to drag-n-drop a file or folder into the user interface and
quickly computes the requested hash values.

Jacksum
http://sourceforge.net/projects/jacksum/
Jacksum is a free platform independent checksum utility (written entirely in JAVA) for computing and
verifying (integrity check) checksums, CRC and hashes (fingerprints). It supports 58 popular hash
algorithms.

CyoHash
http://cyohash.sourceforge.net/
CyoHash is a free shell extension that is used from within Windows Explorer. It allows for right-clicking
on a file to bring up a dialog box containing a selection of hashes for the selected file (currently MD5
and SHA 1) in a mixture of encodings (hex, base 32, and base 64). CyoHash can run Base 32 SHA-1
values. This is especially useful for Gnutella investigations since proactive peer-to-peer investigations
key on Base 32 SHA-1 values for contraband files.

FileFormat.Info
http://www.fileformat.info/tool/hash.htm is an online hash calculator. It can perform a wide range of hash
functions.

IX. Conclusion
As discussed, there are several different uses for hashing and different hashing algorithms to aid a
digital forensic examiner in the examination process. Examiners need to be cautious however and
understand the benefits as well as the limitations of hashing.

X. Recommended Resources
RFC 1321 - The MD5 Message-Digest Algorithm - http://www.faqs.org/rfcs/rfc1321.html

SHA1 Secure Hash Algorithm - Version 1.0 - http://www.w3.org/PICS/Dsig/SHA1_1_0.html

How to Break MD5 and Other Hash Functions -

“http://www.infosec.sdu.edu.cn/uploadfile/papers/How to Break MD5 and Other Hash Functions.pdf

SHA-1 Collision by Google and CWI Amsterdam

https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html
http://shattered.io/
Forensically Sterile Media - the media has been overwritten with a single known value, overwriting the
target media with a known value of 0x00 will result in a checksum64 result of all 0’s.

Cyclic Redundancy Check (CRC) - comes in 16- or 32-bit variations. It was developed to ensure data
integrity and is still used for that purpose. An example of this is sector checking, ensuring a sector's
data is good by running a CRC against the data held in the sector. CRCs are also used to validate data
sent by modem transmissions. As a validation hashing tool, it is old and considered quite weak;
because of this, its use in the digital forensics field, generally speaking, has been discontinued for file
verification.

Message Digest 5 (MD5) - an algorithm for computing a condensed representation of a dataset or a

data file. The condensed representation of fixed length and is known as a message digest or hash
value. The MD5 is a 128-bit message digest.

Secure Hash Algorithm (SHA) - newer than MD5, SHA an algorithm for computing a condensed
representation of a set of data or a file. It is a 160-bit message digest and very popular. SHA was
developed by NIST (National Institute of Standards and Technology); it is specified in the Secure Hash
Standard (SHS, FIPS 180).

Hash or Hash Value

Alphanumeric values, generated by hashing functions, used to substantiate the integrity of digital
evidence, and for inclusion or exclusion comparisons against known value sets.

Hashing Function
An established mathematical calculation that generates an alphanumeric value based on input data. This
alphanumeric value is referred to as the hash or hash value.

Hashing - hashing is a way to represent a piece of digital data as a unique alphanumeric value by
applying a mathematical algorithm to the data. It simply is a mathematical representation of a variable
length input whether it is a sector, individual bytes, text, single file, group of files, partition or entire hard
drive and generates a fixed length value. Two files with exactly the same bit patterns should hash to the
same value using the same hashing algorithm.

Positive Hashing - a list of hash values for known and sought out files can be compiled and used to
search for and identify files of interest to the investigator.

Negative Hashing - Hash analysis can be used to “eliminate" files from the examination, which can
greatly reduce the number of files to be examined by the investigator. These would be files that the
investigator can safely ignore.
 Memory Analysis
ÏA O S
The International Association of
Computer Investigative Specialists
Forensic Acquisition and Methodology

Contents
I. Synopsis....................................................................................................................................................... 1
II. Learning Objectives..................................................................................................................................... 1
III. Fundamentals of Memory............................................................................................................................ 2
IV. Random Access Memory............................................................................................................................. 3
V. Other Potential Sources of Memory............................................................................................................. 5
VI. Guidelines for Capturing RAM..................................................................................................................... 8
VII. Preparing the Capturing Device................................................................................................................... 9
VIII. Select Free Tools for Capturing RAM..........................................................................................................9
IX. Conditions That May Cause Failure in the RAM Capture..........................................................................10
X. Select Tools for Analyzing RAM Data........................................................................................................ 11
XI. Analyzing RAM........................................................................................................................................... 13
XII. Appendix 1 - Ram Capture Cheat Sheet.................................................................................................... 14
XIII. Appendix 2 - RAM Capture Practical......................................................................................................... 20
XIV. Appendix 3 - RAM Analysis Practical......................................................................................................... 22

I. Synopsis
Capturing and forensically analyzing RAM has been an exciting and important addition to the digital
forensics world by providing the access to 2GB+ of potentially relevant data to investigations. With a
growing interest in RAM analysis, many tools have been developed to capture this volatile memory.
Dumplt, RAM Capturer, and WinPmem, just to name a few, are all tools that can capture the live RAM of
a system. While there are many programs out there designed to capture and analyze RAM, it is still a new
process that has not been perfected. RAM is very delicate as it is volatile. Examiners should exercise care
when acquiring its data.

II. Learning Objectives

At the conclusion of this course the student should be able to:
• Understand RAM and other potential sources of memory
• Become familiar with potential evidentiary artifacts contained in RAM
 • Be familiar with the limitations and guidelines for RAM Capture
• Be familiar with a selection of tools for RAM capture
• Become familiar with the various methods and tools that can be used to process items from volatile
memory

III. Fundamentals of Memory

Current running processes can show the exact state a system was in before it was shut down or the power
removed. This can include any running malware or key loggers, peer-to-peer software running, or any
software which may be relevant to the investigation.

Active network connections aid in showing what a computer was doing across a network or the Internet at
the time it was seized. Any running peer-to-peer software will list open connections with other file sharers
on the swarm, assisting in showing probable cause for distribution of explicit images. Open network
connections from Internet browsers to websites can show browsing activity and connections.

URLs in RAM can show a user's browsing history. Not all Internet data is written to disk immediately and
many of the browsers have a privacy mode which can prevent certain pieces of information from being
written to disk. Several chat programs, including Facebook Messenger chat, do not write their data to disk,
preventing any recovery if the system is powered off. However, these artifacts may be found in RAM.

Files which are opened or used have had their data moved through memory. Everything typed into a
program goes through memory. By using automated tools, such as Internet Evidence Finder or carving
scripts in a forensic suite, photos and videos can be successfully recovered. Files can be recovered using
Volatility or Rekall. Recovering data held on the clipboard and pulling text stings from captured memory is
easy. The recovered text can be used to aid in building a word list for a brute force attack on passwords
or searching for a term which may have been used in a program.

Encryption is becoming more and more common in files, volumes, and on entire physical drives. There
are open source methods available (True Crypt and its variants) as well as paid products (PGP, BCA).
Modern operating systems come with easy to implement user encryption options, and in some cases (OS
X) is turned on by default. RAM may hold the passwords and encryption keys.

Microsoft Windows loads Registry hives and keys it uses into memory. Many changes are not made to
the Windows Registry hives right away; but rather they are cached to memory to be written to disk at a
later time. Analyzing RAM allows us to see what changes are made and if the changes are relevant to the
investigation. Recovered Event logs can give an overview of system activity for that session, particularly
with events which have not been written to disk yet.

Conducting an analysis of a computer’s RAM can reveal valuable information about the computer system,
its users as well as current and recent activity. Some of the information recovered from the active, volatile
memory will never be stored to disk. These items will only be able to be collected from the RAM, the page
file or hibernation. It is vital when conducting investigations into network intrusion and malware infected
systems that the active memory be analyzed. If the memory is not acquired and analyzed, it will be very
difficult if not impossible to adequately investigate these incidents. “Running processes and programs,
active network connections, registry hives, passwords, encryption keys and decrypted files are just a few
examples of the evidence that can be found in memory. Many web apps, like Gmail, or private/incognito
 browsing modes will only store data in memory.”1 Traditional dead box forensics where only data from the
computer’s primary hard drive is analyzed is no longer sufficient. In order to conduct a thorough and
complete analysis the volatile memory should also be examined. Figure 1 lists some examples of RAM
contents.

Data which may be present includes

• Running processes and programs, including malware

• Network connections
• Internet browser activity, including searches and visited sites
conducted in standard and InPrivate Browsing modes
• Passwords being used within the system
• Encryption keys for file ari*d disk encryption
• Active chats, such as Facebook Messenger, Kik Messenger and more
• Files (decrypted), Images and Videos
• Event log entries and Registry keys not yet saved to the disk

Figure 1

Dr. Timothy Vidas of Carnegie Mellon University asserted that volatile memory is perceived to be more
trusted because its data is stored in plaintext, while that same data, such as passwords, financial
transaction information, and encryption keys, could be encrypted or stored in an otherwise protected state
when stored on disk. Data could exist in memory as a result of malware or poorly coded applications. The
volatile memory contains running and deleted system processes as well as files and other data that have
not been saved to the disk drive.2

IV. Random Access Memory

RAM is an acronym for Random Access Memory. RAM is a specific type of flash memory that permits
random read and write access to any byte throughout the media. This NOR flash media is not restricted
like standard NAND flash which must reset data at the block level.

Classic RAM was SRAM (Static Random Access Memory) which had fast access speeds and maintained
the data as long as power was supplied. However, this type of memory was expensive. The most common
type of RAM is DRAM (Dynamic Random Access Memory). The capacitors used within DRAM bleed off
their charge and must be refreshed every few milliseconds in order to maintain their value. The type of
DRAM employed in most modern computers is known as SDRAM (Synchronous Dynamic Random Access

1https://www.magnetforensics.com/computer-forensics/acquiring-memory-with-magnet-ram-capture
2 The Acquisition and Analysis of Random Access Memory by Timothy Vidas PhD 2007,
https://pdfs.semanticscholar.org/409a/5f16169bf208d55ca994cdd8638624392faf.pdf. Page 3_______________
 Memory) which operates at a much higher rate and is synchronized with the microprocessors clock speed.
The latest iteration of DRAM is DDR4 (Double Data Rate) utilizing a high bandwidth creating a very fast
memory system with a capacity up to 512GB.

Microsoft Windows computer systems can be either 32-bit or 64-bit systems. The 32-bit systems built off
the Intel x86 chipset architecture have a limitation of 4GB of RAM. Windows operating systems and
hardware built using a 64-bit architecture can utilize up to 128GB of RAM. When computer hardware and
software are designed to utilize the 64-bit architecture the computing power is greatly increase.

Due to the very nature of RAM and its contents of running applications and files, the data contained in
RAM is continually changing. This creates problems for the forensic examiner. Since RAM is volatile
memory, the system cannot be shutdown prior to acquisition. (See Figure 2)
□

Random Access (Volatile) Memory

• Modern systems contain 2GB+ of RAM

• On running systems this is data which should not be left behind by
pulling the plug or leaving a system intact
• Contents of RAM are lost once power is removed from a system

Figure 2

Examiners must execute software which will be loading into the very RAM that they are seeking to acquire.
The key is to utilize software that has a minimal footprint allowing the examiner to capture and preserve
the maximum amount of existing RAM. The RAM spaces that are overwritten are not of active data rather
recent data no longer being used. The loss of this data is a necessary side effect of the acquisition process.
There is another issue. RAM is changing at the same time the acquisition is taking place. A RAM
acquisition will not contain a snapshot of a specific moment in time but rather a “time sliding-window where
at least some portion of RAM was currently being altered at the time of the capture”.3 This is commonly
called Memory Smear.

The very nature of flash memory makes hash verification of an image problematic. The constantly
changing nature of RAM makes it impossible. Even if consecutive RAM captures are created immediately
after each other, the two images will not be identical.

3 The Acquisition and Analysis of Random Access Memory by Timothy Vidas PhD 2007____________________
©2018IACIS Memory Analysis Page 4 of 25
 Pagefile.sys
Windows uses various files in addition to the physical RAM to function properly. When data is saved to
disk, as in a paging operation, there is additional data which can be obtained. This is information which
existed in memory, but was not permanently written to a file or folder as part of a program operation. Data
obtained from the pagefile.sys is generally current and relevant to your investigation.

Microsoft Windows 95 heralded some significant changes in computing. One of the significant changes to
the operating system was the introduction of the pagefile.sys. The pagefile.sys is a file on the hard disk
where pages of active data are temporarily stored and moved in and out of the physical RAM as they are
needed. Windows supports up to 16 separate page files. Within a typical 32-bit system the maximum size
of each page file is 4096 MB. On 64-bit and 32-bit systems utilizing the PAE (Physical Address Extension)
kernel, the maximum page file size is 16TB. The 64-bit Itanium architecture systems have an incredible
page size capacity of 32TB. The default size of the page file is 1.5 to 3 times the amount of physical RAM
in a system.

The pagefile.sys is used to store data which has been moved from RAM. To obtain a full “picture” or
snapshot of what activity is taking place in a system, the pagefile.sys should be examined as well. Some
tools allow both your physical memory image and the pagefile.sys to be examined together (ideal) while
other tools only allow you to examine the physical memory image. In this case the pagefile.sys can be
examined using a traditional forensic tool, bulk extractor, strings, or a program such as page_brute. While
the pagefile.sys normally sits on the default operating system volume (C:), it is possible to change the
location through Windows Advanced Settings or the Windows Registry.

Beginning with Windows 7, Microsoft provided the ability to encrypt the pagefile.sys. Seeing that the
pagefile.sys is an essential operating system file, Microsoft did not allow the user to manage the encryption
key. The operating system creates and deletes the page file encryption key when appropriate. Users can
enable page file encryption through an administrator command prompt. Within the administrator command
prompt enter the command: “fsutil behavior set encryptpagingfile 1”. This encryption can also be set
through a group or administrative policy. To check if page file encryption is enabled, use the command:
“fsutil behavior query encryptpagingfile”, as seen below in Figure 3. The value of 0 is unencrypted and 1
is encrypted.4

4 http://superuser.com/questions/610471/how-can-i-encrypt-the-swap-file-under-windows-7_________________
©2018IACIS Memory Analysis Page 5 of 25
 C:\Windous\systen32>fsutil behavior set Encrypt P agin yFlie 1
NOTE: Changes to th is s e t t in g require a reboot to take e f f e c t .
EncryptPagingFi le = 1

C:\W indov«\systen32>fsutil behavior query EncryptPayinyFile

EncryptFayinyFile ~ 1

C:\Windous\c yster>32 >

Figure 3

Hiberfil.sys
The hiberfil.sys (C:\Hiberfil.sys) file is a compressed image of a system’s RAM, which is written when the
system enters hibernation mode. This allows the computer to power all of the way down. It should be noted
that when a system goes into hibernation mode the network connections are closed, losing that data.
When the system powers up, the hiberfil.sys file is read back into RAM, making the recovery time from
hibernation very quick. The hibernation file consists of a standard header (PO_MEMORYJMAGE), a set
of kernel contexts and registers, and several arrays of,compressed data blocks. The file is compressed
using the Xpress algorithm along with Huffman and LZ encoding. The file header usually contains "hibr”,
“HIBR”, "wake”, or "WAKE”. After the system wakes from hibernation the header is zeroed out. The zero
header may prevent some forensic tools from being able to analyze the file.5

By examining the date and time modified timestamp, you can see when the system was last allowed to
hibernate, and therefore when the last memory image was written to disk. There is only one hiberfil.sys
file present on a system at a time. The previous file data is overwritten by the current contents of RAM
when the system enters hibernation again. The data within the hiberfil.sys file requires analysis by software
that can decompress the data into its raw data and interpret it. Mattieu Suiche’s Windows Memory Toolkit
utility, hibr2bin.exe, can be used to convert the hibernation file to a raw dump.

There may come a time when an examiner has access to a computer system but is unable to capture the
RAM. This could be from an incompatibility of RAM capture utilities or something configured within the
system which is preventing the RAM capture software from running. An alternative method could be to
force the system to hibernate causing the RAM to be preserved in the hyberfil.sys file. In order to force the
system to hibernate, hibernation must first be enabled. On Windows 8 and higher systems hibernation is
enabled by default. Within an administrator command prompt enter: “powercfg.exe /hibernate on”. To force
the system to hibernate enter the command: "shutdown /h”. In older operating systems, the system can be
hibernated through the Start menu (Start ^Hibernate or Start ^Shutdown ^Hibernate). If a computer has
a UEFI, and the user uses the menu command to shut the computer down, it is actually going into
hibernation. This is to allow the system to recover quickly and make it seem like it is powering on "instantly”.

5 The Art of Memory Forensics: Detecting Malware and Threats in Windows, Linux and MAC Memory_________
©2018IACIS Memory Analysis Page 6 of 25
 During some cases the examiner may encounter a laptop computer that has already hibernated, in these
cases, the most recent RAM data has already been saved to the hard disk for the examiner. The RAM’s
hibernated data is acquired as part of your standard forensic image. The data could also be acquired or
analyzed through a live forensic CD.5 The hiberfil.sys file can be analyzed using tools such as Volatility
or Mandiant Redline.

Swapfile.sys
Microsoft Windows 8 and newer use the same hiberfil.sys and pagefile.sys files from previous versions as
well as a new file, swapfile.sys. The swapfile.sys resides in the same directory as the pagefile.sys and
hiberfil.sys (See Figure 4).

D rr* V *« lo ca l Or.lt (C ) □
G
e- -4 - t 5 ., > th is PC > local Disk (C) > T O

> >♦" Q uid: access

l_l Name mod'll
Users
> c k OneDuve Windows
boolm gr
> * T J w PC
BOOTNXI
> Network hibetfilsys
pagefäe.sys
sw apfie sys

17 items

Figure 4 - Directory listing of root directory with swapfile.sys, pagefile.sys, hiberfil.sys

The swap file is used by the operating system to make some paging operations for suspended Metro-style
or Modern Windows apps.6 Windows operating system can write the entire application data set to the
swap file and free up that portion of memory. When the application resumes, the data is loaded back into
memory. The data from the swap file can be read as part of your normal forensic process. The swapfile.sys
should be at most about 256 MB in size. It is managed along with the pagefile.sys, so disabling the paging
file on a drive will also disable the swap file.

Memory.dmp
It is possible to configure Windows to save a dump file when it experiences the Blue Screen of Death
(BSOD). When this occurs, the system will dump the memory into a file named "memory.dmp", located in
the C:\Windows directory. The configuration of the memory.dmp function is in the “System Properties-
Advanced [Startup and Recovery] - Settings". The settings will determine whether there is a dump and

6 http://www.thewindowsclub.com/hiberfil-pagefile-swapfile-sys-windows________________________________
©2018IACIS Memory Analysis Page 7 of 25
 what type. The memory dump is a kernel memory dump that contains some status information. The
memory file is saved in a proprietary format. The data is designed to aid in debugging the system crash.
The dump does not contain the whole physical memory.7

VI. Guidelines for Capturing RAM

RAM may be captured remotely or by using an application launched from a portable device. The following
guidelines address the use of an application on a portable device.

Guidelines set by the Association of Chief Police Officers (ACPO) recommend the following steps:8

• Perform a risk assessment of the situation: Is it evidentially required and safe to perform the capture?
• If so, install the capture device (i.e., USB flash drive, USB external hard drive) in the suspect machine
• Run the collection script
• When completed, stop the USB device prior to removing it
• Remove the device
• Verify the capture on your forensic computer, not the suspect machine
• Immediately follow with standard power off procedure

The Scientific Working Group on Digital Evidence (SWGDE) defined limitations to be considered during
the capturing of RAM. The investigator must be aware that the volatile data capture will cause changes to
a system. These changes may include the following:

• Loading the application overwrites memory contents

o The larger the executable and dlls, the more is overwritten
o The application will show up in the process list
• The USB device driver may be loaded by the operating system
• The USB device used will be written to the registry’s USB keys
• The application will be written in the registry as a "Last opened" app
• The action may be written to the Prefetch
• If the suspect machine runs an anti-virus program, it may create logs regarding the RAM capture

Possible changes in RAM may cause system instability. The investigator must understand how these
concerns may apply to their particular situation. The investigator must take measures to keep the system
accessible for the duration of the acquisition and maintain detailed documentation of all actions.9

7 http://computer.forensikblog.de/en/2006/03/dmp-file-structure.html
8 ACPO Good Practice Guide for Digital Evidence (2012),
https://www.cps.gov.uk/legal/assets/uploads/files/ACPO_guidelines_computer_evidencen].pdf
9 SWGDE Capture of Live Systems 2014,
https://www.swgde.org/documents/Current%20Documents/SWGDE%20Capture%20of%20Live%20Systems
©2018IACIS Memory Analysis Page 8 of 25
VII. Preparing the Capturing Device
The USB device used should be prepared prior to use. Use an NTFS formatted device that is large enough
to hold the size RAM you may encounter. Current systems typically range from 2GB to 16GB of RAM,
although 64-bit Windows will support from 128GB (Windows 10 Home) to 2TB (Windows 10 Pro,
Enterprise, and Education) of RAM.

Prior to the capture, record the serial number of the capturing device by using command line: “vol <drive
letter>”. Document the serial number in the report or field notes.

Choose your application (executable) for the capture and save it to the USB device. The application should
have a small footprint and should be portable so that it will run from the capturing device. Do not install an
application on the suspect system.

After capture, verify the output on the forensic machine. Generate a HASH of the image prior to analysis
to provide verification of captured data and for use in chain of custody records. As in all digital forensics,
document every step made in the process as proper documentation is essential for collecting evidence
that can withstand legal scrutiny.

VIII. Select Free Tools for Capturing RAM

There are many software vendors that have developed software to capture volatile memory from computer
systems. These software utilities will not be successful on every computer system you encounter in the
field. The examiner should collect and validate multiple software utilities that will collect the volatile
memory. They should include software that has the ability to collect both the RAM and other sources of
memory discussed above should the need arise.

Command Line Tools:

Com ae’s Dump It

• Current Release 3.0
• Works on both 32 and 64 bit systems
• Easy to use, only one command to type
• Output to a RAW or DMP (default) file
• http://www.comae.io/labs.html

FireEye Memoryze
• Current Release 3.0
• Can acquire physical memory and perform advanced analysis of live memory while PC is running
• https://www.fireeye.com/services/freeware/memoryze.html

FireEye Redline
• Current Release v 1.14
• Redline Collectors capture RAM
• Redline can analyze the capture
• https://www.fireeye.com/services/freeware/redline.html
 Winpmem
• Current Release 2.0
• Command line driven, small footprint
• Creates an. aff4 file, built on standard ZIP format
• Can compress the memory stream
• winpmem also captures the kernel and driver binaries
• Can use rekall to analyze this image
• https://github.com/google/rekall/releases

GUI Tools:

AccessData FTK Im ager Lite

• Current Release 3.1.1
• Uses a GUI from the thumb drive, no installation required
• Saves a .mem file
• Can save AD1 file (limited examination tool choice)
• Allows the capturing of the page file
• http://accessdata.eom/product-download/digital-forensics/ftk-imager-lite-version-3.1.1

Belkasoft RAM Capturer

• Current Release 1.0

• 32 bit and 64 bit versions available
• Kernel-mode operation
• Bypasses active anti-bugging and anti-dumping protection
• http://belkasoft.com/ram-capturer

M agnet RAM Capture

• Current Release 1.1.1
• Saves as a RAW image
• https://www.magnetforensics.com/computer-forensics/acquiring-memory-with-magnet-ram-capture

osTriage

• Current Release 2.0

• Obtain from ICAC Cops
• Easy to use
• Live response tool - RAM capture is one function of the tool
• https://www.icaccops.com/users/page_materials.aspx

IX. Conditions That May Cause Failure in the RAM Capture

Generally, RAM capture is not difficult, however, there are conditions that cause a failure in the capture.
Some tools require loading a kernel-level driver, giving access to raw memory. If there is no driver, the
capture will fail. Several things can prevent the driver from being loaded, with the most common being not
running the tool from an Administrator account or from an Administrator-level command prompt. Anti-virus
 software can prevent a successful capture. Malware may access memory and anti-malware solutions may
block driver installation. Therefore, anti-virus and anti-malware programs may need to be disabled. After
checking these things, try a different acquisition tool if the capture fails. Differences in a tool’s
implementation can sometimes make a difference on a peculiar system.10

Windows 10 and Server 2016 added the option to enable virtualization-based security (VBS). RAM
Capture tools typically load a device driver into the kernel to read memory. However, the use on a system
with virtual secure mode enabled results in a system crash. One way to avoid the BSOD (Blue Screen of
Death) is to first determine whether virtual secure mode is enabled by checking whether the “Secure
System” process is running. This can be done by opening Task Manager and checking under the
Processes tab. If it is running, a software that can capture RAM from a system with virtual secure mode
must be used. Two free tools identified as successful in trials are Belkasoft RAM Capturer and Dumplt
v3.0.20170620.11

Appendix One includes a Cheat Sheet which includes command lines and directions to use the above
tools.

Appendix Two includes the Practical for the RAM Capture portion of the training.

X. Select Tools for Analyzing RAM Data

If you consider the value and necessity of analyzing RAM it is no surprise that there are a variety of free
and for profit software available. Many of our standard forensic utilities have the ability to process the
acquired volatile data. Of course you must consider what tool you are going to analyze the data with before
you begin. The examiner will need to ensure that the extraction image files are compatible with the analysis
software. Some capture utilities encapsulate the RAM data in a proprietary format file. This will limit the
analysis tools available to you. Just as you should assemble a collection of capture software you should
also find multiple software applications for analyzing the data. There is no magic forensic software bullet.

Bulk Extractor
Bulk Extractor is a computer forensics tool that scans a disk image, a file, or a directory of files and extracts
useful information without parsing the file system or file system structures. The results can be easily
inspected, parsed, or processed with automated tools. Bulk Extractor also creates listings with the
frequency of items that it finds, as features are more common tend to be more important. The program
can be used for law enforcement, defense, intelligence, and cyber-investigation applications.

Bulk Extractor is distinguished from other forensic tools by its speed and thoroughness. Because it ignores
file system structure, Bulk Extractor can process different parts of the disk in parallel. In practice, the
program splits the disk up into 16MB pages and processes one page on each available core. This means
that 24-core machines process a disk roughly 24 times faster than a 1-core machine. Bulk Extractor is

10 https://digital-forensics.sans.Org/blog/2010/11/08/digital-forensics-howto-memory-analysis-mandiant-
memoryze
11 https://dfstream.blogspot.com/2017/08/memory-acquisition-and-virtual-secure.html______________________
also thorough. That is because Bulk Extractor automatically detects, decompresses, and recursively re­
processes compressed data that is compressed with a variety of algorithms. Testing has shown that there
is a significant amount of compressed data in the unallocated regions of file systems that is missed by
most forensic tools that are commonly in use today.

Another advantage of ignoring file systems is that Bulk Extractor can be used to process any digital media.
The program has been used to process plater hard drives, SSDs, optical media, camera cards, cell phones,
network packet dumps, and other kinds of digital information.

While it can be run from the command line in Windows, the GUI is a better choice. If running Bulk Extractor
from the command line to send (pipe) the results to another text based tool, Linux or OS X are a more
efficient choice.

Internet Evidence Finder or Axiom

Internet Evidence Finder and Axiom from Magnet Forensics are versatile, paid, forensic utilities. Internet
Evidence Finder has the ability to analyze the data from the forensic image files of computer hard drive,
files and folders, Volume Shadow Copies, Pagefile.sys, mobile devices, as well as a computer’s extracted
RAM. Internet Evidence Finder has the ability to parse out Internet history, email, chat communication,
Microsoft Windows event log data, Prefetch, link file data, common file types, and more. By processing
RAM captures as an “image” file, Internet Evidence Finder uses its built in technology to locate possible
evidence within the recovered memory data.

Volatility
Volatility is an open source multi-platform framework written in the Python language. Volatility can analyze
raw data image files, Windows crash memory dumps, hyberfil.sys and more. Volatility is a command line
utility with over 260 commands, listed within Volatility as plugins, for running scripts on various operating
systems and data files. Although a very powerful utility, Volatility requires commands to be run one at a
time. First the system profile is determined. Afterwards a batch file may be created to sequence
commands to be run one after the other.

Rekall Forensics
Rekall is an open source, command line, multi-platform framework designed for incident response and
memory analysis. Rekall is a collection of memory forensic acquisition and analysis tools. Rekall can work
on the same platform it is analyzing so it can also be used for Live Analysis and incident response cases
by doing a quick triage of the system. Rekall is a spinoff from Volatility and has the capabilities to work on
Windows, OS X and Linux. Contrary to Volatility, Rekall does not need the system profiles; therefore it
needs an internet access or local repositories. Rekall uses an interactive ¡python shell. The user sends
commands to run plugins to analyse different aspects of the system.

Forensic Disk Decryptor

Elcomsoft's Forensic Disk Decryptor is a paid utility that can be used to identify and extract cryptographic
keys from RAM captures, hibernation and page files. Forensic Disk Decryptor has the ability to extract the
cryptographic key for BitLocker, Truecrypt, and PGP. The software can utilize the recovered keys to mount
or decrypt the encrypted container and gain access to all the decrypted files and folders within the
container.
XI. Analyzing RAM
Collected RAM can be analysed to recover a multitude of different types of data. The RAM can be analysed
to show the most recent user activity. The examination can show what applications the user is running, as
well as what those application are doing. During a search warrant a Suspect was found to be actively
downloading child exploitation materials through a P2P application. The capturing and analysis of the
computer’s RAM was shows what activity was being conducted. The RAM can show the Internet browser’s
activity as well as what email or social media the user is communicating through. In some cases the chat
communication is not cached to the disk and only available within the RAM. The RAM can be examined to
find keywords, user passwords or cryptographic keys to encrypted containers or media. More advanced
analysis can be performed to identify rogue application, malware, and rootkits. The running processes and
TCP/IP connections can identify how a hacker has connected to the system. Some RAM analysis can be
performed with standard forensic training and tools. More advanced analysis techniques require specific
training and a deeper understanding of computer systems to be effective.

Appendix Three includes the Practical for the RAM Analysis portion of the training.
XII. Appendix 1 - Ram Capture Cheat Sheet

What you type will be bold and italics. Anything in [brackets] will be specific to your
situation. The list of tools is not presented as a complete list, but only as a sample of
available free tools. Additionally, only the capturing of RAM is discussed. Many of the
tools have other functions as well.

Preparing your thumb drive prior to capture (to be

completed on your forensic computer):
• Choose a thumb drive large enough to contain the memory you
plan to capture.
• Format your thumb drive as NTFS.
• Rename USB Drive to make it identifiable.
• Document volume serial number of your drive
o Open the command window as administrator: Click on
"start" symbol on bottom left, type cmd in run window,
right click on command prompt and choose run as
administrator (See Figure 1)
o Obtain the volume serial number for your report. In
command prompt, type: (See Figure 2)
M Jin d o w s \ S y s te m 3 2 > v o 1 e
Appendix 1: Figure 2
■
Appendix 1 Figure 1
C:\Windows\System32>vol [your drive letter]:

* This returns the following information: (See Figure 3)

• Volume in drive [your drive letter] is [this will be the label of the thumb drive]
• Volume Serial Number is [this will be the volume serial number]
l:\ U in d o u s \ S y s t e n 3 2 > u o l e :
Uoluroe in d r i v e H i s R ( lh _ n t fs
Uolum e S e r i a l Number i s (1006-0663
! :\ W in d o u s \ S y s te n 3 2 >_________________________

Appendix 1: Figure 3

• Copy your software to your thumb drive.

• Eject your thumb drive properly.

On the Scene (to be completed on the suspect computer:

• Insert your thumb drive into the suspect computer - Autoplay File Explorer may open depending on
setting. If not, open use Windows + E to open File Explorer.
• Note the drive letter given to your thumb drive.
• In a Windows 10 or Server 2016 system, open the Task Manager and check to see if the “Secure
System” process if running. If it is running, use software to capture RAM that will not cause a BSOD,
such as Dumplt v3.0.20170620.
• Capture RAM - instructions below
To Use Command Line Software:
• Open the command prompt as an administrator.
• Change to directory of your software: (See *NOTE below the following instructions for easy shortcut)
o Type [Your drive letter]: and hit enter - this will bring you to the correct directory (Figure 4)
□ _________________________________________________________
a A d f r . r u to r. C:\WindCxri\Syitom3Acrtid.«i.t ^
h c r o s a f t Windo ws [ V e r s i o n 6 . 1 . 7 6 0 1 ]
o p y r i g h t ( c ) 20 0 9 M i c r o s o f t C o r p o r a t i o n . A ll rig h ts reserved.

I :\w in d o w s \s y s tc * 3 ? > £ :

Appendix 1 Figure 4

o If your software is at the root of the thumb drive, you are where you need to be. If your
software is not at the root, type cd and the path of your program:
■ prom pted [path]
See Figure 5 for an example where the path on E was the “dumpit” folder in the
“tools” directory

£ : \> c d to o lc N d u n p it

Appendix 1 Figure 5
*NOTE: Shortcut - After you open the command prompt and switch to the correct drive (this is
important to do first), open the directory of your software in Explorer, click and drag the software into the
command prompt. See Figure 6. Click on the command prompt window. Flit “enter”. This should change
to the directory and program. Be careful, if you do this before switching to the usb drive path, the
software may run and save the output to the C: drive.
□

rsi Administrator; C:\windows\System32\cmd.exe

« C o m .., > D u m ... ► ^ j [ ScorchDumpit fi

Organize » 33 Open » Bum §p - a 0
VT Favorites downloads
^i^esktep File folder
V dowPI^c Dumpft.exe
- Recent Places Mem ory Acquisition Tool
Comae Technologies FZE_________
Libraries Hibr2Bin.exe
a Cases Windows hibernation file decom...
Comae Technologies FZE
»' Documents
IICENSF >tf______________________

Appendix 1 Figure 6

Software Directions
Several of the software programs can be run from a GUI or by clicking on the .exe file (Belkasoft RAM
Capturer, Dumpit, FTK Imager Lite, Magnet RAM Capture, and osTriage). Command line tools use the
specified commands listed below. You must complete some steps on the forensic computer for Memoryze
and Redline prior to use in the field:
Belkasoft R A M Capturer

Execute Belkasoft RamCapture64.exe or RamCapture.exe (depending on your suspect machine) as

an administrator by right clicking on the exe file and choosing “run as administrator”
You will get a box where you will designate the location for the capture to be saved (See Figure 7)
□
♦ Belkasoft l iv e R A M Capture» X

¿elect o u ^ x jt folder o a ru

1'
lo a d e r device dnve»...
Pbys*:a! Memory Pape Sue - <096
Total Phys»cal Memory See * 6673 F©

Capture'

Appendix 1 Figure 7

Dumplt:

To obtain RAM Capture

You can run the program from the exe
• You can execute Dumplt by executing the program file as an administrator (right click on Dumplt.exe
and choose “run as administrator”).
• At the command prompt, type y (See Figure 8)
□

Appendix 1 Figure 8

You can run the program from the command line (See Figure 9)
• prompt:\[path of program]>Dumplt.exe /o u tp u t [path\filenam e.dm p]
a ___________________________________
Œ:\Tuols\Dunp]t>dunpit.exe /output E:\capture\dumpit\dumpit.drop
Appendix 1 Figure 9

To uncompress the hiberfil.sys file:

Windows 7 (NT 6.1) x64 hibernation file (See Figure 10)
• prompt:\[path of program]> hibr2bin.exe /platform x64 /m a jo r 6 /m in o r 1 /in p u t hiberfil.sys
/o u tp u t [path\filenam e.bin]
 E:\Tools\DunpIt>hibr2bin /p la tfo rn x64 /najoi* 6 /ninor 1 /input h ib e r f il.s y s /ou
tput E:\capturc\dunpit\unconprcsscd_)iibci'fi l . bin

Appendix 1 Figure 10

Windows 10 (NT 10.0) x86 hibernation file

• prompt:\[path of program]> hibr2bin.exe/platformx86lmajor10/minor0/inputhiberfil.sys
/output[path\filename.bin]
FTK Im ager Lite:

• Run FTK lmager.exe as administrator.

• The program will open. Click on the RAM icon (or File>Capture Memory), Figure 11
□

• Input the destination path and whether to save the pagefile.sys (See Figure 12)

Appendix 1 Figure 12
 • When completed, there is a box that will indicate the capture finished

Magnet RAM Capture:

You can run the program from the exe
• Run MagnetRAMCapture.exe as administrator.
• You will get the box seen in Figure 13 that allows you to select the location for capture

Appendix 1 Figure 13
You can run the program from the command line
• Run from the command line as an administrator:
o prompt:\[path of program]>MagnetRAMCapture.exe
• This will save the capture to a .raw file in the current folder. You can specify a path using the
following:
o prompt:\[path of program]>MagnetRAMCapture.exe /go [path\filenam e.raw]
• *Note - Magnet RAM Capture can be.run in the background with no interface or progress displayed
- requires the /silent /go parameters
o prompt:\[path of program ^ MagnetRAMCapture.exe /sile n t /go [path\filenam e.raw]

Memoryze
You must install Memoryze on your thumb drive prior to use in field:

msiexec /a MemoryzeSetup.msi /qb TARGETDIR=portable_drive_and_folder

(msiexec la MemoryzeSetup.msi /qb TARGETDIR=[your drive letter]:\)

The following is the command to capture RAM (See Figure 14)

• prompt:\[path of program]>MemoryDD.bat -output [dire cto ry path - do n o t include filename]
e :S T o o ls \ M e n io i'ÿ z e \ x 6 4 > n e m o r ÿ d d -b a t - o u t p u t E :\ C a p tn r e \ M e r o o r y z e
Appendix 1 Figure 14

• ’ Note - if not specified, the default output location will be in the program’s directory. The program will
make a directory structure of [Audits\pc name\date time] and will write the file there in either the
default directory or in the directory you specify.

osTriage (requires .NET v 4.0.30319 or higher):

• Stop all anti-virus, anti-malware and firewalls prior to inserting thumb drive into pc.
• Execute osTriage2.exe as administrator. The first screen gives the option to collect live data.
 The next screen gives the option to collect the RAM as seen in Figure 15
osTnage is loading...

D o y o u w o nt to c a p tu re RAM?
Note: When « {X u m j RAM. the rx erfsee w3 appear fro :en Ee patter* whie RAM «5
captured

RAN'. capaoty 8 GB (8A90.323.QSA bytes)

Desmaibor. dnve A3GBfree (¿5.10A.857.OSS bytes)

Yes 1 Ho
RAM wD be saved to.

E \Tools''ßUro5Tnage\SearchResu!t5\20l702l5151250 RAM capture for

CEACCJ 321-PCCEACC_1321-PC-20170215151250.RAM r w

Getting Irabaltze data ter plugin ‘Capture RAM'

Appendix 1 Figure 15

Redline:

Install the program on the forensic computer. Prepare for the capture:
• Open Redline, choose either standard or comprehensive collector, and only select "Acquire Memory
Image" - uncheck all other options.
o Click on "Edit your script" and only select "Acquire Memory Image",
o Select location (your thumb drive) to save the script and hit "ok".
At the scene - on suspect computer, use the command line to run the "RunRedllneAudlt.bat". (See Figure
16) This will save the capture to the program's directory in the path "Sessions\AnalysisSesslon1\Audits\PC
name\date time".
• prompt:\[path of program]>RunRedlineAudit.bat
□ ___________
V T o o ls \ R e d lin e > R u n R e d lin e A u d i t .b a t
Appendix 1 Figure 16

Winpmem:

To capture RAM, use the following command prompt (See Figure 17)
• prompt:\[path of program]>winpmem_2.0.1.exe - output [path\filename.aff4]
□ ___________________________________________________________________________________________

:\Tools\winpmen>winppiem_2.0 .1 .e x e — output e :\captui'e\winpm em \winpnen.af f 4

Appendix 1 Figure 17

After the capture:

• Eject your thumb drive properly.
• Unless you are planning to image the computer at the scene, hard kill the computer - Pull Plug from
back of PC or remove battery then plug from Laptop.
• Hash the RAM capture on Forensic computer - never on the suspect computer.
READ and follow the directions closely. Read each step prior to executing it.

What you type is displayed below in text that is bold and in italics. Anything in [brackets] will be specific to
your situation.

Preparing your thumb drive prior to capture (to be completed on your forensic
computer):
Choose a thumb drive large enough to contain the memory you plan to capture,
o Assure that your thumb drive is formatted NTFS
o Right click your thumb drive and choose “Format.
If your drive is correctly formatted, hit “close”. If not, format the drive using the NTFS option (and
complete the following step while you format).
(Optional for exercise) Give the thumb drive a volume label that makes it identifiable.
o Right click on the thumb drive and choose “Rename”.
Document the volume serial number of your drive:
Open the command window as administrator as seen in Figure 1:
o In Windows 10, right click on the “start” symbol and choose “run command prompt as
administrator” OR for Windows 7, click on "start" symbol on bottom left, type cmd in run
window, right click on command prompt and choose “run as administrator”•

• Obtain the volume serial number for your report. See Figure 2. In command prompt, type:
C:\Windows\System32>vo/ [your drive letter]:
□

::\Uindous\Sÿstem32>vol e:
Appendix 2 Figure 2
 • This returns the following information as seen in Figure 3:
□ ________________________________
!:\ llin d o u s \ S y s te n 3 2 > v o l e :
Uolume in d r iv e E i s R A M _ntfs
U olun e S e r i a l Number i s AA06-0663
;:M )in d o w s\S y ste n 3 2 >

Appendix 2 Figure 3

Volume in drive [your drive letter] is [this will be the label of the thumb drive]
Volume Serial Number is [this will be the volume serial number]
• Write the Volume Serial Number in the text box:
• Copy Dumplt to your thumb drive.
• Eject your thumb drive properly.

On the Scene (to be completed on the suspect computer):

• Insert your thumb drive into the suspect computer - Autoplay File Explorer may open depending on
setting. If not, open use Windows + E to open File Explorer.
• Go to the directory containing Dumplt.exe
• Run Dumplt as an administrator
o Right click on Dumplt.exe and choose “run as administrator”
• At the command prompt, type y
• By default, the capture will be saved as a .dmp file to the directory where Dumplt is located.

After the capture:

• Eject your thumb drive properly (use “safely remove hardware and eject media” in the notification
area as seen below). You may need to click on the triangle to see the eject media icon.
□•

Appendix 2 Figure 4

• Insert your thumb drive into your forensic computer.

• Hash the RAM capture using your forensic computer - never on the suspect computer.
o Open HASHER.exe
o Either navigate to your RAM dump, or drag the dump into the hasher window,
o After hashing completes, save the results by going to File>Save results>to text.
Exercise 4 Preliminary Internet Evidence Finder RAM Analysis
Open the RAM folder on your desktop. Open the \RAM Analysis\IEF\ folder and the “IEFCase.ief6” file.
(Desktop\RAM\RAM Analysls\IEF\IEFCase.lef6)

This is a pre-processed Internet Evidence Finder Report Viewer package of the Suspect Tommy Russell’s
computer RAM capture (PhysicalMemory). The IEF Report Viewer package has partially limited
functionality since your computers do not have an associated forensic license attached.
• Select the Cloud Services URLs: Note the Remote storage locations that potentially contain
evidence. ^ "Wtu>£-^ ~T\-g> c? ^-«s> ■k'^ f)r\
• What Email address(s) are associated with the user?
■ Ov v 0 <lo
• What book did the user search for?
• Other Internet Searches of Interest:
• Conduct a targeted Search (excluding Media) for “Heroin”. What other hits of interest did you find?

• Identify listings indicating any applications of Interest?•

• What road is identified from the Google Maps visit on 07/07/2017 at 14:47:33 Hours
 Exercise 4 Preliminary Internet Evidence Finder RAM Analysis - Answer Key

Open the RAM folder on your desktop. Open the \RAM Analysis\IEF\ folder and the “IEFCase.ief6” file.
(Desktop\RAM\RAM Analysis\IEF\IEFCase.lef6)

This is a pre-processed Internet Evidence Finder Report Viewer package of the Suspect Tommy Russell’s
computer RAM capture (PhysicalMemory). The IEF Report Viewer package has partially limited
functionality since your computers do not have an associated forensic license attached.
• Select the Cloud Services URLs: Note the Remote storage locations that potentially contain
evidence. OneDrive, Google Drive. Dropbox__________________________________________
• What Email address(s) are associated with the user?
[email protected], [email protected]____________________________________
• What book did the user search for? Cross Dressing Fun by Zubin Medora___________________
• Other Internet Searches of Interest:

brown sugar as a cutting agent for tar heroin What is bitcoin

Laundry detergent as a cutting agent Fake id’s

Costco video surveillance videos Bitcoin core wallet

Bitcoin atms with no id reguired TOR

Bitcoin atms near me Ares

How to wipe computer emule

Changing your identity ccleaner

Heroin cutting agents pybitmessage

how to buy and sell drugs on dark web amory bitcoin

HOw to become a heroin selling kingpen veracrypt

Counter surveillance techniques How to securely delete a file

charging heroin dealers as killers Ares older version

Dark Web Wiping free space ccleaner

Does a drug dealers culpability increase after using fentenyl as cutting agent and user dies

are drug dealers responsible for overdose of a drug user

Agora Market Bitcoin

Agora Market ‘dark net Dark Net

dark web Darknet markets

heroin____________________________________ Remington

Silk Road

• Conduct a targeted Search (excluding Media) for “Heroin”. What other hits of interest did you find?

Z:\Huge heroin bust rocks quiet Montavilla and Mill Park streets _ East PDX News.htm__________________

D:\Heroin cutting agents.odt

C:/Users/Tommy/Downloads/eMule/lncoming/Opium%20-%20Poppy%20cultivation,%20morphine%20
and%20heroin%20manufacture.pdf

http://eastpdxnews.com/general-news-features/huge-heroin-bust-rocks-quiet-montavilla-and-mill-park-streets/
http://www.addictionsearch.com/treatment_articles/article/fentanyl-laced-heroin-or-cocaine-is-a-deadly-
combo_140.html

http://killtheheroinepidemicnationwide.org/2016/09/24/are-drug-dealers-responsible-heroin-overdose-death

https://www.legalmatch.com/law-library/article/heroin-state-and-federal-penalties.htm

• Identify listings indicating any applications of Interest?

Veracrypt emule

TOR Ares

Ccleaner Armory•

• What road is identified from the Google Maps visit on 07/07/2017 at 14:47:33 Hours
_____ Huntington Road, Bend, Oregon_________________________________________
G
Validation, Acquisition and
The International Association of
Environmental Control
Computer Investigative Specialists
Media Validation and Sterilization

CO NTENTS

I. Synopsis
II. Learning Objectives
III. Evidence
IV. Forensic Examination Environment
V. Validation
VI. Sterile Media
VII. Forensic Backup Process
VIII. Write Blocking Strategies
IX. Solid State Storage Devices
X. Deviations from the Laboratory Baseline
XI. Conclusions and Summary

I. Synopsis
The most critical aspect of the computer forensic examination process is having complete control over the
entire forensic environment. Given the volatile nature of electronic data even the most minor error or
momentary lapse in protocol can create serious issues:

• Data might be entirely and forever lost.

• Data might be partially lost or otherwise altered to the point where the integrity of the case is
compromised.

• The integrity or competence of any personnel who are part of the forensic environment, or who are
involved at any point during the computer forensic examination process, could be called into
question. This in turn could create issues for future cases and raise doubts about past cases for
the agency at large, and personally for those involved.

• The integrity or competence of the computer forensic examiner, specifically, could be attacked by
casting them in the light of one with specialized training and expertise, and as such he should
“know better.”

• If a jury’s or trier of fact’s overall confidence in the integrity of technical aspects of a case are
reduced or compromised, that negative perception or negative bias could creep into other, non­
technical aspects of the case and cast doubt on the strength of the entire investigation/prosecution.

This paper addresses how the computer forensic examiner can significantly reduce— and even completely
eliminate— the possibility for such issues arising by developing and using proper validation processes,
using sterile media, and using sound and validated forensic backup practices.
 We will also explore various special circumstances where deviations from baseline best practices are
required, what the implications of such deviations are, and how deviations should be addressed in
reporting.
II. Learning Objectives
At the conclusion of this course students should be able to:

1. Understand the term “evidence.”

2. Understand "validation” as a general concept, and how validation is used during every phase of the
computer forensic examination process.

3. Understand what sterile media is and how one creates, validates, and uses sterile media.

4. Understand the concept of a “forensic backup” and be able to distinguish between a forensic
backup and a non-forensic backup.

5. Plan for and create forensic backups.

6. Explain how data writes to electronic media are made in normal circumstances.

7. Explain how different write-blocking technologies work to prevent data writes to electronic media.

8. Be able to develop testing methodologies to ensure that one’s write-blocking strategy is valid.

9. Be able to differentiate between “forensic evidence files” and a “forensic copy.”

10. Understand the potential evidentiary value of RAM captured from a running computer.

11. Plan for capturing RAM on a running computer in the field during the triage/seizure process, and
know how to document same.

12. Understand the times when deviations from standard best practices might be required, and how
such deviations might be approached and documented.

III. Evidence
Before discussing the core topics of this paper directly a brief look at the notion of “evidence” is in order. At
first glance it might seem that such a discussion is better placed in other courses in the BCFE training
program— and this issue is discussed elsewhere in the program. Here we look at the issue just to provide
some context for what follows.

Even cursory discussion of the concept of “evidence” can quickly devolve into a complex and confusing
dialog. Worse, the myriad of rules, regulations, and laws that pertain to evidentiary matters at different
levels of jurisprudence, and in different jurisdictions, combine to make meaningful dialog even more
inaccessible, even to those seasoned legal minds with years of experience dealing with “evidence."

To keep the discussion as straightforward as possible we’ll look at “evidence” generally, and then drill down
to a limited view that is more practical to the computer forensic examiner.

In a general sense, “evidence” can be thought of as anything that tends to prove or disprove some
assertion as being true. And regardless of the type of evidence, be it testimonial or physical, and
regardless of whether it’s direct/corroborative or indirect/circumstantial, there are strict rules that govern the
admissibility of evidence in legal proceedings.

With that preface, bear in mind:

1. Nothing is actually evidence until a trier of fact admits whatever items are in consideration into the
record, at a legal proceeding, as being accepted by the court as meeting relevant standards.
 2. Even after something is considered evidence, that something, whatever it might be (i.e. a piece of
physical matter, a report, data of some sort, eyewitness testimony, etc.), has no value if it cannot
withstand a rigorous challenge by a competent adversary.

In more practical terms:

• The best way to prevent “evidence” from becoming evidence is to prevent it from being admitted
by the trier of fact or recognized on the record. Now it doesn’t exist in the eyes of the court.

• Failing complete elimination of something as evidence, the next best course of action is to
undermine the credibility of the evidence— if possible undermining it to the point that doubt is cast
not just on the veracity of that particular evidence item, but on the entire matter at hand.

• Failing a successful attack on the evidence itself, the next best course of action is indirectly attack
the evidence by directly attacking everything around the evidence— the computer forensic
examiner and the computer forensic examination process.

As an example, consider a child pornography investigation during which the computer forensic examiner
recovers hundreds of still image and video files with obvious child pornography content from the hard disk
drive of a computer seized pursuant to a search warrant.

(As an aside, our example scenario could be any type of criminal investigation where a computer forensic
examination results in recovery of files with obviously incriminating content. Using the child pornography
example here is intentional: for our illustrative example we want to be sure students understand that even
the most obviously incriminating, damning evidence can be rendered meaningless.)

In our example, can the defendant realistically challenge the content of the files proper? Probably not
considering that the material in question is purely graphic and it’s typically not going to be subject to much
speculation or interpretation: a judge and jury see the still images and video footage, the repugnant nature
of the content of the still images and video footage is obvious, the child-victims are obviously children and
there is no possible mistake as to age, and that’s that. So, what's the defense to do?

As discussed earlier, one strategy is to prevent the “evidence” from becoming evidence in the first place:

• Attack the underlying probable cause that led to the search warrant. If the warrant is invalidated,
then everything that follows will probably be at risk. Think of this as a “fruit of the poisonous tree”
attack, if you will.

• Attack the integrity of the evidence (how items were seized and otherwise handled at seizure and
during transportation, chain of custody, etc.). If doubt can be cast on proper evidence handling
procedures then everything that follows will probably be at risk. Again, think of this as a form of the
“fruit of the poisonous tree" attack...not rooted in strict legal theory, but very similar.

• Even if the attack isn’t successful on the surface, if it exposes even minor flaws in protocol or
process it will open the door to later attacks (i.e. “if they didn’t do that 'by the book' then what else
did they do ‘by the seat of their pants’”).

At this point, the actual contraband content isn't at issue because it would not even be raised. Presumably
this level of attack is in the pre-trial stage, and what was revealed during the computer forensic examination
process has not even been discussed in court. And if the defense is successful at this level that content
may never be revealed, so it won’t matter how damning that content is or how critical it is to the case.

For a reminder of how devastating an attack on a warrant can be, if successful, consider a ruling by federal
magistrate Peggy Leen in US v. Phua (Case 2:14-cr-00249-APG-PAL Document 406 Filed 01/30/15):
 "...a search warrant is never validated by what its execution recovers. See Maryland v. Garrison, 480
U.S. 79, 85 (1987).”

Bottom line: if the proper rules and procedures are not followed at all times from a legal standpoint and
from a practical standpoint, the "evidence” will ever see the inside of a courtroom and never be used to
establish proof of anything.

Moving on, presuming the overarching attack on the integrity of the evidence fails, the next level of
challenge will be more focused and attack the computer forensic examiner and the computer forensic
examination process. Examination procedures, examination tools (hardware and software), and examiner
competence can all be attacked in any number of ways, and by successfully creating doubt in the minds of
the judge or jury in any of these areas (or any part of any of these areas) case could simply fall apart
entirely, or enough doubt might be generated to merit an acquittal.

The computer forensic examiner can easily defeat (or prevent) attacks at this level by keeping these points
in mind:

• In a general sense, proper evidence handling procedures do not end in the field when “evidence” is
seized— proper evidence handling extends to field triage; transportation or other movement or
handling; temporary resting locations such as temporary holding areas, the computer forensics
laboratory, etc.; and final resting locations such as the evidence locker or archival facility.

• Proper forensic methodologies, processes, and procedures must be used at all times by the
forensic examiner, regardless of the setting.

• No forensic methodology, process, or procedure is considered "proper" until it has been personally
tested and validated by the examiner, and independently reproduced by a competently skilled
person who has a sufficient level of knowledge to test and validate the process or procedure.

In summary, any criminal investigation and subsequent prosecution has many moving parts, any of which
can break down and cause the entire case fail. By better understanding the notion of evidence from a
wider view the computer forensic examiner will have a heightened awareness of how even the most minor
flaw in processes and procedures can open the door to attacks— direct and indirect— on the validity of the
evidence.

Computer forensics examiners can sometimes be lulled into a false sense of security, especially in cases
where the computer forensic examination results in recovery of data obviously damning to the defendant.
There will be many instances when this kind of successful examination results in a guilty plea, but that isn’t
always going to be the case, and so the computer forensic examiner must be prepared at all times for the
attacks that will invariably come.

IV. Forensic Examination Environment

Throughout the balance of this paper the various sections will use a number of terms and explore a number
of concepts, and definitions for those terms and concepts will be provided within the text proper. There is,
however, a larger concept that merits more targeted treatment, namely establishing and maintaining a
fo re nsica lly sound exam ination environm ent.

Forensically Sound Examination Environment

A working environment that is completely under the control of the computer forensic examiner at all
times, and within which nothing happens unless the computer forensic examiner permits or causes it
to happen; and when the computer forensic examiner does permit or cause something to happen he
can state with a reasonable degree of certainty what the expected outcome or result will be.

That seems to be a mouthful, but in fact it’s a simple and straightforward concept: the computer forensic
examiner must be in complete control of everything, at all times, and in all places.
 The typical perception is that the computer forensic examiner's environment is the computer forensics
laboratory where an examination proper takes place; and the typical perception of a computer forensic
examination is using some forensic software to recover data.

In reality, the notion of “environment” is much more than the singular location of the computer forensics
laboratory; and the notion of the forensic “examination” is much more than operating a piece of software.
The computer forensic examiner needs to understand the extensions to the common perceptions because
there are times, as we will note elsewhere in this paper, that one must deviate from standard “in the lab”
practices.

So, the “environment” extends to any location where any device capable of recording or storing electronic
data might be located at any particular time, such as a victim’s location, a crime scene, a search warrant
location, transportation vehicles, the temporary evidence locker, the evidence archive/storage room, etc..

Similarly, the “examination” extends to the entire workflow used by the computer forensic examiner, and
includes any process that might be applied during the course of the flow of work. For example, examining
original evidence media directly, making a forensic backup of original evidence media, executing specific
processes against a forensic backup, treatment and specific analysis of recovered data, etc..

Now we can move forward.

V. Validation
In the realm of computer forensics “validation” means the process of verifying that something works as it is
expected to work. At every stage of his work the computer forensic examiner must take care to personally
test and validate. If one doesn’t, then how can one have any confidence in the results one produces?
Moreover, personally testing and validating is the most effective way to preclude many avenues of attack
later in the investigative and prosecutorial processes.

Expanding on our discussion of evidence, at the lowest level there are three (3) aspects involved in a
computer forensic examination: the examiner, the hardware, and the software. Attacks against an
examination focus on all of these.

Attacking the examiner may occur in the form of questioning evidence handling or questioning the
examiner’s technical knowledge and expertise. These attacks, as implied above, can be defeated entirely
or at least significantly blunted by always properly documenting one’s actions when handling electronic
media and related storage devices, and by following best practices for examining electronic media. And
certainly, every computer forensic examiner must maintain his skills by participating in formal and informal
update training or continuing education, and by maintaining existing credentials and earning additional
ones.

Beyond the obvious, it is not uncommon for a computer forensic examiner to have to provide a detailed
explanation of a particular process or circumstance, and unless one personally knows and verifies how
something works, it will be impossible to provide an authoritative explanation. For example, say that during
the course of an examination one recovers deleted data that is of critical value to the case. Later one might
be expected to provide a detailed explanation as to what happens when one deletes data under a particular
operating system, how (and why) that data can be available for recovery later, and how the recovery
process used by the examiner works to accomplish the recovery. This would be a difficult task for the
person with no underlying technical knowledge of file system dynamics.

Examiners should be especially mindful when using more specialized processes during a forensic
examination. An example might be creating a virtual machine (VM) from a suspect hard drive and booting
the VM to make screen captures that will illustrate a critical finding (or perhaps booting the VM live in
court). In this type of scenario there are more technical areas that can be attacked. And the examiner who
doesn't have a good command of underlying technical concepts, and so just follows a “go by" provided by
some other examiner, could be in for a difficult time when testifying.
Attacking hardware or software used during a forensic examination can be done directly or in combination
with an attack on the examiner. Typically, a direct attack on the product itself will attempt to highlight a
product’s known flaws or weaknesses. This serves to cast doubt on the reliability of the product, implying
that results derived from its use cannot be trusted. A more indirect attack will tie-in the examiner, painting
them as one who is not properly trained to use the hardware or software, or as one who does not
understand how the product works, and therefore cannot make reasonable conclusions about the forensic
integrity of the hardware or the findings obtained using the software.

In either case these attacks boil down to attempts to create doubt in the eyes of the trier of fact by
questioning the veracity of the examiner’s work or the tools used to help them do that work. To buttress
these attacks the “opposition” might offer another forensic examiner who attempted to duplicate the
examiner’s findings, but who obtained different results.

Countering an attack against the hardware or software, or the examiner’s ability to use the hardware or
software and understand their functionality can be done by documenting one’s training with the products,
reviewing any release notes or other documents that might provide details about the products’ known
limitations or flaws, maintaining good examination notes, and most importantly by testing and personally
validating the products’ capabilities and functionality.

Now, let's drill down specifically to testing and validation: Examiners must never take someone’s word that
any forensic methodology, process, or procedure; or that any hardware or software will function as it says it
does and produce reliable results. Such anecdotal information is not validation! Even if one uses a
product based on a trusted colleague’s recommendation, and the product appears to do what it says it will,
one must still personally test and validate that product against a known entity or dataset, independent of
the item or data being examined.

To successfully validate hardware or software does not mean that an examiner is required to know the
programming code for the firmware that drives the hardware, nor does one need to know the programming
code for the software product. But, the examiner must at least be conversant with the product's
functionality and he should have tested and confirmed (i.e. validated) that the product does what it is
supposed to do.

A shortcoming in a particular function of a piece of hardware or some forensic software is not necessarily
catastrophic. Most software has numerous features, or functions, and chances are good that one of them
contains a bug. It is common for software vendors to release updates that include new features and bug
fixes. In many cases the examiner will not use every function or procedure that the software offers, but he
should validate those that he does use. This allows the examiner to confidently counter any challenges
later. Similarly, virtually all hardware components rely on embedded software (called "firmware”) to control
the various electronics in that piece of hardware. And just as with application software, firmware can
contain bugs, and manufacturers often release updates to address such bugs.

If an examiner does not know how to validate, or simply chooses not to validate a piece of hardware or
software, then the following questions surface:

• If the examiner knows how to validate a hardware or software product but chooses not to, then how
can it be confirmed that the product is functioning properly and producing correct results?

• If the examiner does not know how to validate a particular procedure, or if the examiner does not
know how to validate a particular product, then what is that examiner’s level of technical skill and
competence in the first place?

Answers to either of these questions while an examiner is on the witness stand could have quite an impact
upon the judge or jury. Inadequate answers could be embarrassing to the examiner and his peers while
casting doubt on his ability to conduct a proper forensic examination. If this occurs in a courtroom setting it
could have a devastating effect on the case at hand an on an examiner’s career.
 Remember that a forensic examination may involve determining a person’s guilt or innocence. Falling
short by not locating relevant evidence or making an inaccurate conclusion about what is or is not found
may allow a guilty person to go free or an innocent person to face unnecessary investigation.

Worse, locating relevant evidence and drawing all the right conclusions...only to have everything excluded
because of sloppy examination procedures or being unable to address simple questions about procedures,
evidence handling, hardware or software validation, etc. can affect the entire forensic community.

A critical point about testing and validation is that during all phases of the testing and validation processes
the examiner must work with a known dataset. That is, one must know now to prepare media so that it
contains the data necessary to allow for validation of the particular skill or process, or hardware or software
functionality that is being tested or validated.

For example, consider that one is testing a forensic software package’s capability to recover deleted data.
In this case the first step is to prepare test media that contains a wide variety of data, that is stored
contiguously and that is fragmented, and that is extant and in deleted states. The test media must then be
thoroughly examined to note exact locations of the data. So, when the recovery processes of the forensic
software are tested one has a valid baseline against which to compare the functional results produced by
the software.

A final word about attacks and testing and validation: examiners must always be mindful of the “hidden
adversary.” Remember, in a criminal investigation and prosecution the examiner’s work is “out front,” as it
were, in the hands of the defense as a part of the discovery process (and the examiner’s work might
actually be the main component of the entire case). There is nothing to stop the defense from having any
number of experts review the examiner's work behind the scenes, without exposing that this is being done.
So, just because a defense expert never conducted an actual examination on the data, one should always
assume that a competent adversary will be reviewing one’s reports, drawing conclusions about the
examiner and his processes and procedures, and helping defense counsel craft lines of attack.

Along these same lines, perhaps the most dangerous “hidden adversary” an examiner has is him/herself
That is, when defense counsel meets with a forensic examiner to review evidence or to ask questions
about a report, or when an examiner is testifying in various pre-trial proceedings, he is defending his work.
If there is any hint that the examiner has some underlying technical weakness or is otherwise unsure of
something, or perhaps cannot thoroughly and professionally address some technical question, that will
exploited later, in open court...and probably in a much more vigorous way.

VI. Sterile Media

Use of sterile media whenever possible during a computer forensic procedure is critical. Unless all pre­
existing data on the media is completely eliminated there will exist the potential for co-mingling of data, and
an examination could be compromised.

Moreover, when dealing with unknown media— for example, media supplied by defense counsel to obtain
copies of data for discovery purposes— it is critical that the media be forensically sterile before any data is
moved to it. The examiner has no idea where the media came from, and even if it is still in what appears to
be factory packaging, there is no way to verify that it is completely free of extraneous data. Having such
data discovered on a drive during a legal proceeding would surely bode ill for a case.

Finally, whenever one retires or recycles/repurposes media previously used in the computer forensics
laboratory in any capacity it should be sterilized to prevent contraband or other restricted/sensitive data
from being released.

So what is “sterile media"? Sterile media is defined as magnetic media on which every byte has been
overwritten in order to eliminate any data that previously existed on the media. This process is also called
"wiping" or "sterilizing."

For computer forensic examination purposes the preferred method for media sterilization is to overwrite
with the known character 0x00 because it allows for quick verification by executing a 64-bit checksum
(checksum64) against the media: if the sterilization is successful the resultant value produced by the
checksum64 process will be 0000-0000-0000-0000.

Because of the nature of the checksum64 algorithm, regardless of the size of the media, if all bytes are
overwritten with 0x00 the resultant value will always be 0000-0000-0000-0000. This is not the case with
hashing algorithms such as an MD5 hash or SHA1 hash, and so use of those algorithms for validating
sterile media should be avoided.

(As an aside, while it is beyond the scope of this paper, students should note that a “checksum" and a
“hash" are different processes, and the terms should not be used interchangeably.)

The above notwithstanding, one could certainly sterile media by overwriting with a known character other
than 0x00, or even with a random hexadecimal character. But doing so would unnecessarily complicate
the verification process. And one could certainly verify sterile media using an algorithm other than a
checksum64. But again, doing so would unnecessarily complicate the verification process.

This discussion begs the question: Why go through the trouble of sterilizing media, validating the
sterilization, and then preparing the media to accept files (partitioning and formatting)? That seems like a
lot of work. Wouldn’t it just be simpler to delete all of the files on the media and then perform a format
procedure?

Note that normal file deletion and format procedures do not sterilize media:

1. Routine file deletion leaves all of the data intact on the media.

2. In most cases a format procedure will:

• Not modify the partition table.

• Create a valid Boot Record on the disk.

• Create FATs or NTFS metafiles.

• Leave pre-existing data intact.

To complicate matters there are additional considerations that apply to formatting media. For example,
under Windows Vista and above, performing a “full format” using Windows’ Disk Administration will
overwrite the data area of the media with 0x00. A so called “quick format,” however, will not overwrite any
data. And executing the FORMAT command from a command line provides access to a number of other
options that can affect the formatting process.

In summary:

• Always use sterile media when restoring suspect data to destination media (in other words,
whenever you want the destination media to contain a forensic copy of the original media).

• Always sterilize media received from another person before copying data to it and returning it to
that person (regardless of whether the media is used or brand new).•

• Never allow media previously used in a computer forensic environment in any capacity to leave the
secure setting without being sterilized.

• Create sterile media by using a utility to overwrite all bytes on the media with the 0x00 character.

• Validate that media completely overwritten with the 0x00 character is sterile by running a
checksum-64 against the media and verifying that the resultant value is 0000-0000-0000-0000.
 To illustrate the points so far we’ll take time in the classroom session to learn more about the short comings
of media formatting vis-à-vis media sterilization; and we’ll learn how to develop a validation strategy, and
well validate forensic software and use it to create and validate sterile media.

Now we’re ready to move on to the forensic backup process proper.

VII. Forensic Backup Process
One of the foremost principles of computer forensics is that, absent the most exigent circumstances, one
should never conduct a forensic examination using the original evidence media (i.e. conduct a “live” forensic
examination of original evidence media). Rather, one should always work with a forensic backup (image).

Certainly there will those rare instances when working with original media will be unavoidable. For example,
the case at hand may be so time sensitive that one is compelled to begin working immediately; or one may
simply be working with a device or media from which it is difficult, or even impossible, to generate forensic
evidence files or to obtain a forensic copy.

A second critical principle of computer forensics is that electronic evidence, regardless of its form or format
is, well...evidence. It is no different than any other type of evidence: it requires the same level of expertise
and care in handling, the same safeguards against alteration and tampering, the same thorough and
complete documentation and tracking, and the same steps for long-term preservation that apply to any other
type of evidence.

So, then, it would be fair to say that one of the most important phases of the computer forensic examination
process is the forensic backup phase: this is when the generation of forensic evidence files/forensic copying
process occurs; and it is during these processes that the danger of compromising the original evidence
media is highest.

So, what is a “forensic backup”? And what about these terms “forensic copy” and “forensic evidence files”?

The term “forensic backup" refers to the process of capturing all data from a piece of source media in a
forensically sound fashion, meaning that the original data on the source media is unaltered.

And “all data” means: The entirety of the contents of the device, to include all file system structures, all
logical files, all slack data regardless of the type of slack, all unallocated space (and thereby any deleted
data that has not been overwritten), and any unused space (i.e. space that exists outside of the boundaries
of any partitions on the media).

It is critical to note that a forensic backup is NOT the same as a standard or non-forensic backup such as
might be performed by consumer-level backup software:

AREA CAPTURED TYPE OF BACKUP

Forensic Non-Forensic
Allocated Files Yes Yes
RAM Slack Yes No
File Slack Yes No
Erased Files Yes No
Unallocated Space Yes No
Non-Partitioned Yes No
HPA Yes No

Table 1

There are two (2) forms of forensic backups: A forensic copy and generation of forensic evidence files.

1. A “forensic copy” is a copy of the original media made directly to target media of the same or a
larger capacity, with any remaining space on the target media completely overwritten with 0x00.
 2. “Forensic evidence files,” in contrast, refers to the generation of one or more files that contain within
them a “bit-for-bit” copy of the data found on the source media, often referred to as a "forensic
image”. The data in these files are generally analyzed either by using software which reads directly
from them (such as Encase or FTK or X-Ways Forensics) or through restoration to another piece of
media (i.e. meaning that the examiner restores the forensic evidence files to sterile target media
thereby creating what is akin to a forensic copy.

While the concept of a “forensic copy" is fairly straightforward and easy to understand, the notion of
“forensic evidence files” is a bit more complex.

There are two major types of forensic evidence files: so-called "flat files” such as the Linux dd file with file
extension of .001, .002, etc., and third-party files (such as the Encase Evidence File with an extension of
E01, E02, etc.). There are other file formats, but these are probably the most popular.

A dd file is a bit-for-bit copy of the original media that can be broken up into individual files of whatever size
the examiner determines, though a single dd file is just as effective. The dd format has no compression and
takes up the exact amount of space as the original media.

ddi dd2 dd3 dd4

In contrast to a “flat” file, E01 files contain additional information within the files, such as a header. The
header can include information such as: evidence name, evidence number, notes, dates and times of
acquisition, operating systems under which the acquisition took place and additional information about the
forensic program used.

In an E01 file the header is found at the beginning of the first evidence file. The header and then each
block of data (a block is 64 sectors of data by default which can be changed by the user) is verified by a
process called a Cyclical Redundancy Check (CRC). The CRC is a 32-bit value calculated to insure data
has not changed within that block during the copying process. At the end of the evidence file an MD5 is
calculated for all the data blocks.

The Header and individual CRC’s are not included in the MD5 calculation. The MD5 value is then included
in the forensic evidence file.

Case Data Block EdiKSII Data Block ESISBl Data MD5 (only data is
Information Block included in
calculation)_____

At this point it is important to discuss terminology. So far we have been using the term “forensic backup” as
sort of a major heading, with “forensic copy” and “forensic evidence files" as types of “forensic backups.”

Over the years a number of other terms have been used to describe a forensic backup and the process of
generating a forensic backup. These include “mirror image", "exact copy,” “bit-stream image,” “disk
duplicating,” “disk cloning,” and “mirroring,” just to name a few of the more popular terms and descriptors.

IACIS holds that these terms are not the best. Each is flawed or otherwise inaccurate to a degree that
renders it unsuitable for use in the computer forensic examination environment, and none properly describe
what the computer forensic examiner is really doing.

Consider:

Mirror Image Is the data really reversed like a mirror reflection; read right to left?
 Exact Copy Is each and every byte on the source and destinations drives exactly the same?
Seldom will the forensic examiner have at their disposal a destination hard drive
whose make and model is identical to the source hard drive, and which contains
the exact number of sectors as in the original.

Bit-stream Image The term “bit-stream image” is getting closer to what is really going on and
applicable for a “disk-to-disk” forensic copy procedure, but may not be true If the
software used to create the forensic backup injects proprietary code into the
output when data is saved to forensic evidence files.

Thus, when dealing with output that goes to forensic evidence files it is important
to understand that the data will probably not be entirely a 'bit for bit' match of the
source media. This circumstance may occur when data specific to the backup
program itself, the program overhead described for an E01 file, above, for
example, is included in the files. Some forensic backup software includes code
to associate the output with the software or to identify the sequence of the output
files. It may also occur when compression is used to lessen the number of files
generated during the backup process.

With the above in mind the terms “Forensic Copy” , “ Forensic Image” and “Forensic Evidence Files”
probably better describe what we are doing.

Vlll.Write Blocking Strategies

The computer forensic examination begins long before one actually starts handling the evidence in the
laboratory. In fact, keeping with the themes we discussed above in the sections on evidence and the
forensic examination environment, the examination process really starts the instant that one opens the
investigation, and it continues through the entirety of the evidence collection phase, physical examination
processes, and right on to the long-term storage of the original evidence following all legal proceedings.

In short, we must always be thinking about properly handling, protecting, documenting, and preserving the
original evidence. And as we noted above, the point at which the evidence is most at risk is in the
laboratory, when it is being physically handled and during the forensic backup process.

To protect the original evidence media one must take active steps to prevent any changes to that media.
There are three ways to accomplish this:

• Through physical hardware alterations that are designed to block any attempts to write to the media.

• By using software programs that are designed to prevent or intercept writes to the media.

• Through firmware solutions wherein the firmware that controls a hardware device enables the write­
blocking protection (these are often mistakenly called “hardware-based” write blockers).

Sometimes there can be confusion about what the differences are between hardware write-blocking and
firmware-based write blocking solutions. We’ll try to clear-up these points of confusion. But before we can
examine each of the available protection methods we need to understand how writes are made to electronic
media in the first place (remember...if one is going to properly test and validate anything one needs to know
how that thing works to begin with).

Disk Access Models

Before we can discuss write blocking methodologies we need to understand how writes to electronic media
are made in the first place.

In the days before Microsoft Windows was even available, IBM PC DOS and Microsoft DOS (MS DOS) were
the two dominant computer operating systems. These operating systems were virtually the same, so for our
discussion we’ll simply consider “DOS” to be either of the brands.
While DOS did not offer much in the way of graphics it was vastly more simple and predictable when
compared to the Windows family of operating systems. Under DOS most writes to the media were made by
calls to BIOS interrupt 13 or 13x (extended interrupt 13). An “interrupt” is merely a call to a programming
routine in the BIOS (for those with a programming background, think of an interrupt as a “call” to a
“subroutine” or “function").

So, then, most applications that wished to write data to the media made a call to the operating system
which, in turn, called BIOS int13 or int13x to make the write. Int13 and int13x contained code that included
ATA commands to manipulate the hard disk drive controller.

Figure 1 on the next page shows this process. In the example, the interaction between the application that
wants disk access and the actual access to the media is controlled by the operating system. That is, the
operating system acts as a “traffic cop” of sorts for media access.

In addition to the traditional model of disk access, under DOS applications could be written in such a way
that they bypassed the operating system and called BIOS int13 and int13x directly. This method of disk
access is known as “direct disk access.”

Figure 2, above, illustrates direct disk access. Programs that used the direct disk access model were
generally considered risky because they directly accessed the media without any regard to other processes
that might need disk access or other activity that the operating system was controlling. A properly written
program that used the direct disk access model would include routines that surrendered resources to the
operating system so that there would be no conflicts or data loss.

An example of a program that uses the direct disk access method is Norton Disk Editor, a program that
more experienced computer forensic examiners have used. In fact, most hex editor programs and other
similar programs that were used for maintenance and repair purposes used this method of disk access.
Under the Windows family of operating systems the model for disk access changed: applications were no
longer permitted to communicate with the BIOS, nor were they permitted to interface directly with the
hardware. Of course, there were mechanisms built into Windows 9.x to permit one to boot into real mode
DOS so that older programs could run; and some programs could even run from within the Windows 9.x
GUI, but with risks of instability and data loss.

In any case, the “official” Microsoft requirement for a program to meet the “For Windows” label was that all
disk access and hardware access must be through the Windows API.

An “API” stands for “Application Programmer’s Interface." It is simply a collection of programming routines
and functions that it is built into the Windows operating system, and which permits programmers to have
program perform common tasks with consistency. This permits stability and reliability.

So, then, consider a program that opens a window in the middle of the display and populates that window
with some text. The program would not have to write from scratch the code to create the window and insert
the text, but rather the programmer would simply make a call to the proper function in the Windows API,
feeding that function the parameters for the window. Now, every program that creates windows on the
screen does so in the same manner, using the same code supplied by Windows itself. Figure 3, below,
shows this model.

Application

o
<J
U Windows API g
a
L J*L
Windows OS
—j
W indows w
Driver interface |
J L
Windows IDE drivers
“T
c
<
n ATA Commands t
tc
a 5

IDE Hard drive

igure 3 - Disk Access Under Windows

Evolution of Write Blockers Part I - Hardware Write Blocking

The very first method of protecting media was via hardware. That is, alterations to a piece of hardware or
the capabilities of the hardware itself prevented writes to the media proper. And some of these technologies
are still with us today.

Some examples include the following:

• The write-protect shutter on diskettes (or the write-protect notch on older 8” and 5.25” floppy
diskettes).

• The write-protect tabs found on some flash memory cards and USB drives.

• CD-R and DVD-R media and drives.

Hardware write-blocking is the most simple and straightforward to understand: under normal operating
conditions there just isn’t any way a properly functioning diskette drive is going to write to a diskette with the
write protect shutter open; nor is there any way that under normal operating conditions that a CD-R or
DVD-R drive is going to write to optical media.

But, while hardware write-blocking is simple to understand and quite effective, it is not applicable in most of
the cases that computer forensic examiners encounter: there is typically no built-in way to write-protect a
hard disk drive, the type of media most often seen in the computer forensics laboratory.

Even in the earliest days of personal computing and computer forensics the need for a write-blocking
strategy beyond that provided by the hardware itself was recognized, and so software write-blocking was
developed.

Evolution of Write Blockers Part II - Software Write Blocking

Software write-blocking began under DOS. And because DOS was so predictable and well-known and
documented, the development process was straightforward, and the strategy was effective.

Simply, changes could be made to key operating system files to prevent the operating system itself from
making writes to media. And because of the way the operating made writes, using inti 3 and inti 3x,
programs were written to intercept these calls by the operating system to prevent applications from making
media writes.

So, then, one could attach the original evidence media to the examination computer, boot to the DOS
operating system with a specially crafted boot disk that would prevent DOS from making any writes to the
evidence media. And one could load a program into memory that would intercept calls to int13 and int13x to
permit one to run a program to generate forensic backup files from or to make a forensic backup of the
media.

In fact, given that DOS was so easy to control in terms of how writes were made to electronic media, many
specialty programs were developed to back up the data from attached media in a forensically sound
manner. But, as always, if one did not take care to be sure that no direct-disk access programs were
running there was a risk that writes could be made.

But, as software development moved forward and some DOS programs began to use the direct-disk access
model to make disk writes, failures occurred. Figures 4 and 5, illustrate how a software write-blocking
programs work, and how they can fail in the case of direct disk access programs.
 Application Application

DOS Commands

Operating System

ATA Commands

IDE Hard drive IDE Hard drive

Figure 4 - INT13/INT13x Intercept Figure 5 - Software Write Blocker Failure

Eventually, software write-blocking programs caught-up with the changes in the way programs were
accessing the media, and once again software write-blocking was an effective strategy. But once again the
shortcomings of this method became apparent with the introduction of Windows.

Unlike the DOS environment, the Windows environment is far more difficult to control. As noted above,
there are no direct calls to the BIOS or to the hardware under Windows, so software write-blockers were
ineffective at protecting evidence media against alterations. Moreover, Windows itself was designed to write
to any newly detected media (Windows will always attempt to put a Recycle Bin folder onto any newly
detected media).

So, with software write blockers found to be forensically unsound in the Windows environment one was
forced to either return to real-mode DOS (which was problematic as hard disk drive sizes increased and
speed became an issue) to create forensic backups of evidence media, or another solution had to be found.

Today there are some software-based write blocking programs available, and some are considered quite
reliable (for example, those that block writes to USB ports); but for the most part software-based solutions
are considered somewhat risky, at best.

Examples of software-based write-blockers include:

• Alterations to key DOS files to prevent DOS from making writes to the media.

• Linux flavors that mount devices as read-only by default (Paladin, for example).
 • Special programs that intercept calls to BIOS int13 and int13x.

• Newer programs that intercept calls from the Windows API to perform disk writes.

• Alterations to Windows to prevent writes to the media (i.e. the USB read-only registry "hack" in
Windows operating systems)

• Changes to the BIOS settings to use BIOS routines to write protect USB ports or make the floppy
disk drive read-only.

Evolution of Write- Blockers Part III - Firmware Write Blockers

As the name implies, firmware write-blockers do not depend on the operating system, the computer BIOS,
or programs that are loaded from the operating system to prevent writes to the media. Rather, the
protection mechanism is the firmware that is embedded in a physical piece of hardware.

The write blocking devices produced by Guidance Software, Digital Intelligence, LogiCube, and many others
are examples of such devices. Other examples include bridge-boards produced by ACARD, Granite Digital,
and other manufacturers.

Firmware write-blocking is effective in any environment, and so the potential for failure is far less than for
many software write blockers. For this reason these are the most popular types of write-blocking devices.

Hardware write-blockers work by acting as a physical barrier between the computer/imaging device and the
attached media. No matter how the write attempt is made, whether through BIOS interrupts, through the
BIOS directly, directly to the drive via ATA commands, or through the Windows API, the write-blocking
device electronics to not permit the call to the drive controller to perform the write operation to succeed.

While firmware-based write-blockers are generally a better solution than software-based write-blockers,
there are still some limitations to consider. First, some older devices do not have large drive support, a
major obstacle as drive sizes continue to grow. Next, the operating system must support the device. For
example, under Windows 9.x or Millennium there might be severe issues (and, frankly, one should not be
using either of these versions of Windows, nor any edition of Windows XP, in a production environment
much less in a computer forensic environment). And for IDE devices, one must be mindful of jumper
requirements: typically, drives attached to most firmware-based write-blocking devices must be set as
MASTER devices or they might not be properly recognized.

Finally, there are some speed and cabling issues to consider. Regardless of what the theoretical speed of
USB or IEEE technology, users will always see slower transfer speeds due to operating system overhead or
just plain bad handling of USB or IEEE data transfers by the operating system.

To get around the connectivity and speed issues, one particular type of firmware-based solution works well:
the self-contained drive duplication device. These devices work like any other firmware-based device, but
the evidence and work drives are not connected to a computer, rather they both connect to the device.

The LogiCube MD5 Forensic and Talon devices, the Digital Intelligence Hard Copy device, and any number
of other devices are examples of self-contained duplication mechanisms.

These devices often permit a user to choose between making a forensic copy (remember from our previous
discussion that a "forensic backup” is device-to-device copy) or generating forensic evidence files of the
evidence hard disk drive.

Some even include advanced features such as creating sterile media, auditing, a choice of forensic
evidence file type (i.e. E01 files or dd files), and the ability to segment forensic evidence files.
 A final word: firmware-based write blocking devices and self-contained backup devices are not static. That
is, as hard disk drive technology changes so too must the devices that are used to protect those devices.
To this end, manufacturers that produce firmware-based write blocking devices are always updating the
device firmware to take into account changes in hard disk drive technology.

A good example of this is when manufacturers push out firmware updates to address advances in hard disk
drive controller technology. It is the responsibility of the computer forensic examiner to ensure that the
devices he/she uses always have the latest firmware from the manufacturer: there is no greater nightmare
for the computer forensic examiner than having a defense expert examine one’s work, find that there were
device protection and preservation issues, and isolate those to the computer forensic examiner not using the
manufacturer's recommended firmware updates. Such a disclosure will speak volumes in court about the
computer forensic examiner’s competence.

IX. Solid State Storage Devices

Solid state storage devices are found in many of the devices you will receive as evidence. This type of
storage presents a new set of challenges.
a. Wear leveling is a function that ensures the storage blocks on the media are used at the same
rate. This is designed to prevent premature failure of the storage blocks.
b. Garbage collection is a function that, in most cases, causes the blocks holding unallocated data to
be automatically reprogrammed, which results in the actual deletion of the stored data.
These functions are held within firmware embedded in the device controller. As a result, an examiner has
no control of when these events may happen. When these events take place changes are made to the
evidence. As forensic examiners, we must be aware of these functions and be able to explain why the
evidence may have changed since the time it was seized.

IX. Deviations from the Laboratory Baseline

To this point our discussions of validation, use of sterile media, and the forensic backup process have been
in the context of the computer forensics laboratory setting where we have the luxury of time, a complete
software toolset, and adequate forensic computer hardware. Unfortunately, there are times when even in
the comfort of the computer forensics laboratory one will need to deviate from standard best practices; and
there will almost certainly be times in one’s career when one will need to use various practices in the field
that seem to fly in the face of the baseline procedures.

Overall, it is understood that there will be times, under a variety of circumstances, when one must deviate
from baseline procedures. And it is understood that doing so will not compromise the computer forensic
examination, the findings, or reflect negatively on the computer forensic examiner so long as these best
practices are observed:

a. The facts and circumstances of the deviation are fully documented and reported.

b. The processes used are reasonable and justified under the circumstances at hand.

c. The processes used are as unobtrusive as is reasonable under the circumstances at hand.

d. The benefit of using non-standard processes outweighs the risks of damage to or destruction of
data.

Here are just a few examples of processes that deviate from the standard laboratory baseline:

• Creating a backup of data in the field, from a running computer.

• Capturing RAM in the field, from a running computer.

• Manually inspecting a portable device and changing settings on the device.

 • Creating a ‘'limited” or “logical” backup of data from original evidence media.

• Directly examining electronic media, in place.

To be sure, some of the above are performed so routinely that they might be considered a standard
practices in the computer forensic community. For example, capturing RAM from a running computer in the
field is widely viewed as something that should be done routinely: one can recover various messing
fragments, images, running processes (current and historical), passwords, etc. from RAM. So to not capture
RAM for later analysis is to risk losing a significant amount of potentially relevant data (consider that most
computer systems will have 4GB - 32GB of RAM...that’s a lot of potentially useful data!).

Similarly, performing on-site triage of computers to limit unnecessary seizure (for example, narrowing down
involved systems in a child pornography investigation) is widely considered to be reasonable and relatively
unobtrusive. There was a time when one might take 2, 3, 4, or even more computers from a search warrant
scene, but considering that many computers will have upwards of 500GB of storage (and in many cases
more), eliminating systems that don’t need to be seized for further analysis will help later in the laboratory
setting.

And certainly, triaging systems for use of encryption or potentially destructive countermeasures, and taking
necessary steps to preserve data when encryption or destructive countermeasures are indicated, is quite
reasonable regardless of how intrusive the preservation process might be. The alternative is to get no data
at all.

As for cellular telephones and other portable devices, surely there is ample justification for putting a device
in “airplane mode" to isolate the device from networks and outside access. And certainly there is ample
justification for directly examining the device under certain circumstances where the public safety might be
at risk.

In the end, knowing the standards for the baseline practices, and knowing the implications of deviating from
the baseline (and documenting and reporting them) is the key. The computer forensic examiner should
never attempt to hide or “gloss over” a deviation from standard practice. Simply note the change and the
reasoning behind it!

While we could deep dive further into this area, for now we’ll simply acknowledge that deviations from
standard practice are not unreasonable. During the class presentation for this topic we'll explore further
during some hands-on, instructor led activities that will enable further exploration.

X. Conclusion and Summary

So at the end, the question is after all we’ve covered in this paper, why do we care? After all, if we can
establish that a particular work process or methodology works as advertised and is forensically sound, what
else is there to say?

Well, as we’ve seen, there is no one, single perfect solution to every situation. What solution an examiner
chooses will vary from case to case: it is incumbent upon the examiner to know the advantages and
limitations of each solution he/she uses, and to do that one must know how things work under normal and
routine circumstances, and so why things were done a particular way or why deviations were made (and
what the implications of those deviations might be).

Surely there will be times when one's preferred method of doing something such as creating a forensic copy
of evidence media or generating forensic evidence files from evidence media will fail...and the examiner will
have to come up with an alternative solution. If one does not know one’s options...and the relative strengths
and weaknesses of each alternative, one will have difficulty.

Finally, and most important, the examiner has the responsibility to present testimony regarding the integrity
of the evidence. If one cannot establish that the evidence media was handled in a forensically sound
manner throughout the investigation and examination processes, the “evidence” could be excluded from the
court proceedings!
To show that a particular handling process— namely, the forensic imaging process— was forensically sound
and properly conducted, examiners must complete their own testing and validation. How is it possible to do
that if one does not know how the write process works in the first place, and how the methodology being
tested is supposed to work?

In short, it would be quite an embarrassment if one were asked in court to describe how he/she knows that a
particular imaging methodology works, and how he/she tested that methodology, and one could not provide
such an explanation— or worse, provided an incorrect or inaccurate explanation.

Well, that’s it. Now we know what we need to do, why we need to do it, and some of the options we have to
make our “how” part more effective. And we can also provide testimony to explain how the “magic” works
behind the scenes.
 Validation, Acquisition and
IA CIS
The International Association of
Computer Investigative Specialists
Environmental Control
■

Instructor Led Sterilization Practical Exercise

1. If not already done, disable Secure Boot on the student laptops.

2. If not already done, enable Legacy Support on the student laptops.

3. Boot the laptops from the Paladin USB device.

4. Insert the USB drive supplied by the coaches.

5. Launch Paladin Toolbox.

6. Select the Disk Manager Tab.

7. Note how the Linux Operating system names physical disks and logical volumes.

8. Select the physical USB disk and click on the W ipe button, (this process will take approx. 20 m inutes).

9. Choose to NOT verify. We will validate with a different tool.

 Imager Device M odel FileSystem Label Size M o u n t Path M ode

/d e v/sd a WDC W D5000LPLX-60ZNTT1 46S.76GB

Image Converter
/dev/sda1 WDC WD5000LPLX-60ZNTT1 v fa t 260.00MB

Find /dev/sda2 WDC W D5000LPLX-60ZNTT1 16.00MB

/d e v /s d a 3 WDC W D5000LPLX-60ZNTT1 n tfs W indow s 450.14GB

Unallocated
/dev/sd a4 WDC W D5000LPLX-60ZNTT1 n tfs W indows_RE_tools 980.00MB

Disk Manager
/dev/sda5 WDC WD5000LPLX-60ZNTT1 n tfs RECOVERY 14.39GB

Network Share /d e v /s d b Flash Disk 7.62GB

/d e v /s d b l Flash Disk v fa t PALADIN 7.47GB /isodevice Read-W rite

/dev/sd c ST500LT012-1DC142 465.76GB

/m e d ia /
/d e v /s d d ST500LT012-1DG142 n tfs Seagate_Expansion_Drive 465.76GB Read-W rite
Seagate_Exp...

7 d e v /s d d D ataTraveler 3.0 14.41GB

M ou/rrH Kr» n x /n o u f rxAQACcu HQ

Refresh V e rify F orm at , W ipe

Task Logs System Logs V e rify W ipe

M ar-17-2018 06:40:46 /d e v /s d c l (M o d e l : ST5O0LTO12-1DG142, S c ri.il N o. : S 3P P 8H 1H .S ze :46S .76G B ) m o u n te d as re a d -w rite

Sum u ri LLC, USA

PALADIN-7.02

10. Reboot the laptops to Windows and remove the Paladin USB device.
 Validation, Acquisition and
IAC3S
The International Association of
Computer Investigative Specialists
Environmental Control
■

Instructor Led Validation Practical Exercise

1. Launch HxD as Administrator.

2. From the Extras Menu, select Open Disk.

3. Select the disk listed as Removable Media. (Note that the tool defaults to open the device Read Only).

4. Once the disk is open, use the Analysis menu to select Checksums.

5. Select Checksum-64 and click on the OK button.

6. Note the output of all Oh.

7. Close HxD..
 Validation, Acquisition and
Environmental Control
Instructor Led Imaging Practical Exercise

1. Format the previously wiped USB drive.

2. Once the volume is formatted, created a new text document named Test.txt.

3. Open the text file and enter “Test data" and save the file.

4. Plug in the external USB drives you received in your student backpack.

5. Give the volume a unique label.

6. Boot the laptops to Paladin.

7. Launch the Paladin Toobox.

8. Select the Disk Manager tab.

9. Locate the volume on the USB drive to which you wish to write the image (this is the reason for the
unique volume label).

10. Highlight that volume and click on the Mount-RW button.

11. Select the Imager tab.

12. Select the Source (the disk to be imaged).

13. Select the Image type (Note the different choices).

14. Select the Destination (the volume we just mounted).

15. Provide a Label (Use Paladin Practical).

 16. Check the Verify after creation box.

17. Click the Start button.

PALADIN TOOLBOX

r Im ager

Imag* Converter
Source

Image Type

D estination
/d e v /s d d D a taT raveler3.0 14.41GB

dd (RAW)

/d e v /s d c t ST500LT012-1DG142 Seagate_Expansion_Drive 465.76GB n tfs

: it

J
Label

•y (V erify a fte r tre a tio n l Segm ent Size 12000

A d d itio n a l Im ager
Disk Manager
Image Type
Network Share
Destination

Label

V e rify a fte r cre a tio n S egm ent Size 12000

S tart

Task Logs System Logs Im ager 1 im ager 2

3021B842 sectors o u t

dc3dd c o m p le te d a t 201B-03-11 0 6 :4 9:3 2 +0000

V
Sumuri LLC, USA

PALADIN-7.02

18. Once the image has been created and verified, reboot to Windows.

19. Using File Explorer, navigate to the folder containing the image.

20. View the log created by Paladin Imager.

 Validation, Acquisition and
I AGI S
The International Association of
Environmental Control
■

Computer Investigative Specialists

Practical Exercise (Student Version)

Students are required to perform a number of processes to demonstrate understanding of and competency in
concepts taught in the lessons on physical and logical disk structures, hashing, environmental control, media
sterilization and validation, and forensic imaging theory.

Following an overview presentation, students will be issued a 40GB 2.5” SATA hard disk drive to use a
“suspect” hard disk drive. Students will use their lACIS-issued write blocking device to connect the “suspect”
hard disk drive to their forensic computers, and then use forensic software to generate a forensic imaging of the
device (in the form of forensic evidence files). Students will use their lACIS-issued external hard disk drive as
the destination location for the forensic imaging of the “suspect” hard disk drive.

The directives and questions that follow are designed to help guide students through the forensic imaging
process, reinforcing the instructional material covered in the relevant lecture sessions.

This document will serve as a record of completion of the exercise, and it will be collected by IACIS staff.

1. List the suspect hard.disk drive geometry (attributes): .

Ç/I?. j .t S l (?(? $Cc~^0< ~~ Gf

List the destination hard disk drive geometry (attributes):
A, ^ 53^ S ’T&
£<ft,\nrv- Ç /Z -
JL r ¿ÇÇ
t, *, cU G«C cï &
What \&rhe-bloÎkinç)devic(Tis being used:
'T S3

4. Was the suspect hard disk drive physically recognized by the forensic computer?

JY e s * No

5. Was the suspect hard disk drive physically recognized by Tableau Imager? .-Yes — No

If so list the hard disk drive geometry (attributes):

6. Was forensic imaging software used?

_^Y£sy — No
If so, list the software and why it was used (for example, forensic imaging generation, forensic imaging
verification, etc.):
7. For the suspect hard disk drive, what is the reported number of physical sectors reported by the forensic
imaging software (if used)?

\s&\
Ah
8. For the suspect hard disk drive, what is the physical drive number as reported by Windows and the
forensic imaging software (if used)?

9. For the suspect hard disk drive, does the number of physical sectors reported by the manufacturer,
Tableau Imager, and forensic imaging software match?

.^Yes ^ No

If not, explain why:

10. Provide the MD5 and SHA1 hash values obtained prior to generating the forensic image of the suspect
hard drive (i.e. pre-hashing):
MD5 Hash: C-

SHA1 Hash: d G- JL Z (-1 H CSC 7 J o ¿tfStfCM S e Jc 8 c m k

11. List the size, full path, and volume letter of the destination location where the forensic image file(s) will be
written:
'Í - 5 - K ?

12. List any software options or settings used or selected when creating the forensic image:
■jr ty vv^ P
13. List the beginning and ending date and time for the forensic imaging process:

Start Date/Time: ¿>(r AA.1 £/)

End Date/Time: 4 . 42 . "7 c?.4 2^* A? i J c)

14. For the suspect hard disk drive, based on the number of physical sectors documented from the drive’s
manufacture (label, website, or other source), forensic imaging software, and resulting forensic imaging
file, do all of the numbers match?
15. Do you believe that an accurate forensic image of the suspect hard disk drive has been successfully
generated?

.—Yes — No

16. List the MD5 and SHA1 values you obtained after generating the forensic image of the suspect hard disk
drive (aka: post-hashing):

MD5 Hash:

SHA1 Hash:

17. Do the MD5 and SHA1 hash values documented before and after generating the forensic image match?

—Yes — No

18. Based on all of your documentation, is there any information that would suggest that data on the suspect
hard disk drive has been altered as a result of the hardware, software, or the procedures used during the
forensic imaging process?

.-.Yes — No

19. Choose the best answer for the order of final procedures in the forensic imaging process:

a. Close the forensic imaging software, disconnect the data cable from the suspect hard disk drive,
and turn off the write-blocking device.

b. Disconnect the write-blocking device's power from the wall, pull the plug on the forensic
computer, and disconnect the suspect hard disk drive.

c. Close the forensic imaging software, turn off the power to the write-blocking device, and
disconnect the data/power cables from the suspect hard disk drive.

d. Pull the plug on the forensic computer, disconnect the data/power cable from the suspect hard
disk drive, and power-off the write-blocking device.

20. True or False (circle): After obtaining a forensic image of a stand-alone hard disk drive from one exhibit
(evidence package), examiners should securely package the evidence, complete a chain of custody log,
and return the exhibit to the proper evidence storage facility or the submitting agency.
 SW GDE Digital & Multimedia Evidence Glossary

Disclaimer:
As a condition to the use o f this document and the information contained therein, the SW G D E
requests notification by e-mail before or contemporaneous to the introduction o f this document,
or any portion thereof, as a marked exhibit offered for or moved into evidence in any judicial,
administrative, legislative or adjudicatory hearing or other proceeding (including discovery
proceedings) in the United States or any Foreign country. Such notification shall include: 1) The
formal name o f the proceeding, including docket number or similar identifier; 2) the name and
location o f the body conducting the hearing or proceeding; 3) subsequent to the use o f this
document in a formal proceeding please notify S W G D E as to its use and outcome; 4) the name,
mailing address (if available) and contact information o f the party offering or moving the
document into evidence. Notifications should be sent to [email protected].

It is the reader's responsibility to ensure they have the most current version o f this document. It
is recommended that previous versions be archived.

Redistribution Policy:
S W G D E grants permission for redistribution and use o f all publicly posted documents created by
S W G D E , provided that the following conditions are met:
1. Redistribution o f documents or parts o f documents must retain the S W G D E cover page
containing the disclaimer.
2. Neither the name o f S W G D E nor the names o f contributors may be used to endorse or
promote products derived from its documents.
3. Any reference or quote from a S W G D E document must include the version number (or
create date) o f the document and mention if the document is in a draft status.

Requests for Modification:

S W G D E encourages stakeholder participation in the preparation o f documents. Suggestions for
modifications are welcome and must be forwarded to the Secretary in writing at
[email protected]. The following information is required as a part o f the response:
a) Submitter’ s name
b) Affiliation (agency/organization)
c) Address
d) Telephone number and email address
e) Document title and version number
f) Change from (note document section number)
g) Change to (provide suggested text where appropriate; comments not including
suggested text will not be considered)
h) Basis for change

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 1 of 21
Intellectual Property:
Unauthorized use o f the S W G D E logo or documents without written permission from S W G D E
is a violation o f our intellectual property rights.

Individuals may not misstate and/or over represent duties and responsibilities o f S W G D E work.
This includes claiming oneself as a contributing member without actively participating in
S W G D E meetings; claiming oneself as an officer o f S W G D E without serving as such; claiming
sole authorship o f a document; use the SW G D E logo on any material and/or curriculum vitae.

Any mention o f specific products within S W G D E documents is for informational purposes only;
it does not imply a recommendation or endorsement by S W G D E .

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 2 of 21
Preface
S W G D E provides this Glossary o f Terms with general, as well as discipline specific, definitions
as they apply across the spectrum o f image analysis, computer forensics, video analysis, and
forensic audio. Sources are notated within brackets at the end o f the definition when that
definition came from outside o f S W G D E . The following abbreviations will be used throughout
this glossary and appear before the definition as applicable:
(i) - Image Analysis
(c) - Computer Forensics
(v) - Video Analysis
(a) - Forensic Audio

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 3 of 21
Achievable Resolution
(i,v) Is a direct measurement o f the ability o f an imaging system to record detail, typically
measured by its ability to maintain separation between close subject elements such as fine lines
which are usually stated as ‘ line pairs or cycles per millimeter’ . It is often determined by imaging
a resolution test chart. With some imaging systems there may be a slight difference in the
horizontal and vertical resolution. I f so, the lower o f the two values is considered the achievable
resolution o f the imaging system.

Acquisition
(c) See “ Image".

Administrative Review
A procedure used to check casework for consistency with agency/laboratory policy and for
editorial practice.

Algorithm
A step-by-step procedure for solving a problem or accomplishing some end. [Webster’s
Dictionary ]

Analytical Photogrammetrv
A method o f photogrammetry in which solutions are obtained by mathematical methods.

Archive Copy
A copy o f data placed on media suitable for long-term storage, from which subsequent working
copies can be produced.

Archive Image
(i,v) Any image placed on media that is suitable for long-term storage.
(c) A bit stream duplicate o f the original data placed on media that is suitable for long-term
storage.

Archiving
The process o f storing data in a manner suitable for long term availability and retrieval.

Artifact
(a,i,v) A visual/aural aberration in an image, video, or audio recording resulting from a technical
or operational limitation. Examples include speckles in a scanned picture or “ blocking" in
images compressed using the JP E G standard.
(c) Information or data created as a result o f the use o f an electronic device that shows past
activity.

Aspect Ratio
(i,v) The width to height ratio o f an image.

SW G D E Digital & M ultim edia Evidence G lo ssary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 4 of 21
Audio Enhancement
Processing o f recordings for the purpose o f increased intelligibility, attenuation o f noise,
improvement o f understanding the recorded material and/or improvement o f quality or ease o f
hearing.

Authentication
The process o f substantiating that the data is an accurate representation o f what it purports to be.

Capture
The process o f recording data, such as an image, video sequence, or audio stream.

Capture eard/frame grabber

A piece o f computer hardware that accepts an analog or digital signal and outputs the signal as
digital data.

Capture Device
A device used in the recording o f data.

Carve
(c) The extraction o f a portion o f data for the purpose o f analysis.

CD/DVD (compact disc/digital versatile disc)

Optical disc formats designed to function as digital storage media.

Cellular Network Isolation Card (C N IC )

Identity module card that isolates a device from cellular connectivity. C N IC 's do not contain a
“ cipher key” thus preventing access with a cellular network.

Chain of Custody
The chronological documentation o f the movement, location and possession o f evidence.

Clarification
(i.v) See “ Image Enhancement” .

Clean Room/Chamber
To the extent possible, a limited particulate environment (e.g. requirements would follow- ISO 5
or Class 100 standard for air quality).

Codec (compressor/decompressor)
(i,v) A device or program capable o f encoding and decoding digital data. Codecs encode a
stream or signal for transmission, storage or encryption and decode it for viewing. Codecs are
necessary for playback o f encoded data. Generally, codecs from D C C T V systems are
proprietary.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 5 of 21
Cognitive Image Analysis
(i,v) The process used to extract visual information from an image.

Colorimetry
The quantification o f the color o f an object.

Color Range
The range o f colors that can be detected by a sensor.

Competency Test
The evaluation o f a person's knowledge and ability prior to performing independent work in
forensic casework. [ASCLD]

Composite Video Signal

(i,v) An analog signal which contains chroma, video, blanking and sync information and has
been combined using one o f the coding standards N T S C , P A L , S E C A M , etc.

Compression
The process o f reducing the size o f a data file. (See also, “ Lossy Compression” and “ Lossless
Compression'’ .)

Compression ratio
The size o f a data file before compression divided by the file size after compression.

Computer Forensics
A sub-discipline o f Digital & Multimedia Evidence, which involves the scientific examination,
analysis, and/or evaluation o f digital evidence in legal matters.

Copy
A n accurate reproduction o f information.

Data
Information in analog or digital form that can be transmitted or processed.

Data Analysis
The assessment o f the information contained within the media.

Data Extraction
A process that identifies and recovers information that may not be immediately apparent.

Data Smear
(c) The modification o f data by a running system during the data acquisition process.

SW GD E Digital & M ultim edia Evidence G lo ssary

Version: 3.0 (June 23, 2016)
This docum ent includes a cover page with the SWGDE disclaimer.
Page 6 of 21
Deblurring
(i,v) A type o f image restoration used to reverse image degradation, such as motion blur or out-
of-focus blur. It is accomplished by applying algorithms based on knowledge or an estimate o f
the cause o f the original degradation.

Deinterlacing
(v) Separating an interlaced frame into two discrete fields.

Demonstrative Comparison
(v) A method o f presenting the similarities and/or differences among images and/or objects
without rendering an opinion regarding identification or exclusion.

Digital C C T V Retrieval
(v) The process o f retrieving video/images from digital C C T V systems.

Digital Evidence
Information o f probative value that is stored or transmitted in binary form.

Digital Image
(i) An image that is represented by discrete numerical values organized in a twro-dimensional
array. [Taken from the ‘‘Encyclopedia o f Photography” 3rd Edition] When viewed on a monitor
or paper, it appears like a photograph.
(c) See “ Image” .

Directory Listing
(c) A list o f files contained within an object. It may also contain other information such as the
size and dates o f the files.

Dowmloading/Exporting
(i,v) The process o f retrieving audio, video, and still images and transactional data from a D V R
system. Can be in either the native/proprietary format or an open format.

Duplicate
An accurate and complete reproduction o f all data objects independent o f the physical media.

Dynamic Range
(i) The difference between the brightest highlight and darkest value that a sensor (e.g. film or
C C D ) can detect and record in a single image.
(a,v) The ratio o f the strongest (undistorted) signal to that o f the weakest (discernible) signal in a
unit or system as expressed in decibels (dB). A w'ay o f stating the maximum signal to noise ratio.

D V R (Digital Video Recorder)

(i,v) A stand-alone embedded system or a computer based system used to record video and/or
audio data.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page w ith the SWGDE disclaimer.
Page 7 of 21
Enhancement
(i.v) See “ Image Enhancement'’.
(a) See “ Audio Enhancement” .

Erased File Recoven7

(c) The process for recovering deleted files.

Extraction
(c) A method o f exporting data from a source (e.g. copying data from EnCase preview, dumping
data from a cell phone). See “ Data Extraction” .
(i,v) See “ Downloading/Exporting".

Field
(v) A n element o f a video signal containing alternate horizontal lines. For interlaced video, the
scanning pattern is divided into two sets o f spaced lines (odd and even) that are displayed
sequentially. Each set o f lines is called a field, and the interlaced set o f the two sets o f lines is a
frame.

File Format
The structure by which data is organized in a file.

File Slack
(c) The data between the logical end o f a file and the end o f the last storage unit for that file.
E x : For the F A T file system, the data between the logical end o f the file and the end o f the
cluster.

Fixed Focal Length Lens (Prime Lens)

(i.v) A lens with a focal length that is not adjustable.

Focal Length
(i,v) Distance from the optical center o f a lens to its point o f focus at the sensor/image plane
when focused at infinity. Smaller focal length values provide a wider field o f view; larger focal
length values provide a narrower field o f view.

Forensic
The use or application o f scientific knowledge to a point o f law, especially as it applies to the
investigation o f crime.

Forensic Audio
A subdiscipline o f Digital & Multimedia Evidence, which involves the scientific examination,
analysis, comparison, and/or evaluation o f audio.

Forensic Cloning
The process o f creating a bit stream duplicate o f the available data from one physical media to
another.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 8 of 21
Forensic Image
(c) See " Image” .

Forensic Photogrammetrv
The process o f obtaining dimensional information regarding objects and people depicted in an
image for legal applications.

Forensic Video Analysis

See " Video Analysis” .

Forensic Wipe
A verifiable procedure for sanitizing a defined area o f digital media by overwriting each byte
with a known value.

Format
(verb) The process o f preparing a hard disk and/or removable media for data storage. This is not
a replacement for a forensic wipe.

(noun) The structure by which data is organized on a device.

(v) One or several combined elements that may be used to describe the video recording method.
These include tape width (e.g. 8mm. /2 inch. % inch. 1 inch), signal form (e.g. composite. Y/C,
component), media (e.g. V H S tape. D V D , C D ), data storage type (e.g. analog/digital,
A V I/M PE G ), and signal standard (e.g. N T S C . P A L . S E C A M ).

Format Conversion
(a.i,v) To transfer audio and/or video information from one media type to another and/or from
one recording method to another.

Frame
(v) Lines o f spatial information o f a video signal. For interlaced video, a frame consists o f two
fields, one o f odd lines and one o f even lines, displayed in sequence. For progressive scan (non­
interlaced) video, the frame is written through successive lines that start at the top left o f the
picture and finish at the bottom right.

Free Space
Data storage areas available for use by the computer. The area may already contain previously
stored information. Also referred to as Unallocated Space.

Gaussian Blur
(i,v) A function typically used to reduce image noise and detail using a specific mathematical
function known as the “ Gaussian Kernel” or "bell-curve” . The visual effect o f this technique is a
smoothing o f image features as if viewing the image through a translucent filter.

Gcotag
G P S coordinates added to files as metadata.
SW GD E Digital & M ultim edia Evidence G lossary
Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 9 of 21
GPX
G P S exchange format. An X M L scheme designed for a common G P S format for software
applications.

Hash or Hash Value

Numerical values, generated by hashing functions, used to substantiate the integrity o f digital
evidence and/or for inclusion /exclusion comparisons against known value sets.

Hashing Function
An established mathematical calculation that generates a numerical value based on input data.
This numerical value is referred to as the hash or hash value.

Image
(i,v) An imitation or representation o f a person or thing, drawn, painted, photographed, etc.
(c) A bit stream copy o f the available data. The result may be encapsulated in a proprietary
format (e.g., E01. 001, etc.).

Image Analysis
The application o f image science and domain expertise to examine and interpret the content o f an
image, the image itself, or both in legal matters.

Image Averaging
(i.v) The process o f averaging similar images, such as sequential video frames, to reduce noise
in stationary scenes.

Image Comparison (Photographic Comparison)

(i) The process o f comparing images o f questioned objects or persons to known objects or
persons or images thereof, and making an assessment o f the correspondence between features in
these images for rendering an opinion regarding identification or elimination.

Image Content Analysis

(i) The drawing o f conclusions about an image. Targets for content analysis include, but are not
limited to: the subjects/objects within an image; the conditions under which, or the process by
which, the image was captured or created; the physical aspects o f the scene (e.g.. lighting or
composition); and/or the provenance o f the image.

Image Data Recovery

(i) The process o f retrieving viewable image(s) from a data set.

Image Enhancement
(i,v) Any process intended to improve the visual appearance o f an image or specific features
within an image.

Image Output
(i) The means by which an image is presented for examination or observation.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This docum ent includes a cover page with the SWGDE disclaimer.
Page 10 of 21
Image Processing
(i) Any activity that transforms an input image into an output image.

Image Processing Log

(i) A record o f the steps used in the processing o f an image.

Image Restoration
See ‘‘Restoration” .

Image Synthesis
(i,v) Any process that renders an image, using computer graphics techniques, for illustrative
purposes (i.e. age progression, facial reconstruction, accident/crime scene reconstruction).

Imaging Technology
(i.v) Any system or method used to capture, store, process, analyze, transmit, or produce an
image. Such systems include film, electronic sensors, cameras, video devices, scanners, printers,
computers, etc.

Image Transmission
(i,v) The act o f moving images from one location to another.

Integrity verification
The process o f confirming that the data presented is complete and unaltered since time o f
acquisition.

Intermediate Storage
Any media or device on which data is temporarily stored for transfer to permanent or archival
storage.

Interlaced Scan
(v) A technique o f combining two television fields in order to produce a full frame. The two
fields are composed o f only odd and only even lines, which are displayed one after the other but
with the physical position o f all the lines interleaving each other, hence interlace, fC C T V , Vlado
Damjanovski, Butterworth-Heinemann. 2000]

Interpolation
(i.v) A method o f image processing whereby one pixel, block, or frame is displayed or stored
based on the differences between the previous and subsequent pixel, block, or frame o f
information. [Taken from the Encyclopedia o f Photography 3rd Edition] This is often done to
increase the apparent clarity o f an image.

Log File
A record o f actions, events, and related data.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 11 of 21
Logical Acquisition/Conv
(c) A n accurate reproduction o f information contained within a logical volume (e.g. mounted
volume, logical drive assignment, etc).

Lossy Compression
Compression in which data is lost and cannot be retrieved in its original form.

Lossless Compression
Compression in which no data is lost and all data can be retrieved in its original form.

Media
Objects on which data can be stored.

Media Characterization
The process o f inspecting, identifying, and noting the properties o f the media.

Memory Smear
(c) The modification o f data by a running system during the memory acquisition process.

Metadata
Data, frequently embedded within a file, that describes a file or director}', which can include the
locations where the content is stored, dates and times, application specific information, and
permissions.

Mobile Device
A portable device that has an embedded system architecture, processing capability, on-board
memory, and may have telephony capabilities (e.g., cell phones, tablets, and smartphones).

Mobile Phone Forensics

For legal purposes, the utilization o f scientific methodologies to recover data stored by a cellular
device.

Multiplexcr/Demultiplcxer
(v) A device used to combine multiple video signals into a single signal or separate a combined
signal. These devices are frequently used in security and law enforcement applications for
recording and/or displaying multiple camera images simultaneously or in succession.

Multimedia Evidence
Analog or digital media, including, but not limited to, film, tape, magnetic and optical media,
and/or the information contained therein.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 12 of 21
Native File Format
The original form o f a file. A file created with one application can often be read by others, but a
file's native format remains the format it was given by the application that created it. In most
cases the specific attributes o f a file (for example, fonts in a document) can only be changed
when it is opened with the program that created it. [Newton's Telecom Dictionary\

Noise
(i.v) Variations or disturbances in brightness or color information in an image that do not arise
from the scene. Sources o f noise include film grain, electronic variations in the input device
sensor and circuitry, and stray electromagnetic fields in the signal pathway. It frequently refers to
visible artifacts in an image.

Nominal Resolution
(i,v) The numerical value o f pixels per inch as opposed to the achievable resolution o f the
imaging device. In the case o f flatbed scanners, it is based on the resolution setting in the
software controlling the scanner. In the case o f digital cameras, this refers to the number o f
pixels o f the camera sensor divided by the corresponding vertical and horizontal dimension o f
the area photographed.

Normal Lens
(i.v) A lens designed to approximate the field o f view o f the human eye without magnification
or reduction. The focal length o f a normal lens is based on the sensor size in the camera.

N TSC
National Television System Committee also referred to as National Television Standards
Committee.

N V R (Network Video Recorder)

A network based surveillance video recording system, typically utilizing Internet Protocol (IP)
cameras and Internet connectivity that allows for remote access through a web client or mobile
application.

Original Image
(i) An accurate and complete replica o f the primary image, irrespective o f media. For film and
analog video, the primary image is the original image.

Original Recording
(a) The first manifestation o f sound in a recoverable stored format.

PAL
Phase Alternation Line. [European Broadcast Union ]

Partition
User defined section o f electronic media.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 13 of 21
Password Recovery
The process o f locating and identifying a series o f characters used to restrict access to data.

PCB
Printed Circuit Board. A board used in electronics.

Peer Rev iew/Technical Review

An evaluation conducted by a second qualified individual o f reports, notes, data, conclusions,
and other documents.

Photogrammetrv
The art, science, and technology o f obtaining reliable information about physical objects and the
environment through the processes o f recording, measuring, and interpreting photographic
images and patterns o f electromagnetic radiant energy and other phenomena. [The Manual o f
Photogrammetry, 4,h Edition, 1980, A SPR S]
In forensic applications. Photogrammetry. sometimes called “ mensuration.” most commonly is
used to extract dimensional information from images, such as the
height o f subjects depicted in surveillance images and accident scene reconstruction. Other
forensic photogrammetric applications include visibility and spectral analyses. When applied to
video, this is sometimes referred to as “ videogrammetry” .

Photometry'
The measurement o f light values o f objects in an image.

Physical Copy
(c) An accurate reproduction o f information contained on the physical device.

Physical Image/Acquisition
(c) A bitstream duplicate o f data contained on a device.

Pixel
Picture element, the smallest component o f a picture that can be individually processed in an
electronic imaging system [The Focal Encyclopedia o f Photography, 4th Edition 2007].

Playback Optimization
(a.v) The process o f determining the most suitable equipment and settings for analyzing the
output signal.

Playback
Recorded material viewed and heard as recorded, facilitated by camcorder, cassette recorder, or
other device.

Preview
(c) A sub-process o f triage where a cursory' review o f items is performed to assess the need for
collection and/or further examination.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This docum ent includes a cover page with the SWGDE disclaimer.
Page 14 of 21
Primary Image
(i,v) Refers to the first instance in which an image is recorded onto any media that is a separate,
identifiable object. Examples include a digital image recorded on a flash card or a digital image
downloaded from the Internet.

Processed Image
(i,v) Any image that has undergone enhancement, restoration or other operation.

Production Switcher
(a,v) A device and/or software used to mix video and/or audio signals from two or more sources
(e.g. cameras, videocassette recorder/players, character generators) for dissolves, wipes, and
other transition effects.

Proficiency Test
A test to evaluate analysts, technical support personnel, and the quality performance o f an
agency. (Four examples are provided)
1. Open test - the analyst(s) and technical support personnel are aware they are being
tested.
2. Blind test - the analyst(s) and technical support personnel are not aware they are
being tested.
3. Internal test - conducted by the agency itself.
4. External test - conducted by an agency independent o f the agency being tested.

Progressive Sean
(v) Display scan pattern where each line o f the frame is scanned out sequentially.

Proprietary File Format

Any file format that is unique to a specific manufacturer or product.

Quality Assurance
Planned and systematic actions necessary to provide sufficient confidence that an
agencyVlaboratory's product or service will satisfy given requirements for quality.

Quantitative Image Analysis

(i,v) The process used to extract measurable data from an image.

Reconstruction
The process o f repairing damaged media in order to allow the retrieval o f data.

Reference Materials
Refers to items such as published literature, hardware and software documentation, hash sets,
header sets. etc.

Reliability
The extent to which information can be depended upon.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This docum ent includes a cover page w ith the SWGDE disclaimer.
Page 15 of 21
Reproducibility’
The extent to which a process yields the same results on repeated trials.

Residue
(c) Data that is contained in unallocated space or file slack.
(a) The residue o f a filtered signal is the algebraic difference between the filter output and its
signal input. [Diamond Cut Users Manual]

Resolution
(i,v) The act, process, or capability o f distinguishing between two separate but adjacent parts or
stimuli, such as elements o f detail in an image, or similar colors. [Taken from the Encyclopedia
o f Photography, 3rd Edition]

Resolving Power
(i,v) See “ Achievable Resolution".

Restoration
(i,v) Restoration is any process applied to an image that has been degraded by a known cause
(e.g.. defocus or motion blur) to partially or totally remove the effects o f that degradation.
(c) The process o f restoring data from an image.

Route
A series o f waypoints.

Routing Sw itcher
(a,v) A device and/or software used to direct the path o f one or more signals into one or more
devices.

Sharpening
(i.v) A process used to emphasize edge detail in an image by enhancing the high frequency
components.

Signature Wiped
Media that has been securely wiped in accordance with acceptable standards, such as those by
N IST , utilizing a sector character signature that is unique.

Skimmer
A magnetic card reader used for illegal purposes.

Standard Conversion
(v) The transformation o f one television system signal to another. For example, N T S C to PA L .

Source Code
The list o f instructions written in a programming language used to construct a computer
program.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 16 of 21
Storage Media
Any object on which data is preserved.

S-Video
(i.v) A signal in which the luminance and chrominance are separate.

Technical/Peer Review
An evaluation conducted by a second qualified individual o f reports, notes, data, conclusions,
and other documents.

Time-base Corrector (TBC)

(v) An electronic device used to correct timing inconsistencies and stabilize the playback o f the
video signal for optimum quality. It also synchronizes video sources allowing image mixing.

Timed Expiry
(v) A feature o f D V R s that allows the equipment to adhere to data retention policies that may be
mandated in certain parts o f the world which results in video data becoming inaccessible after a
certain date. This may happen even when the unit is switched off.

Time Lapse Video Recording

(v) Process by which images are recorded at less than the standard rate o f frames per second
(N T SC - 29.97; P A L - 25.00) thus extending the period o f time that can be covered by the
storage medium.

Timeline Sequence Reconstruction

The process o f relating images, audio, or other data to one another in a chronologically ordered
succession.

Track Log
A complete list o f trackpoints that a G P S device has created.

Trackpoint
A location automatically created and stored by a G P S device without user interaction as a record
o f where it has been.

Traditional Enhancement Techniques

(i) Techniques that have direct counterparts in traditional darkrooms. They include brightness &
contrast adjustment, color balancing, cropping, and dodging & burning.

Transcode
To convert between formats or encoding methods.

T riage
(c) The process by which items considered for collection or analysis arc prioritized to determine
the order in which they should be collected and/or analyzed, if at all.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 17 of 21
Trusted Media
(c) Media o f a known state and risk to the examination.

Unallocated Space
(c) Data storage areas available for use by the computer. The area may already contain
previously stored information. Also referred to as Free Space.

Validation
The process o f performing a set o f experiments, which establishes the efficacy and reliability o f a
tool, technique or procedure or modification thereof.

Validation Testing
An evaluation to determine i f a tool, technique or procedure functions correctly and as intended.

Variable Focal Length Lens (Zoom)

(i,v) A lens that the focal length can be continuously changed between set limits. It can range
from wide angle to telephoto.

Vectorscone
(v) An electronic device that measures a video signal’ s chrominance (color) performance.

Verification
1. The process o f confirming the accuracy o f an item to its original.
2. Confirmation that a tool, technique or procedure performs as expected.

Video
The electronic representation o f a sequence o f images, depicting either stationary or moving
scenes. It may include audio.

Video Analysis
The scientific examination, comparison, and/or evaluation o f video in legal matters.

Video Distribution Amplifier

(v) A device used to divide single video signals, while boosting their strength for delivery to
multiple video devices.

Video Enhancement
Any process intended to improve the visual appearance o f video sequences or specific features
within video sequences.

Video Security7Recording System

One or more cameras connected to a recording device capable o f storing analog or digital video
infonnation.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This docum ent includes a cover page with the SWGDE disclaimer.
Page 18 of 21
Video Stabilization
(v) The process o f positioning individual frames so that a selected object or person will remain
in the same location as the video is played.

Waveform Monitor
(v) An electronic device that provides a graphic display o f a video signal.

Waypoint
A location that is stored by a G P S device based on user interaction.

Work Copy
A copy or duplicate o f a recording or data that can be used for subsequent processing and/or
analysis.

W O R M (storage)
Write Once, Read Many. A storage technology that allows media to be written only once but
read an unlimited number o f times.

Write Block/Write Protect

Hardware and/or software methods o f preventing modification o f media content.

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 19 of 21
 SW GDE Digital & Multimedia Evidence Glossary

History

Revision Issue Date Section History

1.0 07/25/2005 Original Release created
by SW G D E and the
Scientific Working Group
on Imaging Technology
(SW GIT) ~

2.0 01/10/2006 Added Image Data Recovery (i), Image Content Revision o f document by
Analysis (i), Digital C C T V Retrieval (v), SW G D E and SW GIT.
Demonstrative Comparison (v), Video Revision number change.
Stabilization (v)

2.1 06/08/2007 Updated Demonstrative Comparison (v) definition Revision o f document by

SW G IT and SW G D E .
Revision number change.

2.2 11/1/2007 Removed definition Digital Image (c), Revision o f document by

SW G IT and SW G D E .
Added Forensic Image (c) Revision number change.

2.3 05/22/2009 Added Aspect Ratio (i,v), Image Restoration (i,v) Revision o f document by
Sharpening (i,v), Noise (i,v), Deblurring (i,v) SW G IT and SW G D E .
Gaussian Blur (i,v), updated Photogrammetry Revision number change.
definition, and updated Restoration definition

2.4 01/14/2011 Added Achievable Resolution definition. Nominal Revision o f document by

Resolution (i,v). Competency Test, Reference for SW G IT and SW G D E .
Peer Review, Forensic Wipe Revision number change.

2.5 1/13/2012 Added Format. Timed Expiry and Mobile Phone Revision o f document by
Forensics definitions, modified logical copy to SW G IT and SW G D E .
include logical acquisition, modified physical Revision number change.
image to include physical acquisition and deleted
the word physical

2.6 6/8/2012 Changed Peer Review to Peer/Technical Review Revision o f document by

and used same definition as Technical/Peer SW G IT and SW G D E .
Review , added Acquisition (c), Extraction (c,i,v), Revision number change.
Codec (i,v), Composite Video Signal (i,v),
Downloading/Exporting (i,v), D V R (i,v),
Enhancement (a,i,v). Fixed Focal Length Lens
(i,v), Focal Length (i,v), Normal Lens (i,v), S-
Video (i, v). Variable Focal Length Lens (Zoom)
(i.v)

SW GD E Digital & M ultim edia Evidence G lo ssary

Version: 3.0 (June 23, 2016)
This docum ent includes a cover page with the SWGDE disclaimer.
Page 20 of 21
Revision Issue Date Section History
2.7 4/8/2013 Added definitions: Cellular Network Isolation Revision o f document by
Card (CN1C), Forensic Cloning, Image (c), Pixel, SW G IT and SW G D E .
Trusted Media (c). W ORM Revision number change.

2.8 05/27/2015 Added the following definitions: Clean Revision o f document by

Room/Chamber, Data Smear. Geotag(s), G P X , SW G IT and SW G D E .
Memory Smear, Mobile Device, Original Revision number change.
Recording, PCB , Preview, Route, Signature
Wiped, Skimmer, Track Log, Trackpoint,
Transcode. Triage. Waypoint

3 .0 -D ra ft 02/08/2016 This document was originally created and released Revision o f document by
in collaboration with SW G IT and titled, SW G D E for Draft for
SW GDE/SW GIT Diaital & Multimedia Evidence Public Comment.
Glossarv. This undate retitled the document.
SW G D E Diaital & Multimedia Evidence Version number change
Glossary, and chanaed the formattina to match pending release as
SW G D E formatting. Approved.

Added the following definitions: Forensic

Analytical Photogrammetry, N V R (Network
Video Recorder), Photogrammetry, Video
Security Recording System

Modified the following definitions: Image

Analysis. Video Analysis

Removed the following definition:

Photogrammetric Analysis
3.0 06/23/2016 Added term “ Forensic Video Analysis5' and SW G D E voted to release
pointed to existing definition for “ Video as an Approved document.
Analysis’".

SW GD E Digital & M ultim edia Evidence G lossary

Version: 3.0 (June 23, 2016)
This document includes a cover page with the SWGDE disclaimer.
Page 21 of 21
0 '— " > Validation, Acquisition and
1AG I S
The International Association of
Environmental Control ■

Computer Investigative Specialists Practical Exercise (Staff Version)

Students are required to perform a number of processes to demonstrate understanding of and competency in
concepts taught in the lessons on physical and logical disk structures, hashing, environmental control, media
sterilization and validation, and forensic imaging theory.

Following an overview presentation, students will be issued a 40GB 2.5” SATA hard disk drive to use a
“suspect" hard disk drive. Students will use their lACIS-issued write blocking device to connect the “suspect”
hard disk drive to their forensic computers, and then use forensic software to generate a forensic imaging of the
device (in the form of forensic evidence files). Students will use their lACIS-issued external hard disk drive as
the destination location for the forensic imaging of the “suspect” hard disk drive.

The directives and questions that follow are designed to help guide students through the forensic imaging
process, reinforcing the instructional material covered in the relevant lecture sessions.

This document will serve as a record of completion of the exercise, and it will be collected by IACIS staff.

Students are encouraged to work this exercise independently, if for no other reason than to challenge
or test their baseline knowledge and skillsets.

Staff should monitor their assigned students provide assistance and answer questions, as needed.

When addressing student questions, staff might consider guiding students to the correct answer or
understanding of the concept or point rather than directly answering, if that approach is possible, and
if the staff member feels that it w ill best serve the particular student’s needs.

it is NOT mandatory for a student to “ pass” every phase of the exercise by demonstrating obvious
mastery of the process and the concepts that underpin it. But, the student should at least
demonstrate a reasonable grasp of the underlying knowledge points, and demonstrate the skills
necessary to, generate and verify a forensic backup of a hard disk drive.

If a student does not demonstrate a satisfactory level of proficiency, staff should encourage the
student to work the exercise again during an evening laboratory session.

1. List the suspect hard disk drive geometry (attributes):

List common attributes/characteristics of the suspect hard disk drive (external visual
examination), and proper documentation of manufacturer information.

2. List the destination hard disk drive geometry (attributes):

See above.
3. What write-blocking device is being used:

Identify the make/model of the device, firmware version, serial number, and other important
identifiers. Identify the interface used to connect the device to the forensic computer.

4. Was the suspect hard disk drive physically recognized by the forensic computer?

^Y e s No

Self-explanatory...staff should assist students who experience issues. Students can try to verify
detection using Windows Disk Administration or with FTK Imager. If both of those methods
fail...try with Tableau Imager (see next question!). If everything fails...check connections...check
that the drive is actually powering up.

5. Was the suspect hard disk drive physically recognized by Tableau Imager? ^Y e s ^ No

If so list the hard disk drive geometry (attributes):

Tl should recognize the drive once the write-blocking device is powered on. Device information
should be reported by Tl.

6. Was forensic imaging software used?

.—Yes — No

If so, list the software and why it was used (for example, forensic imaging generation, forensic imaging
verification, etc.):

Students MUST use FTK Imager...and they MUST go to HELP | ABOUT to obtain version
information.

7. For the suspect hard disk drive, what is the reported number of physical sectors reported by the forensic
imaging software (if used)?

Self-explanatory.

8. For the suspect hard disk drive, what is the physical drive number as reported by Windows and the
forensic imaging software (if used)?

Self-explanatory.

9. For the suspect hard disk drive, does the number of physical sectors reported by the manufacturer,
Tableau Imager, and forensic imaging software match?

—Yes — No

If not, explain why:

The values should all match. The point is to determine the number of physical sectors reported
by the manufacturer and compare them to what the forensic backup software (FTK Imager) and
the write-blocking device (Tl) report...to ensure nothing is being missed and that a complete
physical forensic backup is being generated.
10. Provide the MD5 and SHA1 hash values obtained prior to generating the forensic image of the suspect
hard drive (i.e. pre-hashing):
MD5 Hash:

SHA1 Hash:

Self-explanatory.

11. List the size, full path, and volume letter of the destination location where the forensic image file(s) will be
written:

Self-explanatory. But ensure that the student creates an appropriate target folder structure on
the issued external USB hard disk drive.

12. List any software options or settings used or selected when creating the forensic image:

Self-explanatory. E01 files are preferred here, as are segmented files. We will cover single dd
options and other options for forensic evidence files during the instruction and overview
presentation.

13. List the beginning and ending date and time for the forensic imaging process:

Start Date/Time:

End Date/Time:

14. For the suspect hard disk drive, based on the number of physical sectors documented from the drive’s
manufacture (label, website, or other source), forensic imaging software, and resulting forensic imaging
file, do all of the numbers match?

.—Yes — No

Self-explanatory.

15. Do you believe that an accurate forensic image of the suspect hard disk drive has been successfully
generated?

—Yes — No

The answer should be “ yes.” Students must compare the pre-process values/attributes and
post-process values/attributes immediately following completion of the forensic backup
process.

16. List the MD5 and SHA1 values you obtained after generating the forensic image of the suspect hard disk
drive (aka: post-hashing):

MD5 Hash:

SHA1 Hash:

Self-explanatory.
17. Do the MD5 and SHA1 hash values documented before and after generating the forensic image match?

.—Yes — No

The answer should be “ yes.”

18. Based on all of your documentation, is there any information that would suggest that data on the suspect
hard disk drive has been altered as a result of the hardware, software, or the procedures used during the
forensic imaging process?

.—Yes — No

If the hash values match and the physical sector counts match, the answer should be “ no”
(meaning that there is no reason to suggest that there are any problems with writes to the
suspect media).

Pre- and post-process hashing verifies that the data on the suspect hard disk drive was not
altered in any way during the forensic backup process...the main point of validation that we
want students to understand from a conceptual standpoint.

19. Choose the best answer for the order of final procedures in the forensic imaging process:

a. Close the forensic imaging software, disconnect the data cable from the suspect hard disk drive,
and turn off the write-blocking device.

b. Disconnect the write-blocking device’s power from the wall, pull the plug on the forensic
computer, and disconnect the suspect hard disk drive.

c. Close the forensic imaging software, turn off the power to the write-blocking device, and
disconnect the data/power cables from the suspect hard disk drive.

d. Pull the plug on the forensic computer, disconnect the data/power cable from the suspect hard
disk drive, and power-off the write-blocking device.

20. True or False (circle): After obtaining a forensic image of a stand-alone hard disk drive from one exhibit
(evidence package), examiners should securely package the evidence, complete a chain of custody log,
and return the exhibit to the proper evidence storage facility or the submitting agency.