T
ty123
Unregistered / Unconfirmed
GUEST, unregistred user!
中文部分
1.共享软件如何防破解
首先要说的是任何软件都会被破解，下面所讲到的方法只能起到一定的保护作用，延长破解时间。如果想永远都不被破解，那么只有一个办法：不要把它做出来。
让我们来做出最简单的注册验证算法。
1、简单的讲，就是一个数值(a)通过某种运算方法(c)变成另一个数值(b)方法。举个例子，a1=b1 xor c1，a1就是a，表示用户名；b1就是b，表示注册码；运算部分x xor c1就是运算方法c。根据用户名a1通过上面的表达式生成b1（当然运算方法c只能你自己知道），用户得到a1和b1，输入到软件中，如果它是成立的，表明注册成功，当然不成立则表示注册失败。
上面的例子非常简单，主要说明注册的原理。当然用它做注册算法，普通的用户是无法破解出来，但对于一些喜欢破解软件的人来说当然太简单了。下面让我们做出一个复杂的注册算法。
2、更为复杂的算法－－RSA，这种方法和上面的方法原理基本一样，但可以生成更为复杂的注册码，其用法和源代码可以在网上找到。注意的事是选择的参数不要太长，如果太长很麻烦，也不要太短，太短很容易被破解，用多长的注册码最好呢，以目前主流电脑上一秒种完成验证的时间长度为最好。
用RSA做注册算法理论上是做不出来注册机，但事实上仍然可能做出注册机。所以我们把它和一些其它方法配合使用。
3、不要忘了你自己也可以做注册算法的，当然你不可能做出超过RSA的算法，但你的算法仍然是很有威力的，原因在于你的算法是独特的。如果破解者对你的算法非常熟悉，再好的算法也没用，但如果破解者对你的算法不清楚，即使很容易，他也要思考一下。好了，我相信你已经做出了一个类似a1=b1 xor c1的注册算法，我们的软件现在不会那么容易就被破解了。
现在告诉你一个很不幸的消息，由于你的独特算法，破解者已经对你的软件很感兴趣了。那么我们不得不使用更好的方法来保护你的软件。
3、我们可以使用更多算法来增加难度，如何增加呢？首先不要使用明码比较，也就是不要直接用a1与b1 xor c1比较，而要使用a1 xor c1和b1 xor c2比较的方法（其中a1 xor c1和b1 xor c2都是运算方法c），因为这样破解者就不容易做出注册机。另外，要许多算法同时使用，比如说a经过算法c得到d，d通过算法e得到f。这样破解者就不得不把所有的算法都破解出来才行。看来要破解你软件的人不得不搞清你所有的算法，而不单单是其中的一种。
可为什么还有那么多软件被破解？因为你的算法再难，破解者总有一天也会搞清楚了它们，我们可不能让他们看清楚我们的算法。那只有一种办法。
4、化整为零。由于破解者在破解时一般都是分析你软件的代码，因此只要找到软件中负责注册验证的部分，你再高明的算法也无济于事，但如果它找不到你用于注册验证的全部算法就另当别论了。代码都在程序中，如何使破解者找不到呢？非常简单，在软件开始进行验证时不全部验证，而是保留一部分，这就要求你的注册码必须在原先已有的基础上再加入一些新东西。我们现在新加入一部分注册码，我们把它们加在原来注册码的后面，你生成的注册码前n位都是原来的部分，它们由原来的验证部分－‘机枪手’来处理；而另外新加入的n位注册码是由你刚刚加入的新算法负责处理的，我们称这部分新加入的算法为狙击手。那么你最好让你的狙击手可以独立使用，比如可以让其中的1个狙击手瞄准用户名的第一个字母，如果这个字母是在a到g的范围内则狙击手所负责的这位注册码为1时表示正常；否则就代表注册失败。这样新加入这部分注册码自然可以很简单分成了n个独立的部分（注意的是我们只需要每一个狙击手都可以独立使用，不需要它很复杂，越简单越好）。你可以把你狙击手放到你软件的每一个脚落。当然破解者仍然可以找到它，但在茫茫的代码中找到我们不止一处的验证算法可真够累人的了。我们可以将它们的一部分放入核心代码，另一部分放入普通代码中，比如帮助按钮中。
恭喜你，现在你的程序已经很完善了，一般的破解者已经不是你的对手了。哈哈哈。可你不要忘了，任何软件都会被破的，你只是隐藏了你的某些代码，但如果破解者愿意在你的软件上花几周甚至几个月，总会找到你所有的狙击手。我不得不再次为你的程序担心起来，可你的算法无论怎么做都跑不出你的软件。怎么办？有了。
5、如果更新注册码那么原有的破解不就失效了吗？就这么办，我们更新软件的注册算法，因为现在几乎所有的网站都不提供原软件的下载服务，它们都是把用户连接到你的网站上下载，那么我们修改用于生成注册码的算法c也可以防止破解了，当然我们必须每次都要发信通知我们的用户新更新的注册码，这有点辛苦。不过是累你，不是累我，呵呵
是不是感到每次更新注册码都很累人，没关系，让我们使用一点小魔法吧。
6、现在我们还要保留软件中的机枪手，但把一部分狙击手从程序中清除掉，清除的这些狙击手我们称它为影子狙击手。当然，这时你要假设影子狙击手仍然存在（当然影子狙击手已经不存在了），你仍然生成注册码给你的客户，当然这个注册码中一部分已经是没有意义的数字了，但你仍然要按影子狙击手存在的规则生成，而破解者可以无视影子狙击手的存在，这使得你的软件更容易被破解（注意只是容易了一些，而不是可以随意解破）。现在你的软件被破了，和我们担心的一样，我们不能坐以待毙，现在是影子狙击手出击的时候了，在你的软件增加一个影子狙击手，它的出现使得原有的破解失效，因为破解者只能看到机枪手和普通狙击手，但却无法发现不存在的影子狙击手。主动权在我们手上了，我们可以随时升级软件而不用向每个用户发注册码。如果你愿意，你可以准备20个影子狙击手，这至少可以用上一年。如果你担心注册码太长影响输入，你可以把注册码做成一个reg文件，这样用户收到注册文件后直接点击就可以把注册码写入系统注册表中。
2. 合理利用破解的办法
发布版本中添加隐藏限制，短期不会生效，等用户用上手了之后。在特定情况下提示不能使用。如果你的东西写的好，肯定会有人买的。
然后给一个完整版本的下载连接给用户。不过需要能够监视下载日志，避免完整版本泄漏。
举个例子：你写数据库相关的，那么在SQL语句上面做手脚，比如 where 后面加一个
(select count(*) from """"" ) < 1000
这样那个表中数据小于1000条的时候，工作正常，等他用到一定时候了。数据都进系统了，欲罢不能的时候，只好买了。
这样的限制是没有办法破解的，他没法改你的SQL语句。哈哈。
然后，写一个简单的加密手段，让别人破解。然后让别人传播。越多人用越好，这就是在帮助你的共享软件了。
实在没有人破解，你就自己写一个注册机去0Day上发布。呵呵。
一个方法，抛砖引玉。
3. 关于防止破解-转贴自csdn
刚刚Copy了CXU兄的高论，不知道是否对你有用，接住！
破解永远比加密容易，唉！
假设你的注册部分有300行，你可以分成30个inline函数调用（一定要inline)，func1(),func2()... func30(). 将他们随意放到程序的各个部分，一定不能放在一起（自己能找到就行了）。不要用Memcpy等常用系统调用拷贝注册码，近可能自己写,像Memcpy很好写，性能差点无所谓。经过编译后inline函数展开，注册部分和其他代码混在一起，他要写出注册机就像大海里捞针，在几十万甚至上百万汇编代码里找出有用的注册部分。另外注册码也不要放在一起，假设你的注册码是12位，千万不要用一个12位的数组放注册码，你可以在程序的不同位置定义12个全局字符变量，每个放一位，这样注册码在内存就不连续了。最好再加密处理一下（简单的字符异或就可以），验证时再解密。
非技术方法在中国几乎没有用，这么多有钱有实力的公司的软件都被盗版，你个人还能有什么办法。
忘了说了，只要破解者找不到你验证结束的地方，暴力和Loader破解也没有可能。
很重要的一点是不要用连续内存保存验证用到的变量，尽量将用到的验证临时变量分散定义在程序的不同处，再在验证中，不断转移一些值到其他变量中，对付暴力和Loader会比较有效。
没有必要用复杂的加密算法，更容易成为追踪的目标。只要你将注册部分隐藏的足够好，也没有漏洞，你花1天写的加密算法，破解者可能会花100－1000倍的时间破解。大部分人都会放弃。
你将注册做在一起，就像将你的财宝放在现代保险箱里，虽然非常坚固难以解密，对于开锁高手两分钟就打开了。
而古代海盗用的方法是将财宝埋在海岛上，这样没有藏宝图，对应高手和低手都只有一条路，拿一把铁撬挖，可能要挖一生。程序有那么多代码，你将注册部分藏在里面，藏的好就如同将财宝埋在海岛里。那些所谓的Crackme只是给高手玩儿的现代保险箱而已，用原始的方法可以达到同样效果。
这是农民的方法，我也不会汇编，高深的反破解都不会。
程序一出来就被0day破解了，而且被暴力破解了两次，为了对付0day, 只好想了这么一个农民的方法，结果发现简单的东西比复杂的更有用，古老的方法似乎比现代的更有效。
对于一些比较专业的破解者采用上面的方法也是很有效的但是，还是要避免一些低级失误例如：
不要在内存中直接出现注册码和明显的注册码比较部分
不要给用户太多的有关注册验证的信息
不要接收到注册码后立刻就进行比较，在软件的不同功能处实现验证时的好处还有就是不会立刻执行到验证代码
注册码可以分多次验证可以分成几部分验证可以分成几层验证
验证时，可以尽量多执行一些无用的操作，加上一些象递归之类难于调试追踪的代码，但在其中要穿插实现软件功能的代码否则人家直接就跳了过去…………
反正就是越不引人注意越好：）越乱越好
……………………
这些在一般的破解教程里也都会有的
//如果能找到几个不常见的加壳软件最好！：）
只要能避免这样的低级错误，再加上上面的那些不太难实现的方法可以应付一般水平的破解了//因为大家都怕麻烦：）
只要这些措施得当，一般的破解者都会知难而退：）
不过如果你的软件太好了………………
你还是找一个专业人士与你一起写吧，很麻烦的：）
btw：我只是以前对破解有些兴趣，所以找过些资料懂的其实不多而且没做过破解的事，不要误会我的人格哦：）嘿嘿
4. 共享软件开发常识
一、献给某人的话：
首先说一下，这篇文章仅仅是一个入门、是一个讨论，我也仅站在门外汉的角度上对共享软件开发所需要注意的几个方面进行罗列，文章并不能将所有需要注意的环节写清楚，因而如果你认为此文不好，大可不看。
另外一点，我上面已经提到了，这是给刚刚接触共享软件开发的人阅读的，在他们看来也许能够有些收获，而在于高手看来，这篇文章中所述也许并不值一提，但是请不要忘记，新手在学习类和继承的时候，感觉是多么困难，因而请不要用你那种评委般近乎苛刻的目光对本文进行挑剔。
二、开发需要整体规划：
我们在做大多数事情的时候都需要进行整体规划，共享软件开发也是如此。如果你希望做一套功能完善、健全，能够经得起时间考验的软件，就一定要在开始写代码之前做一个整体的功能列表。
这个功能列表至少应该包括软件的所有功能、功能细节、功能实现的方法，并且为日后可能加入的功能做好充分的准备工作。为什么要这么做呢？原因很简单，如果你在编写的软件中包含多个功能，而功能之间又相互存在某些联系，那么如果你没有进行很好的规划，在编写代码的过程中你就会发现自己的思路越来越乱，直到最后几千行的代码到达“牵一发而动全身”的混乱局面，让你根本就没有可能对软件继续开发下去，结果可想而知。
举个例子，不知道大家知不知道网景公司的浏览器，曾经就因为混乱的开发模式而最终走向了死亡。那是一家大公司，开发团队的程序员很多，而程序员之间没有达到很好的默契，自己做自己的，做到最后竟然把一个功能强大的浏览器做死了。
个人编写共享软件虽然有别于团体开发，然而也可以看作是一个“大脑内部的团体”，你在编写软件的每一个功能的时候，都要充分考虑到其他功能对此可能带来的影响，因而开始之前的规划尤为重要。我曾经编写软件并没有注意这一点，因而一个软件通常要经过两三次的失败，然后在脑子中有了软件的整体印象，才能最终完整，与其这样反复，不如开始就作出完整的需求分析，所谓磨刀不费砍柴功。
三、建立漏洞记录和解决记录：
在编写程序的过程中，共享软件作者也许只有一个人，而所要进行的工作却非常多，美化、编码、调试等等，如此多的工作要由个人独自完成，脑子必然混乱，不要在这里说我牵强附会，谁敢说自己编写程序的时候脑子从来是清醒的？
因而无论是发现了程序中的错误，还是有了更好的想法，都要将它记录下来。如果是程序中的错误，至少应该记录下错误产生的原因、操作过程，并且把错误的解决方案也一同写出来。这样做并不是我个人的经验，任何正规程序开发团体都要建立一个“已知漏洞列表”的漏洞数据库，这是为多人之间配合而设立的此表，而我们虽然只有一个人，但是这个记录也是必不可少的。
想想看，如果你今天写程序已经写到深夜，而正当你准备睡觉的时候，突然想到了程序中的一个错误，如果你没有把这个错误记录下来，等第二天你是否还能记得昨晚临睡觉前所发生的事情？你又要和我叫真，非要说你能记住？好吧，那么假如是30个错误呢？假如你第二天有事情要出去，写代码的工作一定要两个星期后才能继续呢？不要说我走极端，在你看来多么不可能发生的事情也有可能发生，好记性不如烂笔头，将问题记录下来是最牢靠的。
四、注释要内外兼修：
也许有些人看到这条建议又要倚老卖老：我从来只把注释写在代码里面。我不和这些人顶撞，他们既然能说出这种话，说明他们没有遇到过苦头。但是亲爱的朋友们，如果你们还没有什么习惯可言，那么从现在开始要养成这条习惯。
写程序一定要写注释，同时还要写“外部注释”，也就是说你的代码中嵌入注释，同时还要为整个程序或者某个功能模块写份详细的外部说明，这份说明也需早在你做整体规划的时候就制作出来了，如果没有，那么就请在完成每个函数之后将函数的作用、调用方法、实现方法都写出来，写出来的目的无非就是为了更好的维护。
假如你不这么做会怎么样呢？我们做个假设：你的软件经过了3个月的搁置，现在又要继续进行开发了，这次开发的主要目的是完善程序。当你打开了代码之后，你要在代码中不断的阅读自己3个月前编写代码的时候遗留的注释，那写注释也许只是只言片语，从这种断断续续的言语中，你是否还能够回忆起3个月前究竟是为什么写的这些注释吗？
而假若你拥有完整的函数说明，那情况就大不一样了，你只要阅读完整的说明文字，就能够很快的回忆起自己的代码是如何编写出来的。什么？你编程已经达到融会贯通的程度了？那你还看这篇文字做什么？
五、还说注释：
注释的重要性我就不说了，要说的是如果你的代码中某个地方进行了修改，千万不要忘记加上注释，并且暂时不要删除原来的代码，将原来的代码也用注释注上，这里要说明为什么进行更改，原来的代码存在什么问题。
如果你在某个地方进行多次更改，就为每一个更加加上注释和日期，因为我说过，你的代码中的每个函数见也许都相互关联着，它们之间的联系很可能达到牵一发动全身的效果，因而尽可能不要将自己辛辛苦苦编写的代码随便删除，也许那一天你会发现原来曾经认为有问题的代码还要使用，到那个时候想单凭记忆找回来就有些困难了。
六、保留软件的重要版本：
除非你的硬盘很小，否则建议将代码的重要版本都保留下来，原因和上面第5条差不多，因为你不知道什么时候会需要以前的代码，做好备份工作是非常重要的。我曾经参与学校内的某个项目，虽然说是个非常简单的项目，但是每天晚上的时候，我们都要将整个程序的所有代码、文档用刻录机做成光盘，并写上日期保留起来。
虽然说每天的任务之向前推动了一点点，但依然是如此“浪费”的将曾经已经保存过的代码在保存一便，这样做的原因还用说吗？说说吧，原因就是一旦在哪一天你的程序出了问题，直接将上一次的保存拿出来，然后继续开发就可以了。但是如果你每天保存的都只是“当天新写的代码”，那么你就会发现你还要经过一步或多步的“还原”操作，你能保证自己所有新写的代码都不会对原来的代码进行任何修改吗？
另外保存软件的早期版本还有一个妙用，那就是你在制作过程中也许会发现自己的代码有不同的发展方向，这是在一开始并没有发现的。从某一版本开始，你就已经开始策划另一个软件了，那么只要将那个“分支版本”拿出来，从那里开始继续你的工作就可以了。
七、善用免费的公共代码：
也许你有这样一个想法：我要自己完成程序中所有的代码。那样的话我要说你有些傻。网络上有很多免费的代码可以直接应用到你的程序中，当你发现自己正需要某个功能的时候，先到网上找找有没有适合自己的代码，如果有直接用就是了。
记得曾经听过一个笑话，高级程序员和初级程序员遇到相同的问题需要编程解决，初级程序员会查阅资料编写代码，高级程序员会打电话问其他程序员要一份代码，两者不同之处在于后者懂得了“拿来主义”。做为共享软件开发人员，大多数是通过程序解决实际问题，这样就好像搭积木，只要你手里“积木”够多，通过不同的组合就能够写出多个优秀的程序。而前者则更好象是用原始的木料制作积木，做了半天也没有成型的产品，那么前者所做的工作并不是制作软件，而是在制作零件。
当然对于此点在标题中已经鲜明的指出“善用”，便写程序不要一味的编写代码，也不能完全“拿来”，如果是完全的拿来主义，那你不如直接拿一个现成的软件通过修改资源界面痛快。
八、结语：
天下文章没有任何一篇能涵盖古今，即使恢弘的《史记》也无法道尽历史沧桑，更何况不足万字的这么一篇短文？因而你无法通过这篇文章掌握所有共享软件开发需要注意的事项。
另外，对于文章而言，只是一家之词，其中错误难免。但是正象余秋雨先生所说，读文章重在正篇的意义，而不应该拘泥于某些微不足道的问题上。如果楞有人在这篇文章上咬文嚼字，那也只能用可笑两个字来形容。
我希望能够有人来一同交流讨论，总结个人的心得体会，同时我也希望大家不要迷信这种理论性的总结，因为每个人的实际情况不同，在你真正开始进行某项工作的时候，也许你会发现他人的总结并不适合你，因而对于指导性的讨论并没有过多的意义，重在实际应用。
5. 怎么防止软件被破解
Visual CHM 推出已经3个月了，2.0版后我见过几个破解版本，但是到现在都没有一个成功的破解版本，很多朋友问我是怎么加密的，我现在决定公布一下2.X(每个版本的加密方法都是一致的)采用了什么方法防破解。算是对中国共享软件作的一点点微小贡献吧!
首先要防止被写出注册机， 你的软件的注册机一旦被发表， 那你完全有理由做成免费软件了。防止被写出注册机 最简单的方法就是保护你的校验算法，具体的做法就是千万别使用校验函数，把你的校验算法嵌入功能代码里是比较保险的，这样破解者至少要花很多精力去研究那一部分是校验算法。当然这还不够，你还可以把检验算法分散到2个地方，当然更多地方效果会更好，只是将来代码维护起来会很麻烦的。 我想如果不是象WinZIP、ACDsee这样的大牌软件，很少会有人去找出检验算法了（太头疼了）。做完了这些， 你还可以用Aspack,upx之类的压缩执行文件工具做进一步的保护。完了吗？还没有，我这里还有一些更用的东西。 现在的脱壳工具太多了，可以说是没有脱不掉的壳。那怎么办？我这里有一段Delphi5代码更进一步的保护你的软件：
procedure TForm1.FormCreate(Sender: TObject);
Var
exefile :file of byte;
ConstStr:byte;
begin
AssignFile(exefile, Application.ExeName);
reset(exefile);
filemode := 0; //读写属性设置为只读，这样才不会出错！
seek(exefile,5);
//exe文件的第5+1个位置（自己设要查找的位置）
Read(exefile,ConstStr);
//showmessage(inttostr(ord(constmi)));//看看实际是多少（假定为56）
closefile(exefile);
if ConstStr <> chr(56) then
exit;//如果第5+1个位置的值不是56退出（说明你的软件被改动了）
end;
这段代码随时随地都可以加入，真的非常方便。 不过你要注意的是，万一用户的机器染上了病毒怎么办。 保护了检验算法，还要保护什么呢？校验算法只是让Cracker很难写出注册机，但是这还防止不了软件被破解（也就是常说的暴破）。暴破的原理很简单：你的软件写完后编译成可执行文件，当Cracker得到这个软件就可以进行反编译，得到汇编代码。你的那段“If 检验不成功 then
...”，就变成了cmp xx,xx，jp xx,xx。稍微改动一下变成cmp xx,xx，rop，rop，rop，rop。整个前面的校验算法也就作废了。我想应该是没有太好的方法，只是千万不要用明文比较。再想保护深一点就加入一些冗余代码，让Cracker在这堆代码里转的头晕脑涨，你的目的就达到了。
最后，有些话不吐不快。1.（引用别人：）加密是救不了共享软件业的！在好的加密技术也有人能解开的！与其花费时间去加密，不如把自己软件的功能增强些！ 这样可能会有更多的人支持您的！！（整天跳出窗口是谁也烦了）！ 2.我认为Cracker们其实挺可爱。
6. 我的一个回贴
http://www.delphibbs.com/delphibbs/dispq.asp?lid=2353686
西文部分
Defending Shareware Against Cracks
Introduction
(From dictionary.com)
en·crypt (n-krpt)
v. tr. en·crypt·ed, en·crypt·ing, en·crypts.
1. To put into code or cipher.
2. Computer Science. To scramble access codes to (computerized information) so as to prevent unauthorized access.
Thisdo
cument will focus on a very small fraction of encryption. That is, we will only discuss how to protect shareware applications from being pirated using the encrypted keys. While there are many other encryption source code sites, and such on the Internet (see the Links section at the end of thisdo
cument), we will focus on how to create a system that will confuse any cracker and help prevent him/her from cracking your encryption. There are a few points that I need to make about this article outlining assumptions. This article assumes:
- You are a shareware developer seeking a way to protect your shareware program from being pirated
- You are at or near the advanced level
A note about the last assumption: when I say "advanced," Ido
not only mean in programming. In fact, even if you only know a few functions and the basic syntax, you can create an above-average encryption scheme using two often under-appreciated virtues: mathematical talent and creativity. I consider them to be of either equal or greater importance than knowing simple functions. Anybody can throw together an encryption algorithm using a couple of neat functions without any real mathematical thought. However, thisdo
cument is not a tutorial for developing a completely new encryption algorithm. Chances are that you will end up using an already made scheme. So why must one involve mathematical thought in order to develop a *secure* encryption plan? While working to implement a packaged set of code into your application, it would be to your advantage to understand how it works and make any modifications that would either make it faster, more secure, or less faulty. Any modifications you make (provided that theydo
not impair functionality) will make the cracker's job harder. If you go to a common site and grab their encryption code to use, the cracker may have already seen and/or used this code so they know how it works and therefore can crack it with ease.
Now would be a good time to stop and enlighten those of you wondering what a cracker is. For our purposes, cracker is any entity that is trying to bypass your shareware protection. I have written half-a-dozen applications that have been cracked. That means that the protection was circumvented. Usually, after any given program is cracked, source code that will allow anyone to bypass your protection will be released. This program (which can be an executable, text file, or just about anything else
) is called a crack. So crack along with a few suffixes can produce different nouns or verbs.
When I first started considering options for thisdo
cument, I was overwhelmed. I could write a whole book on shareware protection alone! I have been forced to specialize even more than just shareware protection. As always, I choose to be as unique as possible. All across the Internet, you can find source code for various encryption techniques. Here we will focus away from the actual algorithms and more toward methods of implementation and fooling crackers.
Be Creative!
Introduction
I would estimate (please remember, this is only an estimate) that 95% of all shareware programs use a kind of string for the key. Whether it is a number, hex value, serial number, or a plethora of pseudo-random characters, crackers are used to these sort of things. I would also assume that about 4.9% of shareware programs use a file as the key. These are also often called certificates. Basically, instead of having a string, a file is used as the key. This method has been found less likely to be cracked because most crackers only evolve their skills to meet the average requirements (cracking a program protected by a string). The remaining 0.1% comprises of other methods. If you only count current releases, none of my shareware programs are cracked. This is not because they are not popular enough;
in fact, previous versions have been cracked. As far as current releases go, however, both are in the 0.1%. The more creative you are in your techniques, the more the crackers will be confused and go on to crack the next guy's program.
Now let's take a look at those two programs and their general structure. We won't even touch on their function, but instead look at the encryption schemes.
StuffV
The scheme here is VERY unique. Not onlydo
es it require the appropriate programming skills;
it also uses ASP on the server-side for a client-server session. A Microsoft Access Database is kept on the server with a list of all of the registered users. After the user receives confirmation of their registration, they input their name and email address into a form, then
click a button. Upon clicking the button, the user starts the client-server session, requesting an URL like http://www.viratech.com/reg/key.asp?Name=Henry%20Ford&Email=user@host.com&HDSerial=00000000. then
the ASP file (which can be written in VBScript of JavaScript) checks the database to see if the user is registered. If the user is registered, it will encrypt their key and send it back to the client. If the user is not registered, it will deny the request. Also, as a preventive measure, every time someone requests a look up (regardless of whether or not they are found to be registered), the database records the time, source IP, name, email, and HD serial number of the client.
The encryption algorithm used here is very complex and hard to break. This is necessary because the keys are stored in the registry and can be retrieved by any would-be cracker who can find their hidden location. In fact, the algorithm is so complex, it takes the program about seven seconds to decrypt and verify it on a Pentium 233MMX. The algorithm is a derivative of Skipjack, the secret key encryption algorithm used by the US government in the Clipper chip and Fortezza PC card. It was implemented in tamper-resistant hardware and its structure had been classified since its introduction in 1993. On June 24th, 1998, SkipJack was unclassified, and described in the web site of the NIST.
This particular application was not Internet-related. If it was, for example a FTP client, I could have made the application verify registration every time it started. While encryption would still be necessary, the fact that you would not have to store the keys in the registry would be a big plus. Also with this you could keep track of how often the program is started. You could also use something like this to make a 30-day trial a REAL 30-day trial. With most time-limited trials, the user can set his/her computer clock back to regain functionality after the program has expired. However, if the program refers to the server, time should be accurate.
Lines of code: 500+*
Advantages:
-Real-time verification
-Can monitor usage (and with considerable accuracy determine if the user is using the product on multiple computers;
see HD Serial Number under the Precautions section)
-Userdo
es not have to keep track of key
Disadvantages:
-User must be connected to the Internet in order to query the server for their key
-If the server isdo
wn, users cannot retrieve registration codes
* Not counting server-side code
Time Manager
This one is fun! Not only that, but it was a real challenge to implement. Here is what the user sees. After someone registers, they receive an email with a HTML file attached. In the HTML file is their name, their password, and their key. The user then
encounters a form that looks like the following:
As you can see, this is not the typical registration key entry form. It is very unique. The typical cracker after seeing this will say to themself "Ok, time to move on to our next victim."
In this particular program, I am using the Secure Hash Algorithm (SHA-1) along with some simple conversion functions. The result is two strings (name and password) and an image sequence. To enter his or her registration, a user type in their name and password, then
click the Start button. After clicking the Start button, the user has eighty seconds to click all of the images from their key in the correct sequence. It can be fun or annoying, depending on the mood of the user. However it is easier-to-use than one would think. After the key is entered, the user never sees anything about registration again.
The major problem with this system is that some user's email clientsdo
not support attachments. Either that or the user did not know how to open HTML attachments. This is the case in about 10%-20% of registered users. For them, I simply upload the HTML file to my web server and they can browse to it just like any other page. This contingency has never failed me, but there are a few security precautions that should be taken to keep other people from accessing this key. The HTML file can be put in a password protected directory if your host supports it;
also you can give it an unusual name to the HTML file, and turn off directory listings. Another precaution is to ask the user to tell you once they have accessed and printed their key, then
you can remove it from the server.
Lines of code: 400+
Advantages:
-Unique
-Can be fun
Disadvantages:
-User's email client must support HTML attachments
Tips &
Tricks
Introduction
Below are legions of various tips and tricks that will help you make your program more secure. I have learned these through much experience in trying to stop crackers in their tracks. Take them to heart.
Serial Numbers
Throughout shareware history, developers have been looking for ways to enforce their policies. For example, I have seen keys that only work on a hard drive with a certain serial number. This is effective. Perhaps too effective, because if a user re-formats their hard drive, they must obtain another key. This is an inconvenience for the user *and* the developer. After paying for your product, any customer will expect for the program to work without any nags. Imagine their surprise when their key is rejected after a re-installation.
This system is often implemented in a challenge-response scheme. When a user wants to register, they open up a registration screen that contains instructions and a certain string. This string is usually either the hard drive serial number itself or a derivative. then
when you are building the key, you input this string and the final product is specific to computers with that input string that is based on that unique hard drive serial number.
There are distinct advantages and disadvantages to limiting a key to a certain hard drive serial number. On one side it will effectively restrict the user from using the program on any computer other than that on which they gave you their challenge from. However, if the user re-formats their hard drive or gets a new computer, the challenge will change, and because of that the original key will not work. At this point the user is obliged to obtain a new key if they wish to continue to use the program that they have already paid for.
This is one of the distinct advantages of the key system that references an Internet server like StuffV. If the user formats and reinstalls, they simply type in their name/email and get their key. The key *can* be hard drive serial number specific to keep users from simply copying the key from one computer to the next via the registry. However, if the user wants to re-install StuffV, they must go through the form. After they submit the form, the hard drive serial number of that machine is recorded on the server. Therefore I can keep track of how many different serial numbers any StuffV user has registered with.
Check for empty fields
It happens to all of us at some point: we release a product with a major bug. It happens to the big guys too (*cough* Microsoft *cough*)! I have seen people write elaborate and complex encryption codes, but fall victim to an extremely simple error. In fact, it happened to the person who got me started in programming. Josh Straub forgot to add a routine to check the length of the name field in an early version of his QuakeNameEditor, so any user could leave the name empty, type in "0" for the key, and become instantly registered!
Check, check, and recheck
When a user inputs their key into your program,do
n't simply write a boolean variable to the registry, but instead copy the key to the registry. then
, on every execution, check the key from the registry to confirm it. It might even be advisable to check the key at random times in your program, and/or when a function for registered users is called.
A note on variables
When a cracker starts at a program, the typical method is to scan through and monitor all of the variables to try to determine the one that holds the keys and results in a decryption routine. Therefore, if you have a boolean variable named IsRegistered, the cracker will know that all that needs to bedo
ne is to write a modification for your program to always switch the IsRegistered variable on at every execution. Therefore, if you must use a boolean variable, give it a misleading name. However, it would be to your advantage if you could hide it even further. For example, in Time Manager, there are a host of variables that hold numbers that work with the time. When the function to validate the key from the registry is called, I could tell it to write a random value between 30 and 60 to an integer variable if the key is valid, but a value between 0 and 29 if the key is invalid. then
, when I wanted to determine if the program is registered, inside a bunch of other complex functions I could stick in stuff like:
C:
if(tsec < 30) {
HideAdvanced();
}
VB:
If tsec < 30 then
Call HideAdvanced
End if
This is really going to make the cracker's job harder. The only "weak" line in this code is the name of the function: HideAdvanced. It would be better to name it something stealthier. In the case of Time Manager, something like ResetTime might be more appropriate.
(VB Specific) P-Code: The Best
To be honest, I reallydo
not know exactly why it is, but Ido
know that P-Code is harder to disassemble than Native Code. While it is really neat to be able to optimize your program for things like size, speed, and Pentium Pro processors, this makes the cracker's job easier. Also to take into consideration is that native code can also cause other problems such as the compiler executing the program incorrectly.
Discombobulate now!
Your job as a shareware developer is to confuse the cracker in your key system. Again, be creative (yes, that's an order)! Make sure to integrate some of your routines into your main data functions, so it is impossible to figure out. You can add in a simple layer to the encryption scheme that could share a function with the main data functions. For example, in Time Manager, when the user enters their values for the time to start at, the program will take the seconds field and if it is greater than 59, convert it to a new hour/minute/second value. So if the seconds is 150, Time Manager will convert this to two minutes and 30 seconds. This could be used as a primitive mod function. Now imagine the cracker trying to figure that out!
Layer, layer, crack slayer
When the Russians were making their first Atomic bombs, they found that a good way to induce pressure on the Uranium-235 was to stack it in layers with some conventional explosives. For every layer they added the bomb's power was increased exponentially. In the same way, a highly secure program will use multiple layers of encryption. Even if one is a simple Xor routine and another is an easy Caesar algorithm, as long as there is a strong element somewhere, all of the little things will pay off. Here is a sample flow chart of three encryption techniques that we will lovingly call A, B, and C. The terms Name and Key are simply generic;
you can use anything here!
Name >> EncryptA >> EncryptB >> EncryptC >> Key
Key >> DecryptC >> DecryptB >> DecryptA >> Name
It's that simple!
Armed Combat
Introduction
Are you ready to take active measures against crackers? This is for the people who really want to target the crackers in their programs. This isn't easy, and should only be attempted by the best of the best. If you are one of these few, suit up and prepare to brandish your programming sword!
Let me open with an example for an introduction. At one time, I noticed that a certain site was serving a crack to one of my programs. That was the only site that I could find that had it. The site was first brought to my attention when I was looking at the sites that people were coming from on my website statistics. A fair amount of traffic was coming from this page advertising the crack. I decided to set up an ASP script that would separate the traffic coming from this site and the traffic coming from everywhere else
. The traffic coming from that sitedo
wnloaded a version of the program that woulddo
various things to the machine it was ran on, such as deleting all of the DLL files it could. All other traffic was directed to the real thing. A total of 12 copies of the malicious version weredo
wnloaded. I never heard a word about it from anyone. After a while, though, the crack was takendo
wn. Victory.
Looking back now, I see how effective it was. I also can see more clearly how risky it was. I probably could have been legally prosecuted for it. While it serves as a good example of what Armed Combat really is, we will not discuss or promote wreaking havoc on a machine here.
This section will be presented in two sub-sections. In the first we will discuss how to identify when the program is being attacked by a cracker, then
we will discuss what todo
about it.
A big warning that EVERYONE should read:do
n't cross the line. Nothing youdo
should interfere with the end user's experience. If your protection is so elaborate that you're warding off the legitimate users, itdo
esn't matter how good your program or how secure your protection is, you've lost. If a newbiedo
es something wrong or weird and they see a message box saying "GO AWAY YOU CRACKER!" that's not good for business. You want to make a direct distinction of what the end user sees and what the cracker sees. The legitimate user should see a terse and modest key entry form while the underlying code is very complex. then
, the cracker will have to look at the code, trying to figure out what it isdo
ing.
Detection: the first step to protection
Here is where we will test your creativity. I will only give you one possible method of detection here. You can then
either use it or make up your own.
Declare a boolean variable IsRegistered. Set it to false, *never* set it to true.do
checks when you're bringing up the main form. If the variable is ever true, then
your program has been tampered with.
Attack
"Tell me where you at, I will be there in ten seconds flat. You know I got your back, I'll be there just in time to counteract.
- Busta Rhymes, "Fire it up"
Now that we have identified that the program has been tampered with, we can take action. Here we have a few interesting options:
a) Wreak havoc (this will not be discussed)
b) Ignore it
c) Fake the cracker out
There are more than these;
you only need to be (again) creative. If we ignore the variable, we will only have succeeded in wasting some of their time. On the other side, we can also fake them out. How? After detecting that the program has been tampered with, change the program to act as if it were registered. However, encrypt the current date (anything here willdo
, including Xor) and write it to the registry or hide it in some other corner of their computer. Every time the program starts, search for this date. If the date can be found, you have a record of when the tampering was first detected. If the current date is three or more days after when the first tampering was detected, give the cracker a nice message box saying something to the effect of it didn't work, then
either close out the program or let it continue unregistered.
Why the three day period? By the time that point is reached, the user will have probably already distributed the crack to his friends. Eventually it will probably reach the general public. After three days, it will stop working, however. then
, the cracker will be labeled as a lamer in the cracker community.
Sounds pretty easy, huh? Yeah, maybe so. Nevertheless, you must be extremely stealthy about it. If you just put it out there in plain code, maybe the newest of crackers will fall victim to the trap, but the adept will catch on. Be creative and set it's roots deep into the main functions of your program. This is why at the begin
ning of this section I warned that only the best should try this one.
Cracks happen
Eventually, at some point one of your programs will be cracked. That is provided that they are popular enough and that there are enough of them. Whatdo
youdo
then
? Fire up your tools and prepare for battle.
Monitoring
Before you can start to fight against a crack, you have to know that it exists. I am not going to turn this section in to ado
cument outlining how to find a crack for any program. However, some good sites to look at are http://astalavista.box.sk and you can run searches with keywords like "crackdo
wnload YOUR-PROGRAM-NAME-HERE."
It is also a good idea to make friends with some crackers. A lot of them will give you advice on what todo
and what not todo
. They can also help keep a look out for cracks. Actually, tell all of your friends to keep a look out for cracks.
Taking Action
After a crack is released, you must then
try to defeat it. It is generally best to redesign your encryption scheme, as this is the only long-term (hopefully) fix! Unfortunately, it involves re-sending keys to all of your users;
either that or simply issuing new keys upon request (this is generally the best option). To design a fully reliable encryption scheme can take hours, even days. However, sooner or later will be necessary.
After you have completed your changes, you must decide whether or not you want to release a new version. If youdo
decide todo
that, you can't hurt the cracker's reputation as described below. In fact, I wouldn't recommend releasing a new version unless you have a multitude of new features in it. My reasoning is that these features should persuade users to leave the old cracked version and to upgrade to the new version, which they will have to pay for. If youdo
not release a new version but replace all of the old cracked versions, then
the problem should be remedied.
Replacing Files
This topic is often overlooked. When you have a new fix, you want to replace your old program with the new one as soon as possible. The sooner youdo
it, the fewer people that will have the crack, and the more registrations you will have. Consequently, it is extremely important to maintain good control over your distribution points. One of the best schemes to have here is as follows:
Primary: On the same server as your website, you should have direct control.
Secondary: To be used if primary is too slow;
these guys should have MEGA bandwidth. You should have a contact here that has direct control.
3rd-ary: This can be your friend's cable modem that is on 24/7, which you can send ICQ updates to.
In the case that a crack is released, you need to be able to replace the old version very quickly. This is the only thing I have against big servers such as Simtel.Net. It may take days for them to update their files. The same is true for ZDNetdo
wnloads, who insists on having their own copy of your software on their servers. One can be caught having to wait for days or even weeks to get a program updated. Yet I still have my software on their site, for the publicity. Remember that itdo
esn't matter how good your program or encryption is if you go so far as to hinder the real users.
Now, moving on, if you like you can possibly hurt the cracker's reputation. In every crack there is almost always an address at which the user of the crack cando
wnload the main program. Now, let us assume that a working crack has been widely distributed and many users aredo
wnloading your program only to be cracked. After discovering this, here is what youdo
:
a) Fix the program so that the crack no longer works (described above)
b) Adjust the file's dates and times in which they were created
c) Zip 'em up (or whatever youdo
for your distribution)
d) Set the zip date and time to the same as the original
e) Upload
I'll leave the changing of the file information up to you. Now if the cracker claims that you changed the program so that the crack no longer works, he will be putdo
wn. As far as the end users see, the program is the exact same as it was before. But the crackdo
esn't work!
Conclusion
In conclusion, I would like to drive home two main points:
a) Remember, there is no such thing as a program that cannot be cracked!
b) Also remember that if you overdo yourself, you will loose potential customers.do
not cross the line!
That's it! I hope that you learned something from thisdo
cument.
Copyright &copy;
2000 Sense of Security Incorporated All Rights Reserved.
1.共享软件如何防破解
首先要说的是任何软件都会被破解，下面所讲到的方法只能起到一定的保护作用，延长破解时间。如果想永远都不被破解，那么只有一个办法：不要把它做出来。
让我们来做出最简单的注册验证算法。
1、简单的讲，就是一个数值(a)通过某种运算方法(c)变成另一个数值(b)方法。举个例子，a1=b1 xor c1，a1就是a，表示用户名；b1就是b，表示注册码；运算部分x xor c1就是运算方法c。根据用户名a1通过上面的表达式生成b1（当然运算方法c只能你自己知道），用户得到a1和b1，输入到软件中，如果它是成立的，表明注册成功，当然不成立则表示注册失败。
上面的例子非常简单，主要说明注册的原理。当然用它做注册算法，普通的用户是无法破解出来，但对于一些喜欢破解软件的人来说当然太简单了。下面让我们做出一个复杂的注册算法。
2、更为复杂的算法－－RSA，这种方法和上面的方法原理基本一样，但可以生成更为复杂的注册码，其用法和源代码可以在网上找到。注意的事是选择的参数不要太长，如果太长很麻烦，也不要太短，太短很容易被破解，用多长的注册码最好呢，以目前主流电脑上一秒种完成验证的时间长度为最好。
用RSA做注册算法理论上是做不出来注册机，但事实上仍然可能做出注册机。所以我们把它和一些其它方法配合使用。
3、不要忘了你自己也可以做注册算法的，当然你不可能做出超过RSA的算法，但你的算法仍然是很有威力的，原因在于你的算法是独特的。如果破解者对你的算法非常熟悉，再好的算法也没用，但如果破解者对你的算法不清楚，即使很容易，他也要思考一下。好了，我相信你已经做出了一个类似a1=b1 xor c1的注册算法，我们的软件现在不会那么容易就被破解了。
现在告诉你一个很不幸的消息，由于你的独特算法，破解者已经对你的软件很感兴趣了。那么我们不得不使用更好的方法来保护你的软件。
3、我们可以使用更多算法来增加难度，如何增加呢？首先不要使用明码比较，也就是不要直接用a1与b1 xor c1比较，而要使用a1 xor c1和b1 xor c2比较的方法（其中a1 xor c1和b1 xor c2都是运算方法c），因为这样破解者就不容易做出注册机。另外，要许多算法同时使用，比如说a经过算法c得到d，d通过算法e得到f。这样破解者就不得不把所有的算法都破解出来才行。看来要破解你软件的人不得不搞清你所有的算法，而不单单是其中的一种。
可为什么还有那么多软件被破解？因为你的算法再难，破解者总有一天也会搞清楚了它们，我们可不能让他们看清楚我们的算法。那只有一种办法。
4、化整为零。由于破解者在破解时一般都是分析你软件的代码，因此只要找到软件中负责注册验证的部分，你再高明的算法也无济于事，但如果它找不到你用于注册验证的全部算法就另当别论了。代码都在程序中，如何使破解者找不到呢？非常简单，在软件开始进行验证时不全部验证，而是保留一部分，这就要求你的注册码必须在原先已有的基础上再加入一些新东西。我们现在新加入一部分注册码，我们把它们加在原来注册码的后面，你生成的注册码前n位都是原来的部分，它们由原来的验证部分－‘机枪手’来处理；而另外新加入的n位注册码是由你刚刚加入的新算法负责处理的，我们称这部分新加入的算法为狙击手。那么你最好让你的狙击手可以独立使用，比如可以让其中的1个狙击手瞄准用户名的第一个字母，如果这个字母是在a到g的范围内则狙击手所负责的这位注册码为1时表示正常；否则就代表注册失败。这样新加入这部分注册码自然可以很简单分成了n个独立的部分（注意的是我们只需要每一个狙击手都可以独立使用，不需要它很复杂，越简单越好）。你可以把你狙击手放到你软件的每一个脚落。当然破解者仍然可以找到它，但在茫茫的代码中找到我们不止一处的验证算法可真够累人的了。我们可以将它们的一部分放入核心代码，另一部分放入普通代码中，比如帮助按钮中。
恭喜你，现在你的程序已经很完善了，一般的破解者已经不是你的对手了。哈哈哈。可你不要忘了，任何软件都会被破的，你只是隐藏了你的某些代码，但如果破解者愿意在你的软件上花几周甚至几个月，总会找到你所有的狙击手。我不得不再次为你的程序担心起来，可你的算法无论怎么做都跑不出你的软件。怎么办？有了。
5、如果更新注册码那么原有的破解不就失效了吗？就这么办，我们更新软件的注册算法，因为现在几乎所有的网站都不提供原软件的下载服务，它们都是把用户连接到你的网站上下载，那么我们修改用于生成注册码的算法c也可以防止破解了，当然我们必须每次都要发信通知我们的用户新更新的注册码，这有点辛苦。不过是累你，不是累我，呵呵
是不是感到每次更新注册码都很累人，没关系，让我们使用一点小魔法吧。
6、现在我们还要保留软件中的机枪手，但把一部分狙击手从程序中清除掉，清除的这些狙击手我们称它为影子狙击手。当然，这时你要假设影子狙击手仍然存在（当然影子狙击手已经不存在了），你仍然生成注册码给你的客户，当然这个注册码中一部分已经是没有意义的数字了，但你仍然要按影子狙击手存在的规则生成，而破解者可以无视影子狙击手的存在，这使得你的软件更容易被破解（注意只是容易了一些，而不是可以随意解破）。现在你的软件被破了，和我们担心的一样，我们不能坐以待毙，现在是影子狙击手出击的时候了，在你的软件增加一个影子狙击手，它的出现使得原有的破解失效，因为破解者只能看到机枪手和普通狙击手，但却无法发现不存在的影子狙击手。主动权在我们手上了，我们可以随时升级软件而不用向每个用户发注册码。如果你愿意，你可以准备20个影子狙击手，这至少可以用上一年。如果你担心注册码太长影响输入，你可以把注册码做成一个reg文件，这样用户收到注册文件后直接点击就可以把注册码写入系统注册表中。
2. 合理利用破解的办法
发布版本中添加隐藏限制，短期不会生效，等用户用上手了之后。在特定情况下提示不能使用。如果你的东西写的好，肯定会有人买的。
然后给一个完整版本的下载连接给用户。不过需要能够监视下载日志，避免完整版本泄漏。
举个例子：你写数据库相关的，那么在SQL语句上面做手脚，比如 where 后面加一个
(select count(*) from """"" ) < 1000
这样那个表中数据小于1000条的时候，工作正常，等他用到一定时候了。数据都进系统了，欲罢不能的时候，只好买了。
这样的限制是没有办法破解的，他没法改你的SQL语句。哈哈。
然后，写一个简单的加密手段，让别人破解。然后让别人传播。越多人用越好，这就是在帮助你的共享软件了。
实在没有人破解，你就自己写一个注册机去0Day上发布。呵呵。
一个方法，抛砖引玉。
3. 关于防止破解-转贴自csdn
刚刚Copy了CXU兄的高论，不知道是否对你有用，接住！
破解永远比加密容易，唉！
假设你的注册部分有300行，你可以分成30个inline函数调用（一定要inline)，func1(),func2()... func30(). 将他们随意放到程序的各个部分，一定不能放在一起（自己能找到就行了）。不要用Memcpy等常用系统调用拷贝注册码，近可能自己写,像Memcpy很好写，性能差点无所谓。经过编译后inline函数展开，注册部分和其他代码混在一起，他要写出注册机就像大海里捞针，在几十万甚至上百万汇编代码里找出有用的注册部分。另外注册码也不要放在一起，假设你的注册码是12位，千万不要用一个12位的数组放注册码，你可以在程序的不同位置定义12个全局字符变量，每个放一位，这样注册码在内存就不连续了。最好再加密处理一下（简单的字符异或就可以），验证时再解密。
非技术方法在中国几乎没有用，这么多有钱有实力的公司的软件都被盗版，你个人还能有什么办法。
忘了说了，只要破解者找不到你验证结束的地方，暴力和Loader破解也没有可能。
很重要的一点是不要用连续内存保存验证用到的变量，尽量将用到的验证临时变量分散定义在程序的不同处，再在验证中，不断转移一些值到其他变量中，对付暴力和Loader会比较有效。
没有必要用复杂的加密算法，更容易成为追踪的目标。只要你将注册部分隐藏的足够好，也没有漏洞，你花1天写的加密算法，破解者可能会花100－1000倍的时间破解。大部分人都会放弃。
你将注册做在一起，就像将你的财宝放在现代保险箱里，虽然非常坚固难以解密，对于开锁高手两分钟就打开了。
而古代海盗用的方法是将财宝埋在海岛上，这样没有藏宝图，对应高手和低手都只有一条路，拿一把铁撬挖，可能要挖一生。程序有那么多代码，你将注册部分藏在里面，藏的好就如同将财宝埋在海岛里。那些所谓的Crackme只是给高手玩儿的现代保险箱而已，用原始的方法可以达到同样效果。
这是农民的方法，我也不会汇编，高深的反破解都不会。
程序一出来就被0day破解了，而且被暴力破解了两次，为了对付0day, 只好想了这么一个农民的方法，结果发现简单的东西比复杂的更有用，古老的方法似乎比现代的更有效。
对于一些比较专业的破解者采用上面的方法也是很有效的但是，还是要避免一些低级失误例如：
不要在内存中直接出现注册码和明显的注册码比较部分
不要给用户太多的有关注册验证的信息
不要接收到注册码后立刻就进行比较，在软件的不同功能处实现验证时的好处还有就是不会立刻执行到验证代码
注册码可以分多次验证可以分成几部分验证可以分成几层验证
验证时，可以尽量多执行一些无用的操作，加上一些象递归之类难于调试追踪的代码，但在其中要穿插实现软件功能的代码否则人家直接就跳了过去…………
反正就是越不引人注意越好：）越乱越好
……………………
这些在一般的破解教程里也都会有的
//如果能找到几个不常见的加壳软件最好！：）
只要能避免这样的低级错误，再加上上面的那些不太难实现的方法可以应付一般水平的破解了//因为大家都怕麻烦：）
只要这些措施得当，一般的破解者都会知难而退：）
不过如果你的软件太好了………………
你还是找一个专业人士与你一起写吧，很麻烦的：）
btw：我只是以前对破解有些兴趣，所以找过些资料懂的其实不多而且没做过破解的事，不要误会我的人格哦：）嘿嘿
4. 共享软件开发常识
一、献给某人的话：
首先说一下，这篇文章仅仅是一个入门、是一个讨论，我也仅站在门外汉的角度上对共享软件开发所需要注意的几个方面进行罗列，文章并不能将所有需要注意的环节写清楚，因而如果你认为此文不好，大可不看。
另外一点，我上面已经提到了，这是给刚刚接触共享软件开发的人阅读的，在他们看来也许能够有些收获，而在于高手看来，这篇文章中所述也许并不值一提，但是请不要忘记，新手在学习类和继承的时候，感觉是多么困难，因而请不要用你那种评委般近乎苛刻的目光对本文进行挑剔。
二、开发需要整体规划：
我们在做大多数事情的时候都需要进行整体规划，共享软件开发也是如此。如果你希望做一套功能完善、健全，能够经得起时间考验的软件，就一定要在开始写代码之前做一个整体的功能列表。
这个功能列表至少应该包括软件的所有功能、功能细节、功能实现的方法，并且为日后可能加入的功能做好充分的准备工作。为什么要这么做呢？原因很简单，如果你在编写的软件中包含多个功能，而功能之间又相互存在某些联系，那么如果你没有进行很好的规划，在编写代码的过程中你就会发现自己的思路越来越乱，直到最后几千行的代码到达“牵一发而动全身”的混乱局面，让你根本就没有可能对软件继续开发下去，结果可想而知。
举个例子，不知道大家知不知道网景公司的浏览器，曾经就因为混乱的开发模式而最终走向了死亡。那是一家大公司，开发团队的程序员很多，而程序员之间没有达到很好的默契，自己做自己的，做到最后竟然把一个功能强大的浏览器做死了。
个人编写共享软件虽然有别于团体开发，然而也可以看作是一个“大脑内部的团体”，你在编写软件的每一个功能的时候，都要充分考虑到其他功能对此可能带来的影响，因而开始之前的规划尤为重要。我曾经编写软件并没有注意这一点，因而一个软件通常要经过两三次的失败，然后在脑子中有了软件的整体印象，才能最终完整，与其这样反复，不如开始就作出完整的需求分析，所谓磨刀不费砍柴功。
三、建立漏洞记录和解决记录：
在编写程序的过程中，共享软件作者也许只有一个人，而所要进行的工作却非常多，美化、编码、调试等等，如此多的工作要由个人独自完成，脑子必然混乱，不要在这里说我牵强附会，谁敢说自己编写程序的时候脑子从来是清醒的？
因而无论是发现了程序中的错误，还是有了更好的想法，都要将它记录下来。如果是程序中的错误，至少应该记录下错误产生的原因、操作过程，并且把错误的解决方案也一同写出来。这样做并不是我个人的经验，任何正规程序开发团体都要建立一个“已知漏洞列表”的漏洞数据库，这是为多人之间配合而设立的此表，而我们虽然只有一个人，但是这个记录也是必不可少的。
想想看，如果你今天写程序已经写到深夜，而正当你准备睡觉的时候，突然想到了程序中的一个错误，如果你没有把这个错误记录下来，等第二天你是否还能记得昨晚临睡觉前所发生的事情？你又要和我叫真，非要说你能记住？好吧，那么假如是30个错误呢？假如你第二天有事情要出去，写代码的工作一定要两个星期后才能继续呢？不要说我走极端，在你看来多么不可能发生的事情也有可能发生，好记性不如烂笔头，将问题记录下来是最牢靠的。
四、注释要内外兼修：
也许有些人看到这条建议又要倚老卖老：我从来只把注释写在代码里面。我不和这些人顶撞，他们既然能说出这种话，说明他们没有遇到过苦头。但是亲爱的朋友们，如果你们还没有什么习惯可言，那么从现在开始要养成这条习惯。
写程序一定要写注释，同时还要写“外部注释”，也就是说你的代码中嵌入注释，同时还要为整个程序或者某个功能模块写份详细的外部说明，这份说明也需早在你做整体规划的时候就制作出来了，如果没有，那么就请在完成每个函数之后将函数的作用、调用方法、实现方法都写出来，写出来的目的无非就是为了更好的维护。
假如你不这么做会怎么样呢？我们做个假设：你的软件经过了3个月的搁置，现在又要继续进行开发了，这次开发的主要目的是完善程序。当你打开了代码之后，你要在代码中不断的阅读自己3个月前编写代码的时候遗留的注释，那写注释也许只是只言片语，从这种断断续续的言语中，你是否还能够回忆起3个月前究竟是为什么写的这些注释吗？
而假若你拥有完整的函数说明，那情况就大不一样了，你只要阅读完整的说明文字，就能够很快的回忆起自己的代码是如何编写出来的。什么？你编程已经达到融会贯通的程度了？那你还看这篇文字做什么？
五、还说注释：
注释的重要性我就不说了，要说的是如果你的代码中某个地方进行了修改，千万不要忘记加上注释，并且暂时不要删除原来的代码，将原来的代码也用注释注上，这里要说明为什么进行更改，原来的代码存在什么问题。
如果你在某个地方进行多次更改，就为每一个更加加上注释和日期，因为我说过，你的代码中的每个函数见也许都相互关联着，它们之间的联系很可能达到牵一发动全身的效果，因而尽可能不要将自己辛辛苦苦编写的代码随便删除，也许那一天你会发现原来曾经认为有问题的代码还要使用，到那个时候想单凭记忆找回来就有些困难了。
六、保留软件的重要版本：
除非你的硬盘很小，否则建议将代码的重要版本都保留下来，原因和上面第5条差不多，因为你不知道什么时候会需要以前的代码，做好备份工作是非常重要的。我曾经参与学校内的某个项目，虽然说是个非常简单的项目，但是每天晚上的时候，我们都要将整个程序的所有代码、文档用刻录机做成光盘，并写上日期保留起来。
虽然说每天的任务之向前推动了一点点，但依然是如此“浪费”的将曾经已经保存过的代码在保存一便，这样做的原因还用说吗？说说吧，原因就是一旦在哪一天你的程序出了问题，直接将上一次的保存拿出来，然后继续开发就可以了。但是如果你每天保存的都只是“当天新写的代码”，那么你就会发现你还要经过一步或多步的“还原”操作，你能保证自己所有新写的代码都不会对原来的代码进行任何修改吗？
另外保存软件的早期版本还有一个妙用，那就是你在制作过程中也许会发现自己的代码有不同的发展方向，这是在一开始并没有发现的。从某一版本开始，你就已经开始策划另一个软件了，那么只要将那个“分支版本”拿出来，从那里开始继续你的工作就可以了。
七、善用免费的公共代码：
也许你有这样一个想法：我要自己完成程序中所有的代码。那样的话我要说你有些傻。网络上有很多免费的代码可以直接应用到你的程序中，当你发现自己正需要某个功能的时候，先到网上找找有没有适合自己的代码，如果有直接用就是了。
记得曾经听过一个笑话，高级程序员和初级程序员遇到相同的问题需要编程解决，初级程序员会查阅资料编写代码，高级程序员会打电话问其他程序员要一份代码，两者不同之处在于后者懂得了“拿来主义”。做为共享软件开发人员，大多数是通过程序解决实际问题，这样就好像搭积木，只要你手里“积木”够多，通过不同的组合就能够写出多个优秀的程序。而前者则更好象是用原始的木料制作积木，做了半天也没有成型的产品，那么前者所做的工作并不是制作软件，而是在制作零件。
当然对于此点在标题中已经鲜明的指出“善用”，便写程序不要一味的编写代码，也不能完全“拿来”，如果是完全的拿来主义，那你不如直接拿一个现成的软件通过修改资源界面痛快。
八、结语：
天下文章没有任何一篇能涵盖古今，即使恢弘的《史记》也无法道尽历史沧桑，更何况不足万字的这么一篇短文？因而你无法通过这篇文章掌握所有共享软件开发需要注意的事项。
另外，对于文章而言，只是一家之词，其中错误难免。但是正象余秋雨先生所说，读文章重在正篇的意义，而不应该拘泥于某些微不足道的问题上。如果楞有人在这篇文章上咬文嚼字，那也只能用可笑两个字来形容。
我希望能够有人来一同交流讨论，总结个人的心得体会，同时我也希望大家不要迷信这种理论性的总结，因为每个人的实际情况不同，在你真正开始进行某项工作的时候，也许你会发现他人的总结并不适合你，因而对于指导性的讨论并没有过多的意义，重在实际应用。
5. 怎么防止软件被破解
Visual CHM 推出已经3个月了，2.0版后我见过几个破解版本，但是到现在都没有一个成功的破解版本，很多朋友问我是怎么加密的，我现在决定公布一下2.X(每个版本的加密方法都是一致的)采用了什么方法防破解。算是对中国共享软件作的一点点微小贡献吧!
首先要防止被写出注册机， 你的软件的注册机一旦被发表， 那你完全有理由做成免费软件了。防止被写出注册机 最简单的方法就是保护你的校验算法，具体的做法就是千万别使用校验函数，把你的校验算法嵌入功能代码里是比较保险的，这样破解者至少要花很多精力去研究那一部分是校验算法。当然这还不够，你还可以把检验算法分散到2个地方，当然更多地方效果会更好，只是将来代码维护起来会很麻烦的。 我想如果不是象WinZIP、ACDsee这样的大牌软件，很少会有人去找出检验算法了（太头疼了）。做完了这些， 你还可以用Aspack,upx之类的压缩执行文件工具做进一步的保护。完了吗？还没有，我这里还有一些更用的东西。 现在的脱壳工具太多了，可以说是没有脱不掉的壳。那怎么办？我这里有一段Delphi5代码更进一步的保护你的软件：
procedure TForm1.FormCreate(Sender: TObject);
Var
exefile :file of byte;
ConstStr:byte;
begin
AssignFile(exefile, Application.ExeName);
reset(exefile);
filemode := 0; //读写属性设置为只读，这样才不会出错！
seek(exefile,5);
//exe文件的第5+1个位置（自己设要查找的位置）
Read(exefile,ConstStr);
//showmessage(inttostr(ord(constmi)));//看看实际是多少（假定为56）
closefile(exefile);
if ConstStr <> chr(56) then
exit;//如果第5+1个位置的值不是56退出（说明你的软件被改动了）
end;
这段代码随时随地都可以加入，真的非常方便。 不过你要注意的是，万一用户的机器染上了病毒怎么办。 保护了检验算法，还要保护什么呢？校验算法只是让Cracker很难写出注册机，但是这还防止不了软件被破解（也就是常说的暴破）。暴破的原理很简单：你的软件写完后编译成可执行文件，当Cracker得到这个软件就可以进行反编译，得到汇编代码。你的那段“If 检验不成功 then
...”，就变成了cmp xx,xx，jp xx,xx。稍微改动一下变成cmp xx,xx，rop，rop，rop，rop。整个前面的校验算法也就作废了。我想应该是没有太好的方法，只是千万不要用明文比较。再想保护深一点就加入一些冗余代码，让Cracker在这堆代码里转的头晕脑涨，你的目的就达到了。
最后，有些话不吐不快。1.（引用别人：）加密是救不了共享软件业的！在好的加密技术也有人能解开的！与其花费时间去加密，不如把自己软件的功能增强些！ 这样可能会有更多的人支持您的！！（整天跳出窗口是谁也烦了）！ 2.我认为Cracker们其实挺可爱。
6. 我的一个回贴
http://www.delphibbs.com/delphibbs/dispq.asp?lid=2353686
西文部分
Defending Shareware Against Cracks
Introduction
(From dictionary.com)
en·crypt (n-krpt)
v. tr. en·crypt·ed, en·crypt·ing, en·crypts.
1. To put into code or cipher.
2. Computer Science. To scramble access codes to (computerized information) so as to prevent unauthorized access.
Thisdo
cument will focus on a very small fraction of encryption. That is, we will only discuss how to protect shareware applications from being pirated using the encrypted keys. While there are many other encryption source code sites, and such on the Internet (see the Links section at the end of thisdo
cument), we will focus on how to create a system that will confuse any cracker and help prevent him/her from cracking your encryption. There are a few points that I need to make about this article outlining assumptions. This article assumes:
- You are a shareware developer seeking a way to protect your shareware program from being pirated
- You are at or near the advanced level
A note about the last assumption: when I say "advanced," Ido
not only mean in programming. In fact, even if you only know a few functions and the basic syntax, you can create an above-average encryption scheme using two often under-appreciated virtues: mathematical talent and creativity. I consider them to be of either equal or greater importance than knowing simple functions. Anybody can throw together an encryption algorithm using a couple of neat functions without any real mathematical thought. However, thisdo
cument is not a tutorial for developing a completely new encryption algorithm. Chances are that you will end up using an already made scheme. So why must one involve mathematical thought in order to develop a *secure* encryption plan? While working to implement a packaged set of code into your application, it would be to your advantage to understand how it works and make any modifications that would either make it faster, more secure, or less faulty. Any modifications you make (provided that theydo
not impair functionality) will make the cracker's job harder. If you go to a common site and grab their encryption code to use, the cracker may have already seen and/or used this code so they know how it works and therefore can crack it with ease.
Now would be a good time to stop and enlighten those of you wondering what a cracker is. For our purposes, cracker is any entity that is trying to bypass your shareware protection. I have written half-a-dozen applications that have been cracked. That means that the protection was circumvented. Usually, after any given program is cracked, source code that will allow anyone to bypass your protection will be released. This program (which can be an executable, text file, or just about anything else
) is called a crack. So crack along with a few suffixes can produce different nouns or verbs.
When I first started considering options for thisdo
cument, I was overwhelmed. I could write a whole book on shareware protection alone! I have been forced to specialize even more than just shareware protection. As always, I choose to be as unique as possible. All across the Internet, you can find source code for various encryption techniques. Here we will focus away from the actual algorithms and more toward methods of implementation and fooling crackers.
Be Creative!
Introduction
I would estimate (please remember, this is only an estimate) that 95% of all shareware programs use a kind of string for the key. Whether it is a number, hex value, serial number, or a plethora of pseudo-random characters, crackers are used to these sort of things. I would also assume that about 4.9% of shareware programs use a file as the key. These are also often called certificates. Basically, instead of having a string, a file is used as the key. This method has been found less likely to be cracked because most crackers only evolve their skills to meet the average requirements (cracking a program protected by a string). The remaining 0.1% comprises of other methods. If you only count current releases, none of my shareware programs are cracked. This is not because they are not popular enough;
in fact, previous versions have been cracked. As far as current releases go, however, both are in the 0.1%. The more creative you are in your techniques, the more the crackers will be confused and go on to crack the next guy's program.
Now let's take a look at those two programs and their general structure. We won't even touch on their function, but instead look at the encryption schemes.
StuffV
The scheme here is VERY unique. Not onlydo
es it require the appropriate programming skills;
it also uses ASP on the server-side for a client-server session. A Microsoft Access Database is kept on the server with a list of all of the registered users. After the user receives confirmation of their registration, they input their name and email address into a form, then
click a button. Upon clicking the button, the user starts the client-server session, requesting an URL like http://www.viratech.com/reg/key.asp?Name=Henry%20Ford&Email=user@host.com&HDSerial=00000000. then
the ASP file (which can be written in VBScript of JavaScript) checks the database to see if the user is registered. If the user is registered, it will encrypt their key and send it back to the client. If the user is not registered, it will deny the request. Also, as a preventive measure, every time someone requests a look up (regardless of whether or not they are found to be registered), the database records the time, source IP, name, email, and HD serial number of the client.
The encryption algorithm used here is very complex and hard to break. This is necessary because the keys are stored in the registry and can be retrieved by any would-be cracker who can find their hidden location. In fact, the algorithm is so complex, it takes the program about seven seconds to decrypt and verify it on a Pentium 233MMX. The algorithm is a derivative of Skipjack, the secret key encryption algorithm used by the US government in the Clipper chip and Fortezza PC card. It was implemented in tamper-resistant hardware and its structure had been classified since its introduction in 1993. On June 24th, 1998, SkipJack was unclassified, and described in the web site of the NIST.
This particular application was not Internet-related. If it was, for example a FTP client, I could have made the application verify registration every time it started. While encryption would still be necessary, the fact that you would not have to store the keys in the registry would be a big plus. Also with this you could keep track of how often the program is started. You could also use something like this to make a 30-day trial a REAL 30-day trial. With most time-limited trials, the user can set his/her computer clock back to regain functionality after the program has expired. However, if the program refers to the server, time should be accurate.
Lines of code: 500+*
Advantages:
-Real-time verification
-Can monitor usage (and with considerable accuracy determine if the user is using the product on multiple computers;
see HD Serial Number under the Precautions section)
-Userdo
es not have to keep track of key
Disadvantages:
-User must be connected to the Internet in order to query the server for their key
-If the server isdo
wn, users cannot retrieve registration codes
* Not counting server-side code
Time Manager
This one is fun! Not only that, but it was a real challenge to implement. Here is what the user sees. After someone registers, they receive an email with a HTML file attached. In the HTML file is their name, their password, and their key. The user then
encounters a form that looks like the following:
As you can see, this is not the typical registration key entry form. It is very unique. The typical cracker after seeing this will say to themself "Ok, time to move on to our next victim."
In this particular program, I am using the Secure Hash Algorithm (SHA-1) along with some simple conversion functions. The result is two strings (name and password) and an image sequence. To enter his or her registration, a user type in their name and password, then
click the Start button. After clicking the Start button, the user has eighty seconds to click all of the images from their key in the correct sequence. It can be fun or annoying, depending on the mood of the user. However it is easier-to-use than one would think. After the key is entered, the user never sees anything about registration again.
The major problem with this system is that some user's email clientsdo
not support attachments. Either that or the user did not know how to open HTML attachments. This is the case in about 10%-20% of registered users. For them, I simply upload the HTML file to my web server and they can browse to it just like any other page. This contingency has never failed me, but there are a few security precautions that should be taken to keep other people from accessing this key. The HTML file can be put in a password protected directory if your host supports it;
also you can give it an unusual name to the HTML file, and turn off directory listings. Another precaution is to ask the user to tell you once they have accessed and printed their key, then
you can remove it from the server.
Lines of code: 400+
Advantages:
-Unique
-Can be fun
Disadvantages:
-User's email client must support HTML attachments
Tips &
Tricks
Introduction
Below are legions of various tips and tricks that will help you make your program more secure. I have learned these through much experience in trying to stop crackers in their tracks. Take them to heart.
Serial Numbers
Throughout shareware history, developers have been looking for ways to enforce their policies. For example, I have seen keys that only work on a hard drive with a certain serial number. This is effective. Perhaps too effective, because if a user re-formats their hard drive, they must obtain another key. This is an inconvenience for the user *and* the developer. After paying for your product, any customer will expect for the program to work without any nags. Imagine their surprise when their key is rejected after a re-installation.
This system is often implemented in a challenge-response scheme. When a user wants to register, they open up a registration screen that contains instructions and a certain string. This string is usually either the hard drive serial number itself or a derivative. then
when you are building the key, you input this string and the final product is specific to computers with that input string that is based on that unique hard drive serial number.
There are distinct advantages and disadvantages to limiting a key to a certain hard drive serial number. On one side it will effectively restrict the user from using the program on any computer other than that on which they gave you their challenge from. However, if the user re-formats their hard drive or gets a new computer, the challenge will change, and because of that the original key will not work. At this point the user is obliged to obtain a new key if they wish to continue to use the program that they have already paid for.
This is one of the distinct advantages of the key system that references an Internet server like StuffV. If the user formats and reinstalls, they simply type in their name/email and get their key. The key *can* be hard drive serial number specific to keep users from simply copying the key from one computer to the next via the registry. However, if the user wants to re-install StuffV, they must go through the form. After they submit the form, the hard drive serial number of that machine is recorded on the server. Therefore I can keep track of how many different serial numbers any StuffV user has registered with.
Check for empty fields
It happens to all of us at some point: we release a product with a major bug. It happens to the big guys too (*cough* Microsoft *cough*)! I have seen people write elaborate and complex encryption codes, but fall victim to an extremely simple error. In fact, it happened to the person who got me started in programming. Josh Straub forgot to add a routine to check the length of the name field in an early version of his QuakeNameEditor, so any user could leave the name empty, type in "0" for the key, and become instantly registered!
Check, check, and recheck
When a user inputs their key into your program,do
n't simply write a boolean variable to the registry, but instead copy the key to the registry. then
, on every execution, check the key from the registry to confirm it. It might even be advisable to check the key at random times in your program, and/or when a function for registered users is called.
A note on variables
When a cracker starts at a program, the typical method is to scan through and monitor all of the variables to try to determine the one that holds the keys and results in a decryption routine. Therefore, if you have a boolean variable named IsRegistered, the cracker will know that all that needs to bedo
ne is to write a modification for your program to always switch the IsRegistered variable on at every execution. Therefore, if you must use a boolean variable, give it a misleading name. However, it would be to your advantage if you could hide it even further. For example, in Time Manager, there are a host of variables that hold numbers that work with the time. When the function to validate the key from the registry is called, I could tell it to write a random value between 30 and 60 to an integer variable if the key is valid, but a value between 0 and 29 if the key is invalid. then
, when I wanted to determine if the program is registered, inside a bunch of other complex functions I could stick in stuff like:
C:
if(tsec < 30) {
HideAdvanced();
}
VB:
If tsec < 30 then
Call HideAdvanced
End if
This is really going to make the cracker's job harder. The only "weak" line in this code is the name of the function: HideAdvanced. It would be better to name it something stealthier. In the case of Time Manager, something like ResetTime might be more appropriate.
(VB Specific) P-Code: The Best
To be honest, I reallydo
not know exactly why it is, but Ido
know that P-Code is harder to disassemble than Native Code. While it is really neat to be able to optimize your program for things like size, speed, and Pentium Pro processors, this makes the cracker's job easier. Also to take into consideration is that native code can also cause other problems such as the compiler executing the program incorrectly.
Discombobulate now!
Your job as a shareware developer is to confuse the cracker in your key system. Again, be creative (yes, that's an order)! Make sure to integrate some of your routines into your main data functions, so it is impossible to figure out. You can add in a simple layer to the encryption scheme that could share a function with the main data functions. For example, in Time Manager, when the user enters their values for the time to start at, the program will take the seconds field and if it is greater than 59, convert it to a new hour/minute/second value. So if the seconds is 150, Time Manager will convert this to two minutes and 30 seconds. This could be used as a primitive mod function. Now imagine the cracker trying to figure that out!
Layer, layer, crack slayer
When the Russians were making their first Atomic bombs, they found that a good way to induce pressure on the Uranium-235 was to stack it in layers with some conventional explosives. For every layer they added the bomb's power was increased exponentially. In the same way, a highly secure program will use multiple layers of encryption. Even if one is a simple Xor routine and another is an easy Caesar algorithm, as long as there is a strong element somewhere, all of the little things will pay off. Here is a sample flow chart of three encryption techniques that we will lovingly call A, B, and C. The terms Name and Key are simply generic;
you can use anything here!
Name >> EncryptA >> EncryptB >> EncryptC >> Key
Key >> DecryptC >> DecryptB >> DecryptA >> Name
It's that simple!
Armed Combat
Introduction
Are you ready to take active measures against crackers? This is for the people who really want to target the crackers in their programs. This isn't easy, and should only be attempted by the best of the best. If you are one of these few, suit up and prepare to brandish your programming sword!
Let me open with an example for an introduction. At one time, I noticed that a certain site was serving a crack to one of my programs. That was the only site that I could find that had it. The site was first brought to my attention when I was looking at the sites that people were coming from on my website statistics. A fair amount of traffic was coming from this page advertising the crack. I decided to set up an ASP script that would separate the traffic coming from this site and the traffic coming from everywhere else
. The traffic coming from that sitedo
wnloaded a version of the program that woulddo
various things to the machine it was ran on, such as deleting all of the DLL files it could. All other traffic was directed to the real thing. A total of 12 copies of the malicious version weredo
wnloaded. I never heard a word about it from anyone. After a while, though, the crack was takendo
wn. Victory.
Looking back now, I see how effective it was. I also can see more clearly how risky it was. I probably could have been legally prosecuted for it. While it serves as a good example of what Armed Combat really is, we will not discuss or promote wreaking havoc on a machine here.
This section will be presented in two sub-sections. In the first we will discuss how to identify when the program is being attacked by a cracker, then
we will discuss what todo
about it.
A big warning that EVERYONE should read:do
n't cross the line. Nothing youdo
should interfere with the end user's experience. If your protection is so elaborate that you're warding off the legitimate users, itdo
esn't matter how good your program or how secure your protection is, you've lost. If a newbiedo
es something wrong or weird and they see a message box saying "GO AWAY YOU CRACKER!" that's not good for business. You want to make a direct distinction of what the end user sees and what the cracker sees. The legitimate user should see a terse and modest key entry form while the underlying code is very complex. then
, the cracker will have to look at the code, trying to figure out what it isdo
ing.
Detection: the first step to protection
Here is where we will test your creativity. I will only give you one possible method of detection here. You can then
either use it or make up your own.
Declare a boolean variable IsRegistered. Set it to false, *never* set it to true.do
checks when you're bringing up the main form. If the variable is ever true, then
your program has been tampered with.
Attack
"Tell me where you at, I will be there in ten seconds flat. You know I got your back, I'll be there just in time to counteract.
- Busta Rhymes, "Fire it up"
Now that we have identified that the program has been tampered with, we can take action. Here we have a few interesting options:
a) Wreak havoc (this will not be discussed)
b) Ignore it
c) Fake the cracker out
There are more than these;
you only need to be (again) creative. If we ignore the variable, we will only have succeeded in wasting some of their time. On the other side, we can also fake them out. How? After detecting that the program has been tampered with, change the program to act as if it were registered. However, encrypt the current date (anything here willdo
, including Xor) and write it to the registry or hide it in some other corner of their computer. Every time the program starts, search for this date. If the date can be found, you have a record of when the tampering was first detected. If the current date is three or more days after when the first tampering was detected, give the cracker a nice message box saying something to the effect of it didn't work, then
either close out the program or let it continue unregistered.
Why the three day period? By the time that point is reached, the user will have probably already distributed the crack to his friends. Eventually it will probably reach the general public. After three days, it will stop working, however. then
, the cracker will be labeled as a lamer in the cracker community.
Sounds pretty easy, huh? Yeah, maybe so. Nevertheless, you must be extremely stealthy about it. If you just put it out there in plain code, maybe the newest of crackers will fall victim to the trap, but the adept will catch on. Be creative and set it's roots deep into the main functions of your program. This is why at the begin
ning of this section I warned that only the best should try this one.
Cracks happen
Eventually, at some point one of your programs will be cracked. That is provided that they are popular enough and that there are enough of them. Whatdo
youdo
then
? Fire up your tools and prepare for battle.
Monitoring
Before you can start to fight against a crack, you have to know that it exists. I am not going to turn this section in to ado
cument outlining how to find a crack for any program. However, some good sites to look at are http://astalavista.box.sk and you can run searches with keywords like "crackdo
wnload YOUR-PROGRAM-NAME-HERE."
It is also a good idea to make friends with some crackers. A lot of them will give you advice on what todo
and what not todo
. They can also help keep a look out for cracks. Actually, tell all of your friends to keep a look out for cracks.
Taking Action
After a crack is released, you must then
try to defeat it. It is generally best to redesign your encryption scheme, as this is the only long-term (hopefully) fix! Unfortunately, it involves re-sending keys to all of your users;
either that or simply issuing new keys upon request (this is generally the best option). To design a fully reliable encryption scheme can take hours, even days. However, sooner or later will be necessary.
After you have completed your changes, you must decide whether or not you want to release a new version. If youdo
decide todo
that, you can't hurt the cracker's reputation as described below. In fact, I wouldn't recommend releasing a new version unless you have a multitude of new features in it. My reasoning is that these features should persuade users to leave the old cracked version and to upgrade to the new version, which they will have to pay for. If youdo
not release a new version but replace all of the old cracked versions, then
the problem should be remedied.
Replacing Files
This topic is often overlooked. When you have a new fix, you want to replace your old program with the new one as soon as possible. The sooner youdo
it, the fewer people that will have the crack, and the more registrations you will have. Consequently, it is extremely important to maintain good control over your distribution points. One of the best schemes to have here is as follows:
Primary: On the same server as your website, you should have direct control.
Secondary: To be used if primary is too slow;
these guys should have MEGA bandwidth. You should have a contact here that has direct control.
3rd-ary: This can be your friend's cable modem that is on 24/7, which you can send ICQ updates to.
In the case that a crack is released, you need to be able to replace the old version very quickly. This is the only thing I have against big servers such as Simtel.Net. It may take days for them to update their files. The same is true for ZDNetdo
wnloads, who insists on having their own copy of your software on their servers. One can be caught having to wait for days or even weeks to get a program updated. Yet I still have my software on their site, for the publicity. Remember that itdo
esn't matter how good your program or encryption is if you go so far as to hinder the real users.
Now, moving on, if you like you can possibly hurt the cracker's reputation. In every crack there is almost always an address at which the user of the crack cando
wnload the main program. Now, let us assume that a working crack has been widely distributed and many users aredo
wnloading your program only to be cracked. After discovering this, here is what youdo
:
a) Fix the program so that the crack no longer works (described above)
b) Adjust the file's dates and times in which they were created
c) Zip 'em up (or whatever youdo
for your distribution)
d) Set the zip date and time to the same as the original
e) Upload
I'll leave the changing of the file information up to you. Now if the cracker claims that you changed the program so that the crack no longer works, he will be putdo
wn. As far as the end users see, the program is the exact same as it was before. But the crackdo
esn't work!
Conclusion
In conclusion, I would like to drive home two main points:
a) Remember, there is no such thing as a program that cannot be cracked!
b) Also remember that if you overdo yourself, you will loose potential customers.do
not cross the line!
That's it! I hope that you learned something from thisdo
cument.
Copyright &copy;
2000 Sense of Security Incorporated All Rights Reserved.