Access ESET Encrypted Drive

[Skier 7]

Following a catastrophic hardware failure with my computer, I have built another.  All my data is stored on a separate drive and is intact (and backed-up).  On this Data drive I have an ESET Encrypted Drive that worked perfectly when setup and used on the old machine.  However, in the new machine when double-clicking on it I am asked to select an app to open the file with and I'm then taken to the ESET Program Files folder with lots of exe, dll etc. files.  Which file should this eed file be associated with?  I know the password but there's no way to enter it on a new installation for an Encrypted Dive created on an old installation.  I do not want to lose the files within.

[Marcos 5,082]

Did you encrypt a removable drive or created an encrypted virtual drive (a file with the eed extension)?

Do you have Secure Data enabled in ESET Smart Security Premium?

[Skier 7]

I created an encrypted virtual drive with an eed extension as described above.  Yes, I have Secure Data enabled.

To be clear the virtual encrypted drive was created on an M2 SSD in the failed computer.  The M2 SSD is now installed in a newly built computer with a fresh installation of ESET Smart Security Premium, which has Secure data enabled.

[Marcos 5,082]

Do you have the eed extension associated with Secure Data? I assume that disabling and re-enabling Secure Data would reinstate the association.

[Skier 7]

The default app for the eed file is set to ESET Secure Data BUT this is only because I have had to navigate the ESET Program Files folder and select this exe file.   IT IS NOT shown as an 'app' that is available.  Hence asking which executable (or other) file should I associate the eed file type with.

Edited November 4, 2023 by Skier

[itman 1,662]

My take on this is if Eset can recognize the encrypted drive per below;

Quote

To access the encrypted drive after restarting the computer, locate the encrypted drive file (.eed file type) you created and double-click it. If prompted, type the password you configured when creating the encrypted drive. The drive will be mounted and appear as a local disk under This PC. When the encrypted drive is mounted as a local disk, the local disk and its decrypted content are available to other users on your computer unless you log out or restart the computer.

https://help.eset.com/essp/16.1/en-US/enc_intro.html?enc_encrypted_virtual_drive.html

you're "good to go."

Recognition would be if Eset prompts for the password. The "gotcha" is since the password was created on another device, will Eset recognize this password on the new device?

Edited November 4, 2023 by itman

[Skier 7]

@itman.  Yep, I've read that and the 'if prompted' doesn't happen.  I have found no way to enter the password to decrypt the drive.

 

In searching for a solution I can find quite a few requests of a similar nature with no resolution.  This is an occurrence i.e. an Encrypted Drive on a drive as part of a system that has failed, where the owner knows the password but can't access the drive when installed in a new system.  It is, IMHO, a major oversight and one only apparent when a major system failure occurs.

Edited November 5, 2023 by Skier

[itman 1,662]

14 hours ago, Skier said:

@itman.  Yep, I've read that and the 'if prompted' doesn't happen.  I have found no way to enter the password to decrypt the drive.

ESSP Secure Data option is not a full encryption solution as exists in Eset commercial products.

It is set up primarily to encrypt removable drives. My guess here is Eset stores the decryption password somewhere on the removable drive.

"My gut is telling me" Eset never anticipated your scenario; using an Eset encrypted non-boot internal HDD in another Windows system.

Another possibility here is the SSD is either damaged or malfunctioning in some way. Did you run chkdsk on that drive? Better yet, the drive manufacturer test tool?  You mentioned a catastrophic hardware failure with your old computer. It is within the realm of possibilities that could have impacted this SDD.

Edited November 5, 2023 by itman

[Skier 7]

@itman.  The catastrophic failure appears to be connected with the interface to the M2 SSD slot in which I had the boot SSD, which is also trashed; I've purchased a new one for the new Intel NUC.  A known good M2 SSD was not recognised in the suspect slot.  The data M2 SSD is fine and passes all checks..........that take an age as it's 8TB and I'm very thankful for as it was expensive.

To clarify, I haven't encrypted the whole of the M2 SSD, I've only created an encrypted folder on this drive.

[itman 1,662]

Let's "take it from the top" again starting with the very first statement in Eset Secure Data FAQ;

Quote

ESET Secure Data is a new feature available in ESET Smart Security Premium that enables you to create encrypted directories on removable drives to protect against data theft in the event of USB flash drive or laptop loss.

https://support.eset.com/en/kb6266-eset-secure-data-faq#deleteVD

Next is when reviewing Eset product on-line help in regards to Secure Data processing are the repeated references to removable drives,

My take here is Eset never fully designed Secure Data to be deployed on internal HDDs. It does so by creation of a virtual hard drive. My assumption is VHD's are directly linked to the device OS where created. Installing the SSD on a new device/OS no longer has an Eset VHD relationship. Did you create a new Secure Data VHD on the new device specifying this SSD as the source? Also, this might not work in that all that is created is a new empty .eed encrypted folder for the new VHD on the new device I assume.

Also if you exported Eset settings prior to the old system crash that contained Secure Data settings and imported those settings after ESSP installation on the new system, the VHD might have been auto created w/o issue. But again, I am not sure this would have worked.

In any case, I believe you need to create a support request for this one.

-EDIT- Pondering a bit more.

The problem here is a way to replace the newly created empty .eed folder associated with the new Secure Data VHD on the new device with the old existing .eed folder created on your old device. This I have no clue on how to do or even if this is possible.
 

Edited November 5, 2023 by itman

[Marcos 5,082]

You could try to uninstall ESET Smart Security Premium, install it from scratch and enable Secure Data. Alternatively you can change the product, e.g. to ESET NOD32 Antivirus, change it back to ESET Smart Security Premium, reboot the machine and enable Secure Data. The eed file should open also on other machines with ESET and Secure Data enabled after entering a correct password.

[Skier 7]

I have effectively done that as this is a new build machine.  I installed windows on Friday evening and spent much of the weekend installing and setting up all other applications.

To emphasise, again: I have Secure Data enabled, I know the password for the encrypted dive but I can't get ESET to offer a prompt where I can enter it.  What exe file should the .eed file type be associated with?  If I can get an answer to that question I may be able to progress.

I have raised a Support ticket for this issue: CASE_00661136

[itman 1,662]

4 hours ago, Skier said:

To emphasise, again: I have Secure Data enabled

Pondering more, there is another possibility here and your not going to like it.

First, a clarification of what the .eed file is. It appears to be the Secure Data executable file. The file is used to access Eset encrypted data on a created VHD or removable drive.

When your old device crashed, so did the VHD and any data on it. Unless you backed up that data to external media prior to the crash, I am afraid it is lost. Or if your very lucky, the data still physically exist on the SDD. But I see nothing in the Eset Secure Data documentation this is the case. Also if the Eset encrypted files from the old system still exist on the SDD, there is no documented procedure on how to link those files to the new Eset VHD created on the new system.

Now if you instead had created Secure Data removable media drive, Eset would have created the data on that drive permanently. This is why it can be accessed again when Eset is reinstalled either on the existing device or a new device.

Edited November 6, 2023 by itman

[Skier 7]

The .eed file/folder is the extension of the wrapper created using ESET Secure Data.  The files within it are still there in some form or other as the folder size is reported as 24MB which is what I'd expect.  All i need is to get ESET SS Premium to offer a prompt to enter the password to access the files and then I will move them.  Hard drive failures are a normal part of computer usage and ownership and I'm struggling to understand why ESET hasn't considered this use case.

 

The current instruction from the tech advisor as a result of submitting the support ticket is to uninstall and reinstall ESET.  That will have to wait until later.

[Skier 7]

1 hour ago, Skier said:

The current instruction from the tech advisor as a result of submitting the support ticket is to uninstall and reinstall ESET.  That will have to wait until later.

The uninstall/reinstall made no difference.

[Marcos 5,082]

Are you able to open a newly created eed file if you create a new encrypted virtual drive?

[Skier 7]

Yes I am, however, I cannot then open it as when double-clicking on it I receive the same error message - see image.  I believe this is because in trying to associate an executable file to the .eed file/folder I have created a problem.  Hence my repeated question here and in the support ticket; When double clicking an .eed file which .exe file is supposed to be invoked?

[itman 1,662]

To get to the bottom of this, here's what I did pain in the butt it is.

I activated Secure Data and created a virtual encrypted drive on a non-boot HDD I have installed. Verified I could access it via password and that the drive loaded into Win Explorer.

I then exported my existing Eset settings.

I then uninstalled ESSP. While the uninstaller was running, I saw Secure Data roll by. Oh-oh. Sure enough, when ESSP was uninstalled, all traces of the previously created VHD were wiped from the HDD it was previously installed on. I will continue, but this in itself is enough to state that any VHD created by Secure Data option is 100% dependent upon the current Eset installation.

I then reinstalled ESSP and imported my previously exported settings. Secure Data was still showing as never setup after settings import completed.

"I again say to thee", yes the OP new system shows that an existing old installation VHD exists on his non-boot SDD. But as far as his current ESSP installation on the new system is concerned, this VHD doesn't exist. It is in effect an "orphaned" VHD. Unless Eset developers can come up with a way to associated this old VHD with the current ESSP installation, it will remain inaccessible.

Edited November 6, 2023 by itman

[itman 1,662]

Some further info on why encrypted VHD recovery might be "an effort in futility."

From a May, 2023 Secure Data forum posting;

Quote

ESSP Secure Data creates an encryption 'keystore' file called 'premiumkey.dat' in C:\Users\USERNAME\AppData\Local\DESlock+\

If you delete this directory and the files within, then the encryption key is no longer available and your encrypted USB cannot be decrypted or accessed. Re-installing ESSP and enabling Secure Data will generate a new keystore file, which will NOT work for anything encrypted with a different key.

If we're lucky, and you still have the directories and files you deleted in the Recycle Bin, then you should be able to restore them and access your USB stick! If not, perhaps you have a Windows backup that you can restore where the DESlock+ directory and files are intact and can be restored to regain access to your USB.

Failing this, the data on the USB is inaccessible and you will need to format the device for future use.

https://forum.eset.com/topic/36474-eset-encrypted-drive-error-authenticating-or-mounting-encrypted-virtual-drive-error-code-0xc00f000c/?do=findComment&comment=167214

I checked for this same folder on my device and it does exist. So it appears it is also created when a VHD drive is created.

Since the OP installed a new boot SSD and reinstalled Windows, this original Secure Data keystore folder no longer exists. Therefore even if it was somehow possible to associated the old VHD .eed file with the current Eset Secure Data installation, it would be impossible to decrypt those files. If there was a full backup of the old boot SSD taken prior to drive failure, it might be possible to restore the keystore folder from that.

Finally, Deslock+ documentation clearly states the this "keystore" folder needs to be backup to external media for just this event occurance; something Eset documentation is silent on.

Edited November 7, 2023 by itman

[Marcos 5,082]

The issue is being dealt with via a support ticket. Since the thread here has become convoluted, developers have asked us to close it here and keep the communication within the support ticket. Once resolved, we or Skier could post an update here.