-
-
[原创] 自写简易Arm64模拟执行去除控制流平坦化
-
发表于: 2024-12-19 17:50
-
为什么要自写模拟执行？
现在比较流行的反控制流平坦化 一般由Unidbg、 frida Stalker、这种runtime下线性的记录块的信息来完成patch， 此种方式有优势，也有缺陷。比如对else分支无法记录，如果手动干预else分支 那么就需要在上下文下补环境，简易的分支下还算较为简单，但是复杂的情况下，实现难度非常大(其实是地狱式的级别)。于是在猜想能不能实现一个基于特征的模拟执行，由于之前写过类似IDA的F5汇编解析，也手写过伪模拟执行的仿真器，所以写一个基于ollvm特征的模拟执行难度也不大，于是就开始了开发之路。。
先附上源码链接：AntiOllvm
功能
这是一个基于函数级别的模拟执行，并不分析整个So，也不需要补环境，基于IDA的CFG信息生成并且自动patch所有的真实块。但是需要对主分发块、次分发块进行标识（仅此而已，你并不需要对汇编、CFG构建有所了解 只需要标识这2个即可还原Fla）。Demo里包含比较通用的特征查找，具体可查看源码。如何食用请跳转github 。PS： 如果是魔改的Ollvm 请自行理解框架，并结合实际情况进行代码调整。目前仅兼容标准的ollvm特征。 更多兼容正在调整中.
原理介绍
现在先回顾一下Fla的特征。 先来一段伪代码
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
Label1: int a = 100;
switch (a)
{
case 98:
{
//Logic
a = 101;
goto Label1;
}
case 99:
{
//Logic
a = 98;
goto Label1;
}
case 100:
{
//Logic
a = 99;
goto Label1;
}
default:
break;
}
|
以上其实就是比较简易的一个分发块伪代码； 一个简单的if逻辑编译成So 经过Fla会变成这样的CFG图
F5的结果是这样的
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
__int64 __fastcall sub_181E0C(__int64 a1)
{ int v2; // w8
__int64 v3; // x0
__int64 v4; // x1
__int64 v5; // x2
__int128 v7; // [xsp+0h] [xbp-70h] BYREF
char v8; // [xsp+10h] [xbp-60h]
__int64 v9; // [xsp+28h] [xbp-48h]
v2 = 1999739781;
v9 = qword_7289F8;
while ( 1 )
{
while ( v2 == 1087191716 )
{
v8 = -12;
v7 = xmmword_587FDD;
qword_7289F8 = (__int64)sub_1815C0(&v7, 17);
v2 = -1880484146;
}
if ( v2 != 1999739781 )
break;
if ( v9 )
v2 = -1880484146;
else
v2 = 1087191716;
}
sub_165910(*(_QWORD *)(a1 + 8), aVIsvSvS, *(_QWORD *)(a1 + 32));
v3 = sub_15D4E4(*(_QWORD *)(a1 + 8), 3LL);
return sub_181EE0(v3, v4, v5);
|
结合一下伪代码可以看出分支的控制由CSEL指令来决定的 即为
1 |
CSEL W8, W24, W21, EQ |
那么此项值在哪初始化呢？ 在主分发器开始进入之前
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
MOV W21, #0x16CE
MOV W23, #0x9B85
MOV W24, #0x3AA4
ADRP X26, #xmmword_587FDD@PAGE
MOV W8, #0x9B85
MOV X20, X1MOV X19, X0MOVK W21, #0x8FEA,LSL#16
MOVK W23, #0x7731,LSL#16
MOVK W24, #0x40CD,LSL#16
MOV W25, #0xF4
ADD X26, X26, #xmmword_587FDD@PAGEOFF
MOVK W8, #0x7731,LSL#16
STR X4, [SP,#0x70+var_48]
|
最后于 2024-12-19 20:12
被IIImmmyyy编辑
，原因：
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
恰恰相反，我写这个的目的就是处理复杂情况，无论是何种情况下 块和块的链接只有2个结果 真实块或者分发块。满足条件即可遍历出结果 |
|
|
大佬为啥arm的vmp没有ida插件呢，可否引用你的vm3.5插件呢 |
|
|
|
|
|
请问大佬，arm32 thumb适用吗 |
|
|
可曾遇到共用块 |
|
|
不适用 暂未有arm32 和x86的支持计划。 如果要做多架构的话 需要抽出一个中间语言作为桥接。 我闲麻烦没有做了 |
|
|
for循环就是标准的共用块情况。 查找过程中会对正在查找的block进行标记，如果递归发现是已经正在查找的则返回，同时链接已经存在的block。此处理就可完成for循环的处理 ``` if (block.isFind) ```
最后于 2024-12-20 14:28
被IIImmmyyy编辑
，原因：
|
|
|
好的，retdec优化貌似支持所有的架构 |
|
|
其实这个也支持，也不难。 你可以仿造arm64的写法进行逻辑的剥离。 代码量很少 并不多的。不想支持的原因主要还是目前工作中需要单独去分析arm32 的情况实在是太少了。 arm64已经是主流了 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
好的，试着搞搞 |
|
|
|
|
|
|
|
|
|
|
|
这个是在修复过程中对指令的兼容度不够大。 在runtime的过程中 对其他指令并不敏感 补上对应的OpCode即可。 主要是需要识别CSEL, MOV,MOVK,CMP指令作为runtime的特征运行
最后于 2024-12-23 11:31
被IIImmmyyy编辑
，原因：
|
|
|
|
|
|
这个东西可不好patch |
|
|
这应该是一个函数内包含多个不同的操作分发器引起的 比如CMP W10,W28，这个是主分发器， 然后分支下出现了CMP W8,W30 这种情况导致次的主分发器被认定成了真实块。 不知是否能附上样本？ |
