再论 pb所写的软件如何防止破解？

之前有对这个问题讨论：

http://blog.csdn.net/chengg0769/archive/2009/02/28/3944575.aspx

但是针对的是比较通用的想法。单就pb程序来说。主要是应对反编译软件的侵害。

depb(1.0版视乎很多bug，测试一个结构也无法反编译),pbkiller,shudepb。因为pb采用vm执行，所以汇编和调试根本对pb写的程序威胁不是很严重。

粗略地说有这末几种保护方式：

1. machine code方式的单一exe文件编译。

这个用反编译软件测试，都只能看到变量申明，无法看到源代码。 如果你的程序会出现无法编译成一个exe的情况(基本无法编译，如果是软件很复杂的情况下),那你不妨把要害部分作在一个独立的比较小的可执行文件中，比如注册码验证，然后这个小的可执行文件生成一个外部文件，比如100K大小的二进制文件。随即马上调用主程序运行整个程序，而主程序将这个外部100K文件第一时间读入blob变量，然后删除外部100K文件。然后在主程序里有意无意地在很多地方引用这个blob中的数值对软件进行限制。 一般而言，除非是作者自己反编译自己的软件，所以一般破解者是无法真正完整(或者说不会有相应的专业知识和耐心)反编译的。可以这么认为，他们只能很容易偷窥到一些代码，但是你的代码写明要把一个数据检索的行数限制为100行，他也没有办法。应该他不可能反编译后再进行编译打包嘛！对不对。可以我们在【可以看到代码而无法修改代码并重新打包】这层意义上来防止他是可以的。试想，如果你在100个地方都做了手脚，他难道有那个耐心来弄个工具，达到什么什么效果？

所以总结一句就是，把关键的敏感代码放入machine cdoe的 单一exe编译文件，而在主程序里搞鬼，尽量搞得破解者莫名其妙。他不懂程序，他的难度就非常高。

2. 用pbni的方式编译敏感代码,然后转成pbd,一般反编译软件只能编译传统的pbd和dll，不能反出vc++编译后转过来的pbd。

3. 如果在一个工程里，一个全局的对象出现过多次，它会按lib的次序查找，所以这一点也可以拿来迷惑破解者。比如我对若干函数，甚至窗体生成多个拷贝对象，把测试版的放在前面，用单一的机器码程序来验证注册码，如果注册码OK，那我可以生成一个加密的文件，这个文件指示出lib的顺序。在主程序里设置这个顺序。假如说这个顺序是： 10001.pbd 10002.pbd 10003.pbd 当然我这个顺序列表是从加密的文件内取出的。因为破解者他用shudepb能看到代码，他也没法调试，毕竟软件反编译后很多错误。没有几天几夜是无法修改掉错误处的，所以我们可以认为他不具备调试的条件。而具体你的lib的顺序是怎么样的，他应该不清楚。

你的真正的pbd你可以动态从某个文件里创建出来。更增加了破解的难度。

你可以把所有pbd或者dll从一个包里解析出来，用一个独立的exe文件来执行这个任务，就是在主程序下生成多个假的pbd文件，然后随即在window系统目录或者其他path所指向的目录生出pbd，然后把这个清单通过主程序的parmlist传入，在主程序的application的open事件中设置库路劲。你可以一次性释放出几百个文件来。用完之后删除，下次启动再次生成。这样文件名可以随机和随意起名。静态反编译时，pj者无法确认你的正确的对象在哪里。pj者修改pbd文件也没有用。

鉴于目前pbkiller和shudepb，最好在启动时创建上百个甚至上千个文件。。。等pj者去研究吧。

总之。很多编译型软件是很容易被破解掉的。其原因就是别人asm后跟踪了jxxp这样的汇编指令。而pb程序我认为只要足够地愚弄破解者。就能尽量拖延时间，保护好软件。让其破解的时间成本和难度增加，迷幻度增加是一个办法。 试想，如果一个房门，一把锁，想打开它，是可以很快速地想到办法，比较暴力的方法就是砸掉锁，或者砸掉门。而你如果采用足够迷惑的方法，让其根本不晓得门在哪里，或者设置若干假门，耽误他的时间，增加它的挫折度。我想也是一个好的方法。 4. 网络认证，把认证部分放在网络服务器上，认证完，下载一个加密文件下来。用其对程序的一些参数进行设置。当然有人会说破解者有相当的技术，他能怎么怎么样！但是他工程量绝不亚于重新开发10套软件的工作量嘛。他何苦呢？