起初E-debug是由xjun开发的,但是由于我并不满足E-debug的函数识别率,于是基于xjun的源码进行了修改、重构,在此对Xjun哥表示感谢

E-debug Plus的目的是识别函数命令,为此首先开发了ECodeMake,ECodeMake是将易语言的支持库函数转换为Esig的一款工具:https://github.com/fjqisba/CodeMake

例如取字节集长度这个命令

ECodeMake会将之转换为8B44240C8B0085C075078B4C24048901C38B5424048B40048902C3

其中为了识别函数的尾部,运用到了Bea反汇编引擎.

而同时E-debug则是一款OD的插件,能够提取蕴含在易语言静态编译程序里的命令地址信息,将之逐个与上面十六进制进行对比,就能得出函数的命令了.

很明显有了这两个东西,绝大多数函数都能识别出来了.

然而易语言支持库命令中不乏有这样的函数:

这样的函数

甚至是这样的函数

起初我的做法比较愚蠢,就是通过在CODEMAKE中对比函数来得到这些无法识别的函数,再对它们进行额外的记录,像下面这样.

typedef struct
{
	char	m_CommandName[64];              //命令名称
	int  	m_CallType;                     //函数类型,0代表无重复CALL,1代表需要判断第二个CALL,2代表需要判断IAT函数的CALL
                                            //3代表判断CALL之前有一段特殊代码
	ULONG   m_CallOffset;                   //记录需要判断的call的偏移
	int		m_size;                         //程序一阶函数的字节大小
	UCHAR   m_opcode[128];                  //匹配的字节
	int     m_size2;                        //程序二阶函数的字节大小
	UCHAR	m_opcode2[128];                 //类型1或3时的opcode
	char    m_IATEAT[128];                  //call为类型2时为IAT与EAT
}ESTATICLIBOPCODE, *PESTATICLIBOPCODE;

这就是E-debug3.0当中的做法,现在看来是非常不好的,即使通过一段时间的完善,能够识别出易语言系统核心支持库的600多条命令,

后续批量制作特征文本、对任意函数生成特征文本又该怎么办呢?

于是我思考了很久,想到了得自己制作一个简易的函数<->文本转换引擎,即ECODEMAKE负责将函数转换为文本,E-debug则负责将文本转换为函数进行识别.

有些无论如何也无法分辨出来的函数,例如 下载对象.取对象信息 与 FTP上传对象.取对象信息,两个函数除了地址不同外没有任何分别,采用单函数多重表示法

表示成 FTP上传对象|下载对象.取对象信息

再如 FTP上传对象.取已上传长 与 下载对象.取已下载长,两个完全一样的函数表示成 FTP上传对象.取已上传长||下载对象.取已下载长

Esig就是ECODEMAKE生成的函数文本化格式,为了应付各种各样的函数,有以下文本格式,
<>:CALL 命令,例如<20181116>

-->:jmp 跳转指令,例如50-->58C3

<[]>:IAT/EAT 函数调用指令,例如<[KERNEL32.InitializeCriticalSection||RtlInitializeCriticalSection]>,前面是检索导入表,后面为检索导出表

[]:IAT/EAT 函数jmp指令,例如[KERNEL32.TerminateThread]

[]>:jmp 函数类跳转,例如易语言调用Delphi的支持库就会采取跳转的方式.

??:通配符

通过以上一些格式,我们可以想象出易语言的大部分函数终于能表示出来了.

在生成出来的Esig文件中,采用了函数命名的方式来记录,上半部分是子函数列表,下半部分是主函数列表. 在可视化的Esig文件中,每个人都可以对识别出错的函数进行修改,这正是我的目的.

同时由于易语言fne支持库的函数和实际编译出来的程序代码有出入,导致Esig中有一些目前识别错误的易语言命令,如果有的话可以反馈给我完善.

对于有一些ECODEMAKE很难制作出来的Esig,可以考虑人工生成.例如飘零金盾8.0的Esig就是我配合CODEMAKE+人工制作的一份Esig,

需要注意的是,不应该出现类似于 A8A6A这样的特征码,因为存在半个字节,不过FF5?56EE这种却是可以的.

E-debug Plus对于函数的匹配要求相当严格,一个字节出错也会匹配失败，所以此款软件目前不适合用于分析那些经过加壳处理的软件,
因为这些软件会修改调用函数的IAT CALL,导致函数字节发生变化. 这个问题从理论上能用模糊匹配来解决,即通过计算匹配字节的百分比来判断函数,然而目前这并不是我想要研究的方向. 脱壳或许是更好的处理方式,然而有时壳会将整个支持库函数进行VM,如此则软件完全失效. 编译或者独立编译的程序,由于软件数目少,研究难度低,暂时也懒得去写了.

将插件与Esig文件夹放置于OD目录下

OD\plugin\E-debug.dll

OD\plugin\esig即可

未加壳的程序,在text区段可直接分析. 加壳的程序,可待text区段解码后，CPU窗口到达text区段再开始分析.

如果有分析崩溃的样本,可以发送至[email protected]

交流QQ群:633783602

2019.01.27:

修复扫描判断逻辑BUG,扫描算法基本完成

2019.01.28:

依旧是修复判断逻辑BUG,完善了几个支持库,极大减少了插件崩溃的概率

2019.02.20:

修复FF15与FF25识别BUG,略微提升识别速率