How to decrypt files without the EFS Certificate

On 14 Бер 2005, 18:25, "Springna"
wrote:
Hello,

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
am...

Is there any way to solve this serious problem?

Thanks!


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
challenge.

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.

Regards!

For detailed questions feel free to write to me personally (though I’m
not promise to reply instantly).

Andriy

forgot to mention original thread. here -
http://groups.google.com.ua/group/mi...f0a061b920b921

"ant" wrote in message
...

[...]

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.

[...]

I believe that the point there was that the field itself contained only a
hash, not actually a key. If I'm understanding it correctly, it is a hash
that identifies a certificate that contains a key needed to decrypt the key
needed to decrypt the data.

On 20 Сер, 18:12, "FromTheRafters" erratic @nomail.afraid.org wrote:

I believe that the point there was that the field itself contained only a
hash, not actually a key. If I'm understanding it correctly, it is a hash
that identifies a certificate that contains a key needed to decrypt the key
needed to decrypt the data.

Not exactly. Certificate do not contain the private key by itself
(which is actually used to decrypt the FEK), but it has a reference to
it.

On 20 Сер, 20:13, ant wrote:
On 20 Сер, 18:12, "FromTheRafters" erratic @nomail.afraid..org wrote:

I believe that the point there was that the field itself contained only a
hash, not actually a key. If I'm understanding it correctly, it is a hash
that identifies a certificate that contains a key needed to decrypt the key
needed to decrypt the data.

Not exactly. Certificate do not contain the private key by itself
(which is actually used to decrypt the FEK), but it has a reference to
it.

One more important note to this. FEK is encrypted by public key which
is stored in certificate, but decrypted by correspondent private key.
That's how Windows allows several users (if they are in the authorized
list for the file) to read encrypted file without need for the
password of the file owner. The file stores the list of encrypted FEK
in its DDF (along with correspondent certificates fingerprints) for
each authorized user in the list. So any user from the list can
decrypt FEK with its own private key.

Regards,
Andriy