The moment an encrypted disk lands on the bench, the entire nature of a recovery job changes. For years in our lab in Ankara, we have rebuilt ext4 filesystem trees, desoldered and read NAND chips by hand, and pulled sectors one by one from a drive with stuck heads. All of those cases share one thing: the data exists in readable form, and our job is to extract it. But when a disk is encrypted with FileVault or LUKS, there is no readable data sitting there. Without the correct key, every sector is just bytes that look statistically random. In this article we will explain, from an engineer's point of view, how FileVault encryption works on Macs and how LUKS/dm-crypt works on Linux, why losing a password or a key usually means losing your data permanently, and how a physically failing encrypted drive differs from a healthy but locked one.

Let us state the hard truth first, because in this trade honesty matters more than making a sale. Modern, properly configured strong encryption cannot be broken without the key. Any firm that claims otherwise is either lying or quietly running a dictionary attack against an already weak password. Trying to brute-force the master key of a volume encrypted with AES-256-XTS would take many times longer than the age of the universe. So the golden rule of encrypted disk recovery can be stated in a single sentence: you must have the correct password, the recovery key, or a backed-up header. What we do is recover that encrypted data safely off a drive that has failed, become corrupted, or partially unreadable, while the key is in your hands, and bring it to a state where you can open it with your key.

Second, encrypted disk recovery must never be confused with password cracking. We do not crack passwords. We recover data that you legitimately own and for which you hold the key, when a physical or logical fault has made it inaccessible. This distinction is critical both legally and technically. Below we will examine both encryption ecosystems in depth and make clear exactly what is possible in each situation.

Quick Answer

To recover data from an encrypted disk, you absolutely need the correct password, the recovery key, or a backed-up encryption header. If you have the key and the problem is a physical or logical fault (bad sectors, a failed controller, a wiped partition table, a damaged filesystem), the job is usually recoverable: we first take a bit-for-bit sector copy (image) of the drive, then all work happens on that image, and finally the encrypted volume is opened with your key. But if you have lost the password or recovery key, especially on Apple Silicon (M1, M2, M3) Macs, the data is practically unrecoverable, because the key is bound to the hardware Secure Enclave. On LUKS, if the header is wiped and no header backup exists, the master key is gone and the data is mathematically unrecoverable. Physical repair and unlocking the encrypted volume are two separate steps, and recovery succeeds when both are possible.

How FileVault Works on Modern Macs

FileVault is Apple's full-disk encryption solution for macOS. On modern Macs, meaning T2-equipped Intel Macs and Apple Silicon (M1 and later) machines, FileVault is built on top of the native volume encryption of the APFS filesystem. The critical point to understand here is this: in APFS, encryption is applied at the filesystem layer, per volume, and the encryption keys are managed by a hardware security engine.

The system works with the following layered key architecture. Every encrypted APFS volume uses a Volume Encryption Key (VEK) that encrypts the actual data. This VEK is not encrypted directly by the password. Instead the VEK is wrapped by a Key Encryption Key (KEK). The KEK in turn is protected by a key derived from the user's password together with keys coming from the secure elements in the hardware. So your password alone does not open the data; your password combines with keys embedded in the hardware to unlock the KEK, the KEK unwraps the VEK, and the VEK decrypts the data. Every link in this chain matters.

On T2-equipped Intel Macs, all of these operations are performed by the hardware AES engine inside the T2 Security Chip. Data is encrypted and decrypted on the fly as it is written to and read from the SSD; the AES keys never leave the chip in plaintext. On Apple Silicon Macs, the Secure Enclave takes on the same role. The Secure Enclave is a separate co-processor isolated from the main processor, with its own secure boot chain and persistent key storage. A device-specific UID (Unique ID) key is fused into the Secure Enclave during manufacturing and can never, under any circumstances, be read out. Because the FileVault key wrapping chain is bound to this UID, the encrypted data cannot be opened without that specific logic board, that specific Secure Enclave.

This is exactly where the reason losing the password or recovery key is catastrophic on Apple Silicon Macs becomes clear. The chain that opens the data is bound to the hardware, and because the key fragments from that hardware never leave it, decrypting that data on another computer or in a lab is simply not possible. If the logic board physically dies, the device-specific key fragments die together with the Secure Enclave. We covered deeper technical details of this architecture in our article on MacBook and Apple Silicon data recovery.

FileVault on Older Intel Macs and the Differences

On Intel Macs that predate the T2 chip, roughly before 2017, the situation is somewhat different. These machines do not have a dedicated hardware security chip, and encryption is done entirely in the software layer, with CoreStorage or, on older systems, HFS+ based FileVault 2. Here the master key is wrapped with a key derived from the user's password through a key derivation function such as PBKDF2, and stored on the disk itself, in a metadata area.

The practical consequence of this architecture is the following: on older Intel Macs, you can pull the encrypted SSD or HDD out of the machine, connect it to another system, and open the volume with the correct password or recovery key, because opening it does not require a key bound to specific hardware. The key material sits on the disk itself, protected by the password. This means that from a physically failed older Intel Mac, we have a chance to remove the disk, image it in the lab, and then open it with the password.

Even so, the golden rule does not change: you must know the password or the 28-character recovery key. Even on older Intel Macs, if the password is lost and there is no recovery key, brute-forcing an AES-XTS encrypted master key is practically impossible. The only difference is that, thanks to the absence of a hardware dependency, when the key is in your hands we can process the disk independently of the machine. On modern Apple Silicon machines this flexibility disappears entirely.

LUKS and dm-crypt Architecture on Linux

In the Linux world, the standard for full-disk encryption is LUKS (Linux Unified Key Setup). LUKS is a key management layer that sits on top of the kernel's dm-crypt subsystem. dm-crypt provides transparent block-level encryption through device-mapper; it takes a block device and creates a virtual decrypting block device on top of it. LUKS standardizes the key management, password handling, and metadata side of this work.

The heart of LUKS is the LUKS header located at the start of the encrypted volume. This header holds everything needed to open the volume: the cipher algorithm and mode in use (for example aes-xts-plain64), the parameters of the key derivation function (PBKDF2 in LUKS1, Argon2id by default in LUKS2), the salt values, and most critically the key slots. LUKS1 typically has 8 key slots, LUKS2 has more.

The most important concept to grasp here is this: the key that actually encrypts the data is the master key (the volume key in LUKS2 terminology). This master key is not produced directly from the user's password. Instead the master key is generated randomly and stored, encrypted, in each key slot with the key derived from that slot's password. So you can define different passwords in different slots on the same encrypted volume; every password opens an encrypted copy of the same master key. When you delete a password, only that slot is cleared; the master key and the other slots are unaffected.

This architecture makes changing passwords and granting access to multiple users easy. But the same architecture also explains why the header is so vital. The master key exists only inside the key slots in the header, in encrypted form. If the header is corrupted, overwritten, or wiped, the encrypted copies of the master key are gone with it. Even if you know your password perfectly, there is no slot left to open, so you cannot recover the master key, and the data in the rest of the volume becomes permanently inaccessible. We detailed Linux server and filesystem-level recovery scenarios in our ext4, btrfs, and LVM article.

Why a Damaged or Wiped LUKS Header Is Catastrophic

Loss of the LUKS header is one of the most painful scenarios we encounter in encrypted disk recovery, because it is often irreversible. Let us list the common mistakes that destroy a header, because avoiding them is frequently more valuable than recovering the data.

The most common mistake we see is the user writing to the wrong device. For example, when creating a new partition, formatting, or writing an ISO image to the wrong disk with dd, the first few megabytes of the device hosting the LUKS volume get overwritten. Because the LUKS header, and especially the binary metadata areas in LUKS2, sit at the very start of the disk, any overwrite of the first few MB wrecks the key slots. The second common mistake is shifting offsets while recreating a partition table, which makes the LUKS start point be miscalculated.

Another dangerous situation is, on a physically failing disk, the sectors precisely in that header region becoming unreadable. The first sectors of a disk, being the most frequently accessed region, are also at risk of wear and bad sectors. If even a few bytes of the key slot data in the header become unreadable, the master key cannot be decrypted from that slot.

This is exactly why there is one piece of advice we repeat constantly to every experienced Linux user and system administrator: take a header backup with the cryptsetup luksHeaderBackup command and store that backup somewhere safe, outside the volume. This small backup file contains the encrypted copies of the master key. Even if the header is destroyed on the physical disk, if you have the header backup and your password, we can reopen the data with luksHeaderRestore. Without a header backup, a wiped LUKS header means certain data loss in most cases. Also remember that you must keep this backup at least as confidential as your password, because it contains the encrypted form of the master key.

Healthy but Locked versus a Physically Failing Encrypted Drive

In encrypted disk recovery, we split the cases that come in on day one into two, and this distinction determines the entire work strategy.

The first situation: the disk is physically healthy and merely locked. The user has forgotten the password, lost the recovery key, or the operating system will not boot, but the disk reads perfectly at the hardware level. In this scenario there is no physical recovery procedure. The only thing that can be done depends on whether you have the correct key. If the key exists, the volume is opened normally and the data is copied. If the key does not exist, as we have said many times, there is no technical method that will open strong modern encryption. Here we have to be honest: without the password, a healthy but locked disk is just as inaccessible as a broken one.

The second situation: the disk is physically or logically faulty. There are bad sectors, the controller board is burned, the head assembly is damaged, there are read errors on the NAND chip, or the partition table and filesystem are corrupted. In this scenario the nature of the work is entirely engineering. But there is a critical rule here, and we never bend it: first take a bit-for-bit copy of the disk, and always work on the copy.

Image First, Then Work on the Image

This rule is far more critical for encrypted disks than for ordinary ones, and the reason lies in the nature of encryption. In an encrypted volume, every bit matters. On a normal filesystem, if a sector is unreadable, only the single file in that sector is damaged and the rest of the data stays intact. But in a volume encrypted with modes like XTS, the integrity of blocks affects the decryption chain; and more importantly, even a single-bit error in the header or key slot region can render the entire volume unopenable.

For this reason, when dealing with a physically failing encrypted disk, attempting to unlock the original drive directly is a serious mistake. Unlock attempts, password-try writes, and running filesystem check tools can further exhaust an already weak disk and lead to losing the last sectors that were still readable. Our method is clear. First we stabilize the disk at the hardware level; if necessary we repair it in a clean room environment. Then, with error-tolerant imaging hardware, we extract a bit-for-bit sector copy of the disk. For unreadable sectors we read again and again with different strategies and map the unreadable regions precisely.

Once we have this image in hand, the physical disk is safe and goes back on the shelf. All decryption and filesystem repair work is then done on a copy of the image, in a way that can be retried and undone. If the user gives us the correct password or recovery key, we open the LUKS image with cryptsetup, and the FileVault image with the appropriate tools, through a loop device, and reach the decrypted data. From there it is classic filesystem recovery work. You can see the scope of all our encrypted recovery services on the services page.

Corruption of the Encryption Header and Partial Recovery

The header is not always entirely destroyed; sometimes it is only partially corrupted. In that case there are things we can do, and these are the most technical part of encrypted recovery.

In LUKS, part of the header may remain readable. If the volume contains a secondary metadata copy on the same disk, even without a header backup (LUKS2 keeps the header metadata redundantly in two copies), recovery from the uncorrupted copy can be attempted. The most valuable scenario for us is when the user has previously taken a backup with luksHeaderBackup; in that case our chance of opening it on the image, by replacing the corrupted header with the intact backup, is very high.

On the FileVault and APFS side, when the metadata structures of the encrypted volume are corrupted, the checkpoint architecture of APFS and redundant super block copies sometimes allow recovery. But here too the fundamental key chain must be intact; repairing metadata does not regenerate the key.

In VeraCrypt and similar container-based solutions, the concept of a header backup is the same, and VeraCrypt usually keeps an embedded backup header. We examined a specific case of such container corruption in our article on VeraCrypt encrypted container recovery. In the Windows BitLocker scenario, the concept of a recovery key and the role of the recovery key are quite similar to FileVault; we detailed this in our article on BitLocker encrypted disk recovery. The common point that never changes across all of these systems is that recovery depends on the existence of the key material.

Confidentiality and the Limit of Recovery Without the Key

When an encrypted disk comes to us, the data on it is by definition extremely sensitive, because people encrypt their most valuable data. That is why confidentiality is not a technical detail for us but the foundation of the work. The password, recovery key, or header backup you bring us is used only for the recovery operation, destroyed in a controlled manner once the job is done, and never shared with third parties.

And finally, let us state once more, clearly, the truth we have repeated throughout this article. If you do not have your password, your recovery key, and your header backup, there is no way to open modern strong encryption. AES-256, when correctly implemented, cannot be broken in any reasonable time even with all the computing power in the world. If the key is locked to the hardware on an Apple Silicon Mac and that hardware is dead, there is no data. If the LUKS header was wiped without a backup, there is no master key, and therefore no data. We will not mislead you or sell false hope. Our expertise is recovering data that you cannot access due to a fault while you still hold the key, exhausting every technical avenue that is possible when the key exists. If your encrypted disk has failed and you still hold your key, the chance that it is still recoverable is high.

FAQ

I lost both my FileVault password and recovery key. Can you recover the data on my Apple Silicon Mac? Let us be plain: no. On Apple Silicon (M1, M2, M3) Macs, the FileVault encryption keys are bound to the hardware inside the Secure Enclave, and if both the password and the recovery key are gone, there is no way left to open the data. This is not a lack of tools or expertise; it is a direct consequence of mathematics and hardware security. The only hope for your data is to find the password or the 28-character recovery key somewhere. We also recommend checking the recovery key you may have stored in your Apple ID via iCloud.

My LUKS header was wiped but I still know my password. Can the data be recovered? This depends on whether you have a header backup. If you previously took a backup with cryptsetup luksHeaderBackup, that backup, together with your password, contains the encrypted copy of the master key, and recovery is very likely possible. But without a header backup, knowing the password is unfortunately not enough, because the password can only open the master key from the key slots inside the header. If the slots are wiped, there is nothing left to open, and the data is mathematically unrecoverable.

My encrypted disk is physically faulty but I have my password. Do I have a chance? Yes, this is one of the most hopeful scenarios. Physical failure and decryption are two separate steps. First we stabilize the disk at the hardware level and extract a bit-for-bit sector copy (image), so the failing disk is not worn down any further. Then, with the correct password or recovery key you provide, we open the encrypted volume on the image. If the readable portion of the disk is sufficient and the header region is intact, recovery completes successfully. For this reason, never attempt to unlock or repair a faulty encrypted disk yourself, you may make things worse.

Can you crack my password, this is really important data? No, we do not and cannot offer password-cracking services. Breaking modern strong encryption without the key is technically impossible; stay away from anyone who claims they can. What we do is recover data that you legitimately own and for which you hold the key, when a hardware or software fault has made it inaccessible. If you do not have the key, our honest answer is to tell you that recovery is not possible; we will not string you along.

Is my encrypted data safe with you, and how do you ensure confidentiality? Confidentiality is the foundation of the work for us. The password, recovery key, and header backup you provide are used only during the recovery operation and only for that purpose. When the job is complete, this sensitive key material is destroyed in a controlled manner. Your recovered data is never shared with third parties, never copied to an external network, and securely wiped from the lab environment after delivery. We know that the data of customers who bring us encrypted disks is by its nature of the highest sensitivity, and we have designed our processes accordingly.

Conclusion

Encrypted disk recovery is a fundamentally different discipline from classic data recovery, because at its center sits not hardware or the filesystem but key management. FileVault's hardware key architecture, bound to Apple Silicon and the T2 chip, and the LUKS structure that stores the master key in slots inside the header both point to the same fundamental truth: your data can only be opened with the correct key material. Our expertise is overcoming any physical or logical fault that gets in the way while that key is in your hands, imaging the disk safely, and bringing the encrypted volume to a state where it can be safely opened. We will never declare a case impossible while you hold the key; nor will we sell you false hope when you do not.

If your encrypted disk has failed, will not open, or its header is corrupted, the right first step is to contact us before doing anything. Especially if you still hold your password or recovery key, avoid trial unlock attempts that could worsen the situation, and bring the disk as it is. Since 2003, in our lab at Ankara Hacettepe Teknokent, we have handled thousands of recovery cases, both encrypted and unencrypted. To assess your situation together and offer an honest preliminary analysis, reach us through the contact page.

References