E-Book
116,99 €

File System Forensics E-Book

Fergus Toolan

0,0

116,99 €

Sammeln Sie Punkte in unserem Gutscheinprogramm und kaufen Sie E-Books und Hörbücher mit bis zu 100% Rabatt.
Mehr erfahren.

Herausgeber: John Wiley & Sons
Kategorie: Wissenschaft und neue Technologien
Sprache: Englisch

Beschreibung

Comprehensive forensic reference explaining how file systems function and how forensic tools might work on particular file systems

File System Forensics delivers comprehensive knowledge of how file systems function and, more importantly, how digital forensic tools might function in relation to specific file systems. It provides a step-by-step approach for file content and metadata recovery to allow the reader to manually recreate and validate results from file system forensic tools.

The book includes a supporting website that shares all of the data (i.e. sample file systems) used for demonstration in the text and provides teaching resources such as instructor guides, extra material, and more.

Written by a highly qualified associate professor and consultant in the field, File System Forensics includes information on:

The necessary concepts required to understand file system forensics for anyone with basic computing experience
File systems specific to Windows, Linux, and macOS, with coverage of FAT, ExFAT, and NTFS
Advanced topics such as deleted file recovery, fragmented file recovery, searching for particular files, links, checkpoints, snapshots, and RAID
Issues facing file system forensics today and various issues that might evolve in the field in the coming years

File System Forensics is an essential, up-to-date reference on the subject for graduate and senior undergraduate students in digital forensics, as well as digital forensic analysts and other law enforcement professionals.

Details

Sie lesen das E-Book in den Legimi-Apps auf:

Android

iOS

von Legimi
zertifizierten E-Readern

Seitenzahl: 868

Veröffentlichungsjahr: 2025

Bewertungen

0,0

Rezensionen(0 Rezensionen)

Leseprobe

Cover

Title Page

Dedication

Preface

Structure

Resources

Acknowledgements

Part I: Preliminaries

1 Introduction

1.1 What is Digital Forensics?

1.2 File System Forensics

1.3 Digital Forensic Principles

1.4 Digital Forensic Methodology

1.5 About This Book

1.6 Book Structure

1.7 Summary

Bibliography

Notes

2 Linux as a Forensic Platform

2.1 Open‐Source Software

2.2 Open‐Source Software in Digital Forensics

2.3 What is Linux?

2.4 Using Linux

2.5 Linux as a Forensic Platform

2.6 Summary

Bibliography

Notes

3 Mathematical Preliminaries

3.1 Bits and Bytes

3.2 Number Systems

3.3 Representing Text

3.4 Representing Time

3.5 Endianness and Raw Data

3.6 Summary

Bibliography

Notes

4 Disks, Partitions and File Systems

4.1 Disk Storage

4.2 Partitions

4.3 File Systems

4.4 Acquisition of File System Data

4.5 Analysis of File Systems

4.6 Summary

Bibliography

Notes

Part II: Windows File Systems

5 The FAT File System

5.1 On‐Disk Structures

5.2 Analysis of FAT32

5.3 FAT32 Advanced Analysis

5.4 Summary

Bibliography

Notes

6 The ExFAT File System

6.1 On‐Disk Structures

6.2 Analysis of ExFAT

6.3 ExFAT Advanced Analysis

6.4 Summary

Bibliography

Notes

7 The NTFS File System

7.1 On‐Disk Structures

7.2 Analysis of NTFS

7.3 NTFS Advanced Analysis

7.4 Summary

Bibliography

Notes

Part III: Linux File Systems

8 The EXT2 File System

8.1 On‐Disk Structures

8.2 Analysis of ext2

8.3 Ext2 Advanced Analysis

8.4 Summary

Bibliography

Notes

9 The EXT3/EXT4 File Systems

9.1 Supplied Image Files

9.2 The ext3 File System

9.3 The Ext4 File System

9.4 Summary

Bibliography

Notes

10 The XFS File System

10.1 On‐Disk Structures

10.2 Analysis of XFS

10.3 XFS Advanced Analysis

10.4 Summary

Bibliography

Notes

11 The Btrfs File System

11.1 On‐Disk Structures

11.2 Analysis of Btrfs

11.3 Btrfs Advanced Analysis

11.4 Summary

Bibliography

Notes

Part IV: Apple File Systems

12 The HFS+ File System

12.1 On‐Disk Structures

12.2 Analysis of HFS+

12.3 HFS+ Advanced Analysis

12.4 Summary

Bibliography

Notes

13 The APFS File System

13.1 On‐Disk Structures

13.2 Analysis of APFS

13.3 APFS Advanced Analysis

13.4 Summary

Bibliography

Notes

Part V: The Future

14 Future Challenges in Digital Forensics

14.1 Challenges in Digital Forensics

14.2 Where Do We Go from Here?

14.3 Summary

Bibliography

Notes

Index

End User License Agreement

List of Tables

Chapter 1

Table 1.1 Competing digital forensic methodologies. Similar phases are groupe...

Chapter 2

Table 2.1 A selection of the file systems supported in the Linux kernel. Note...

Table 2.2 Distro popularity based on Distro Watch page views (April 2024).

Chapter 3

Table 3.1 Group names for binary digits.

Table 3.2 Number of values for each of the common powers of two!

Table 3.3 Decimal/binary prefixes and values.

Table 3.4 Binary/hexadecimal conversion table.

Table 3.5 Converting a fixed‐point binary number to decimal.

Table 3.6 Calculating the value of the 12‐bit floating‐point binary number....

Table 3.7 ASCII table.

Table 3.8 ISO‐8859 variants.

Table 3.9 Interpretation of 0xE1 in all ISO‐8859 variants.

Table 3.10 UTF‐8 structure.

Table 3.11 Common epoch‐based time formats.

Table 3.12 Structure of the MBR partition table entry.

Chapter 4

Table 4.1 MBR partition table entry structure.

Table 4.2 MBR partition table entry structure for Listing 4.7.

Table 4.3 Selection of values for the file system type in the MBR partitionin...

Table 4.4 GPT header structure.

Table 4.5 GPT partition entry structure.

Table 4.6 A selection of commonly encountered partition‐type GUID values.

Table 4.7 General attribute values in GPT.

Table 4.8 Attribute values specific to the Microsoft Basic Data Partition.

Table 4.9 Comparison of the most common file systems.

Table 4.10 Timestamp availability in the common file systems.

Chapter 5

Table 5.1 Common FAT VBR structure.

Table 5.2 Extended FAT VBR structure (FAT32).

Table 5.3 The FSINFO structure.

Table 5.4 FAT generic directory entry structure.

Table 5.5 FAT flag values.

Table 5.6 FAT LFN directory entry structure.

Table 5.7 Supplied image files available from the book's website.

Table 5.8 Partially processed VBR from FAT32_V1.E01.

Table 5.9 Processed generic root directory entries in FAT32_V1.E01.

Chapter 6

Table 6.1 The structure of the exFAT main boot sector (sector 0).

Table 6.2 ExFAT directory entry types.

Table 6.3 The primary directory entry generic structure.

Table 6.4 The secondary directory entry generic structure.

Table 6.5 The allocation bitmap directory entry structure. The values are fro...

Table 6.6 The up‐case table directory entry structure. The values are from Li...

Table 6.7 The volume label directory entry structure. The values are from Lis...

Table 6.8 The file directory entry structure.

Table 6.9 The volume GUID directory entry structure.

Table 6.10 The stream extension directory entry structure.

Table 6.11 The filename extension directory entry structure.

Table 6.12 Supplied exFAT image files available from the book's website.

Table 6.13 Processing the main boot sector in ExFAT_V1.E01.

Table 6.14 The file directory entry for info.txt in ExFAT_V1.E01.

Table 6.15 The stream extension directory entry for info.txt in ExFAT_V1.E01. ...

Chapter 7

Table 7.1 Special files in NTFS.

Table 7.2 NTFS $Boot structure.

Table 7.3 MFT record header structure.

Table 7.4 Attribute header structure.

Table 7.5 Resident attribute header structure.

Table 7.6 Non‐resident attribute header structure.

Table 7.7 The attributes and their lengths from the MFT record in Listing 7.3...

Table 7.8 The $STANDARD_INFORMATION attribute structure.

Table 7.9 Flag values for the $STANDARD_INFORMATION attribute.

Table 7.10 $ATTRIBUTE_LIST structure.

Table 7.11 $FILENAME attribute structure.

Table 7.12 $OBJECT_ID attribute structure. Note that often in recent Windows ...

Table 7.13 $SECURITY_DESCRIPTOR attribute header structure.

Table 7.14 The Security ID (SID) structure.

Table 7.15 Access control list (ACL) structure.

Table 7.16 Access control entry (ACE) structure.

Table 7.17 Object specific access mask bits.

Table 7.18 Standard access mask bits.

Table 7.19 The $VOLUME_INFORMATION attribute structure. The values are from L...

Table 7.20 Flag values for the $VOLUME_INFORMATION attribute in NTFS.

Table 7.21 $INDEX_ROOT header structure with values from Listing 7.8.

Table 7.22 $INDEX_ROOT node header structure with values from Listing 7.8.

Table 7.23 The index record header structure.

Table 7.24 The structure of $REPARSE_POINT attribute.

Table 7.25 The structure of $REPARSE_POINT attribute.

Table 7.26 $EA_INFORMATION attribute structure.

Table 7.27 $EA attribute structure.

Table 7.28 NTFS disk images available from the book's website.

Table 7.29 Processed values from $Boot structure in NTFS_V1.E01.

Table 7.30 The attributes discovered in the MFT record for $MFT in NTFS_V1.E01

Table 7.31 Partially processed non‐resident attribute header structure in the...

Table 7.32 The attributes discovered in the MFT record for the root directory...

Table 7.33 Partially processed values for the $INDEX_ALLOCATION attribute in ...

Table 7.34 Processed index record header from Listing 7.18.

Table 7.35 Processed node header from Listing 7.18.

Table 7.36 Processed directory entries from Listing 7.18. Note that some valu...

Table 7.37 The processed MFT record header for info.txt in NTFS_V1.E01.

Table 7.38 The processed $STANDARD_INFORMATION attribute in info.txt in NTFS_V...

Table 7.39 The processed $FILENAME attribute in info.txt in NTFS_V1.E01.

Table 7.40 Non‐resident attribute header structure.

Table 7.41 Partially processed $AttrDef entry structure with values from List...

Table 7.42 Processing the alternate data stream in Listing 7.37. The offsets ...

Table 7.43 Processed attribute entries from Listing 7.42.

Chapter 8

Table 8.1 Comparison of ext file systems with traditional Windows file system...

Table 8.2 Block groups in ext that contain superblock structures.

Table 8.3 Superblock structure. Note that some values have been omitted.

Table 8.4 Compatible, incompatible and read‐only compatible features.

Table 8.5 Block group descriptor structure.

Table 8.6 Ext2 inode structure.

Table 8.7 Interpretation of the most significant nibble in the ext mode struc...

Table 8.8 Selection of inode flag values in various ext file systems.

Table 8.9 Disk images available from the book's website.

Table 8.10 Selected superblock values from Ext2_V1.E01.

Table 8.11 Partially processed BG0 descriptor from Listing 8.8.

Table 8.12 Partially processed root directory inode in Ext2_V1.E01.

Table 8.13 Root directory entry structure.

Table 8.14 Processed root directory entries.

Table 8.15 Possible file type field values in a root directory entry.

Chapter 9

Table 9.1 Ext3/4 disk images available from the book's website.

Table 9.2 Ext3 journal block header structure.

Table 9.3 Ext3 journal superblock version 1 structure.

Table 9.4 Ext3 journal superblock version 2 structure. The first 0x24 bytes a...

Table 9.5 Default journal descriptor block structure.

Table 9.6 Version 3 journal descriptor block structure.

Table 9.7 Processed entries from the Ext3_V1.E01 descriptor block (block numbe...

Table 9.8 HTree root node structure with interpreted values from Listing 9.12...

Table 9.9 Ext4 inode structure.

Table 9.10 The extent header structure in ext4.

Table 9.11 The extent leaf node structure in ext4.

Table 9.12 Processed extent tree from Listing 9.18.

Table 9.13 The ext4 extent index structure.

Table 9.14 Processed extents from Listing 9.21.

Table 9.15 Extended attribute structure. The values are from Listing 9.31.

Table 9.16 Extended attribute header block structure. The values are from Lis...

Table 9.17 Ext4 block group descriptor entry structure.

Chapter 10

Table 10.1 Structure of the XFS short form B+Tree.

Table 10.2 Structure of the XFS long form B+Tree.

Table 10.3 XFS superblock structure.

Table 10.4 XFS extended superblock structure (version 5).

Table 10.5 Expected superblock locations in an XFS file system with a block s...

Table 10.6 A selection of signature values used in the XFS file system.

Table 10.7 XFS inode core structure.

Table 10.8 Directory header structure.

Table 10.9 XFS directory entry structure.

Table 10.10 XFS image files used in this chapter.

Table 10.11 Extracted values from the superblock in XFS_V1.E01.

Table 10.12 Partially processed root directory inode in XFS_V1.E01.

Table 10.13 Processed directory entries in the root directory.

Table 10.14 Partially processed AG free block information structure. The valu...

Table 10.15 Processed short form tree header from the free space block number...

Table 10.16 Processed entries in Listing 10.11.

Table 10.17 AG Free list header structure with values from Listing 10.12.

Table 10.18 The inode information area. Values are from Listing 10.13.

Table 10.19 Processed inode B+Tree. from AG0 in XFS_V1.E01. Values are from Li...

Table 10.20 Inode B+Tree record structure. Processed values are from the reco...

Table 10.21 Extended attribute structures. Values are from Listing 10.18.

Table 10.22 Processed values from the log record header in Listing 10.24.

Table 10.23 Journal log operation header structure.

Table 10.24 Processed operation headers from Listing 10.26.

Table 10.25 Processed transaction header from Listing 10.26.

Table 10.26 Transaction types as found in the transaction header structure.

Table 10.27 Log item magic values.

Table 10.28 Buffer write operation structure. Values are taken from Listing 1...

Table 10.29 Processed operation headers from Listing 10.27.

Table 10.30 Processed inode update for operation.

Table 10.31 Possible values for fields in the inode update operation.

Chapter 11

Table 11.1 Btrfs file system limitations.

Table 11.2 Btrfs superblock structure.

Table 11.3 Btrfs B‐Tree node header structure.

Table 11.4 Leaf node key pointer structure.

Table 11.5 Internal node key pointer structure.

Table 11.6 Btrfs key structure.

Table 11.7 INODE_ITEM structure.

Table 11.8 INODE_REF structure.

Table 11.9 DIR_ITEM structure.

Table 11.10 EXTENT_DATA header structure.

Table 11.11 Subsequent data in EXTENT_DATA structure for a regular file.

Table 11.12 ROOT_ITEM structure.

Table 11.13 DEV_ITEM structure.

Table 11.14 CHUNK_ITEM structure.

Table 11.15 Btrfs time structure.

Table 11.16 Sample partial CHUNK_TREE for a single device file system.

Table 11.17 Summary of provided Btrfs image files.

Table 11.18 Partially processed superblock values for BtrFS_V1.E01.

Table 11.19 Processed key from first CHUNK_ARRAY item.

Table 11.20 Processed CHUNK_ITEM found in the CHUNK_ARRAY.

Table 11.21 Processed stripes from the CHUNK_ARRAY's CHUNK_ITEM.

Table 11.22 Processing of the four item pointers found in the CHUNK_TREE root...

Table 11.23 Partially processed DEV_ITEM from the CHUNK_TREE.

Table 11.24 Partially processed CHUNK_ITEMs from the CHUNK_TREE root node.

Table 11.25 Processed item pointers from the root node in Listing 11.14.

Table 11.26 Items discovered in the FS_TREE root node.

Table 11.27 OIDs and associated items in the FS_TREE.

Table 11.28 Processing of DIR_ITEMs in the FS_TREE root node.

Table 11.29 Processing of DIR_ITEMs in the FS_TREE belonging to OID 0x101.

Table 11.30 Partially processed INODE_ITEM for OID 0x105 ( sea.jpg).

Table 11.31 Processed EXTENT_DATA for OID 0x104.

Table 11.32 The extent structure for the EXTENT_DATA item in OID 0x105.

Table 11.33 Excerpts from the CHUNK_ITEMS in BtrFS_V2.E01. These excerpts prov...

Table 11.34 btrfs_root_backup structure.

Table 11.35 Logical and physical addresses from the second backup root struct...

Table 11.36 Values for the first three pointers in the FS_TREE root node.

Table 11.37 Processed stripes from superblock CHUNK_ARRAY.

Table 11.38 Partially processed DEV_ITEMs from both superblocks.

Table 11.39 The processed CHUNK_TREE for the RAID 1 file system.

Table 11.40 Values discovered in the ROOT_BACKREF item for sub1.

Chapter 12

Table 12.1 HFS+ file system limits.

Table 12.2 HFS+ reserved CNIDs.

Table 12.3 HFS+ fork structure.

Table 12.4 HFS+ extent descriptor structure.

Table 12.5 HFS+ volume header structure.

Table 12.6 HFS+ volume header attribute bit field values.

Table 12.7 HFS+ volume header structure (continued).

Table 12.8 HFS+ B‐Tree node descriptor.

Table 12.9 HFS+ B‐Tree header node structure.

Table 12.10 Catalog file key structure.

Table 12.11 Structure of the folder record data item in the catalog file.

Table 12.12 Structure of the file record data item in the catalog file.

Table 12.13 Structure of the thread record data item in the catalog file.

Table 12.14 HFS+ permission structure.

Table 12.15 Text encoding values.

Table 12.16 Extents overflow key structure.

Table 12.17 HFS+ Journal info block structure.

Table 12.18 The journal header structure.

Table 12.19 Supplied HFS+ disk images.

Table 12.20 Processed volume header in HFS_V1.E01.

Table 12.21 Processed values for the HFS+ catalog file fork in HFS_V1.E01.

Table 12.22 HFS+ Catalog file header node descriptor.

Table 12.23 HFS+ B‐Tree header record for the catalog file's header node in HF...

Table 12.24 Catalog file's root node descriptor in HFS_V1.E01.

Table 12.25 Processed keys in the HFS_V1.E01 catalog file's root node. Offsets...

Table 12.26 Partially processed catalog file record for the foggy.jpg file.

Table 12.27 Partially processed header record from the catalog file's header ...

Table 12.28 Keys from the two items in the root node with their pointer value...

Table 12.29 Processed extents for hills.jpg (CNID: ) in HFS_V4.E01.

Table 12.30 Partially processed header record from the extents overflow file'...

Table 12.31 Extents overflow file's key structure.

Table 12.32 Processed extents overflow keys from Listing 12.23.

Table 12.33 Processed extents from the data forks in Listing 12.23.

Chapter 13

Table 13.1 APFS object header structure.

Table 13.2 APFS B‐Tree node header structure.

Table 13.3 B‐Tree info structure.

Table 13.4 ToC entry structure for fixed length key value pairs.

Table 13.5 ToC entry structure when handling variable length keys and values.

Table 13.6 APFS container superblock structure.

Table 13.7 APFS volume superblock structure.

Table 13.8 The object map structure.

Table 13.9 Structure of the object map B‐Tree values.

Table 13.10 Object‐type codes for file system tree keys.

Table 13.11 APFS inode structure.

Table 13.12 Extended field information structure.

Table 13.13 Extended field data‐type values.

Table 13.14 Extended field data stream structure.

Table 13.15 Directory record structure.

Table 13.16 File extent value structure.

Table 13.17 Checkpoint mapping structure.

Table 13.18 Supplied APFS container images.

Table 13.19 Partially processed container superblock from APFS_V1.dd.

Table 13.20 Partially processed container object from Listing 13.3.

Table 13.21 Partially processed object and node headers of the object map B‐T...

Table 13.22 Partially processed B‐Tree information area from Listing 13.5.

Table 13.23 Partially processed VSB from Listing 13.8.

Table 13.24 Partially processed object and node headers from Listing 13.9.

Table 13.25 Processed ToC entries from Listing 13.10.

Table 13.26 Processed inode from Listing 13.15.

Table 13.27 Processed data stream extended attribute from Listing 13.16.

Table 13.28 The XID values in each of the container superblocks located in th...

Table 13.29 Contents of the volume object map located in block 0xC00 in APFS_V...

Table 13.30 Interpreted key/value pairs from Listing 13.25. Note that keys ha...

Table 13.31 The structure of the sibling link record with values from Listing...

Chapter 14

Table 14.1 Identified current and future challenges in file system forensics ...

List of Illustrations

Chapter 2

Figure 2.1 Interactions between the various layers in the Linux OS.

Figure 2.2 Logical view of Linux memory.

Figure 2.3 The Linux Mint desktop immediately after login.

Figure 2.4 The Linux Mint Menu showing the various application categories.

Figure 2.5 The Linux Mint terminal application.

Chapter 3

Figure 3.1 FAT date bit field structure.

Figure 3.2 FAT time bit field structure.

Figure 3.3 Raw binary data displayed using the xxd command.

Figure 3.4 Raw hexadecimal data displayed using the xxd command.

Figure 3.5 The in‐built calculator showing the conversion of a decimal numbe...

Chapter 4

Figure 4.1 A traditional HDD with the cover removed showing the internal str...

Figure 4.2 Platter structure showing the tracks, sectors and clusters.

Figure 4.3 A disk with five partitions created using a primary MBR and an ex...

Figure 4.4 GPT‐partitioned device structure.

Figure 4.5 Demonstrating slack space. (A) A file that occupies three cluster...

Figure 4.6 A sample B‐Tree structure.

Figure 4.7 Media handling preferences in nemo file explorer when automount i...

Figure 4.8 The guymager application showing two connected disks.

Chapter 5

Figure 5.1 The layout of the FAT file system.

Figure 5.2 The FAT date bit field structure.

Figure 5.3 The FAT time bit field structure.

Figure 5.4 The recovered CLIFFS.JPG file.

Chapter 6

Figure 6.1 The layout of the exFAT file system.

Figure 6.2 An example allocation bitmap (0xEF36) showing the binary values o...

Chapter 7

Figure 7.1 A sample B‐Tree structure showing the three nodes that are examin...

Figure 7.2 A sample B‐Tree structure with filenames as values. Similar to th...

Figure 7.3 An original NTFS metadata structure (top) and the same metadata s...

Figure 7.4 MFT record structure.

Figure 7.5 A sample run list. The first byte describes the structure which i...

Figure 7.6 The Access Mask bit field structure.

Figure 7.7 The relevant bitmap values for hills.jpg before file deletion.

Chapter 8

Figure 8.1 General layout of an ext volume.

Figure 8.2 Internal block group structure.

Figure 8.3 Block pointer structure.

Figure 8.4 BG0 structure in Ext2_V1.E01.

Figure 8.5 The extracted lake.jpg file.

Chapter 9

Figure 9.1 Ext journal structure.

Figure 9.2 HTree structure.

Figure 9.3 Flexible block group structure.

Figure 9.4 Incompatible features value 0x82C2 from Listing 9.36 showing the ...

Chapter 10

Figure 10.1 Allocation group structure.

Figure 10.2 Absolute address structure in XFS where is .

Figure 10.3 Absolute inode address structure in XFS where is and is ....

Figure 10.4 XFS inode structure.

Figure 10.5 XFS extent structure.

Figure 10.6 Contents of the recovered file sunrise.jpg.

Figure 10.7 The recovered tree.jpg file.

Chapter 11

Figure 11.1 Btrfs B‐Tree leaf node structure.

Figure 11.2 Btrfs B‐Tree internal node structure.

Figure 11.3 The recovered sea.jpg file.

Chapter 12

Figure 12.1 Structural overview of a HFS+ B‐Tree.

Figure 12.2 The recovered foggy.jpg file.

Figure 12.3 A HFS+ Catalog node before deletion (left) and after deletion (r...

Chapter 13

Figure 13.1 APFS container structure.

Figure 13.2 APFS B‐Tree structure.

Figure 13.3 APFS B‐Tree (root) node structure. ToC is the node's table of co...

Figure 13.4 Extended field structure.

Figure 13.5 APFS container structure showing the checkpoint descriptor and d...

Figure 13.6 The recovered Headland.jpg file.

Guide

Cover

Table of Contents

Title Page

Dedication

Preface

Acknowledgements

Begin Reading

Index

End User License Agreement

Pages

iii

xvii

xviii

xix

xxi

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

354

353

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

File System Forensics

Fergus Toolan

Norwegian Police University CollegeBallina, Tipperary

Published by John Wiley & Sons, Inc., Hoboken, New Jersey.

Published simultaneously in Canada.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per‐copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750‐8400, fax (978) 750‐4470, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748‐6011, fax (201) 748‐6008, or online at http://www.wiley.com/go/permission.

The manufacturer's authorized representative according to the EU General Product Safety Regulation is Wiley‐VCH GmbH, Boschstr. 12, 69469 Weinheim, Germany, e‐mail: [email protected].

Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates in the United States and other countries and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.

Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Further, readers should be aware that websites listed in this work may have changed or disappeared between when this work was written and when it is read. Neither the publisher nor authors shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.

For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762‐2974, outside the United States at (317) 572‐3993 or fax (317) 572‐4002.

Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic formats. For more information about Wiley products, visit our web site at www.wiley.com.

Library of Congress Cataloging‐in‐Publication Applied for:

Hardback ISBN: 9781394289790

Cover Design: Wiley

To Helen

Thanks for everything!

Preface

The prevalence of digital evidence in modern investigation has led to the need for more skilled analysts who can interpret digital evidence in a meaningful manner. Much digital evidence is stored in a file system and the correct recovery of this information is crucial to investigation. While there exist many tools that automate the recovery of data from file systems, there is a need for greater understanding of what these tools do. This allows the expert to verify the findings of file system forensic tools leading to greater trust in the recovered evidence.

The target audience of this title is anyone with an interest in digital investigation, who wishes to know how evidence is recovered from file systems. This includes University students taking modules or even entire programmes in the digital forensics and cybersecurity domains and law enforcement agents (or other investigators) who are tasked with recovering information from file systems and explaining its relevance. For both audiences the aim of this book is to provide an in‐depth understanding of how information is recovered from common file systems.

Structure

This book is organised in five distinct parts. Part I provides the preliminaries that all digital forensic experts require. Parts II–IV provide the technical meat of the title. These parts focus on the common file systems for each of the most popular operating systems (Windows, Linux and macOS). Part V discusses the future of file system forensics and what new (and some old) challenges are ahead for the discipline.

Part I, Preliminaries, begins with an introduction to digital forensics in general and discusses some of the principles that govern the area. This chapter also introduces the reader to digital forensic methodologies and how they are used to streamline investigation. Chapter 2 describes the Linux operating system and how it can be used for file system forensics. Throughout the remainder of the text the examples will be given using the Linux command line, but there is no requirement for readers to follow this. Chapter 2 provides an introduction to Linux for those that wish to use it going forward. For those who do not intend to use (or already use) it, this chapter can be skipped. Chapter 3 discusses the topic of information representation. Computers are capable of processing and storing only binary data (ones and zeros). How these ones and zeros are interpreted as meaningful information is of vital importance. This chapter shows how numbers, text and time are represented in computing systems and how we interpret the raw hex data that we will encounter during file system forensics. The final chapter in this part introduces the reader to disk storage, partitions and file systems. This chapter describes the common partitioning schemes in use today and shows how they can be located. It then introduces the file system and shows the various concepts that exist within this organisational structure. The chapter finishes with an introduction to disk acquisition – how we acquire the file systems that we will later process – and the analysis of these file systems.

Part II introduces the Windows family of file systems, although more accurately this might be called the Microsoft family. This includes FAT (Chapter 5), ExFAT (Chapter 6) and NTFS (Chapter 7). For many years FAT file system variants were the standard for removable media. While this is changing as ExFAT becomes dominant a large volume of devices with the FAT file system are still found during investigation. This, coupled with the relative simplicity of the FAT file system, means that it is an ideal choice for the first file system to be studied in this book. Subsequently the ExFAT file system is introduced. While some consider this to be another variant of the FAT file system, it is sufficiently more advanced to be deserving of its own chapter. This is the most common file system found on removable media today. Both FAT and ExFAT are supported by all major operating systems and, as such, can be found in many cases. The final Windows file system in this text is that of NTFS. The New Technology File System is the default on all Windows systems and as such is very commonly encountered in digital investigation.

Part III introduces the Linux file systems. This begins with the ext family of filesystems (Chapters 8 and 9). Many might wonder how important these chapters are as Linux is rarely encountered in digital investigation. However, these are some of the most important file systems in use today. The ext family are one of the default file systems found in Android phones, and as such, one of the most commonly encountered file systems in investigation. Knowledge of these file systems is of vital importance to all file system forensic investigators. File systems of the ext family are commonly encountered in many IoT devices. So while true to say that they are not commonly encountered in the home computer area, they are very important file systems for the analyst. This part of the book also introduces two less common Linux file systems: XFS (Chapter 10) and BtrFS (Chapter 11). These file systems are encountered in some Linux distributions, and are also found in large scale storage applications such as data centres. As device storage capacity increases these file systems will become more common in the home market.

Part IV examines the Apple file systems. For many years Apple devices utilised the HFS+ file system (Chapter 12). Since late 2017 Apple devices have begun to use the APFS file system (Chapter 13). This is a modern file system which can scale to modern device sizes in an efficient manner. Due to the popularlity of Apple devices (phones, tablets, computers etc.) this file system is encountered very frequently in modern digital investigation. The final part of this book looks to the future and in particular examines the challenges that will face the community over the next number of years.

Each file system chapter (Chapters 5–13) is organised in a similar manner. Initially a description of the general layout and the actual structures present in the file system is provided for each file system. This is followed by a manual analysis in which the reader can see all steps required to recover file content and metadata. Finally each chapter finishes with advanced topics for each file system. This always includes topics such as deleted and fragmented files along with topics specific to each file system.

Resources

Throughout this book example file systems are used to demonstrate the manual analysis and more advanced topics. Each file system generally has between three to five different image files that are used. All of this data is available to the user through the book's supporting website. This data can be found at: https://www.fsforensics.com/book.

Please email any corrections to me at [email protected].

Ireland, June 2024

Fergus Toolan

Acknowledgements

When I began this project I never realised how difficult it would be to complete. It would never have been completed without the support of many people. To everyone who had any part in this thank you all very much! There are some who must be mentioned directly!

Firstly those that proof read the document itself. Thank you! To my technical proof readers Ray Genoe, Alan Browne, Ivar Friheim and Ulf Bergum who between them checked the code listings and exercises in the book. Many thanks for that! My father Dónal read every single word of the manuscript and offered countless corrections and suggestions for improvement.

Many thanks to the editorial team at John Wiley & Sons Ltd. Victoria Bradshaw, Vishal Paduchuru, and Aileen Storry for all of your help throughout the publication process.

Over the years I have been very fortunate to work with some amazing people in the area of digital forensics. In my current role I am part of an amazing team of academics and law enforcement officers. Thanks to Carlota, Georgina, Nina, Rune, Sara and Ulf. Also past colleagues including Ray, Cormac, Gerry, Kurt‐Helge, Yves, Jørn Helge and Alexander. I thank the wonderful heads of the investigation section in the Norwegian Police University College: Ivar, John Ståle, Dag and Inger. All of you gave me the freedom to explore the topics that I was most interested in.

This book started as a resource for my students. I thank all of you that I taught over the years. Much of the information presented in this book is based on the challenging questions that you have asked me. Hopefully this book will answer some of them!

During my own formative years I had some wonderful teachers in University College Dublin. Special mention to Joe Carthy, John Dunnion, Nick Kushmerick and Henry McLoughlin. I would not have had the ability or the confidence to attempt this project without your inspirational teaching over the years.

This project would never have been completed without the constant belief and support of my family. Thanks to my parents, Dónal and Anna, who always encouraged me to pursue my dreams and supported me throughout.

Finally when I thought about giving up on this project, it was my partner Helen who encouraged me to keep going. She always believed that I could do this even on the days when I didn't believe that myself. Thank you!

Fergus Toolan

Part IPreliminaries

1Introduction

In recent years the volume of digital evidence in criminal investigations has increased dramatically. Consider the situation at the turn of the century when the standard computer was the desktop computer a device that resided on, as the name suggests, the desk. The majority of crime scenes did not involve a computer. When computers were involved they were generally relevant only in specific case types such as hacking/cybercrime; child abuse material; and fraud. Returning to the present, there is digital evidence in almost every case!1 The majority of people carry smartphones on their person at all times. Cars contain navigation, entertainment and camera systems. Homes and businesses have digital CCTV systems that run continuously. People communicate through social media. The end result for investigators2 is that there has been a vast increase in the quantity of digital evidence encountered during investigation.

Almost all data in electronic storage media is held in files. A file is an object on a computing device that stores data, information, settings or applications. Every document, picture, spreadsheet, database, etc. on a computer system is composed of one or more files. Every computer system therefore needs a method of managing files. This is generally achieved through the use of a file system. File systems exist on every electronic storage device and provide a method of locating the actual file's content and also provide information about the file itself. An ability to access these files is of vital importance during investigation.

Investigators have many tools at their disposal which allow them to access this information. However, these tools suffer certain limitations including:

Unsupported File Systems:

There are many different file systems in existence. File system forensic tools generally support only the most common file systems, those that are found on the most common operating systems. However, there are many more that are sometimes encountered during an investigation. These might be impossible to process without knowledge of how file systems function.

Undisclosed Methods:

Most file system forensic tools are closed source

meaning users are unable to see exactly what actions are being performed. A knowledge of file system structures will allow the investigator to show how data is stored in a file system and therefore show possible means of recovering said data. It also supports verification of the results of closed‐source tools.

Cost:

The majority of these tools are commercial tools with associated cost implications for users. Knowledge of how file systems function could ultimately allow an investigator to create their own tools.

Hence it is necessary that investigators understand the structures that are utilised by file systems. This not only allows the investigator to analyse file systems which are not supported by the current tool but also allows them to explain possible means by which these tools work. Digital forensic analysts are often considered ‘experts’ in their field. Knowledge of file systems and their underlying structures will allow these analysts to more validly claim this title and stand over the evidence generated by file system forensic tools.

1.1 What is Digital Forensics?

In recent years the term digital forensics has become more familiar to all, especially anyone involved in investigation. Digital evidence is seen in TV shows on a regular basis. Numerous jobs are available in many areas which require skills in digital forensics, from e‐discovery to incident response and cybersecurity. But what is digital forensics? That's a difficult question to answer!

There is no single accepted definition of digital forensics. In this section a number of definitions are presented and the common elements identified. This process will eventually culminate in the definition that is used throughout this book.

Interpol defines digital forensics as:

… a branch of forensic science that focuses on identifying, acquiring, processing, analysing, and reporting on data stored electronically.

Interpol (n.d.)

Lang et al define digital forensics as:

… the science of identifying, collecting, preserving, documenting, examining, analyzing and presenting evidence from computers, networks, and other electronic devices.

Lang et al. (2014)

Techopedia defines digital forensics as:

… the process of uncovering and interpreting electronic data. The goal of the process is to preserve any evidence in its most original form while performing a structured investigation by collecting, identifying and validating the digital information for the purpose of reconstructing past events.

Techopedia (n.d.)

These, and the many other definitions that can be found, all share some common traits. For instance all of them mention electronic devices/data. All evidence in digital forensics is generated from electronic traces. These traces may be found on storage media, in network traffic, online, etc. Hence digital forensics is forensic analysis performed on electronically stored/transmitted information. Additionally both Lang et al. (2014) and Interpol mention science. Digital forensics is a branch of forensic science and as such should be based on scientific principles.

All of the above definitions attempt to define the process that is followed. Many definitions use similar wording to describe these processes. For instance words such as identifying, collecting (or acquiring), preserving, presenting (or reporting) or analysing (or interpreting) are used in the majority of definitions.

Hence, for the purposes of this book the following definition will be adopted.

Digital forensics is the application of scientific principles to the identification, preservation, collection, analysis and presentation of evidence obtained from electronic media.

1.2 File System Forensics

File system forensics is a particular branch of digital forensics in which the electronic medium in question is the actual storage device (i.e. the disk). File systems are structures which organise information on disk. The file system is the structure that allows saved information to be retrieved at a later date. When a file is saved, not only is the content saved but information about the content (metadata) is also saved. This metadata provides much necessary information about the file content such as timestamps and file size, but also provides information on how to locate the content on disk.

Techopedia defines a file system as:

… a process that manages how and where data on a storage disk, typically a hard disk drive (HDD), is stored, accessed and managed. It is a logical disk component that manages a disk's internal operations as it relates to a computer and is abstract to a human user.

Techopedia (n.d.)

File system forensics therefore involves the application of the scientific method to identify, preserve, collect, analyse and present evidence recovered from a file system. In order to be able to perform these tasks the analyst (whether human or software) must fully understand the structures on which the file system in question is based. Different file systems result in very different structures and hence different analysis methods.

For instance compare two commonly encountered file systems in digital forensics: The File Allocation Table (FAT) and the new Apple File System (APFS). FAT is an old file system and in comparison to modern file systems such as APFS it is very simple. Generally older file systems allow for the storage/retrieval of information from them and very little else. FAT contains three structures that are of interest to forensic examiners (the volume boot record, the file allocation table and directory entries) meaning that only a small amount of knowledge is required to analyse this file system effectively. Now compare this to APFS. APFS is a modern file system. It provides much more functionality than an older system such as FAT. This includes encryption, snapshots, compression, etc. The underlying structures are inherently more complex meaning that this file system is much more difficult to examine effectively.

1.3 Digital Forensic Principles

The United Kingdom's Association of Chief Police Officers4 (ACPO) drafted the Good Practice Guide for Digital Evidence. Version 5 (released in 2012) is the latest version of this document. This document contains a set of four principles for the effective handling of digital evidence.

These ACPO principles, as they are often called, are based on the UK legal system and the rules of evidence in that system. However, the principles are almost universal and have been adopted in many countries over recent years. These principles are:

Principle 1:

No action taken by law enforcement agencies, persons employed within these agencies or their agents should change data which may subsequently be relied upon in court.

Principle 2:

In circumstances where a person finds it necessary to access original data, that person must be competent to do so and be able to give evidence explaining the relevance and the implications of their actions.

Principle 3:

An audit trail or other record of all processes applied to digital evidence should be created and preserved. An independent third party should be able to examine those processes and achieve the same result.

Principle 4:

The person in charge of the investigation has overall responsibility for ensuring that the law and these principles are adhered to.

These principles were originally drafted in the early days of digital evidence. At that stage most digital evidence resided on computer storage devices. The standard method was to power off the device, create an image and analyse that image. As the area of digital forensics has developed over the years this standard method of operation has also developed. Now it is no longer always advised to switch off the computer. Instead it is sometimes recommended to analyse running machines. Not all information is now stored locally, some will be stored remotely, even the crime scene itself may be remote. However, while some argue that the principles need to be updated, they are still fit for purpose.

The overall aim of these principles is to ensure that all digital evidence accessed during a criminal investigation is handled in such a manner that it can be used in court. Hence the first principle states that no changes should be made to the original data. The second principle ensures that only trained personnel will ever access original data and the third principle ensures that others will be able to recreate and validate the analysis of the evidential material. For traditional computer forensics these three principles are sufficient.

Now consider a modern scenario. First responders arrive at the home of a suspected cybercriminal. They use a warrant to enter the premises and seize all electronic evidence that is encountered. Upon entering the premises they discover a running computer. The traditional advice was to ‘pull‐the‐plug’; however, with modern computers this might lose evidence. Most modern operating systems allow options for encrypted storage. If power is removed the data on the device will become inaccessible due to its encryption. Additionally many users use remote storage resources for files, emails, profiles, etc. Connections to these sites (and potentially access to the data they contain) will be lost if the power is removed. Hence live data forensics (LDF) is conducted, in which the running computer is analysed to determine if there is anything of evidential value present.

Returning to ACPO Principle 1 which states ‘no action taken by law enforcement agencies … should change data which may subsequently be relied upon in court’. LDF immediately breaks this principle. Every action performed on a running computer system will leave traces in memory and on disk. Even the simple act of moving the mouse will have consequences, as it will change certain parts of the computer system. This has led to some researchers suggesting that the ACPO principles should be rewritten. However, they are still fit for purpose as while LDF breaks principle 1, combining this with principles 2 (competence) and 3 (audit trail), the altered data collected from the LDF process can still be used in a court setting.

1.4 Digital Forensic Methodology

From the early days of digital forensics it has long been recognised that there is no standard methodology for obtaining results. As, in an ideal world, digital forensics is ‘based on scientific principles’ it is necessary that there should be one agreed‐upon methodology.

Table 1.1 summarises the phases in a number of competing methodologies for digital forensics. These include O'Ciarduin's Extended Model of Cybercrime Investigation, the Digital Forensics Research Workshop Model, Reith Carr and Gunsch's model and the Nordic Computer Forensic Investigators model.5Table 1.1 presents each of these methodologies grouped to show similar phases.

Table 1.1 Competing digital forensic methodologies. Similar phases are grouped.

DFRWS

Reith, Carr, Gunsch

O'Ciarduin

NCFI

Identification

Awareness

Initiation

Preparation

Authorisation

Strategy Development

Authorisation

Planning

Notification

Identification

Localisation

Preservation

Collection

Acquisition

Transport

Storage

Examination

Processing

Analysis

Hypothesis

Analysis

Hypothesis Presentation

Hypothesis Proof

Presentation

Dissemination

Reporting

Decision

QA/Evaluation

Evidence Return

Combining the methodologies shown in Table 1.1 leads to the methodology that will be used throughout this book. This consists of eight phases: Preparation; Localisation/Preservation; Acquisition; Processing; Analysis; Reporting; Quality Assurance and Evidence Return. The following sections describe these phases of the proposed digital forensics methodology.

1.4.1 Preparation

The preparation phase consists of a number of tasks that must be completed in order for the digital forensic process to succeed. O'Ciarduin's extended model of cybercrime investigation subdivides this phase into four distinct phases. Common tasks in the preparation phase include:

Crime Identification:

Part of preparation involves identifying that a crime/incident has taken place and determining what laws have been broken. This will determine some of the hypotheses that will be developed in subsequent phases.

Authorisation:

Ensuring that the relevant parties have the correct authorisation to investigate/prosecute the crime in question. In certain jurisdictions the suspect must also be notified that the investigation is to take place.

Planning:

The investigation is planned at this stage. Necessary warrants must be obtained and initial roles are allocated to the investigative team.

Resource Allocation:

It is necessary to ensure that all relevant resources (hardware, software, personnel, etc.) are in place prior to commencing the investigation.

Training:

All members of the investigative team must have received all necessary training/education. This is directly related to the ACPO principles which require all agents handling original material to be competent to do so.

1.4.2 Localisation/Preservation

The purpose of this phase is to locate sources of potential digital evidence and to preserve these in such a way that they are not altered (or are altered as little as possible) so that they can be relied upon in court.

Traditionally this phase took place at a physical crime scene, for instance a house search. The first response team attempt to locate all sources of digital evidence at the scene. This might include traditional devices such as computers, tablets, smartphones and USB keys. It also includes less common items such as smart appliances, networking technology, vehicles and drones. In modern digital investigation the focus is shifting from the physical to the virtual. Hence localisation is also concerned with finding relevant online sources (open‐source intelligence – OSINT – gathering), log files and external sources of digital evidence such as CCTV and access logs.

Once sources of potential evidence are located the next part of this phase is to preserve them. Traditionally this involved pulling the plug and then bagging and tagging the physical device. With the advent of LDF this phase sometimes involves preserving a running computer by preventing it from locking or, if battery powered, from dying. With the modern networked age another vital step at this stage is to prevent remote access to the device as a person could remotely delete evidence from the device. In the online environment preservation is often more complex. Generally the potential evidence will not be present at the crime scene indeed it may exist in a different jurisdiction to that of the investigator. Preservation of these online items might be achieved through court orders. Preservation of external records such as call data records (CDR) can also be achieved through a court order.

1.4.3 Acquisition

Acquisition is the process where a forensically sound copy of the potential evidence is created. Once this step is completed there should never be a need to return to the original source. All of the subsequent stages should be performed on the copy. With electronic storage media this stage involves the creation of an image, an exact bit by bit copy, of a storage device. This means not only will the live files on the device be copied, but also deleted files, slack space, unallocated space, etc. These concepts will be explained in Chapter 4.

For online resources this phase involves the acquisition of a copy of the web resource. This can be done through a browser (using the save functionality) or by taking screenshots or videos of the site. In certain cases, acquisition can be performed by the site administrator and the resulting evidence files delivered to the investigator.

1.4.4 Processing

Processing involves getting the acquired evidence file ready for analysis by investigators. This is the phase in which file system forensic analysis resides. With a traditional electronic storage device processing involves extracting all live and deleted files from the image along with the unallocated space and slack space from the device. Processing involves carving in unallocated space to recover files which are no longer part of a file system (Section 4.5.2). This stage also involves processing certain artefacts that have been recovered. This might include rebuilding browser history, extracting individual chat messages from a database, expanding archive files and so forth. In the online environment processing involves the extraction of relevant components of the online artefact such as contacts, images, email addresses and comments.

The information generated by processing is passed to the analyst to determine if the information is relevant to the investigation and if that evidence supports or refutes the investigative hypotheses.

1.4.5 Analysis

The analysis phase of the digital forensic methodology requires knowledge of the actual case being investigated. In this stage investigative hypotheses are generated and the analyst uses the evidence provided by the processing phase to prove or disprove these hypotheses. This phase is very much dependent on the case in question.

1.4.6 Reporting

The dissemination of results is one of the most important stages in any investigation. This phase covers a multitude of reporting types. The most iconic is that of the final report which is submitted to the court. This document shows all the evidence that has been discovered throughout the investigation, the relevance of this evidence to the hypotheses under investigation and the methods used to recover the evidence.

However, this phase is much more than a mere final report. Many digital forensic methodologies are described in a linear fashion, implying that one phase follows another. This is not strictly speaking correct, no more so than in the case of reporting. Firstly it is not common to find only a single final report. Generally there will be reports made at the end of most phases of the methodology. For instance a report will be written in relation to localisation/preservation (the report about the crime scene search). Another report will be written about the acquisition process and another relating to processing. All of these intermediate reports will be used to help create the final report.

The dissemination of results involves more than written reports. There are other forms of dissemination of information that are vital to the correct application of the digital forensic methodology. One example of this is the use of contemporaneous notes. It is recommended that all actors in the digital forensic process maintain their own personal notes about the case and the tasks that are performed during the case. This can act as another aid to the creation of a final report but can also be used as an audit trail (ACPO 3) allowing third parties to recreate the actions of investigators.

A final part of this phase is that of internal presentation of results. The digital forensic process may involve multiple actors (first responders, analysts, investigators, etc.). It is necessary during the process to ensure that all parties are conversant with the actions that have been taken by other parties in the handling of digital evidence in the case. This type of reporting is often achieved through briefings throughout the investigation.

The final task in some instances is the presentation of evidence in court. Generally this presentation will be based on the final report and will be directed by the prosecution while subject to cross‐examination by the defence.

1.4.7 Quality Assurance

Tausende von E-Books und Hörbücher

Ihre Zahl wächst ständig und Sie haben eine Fixpreisgarantie.

Sie haben über uns geschrieben: