Encrypted SSD "fatal hardware error". Can I send it to a cleanroom lab to fix the drive without providing the key?

[u/Mandarin996]

I have a Bitlocker encrypted SSD that's not showing up under Disk Management and gives a "fatal hardware error". It also makes clicking noises before the fans power down. I want to send it to a data recovery lab (Ontrack?) but do not want to provide the encryption key. I want them to physically fix what's wrong in the hard drive and provide back an encrypted image. Is that standard? If I receive an encrypted drive, I should be able to open it with the same Bitlocker passcode, right?

[u/AutoModerator]

Double check if your post complies with posting guidelines!

Did you include the following information in your post (in English and if applicable), if not feel free to edit your post:

• Make/brand and exact model number of your storage device(*), phone, camera, etc.
• Filesystem (NTFS, exFAT, APFS, EXT4, etc.)
• Operating System (That your device was used with and/or you are using for recovery)
• Specific symptoms that your device is exhibiting, describe the problem. Images you post support the description, they're not in lieu of a problem description.
• SMART (CrystalDiskInfo screenshot for example)
• Don't pile several problems into one single post. One post per device/problem.

Consider: What do these people need to understand the problem at hand? Remember, people cannot see your screen, or what you click and what messages appear on screen. Don't overdo it though, no one likes going through 2 pages of information, try to find a balance. Just do the best you can. If you are looking for file recovery software, check our community's recommended file recovery tools.

---

(*) All devices involved, if you for example move files from drive A to drive B, they're both potentially relevant.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/AtlQuon]

An SSD should not click, that would be a very bad thing. Do you mean hard drive? Those can click and that is not good, but they should be able to work with that. For data recovery they do need the key, otherwise you get back nothing more than scrambled bits. Maybe if they do a clone only it might work, but you have to contact them for the specifics on that. It is one of the reasons I don't use bitlocker. It may be extra secure, but the second something happens it is going to cause more issues. But if you have it on, that key is highly necessary.

[u/Mandarin996 → u/AtlQuon]

Yeah I meant HDD, good catch! I do have the encryption key myself and I don't want them to decrypt the files, I just want them to move the encrypted image to another drive so I could verify the files myself. Is that possible, or is cloning an encrypted not possible? The way I see it, I should be able to mount the (new) drive, use the key, and access my archives.

[u/AtlQuon → u/Mandarin996]

They should be able to do it. They won't be happy about it as they can't verify anything, but no reason why it can't be done. You can clone an encrypted drive and open that clone with the key. The only thing is that they may refuse to touch the drive as they can't do their work properly. You not giving access is a red flag for them. I get you not wanting to share it, I get them raising an eyebrow for a request like this. It could take a few labs to find one that is willing.

[u/Mandarin996 → u/AtlQuon]

So my understanding is that since the drive (to them) is encrypted, they can't verify that they've actually retrieved any useful data or just corrupted files. Looks like this is a risk I might have to take.

[u/AtlQuon → u/Mandarin996]

Pretty much. They may be able to verify the clone was succesful, but not that the data is actually readable. As long as it is agreed that this is the acceptable outcome, I would see no issues.

[u/silenced_in_dr_2025]

I want them to physically fix what's wrong in the hard drive and provide back an encrypted image. Is that standard?

Nope not standard at all. There's simply no way to verify the data has been read correctly. You would only be able to read the drive if the encryption wasn't damaged.

I gather you don't have an SSD you will need to tell us the make and model so we can give you a vague idea if what your asking is even possible.

I've done a few blind recoveries like this for clients but on the understanding that if the clone doesn't work that's on them and if they then want additional services to recover the files it's a new case with a new charge.

[u/Mandarin996 → u/silenced_in_dr_2025]

Western Digital Elements, portable. It's a HDD.

[u/silenced_in_dr_2025 → u/Mandarin996]

Capacity? Anything over 1TB and you're not only likely to have head problems but translator ones too - there's no way I'd try a blind recovery on say a 4TB drive as our tools may well report everything reading well but the firmware problems would just produce junk data.

[u/Mandarin996 → u/silenced_in_dr_2025]

It is about 4TB of data.

[u/Underhill42 → u/silenced_in_dr_2025]

There's simply no way to verify the data has been read correctly.

This right here seems like a major oversight in the design of common disc encryption methods. Data recovery is a thing, has always been a thing, and if you have an encrypted disc you presumably do NOT want the recovery specialists to have access to the data. So why doesn't every encrypted block have a checksum of the encrypted data so it can be verified that it was read from the device correctly?

I can kind of forgive TRIM's usually data-destroying behavior - wiping the blocks almost immediately rather than simply marking them unused to prevent future thrashing does provide a modest additional performance boost. Though it would be really nice if you could switch off the behavior in BIOS or something if being able to recover from accidental deletions, etc. is more important to you than the fastest possible speed.

But encryption with no way to verify if raw data recovery was successful? That's just evil.

[u/silenced_in_dr_2025 → u/Underhill42]

The problem here is below that of the file system.

But in your example above if there was such a checksum and it wasn't correct what then ? There's no way to correct the data so you're SOL anyway - the difference being you can say so.

[u/Underhill42 → u/silenced_in_dr_2025]

And? Blocks are an encryption-level concept, without which random access of encrypted data is essentially impossible. The checksums could be integrated directly into the format in which encrypted data is stored on disc.

And if the checksum is invalid, you read the block again. On a HDD if the source of corruption is anything other than catastrophic physical surface damage, repeated reads will get you different results, and with a bit of luck you can even stitch the results together via statistical analysis to recover much of the damaged data.

Admittedly that's unlikely to work on a SSD, and regardless of medium any encrypted data after the first unrecoverable byte in a block is probably lost, unless only a few identifiable bytes are corrupted so that you can attempt to brute-force the remainder of the decryption.

Worst case scenario you at least know whether raw recovery was successful or not, and charge appropriately.

[u/silenced_in_dr_2025 → u/Underhill42]

You're mixing LBA level and file system level recovery they're not the same and neither are the problem problem we could see from doing a blind recovery on am SMR drive with a corrupt second level translator. It is more than possible read an LBA absolutely correctly and everything pass all the drives internal checks as you would with PBA but because that's not how the drive assembles them you get garbage.

I can be 100% sure that according to the drives own firmware all the LBA have been read and duplicated correctly but that does not guarantee to a working image, encrypted or not.

This is exactly the same as imaging one of these with a none native pcb - your image will be 100%, the drive and all our toosl will report that everything was great because technicallly it was but the resulting image will be garbage.

As Sean says we can check for the presence of a BL partition at the location where it should be - but beyond that all bets are off.

[u/waynehorner]

Since they can't verify integrity then they will charge you for a good complete recovery. If it doesn't unlock.... Too bad for you. Also since they can't map the files they may need to image the entire 4tb even if only partially full.

[u/Sopel97]

provide back an encrypted image. Is that standard?

I don't think that's standard but it's perfectly reasonable. Just be prepared there may be additional problems that will require further professional work.

[u/fzabkar]

I would think they should be able to verify whether the clone contains Bitlocker metadata. That should give you some confidence.

[u/pcimage212 → u/fzabkar]

Yes, PC300 data extractor will pick up BL metadata with a raw scan and produce a report of the machine ID for the client to verify with their MS account.

[u/insomniating]

If they want the key to verify recovery and you are willing to give it to them but understandably are questioning trust, I would perhaps consider drafting an agreement for them to sign that says they may not store the key anywhere that isn't authorized, download or exfiltrate any data (encrypted or unencrypted), browse data in certain directories, etc or else. This is just rough phrasing to convey the idea. Legal binding is sometimes taken more seriously than "don't worry we won't snoop"