EXE2DELPHI工具到没有见过,以前用过EXE2ASM, EXE2C, EXE2VB等逆
向翻译之类的东西, 但转换的效果都不太理想。有些修改过后再编译就用不了
(尤其是EXE2ASM),有些如EXE2VB的效果还将就.
根据编译理论,100%的逆向工程是不可能的,但我想尽可能的转换还是可
行的.但转换的结果跟源程序差异很大.比如明明你将几个变量申明在几个单元的
Interface中,逆向翻译的结果可能会将这几个变量都放在了一个公共的单元里面,
因为Delphi将单元中的interface变量统统都放入了一个全局数据段中,逆向翻译
并不知道数据段中那个变量应该放在那个单元中.
逆向翻译工程一般要解决几个基本问题:比如:
1.程序结构的翻译:知道那一段机器代码对应那一种程序结构。
用ASM编写的程序其结构一般不太规格化,比如做一个循环结构的方法
就非常之多,可以用je、jb、ja、jna、jcxz、jmp、loop等指令组合,甚至
还用pop,对一个结构很差的ASM程序跟本搞不了结构翻译.
用高级语言(如Delphi)本身就是规格化的,一个repeat . . . until循环对
应的机器代码一般是固定的,用一般的模式匹配就容易从机器代码得出对应
的程序结构.
2.数据引用的翻译:知道代码引用数据(包括函数)的位置(全局或是局部)、
结构、类型
这一点的难度较大,Delphi中的数据类型复杂,特别涉及到VFT(对象的
虚函数表)时更是要小心,里面可能涉及到很多不可解的引用问题,逆向翻译的
失败也往往在此。
. . .
再加上一些优化处理:比如:
1. 库函数匹配:知道代码call的是自定义的还是库函数
好在Win95的PE结构代码在调用Win32API非常规格化,你可以更居上
下文得到对应的Win32API函数、参数。
2. 优化类表:根据分析到的数据进行类的构造。
做这一步很累,你必须对Delphi的控件结构和关系有精确的掌握,分离出对类
的引用和继承,去掉祖先类的代码,保留子类的代码。
同时整理类表,生成相关DFM文件
. . .
咳,还要考虑很多。
总之,这是件头疼和费时的事情。自己搞肯定不现实(除非有特殊目的),
还是想想办法到网上找找。估计有。