Win7 Desencriptar Carpeta en Windows XP

sarcoleto dijo:

Haga la facil, inicie con un live cd de linux (te recomiendo el live cd de (KX)ubuntu dapper, e instalaes el ntfs-3g, accedes a la caroeta y copias todos los datos a otra parte y listo!!!

Haz clic para expandir...

EFS nos da un encriptación segura de la información. La encriptación es tan segura, que si perdemos la clave para desencriptar los datos, la información. estará irremediablemente perdida. Windows XP no tiene una "puerta trasera" si la clave se pierde.

Inocentemente podemos perder la clave por varios motivos:

* Por ejemplo, manipulando en la caja de dialogo de Certificados o en la consola de Certificados (certmgr.msc) podemos sin querer, borrar el certificado de encriptación.

* Podemos tener, por ejemplo, los datos almacenados en carpetas encriptadas en un segundo volumen (disco D:, por ejemplo). E imaginemos que decidimos por problemas reinstalar Windows. Formateamos C:\ e instalamos. Por desgracia, en cada instalación de Windows, aunque los nombre y claves de usuario sean las mismas, Windows crea un nuevo identificador de seguridad (SID) para cada usuario. Por tanto, las claves de encriptación y el certificado de seguridad, serán diferentes al ser nuevo el SID del usuario. En este caso, o tenemos copia de los certificados anteriores, o habremos perdido también irremediablemente la información. encriptada en nuestro segundo disco duro (D.

Con un poco de cuidado, estos escenarios tan dramáticos pueden prevenirse. Para ello, sigamos los siguientes pasos (por primera vez):

1) Creamos una carpeta vacía, y le colocamos los atributos de encriptada.

2) Creamos o guardamos cualquier fichero de texto en dicha carpeta. Esto encriptará un archivo por primera vez.

3) Si nuestra máquina no es parte de un Dominio, creamos un agente de recuperación. Una segunda cuenta de usuario podrá ser usada con este agente para desencriptar los ficheros. Veremos más adelante como crear este agente de recuperación.

4) Guardamos el certificado de agente de recuperación. y el certificado personal de encriptación (en un disquete, por ejemplo y a salvo de terceras personas). Este último certificado no se creará hasta que hayamos realizado la primera encriptación, por ello es por lo que hemos realizado, por primera y única vez, los pasos 1) y 2).

5) Ahora ya podemos empezar a encriptar los datos sensibles.

Haz clic para expandir...

en consecuencia

EFS nos proporciona una vía segura para almacenar datos sensibles. Usa una clave pública para crear una clave de encriptación aleatoriamente generada (FEK). Este proceso se realiza transparentemente para el usuario. Windows, automáticamente encripta los datos usando esta FEK cuando los datos se escriben a disco. Estos datos pueden ser sólo desencriptados con su certificado y su clave privada asociada, la cual sólo está disponible haciendo "logon" con el usuario / password que lo encriptó. Si otros usuarios intentan usar uno de estos archivos encriptados, recibirán un mensaje de "acceso denegado".

Se pueden encriptar archivos o carpetas. Se recomienda encriptar carpetas en lugar de archivos individuales, ya que cualquier archivo que guardemos en dicha carpeta se encriptará automáticamente Y esto último, incluye también archivos temporales que una aplicación pueda escribir en dichas carpetas, ya que, por ejemplo Office, escribe una copia temporal de los documentos que estemos abriendo en la carpeta en donde resida el documento. Si la carpeta está encriptada, estos temporales también lo estarán y no corremos peligro de que por una caída de la aplicación queden archivos temporales con datos sensibles sin encriptar. Por esta razón se debe considerar también el encriptar la carpeta %temp% y %tmp% del usuario.

Lo mismo que el proceso de encriptación, la desencriptación se realiza transparentemente para el usuario. Por ello, la manera de trabajar con ficheros encriptados es la misma que con ficheros no encriptados: no tenemos que hacer nada. Cuando Windows detecta que un fichero está encriptado, simplemente busca el certificado y usa la clave privada para desencriptar los datos. Es transparente, por tanto, a las aplicaciones.

Haz clic para expandir...

recovery with the orginal profile not in the file system

it is _highly_ recommended to mount the disk containing the volume with the orginal install on as slave on a second machine as your recovery activities may overwrite the key data. - if you are using a laptop, get a 2.5" to 3.5" ide cable. avoid all data writes to the orginal volume.

you will need a decent hex editor (winhex recommended) and filemon from sysinternals or equivalent.

first some key pieces of information need to be optained from the encrypted files themselves. you can either jump on the ntfs to the efs header or (recommended) use ntbackup to backup one of the encrypted files you cannot access. open the backup with a hex editor and scroll down untill you see something like this.




green = the machine sid and usernumber in hex
fd374240 f094c85f 16c0ea32 eb030000 -> reverse
404237fd 5fc894f0 32eac016 000003eb -> convert to decimal
1078081533-1606980848-854245398-1003 -> prefix with s-1-5-21- for full sid/userno.

red = the public key thumbprint
79B73C0C5A501E06B9EC0A6EF4A3B8CB23BF84E9 - this is the filename of the public key

blue = the private key guid - this section maynot be present if other users have been added.
aqui voy... ¿QUE ES LO QUE DEBO SEGUIR HACIENDO?

now to search the orginal volume for the data of the two critical files - the private key and the locking file.

within the private key the guid(blue) is stored, the difference between the efs header is that it is stored in ascii, not unicode. if the private key guid was not present in the efs header you can search for "cryptoapi private key" in unicode, some results maynot be the correct ones, but this will be obvious on sight. the private key should look some thing like this. recover and name "privatekey" for now.

note well - if you do not find this private key, this method will not work and specialist methods must be used.




blue = private key guid - mentioned before
cyan = the locking file name and also mentioned within.
9f7479dc ea80 924a b41f 6392c4e3b72d -> some reversing
dc79749f-80ea-4a92-b41f-6392c4e3b72d

do a search for this string in unicode. the locking file should look something like this. recover and name as pictured in cyan in ascii.

note well again - if you do not find this locking file, this method will not work and specialist methods must be used.




cyan = the locking file name - mentioned before
yellow = a hex string required for the credhist file
dc42a7eeac5b104481336024113992ff - as is.

if you have just successfully recovered these two pieces of data, things are looking very good!! no further data needs to be recovered from the orginal install.

create a file called credhist so it looks like this:




yellow = as is, taken from the locking file - mentioned before

create a file called preferred so it looks like this:




on the second installation that you are running, encypyt a file so that you create a set of efs keys. copy out the public key from c:\documents and settings\foo\application data\microsoft\systemcertificates\my\certificates\ and rename to the public key thumbprint mentioned in the efs header - mentioned before. open in the hex editor and update the following sections.




blue = private key guid - mentioned before
red = public key thumbprint - mentioned before

follow the method "recovery with the orginal profile in the file system" detailed in the previous section and place the files into their correct locations. reboot.

c:\documents and settings\foo\application data\microsoft\

\crypto\rsa\s-1-5-21-1078081533-1606980848-854245398-1003\privatekey
\protect\credhist
\protect\s-1-5-21-1078081533-1606980848-854245398-1003\ (2files)
dc42a7eeac5b104481336024113992ff
preferred
\systemcertificates\my\certificates\79b73c0c5a501e06b9ec0a6ef4a3b8cb23bf84e9

the privatekey needs the correct name, this is determined from the private key guid by some unknown hashing process, however filemon can record the system request and thus the correct file name can be resolved. run filemon and simply select one of the encrypted files, stop filemon and apply a highlighting filter of "file not found" scroll up untill you see highlight entry by the process lsass. you should see the complete folder name request with the correct file name - something like this: bb1c31a261eed4c09b0a92ad011aae21_904f931f-4993-4059-ab65-e3961044d535 - you can ignore the second half, it is merely the machine guid querried from the registry - hklm\software\microsoft\cryptography\machineguid - you can just used the resolved hash followed by an underscore - bb1c31a261eed4c09b0a92ad011aae21_

now try accessing the encrypted file - it should all matchup. decrypt.

Haz clic para expandir...