PB防反编译
pb加密与解密
PB 编译、反编译、反反编译
pbzip pb防反编译封包工具
powerbuilder程序如何对抗shudepb
PB反编译工具
PowerBuilder程序暴力破解
自己做的一个PB反编译器
DePB 针对PowerBuilder语言编写的程序进行反编译
PBKiller v2.5.18
pb程序有哪些反编译,反破解的方法
PowerBuilder shudepb反汇编利器
PBKiller2.5.18及PB加密器下载
针对Powerbuilder的硬加密套件
PowerBuilder 的编译文件PBD加密程序
反编译PowerBuilder语言程序的工具
pbobfuscator v2010.05.3(Powerbuilder-pbd文字移除与代码混淆加密器)
build 2010.05.19 23:52
支持版本:
pkb2.5
pb5,6,7,8,9,10,10.5,11,11.5,12
版本为pbvm.dll的版本,如pbvm115.dll。而不是指开发工具的版本。因为一个vm支持多个细微版本。
曾撰文把pb比作钥匙链上的指甲剪,随拿随用,方便简单,但又不乏强大。防止破解是软件发行时最关心的问题。
所以暂未释出。2010.3月研究PowerShield1.0简易版,并成功反混淆(估计是简易版的缘故,否则我不会感叹太容易反混淆)也撰文提到
PowerShield1.0简易版可能留有后门和安全系数不高的问题。PowerShield有点像三打祝家庄里的白杨树,一旦测试一个程序的不同加密
强度,其转弯标识清晰可见。如果在分析时设置一个检查栈,并适配假跳的规律,即可反混淆。尤以区分行间与行内为一个重要技巧,可完美反混淆。具体文字可见我blog中述。
倒不是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其他动态语言的混淆器还没去参考,因为想先有个基本实现。java,c#等的混淆器应该已经很成熟,可以借鉴。
2.7还将在更多的数据段进行伪造。伪造的一个好处是,想反编译必须得先理顺并归置到伪造前。这个有点难。还有一个公理是:pb执行时是动态的,他用到的才会去呼叫并调用内存。而伪造的绝对不会被呼叫。但,但,反编译器并不知道,所以任何东东都会去屁颠屁颠地分析。
2.8数字和文字的等效替换,防止pj者直接搜索敏感位置。
2.9考虑到我的实现受制于代码长度,可利用代码太少,版本差异等因素,想到可给编程者预留陷阱标志(混淆器代为扰乱),程序员在代码编写上主动防御,则混淆后真假难分,模糊程度更好,陷阱隐蔽性更好。