The latest update to iOS Forensic Toolkit brought bootloader-level extraction to a bunch of old iPads, Apple TVs, and even the first-gen HomePod running OS versions 17 and 18. This enabled full file system and keychain extraction on a those older Apple devices that can still run these versions of the OS.
When an iPhone is seized and later re-examined, forensic teams sometimes find that data present in an earlier extraction are missing from a subsequent backup or filesystem image. Why exactly does that happen, what kinds of data are affected, how long do they usually live, and what can you do to preserve volatile and semi-volatile artifacts? Let’s try to find out.
Welcome to Part 5 of the Perfect Acquisition series! In case you missed the previous parts, please check them out for background information. This section provides a comprehensive guide to performing the Perfect APFS Acquisition procedure.
When it comes to digital evidence, most investigators naturally focus on smartphones – and occasionally tablets. But the rest of the Apple ecosystem often goes unnoticed: Apple Watch, Apple TV, HomePod, even older iPod Touch models. These supplementary devices might seem irrelevant, but they can contain valuable digital artifacts: activity logs, Wi‑Fi credentials, leftover bits and pieces of information, system logs, and even synced photos.
For a long time, the macOS version of iOS Forensic Toolkit remained the most feature-complete. Only macOS supported bootloader-level acquisition using checkm8, installation of the extraction agent with regular Apple IDs, and use of wireless adapters for Apple Watch analysis. All of these capabilities are now available in the Linux build as well, eliminating the need for a Mac in many workflows. This guide explains how to properly install and use EIFT on a Linux system.
With the release of iOS 17.3, Apple introduced a new security feature called “Stolen Device Protection.” This functionality is designed to prevent unauthorized access to sensitive data in cases where a thief has gained knowledge of an iPhone’s passcode. While this feature significantly enhances security for end users, it simultaneously creates substantial obstacles for digital forensic experts, complicating lawful data extraction.
Over the years, Apple has continuously refined its security mechanisms to deter unauthorized access to their devices. One of the most significant aspects of this evolution is the increasingly sophisticated passcode protection system in iOS devices. This article explores how the delay between failed passcode attempts has evolved over time, highlighting changes that have made iOS screen lock protection more secure.
Welcome to the world of mobile forensics, where extracting data is the first (and arguably the most critical) step. Whether you’re working with an ancient Apple device or attempting to break into the latest iPhone 16 Pro Max, there is a method for every gadget – each with its own share of challenges. We love explaining the differences between the extraction techniques, detailing their pros and contras, but sometimes you are limited to the one and only method that is the most likely to succeed.
In the realm of iOS device forensics, the use of the checkm8 exploit for low-level extractions has become a common practice. However, when using this method, you may occasionally need to remove the device’s screen lock passcode, which can lead to several undesirable consequences. In this article, we’ll study these consequences and learn when you need a screen lock reset, when it can be avoided, and how what the latest iOS Forensic Toolkit has to do with it.
iOS backup passwords are a frequent topic in our blog. We published numerous articles about these passwords, and we do realize it might be hard for a reader to get a clear picture from these scattered articles. This one publication is to rule them all. We’ll talk about what these passwords are, how they affect things, how to recover them, whether they can be reset, and whether you should bother. We’ll summarize years of research and provide specific recommendations for dealing with passwords.