Book Image

Learning Python for Forensics

By : Chapin Bryce
Book Image

Learning Python for Forensics

By: Chapin Bryce

Overview of this book

This book will illustrate how and why you should learn Python to strengthen your analysis skills and efficiency as you creatively solve real-world problems through instruction-based tutorials. The tutorials use an interactive design, giving you experience of the development process so you gain a better understanding of what it means to be a forensic developer. Each chapter walks you through a forensic artifact and one or more methods to analyze the evidence. It also provides reasons why one method may be advantageous over another. We cover common digital forensics and incident response scenarios, with scripts that can be used to tackle case work in the field. Using built-in and community-sourced libraries, you will improve your problem solving skills with the addition of the Python scripting language. In addition, we provide resources for further exploration of each script so you can understand what further purposes Python can serve. With this knowledge, you can rapidly develop and deploy solutions to identify critical information and fine-tune your skill set as an examiner.
Table of Contents (24 chapters)
Learning Python for Forensics
Credits
About the Authors
Acknowledgments
About the Reviewer
www.PacktPub.com
Preface
Index

Forensic scripting best practices


Forensic best practices play a big part in what we do and, traditionally, refer to handling or acquiring evidence. However, we've designated some forensic best practices of our own when it comes to programming, as follows:

  • Do not modify original data you're working with and to that effect

  • Work on copies of the original data

  • Comment code

  • Validate your program's results

  • Maintain extensive logging

  • Return output in an easy-to-analyze or understand format

The golden rule of forensics: do not modify the original data. Always work on a forensic copy or through a write-blocker. However, this may not be an option for other disciplines such as for incident responders where the parameters and scope varies.

In these cases, it is important to consider what the code does and how it might interact with the system at runtime. What kind of footprint does the code leave behind? Could it inadvertently destroy artifacts or references to them? Has the program been validated in similar...