Data security: password cracking for all. mdb versions

The 13 bytes at the 0x42 bytes of the mdb file are 0x86, 0xfb, 0xec, 0x37, 0x5d, 0x44, 0x9c, 0xfa, 0xc6, 0x5e, 0x28, 0xe6, or 0x13 returns the Database Password. However, in Access 2000 and 2002, the key is no longer fixed 13 bytes, And the encryption method has also changed.

After one afternoon of research by the ccrun, the Access2000 encryption method was finally clarified. Hey. I will share my experiences here, hoping to help you.

The analysis tool I used is UltraEdit32 v10.00, and the programming tool is C ++ Builder 6.0.

After analysis with UltraEdit32, it is found that Access2000 and Access2002 are encrypted in the same way, so the following is only for the mdb File of Access2000. In addition, I use a hexadecimal number, so 0x is added in front. If you are using VB or others, pay attention to the value.

First, use AccessXP to create a database file db1.mdb with an empty password, which contains a table with a field that does not fill in any data. Save and exit, copy a copy as db2.mdb, enable 2.mdbexclusively, and add password 1324567890123 to save and exit.

Use UltraEdit32 to open the two databases and compare them. The comparison method is also very simple. In UltraEdit32, click the opened file tab (switch between two files. You can find that the file header is changed from 0x42 bytes.

db1.mdb00000040h：BC 4E BE 68 EC 37 65 D7 9C FA FE CD 28 E6 2B 25 ；00000050h：8A 60 6C 07 7B 36 CD E1 DF B1 4F 67 13 43 F7 3C ； 00000060h：B1 33 0C F2 79 5B AA 26 7C 2A 4F E9 7C 99 05 13 ；db2.mdb00000040h：BC 4E 8F 68 DE 37 56 D7 A8 FA CB CD 1E E6 1C 25 ；00000050h：B2 60 55 07 4B 36 FC E1 ED B1 7C 67 13 43 F7 3C ；00000060h：B1 33 0C F2 79 5B AA 26 7C 2A 4F E9 7C 99 05 13 ；

To make it clearer, I added different bytes to the color. As you can see, in Versions later than Access97, password bytes are not stored continuously, but stored in one byte. And encrypted. The decryption method is still the old method "different or "! 0xBE ^ 0x8F = 0x31, which is exactly the Ascii code "1. The next 0xEC ^ 0xDE = 0x32 is exactly the Ascii code "2. Until the last different 0x4F ^ 0x7C = 0x33, the obtained character is merged into a string, that is, the plaintext "1234567890123" of the password. Do not think this is the case. Because this time is correct. Haha. I thought it was that simple at the beginning, so I made a small program using CB and tried to solve several mdb passwords. However, I triedForumThe obtained password is incorrect in the mdb file. So I used another tool to retrieve the mdb password. I found that the password can be correctly retrieved by someone else. It is in the Access2000 format. So I feel that the method of Microsoft encryption has not been fully studied. Continue to work. Use UltraEdit32 to open the InternetForumThe database dvbbs. mdb, compared with the database I used to add a password, found that there are many different places. Try to use only one byte .... After nnn times, it is found that the byte at 0x62 plays a key role. It is called the encryption mark for the time being.

Db1.mdb // empty password 00000040 h: BC 4E BE 68 EC 37 65 D7 9C fa fe cd 28 E6 2B 25; 00000050 h: 8A 60 6C 07 7B 36 CD E1 DF B1 4F 67 13 43 F7 3C; 00000060 h: B1 33 0C F2 79 5B AA 26 7C 2A 4F E9 7C 99 05 13; db2.mdb // password: 123456789012300000040 h: BC 4E 8F 68 DE 37 56 D7 A8 fa cb cd 1E E6 1C 25; 00000050 h: b2 60 55 07 4B 36 FC E1 ED B1 7C 67 13 43 F7 3C; 00000060 h: B1 33 0C F2 79 5B AA 26 7C 2A 4F E9 7C 99 05 13; dvbbs. mdb // password: yemeng. net00000040h: BC 4E DB 6A 89 37 14 D5 F9 FA 8C CF 4F E6 19 27; 00000050 h: E4 60 15 05 0F 36 D1 E3 DF B1 53 65 13 43 EB 3E; 00000060 h: B1 33 10 F0 79 5B B6 24 7C 2A 4A E0 7C 99 05 13;

How can we try it? It's still a different or. Take the bytes starting from 0x42, 0xDB, and 0x42 of the null password file, and take the encryption mark at 0x62 as different from that at 0x62 of the null password file, then the two obtained values are different or:

(0xDB ^ 0xBE) ^ (0x10 ^ 0x0C) = 0x79. This value is Ascii "y", and then the next byte (remember to take one byte)

(0x89 ^ 0xEC) ^ (0x10 ^ 0x0C) = 0x79 bytes. Originally, this Byte should have been "e". How has it changed to "y? Try not to be different or different from the following two values. calculate 0x65 for 0x0 and get "e", haha. That's right. Next

(0x14 ^ 0x65) ^ (0x10 ^ 0C) = 0x6D get "m", next

(0xF9 ^ 9C) = 0x65 get "e", note that here only the two numbers are different or. You can try it later.

In this way, the rule is summarized.

During decryption, the encrypted file is extracted from the byte starting at 0x62 from the file header, which is different from the null password database file at 0x62 or to obtain an encryption mark.

Then, one byte is taken from each byte starting at 0x42 and 13 encrypted key bytes are obtained, it is the same as the 13 bytes obtained at every one byte of the null password database file 0x42. Why is it a semi-finished product? Because the 13-byte password is different from the encryption mark, or the last 13 bytes are the real password. Of course, if there is a byte 0x0 in the middle, it indicates that the number of digits in the password is not 13. Simply show it.

In addition, I found that the encryption mark will vary with time or machines, so there is no omnipotent solution, but there is a reference. The following code is the number I obtained when writing this program. It is not the same as the number I wrote this article, so the value is different, but the Final decryption result is the same. For more information, see.

By the way, it is also important to determine the database version first. I used a simple method to get the byte at 0x14. If it is 0, it will be regarded as Access97, if the value is 1, it is regarded as Access2000 or 2002. However, we have not found a way to determine 2000 and 2002. If anyone knows this, please advise.

Code:

// The definition of 13 bytes is used as the source code of the Access2000 exception or exception. The corresponding encryption sign is 0x13, and the ccrun hereby specifies

// Of course you can use this group: be ec 65 9C FE 28 2B 8A 6C 7B cd df 4F corresponds to this group of encryption signs is 0x0c

// Haha. The program is messy. I hope you can understand it.

Char PassSource2k [13] = {0xa1, 0xec, 0x7a, 0x9c, 0xe1, 0x28, 0x34, 0x8a, 0x73, 0x7b, 0xd2, 0xdf, 0x50 }; // unique or source code of Access97 char PassSource97 [13] = {0x86, 0xfb, 0xec, 0x37, 0x5d, 0x44, 0x9c, 0xfa, 0xc6, 0x5e, 0x28, 0xe6, 0x13}; void _ fastcall TMainForm: GetMdbPass () {char PassStrTemp [26], Ver, EncrypFlag, t1; int FileHandle; String MdbPassword, mdbVersion, MdbFileName; FileHandle = FileOpen (MdbFileName, fmOpenRead); if (FileHandle <0) {ShowMessa Ge ("file opening error! "); Return;} // obtain the database version FileSeek (FileHandle, 0x14,0); FileRead (FileHandle, & Ver, 1); // obtain the encrypted flag FileSeek (FileHandle, 0x62,0); FileRead (FileHandle, & EncrypFlag, 1); // read the encrypted password to the buffer zone FileSeek (FileHandle, 0x42,0); FileRead (FileHandle, & PassStrTemp, 26); FileClose (FileHandle); if (Ver <1) {MdbVersion = "Access 97"; if (int (PassStrTemp [0] ^ PassSource97 [0]) = 0) mdbPassword = "the password is blank! "; Else {MdbPassword =" "; for (int I = 0; I <13; I ++) MdbPassword = MdbPassword + char (PassStrTemp ^ PassSource97 );}} else {MdbVersion = "Access 2000 or 2002"; MdbPa