Forensic Analysis of the Resilient File System (Refs) Version 3.4

Total Page:16

File Type:pdf, Size:1020Kb

Forensic Analysis of the Resilient File System (Refs) Version 3.4 Department Informatik Technical Reports / ISSN 2191-5008 Paul Prade, Tobias Groß, Andreas Dewald Forensic Analysis of the Resilient File System (ReFS) Version 3.4 Technical Report CS-2019-05 December 2019 Please cite as: Paul Prade, Tobias Groß, Andreas Dewald, “Forensic Analysis of the Resilient File System (ReFS) Version 3.4,” Friedrich-Alexander-Universitat¨ Erlangen-Nurnberg,¨ Dept. of Computer Science, Technical Reports, CS-2019-05, December 2019. Friedrich-Alexander-Universitat¨ Erlangen-Nurnberg¨ Department Informatik Martensstr. 3 91058 Erlangen Germany · · www.cs.fau.de Forensic Analysis of the Resilient File System (ReFS) Version 3.4 Paul Prade1, Tobias Groß1 and Andreas Dewald1, 2 1Friedrich-Alexander University, Erlangen-Nuremberg, Germany 2ERNW Research GmbH, Heidelberg, Germany [email protected], [email protected] Abstract ReFS is a modern file system that is developed by Microsoft and its internal structures and behavior is not officially documented. Even so there exist some analysis efforts in deciphering its data structures, some of these findings have yet become deprecated and cannot be applied to current ReFS versions anymore. In this work, general concepts and internal structures found in ReFS are examined and documented. Based on the structures and the processes by which they are modified, approaches to recover (deleted) files from ReFS formatted file systems are shown. We also evaluated our implementation and the allocation strategy of ReFS with respect to accuracy, runtime and the ability to recover older file states. In addition, we extended The Sleuth Kit allowing it to parse ReFS partitions and build a carver based on that extend The Sleuth Kit. i List of Tables 2.1 Data categories........................................ 16 2.2 Postfixes of the names of file system tools.......................... 16 4.1 List of default ReFS attribute types.............................. 33 4.2 Data structure in the first 24 bytes of the boot sector (FSRS)................ 49 4.3 Data structure contained in the remainder of the boot sector................. 49 4.4 Structure of a page header.................................. 51 4.5 Structure of a page reference................................. 52 4.6 Structure of the superblock.................................. 53 4.7 Structure of the checkpoint.................................. 55 4.8 Structure of the index root element.............................. 57 4.9 Structure of the index header................................. 58 4.10 Structure of the header of a regular index entry....................... 58 4.11 Rows found in the Schema Table............................... 60 4.12 Rows found in the Object ID Table.............................. 60 4.13 Variable index root element used in Allocator Tables.................... 61 4.14 Rows found in Allocator Tables............................... 61 4.15 Bitmap structure used in Allocator Tables.......................... 61 4.16 Rows found in the Container Table.............................. 62 4.17 Rows found in the Parent Child Table............................ 62 4.18 Rows found in the Upcase Table............................... 62 4.19 Structure of the buffer found in the Logfile Information Table................ 63 4.20 Structure of the “Volume Label” row in the Volume Information Table........... 63 4.21 Structure of the “General Information” row in the Volume Information Table........ 63 4.22 Structure of the “General Information backup block” row in the Volume Information Table 64 4.23 Rows found in the Security Table............................... 64 4.24 Rows found in the Reparse Index Table........................... 64 4.25 Structure of the “Directory Descriptor” row type....................... 65 4.26 Structure of the “ID2” row type................................ 65 4.27 Structure of the “File” row type................................ 65 4.28 Structure of the “Directory Link” row type.......................... 66 4.29 Variable index root element used in Directory Descriptor tables............... 66 4.30 Variable index root element used in File tables........................ 67 4.31 Structure of the key in an attribute row............................ 68 4.32 Structure of the header of a standalone attribute....................... 68 4.33 Structure of the $DIR_LINK attribute type......................... 68 4.34 Structure of the $INDEX_ROOT attribute type........................ 69 4.35 Structure of the $NAMED_DATA attribute type........................ 69 4.36 Structure of the $REPARSE_POINT attribute type..................... 69 4.37 Structure of the $USN_INFO attribute type......................... 69 4.38 Rows found in the Data Run Table.............................. 70 4.39 Structure of a log page in the restart area........................... 76 4.40 Structure of a log page in the logging area.......................... 77 4.41 Structure of the redo information found in a log page in the logging area.......... 78 ii List of Tables 4.42 Structure of a table path component in a redo operation................... 78 6.1 Overview of the created test data sets............................. 91 6.2 Output of the TSK extension, compared to the final state of the file system......... 91 6.3 Final state of the file system, compared to the output of the TSK extension......... 92 6.4 State of all allocated files according to the TSK extension, compared to all actions..... 92 6.5 State of all files that could be recovered with the TSK extension compared to all actions.. 93 6.6 State of all files that could be recovered with the carver application compared to all actions 93 6.7 Runtimes of the different applications............................ 94 6.8 Experiment to analyze the recoverability of COW copies.................. 94 iii List of Figures 2.1 NTFS structure, based on [35, p. 7] and [12, p. 275].....................6 2.2 Corruption in B+-trees, according to [44]..........................8 2.3 (a) A basic b-tree (b) Inserting key 19, and creating a path of modified pages [39, p. 7]... 11 2.4 (a) A basic tree (b) Deleting key 6. [39, p. 7]......................... 11 2.5 Experiment to show, that Copy-On-Write allocations make full page copies........ 12 2.6 Abstraction layers used in The Sleuth Kit (TSK), based on [5]............... 14 4.1 Overview of the checkpoint mechanism........................... 25 4.2 Global root nodes referenced by the checkpoint....................... 26 4.3 Implementation of a table in a key-value store by using a B+-tree.............. 27 4.4 Concept of embedding tables................................. 27 4.5 Tables referenced by the Object ID Table........................... 28 4.6 Schematic view of the organization of the Object ID Table................. 29 4.7 Exemplary directory table................................... 30 4.8 Overview of the interaction between the Object ID Table and directory tables....... 32 4.9 Tables referenced by the checkpoint structure........................ 35 4.10 Exemplary view of the Upcase Table............................. 35 4.11 Overview of the Volume Information Table......................... 36 4.12 Exemplary Parent Child Table with its interpretation..................... 37 4.13 Interaction between the hierarchical allocators, according to [22, p. 41]........... 38 4.14 Schematic view of bands found in ReFS........................... 39 4.15 Necessity of the address translation process......................... 40 4.16 Exemplary address translation process............................ 41 4.17 Exemplary usage of the Block Reference Count Table.................... 41 4.18 Overview of the logging areas used in ReFS......................... 46 4.19 Example for an inconsistent checkpoint state (redo operations are necessary)........ 47 4.20 Example for a consistent checkpoint state (no redo operations are necessary)........ 47 4.21 Implementation to calculate the checksum of the FSRS................... 49 4.22 Example layout of the FSRS structure, explained in table 4.2................ 50 4.23 Example layout of the remaining boot sector, explained in table 4.3............. 50 4.24 Example layout of a page header, as explained in table 4.4................. 51 4.25 Example layout of a page reference structure, as explained in table 4.5........... 51 4.27 Calculation of a volume signature.............................. 53 4.26 Example layout of a superblock structure, as explained in table 4.6............. 54 4.28 Example layout of the first 144 bytes of a checkpoint structure, as explained in table 4.7.. 56 4.29 Example layout of the pointer list found in a checkpoint structure, as explained in table 4.7 56 4.30 Overview of the components of a Minstore B+ node.................... 57 4.32 Example layout of an Index Header structure, according to 4.9............... 58 4.33 Example layout of a key index structure........................... 58 4.31 Example layout of an index root structure, according to table 4.8.............. 59 4.34 Example layout of an index entry structure, according to 4.10................ 59 4.35 Example for the deletion of the entries e2 and e1 ....................... 71 4.36 Example for the deletion of the entries e1 and e2 ....................... 72 4.37 Example for the deletion of the entry e3 ........................... 72 4.38 Example for the insertion of the entry e5 ........................... 72 4.39 Example for the insertion of the entry e4 ........................... 73 4.40 Example for the remaining traces after a push operation................... 74
Recommended publications
  • File Protection – Using Rsync Whitepaper
    File Protection – Using Rsync Whitepaper Contents 1. Introduction ..................................................................................................................................... 2 Documentation .................................................................................................................................................................. 2 Licensing ............................................................................................................................................................................... 2 Terminology ........................................................................................................................................................................ 2 2. Rsync technology ............................................................................................................................ 3 Overview ............................................................................................................................................................................... 3 Implementation ................................................................................................................................................................. 3 3. Rsync data hosts .............................................................................................................................. 5 Third Party data host ......................................................................................................................................................
    [Show full text]
  • IT1100 : Introduction to Operating Systems Chapter 15 What Is a Partition? What Is a Partition? Linux Partitions What Is Swap? M
    IT1100 : Introduction to Operating Systems Chapter 15 What is a partition? A partition is just a logical division of your hard drive. This is done to put data in different locations for flexibility, scalability, ease of administration, and a variety of other reasons. One reason might be so you can install Linux and Windows side-by-side. What is a partition? Another reason is to encapsulate your data. Keeping your system files and user files separate can protect one or the otherfrom malware. Since file system corruption is local to a partition, you stand to lose only some of your data if an accident occurs. Upgrading and/or reformatting is easier when your personal files are stored on a separate partition. Limit data growth. Runaway processes or maniacal users can consume so much disk space that the operating system no longer has room on the hard drive for its bookkeeping operations. This will lead to disaster. By segregating space, you ensure that things other than the operating system die when allocated disk space is exhausted. Linux Partitions In Linux, a minimum of 1 partition is required for the / . Mounting is the action of connecting a filesystem/partition to a particular point in the / root filesystem. I.e. When a usb stick is inserted, it is assigned a particular mount point and is available to the filesytem tree. - In windows you might have an A:, or B:, or C:, all of which point to different filesystems. What is Swap? If RAM fills up, by running too many processes or a process with a memory leak, new processes will fail if your system doesn’t have a way to extend system memory.
    [Show full text]
  • NTFS • Windows Reinstallation – Bypass ACL • Administrators Privilege – Bypass Ownership
    Windows Encrypting File System Motivation • Laptops are very integrated in enterprises… • Stolen/lost computers loaded with confidential/business data • Data Privacy Issues • Offline Access – Bypass NTFS • Windows reinstallation – Bypass ACL • Administrators privilege – Bypass Ownership www.winitor.com 01 March 2010 Windows Encrypting File System Mechanism • Principle • A random - unique - symmetric key encrypts the data • An asymmetric key encrypts the symmetric key used to encrypt the data • Combination of two algorithms • Use their strengths • Minimize their weaknesses • Results • Increased performance • Increased security Asymetric Symetric Data www.winitor.com 01 March 2010 Windows Encrypting File System Characteristics • Confortable • Applying encryption is just a matter of assigning a file attribute www.winitor.com 01 March 2010 Windows Encrypting File System Characteristics • Transparent • Integrated into the operating system • Transparent to (valid) users/applications Application Win32 Crypto Engine NTFS EFS &.[ßl}d.,*.c§4 $5%2=h#<.. www.winitor.com 01 March 2010 Windows Encrypting File System Characteristics • Flexible • Supported at different scopes • File, Directory, Drive (Vista?) • Files can be shared between any number of users • Files can be stored anywhere • local, remote, WebDav • Files can be offline • Secure • Encryption and Decryption occur in kernel mode • Keys are never paged • Usage of standardized cryptography services www.winitor.com 01 March 2010 Windows Encrypting File System Availibility • At the GUI, the availibility
    [Show full text]
  • Organization, Planning, and Decision Making Strategy and Innovation to Describe What It Takes to ■ Keystone Strategy LLC (
    (continued from front fl ap) SINOFSKY $39.95 USA /$47.95 CAN IANSITI functions, building on his original research in the development of innovative products. Revealing insights into successfully making the leap from strategy to execution Learn from the concepts, capabilities, processes, and behaviors that aligned around one strategy One Strategy examines the concepts, capabilities, processes, and behaviors with the hard-won, fi rst-person insight found in that are essential to aligning an organization around one strategy. One Strategy. Learn some of the key management tools and processes the Windows 7 team put in place to manage strategy and execution. The themes in One his book challenges traditional views of strat- STEVEN SINOFSKY is President of the Win- Strategy are backed up through examples of internal blogs by Microsoft Tegy and operational execution—views that say dows and Windows Live Division at Microsoft Cor- Division President Steven Sinofsky and merged with insightful context strategy comes from a small group of select people poration. Prior to this position, he worked on the from technology and operations strategy expert Marco Iansiti, the David or that an innovative strategy can only emerge development of Microsoft Offi ce from 1994–2006 Sarnoff Professor of Business Administration at Harvard Business School. from a distinct organizational spinoff. Aligning a and, prior to that, worked on Microsoft’s develop- complex organization around one strategy requires All about developing and executing great, innovative strategies, One Strat- all members of a team to participate—learning, ment tools. egy reveals it is possible to build the right organizational capabilities and sharing, communicating, and contributing to the base of understanding, generate insightful strategies, develop detailed team’s success.
    [Show full text]
  • The Microsoft Compound Document File Format"
    OpenOffice.org's Documentation of the Microsoft Compound Document File Format Author Daniel Rentz ✉ mailto:[email protected] http://sc.openoffice.org License Public Documentation License Contributors Other sources Hyperlinks to Wikipedia ( http://www.wikipedia.org) for various extended information Mailing list ✉ mailto:[email protected] Subscription ✉ mailto:[email protected] Download PDF http://sc.openoffice.org/compdocfileformat.pdf XML http://sc.openoffice.org/compdocfileformat.odt Project started 2004-Aug-30 Last change 2007-Aug-07 Revision 1.5 Contents 1 Introduction ......................................................................................................... 3 1.1 License Notices 3 1.2 Abstract 3 1.3 Used Terms, Symbols, and Formatting 4 2 Storages and Streams ........................................................................................... 5 3 Sectors and Sector Chains ................................................................................... 6 3.1 Sectors and Sector Identifiers 6 3.2 Sector Chains and SecID Chains 7 4 Compound Document Header ............................................................................. 8 4.1 Compound Document Header Contents 8 4.2 Byte Order 9 4.3 Sector File Offsets 9 5 Sector Allocation ............................................................................................... 10 5.1 Master Sector Allocation Table 10 5.2 Sector Allocation Table 11 6 Short-Streams ...................................................................................................
    [Show full text]
  • Minimum Hardware and Operating System
    Hardware and OS Specifications File Stream Document Management Software – System Requirements for v4.5 NB: please read through carefully, as it contains 4 separate specifications for a Workstation PC, a Web PC, a Server and a Web Server. Further notes are at the foot of this document. If you are in any doubt as to which specification is applicable, please contact our Document Management Technical Support team – we will be pleased to help. www.filestreamsystems.co.uk T Support +44 (0) 118 989 3771 E Support [email protected] For an in-depth list of all our features and specifications, please visit: http://www.filestreamsystems.co.uk/document-management-specification.htm Workstation PC Processor (CPU) ⁴ Supported AMD/Intel x86 (32bit) or x64 (64bit) Compatible Minimum Intel Pentium IV single core 1.0 GHz Recommended Intel Core 2 Duo E8400 3.0 GHz or better Operating System ⁴ Supported Windows 8, Windows 8 Pro, Windows 8 Enterprise (32bit, 64bit) Windows 10 (32bit, 64bit) Memory (RAM) ⁵ Minimum 2.0 GB Recommended 4.0 GB Storage Space (Disk) Minimum 50 GB Recommended 100 GB Disk Format NTFS Format Recommended Graphics Card Minimum 128 MB DirectX 9 Compatible Recommended 128 MB DirectX 9 Compatible Display Minimum 1024 x 768 16bit colour Recommended 1280 x 1024 32bit colour Widescreen Format Yes (minimum vertical resolution 800) Dual Monitor Yes Font Settings Only 96 DPI font settings are supported Explorer Internet Minimum Microsoft Internet Explorer 11 Network (LAN) Minimum 100 MB Ethernet (not required on standalone PC) Recommended
    [Show full text]
  • Enhancing the Accuracy of Synthetic File System Benchmarks Salam Farhat Nova Southeastern University, [email protected]
    Nova Southeastern University NSUWorks CEC Theses and Dissertations College of Engineering and Computing 2017 Enhancing the Accuracy of Synthetic File System Benchmarks Salam Farhat Nova Southeastern University, [email protected] This document is a product of extensive research conducted at the Nova Southeastern University College of Engineering and Computing. For more information on research and degree programs at the NSU College of Engineering and Computing, please click here. Follow this and additional works at: https://nsuworks.nova.edu/gscis_etd Part of the Computer Sciences Commons Share Feedback About This Item NSUWorks Citation Salam Farhat. 2017. Enhancing the Accuracy of Synthetic File System Benchmarks. Doctoral dissertation. Nova Southeastern University. Retrieved from NSUWorks, College of Engineering and Computing. (1003) https://nsuworks.nova.edu/gscis_etd/1003. This Dissertation is brought to you by the College of Engineering and Computing at NSUWorks. It has been accepted for inclusion in CEC Theses and Dissertations by an authorized administrator of NSUWorks. For more information, please contact [email protected]. Enhancing the Accuracy of Synthetic File System Benchmarks by Salam Farhat A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor in Philosophy in Computer Science College of Engineering and Computing Nova Southeastern University 2017 We hereby certify that this dissertation, submitted by Salam Farhat, conforms to acceptable standards and is fully adequate in scope and quality to fulfill the dissertation requirements for the degree of Doctor of Philosophy. _____________________________________________ ________________ Gregory E. Simco, Ph.D. Date Chairperson of Dissertation Committee _____________________________________________ ________________ Sumitra Mukherjee, Ph.D. Date Dissertation Committee Member _____________________________________________ ________________ Francisco J.
    [Show full text]
  • Active @ UNDELETE Users Guide | TOC | 2
    Active @ UNDELETE Users Guide | TOC | 2 Contents Legal Statement..................................................................................................4 Active@ UNDELETE Overview............................................................................. 5 Getting Started with Active@ UNDELETE........................................................... 6 Active@ UNDELETE Views And Windows......................................................................................6 Recovery Explorer View.................................................................................................... 7 Logical Drive Scan Result View.......................................................................................... 7 Physical Device Scan View................................................................................................ 8 Search Results View........................................................................................................10 Application Log...............................................................................................................11 Welcome View................................................................................................................11 Using Active@ UNDELETE Overview................................................................. 13 Recover deleted Files and Folders.............................................................................................. 14 Scan a Volume (Logical Drive) for deleted files..................................................................15
    [Show full text]
  • File Formats
    man pages section 4: File Formats Sun Microsystems, Inc. 4150 Network Circle Santa Clara, CA 95054 U.S.A. Part No: 817–3945–10 September 2004 Copyright 2004 Sun Microsystems, Inc. 4150 Network Circle, Santa Clara, CA 95054 U.S.A. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Third-party software, including font technology, is copyrighted and licensed from Sun suppliers. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, docs.sun.com, AnswerBook, AnswerBook2, and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. in the U.S. and other countries. Products bearing SPARC trademarks are based upon an architecture developed by Sun Microsystems, Inc. The OPEN LOOK and Sun™ Graphical User Interface was developed by Sun Microsystems, Inc. for its users and licensees. Sun acknowledges the pioneering efforts of Xerox in researching and developing the concept of visual or graphical user interfaces for the computer industry. Sun holds a non-exclusive license from Xerox to the Xerox Graphical User Interface, which license also covers Sun’s licensees who implement OPEN LOOK GUIs and otherwise comply with Sun’s written license agreements.
    [Show full text]
  • Mac OS X Server Administrator's Guide
    034-9285.S4AdminPDF 6/27/02 2:07 PM Page 1 Mac OS X Server Administrator’s Guide K Apple Computer, Inc. © 2002 Apple Computer, Inc. All rights reserved. Under the copyright laws, this publication may not be copied, in whole or in part, without the written consent of Apple. The Apple logo is a trademark of Apple Computer, Inc., registered in the U.S. and other countries. Use of the “keyboard” Apple logo (Option-Shift-K) for commercial purposes without the prior written consent of Apple may constitute trademark infringement and unfair competition in violation of federal and state laws. Apple, the Apple logo, AppleScript, AppleShare, AppleTalk, ColorSync, FireWire, Keychain, Mac, Macintosh, Power Macintosh, QuickTime, Sherlock, and WebObjects are trademarks of Apple Computer, Inc., registered in the U.S. and other countries. AirPort, Extensions Manager, Finder, iMac, and Power Mac are trademarks of Apple Computer, Inc. Adobe and PostScript are trademarks of Adobe Systems Incorporated. Java and all Java-based trademarks and logos are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. and other countries. Netscape Navigator is a trademark of Netscape Communications Corporation. RealAudio is a trademark of Progressive Networks, Inc. © 1995–2001 The Apache Group. All rights reserved. UNIX is a registered trademark in the United States and other countries, licensed exclusively through X/Open Company, Ltd. 062-9285/7-26-02 LL9285.Book Page 3 Tuesday, June 25, 2002 3:59 PM Contents Preface How to Use This Guide 39 What’s Included
    [Show full text]
  • Alias Manager 4
    CHAPTER 4 Alias Manager 4 This chapter describes how your application can use the Alias Manager to establish and resolve alias records, which are data structures that describe file system objects (that is, files, directories, and volumes). You create an alias record to take a “fingerprint” of a file system object, usually a file, that you might need to locate again later. You can store the alias record, instead of a file system specification, and then let the Alias Manager find the file again when it’s needed. The Alias Manager contains algorithms for locating files that have been moved, renamed, copied, or restored from backup. Note The Alias Manager lets you manage alias records. It does not directly manipulate Finder aliases, which the user creates and manages through the Finder. The chapter “Finder Interface” in Inside Macintosh: Macintosh Toolbox Essentials describes Finder aliases and ways to accommodate them in your application. ◆ The Alias Manager is available only in system software version 7.0 or later. Use the Gestalt function, described in the chapter “Gestalt Manager” of Inside Macintosh: Operating System Utilities, to determine whether the Alias Manager is present. Read this chapter if you want your application to create and resolve alias records. You might store an alias record, for example, to identify a customized dictionary from within a word-processing document. When the user runs a spelling checker on the document, your application can ask the Alias Manager to resolve the record to find the correct dictionary. 4 To use this chapter, you should be familiar with the File Manager’s conventions for Alias Manager identifying files, directories, and volumes, as described in the chapter “Introduction to File Management” in this book.
    [Show full text]
  • Cyber502x Computer Forensics
    CYBER502x Computer Forensics Unit 5: Windows File Systems CYBER 502x Computer Forensics | Yin Pan Basic concepts in Windows • Clusters • The basic storage unit of a disk • The piece of storage that an operating system can actually place data into • Different disk formats have different cluster sizes • Slack space • If they are not filled up-which, the last one almost never is –this excess capacity in the last cluster Old Data Old New Data Overwrites CYBER 502x Computer Forensics | Yin Pan What does a file system do? • Make a structure for an operating system to stores files • For you to access them by name, location, date, or other characteristic. • File System Format • The process of turning a partition into a recognizable file system CYBER 502x Computer Forensics | Yin Pan Windows File Systems • File Allocation Table (FAT) • FAT 12 • FAT 16 • FAT 32 • exFAT • NTFS, a file system for Windows NT/2K • NTFS4 • NTFS5 • ReFS, a file system for Windows Server 2012 CYBER 502x Computer Forensics | Yin Pan FAT File System Structure • The boot record • The File Allocation Tables • The root directory • The data area CYBER 502x Computer Forensics | Yin Pan Boot record • The first sector of a FAT12 or FAT16 volume • The first 3 sectors of a FAT 32 volume • Defines the volume, the offset of the other three areas • Contains boot program if it is bootable CYBER 502x Computer Forensics | Yin Pan FAT (File Allocation Table ) • A lookup table to see which cluster comes next • File Allocation Table for FAT 16 • One entry is 16 bits representing one cluster • Each entry can be • The cluster contains defective sectors (FFF7) • the address of the next cluster in the same file (A8F7) • a special value for "not allocated" (0000) • a special value for "this is the last cluster in the chain“ (FFFF) CYBER 502x Computer Forensics | Yin Pan Directory entry structure • Starting from the root directory.
    [Show full text]