软件加密时保护软件著作权要注意避免的思路误区

软件加密时保护软件著作权要注意避免的思路误区

一、问题的提出

   首先引用有关“ECC加密算法”介绍的原文结尾部分内容：

“七、椭圆曲线在软件注册保护的应用
.......
软件验证过程如下：（软件中存有椭圆曲线Ep(a,b)，和基点G，公开密钥K）
.......

4、如果H=Hash 则注册成功。如果H≠Hash ，则注册失败。

.......

Cracker要想制作注册机，只能通过软件中的Ep(a,b)，点G，公开密钥K ，
并利用K=kG这个关系获得k后才可以。而求k是很困难的。

练习：
.......
软件验证过程如下：(软件中存有椭圆曲线Ep(a,b)，和基点G，公开密钥K)
.......

5、如果v=x’ 则注册成功。如果v≠x’，则注册失败。”

 一般说来，如果编码算法本身具有起码的强度，而且没有变形（等价）算法等漏洞，被该编码算法保护的软件，解密者的确不大可能在短期内有针 对性地开发出实用的注册机，前提是无法改动被保护软件代码。问题是国内外的Cracker是很聪明的，如果发现不能很快地破解出“有效”的注册码，就会直 接或间接“篡改”被“Crack”的软件代码，比如将上述

    “ 4、如果H=Hash 则注册成功。如果H≠Hash ，则注册失败。”
    “ 5、如果v=x’  则注册成功。如果v≠x’  ，则注册失败。”

 所涉及的显式或隐式条件判断语句“转向”而让程序代码违背软件作者的意愿“流动”。

 所以，简单地通过条件判断语句来“甄别”合法用户，可能是保护软件著作权思路里普遍存在的一个明显误区！而且由来已久，特别是在用C语言编写的软件里，这样的例子不胜枚举。

 一旦进入这个误区，那么不论应用软件的认证模块里使用何等保护强度的编码算法，也不论该编码算法是基于对称密匙还是非对称密匙，都难逃被“Crack”的命运，原因就在于“简单地通过条件判断语句来‘甄别’合法用户”导致应用软件著作权的保护异常脆弱！

 就连专业公司都存在这样的安全隐患，国内某专业生产微机安全产品的公司，在其号称异常“坚固”的加密组件里，尽管是基于RSA编码体系，遗憾的是，由于存在上述思路误区，仅仅只花了2天时间，竟然在一台Pentium 150MHz的机器上被破解。

 可见目前这个误区普遍没有引起足够的重视，情况令人担忧。

 大家都知道，对用户输入的涉及著作权的各项认证信息，软件作者都会将这些认证信息作为原始算子，参与认证模块里软件作者“处心积虑”构造的越来越 复杂的运算，甚至罕见的特殊指令都被应用了。目的只有一个，就是通过异常严格的认证过程来保护自己的软件著作权，问题是如此“费尽心思”得到的认证结果， 被简单地应用在一次条件判断语句上，判断一结束，认证结果也随即丢弃了，顶多也就是在软件的其它模块里再“依葫芦画瓢”地多来几次相同的条件判断。比如上 述原文里的“H”及“v”只是简单地参与了一次条件判断就可能被丢弃了！如果“H”及“v”能得到更好地“应用”将使得该保护更强壮。

 可能有同行会说，为防止Cracker直接“篡改”软件代码，对软件加上保护“壳”好了，但是大家要知道，加保护“壳”的做法实际上并不可靠，这体现在二个方面：

 1、这是以牺牲被保护软件的性能甚至稳定性为代价的，被层层“包裹”了保护“壳”的软件（似乎获此“待遇”的往往是应用软件），在此微机可以运 行，换一台微机特别是基于不同处理器体系结构的微机上却运行不稳定甚至不能运行，越是“强悍”的保护“壳”就越容易遇到这样的问题。

 上述问题的原因在于标称“强悍”的保护“壳”为防止被“调试”而在该保护“壳”的解码过程里，对其有读写“权限”的硬件寄存器/系统核心数据表等 重要系统资源持续“复位/篡改”，真可谓“各显神通，无所不用其极”！而这些做法，稍有疏漏或因为计算环境的变化，被保护软件就可能运行错误甚至导致操作 系统瘫痪。如果被保护软件连稳定运行（可再现计算结果）这个起码要求都打折扣，保护“壳”还有意义么？

  2、再“强悍”的保护“壳”最后还是要在其解码的过程里“还原”被保护软件的，而不论其是逐步还原或是一次性全部还原。这就应了“以己之矛攻己之盾”的老 话，所以不管如何“强悍”的保护“壳”，一经推出，很快就会出现解除该保护“壳”的软件，而不论该软件是通用的或是有针对性的。公开发行特别是通过互联网 发行的软件，面对的是国内外的潜在用户群，其著作权（商业秘密）保护思路（方式）面临的挑战也将直接来自国内外技术一流的Cracker。

 可见，用保护“壳”来保护软件著作权，不能真正可靠地保护软件著作权！至少在防止Cracker“篡改”软件代码方面。

 当然，有能力开发保护“壳”的程序员水平都是一流的！行业主管部门在这些方面也是鼓励“百花齐放、百家争鸣”的，自然界里同样存在“生物多样 性”。可执行文件的保护与破解本来就是矛盾的一体二面，保护“壳”的推陈出新也直接促进了相关技术的长足发展，如果将这些“对抗性实战”案例作为“基础教 育”予以普及一定可以培养更多的后起之秀。

 问题是我们更要将注意力放在主要方面，要思考最“根本”的问题，毕竟保护“壳”技术只是计算机信息安全领域里很小的一个方面。大家是否还记得海南 “军机”碰撞引发的Hacker大战？大家就一定明白我们自己的弱势在哪里了！少数西方发达国家对我们实施技术封锁，不管这些技术是民用还是军用。比如加 密强度稍大些的设备（软件）就被其列入所谓的“战略物资”名单实施出口管制，每次我国推出自行研制的新型“超级”计算机，西方发达国家就不得不相应放宽其 出口管制。“落后就要挨打”只有“自强不息”才能“振兴中华”！

 明白了保护软件著作权思路里普遍存在的一个明显误区，那么如何才能避免走入这个误区？怎样才能更有效地保护我们的软件著作权（商业秘密）？

二、问题的解决

 我们知道，每一套应用软件都有其作者值得骄傲或特别着力的地方，具体体现在软件里有限的几个核心功能上，而这些核心功能的代码正是其作者需要花大 力气保护的，前述“千辛万苦”得到认证结果，既然不能简单应用在一次条件判断语句上，那么怎样才能更好地应用这个“来之不易”的认证结果呢？从而使我们的 应用软件著作权（商业秘密）得到更有效的保护！

 关键在于认证工作的“继承”上，如何继承——

  “不论前述认证结果正确与否，都将该认证结果再次作为算子，经过必要运算后对发行前已受保护的软件核心功能代码进行解码”。

 当然，我们强调软件核心功能代码在发行前已被保护，而且是被长度至少为128位即16个字节的单向HasH密匙保护（相应地采用经广泛测 试的稳健的算子长度至少为128位的编码算法如128位MD5等）。应用软件如果没有正式注册，核心功能代码自然未被解码，用户也会被提示“功能受限，建 议注册”。

 如此保护后，如果编码算法没有明显漏洞，要想“Crack”如此加密强度的被保护软件除了穷举，可能短期内很难找到其它的实用方法，这样的保护壁 垒会让相当一部分使用常规手段的Cracker望而却步了——要知道算子长度至少为128位的稳健编码算法，要破解之需要大功率计算机或者性能优异的并行 算法，而这些对于注册费用低廉的Shareware来说，已经没有意义了。而“穷举”又具有相当的难度！

 万一128位单向HasH密匙泄露，软件作者只需“简单”地在新版本里改用新的128位单向HasH密匙重新对核心功能代码进行编码保护后再发行即可！保护“壳”方法可没有如此简单的“快速反应机制”。

 即使退一万步，如此保护的软件还是被一个“天才”一夜之间成功破解，那么软件作者只要再次“简单”地在新版本里改用256位甚至更长的单向HasH密匙重新对核心功能代码进行编码保护即可！保护“壳”方法同样没有如此简单的“快速反应机制”。

 通过上述对软件著作权的有效保护，软件作者可以将工作重点完全放在如何开发功能更强大的应用软件或完善软件的核心功能，而不再每次发行一个新版本 之前都必须“煞费苦心”地设计保护软件著作权的认证模块，这将有力地促进我国应用软件的品质达标！而且应用软件的非核心功能的代码完全可以“明码”出现 ——不需要“保护”，只要Cracker愿意，想反汇编就反汇编好了，想逆向工程就逆向工程好了。这也最大限度地保证应用软件的测试进而保证应用软件的稳 定性，因为程序里未被保护的“常规”指令都在相当“常规”地被处理器逐一执行，被保护前的软件核心功能也是由“常规”指令实现的，而单向解码指令又是相当 “常规”的“移位”、“异或”以及四则运算等！所有的这些“常规”就意味着软件代码的“简单”——“简单就意味着效率，简单就意味着稳定”！

 惟独被保护的核心功能代码，在解码前只能是“一团乱麻”不具可读性，而技术一流的Cracker面对的不是保护软件著作权技术参差不齐的应用软件 程序员，而是面对经过广泛测试的世界级的成熟密码学实践成果，“义无返顾”地破解，结果要么是Cracker震惊世界密码学界，要么则是让Cracker 无功而返。当单向密匙长度超过1024位的时候，恐怕只有.......才有兴趣，才有能力破解。

 对于成功破解128位或以上单向密匙的Cracker，我个人认为，只要这位Cracker不扩散因成功破解而得到的128位甚至更长的单向密 匙！作为软件作者对其的奖励，尽管放心让这位“天才”Cracker“合法”使用这个破解的“注册”版本好了，因为面对其成功破解，软件作者也不得不表示 佩服！

 可能有人会说，那只要向软件作者“正式”注册一次（对于注册提供“网上支付”的软件甚至使用“黑”信用卡）不就得到那令人“梦寐以求”的128位 甚至长度更长的单向HasH密匙了？你还别说，这“损”招还真的管用，只是这对于稍有个性的Cracker来说，却是不屑的。

结论

 关于如何更有效地保护软件著作权，我的个人建议（仅供参考）：

 a、公开发行的应用软件里的核心功能代码被长度至少为128位即16个字节的单向密匙保护（必须采用严格的128位或以上的编码算法）；
 b、对用户输入的各项认证信息进行认证后产生一个长度至少为128位即16个字节的单向HasH密匙；
 c、产生的单向HasH密匙整体不参与任何条件比较，不论其正确与否都在合适的时候作为算子经必要单向运算后参与核心功能代码的解码；
 d、核心功能代码被解码后，如果是真正的“合法”用户，核心功能自然顺利执行，否则应用软件提示出错（肯定会出错的）。

 至于如此保护后是否还需要为公开发行的软件加上保护“壳”呢？这点随个人习惯好了。

 如此这般地说了一通，只是想表达一些自己很早就有了的看法，希望通过贵学院，转告即将成为Cracker的后期之秀，是可以让其少走弯路的，希望不久的将来，计算机信息安全这个行当不再由外国人唱独角戏了

相关业界关注:
当前流行的一些软件保护技术(2011-10-28)

软件加密时保护软件著作权要注意避免的思路误区(2011-9-1)

谈谈软件保护方法的升级进化,(2011-8-25)

软件产品防盗版技术(2011-8-24)

软件加密锁编程技巧(2011-8-3)

jsp加密狗,php加密狗,ASP.NET加密狗,java加密狗,bs加密狗,asp加密狗,课件加密狗,flash加密狗,swf加密狗

地址:深圳市福田区梅秀路深华科技园1栋5J7 | 邮编:518008 | 电话:0755-88865755,(0)138-2326-5258 | 传真:0755-83273525
电邮:se-euse.cn | 关注咱们：
北京代理:中科神州（北京）信息技术有限公司|电话:010-82170250,(0)137-0124-0303|电邮:yubin816-gmail.com

  本网站版权归深圳市易用信息技术有限公司所有   |   粤ICP备09056668号-2  始自2003年

合作伙伴招募中：

上海,广州,杭州,宁波,南京,无锡,佛山,苏州,天津,成都,大连,济南,青岛,烟台,泉州,常州,东莞,武汉,沈阳,金华,南通,重庆,郑州,福州,温州,长沙,厦门,绍兴,西安,哈尔滨,合肥,珠海,包头,昆明,太原,湖州,汕头,惠州,广东,山东,江苏,浙江,河南,河北,辽宁,上海,四川,湖北,湖南,福建,北京,安徽,内蒙古,黑龙江,广西,陕西,吉林,天津,山西,江西,云南,重庆,新疆,贵州

友情连接: flash加密防盗版保护 seo工具 铁卷防泄密 纵横网络 软件项目交易网 深圳工作流系统 局域网管理软件 YCanPDF