APFS Encrypted File Recovery: Keybags, AES-XTS, and Historical Metadata
How encrypted APFS deleted file recovery works: unlock the volume key, decrypt metadata and extents, then recover deleted files from checkpoints, snapshots, and OMAP history.
APFS Encrypted File Recovery: Keybags, AES-XTS, and Historical Metadata
Encrypted APFS recovery has two jobs. First, the volume must be unlocked so APFS metadata and file extents can be read as plaintext. Second, the recovery workflow searches APFS historical metadata for deleted-file candidates and exports their data by extents.
This article explains the model used by Ed Recovery for encrypted APFS volumes when the user provides the correct passphrase.
Related language version: 中文：APFS 加密盘删除文件还原.
Short Answer
An encrypted APFS disk cannot be scanned reliably as raw plaintext. The recovery tool first uses the passphrase and APFS keybag records to unlock the volume master key. After that, encrypted metadata and file data can be decrypted and processed through the same historical APFS recovery strategy used for regular volumes.
Why Encrypted APFS Needs an Unlock Step
On a regular APFS volume, filesystem metadata can be parsed directly. On an encrypted APFS volume, important metadata blocks and file extents are stored as ciphertext. Without the right key, the scanner sees random-looking bytes.
Apple's Apple Platform Security documentation is the best public starting point for Apple's security model. Apple's archived Apple File System Guide is useful background for APFS concepts such as snapshots and copy-on-write metadata.
Unlock Stage
The user passphrase is not used directly as the file-data encryption key. It unlocks APFS key material. The result is a volume master key that can decrypt APFS blocks.
Important details:
- If the passphrase is wrong, the volume master key cannot be obtained.
- The unlocked key is used only for the active scan and recovery path.
- Recovery logs should not include the passphrase.
- A live encrypted disk can still change while being scanned, so imaging is safer for long work.
Metadata Scan Stage
Once the encrypted volume is unlocked, the scanner follows the same high-confidence APFS recovery model: build a current baseline, parse older metadata views, compare the two, and report files that disappeared.
The historical sources are the same APFS structures used for regular recovery:
- Checkpoints.
- Snapshots.
- OMAP root history.
- OMAP transaction history.
- Optional carved metadata nodes.
The difference is that each encrypted metadata read must be decrypted before it can be interpreted as an APFS tree node or file record.
Recovery Stage
When the user selects a candidate, the recovery workflow returns to the historical view associated with that candidate. It locates the file object, reads the extent list, decrypts encrypted physical blocks, and writes plaintext output.
Why Crypto Position Matters
Encrypted APFS file extents need both location information and decryption-position information. The physical block tells the tool where to read. The crypto identifier tells the tool how to position AES-XTS decryption for that file range.
If the passphrase is correct but the wrong historical view or wrong crypto position is used, the output can still be unreadable.
Encrypted Deep Scan
Encrypted deep scan is useful when the normal historical file listing is incomplete. Instead of blindly scanning ciphertext, it decrypts candidate metadata and extents first, then checks for known file signatures and file-size boundaries.
Deep-scan candidates usually include:
- Historical xid.
- Object id.
- Logical offset.
- Candidate size.
- Detected file type.
- Partial status.
Regular APFS vs. Encrypted APFS
Regular APFS mainly depends on whether historical metadata and old data blocks still exist. Encrypted APFS has the same dependency, but adds one more requirement: the correct passphrase must be available.
Practical Recommendations
- Confirm that the selected APFS volume is encrypted.
- Validate the passphrase before a long scan.
- Recover to another physical disk.
- Start with historical metadata scanning.
- Use encrypted deep scan when the normal scan does not find the target.
- Do not store passphrases in support reports or logs.
Sources and Further Reading
- Apple: Apple Platform Security.
- Apple: Apple File System Guide.
FAQ
Can encrypted APFS recovery work without the passphrase?
Not for metadata-based recovery. The scanner needs the correct key to decrypt APFS metadata and file extents.
Does encryption prevent deleted-file recovery?
Encryption does not remove the APFS history model, but it requires a successful unlock before historical metadata can be parsed.
Why can decrypted recovery still fail?
Even with the right passphrase, old metadata or data blocks may have been overwritten.