聚安全libsgmain.so、libsgavmp.so初步分析

版本：libsgmainso-5.4.2010.so

 

一、静态分析:

1.IDA分析：

Binary data 16 is incorrect, maximum possible value is 0. Do you want to continue with the new value?

经过简单的修复以后可以打开：

发现有这种JNI API函数的导出；并且别的导出函数名字是经过混淆处理的；猜测是对JNI api函数的单独重新封装，便于后期的混淆控制流操作；

2.控制流的处理：

大量的这种伪造控制流，使得控制流看起来很复杂。

 

二、动态分析:

静态看不出来，下面动态调试看一下：

首先在JNI_Onload处下断点的时候，jdb附件会报以下错误：为反调试

 

可以看到在java层调用了isDebuggerConnected这个函数，这个函数是早期百度加固的一个反调试方法。

isDebuggerConnected这个函数可以在本地层看到：

 

jdb调试不起来，这时候换一个思路通过自己的主程序load进行加载起来：

然后在JNI_Onload处进行下断点，

 

 

 

首先是通过赋值opcode和VM的其实地址计算出对应的偏移地址，然后得到对应的Handler的执行地址。三、四条指令执行完以后就会如此反复的执行。

 

三、反混淆：

 

发现在计算出来的偏移地址正是下一条指令的hex码。

四、初步分析libsgavmp.so:

下面为类似于对应的opcode，就是高级版的fla，当然也可能有VMP，能力和时间有限，还没有发现。。

 

 

五、正向实现：

第一步：首先对控制流进行划分分块处理；

第二步：每一个块分配一个opcode,放在每一个块的后面；

第三步：通过一个dispatcher，根据opcode计算出对应的偏移地址，然后找到对应的下一个块的起始地址；dispatcher可以设计的很复杂也可以设计的简单；

第四步：循环执行；