我有开发一款新的Powerbuilder的混淆器。
支持版本:pkb2.5;pb5-12
1.移除部份文字,从而使得反组译无法还原文字
2.可执行码的混淆
3.逻辑陷阱,阻止反组译程序获取源码
4.支持现在常用的pb版本。最新支持到12
博客:http://blog.csdn.net/chengg0769
下载网址:http://chengg0769.download.csdn.net/
用于powerbuilder5-12的代码混淆和加密。
博客:http://blog.csdn.net/chengg0769
下载网址:http://chengg0769.download.csdn.net/
主要特点:
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考虑到我的实现受制于代码长度,可利用代码太少,版本差异等因素,想到可给编程者预留陷阱标誌(混淆器代为扰乱),程序员在代码编写上主动
防御,则混淆后真假难分,模糊程度更好,陷阱隐蔽性更好。
3.抹掉所有不必要的可视文字,如RefListObject文字,var变量名,function名字和参数等文字。如此反编译器只能重新命名,从而无法还原可读性。代码功能
的阅读在没有备注的情况下,很大程度依赖变量名,函数名。我们都是程序员,这个道理都懂。因函数与时间都可能被全局呼叫或动态呼叫(写在引号内),所以
目前暂未对函数和事件名字採取措施。处理上应该也相当麻烦。
4.增加了欺骗对像或函数。虽然借助对本软件的反複调试,反混淆器作者可以发现规律,但是因为欺骗对象带随机因子,在没有参考物的情况下,要校验一个对
象的格式完整性和正确性,目前还没人有那个能力。除非就是到处用断言,总归很难判定。就如用视觉鉴别一瓶纯净水和一瓶汽油一样。反混淆器就会不小心陷
入其中。
5.增加对象内函数或事件造假功能。因为考虑到反编译器会提供单点反编的调试开关,所以尽量细化到每个pbd文件,每个对象,每个函数事件,每段代码都可能
出现阻止反编译器的有效手段。如果能轻易绕过,那岂不是白搭。上2.9就是居于这种考虑。
除反混淆和反编译开发者外,一些使用反编译器的普通人是不知道反编译器为什么会中途异常退出的,因为他们没反编译器源码,也无法单步调试。
他们对此种情况也无能为力(要的就是这种效果)。反编译器开发者也不会去为一个不确定的规律而修改程序。
6.对一些可有可无,但对pbd格式肉眼分析有帮助的地方都尽数抹掉了,从而增加肉眼人工分析的错觉感。我的原则是抹掉一切可抹掉之字节,扰乱一切可扰乱
的字节。