Full File System Extraction (FFS)

A full file system (FFS) extraction copies the device's file system as the running operating system sees it: /data with every app sandbox, system databases in /data/system, and usually shared storage. Because the copy is made through the live OS, files come out already decrypted by the device's own file-based encryption keys, which is why FFS has largely replaced physical imaging for modern phones.

Reaching it needs code running with high privileges on the handset, obtained in one of three ways:

• Root: an already rooted device, or a root method the examiner can justify. Unlocking the bootloader to root a phone wipes userdata on modern devices, so it is not an option for existing evidence.
• Exploit: a vulnerability in the boot chain, the kernel or a system service, typically packaged in commercial tools for specific chipsets and patch levels.
• Agent: an app installed by the extraction tool that gains temporary elevated privileges through an exploit, collects, then removes itself.

The output is usually a tar or zip archive rather than a partition image, so there is no unallocated space, but deleted records inside SQLite files (freelist pages, WAL frames) are preserved. What an FFS reaches still depends on the lock state: CE storage only after the first unlock. Document the method, tool version, device patch level and what the agent changed on the device. Compare with logical, ADB backup and bugreport collection in Android acquisition methods.