DPAPI Master Keys

Abstract

In this paper, we are making an attempt to analyze the operation of DPAPI, review the undocumented structures and encryption algorithms of DPAPI, understand and describe the internal functioning of the system.

The paper presents the world's first complete (not claiming to be universal though) description of DPAPI operation logic and all the undocumented structures, including DPAPI blobs, Master Keys and credential history files.

We also attempt to point out some functional drawbacks of the latest version of DPAPI and possible ways to eliminating those. Additionally, a deeper analysis of the implementation of the first version of DPAPI, released along with Windows 2000, has revealed the presence of a number of serious vulnerabilities and put the entire security of the system into question.

Much attention is paid to the recovery of DPAPI data when user profile cannot be loaded. For the first time ever, we practically tested the user logon password recovery algorithm without using SAM or NTDS.DIT files.

The operation of DPAPI was analyzed using a set of 6 utilities, integrated into one of the most powerful applications for auditing Windows passwords, Windows Password Recovery. We hope these tools, as well as certain information from our article, is found interesting not only to experts and criminologists but to all researchers in the field of computer security.

What is DPAPI

Beginning with Windows 2000, Microsoft ships their operating systems with a special data protection interface, known as Data Protection Application Programming Interface (DPAPI). DPAPI is currently widespread and used in many Windows applications and subsystems. For example, in the file encryption system, for storing wireless connection passwords, in Windows Credential Manager, Internet Explorer, Outlook, Skype, Windows CardSpace, Windows Vault, Google Chrome, etc. DPAPI has become popular among programmers first of all due to its simplicity of use, as it consists of just a couple of functions for encrypting and decrypting data, CryptProtectData and CryptUnprotectData.

Despite its apparent simplicity, the technical implementation of DPAPI is rather complicated, and these functions' operation logic is much like the cheerful childish rhyme "The House that Jack Built". Perhaps, that's the reason why the internal structures and operating principles of DPAPI had been kept behind a closed curtain for so long.

For the first time, DPAPI was analyzed by Passcape Software in 2003. In 2005, the company released the first commercial application (Outlook Password Recovery) based on that recovery, which could decrypt DPAPI blobs offline, i.e. without logging on to owner's account. The decryption algorithm proposed by Passcape merely simulated DPAPI operation, so the DPAPI system has not been compromised.

With the release of the brand-new version of Windows Password Recovery tool, the offline DPAPI decryption algorithm has gotten a new round. Now, besides decrypting DPAPI blobs, the program could also analyze them, find them on disk, decrypt Master Keys and validate their passwords, extract users' credential history hashes from DPAPI, and much more.

What does DPAPI protect?

DPAPI is utilized to protect the following personal data:

Passwords and form auto-completion data in Internet Explorer, Google *Chrome

An example of a successful and clever way to protect data using DPAPI is the implementation of the auto-completion password encryption algorithm in Internet Explorer. To encrypt the login and password for a certain web page, it calls the CryptProtectData function, where in the optional entropy parameter it specifies the address of the web page. Thus, unless one knows the original URL where the password was entered, nobody, not even Internet Explorer itself, can decrypt that data back.

DPAPI architecture

Beginning with Windows 2000, as it was mentioned earlier, any application can protect its personal data (e.g., passwords) by simply calling the CryptProtectData function, which returns a "non-transparent" binary structure, also known as DPAPI blob. "Non-transparent", by Microsoft's definition, means that besides the original encrypted data of the application it also contains other supplemential stuff, necessary for decrypting that data. Despite that the structure of DPAPI blobs is not documented, with the release of the new version of Windows Password Recovery, for the first time ever it has become possible to decrypt DPAPI blobs offline and thoroughly analyze them.

Other API function, CryptUnprotectData, which, as its name suggests, works similarly, but the other way around, gets an encrypted DPAPI blob at the input and returns decoded data to the application.

Figure No 1. shows the DPAPI flow chart.Figure 1. DPAPI flow chart.

DPAPI encryption is based upon user password; therefore, data encrypted under one account cannot be decrypted under other account. Moreover, DPAPI allows restricting access to data even within one account by setting an additional secret (entropy). Thus, unless it knows the additional secret, one application cannot access data protected in other application.

Every programmer implementing DPAPI interface must realize that the system only encrypts data. An application must provide a solution for storing the returned DPAPI blobs, including reliable hiding of optional entropy data if it is used.

DPAPI security

DPAPI was created with the view of many aspects in terms of security. Here is a list of key features that distinguish it from similar systems:

PAPI works on top of CryptoAPI. You can create your own encryption service provider and use it with DPAPI.

All the algorithms, as well as their key length, can be configured from the registry, which can be accessed only by users with the Administrator privileges. For example, the number of iterations in the PBKDF2 function is set in the following registry key:

All the parameters that can be configured from the registry have their restrictions and cannot be lesser than the default values. For example, in Windows XP the MasterKeyIterationCount default value is 4000.

All critical data is protected by integrity check.

Size of all encryption keys in all algorithms is sufficient to prevent possible brute force attack.

For the same purpose, PBKDF2 has a rather great iteration counter. The only exception is the first implementation of DPAPI. The table below shows that the Master Key password search speed is sufficient for compromising user password in Windows 2000.

For security reasons, the validity of the Master Key is limited. However, the implementation of that mechanism has weak points, which will be discussed below.

All communications with the domain controller are carried out via a secure RPC channel.

Cached data is written neither to disk, nor to swappable RAM. Intermediate keys and values are reset in the stack after running each encryption function. By the way, when analyzing the SYSKEY utility, Passcape specialists have found an interesting bug related to incorrect stack reset, which resulted in having a part of the system encryption key (SYSKEY) in some systems running under Windows 2000, Windows XP and Windows 2003 stored as plain text, available to all users of the system. Alas, it happens sometimes.

However, there are some nuances, the ignorance of which can weaken the DPAPI security system:

CRYPTPROTECT_LOCAL_MACHINE - flag set in the CryptProtectData function, quite convenient in certain cases, in fact can compromise user data, not providing adequate protection. When it is set, the encryption does not depend on user's logon password. On the other hand, such behavior does not contradict the DPAPI concept and is related to peculiarities of interface implementation.

DPAPI can be configured to run in the compatibility mode for Windows 2000, when the backup Master Key is stored locally and can be decrypted using the LSA secret. Thus, in theory, all the DPAPI blobs can be decrypted without knowing user password. That is what Windows Password Recovery demonstrates in practice. See screenshot No 2. Nevertheless, to activate that mode, one needs Administrator access to the registry key with DPAPI configuration.

By default, the system uses Microsoft's crypto provider named df9d8cd0-1501-11d1-8c7a-00c04fc297eb, implemented in the psbase.dll library.
The encryption is configured by modifying the respective value in the following registry key:HKLM/Software/Microsoft/Cryptography/Protect/Providers/%GUID%

Where %GUID% is the service provider's unique identifier. By default, the DPAPI settings key corresponds with HKLM/Software/Microsoft/Cryptography/Protect/Providers/df9d8cd0-1501-11d1-8c7a-00c04fc297eb

This hive of the registry can be modified by users with Administrator rights only. Here are the descriptions of some keys of this hive.

Value: MasterKeyIterationCount
Data type: REG_DWORD
Description: Iteration counter for function PBKDF2, cannot be smaller than the
default value. The key generation algorithm is used in the encryption
of user's Master Key and credential history.

Value: MasterKeyLegacyCompliance
Data type: REG_DWORD
Description: Set the registry key to 1 to make DPAPI behavior similar to that of
Windows 2000 when backing up/restoring Master Keys.

Value: MasterKeyLegacyNt4Domain
Data type: REG_DWORD
Description: Since DPAPI backup/restore support doesn't exist on NT4, DPAPI provides
a workaround to avoid losing its data and force the client machine to
use W2K style master key backup/restore. For that, you should set the
MasterKeyLegacyNt4Domain parameter to 1.

Value: DistributeBackupKey
Data type: REG_DWORD
Description: Determines compatibility settings when backing up or restoring domain
key. For example, if the domain functional level is set to Windows
2000 native.

Value: Recovery Version
Data type: REG_DWORD
Description: Determines version compatibility when backing up and restoring local
copies of Master Keys. The default version is 2; Windows 7 and Windows
Server 2008 R2 can be configured to use version 3 by setting the DWORD
registry value to 3.

pointer to a DATA_BLOB structure that refers to the original data to be encrypted.

LPCWSTR szDataDescr

data descriptor; stored as plain text in DPAPI blob. This optional parameter is for information purposes only; it may be omitted in the function call.

DATA_BLOB *pOptionalEntropy

as the foregoing, is an optional parameter. However, unlike the descriptor, the entropy directly affects data security, so it is not stored in the DPAPI blob. User must ensure the proper management of this secret. Some third-party applications (such as GTalk) store this secret in the registry, other Windows components (such as .Net Passport or WININET) use a hard-coded constant for the secret, third use a variable value. For example, the internal FTP client of Windows Vista creates entropy based on the server name. One way or the other, this may at least amuse the potential attacker. In our opinion, the most successful example of utilizing entropy is the one implemented in the password storage mechanism of Internet Explorer, which doesn't store the secret at all.

PVOID pvReserved

currently not used.

CRYPTPROTECT_PROMPTSTRUCT *pPromptStruct

when this structure is defined, user is required to enter an additional password for encrypting the DPAPI blob. Put it this way: It is used very infrequently due to the fact that the password prompt occurs in interactive mode.

DWORD dwFlags

flags that control the encryption process. Here is the description of the most interesting of them:CRYPTPROTECT_UI_FORBIDDEN (0x1)
Used when user interface is not available. For example, when using remote access.CRYPTPROTECT_LOCAL_MACHINE (0x4)
Data is protected using local computer account. Any user of the system may be able to decrypt it.CRYPTPROTECT_CRED_SYNC (0x8)
Forces synchronizing user's credentals. Normally runs automatically upon user password change.CRYPTPROTECT_AUDIT (0x10)
Enables audit during encryption/dectyptionCRYPTPROTECT_VERIFY_PROTECTION (0x40)
The flag checks security level of DPAPI blob. If the default security level is higher than current security level of the blob, the function returns error CRYPT_I_NEW_PROTECTION_REQUIRED as advice to reset securiry for the source data.CRYPTPROTECT_CRED_REGENERATE (0x80)
Regenerate local computer passwords.CRYPTPROTECT_SYSTEM (x20000000)
Indicates that only system processes can encrypt/decrypt data.

DATA_BLOB *pDataOut

target DPAPI blob that occurs in the result of calling the function

Examples of use for CryptProtectData/ CryptUnprotectData functions

For the convenience of running tests, as well as for the purposes of providing an example, we have created two simple utilities of the respective names, which implement mere wraps around DPAPI functions. Thus, DPAPI functions can be called from the command line. Here is the С++ source for CryptProtectData. The compiled ЕХЕ files of these programs are also available for download at: CryptProtectData, CryptUnprotectData.

Data encryption in DPAPI

The encryption of user's personal data in DPAPI goes in three phases:

First, the application calls the CryptProtectData function, specifying the source data to be encrypted and the optional entropy parameter. If the latter is not specified, any other program in the context of current user may be able to decrypt the data by gaining physical access to the DPAPI blob.

The CryptProtectData function belongs to the CryptoAPI family and is located in Crypt32.dll. From there, the request for further processing is forwarded via a secure RPC channel to the Local Security Authority (LSA) system process, and the context of current user is switched to the system. All the further manipulations are run in the context of the local system.

In the LSA, the data is actually encrypted and forwarded back to Crypt32.dll via the RPC channel; from there, the data safely travels to the original application.

CryptProtectData and CryptUnprotectData are basically just wrapper functions, since the actual data encryption runs in the context of the system. The magic part of DPAPI takes place in the LSA, and is hidden from the stranger's eye.

The encryption process is lengthy and boring; it may remind of "fulfilling the marital duty after 20 years of living together". In the beginning, we take user's password; then, by applying the PBKDB2 cryptographic standard to it, we get the Master Key encryption key. Now, we use that encryption key to decrypt the Master Key. If the decryption fails, the user password is decrypted using the first hash of the credential history, CREDHIST, which in its turn also gets the Master Key encryption key and attempts to decrypt the Master Key again. If that attempt too ends up in failure, we decrypt the next credential history hash, and so on. The operation continues until either the Master Key is decrypted or the credential history runs out of its items.

To avoid password prompts every time CryptProtectData / CryptUnprotectData is called, Windows caches the password and stores it in the depths of the LSA for the duration of the user profile life. That is why DPAPI works exclusively online, only after the user has logged on to the system.

In 2005, for the first time ever, Passcape Software introduced an algorithm that works in all of the company's products and simulates the offline operation of DPAPI. In other words, to decrypt DPAPI blobs, one no longer needs to load user's context; although having the password is mandatory. In no way does the offline decryption of DPAPI makes the system more vulnerable; at the same time, it remains helpful to researchers, experts and criminalists.

So, user's Master Key resides in a special container file, which can store additional copies - backups - of the Master Key. A Master Key backup is used when the primary copy, for one or the other reason, cannot be decrypted. For example, after a forced password reset. Master Key is a critical element in DPAPI cryptography; therefore, its length is 512 bits, and only proven algorithms are used when encrypting it. See the table 1.

The decryption of Master Key in the first implementation of DPAPI required the NTLM hash of user's password. That was a major: No, that was the greatest blunder of DPAPI developers, which negated the security of the system. All because it technically allowed a potential malefactor to decrypt the Master Key and, consequently, any DPAPI blob by getting the NTLM hash directly from the SAM file; the actual password was not even necessary! In the second, current version of DPAPI, that error was fixed; now Master Key is encrypted using the SHA1 hash.

Once the Master Key is successfully decoded, its source 512-bit data participates in obtaining the symmetric encryption key for the DPAPI blob. For that purpose, the Master Key is "mixed" with random data (which would be then stored in the DPAPI blob) and entropy, if it is specified. Thus we achieve a three-dimensional uniqueness, so to say, of the encryption key for each DPAPI blob.

And, finally, there goes the actual encryption of the source data. In Windows 7, data is encrypted using the AES256 algorithm. All the phases of that intricate process involve using "salt", i.e. set of random data, unifying encryption keys and thus preventing the potential brute force attack with rainbow tables.

By the way, few people know that the first versions of Windows 7 had serious problems with AES encryption. Simply put, this type of encryption did not function at all. Fortunately, the problem was quickly eliminated.

Once the data is encrypted, it is grouped into a single structure along with other system information and sent back to the application as a DPAPI blob. The structure of a DPAPI blob is not documented; however, Passcape researches were able to fully reverse it. Here it is.

Figure 3. Undocumented structure of DPAPI blob.

What is DPAPI Master Key

A user's Master Key is a binary file that contains encrypted data used for creating the primary encryption key in all DPAPI blobs. Since Master Key encrypts user's confidential data, the key itself requires serious protection. User's password was meaningfully chosen as source data for protecting the Master Key.

Figure 4. Master Key structure.

Master Key structure

As shown on Figure 4, a Master Key file consists of 5 units:

Header and system information

User's Master Key

Local backup encryption key

Unique CREDHIST file identifier

Domain Master Key backup

In Windows 2000, instead of the CREDHIST identifier, the system could store the local Master Key backup. That is what made the DPAPI system extremely vulnerable. Windows Password Recovery, for example, can decrypt a Master Key from its local backup and wouldn't even need the user's password to do that.

The header of the Master Key file contains the following information (C++ syntax followed by description of each field):

version of the Master Key file used for the purposes of compatibility check. For Windows 2000 this field is set to 1; for other operating systems - to 2.

WCHAR szGuid[0x24]

string value with a unique Master Key identifier, normally matching the file name. Any DPAPI blob stores this identifier, which links it to a specific (and only one) Master Key.

DWORD dwPolicy

field with various flags. For example, if bit 3 of this field is set, the decryption key for the Master Key (from user's password) will be created using the SHA1 algorithm. In Windows 2000, this flag is always cleared; i.e. it uses NTLM hash.

DWORD dwUserKeySize

contains the size of user's Master Key.

DWORD dwLocalEncKeySize

size of backup copy encryption key.

DWORD dwLocalKeySize

size of local backup key or CREDHIST GUID field

DWORD dwDomainKeySize

size of domain's Master Key backup.

The header is followed by a sequence of 4 Master Key slots. Each slot contains its own header and the actual key.
The header structure is common for all slots. Here is what it looks like for version 1 (Windows 2000):

The table 2 shows the default Master Key encryption algorithms for various operating systems, as well as the analysis of their protection from a potential brute force attack.

OS

CryptAlgId

HMACAlgId

dwPBKDF2IterationCount

Password guess speed (pwd/sec)

Windows2000

RC4

SHA1

1

95000

WindowsXP

3DES

SHA1

4000

76

WindowsVista

3DES

SHA1

24000

12

Windows7

AES256

SHA512

5600

10

Table 2. Master Key encryption algorithms.

Generating new Master Key

Let's take a closer look at the process of creating and encrypting user's new Master Key:

First, we call the API function RtlGenRandom, which returns 64 pseudo-randomly generated bytes. That's the raw material for the Master Key to be used for encrypting DPAPI blobs.

Now we need to protect the raw material for the Master Key. For that purpose, we encrypt it using the user's logon password, security identifier (SID) and additional 16 bytes of random data (so-called "salt"). The Master Key encryption process consists of two major steps. First, we use the Password-Based Key Derivation function (crypto standard described in PKCS #5) and get the key out of the password, SID and salt. Then we use that key to obtain a symmetric Master Key encryption key. Different versions of Windows protect Master Key different ways. Thus, in Windows 2000 the default encryption algorithm is RC4, in Windows XP and Win2K3 it's 3DES, and Windows Vista and higher use AES256.

Master Key obtains a unique name, GUID. Each DPAPI blob stores that unique identifier, which it is bound to via a warm friendly relationship. In other words, Master Key GUID is the key's "link" to the DPAPI blob.

Master Key, created and encrypted with user's password, is stored in a separate file in the Master Key storage folder along with other system data. MKSF is a special location on disk where Master Keys are stored. User's Master Keys are stored in %APPDATA%/Microsoft/Protect/%SID%, where %APPDATA% is the Application Data directory. For example, C:/Users/John/AppData/Roaming/Microsoft/Protect/S-1-5-21-2893984454-3019278361-1452863341-1003, and %SID% is user's security identifier. In the above example that's S-1-5-21-2893984454-3019278361-1452863341-1003. System's Master Keys are stored in %WINDIR%/System32/Microsoft/Protect and used for decrypting DPAPI blobs, protected under a local system account. All the DPAPI blobs created with the CRYPTPROTECT_LOCAL_MACHINE flag set in the CryptProtectData function are protected with the system's Master Keys.

Master Key creation, encryption or decryption can be extremely time-consuming, by the standards of the operating system. For example, in Windows 7, it takes over 0.1 of a second to decrypt a Master Key on a modern PC. But DPAPI has internal caching, so once decrypted, a Master Key is placed in the cache, and accessing it again does not involve a new decryption route.

Regenerating Master Keys

If you open Master Key Storage Folder on your disk, having previously allowed the system to show hidden folders and files (Master Key files have the Hidden attribute), you will likely see several Master Key files. Why several? - Because DPAPI, for safety reasons, forces the creation of a new Master Key approximately every 90 days, so any user account normally has several Master Keys; the number depends on the user profile creation date.

The Master Key regeneration period is hard-coded in the system. It is assumed that it cannot be modified. However, there is a "BUT" to it: The Master Key folder contains an 18-byte file named Preferred, which contains the name of the last Master Key created by the system, as well as the creation date.

Every time some DPAPI function is called, the system checks the last Master Key creation date in Preferred and, if finds it older than 90 days, creates a new Master Key, updating Preferred along the way. The Master Key regeneration process can be managed manually. To do that, call the CryptProtectData function with the CRYPTPROTECT_CRED_SYNC flag set. The system will re-encrypt all the Master Keys and update them on the disk. That operation is normally performed after changing user's password. To prevent the optional Master Key updates, Windows 7 introduced a Master Key synchronization mechanism, which we are going to cover below.

The data in the Preferred file is not protected by any means, so by modifying the last Master Key creation date by hand, one can manually manage the regeneration process; for example, infinitely extend the life of the last Master Key or create any number of Master Keys. But while the extension of life for a Master Key does not give malefactor any privileges, in the last case, a great number of Master Keys followed by password change can put the system in a lengthy screeching halt, as all Master Keys undergo a mandatory re-encryption every time user's password is changed.

Now, figure out how much time it would take to process, for example, 1000 Master Keys in Windows 7 if processing a single Master Key takes over 0.3 of a second. Thus, in our opinion, the Master Key regeneration process requires a bit of additional work. Ideally, adding data integrity control-the absence of which appears to be just about the only major vulnerability of DPAPI, and even that can hardly be called vulnerability-would be sufficient. Overall, the entire DPAPI system is well balanced and robust.

Backing up Master Keys and restoring them from backups

Backing up Master Keys of a domain PC

When the computer is a member of a domain, the Master Key file stores the backup of user's Master Key. When creating a Master Key, DPAPI sends a request to the domain controller that stores the RSA encryption private/public key pair. The Master Key is encrypted using the domain's public key and stored as backup in the same file with the user's Master Key. If an error occurs while decrypting the primary copy of the Master Key, DPAPI sends the backup to the domain controller. The domain controller decrypts it using its private RSA key and sends the decrypted Master Key back.

When it comes to stand-alone computers of home users (Windows XP and higher), DPAPI employs a different recovery mechanism based on password reset disk. Password reset disk, which user can create at any time in the control panel, allows user to recover a forgotten password. The key phrase in the previous sentence is user can. The burden of data recovery rests entirely on user's shoulders.

But what happens if user changes the password after the password reset disk has been created? Everything is going to be just fine. The process is simple and, at the same time, robust as a village closet. When creating a password reset disk, the system creates a pair of the public and 2048-bit private RSA encryption keys. User's current password is encrypted using the public key and stored in user's registry key HKEY_LOCAL_MACHINE/SECURITY/Recovery/%SID% (for Windows XP - Windows Vista) or in HKEY_LOCAL_MACHINE/C80ED86A-0D28-40dc-B379-BB594E14EA1B (for Windows 7). Anyway, access to these keys is forbidden to all users of the system, including Administrators. And the private key that is required for the decryption of the password is saved on the disk. Thus, if after creating a password reset disk user changes the password, the new password is encrypted with the public RSA key and is saved in the registry, replacing the old one. Since the public RSA key matches the respective private key stored on the disk, the private key can be used any time later for decrypting the new password that has just been created and is stored in the registry. By the way, one of the latest versions of Windows Password Recovery can decrypt user's plaintext logon password when the password reset disk is available.

Backing up Master Keys on a stand-alone PC in Windows 2000

But the password reset system came only in Windows XP. What was before that? Indeed, despite the fact that Windows 2000 did not have password reset disk, user's Master Key backup was still performed on stand-alone computers. Both the primary Master Key and the Master Key backup were stored in the same! That means that any data encrypted with DPAPI could be decrypted by a potential malefactor WITHOUT knowing user's logon password (by just having physical access to the system).

Figure 5. Master Key file structure in Windows 2000.

Microsoft strongly recommends upgrading Windows 2000 to a more current version. But if you have a good reason for not doing it, we are going to show you how to best protect your good old Win2K from a potential compromising. For that purpose, let's take a look at the local Master Key backup creation algorithm. A Win2K Master Key file conventionally consists of 5 units:

Header and system information

User's Master Key

Local backup encryption key

Local Master Key backup

Domain Master Key backup

Restoring user's Master Key from a local backup of begins with decoding the local backup encryption key. In the decryption process, we use the local computer account password (oh yes, it does have such an account), which is stored in the LSA secret named DPAPI_SYSTEM.

Once the local backup encryption key is obtained, we use it to decrypt the local backup of user's Master Key. It's as easy as 1-2-3. From this point of view, Win2K is more user-friendly, as even if user's password is deliberately erased, DPAPI can always restore the Master Key from the local backup. Hopefully, there's no need to explain the cost of that user-friendliness:

Any user that can access a PC under OS Windows 2000, which is not a domain member, can easily decrypt other user's encrypted DPAPI data, with no need for the logon passwords or even password hash!

To partially prevent that outrage, we must change the operating mode for SYSKEY. Run the SYSKEY utility (press the WIN + R shortcut on the keyboard, then type in syskey.exe and then click OK), replacing the SYSKEY storage location. Now, to decrypt the DPAPI_SYSTEM LSA secret, a potential malefactor would have to either know the SYSKEY bootup password or have the SYSKEY startup disk.

Hi , I use the code represented in the paper, that is cryptprotect function, to encrypt some plain text to a dpapi blob in win 7. Then I copy the encypted dpapi blob and the master key to Xp system, using the software to decrypt. And I received error 9, saying that the entropy may be wrongly setted. But I didn't set entropy at all. I don't why the software can't decrypt the dpapi blob in win 7. I had test that it can make it in vista?

Re: Can't decrypt the dpapi blob from win 7~

posted by Passcape_Admin at 11:13:34 24.07.2012

No, it's not a mistake. The most interesting thing about DPAPI is that any program can set a salt (entropy) when calling DPAPI encryption function. So without the entropy, you will not be able to decrypt DPAPI blob even if other data is known to you.

For example, Internet Explorer 7 - 9 uses URL address as the entropy when encrypting the site password and saving it to DPAPI blob. So to decode the blob, you'll have to provide the name of the source URL address (ended up with zero character) as entropy parameter. Have a look at the end of the article. It has an example that describes how to decrypt facebook password saved by Internet Explorer.

Most probably the blob you're trying to decrypt was encoded with entropy. So the program complains.