Research on vulnerability of SQL Server database password

Tracking the SQL Server database server login process, found that the password calculation is very fragile, the SQL Server database Password Vulnerability embodies two aspects:
1. Password encryption algorithm for network landing
2. Password encryption algorithm for database storage.

Here is a separate story:
1. Password encryption algorithm for network landing
SQL Server network encryption Password has been very fragile, the internet has a lot of written tables, but there is no specific algorithm to deal with, in fact, tracking the SQL
Server's login process, it is easy to obtain its decryption algorithm: Well, let's demonstrate the assembly process:
The TDS packet for the login type jumps to the 4126a4 for execution
004DE72E: Generates a buffer of the size corresponding to the next copy based on the Size field received
004de748 Copy login information from TDS received BUF offset 8
004de762:call sub_54e4d0: The processing of parameter checking for the buffering of new copy
The information in the TDS package is processed sequentially, each field should have the length of each domain, and the offset 0x24 is compared with the length.
The following assembly code is the implementation of the network encryption password decryption algorithm:
. text:0065c880 mov cl, [edi]
. text:0065c882 mov dl, cl
. text:0065c884 XOR cl, 5
. text:0065c887 xor DL, 0AFh
. text:0065c88a SHR DL, 4
. text:0065c88d SHL cl, 4
. text:0065c890 or DL, cl
. text:0065c892 mov [edi], DL
. text:0065c894 Inc EDI
. text:0065c895 Dec EAX
. text:0065c896 JNZ Short loc_65c880
. text:0065c898 jmp Loc_4de7e6
It is easy to replace it with C code, you can see its encryption and simple, and clear no difference, oh, you can embed this code in the sniffer to sniff the TDs landing packets to decrypt, in fact, 0XA5 is not a specific SQL Server password field demarcation symbol, Just because the encryption algorithm automatically encrypts the two-byte 0x0 of ASC into 0XA5, this is not the main reason to judge the boundaries if a double-byte password is allowed.
void sqlpasswd (char * enp,char* DNP)
{
int i;
unsigned char A1;
unsigned char A2;
for (i=0;i<128;i++)
{
if (enp[i]==0)
Break
a1 = Enp[i]^5;
a1 = A1 << 4;
A2 = Enp[i]^0xaf;
a2 = A2 >> 4;
DNP[I]=A1|A2;
}
dnp[i]=0;
dnp[i+1]=0;
wprintf (L "passwd:%s\n", (const wchar_t *) DNP);
}

2. Password encryption algorithm for database storage.
SQL Server password to the database storage encryption method, is also weird. The process is as follows:
After obtaining the password for the network decryption password
005F9D5A Place Call Sqlsort_14, implement a conversion to uppercase password buffer for saving.
Then call a function at 004def6d to remove the encrypted password from the database in the following form:
2-byte head 0x0100 (fixed)
4-byte hash plus secret key
20-byte HASH1
20-byte HASH2
As I took out an example:
fx:0x0100 1751857F dfdec4fb618d8d18eba5a27f615639f607cd46be Dfdec4fb618d8d18eba5a27f615639f607cd46be
Fixed supplemental key HASH1 HASH2
Password is: 123456

SQL first uses 4 bytes of hash plus secret key to fill its two password buffer, one is uppercase, one is lowercase. Then the encryption process follows the C function
CRYPTACQUIRECONTEXTW (&hprov,null,l ("Microsoft Base Cryptographic Provider v1.0"), 1,0xf0000000);
Cryptcreatehash (Hprov,0x8004,null,null,&hhash);
Cryptcreatehash (Hprov,0x8004,null,null,&hhash);
005F9DFE:
Crypthashdata (hhash,passwdbuf,0x12,null);p asswdbuf is a lowercase passwd buffer, and then attaches a key, as the example above is the
Hash encryption for a string such as {1,23456,0x17,0x51,0x85,0x7f}
Crypthashdata (Hhash,passwdbuf,0x12,null); Passwdbuf is an uppercase passwd buffer, and then attaches a key
005F9E3E:
Cryptgethashparam (hhash,2,&passwdout,&outlen,0); Remove the encrypted value of the passwdbuf is a lowercase passwd
Cryptgethashparam (hhash,2,&passwdout,&outlen,0); Remove the encrypted value of the PASSWDBUF that is uppercase passwd
These two additions are the password encrypted fields in the real database.

Why is it that the above methods are fragile? In fact, its true encryption length generation is only 20 bytes.
lowercase password hash1+ uppercase password HASH1 concatenation of the 40-bit hash value is not as safe as a direct 20-bit hash value. Because we all know the causal relationship between the two values,
Provided more information to the decryption person.
As for its algorithm, if the HASH1=HASH2, you can determine that the password is not using letters, only the number and symbol of the password, such as the 123456 password taken out of the hash, two hashes exactly equal.

is to use the letter, it knows the supplementary key, algorithm, two cryptographic strings of the relationship, its solution should also be greatly simplified.

Of course, I did not study the encryption algorithm, just feel the encryption method is really unsafe, oh, I hope the master of the decryption algorithm guidance.