Principle of restoring the dialing connection password on the NT Platform

Author: eyas
Email: eyas at xfous.org
Date: 2004-11-08

Some time ago, the ADSL password was forgotten, but fortunately it was stored in the dial-up connection, so I found some asterisks and passwords on the Internet.
The display tool does not work. Later, I found a tool named dialupass. This guy gave me the password.
I restored it. (Dialupass v2.42, my system is windows xp)

It seems that dialupass is not a common asterisk password display tool. What is its principle? GOOGLE checked
I did not find the relevant information (maybe the keyword I used is incorrect ). Windbg)
Prepare to unload it. Sadly, after loading with windbg, the password cannot be restored and is displayed as an asterisk. Replacement
Make up for the ollydbg. Does this employee have the Anti-Debug function? At that time, it was just a bit of doubt, because
I don't believe that the authors of such gadgets will spend time protecting them.

In the process of tracking with s-ice, we found such a call:

GetProcAddress (xx, "IsDebugPresent ").

Fainted. The Anti-Debug function was actually available, but it was relatively simple. After statistics, a total of five operations were performed.
Anti-Debug check.

When the problem is identified, it is switched back to windbg for debugging. In windbg, such a breakpoint can bypass Anti-Debug.
Detection:

Bp KERNEL32! IsDebuggerPresent "g poi (esp); r eax = 0; g"

It took some time to track the process of restoring the password of dialupass. This small program is tricky
There are many, summarized as follows:

1. Key functions are not called directly, but LoadLibraryA and GetProcAddress are used to obtain the function address.
And then CALL.
2. The function name is encoded and cannot be seen after disassembly.
3. The key points are to confuse you and the disassembly software with instructions.

In fact, the principle is very simple. It is to use some functions in rasapi32.dll to obtain some information about the dial-up connection,
Use ADVAPI32 again! The LsaRetrievePrivateData function to obtain the password.

According to the principle of dialupasss, a similar tool is written. For the source code, see x_dialupass.c.

Then I used "LsaRetrievePrivateData" and "RasDialParams" as keywords and searched GOOGLE again.
Find some similar code.

Reference resources [1] and [2] are DEMO code published by Russians. No response is returned to LsaRetrievePrivateData.
To split the user name and password. Reference resource [3] is the complete application code published by the Japanese, unfortunately
A bug exists when splitting the data returned by LsaRetrievePrivateData. In some cases
And the password is incorrect.

It was found that lsadump2 DUMP contains the number returned by "LsaRetrievePrivateData ".
Data. The principle of lsadump2 is roughly as follows:

1 worker is inserted into the lsass.exe Process
2) Open the LSA Policy database
3) enumerate subkeys from the Registry "HKLMSECURITYPolicySecrets"
4) LsarOpenSecret
5) LsarQuerySecret

After further tracking, we found that, in fact, ADVAPI32! LsaRetrievePrivateData is passed through
The sender rpccalls the lsass.exeprocess, and then calls LsarOpenSecret and LsarQuerySecret in lsass.exe.
To obtain the dial-up connection information. (Note: LsarOpenSecret has permission judgment, which is not used by the ADMIN group.
The user does not have the permission to call ADVAPI32! LsaRetrievePrivateData)

After tracking LsarQuerySecret, we found that the data returned by LsarQuerySecret is actually read from the registry. Save dialing
The Registry Key of the connection information is:

HKLMSECURITYPolicySecretsRasDialParams! SID #0 CurrVal

SID corresponds to the user's string SID. (The "HKLMSECURITY" key only has SYSTEM permission to read.
Write, even admin has no permission)

After LsarQuerySecret reads data from the registry, it then calls the LsapCrDecryptValue function
Decryption: For the same machine, the keys used for decryption are always fixed. This KEY is in lsasrv. dll.
The variable name is "_ LsapDbSecretCipherKey ". In windows 2003, the variable names are different, corresponding to two
"LsapDbSecretCipherKeyWrite" and "LsapDbSecretCipherKeyRead",
The data in the variable is the same.

LsapCrDecryptValue uses the standard DES algorithm. The main process for decryption is as follows:

Lsasrv! LsapCrDecryptValue
| _ Advapi32! SystemFunction005
| _ Advapi32! DecryptDataLength
| _ Advapi32! SystemFunction002
| _ Advapi32! DES_ECB_LM
| _ Advapi32! Des

After decryption, there is another judgment in the "<" mark:

. Text: 785462F0 call _ LsapCrDecryptValue @ 12
. Text: 785462F5 test eax, eax
. Text: 785462F7 mov [ebp + var_8], eax
. Text: 785462FA jl loc_785838E1
. Text: 78546300
. Text: 78546300 loc_78546300:
. Text: 78546300 cmp byte ptr [esi + 45 h], 0 <
. Text: 78546304 jz short loc_7854632E
......
. Text: 7854632E loc_7854632E:
. Text: 7854632E lea eax, [ebp + var_10]
. Text: 78546331 push eax
. Text: 78546332 push [ebp + arg_8]
. Text: 78546335 push [ebp + var_C]
. Text: 78546338 call _ LsapCrEncryptValue @ 12

If [esi + 45 h] is 0 (esi is the HANDLE returned by the LsarOpenSecret function), it will decrypt
The data is encrypted again. Whether it is 2000 or 2003, the keys used are always fixed
"SystemLibraryDTC ".

In lsadump2, the HANDLE obtained by calling LsarOpenSecret is 1 at 0x45 offset, so
The LsarQuerySecret function returns the decrypted data.

While calling ADVAPI32! HANDLE offset returned by LsarOpenSecret when LsaRetrievePrivateData
The value 0x0 at 0x45, so LsarQuerySecret returns decrypted and encrypted data.
ADVAPI32! LsaRetrievePrivateData also contains a corresponding decryption process. Corresponding,
The main process of LsapCrEncryptValue encryption is as follows:

Lsasrv! LsapCrEncryptValue
| _ Advapi32! SystemFunction004
| _ Advapi32! EncryptDataLength
| _ Advapi32! SystemFunction001