共享软件加密的一些误区及防破解的实用招法

1. 不要太相信注册表所以把注册码之类的敏感信息放在里边2. 不要调用系统时间看是不是试用期已过，可以调用一些系统文件的创建时间3. 不要将敏感信息以明文的形式写在程序中，防止直接十六进制查看4. 加密或验证部分与软件主体部分耦合度要高（虽然不便维护）5. 不要对注册码进行明文比较，防内存补丁，至少md5后比较6. 不要将出错提示信息紧跟在加密判断之后，防直接查找字符串，快速定位破解7. 检查自己的进程的父进程是否为Explorer.exe，不是就Kill掉，甚至Kill自己8. .net winform程序，最好先混淆，或加密，不然被轻易破解机率为100%共享软件加密的一些误区本文发表于《电脑软件编程与维护》2005年12期作者：星轨（oRbIt）E_Mail ：inte2000@共享软件通常是指那种采用“先使用，后付款”的方式发布的软件，这类软件通常有两个（或多个）不同的版本，公开发布的是一个功能受限制或使用时间和次数受限制的共享版本，只有当用户购买（或注册）之后才可以使用没有限制的正式版本。

共享软件从出现的那一天起就深受破解者（Cracker）的“喜爱”，因为相对于防范较为严密或使用硬件加密的商业软件来说，共享软件是比较容易破解的。

虽然许多共享软件的作者也采用了时间限制或注册码校验等方法保护自己的软件，但是多数共享软件的作者对软件加密与解密技术不了解，对加密方法的应用和代码编写过程中存在许多漏洞，从而使看似很可靠的加密方法形同虚设。

软件破解者（甚至是一些菜鸟级的Cracker）只需要参照网络上的破解教程，按图索骥，就能够去掉一些软件的使用限制，或从内存中抓出正确的注册码，破解高手甚至能够写出注册机，这无疑是宣告了这个软件的死刑。

本人也发布过共享软件，经历过软件刚刚发布就被破解的尴尬，痛定思痛之后，开始研究软件加密与解密之道。

思之靡多，终有所悟，其实软件加密与解密之间的斗争，道高一尺则魔高一丈，但是最终往往不是技术致胜，而是心态致胜，从软件破解者的心态考虑加密问题，常常能够兵出奇处，以奇致胜。

从软件破解者的角度考虑，以下是一些软件作者常犯的一些错误，本人把它们列举出来，希望对广大软件作者能有所帮助：过分相信Windows注册表的复杂性注册表是Windows系统存储关于计算机配置信息的数据库，所有的数据都是通过一种树状结构以键和子键的方式组织起来，每个键都包含了一组特定的信息，通过键的名称和路径可以查询和修改这些信息。

许多共享软件地作者都将一些比较重要的信息，比如注册信息或时间、次数限制存放在注册表中，以为注册表结构复杂，藏一些数据别人找不到。

其实这是一个错误的认识，破解者利用一些注册表操作工具很容易就能获得数据在注册表中的存放位置。

RegMon就是一款注册表监视软件，它能够监视系统中运行的程序对注册表的读写操作，一切诡秘在它面前都将大白于天下。

还有一个名为RegSnap的软件，它的工作原理就是通过比较程序运行前后注册表的变化确定程序在注册表中的读写位置。

由此可见，在注册表中存放信息是不安全的，至少要对存储的信息数据进行加密处理。

信息以明文的形式写在程序中C/C++语言的编译程序对代码中出现的字符串通常不作特殊地处理，直接将其按照数据出现的顺序排放在数据段中。

一些软件作者没有注意到这一点，导致程序中使用的一些敏感信息以明文的形式出现在可执行程序中，比如注册表某个键的路径、某个文件路径以及加载的外部动态库名字等等。

破解者使用WinHex之类的十六进制编辑软件打开程序文件就可以看到这些信息。

图（1）就是用十六进制编辑器打开某软件的截图，从中可以看到这个软件可能动态加载了RegKey.dll这个动态库，可能还操作了注册表Software\Microsoft\Windows\ArtComp\RegInfo位置下的某些键。

图（1）可执行文件中的字符串C/C++程序的设计者稍微修改一下代码就可以避免这种简单的信息泄露，比如字符串“RegKey”，可以在程序中这样声明字符串数据：static LPCTSTR lpszKey = _T("SfhLfz");其实就是将每个字母向后移了一位（数值上增加1），使用前稍作处理：TCHAR szBuffer{32};lstrcpy(szBuffer,lpszKey);for(int i = 0; i < lstrlen(lpszKey); i++)szBuffer[i]--;//此时szBuffer中就是“RegKey”的原文加密或验证部分与软件主体部分耦合度太低基于软件工程思想考虑，应该尽量降低软件模块之间的耦合度，但是对于软件加密来说，耦合度越高则加密强度越高，对注册码的验证最好不要封装到独立的函数或模块中。

许多软件作者喜欢将加密或注册信息验证部分的代码封装到一个函数中，在程序中这样使用：if(CheckRegCode(szRegCode) == TRUE){//注册信息正确，执行正常的功能}else{//注册信息不正确，提示错误}这种封装看起来使程序代码结构良好，便于代码的组织与维护，但是也为破解者提供了良机。

这样的程序通过反汇编之后通常有以下结构：push 00406070 '字符串szRegCode参数入栈call 00401050 '调用CheckRegCode函数test eax,eax '判断CheckRegCode返回值je 00401029 '跳转到出错位置' 注册信息正确，顺序执行从上面的汇编代码可以看到，只需将执行跳转的je指令（机器码是740B）改成两个NOP （CPU空操作指令，机器码是90）就等于忽略了对CheckRegCode函数返回值的判断，也就是说，无论这个函数返回TRUE还是FALSE，真正的功能代码都会执行，对注册码的校验就形同虚设。

破解者根据指令的内存偏移地址计算出在可执行程序文件中的文件偏移位置，直接修改可执行文件就达到了破解这个功能的目的。

此外，破解者还知道校验函数的位置是00401050，也就可以直接修改这个函数的代码，将函数开始部分的代码改成：mov eax,1 ' 机器码是B801ret ' 机器码是C3也就是说根本不判断注册码，直接返回1（校验成功的标志），就能够使整个软件的注册码校验功能失效，软件被彻底的破解。

还有一些软件作者为了软件开发的便利，将注册码的计算和校验功能封装到一个单独的动态链接库中，在软件安装过程中将其安装在系统目录中，以为这样就可以神不知鬼不觉了，其实不然，破解者利用SoftICE之类的系统级调试工具在系统的LoadLibrary（根据编码的不同可能有LoadLibraryA和LoadLibraryW两个版本）API上下断点，就可以获知程序所有的动态库加载动作，对注册码进行校验的动态库也不例外。

知道这些信息之后，破解就变得简单了，无需修改主程序文件，只要将这个动态库替换掉就可以破解这个软件。

比如，某软件使用名为“SysSec.dll”的动态库完成注册码校验功能，这个动态库有一个导出函数，函数原型为：BOOL WINAPI CheckRegCode(LPCTSTR lpszCode);破解者只需编写一个同名的动态库，也实现一个同名且同类型的导出函数，函数内容仅仅是返回TRUE：BOOL WINAPI CheckRegCode(LPCTSTR lpszCode){return TRUE;}然后编译这个动态库，将其复制到系统目录覆盖原来的动态库，这样软件运行过程中会调用破解者的动态库，结果可想而知。

网上有很多免费或收费的加密算法库，这些库往往不提供源代码，软件作者在使用这些库的时候一定要慎重，原因很简单：首先，这种用法导致加密模块与主程序耦合度不高，很容易被破解者“切开”；其次，这些公开的库就是软件破解者的众失之的，一旦某个破解组织推出了针对这个加密算法库的破解补丁，那么所有基于这个加密算法库的软件就都被破解了。

可见，对于软件加密来说，应该尽量增加加密模块与主程序的耦合度，将加密或校验代码嵌入到程序代码中，虽然给代码的组织和维护带来了困难，但是提高了软件的安全性，正所谓有得即有失，鱼和熊掌不可兼得。

对注册码进行明文比较现在网上流行的大部分共享软件都是采用“用户信息/注册码”方式进行加密的，它的使用过程一般是用户把自己的用户信息（用户名、机器特征码等）通过网络或其他方式发送给软件作者，软件作者根据用户信息利用预先设计好的算法计算出一个注册码，然后将此注册码发送给用户，用户得到注册码后按照软件说明的注册步骤在软件中输入用户信息和从软件供应者那里得到的注册码，如果注册码正确就取消时间或功能的限制，成为正式版本。

这种保护方法实现起来简单，不需要额外的成本，用户不仅购买方便，还可以根据自己的注册信息得到售后服务。

“用户信息/注册码”方式的验证过程其实就是验证用户信息到注册码之间的数学映射关系，这个映射关系通常是由软件开发者制定的，而且映射关系越复杂就越不容易被破解。

以用户信息做自变量，E表示映射函数，则该映射关系可被表示为以下映射函数：注册码＝E（用户信息）映射函数（1）应该说，只要映射函数E足够复杂，这个映射就是安全的，但是问题往往出在映射函数的两端，也就是作为自变量的用户信息和作为结果的注册码，这两部分都是以明文的形式传递的，如果处理不当就会露出破绽，正所谓良玉其内，败絮其外。

以下是软件作者常用的注册信息校验方式：TCHAR szUserName[32];//存放破解者输入的用户信息（假设是Cracker）TCHAR szRegCode[64]; //存放破解者输入的注册码（假的，假设是ababababab）TCHAR szRealRegCode[64];CalculateRegCode(szUserName,szRealRegCode);//szRealRegCode得到了内部计算的正确注册码if(lstrcmp(szRegCode,szRealRegCode) == 0){//输入的注册信息正确}else{//输入的注册信息不正确}这段代码的问题在于CalculateRegCode函数调用之后，内存中就存在了正确的注册码的明文，保存在内存地址szRealRegCode处，通常情况下破解者不知道这个内存位置，但是借助SoftICE之类的调试软件就很容易跟踪到这个位置。

比如，程序为了验证注册信息是否正确需要从注册窗口界面得到用户信息和用户输入的注册码，这些操作最终是通过调用Windows的API GetWindowText（根据编码的不同可能有GetWindowTextA和GetWindowTextW两个版本）或GetDlgItemText（根据编码的不同可能有GetDlgItemTextA 和GetDlgItemTextW两个版本）完成的，破解者利用调试软件在这些函数上下断点就可以跟踪到szRegCode（存放破解者输入的假注册码）的内存地址。