IaccidentlydeletetheEFScertificatein "Personal"certificatefor one of my encrypted folder. I did not
export thecertificatebefore and did not delegate a
recovery agent. Right now I could not open the files
within it because I do not have permissions. How stupid i
Is there any way to solve this serious problem?
Just faced exactly the same problem a week ago. It took me around tree
of the days solve it, but I studied a lot.
Of course, the aefsdr tool from Elcomsoft worked like a charm for me,
but my files where not so important to pay $100 for them (the tool is
not free and decrypts only first few bytes of the files in demo mode).
On the other side â€“ if they can do it, why I canâ€™t? It was a
It seems to me that I googled everything about the topic. I tried
different approaches â€“ nothing really helped. But eventually I found
the sure and simple way to do this. Here are general guidelines.
First, it should be noted, that certificate deletion procedure does
not delete the correspondent private key it was signed with (from
Crypto\RSA folder). So having private key â€“ you can everything.
Without private key even aefsdr wonâ€™t help if it wonâ€™t be able to find
them by scanning the disc by sectors.
Ok, here are the guidelines (or rather story).
MS provides makecert utility to generate certificates. Among others,
this cute util can utilize the specified private key (if it already
exist). Each key have its unique storage name (which you specify to
makecert also). This name is stored inside the key file (in RSA
folder, open one of them and see yourself, first recognizable ASCII
bytes). So with makecert you can generate new certificate with your
old private key. Here the important note: it should be done from the
user account who owns the key â€“ since it is encrypted there (in RSA
folder storage) with the user password/master key/whatever.
After this the idea is to force the system to use the newly generated
certificate. It took me a while to understand how it works and
eventually I invented the trick for this.
During file decryption, the system use certificateâ€™s fingerprint from
fileâ€™s DDF (so called Data Decryption Field, if I recall correctly)to
locate the correspondent certificate and its private key to decrypt
the FEK (File Encryption Key) which is actually used for synch algos
file encryption/decryption. See http://www.tar.hu/wininternals/ch12lev1sec8..html,
the key sentence for me there was this one â€“ â€œOnly the private/public
key pair certificate hash is used by the description process.â€ Iâ€™m not
sure whether it is kind of secret information, but I failed to find
any other place in the Net which could tell this.
Ok. So how to do this? How to change this hash of all the files?
Windows do now provide any API to edit such kind of file attributes
(at least I failed to find). But what Windows do provide â€“ it is
ReadEncryptedFileRaw and WriteEncryptedFileRaw API which reads and
writes files data along with theirs security descriptors. And these
routines are utilized by standard backup utility. After fighting tree
days with this it was my latest idea to try to edit backup and restore
files from it with new certificate fingerprints. If this wounâ€™t work â€“
I was ready to gave up then already. But voila â€“ luckily, it appeared
to be working.
There was also another minor story for how to edit the large binary
file. I tried a number of different HexEditors (http://
en.wikipedia.org/wiki/Comparison_of_hex_editors) but eventually
decided to write my own trivial utility (I called it hexrep, Hex
Replacer), which successfully solved the task (with mmap syscall). But
it is not so important for the topic.
So by now you might got the main idea of how to do this: generate new
certificate with makecert using the old private key, backup the files,
tweak backup, juggle the fingerprint bytes there, restore files from
backup with the fingerprint of newly generated certificate.
For detailed questions feel free to write to me personally (though Iâ€™m
not promise to reply instantly).