现在的VMP的比较常见了，应该也是稳定性满足要求了，今天来分析一波，如有不当还请各位大佬指正

实际上 libdexjni.so在不同的APP中体积会不一样，应该是硬编码写入字符串和指令导致的

1-VMP还是先看下opcode部分知识，DEX指令格式

代码转换成DEX指令先看代码

对应的第一条指令是 

每条指令是2字节，所以先看第一条 6f 20,根据官方文档  6F的解释是 invoke-super    格式为35c

invoke-super {p0}, Landroidx/fragment/app/FragmentActivity;->getResources()Landroid/content/res/Resources;

import struct
 

start = 0x75172191ec

dump_so = "/Users/beita/tmp/bangbang/dump_vmp.dex"
length = 0x6ee27c
file = open(dump_so,'w')
file.close()
fn = AskStr(dump_so ,"save as:")
with open(fn,"wb+") as f:
    for addr in range(start , start+length):
        f.write(struct.pack("B" , Byte(addr)))
    print "success to save as " 

得到dex之后，转成jar，看了下，大部分函数是 JniLib.cV等来做的，但是有一个Integer.valueof，是一个函数索引，用来查找指令的

附加调试发现实际在这里解开这个java数组也就是 new Object的这个数组

这里用onCreate来分析  索引是18=0x12 

 JniLib.cV(new Object[] { this, paramBundle, Integer.valueOf(18) });

调试往下走，根据这个索引，会取出一个结构体信息,结合上下文信息

这里取出  0x7517a96b50的值 是  0x12

strut JavaInfo {
	uint32_t index;     // 0x12   这是java层传递的
	uint32_t unknow2;   // 0x2e   未知
	uint64_t dexcode;   // dexcode指针
	uint32_t unknow4;   // 0x03
	uint32_t unknow5;   // 0x02
	uint32_t unknow6;   // 0x02  这里看起来没有用到  但是貌似是DexCode的内容
};

struct DexCode {
    u2  registersSize;   // 3
    u2  insSize;           、、 2
    u2  outsSize;
    u2  triesSize;
    u4  debugInfoOff;       /* file offset to debug info stream */
    u4  insnsSize;          /* size of the insns array, in u2 units */
    u2  insns[1]; 
    }

registerSize = 3

insSize = 2

outsSize = 0

.....

主要看

insnsSize = 0xf

共15条指令   ，但是这个指令不是 标准的dex指令 opcode被改过，且字符串信息也是被改过，就是是说他不是系统来解析的，而且会有一个对应关系

A3 20 5C 00 21 00 6B 10  CC 20 13 02 01 00 55 11
6D 00 53 10 6D 00 72 10  60 01 00 00 69 00 

这里之前的代码还能F5看下逻辑，但是到  28b70位置处，函数很大，F5就不行了，因为太大了，貌似是刻意把这个函数写的非常大，

有点像dalvik里边的HANDLE那种搞到一起， 这样在加固过程中OLLVM混淆之后，非常庞大

在解析opcode之前会进行数据保存

信息看起来是保存到一组结构中

	struct Infos1{
		uint64_t data1;
		uint64_t *data2;  // data2 = malloc(32)   是根据JavaInfo的dexCode来的
		uint64_t data3;
		uint64_t data4;
		uint64_t data5;
		uint64_t data6;
		uint64_t data7;
		uint64_t data8;	// JavaInfo的data3的值 
	};

调试继续往下走，来到 j___Sl_I5_lO000_0SSIO_I0_O__OI_5I___lSSl0_lO5_0I5I5S5_  这个函数，这个函数不能F5了，要根据汇编来分析具体的vm是如何

解析opcde来实现代码运行的

最终的 入口是  29b70这个函数 

调用获取GetMethodID的过程是

vm_parse   29b70  -  29bb0 -  4ae80 - 4aeb4  -  4e78c - 3f92c 开始获取名称和GetMethodID
第一个参数 结合全局变量可以获得这些内容Class MethodSig MethodName  

前面提到，vmp可能会借助jni来实现，所以现在GetMethodID下段点，查看数据，方法名称和签名

寄存器x2

寄存器x3

但是因为被ollvm混淆过，体积非常大，可能是fla和bcf都加上去了

这个函数IDA识别基本上是卡死状态，所以只能是找关键点切入

看一下OLLVM的图，被混的 单个switch有几千个，而且F5卡死了

所以用快速定位关键汇编位置

分析ollvm个人觉得一点技巧是找到关键的block，下好断点，走一遍，逆向查找，基本上如果不是很大的代码块都能梳理清楚逻辑

大致如下图

现在反方向去找到是从哪里获取到的字符串，这个字符串是如何从DexCode取出来的，那么这个vm解释执行的逻辑差不多就清楚了

倒推代码来了解逻辑

上面的onCreate是根据在函数j__$S$0l0$SOOII$0lIll$SI_O0$S0ll__Il_S5lIl5lOlI5SO0S5$ 这里，根据一个输入值返回的结构体来得到的

计算处一个全局变量的偏移值

return *(_QWORD *)(qword_7517D666A0 + 8LL * a1);

其实是个结构体

用IDA直接取字符串看一下

idc.GetString(idc.Qword(idc.Qword(idc.Qword(0x7517D666A0) + 0x5C * 1) + 8 *n))

n=0是类名   android/support/v4/app/FragmentActivity

n=1是方法的参数签名 (Landroid/os/Bundle;)V

n=2是方法名称 onCreate

struct {
	void *class_name;
	void *method_sig;
	void *method_name;
}

借助IDAPython来查找一下，之所以不用快捷键x去直接找，是因为需要找到调用顺序，所以在2b970的位置开始用脚本

last_insns = ''

def fn_f8():
	idaapi.step_over()
	GetDebuggerEvent(WFNE_SUSP | WFNE_CONT, -1)

def fn_f9():
	idaapi.continue_process()
	GetDebuggerEvent(WFNE_SUSP | WFNE_CONT, -1)


last_ins = ''
def run_next():
	fn_f8()

	asm_str = idc.GetDisasm(idc.GetRegValue('pc'))

	cur_match = re.match(r'STR\s+(\S+),\s\[SP,#0x15A0\+var_1460\]', asm_str,  re.M | re.I) 
	if cur_match  :
		reg1 = cur_match.group(1) 
 
		value = hex(idc.Word(idc.Qword(reg1) + 2))
		print('nop addr', hex(cur_addr), asm_str)
		return
	else:
		last_ins = asm_str 
 
	run_next()


run_next()

 

最终找到这个上面输入的5C是从最开始的 结构体里面的DexCode取出来的

如下

A3 20 5C 00 21 00

看上图所示，从栈 SP,#0x15A0+var_1460的地址  07517AEA460 得到的正是insns的地址

A3 20 5C 00 21 00

---------------------------------------------------------------------------------------------------------------------------------------------------------

此时联系到onCreate的地方，用到了5c  而我们根据1460推导出了5c的来源

这里很清楚了，实际上指令的格式还是没变  则，解释执行OPCODE

还是6字节

A3 20 5C 00 21 00

A | G | op BBBB F|E|D|C   

对应一下就是   A=2 G=0 op=A3     BBBB是0x5C    C=0  D=0  E=0  F=1

这里的第三组也就是 0021解密一下     0021 & 0xf  = 0001  

0x5c在Android自带虚拟机里变解释执行为  MethodID，这里vmp使用的是自定义存放的一个结构体，估计是为了快速查找，因为按照逻辑，是要从DEX里边取查找，可能是为了提高效率，所以保存起来

并且我看到vmp虚拟化的java函数越多，libdexjni.so的体积越大

继续调试往下走，你会看到  CallNonVirtualMethod   正是 super.onCreate

很熟悉的格式

--------------------------------------------------------------------------------------------------------------------------------

a320 是invoke-super

005c是取MethodID

0021 解密0001 实际上是参数v0  但是我觉得这个解密多余的 因为取前边2位的

则这条指令是   invoke-super {p0, p1}, Landroidx/fragment/app/FragmentActivity;->onCreate(Landroid/os/Bundle;)V

--------------------------------------------------------------------------------------------------------------------------------

同样往下走   用脚本跑，到这里停下，刚好是前边的6个字节的指令执行完了的地方    下一组指令

这里取出来是

6B 10

调试发现实际就是  定义了一个数值

--------------------------------------------------------------------------------------------------------------------------------

6b  const

10 v0,0x1

结果就是   const v0,0x1

--------------------------------------------------------------------------------------------------------------------------------

next

--------------------------------------------------------------------------------------------------------------------------------

CC 20 13 02 01 00[A=2]op{vC, vD},kind@BBBB

CC 20  invoke-virtual  

0213   取MethodiD  requestWindowFeature     (I)Z

0001  参数

 invoke-virtual {p0, v0}, Lcom/abing/appvmp/BaseActivity;->requestWindowFeature(I)Z

--------------------------------------------------------------------------------------------------------------------------------

在5feac处找到 这三句代码，运气不错，这里刻意F5，可以看到是 取出一个对象的值，根据分析得知是 BaseActivity的属性a

修复前的指令

修复后的指令

实际指令是 0xF所以其他的nop掉 最后给一个return void 就可以了

总结 ：

1-是用JNI来解释执行opcde的 

2-op被替换了，但是 A G 那部分参数寄存器数字是不会变的，因为vmp也需要指定是几个参数，来使用

3-做过java2c的都比较熟悉，对dex的opcode比较熟悉的情况下，联系上下文很容易得到结果

4-这里的op可能被加密了，个人愚见人为这个Op加密不加密无所谓，因为最终实际上是个对应关系  0xff个opcode对应0xff个opcode

 hookjni 可以看到很多输出信息 就是说vmp实际采用的还是 jni来实现

如果要全部都替换掉，需要挨个分析指令，做一个映射表岀来

--------------------------------------------------------------------------------------------------
目前来看还是java2c + arm指令虚拟化应该是比较保险的操作，因为自己写一个解释器，纯自己实现指令，肯定问题非常多，所以指令还是通过Jni来实现的，
但是效率貌似低了些，如果这种方式加上ARM指令虚拟化，分析起来可就难受很多了
------------------------------------------------------------------------------------
样本是以前的版本，目的是为了分析和学习，这里只提供so文件，交流经验，需要样本私聊我

[2020元旦礼物]《看雪论坛精华17》发布！（补齐之前所有遗漏版本）！

最后于 1天前 被贝a塔编辑 ，原因：