技术路线图版本pkb2.5pb5,6,7,8,9,10,10.5,11,11.5,12版本为pbvm.dll的版本如pbvm115.dll。而不是指开发工具的版本。因为一个vm支持多个细微版本。用于powerbuilder5-12的代码混淆和加密。做这程序的目的很简单因为我一直在用powerbuilder做项目。时间大约有5年了。曾撰文把pb比作钥匙链上的指甲剪随拿随用方便简单但又不乏强大。防止破解是软件发行时最关心的问题。自2009.6开始研究pbd文件格式。同期开始开发反编译器现已基本成熟因为有一些顾虑(不知道如何授权以及仅授权给需要的用户)所以暂未释出。2010.3月研究PowerShield1.0简易版并成功反混淆(估计是简易版的缘故,否则我不会感叹太容易反混淆)也撰文提到PowerShield1.0简易版可能留有后门和安全系数不高的问题。PowerShield有点像三打祝家庄里的白杨树一旦测试一个程序的不同加密强度其转弯标识清晰可见。如果在分析时设置一个检查栈并适配假跳的规律即可反混淆。尤以区分行间与行内为一个重要技巧可完美反混淆。具体文字可见我blog中述。其中代码混淆部分的思路参考LJTT的PowerShield1.0简易版,在此表示敬仰和感谢。鉴于pbkiller对pb9以下的程序造成极大伤害倒不是pbkiller有什么不对关键在于它的授权泛滥。所以也给了极高的关注并在混淆时想办法加于克制。并对kivens表示敬仰。只要用过混淆器的pbkiller应该都不起作用。还有他对longlong类型的不支持,对unicode版本的不支持基本无害因为作者没针对性开发。把pb kill掉还要我们做什么呢主要特点1.修改了部分关键点参数,诱导早期的一些反编译器崩溃。没有人维护的反编译器就让他退出破解的应用场合吧。至于工程恢复那是另话。2.代码混淆部分原理参考LJTT的PowerShield1.0简易版并在其基础上扩展出一些新的方式。还有些东西在脑子里暂未实现。2.1加入随机变化因子这样使得反混淆器算法难度增加2.2增加了欺骗和逻辑陷阱这些陷阱靠人眼是可以分析和发现的但因为人脑是有逻辑思维能力而靠编程是无法去理解我伪造的假代码的逻辑性的。从而会陷入我预设的逻辑陷阱中。Beta后会扩展2.3在当前的工作基础上(9种)增加至36种(or 100种)左右的混淆方式并限制在单机能测试到所有混淆方式这样开发反编译器的人因为无法测试到所有可能性从而加大反混淆的难度。最主要是混杂一些看似是正常代码的假跳转(包括直接伪造本地变量参与的表达式,让人难辨真伪)相似性越高越不容易判定致使反混淆无法运用程序进行归纳识别。2.4混淆前查看变量列表中有否有一些可利用的变量如int,long类型可以进行伪造假的代码并添加进来与真实代码混杂在一起或者对真实代码形成包裹与混杂相似性更高。2.5将多种方式离散在多个发行版本中。从而让反编译器无所适从。离散也包括按机器特征时间版本授权种类等。尽量分散。2.6其他动态语言的混淆器还没去参考因为想先有个基本实现。javac#等的混淆器应该已经很成熟可以借鉴。2.7还将在更多的数据段进行伪造。伪造的一个好处是想反编译必须得先理顺并归置到伪造前。这个有点难。还有一个公理是pb执行时是动态的他用到的才会去呼叫并调用内存。而伪造的绝对不会被呼叫。但但反编译器并不知道所以任何东东都会去屁颠屁颠地分析。2.8数字和文字的等效替换防止pj者直接搜索敏感位置。2.9考虑到我的实现受制于代码长度可利用代码太少版本差异等因素想到可给编程者预留陷阱标志(混淆器代为扰乱)程序员在代码编写上主动防御则混淆后真假难分模糊程度更好陷阱隐蔽性更好。3.抹掉所有不必要的可视文字如RefListObject文字var变量名function名字和参数等文字。如此反编译器只能重新命名从而无法还原可读性。代码功能的阅读在没有备注的情况下很大程度依赖变量名函数名。我们都是程序员这个道理都懂。因函数与时间都可能被全局呼叫或动态呼叫(写在引号内),所以目前暂未对函数和事件名字采取措施。处理上应该也相当麻烦。4.增加了欺骗对象或函数。虽然借助对本软件的反复调试反混淆器作者可以发现规律但是因为欺骗对象带随机因子在没有参考物的情况下要校验一个对象的格式完整性和正确性目前还没人有那个能力。除非就是到处用断言总归很难判定。就如用视觉鉴别一瓶纯净水和一瓶汽油一样。反混淆器就会不小心陷入其中。5.增加对象内函数或事件造假功能。因为考虑到反编译器会提供单点反编的调试开关所以尽量细化到每个pbd文件每个对象每个函数事件每段代码都可能出现阻止反编译器的有效手段。如果能轻易绕过那岂不是白搭。上2.9就是居于这种考虑。除反混淆和反编译开发者外一些使用反编译器的普通人是不知道反编译器为什么会中途异常退出的因为他们没反编译器源码也无法单步调试。他们对此种情况也无能为力(要的就是这种效果)。反编译器开发者也不会去为一个不确定的规律而修改程序。6.对一些可有可无但对pbd格式肉眼分析有帮助的地方都尽数抹掉了从而增加肉眼人工分析的错觉感。我的原则是抹掉一切可抹掉之字节扰乱一切可扰乱的字节。目前可以确定在格式解析和基本框架上无错。但是码表依然不完整(截止2010.5.12尚差30个)如果测试到错误(unknown pcode)请告知。但是请注意请用full编译通过的程序测试不要用那种编译出错或者编译到一半异常退出的pbd来测试它本身就是有问题(这在反编译器开发时遇到过)还有种错误如link error。实际就是失败了。建议强烈建议只对系列号管制注册在线人数限制等关键代码或关键算法等地方进行加密混淆对于一般的数据录入查询等没必要进行加密混淆因为加密混淆数倍数十倍冗余代码从而造成执行效率低下。并不是其他混淆器所说的只减慢一点点。我测试我的pb11项目时发现有能感觉得到的延迟。当然是设置的强度非常大的情况下。同时为避免不必要的麻烦系列号管制等代码请放在一定数量的代行之后如100行不管怎么说测试版的反编译器都会对可以阅览的代码行有一个限制(因为那个原因...)。这在一定程度也保护了自己的代码。程序的写法上也有一些技巧并非如平常代码一样编写。使用1.把你的以p-code编译方式的文件放入到一个临时文件夹如d:/123为什么要放入一个临时文件夹而不是直接对文件操作因为混淆过程可能失败失败情况下文件会被写入一些数据pbd在被处理前先会备份成.bac为扩展名的备份文件(bak跟ue的自动备份冲突),当处理后发现问题可以第一时间恢复但是当您选择另外一个文件名后就无法恢复前一个文件了你可以打开临时文件夹自行恢复。处理过程必须一气呵成不能分几次进行。2.按软件界面的load files按钮选择一个exe,dll,pbd格式文件(machine-code编译方式的单一exe文件和pbni方式的除外,提示: dll文件如果不是单一exe文件 dll还是含有伪代码)随即文件内的所有对象将在左边的两个CheckListBox中列出(仅仅处理uo,win,func,其他对象类型我认为没必要处理如menu)。其中上面一个CheckListBox中勾选的对象将被加密和混淆下面一个CheckListBox中勾选会将此对象扰乱主要是欺骗和让反编译软件运行时崩溃。利用的一个普遍真理是反编译程序很难校验文件的格式有效性。就比如我从一个对象的二进制系列中随机删除一个。你看不出问题但是你分析立马死掉。道理很简单。虽然你能用uo的二进制对比发现我修改了哪些地方当然我是随机地。但最终用户使用混淆器处理后他的原始pbd是不会给你的。你就无法对比了。就好比被修改过的电影剧本你拿到新版本你无法知道跟老版本的差异在哪里一样。这是公理不是歪理。只有一个可以检测得到那就是反编译器的崩溃或者是从外部调用它会崩溃。所谓兵不厌诈。一般建议在10个对象中放置2-3个这样的“从来都不会用到“的废对象作为欺骗对象。一般来说按照我的经验必然使得反编译器崩溃。在对象命名上要同其他对象名字无什么差别就是不要让人一眼看出即可。切忌不可以有什么规律否则pj者给你屏蔽掉。就如同正常对象一样命名。3.点Confuse按钮代码被处理。正常情况下显示如下:FilePath: D:/pbr测试样本/pb9/ //文件信息FileName: pxx.pbdFileLength: 20480bytesObjQty: 5Unicode/Ansi: AnsiVersion: PowerBuilder/vm:9.0/vi:108691/build:8836 //版本信息-########Write File finished,Object: uf_bitshl.fun //修改后写入“########”为正常标志Old Len: 1394,New Len: 4552Close File normally. //关闭文件如果出现其他提示就是不正确(提示前有连续加号标志就是重大错误或失败如空间不足等提示就表示处理不成功如下Obj:n_cst_dw2excel.udo,Ctrl:n_cst_dw2excel,funcID: 21-Cant find enough space to dispose Code-Chip,[failing] //程序切片不能够放在既有的空间里。程序会//跳过。如果是你的注册函数Code 0x39,step: 4600 of 5481 //那肯定不行.因为寻址空间为0xFFFF所以//5481个是会出现问题的。你必须调整扩展的空间大小(在options标签页9-30倍可选但是因为寻址空间oxFFFF是有限的如果切片太多就放不下),当然在调整空间前你可以尝试2-3次因为程序在寻找一个放代码的空间时会尝试100次,但是有时还是会存在本来有空间但是却不凑巧的可能。程序采用随机寻找位置而非遍历来找空间。但是类似这些信息是正常的-------------Empty expression,Skip.Ctrl:usv_datawindow,funcID: 1它表示跳过空的代码段但是现在这些无聊信息我已经屏蔽掉。只显示关键信息了。为了不给其他人蓄意调试本软件的处理结果调试也无所谓。我有我的思路应对options中除了代码扩展倍数和插入冗余的密度可以选择外其他选项都不可以改变。代码太少大约小于20行(100个切分段)也不会被混淆。因为代码太少如一句。用眼睛就可以反编译。4.2010.5.12新增移除dll编译方式下的PCODE伪码虽然用ue手工移除过几个进行测试发现能运行正常(就是Pcode是多余的只是产生机器码的临时过渡)但我仍然不保证结果正常以前听说过pb的机器码编译方式是机器码和伪码参半的也没去研究。编译机器码时动辄几十分钟够Lan的。所以作为一个选项给你自己勾选。移除后是否能运行正常你自己测试。5.2010.5.12新增伪造一个对象的内部函数如你写有一个函数如of_today,你想让他变成一个阻止反编译的地雷那请在左下方的memo里输入该函数名“of_today”可以输入多个每行一个。处理对象时将核对如果函数名符合则将func或者event的码进行扰乱。比如用随机数覆盖开头的几个码即可达到目的。当然这个函数肯定应该是废函数。只要名字相同不管他在哪个对象哪个控件的哪个地方。当然你混淆其他的项目时应该及时删除它否则会把其它程序里同函数名的函数搞乱了。你最好约定使用一个名字来命名你的地雷在你的整个项目里。2.VM解析的修改pbd文件格式的修改加密目前还没足够时间去跟踪调试。技术方面的实现有些难度。但是我想在不久的一段时间在我项目空暇时间必然会走这个思路。说到安全系数问题可能定制vmpbd格式加密才能称得上牢靠。这个ljtt早说过但是很遗憾未见其形。因为定制vm和加密pbd文件时都可以设置很多随机因子致使每家的文件不一样加之pbd和vm互为配合(狼狈为J)从而从根本上防止反编译。当然并不是看到我这个提示你就去完成一个对文件格式的全部加密的代码嵌入到vm中那样必然有人去研究如果反。因为太明显了。不过并非易事。重申安全性混淆器理论上是无任何安全保障的它只能保障反编译器在基于机械反向时对打乱的statement无法做到真实还原也无法还原文字可读性还有无法还原已经被模糊化或者做等效替换的部分。除此之外因为程序的逻辑顺序并未打乱所以如果靠人工不管欺骗陷阱冗余都能被去除如果辅于工具假以时间是可以正确还原的这其中主要的症结在于伪码编译不是太低阶甚至于很容易理解和还原成高级语言。这就是伪码本身的不安全性。这和java,c#,以及早期的vb等类似。当然也得说说伪码的反面因为偏偏是那种编译成机器码的程序往往容易被跟踪调试。从而在高手的一个NOP就搞定了。喜欢看汇编的人看汇编时跟我们看程序可能是一样的。就说pb开发工具每每都是放出来几天高手就贴出补丁来。就如最近的v12就被一串空操作简单搞定。所以混淆器并不保障程序安全。只是提高反编译的难度系数。可以预见的错误因为永远不可能掌握跟sybase一样的p-code码表所以无法保证切分代码时正确无误但是基本可以保障常用写法时能正确。码表会在足够数量的测试下逐渐命中那些小概率的码。代码的正确切分是混淆的必要保证否则就一错到底了。所以在进行混淆后请自行测试程序。万一出错造成授权或限制不起作用那就不要怪我了。现在我未掌握的未知码都有标示出来在混淆时都会提示unknown pcode所以会很快完善包括我自己也会大量测试自己的项目pb sample和网上下载的代码会很快完善的。如果遇到错误或者混淆后无法运行或者运行时报错请将截图和测试用的pbd文件一起发给我(如果纯粹测试的pbd可以发给我如果是商业的程序,请不要发给我,但为了能完善混淆器可以单独将出问题的对象复制到一个新的pbl中并编译成pbd然后发给我,这样我不会太了解你的程序是干嘛使的)额外提示请在发行程序时进行full编译full编译通过后再进行混淆。附图选项正在改成中文界面并推出正式版
Powerbuilder混淆,加密(powerbuilder防止反编译,pb混淆器，PB加壳，支持5-12) obfuscator for PowerBuilder
技术路线图版本pkb2.5pb5,6,7,8,9,10,10.5,11,11.5,12版本为pbvm.dll的版本如pbvm115.dll。而不是指开发工具的版本。因为一个vm支持多个细微版本。用于powerbuilder5-12的代码混淆和加密。做这程序的目的很简单因为我一直在用powerbuilder做项目。时间大约有5年了。曾撰文把pb比作钥匙链上的指甲剪随拿随用方便简单但又不乏强大。防止破解是软件发行时最关心的问题。自2009.6开始研究pbd文件格式。同期开始开发反编译器现已基本成熟因为有一些顾虑(不知道如何授权以及仅授权给需要的用户)所以暂未释出。2010.3月研究PowerShield1.0简易版并成功反混淆(估计是简易版的缘故,否则我不会感叹太容易反混淆)也撰文提到PowerShield1.0简易版可能留有后门和安全系数不高的问题。PowerShield有点像三打祝家庄里的白杨树一旦测试一个程序的不同加密强度其转弯标识清晰可见。如果在分析时设置一个检查栈并适配假跳的规律即可反混淆。尤以区分行间与行内为一个重要技巧可完美反混淆。具体文字可见我blog中述。其中代码混淆部分的思路参考LJTT的PowerShield1.0简易版,在此表示敬仰和感谢。鉴于pbkiller对pb9以下的程序造成极大伤害倒不是pbkiller有什么不对关键在于它的授权泛滥。所以也给了极高的关注并在混淆时想办法加于克制。并对kivens表示敬仰。只要用过混淆器的pbkiller应该都不起作用。还有他对longlong类型的不支持,对unicode版本的不支持基本无害因为作者没针对性开发。把pb kill掉还要我们做什么呢主要特点1.修改了部分关键点参数,诱导早期的一些反编译器崩溃。没有人维护的反编译器就让他退出破解的应用场合吧。至于工程恢复那是另话。2.代码混淆部分原理参考LJTT的PowerShield1.0简易版并在其基础上扩展出一些新的方式。还有些东西在脑子里暂未实现。2.1加入随机变化因子这样使得反混淆器算法难度增加2.2增加了欺骗和逻辑陷阱这些陷阱靠人眼是可以分析和发现的但因为人脑是有逻辑思维能力而靠编程是无法去理解我伪造的假代码的逻辑性的。从而会陷入我预设的逻辑陷阱中。Beta后会扩展2.3在当前的工作基础上(9种)增加至36种(or 100种)左右的混淆方式并限制在单机能测试到所有混淆方式这样开发反编译器的人因为无法测试到所有可能性从而加大反混淆的难度。最主要是混杂一些看似是正常代码的假跳转(包括直接伪造本地变量参与的表达式,让人难辨真伪)相似性越高越不容易判定致使反混淆无法运用程序进行归纳识别。2.4混淆前查看变量列表中有否有一些可利用的变量如int,long类型可以进行伪造假的代码并添加进来与真实代码混杂在一起或者对真实代码形成包裹与混杂相似性更高。2.5将多种方式离散在多个发行版本中。从而让反编译器无所适从。离散也包括按机器特征时间版本授权种类等。尽量分散。2.6其他动态语言的混淆器还没去参考因为想先有个基本实现。javac#等的混淆器应该已经很成熟可以借鉴。2.7还将在更多的数据段进行伪造。伪造的一个好处是想反编译必须得先理顺并归置到伪造前。这个有点难。还有一个公理是pb执行时是动态的他用到的才会去呼叫并调用内存。而伪造的绝对不会被呼叫。但但反编译器并不知道所以任何东东都会去屁颠屁颠地分析。2.8数字和文字的等效替换防止pj者直接搜索敏感位置。2.9考虑到我的实现受制于代码长度可利用代码太少版本差异等因素想到可给编程者预留陷阱标志(混淆器代为扰乱)程序员在代码编写上主动防御则混淆后真假难分模糊程度更好陷阱隐蔽性更好。3.抹掉所有不必要的可视文字如RefListObject文字var变量名function名字和参数等文字。如此反编译器只能重新命名从而无法还原可读性。代码功能的阅读在没有备注的情况下很大程度依赖变量名函数名。我们都是程序员这个道理都懂。因函数与时间都可能被全局呼叫或动态呼叫(写在引号内),所以目前暂未对函数和事件名字采取措施。处理上应该也相当麻烦。4.增加了欺骗对象或函数。虽然借助对本软件的反复调试反混淆器作者可以发现规律但是因为欺骗对象带随机因子在没有参考物的情况下要校验一个对象的格式完整性和正确性目前还没人有那个能力。除非就是到处用断言总归很难判定。就如用视觉鉴别一瓶纯净水和一瓶汽油一样。反混淆器就会不小心陷入其中。5.增加对象内函数或事件造假功能。因为考虑到反编译器会提供单点反编的调试开关所以尽量细化到每个pbd文件每个对象每个函数事件每段代码都可能出现阻止反编译器的有效手段。如果能轻易绕过那岂不是白搭。上2.9就是居于这种考虑。除反混淆和反编译开发者外一些使用反编译器的普通人是不知道反编译器为什么会中途异常退出的因为他们没反编译器源码也无法单步调试。他们对此种情况也无能为力(要的就是这种效果)。反编译器开发者也不会去为一个不确定的规律而修改程序。6.对一些可有可无但对pbd格式肉眼分析有帮助的地方都尽数抹掉了从而增加肉眼人工分析的错觉感。我的原则是抹掉一切可抹掉之字节扰乱一切可扰乱的字节。目前可以确定在格式解析和基本框架上无错。但是码表依然不完整(截止2010.5.12尚差30个)如果测试到错误(unknown pcode)请告知。但是请注意请用full编译通过的程序测试不要用那种编译出错或者编译到一半异常退出的pbd来测试它本身就是有问题(这在反编译器开发时遇到过)还有种错误如link error。实际就是失败了。建议强烈建议只对系列号管制注册在线人数限制等关键代码或关键算法等地方进行加密混淆对于一般的数据录入查询等没必要进行加密混淆因为加密混淆数倍数十倍冗余代码从而造成执行效率低下。并不是其他混淆器所说的只减慢一点点。我测试我的pb11项目时发现有能感觉得到的延迟。当然是设置的强度非常大的情况下。同时为避免不必要的麻烦系列号管制等代码请放在一定数量的代行之后如100行不管怎么说测试版的反编译器都会对可以阅览的代码行有一个限制(因为那个原因...)。这在一定程度也保护了自己的代码。程序的写法上也有一些技巧并非如平常代码一样编写。使用1.把你的以p-code编译方式的文件放入到一个临时文件夹如d:/123为什么要放入一个临时文件夹而不是直接对文件操作因为混淆过程可能失败失败情况下文件会被写入一些数据pbd在被处理前先会备份成.bac为扩展名的备份文件(bak跟ue的自动备份冲突),当处理后发现问题可以第一时间恢复但是当您选择另外一个文件名后就无法恢复前一个文件了你可以打开临时文件夹自行恢复。处理过程必须一气呵成不能分几次进行。2.按软件界面的load files按钮选择一个exe,dll,pbd格式文件(machine-code编译方式的单一exe文件和pbni方式的除外,提示: dll文件如果不是单一exe文件 dll还是含有伪代码)随即文件内的所有对象将在左边的两个CheckListBox中列出(仅仅处理uo,win,func,其他对象类型我认为没必要处理如menu)。其中上面一个CheckListBox中勾选的对象将被加密和混淆下面一个CheckListBox中勾选会将此对象扰乱主要是欺骗和让反编译软件运行时崩溃。利用的一个普遍真理是反编译程序很难校验文件的格式有效性。就比如我从一个对象的二进制系列中随机删除一个。你看不出问题但是你分析立马死掉。道理很简单。虽然你能用uo的二进制对比发现我修改了哪些地方当然我是随机地。但最终用户使用混淆器处理后他的原始pbd是不会给你的。你就无法对比了。就好比被修改过的电影剧本你拿到新版本你无法知道跟老版本的差异在哪里一样。这是公理不是歪理。只有一个可以检测得到那就是反编译器的崩溃或者是从外部调用它会崩溃。所谓兵不厌诈。一般建议在10个对象中放置2-3个这样的“从来都不会用到“的废对象作为欺骗对象。一般来说按照我的经验必然使得反编译器崩溃。在对象命名上要同其他对象名字无什么差别就是不要让人一眼看出即可。切忌不可以有什么规律否则pj者给你屏蔽掉。就如同正常对象一样命名。3.点Confuse按钮代码被处理。正常情况下显示如下:FilePath: D:/pbr测试样本/pb9/ //文件信息FileName: pxx.pbdFileLength: 20480bytesObjQty: 5Unicode/Ansi: AnsiVersion: PowerBuilder/vm:9.0/vi:108691/build:8836 //版本信息-########Write File finished,Object: uf_bitshl.fun //修改后写入“########”为正常标志Old Len: 1394,New Len: 4552Close File normally. //关闭文件如果出现其他提示就是不正确(提示前有连续加号标志就是重大错误或失败如空间不足等提示就表示处理不成功如下Obj:n_cst_dw2excel.udo,Ctrl:n_cst_dw2excel,funcID: 21-Cant find enough space to dispose Code-Chip,[failing] //程序切片不能够放在既有的空间里。程序会//跳过。如果是你的注册函数Code 0x39,step: 4600 of 5481 //那肯定不行.因为寻址空间为0xFFFF所以//5481个是会出现问题的。你必须调整扩展的空间大小(在options标签页9-30倍可选但是因为寻址空间oxFFFF是有限的如果切片太多就放不下),当然在调整空间前你可以尝试2-3次因为程序在寻找一个放代码的空间时会尝试100次,但是有时还是会存在本来有空间但是却不凑巧的可能。程序采用随机寻找位置而非遍历来找空间。但是类似这些信息是正常的-------------Empty expression,Skip.Ctrl:usv_datawindow,funcID: 1它表示跳过空的代码段但是现在这些无聊信息我已经屏蔽掉。只显示关键信息了。为了不给其他人蓄意调试本软件的处理结果调试也无所谓。我有我的思路应对options中除了代码扩展倍数和插入冗余的密度可以选择外其他选项都不可以改变。代码太少大约小于20行(100个切分段)也不会被混淆。因为代码太少如一句。用眼睛就可以反编译。4.2010.5.12新增移除dll编译方式下的PCODE伪码虽然用ue手工移除过几个进行测试发现能运行正常(就是Pcode是多余的只是产生机器码的临时过渡)但我仍然不保证结果正常以前听说过pb的机器码编译方式是机器码和伪码参半的也没去研究。编译机器码时动辄几十分钟够Lan的。所以作为一个选项给你自己勾选。移除后是否能运行正常你自己测试。5.2010.5.12新增伪造一个对象的内部函数如你写有一个函数如of_today,你想让他变成一个阻止反编译的地雷那请在左下方的memo里输入该函数名“of_today”可以输入多个每行一个。处理对象时将核对如果函数名符合则将func或者event的码进行扰乱。比如用随机数覆盖开头的几个码即可达到目的。当然这个函数肯定应该是废函数。只要名字相同不管他在哪个对象哪个控件的哪个地方。当然你混淆其他的项目时应该及时删除它否则会把其它程序里同函数名的函数搞乱了。你最好约定使用一个名字来命名你的地雷在你的整个项目里。2.VM解析的修改pbd文件格式的修改加密目前还没足够时间去跟踪调试。技术方面的实现有些难度。但是我想在不久的一段时间在我项目空暇时间必然会走这个思路。说到安全系数问题可能定制vmpbd格式加密才能称得上牢靠。这个ljtt早说过但是很遗憾未见其形。因为定制vm和加密pbd文件时都可以设置很多随机因子致使每家的文件不一样加之pbd和vm互为配合(狼狈为J)从而从根本上防止反编译。当然并不是看到我这个提示你就去完成一个对文件格式的全部加密的代码嵌入到vm中那样必然有人去研究如果反。因为太明显了。不过并非易事。重申安全性混淆器理论上是无任何安全保障的它只能保障反编译器在基于机械反向时对打乱的statement无法做到真实还原也无法还原文字可读性还有无法还原已经被模糊化或者做等效替换的部分。除此之外因为程序的逻辑顺序并未打乱所以如果靠人工不管欺骗陷阱冗余都能被去除如果辅于工具假以时间是可以正确还原的这其中主要的症结在于伪码编译不是太低阶甚至于很容易理解和还原成高级语言。这就是伪码本身的不安全性。这和java,c#,以及早期的vb等类似。当然也得说说伪码的反面因为偏偏是那种编译成机器码的程序往往容易被跟踪调试。从而在高手的一个NOP就搞定了。喜欢看汇编的人看汇编时跟我们看程序可能是一样的。就说pb开发工具每每都是放出来几天高手就贴出补丁来。就如最近的v12就被一串空操作简单搞定。所以混淆器并不保障程序安全。只是提高反编译的难度系数。可以预见的错误因为永远不可能掌握跟sybase一样的p-code码表所以无法保证切分代码时正确无误但是基本可以保障常用写法时能正确。码表会在足够数量的测试下逐渐命中那些小概率的码。代码的正确切分是混淆的必要保证否则就一错到底了。所以在进行混淆后请自行测试程序。万一出错造成授权或限制不起作用那就不要怪我了。现在我未掌握的未知码都有标示出来在混淆时都会提示unknown pcode所以会很快完善包括我自己也会大量测试自己的项目pb sample和网上下载的代码会很快完善的。如果遇到错误或者混淆后无法运行或者运行时报错请将截图和测试用的pbd文件一起发给我(如果纯粹测试的pbd可以发给我如果是商业的程序,请不要发给我,但为了能完善混淆器可以单独将出问题的对象复制到一个新的pbl中并编译成pbd然后发给我,这样我不会太了解你的程序是干嘛使的)额外提示请在发行程序时进行full编译full编译通过后再进行混淆。附图选项正在改成中文界面并推出正式版
