破解Access(*.mdb)目前一切版本的明码

在mdb文件第0x42字节处的13个字节分别与0x86,0xfb,0xec,0x37,0x5d,0x44,0x9c,0xfa,0xc6,0x5e,0x28,0xe6,0x13异或后即可失去的明码。但在Access 2000和2002的版本里密钥不再是固定的13个字节.而且加密的模式也有了变化。

通过ccrun用一下午的工夫钻研，终于将Access2000的加密模式搞清楚了。嘿嘿。在此将偶的心得发布。宿愿对大家有用，假设您发现我的理解有误，请来信告之咱们。信箱：info@ccrun.com 版权只管有没有都没关系，不过假设您要转载，请注明出处，并保证文档的残缺性。谢谢。

我用的剖析工具是UltraEdit32 v10.00，编程工具是 Builder 6.0

通过用UltraEdit32剖析，发现Access2000和Access2002的数据库加密模式相反，所以以下只针对Access2000的mdb文件。还有就是我用的是16进制的数示意，所以后面加了0x，假设你用的是或其余，要留意数值哦。

首先用AccessXP创建了一个空明码的数据库文件db1.mdb，蕴含一个表，其中有一个字段，没有填任何数据。保存参加然后复制一份为.mdb，以独占模式打开2.mdb，并加上明码1324567890123 保存参加。

用UltraEdit32打开这两个数据库，并停止比较。我比较的方法也很简略。在UltraEdit32中，快速的来回点击被打开文件的选项卡(就是在两个文件间来回切换，呵呵。笨办法吧)，发现从文件头末尾0x42字节处发生变化。

db1.mdb
00000040h：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.mdb
00000040h：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 ；

为了看的清楚些，我把不同的字节加了色彩。看出门道了吧，Access97当前的版本里，明码字节不再是延续寄存，而是隔一个字节存一个。并且通过加密。到于解密的方法嘛，还是用老办法“异或”！0xBE ^ 0x8F = 0x31，这正好是Ascii码"1"哦。下一个0xEC ^ 0xDE = 0x32 正好是Ascii码"2"，呵呵。不断到最后一个不同的0x4F ^ 0x7C =0x33，将取得的字符合成字符串，便是明码明文“1234567890123"，千万不要认为这样就出工了。由于这一次是正好碰对了。呵呵。我刚末尾也认为就这么简略，于是用CB做了个小程序，试着解了几个mdb明码都还行，可是试到动网论坛的mdb文件时发现取进去的明码不对，晕了。于是用另外一个取mdb明码的工具看了一下，发现人家的就可能正确的取出明码，是Access2000的格式，于是感觉微软加密的模式还是没钻研完。持续工作，用UltraEdit32打开动网论坛的数据库dvbbs.mdb，和我后面的加过密的数据库做比较，发现不同的中央很多。只好一个字节一个字节的试。。。。nnn次当前发现第0x62处的这个字节起着要害作用，暂称之为加密标志。

db1.mdb //空明码
00000040h：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.mdb //明码为:1234567890123
00000040h：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 ；

dvbbs.mdb //明码为:yemeng.net

00000040h：BC 4E DB 6A 89 37 14 D5 F9 FA 8C CF 4F E6 19 27 ；

00000050h： E4 60 15 05 0F 36 D1 E3 DF B1 53 65 13 43 EB 3E ；

00000060h：B1 33 10 F0 79 5B B6 24 7C 2A 4A E0 7C 99 05 13 ；

怎样试呢，还是异或。取0x42处末尾的字节0xDB与空明码文件的0x42处字节异或，取0x62处的加密标志与空明码文件0x62处字节异或，然后再把取得的两个值相异或：

(0xDB^0xBE)^(0x10^0x0C)=0x79 嘿嘿。这个值是Ascii的"y"，然后取下一个字节（记得隔一个字节取一个）

(0x89^0xEC)^(0x10^0x0C)=0x79 咦，原本这个字节应该是"e"的，怎样变成"y"了？试着不与前面的两个异或值相异或，只计算0x89^0xEC=0x65 失去"e",哈。这下对了。下一个

(0x14^0x65)^(0x10^0C)=0x6D 失去"m"，下一个

(0xF9^9C)=0x65 失去"e"，留意这里只是这两个数异或。前面的大家可能本人试。

这样就总结出规律来了。

解密时，先取出加密文件从文件头末尾0x62处的字节，与空明码数据库文件第0x62处相异或，失去一个加密标志。

再从0x42处末尾每隔一个字节取一个字节，取得13个加密后的明码字节，分别与空明码数据库文件0x42处每隔一个字节取得的13个字节想异或，失去13个明码半成品。为什么说是半成品呢，由于还要将13个字节的明码每隔一个字节，就与加密标志相异或，最后失去的13个字节才是真正的明码。当然，假设中间有0x0的字节，则阐明明码位数不够13位。间接show进去就可能了。