流程平坦化混淆是ollvm里面最难还原,最影响分析效率的一个混淆pass,最近花了点时间,终于把它搞掉了.
刚开始是打算使用IDA的微码进行反混淆,搜到了Rolf Rolles大佬的HexRaysDeob,
还有它的Python版本PyHexRaysDeob.
研究了下发现微码API确实是太难用了,而且很多分析好像都得自己做,所以我暂时放弃该方案.
随后转到了binja, 发现这篇文章Dissecting LLVM Obfuscator Part 1,貌似简单可行,修改了下,用无名侠大佬基于Unicorn 的ARM64 OLLVM反混淆帖子的样本跑,失败了.
看来还是得自己干.

下文中反混淆用的样本是无名侠的libvdog.so(vdog)和自己编译的另外一个小程序(cff).

反混淆主要分两步:分析和修复.

分析

这里思路源于llvm-defobfuscator,熟悉它的话可以直接跳到后面修复内容.

流程平坦混淆代码结构:

...
state_var = n;
while(1) {
    switch (state_var) {
        case x:
            code_region_x
        case y:
            code_region_y
        case z:
            code_region_z
        case ...
    }
}

反混淆需要的信息主要有:

• switch语句各case的入口, 出口基本块.即上面各个case对应的代码区域(code_region_xxx).
• case编号和case入口对应关系
• 各case出口的跳转目标case.对于条件跳转,我们还得知道真假分支和目标case的对应关系.

这些信息通过binja还是很容易分析出来的.
vdog中的代码:

  43 @ 0007067c  bool cond:4_1 = x9.w9 != 0x76579ace
  44 @ 00070680  uint64_t x8_1 = zx.q(x9.w9)
  45 @ 00070684  if (cond:4_1) then 10 @ 0x704f0 else 47 @ 0x70688

我们可以看到,最后一条指令是状态变量与0x76579ace进行比较,相等的情况下走0x70688(假分支),这个地址就是case 0x76579aced对应代码区域的起始地址.

 423 @ 000710c0  if (x8_26.w8 == 0xdcf244e1) then 439 @ 0x71080 else 444 @ 0x710c4

对于这个测试, 0xdcf244e1对应的case 入口是0x71080(真分支)

用这个方式来获取case代码区域的起始地址是比较可靠的.
因为llvm在给switch生成代码时,据我观察,在无法使用跳转表的情况下,会转到使用二分查找实现,查找到最后一般都会有这么一条测试case编号的指令.

找到case出口也比较简单:包含对状态变量进行更新基本块的出口就是case出口.

 104 @ 000707bc  aop_init()
 105 @ 000707c4  uint64_t x8_1 = 0xc88d21cd
 106 @ 000707c8  goto 10 @ 0x704f0

实际上,现实代码中会存在有多个出口的情况,这个问题在修复的时候再讨论.

如果是条件跳转,我们还需要知道跳转目标与测试条件的对应关系.

 134 @ 00070854  bool cond:12_1 = x0_4.w0 != 0
 135 @ 00070868  if (cond:12_1) then 144 else 146
 ---
 144 @ 00070868  uint64_t x8_1 = 0x91c5439 ; 真分支
 145 @ 00070868  goto 155 @ 0x7086c ; 跳转到分发器
 ---
 146 @ 00070868  uint64_t x8_1 = 0xf291f0e9 ; 假分支
 147 @ 00070868  goto 155 @ 0x7086c ; 跳转到分发器

case 0x91c5439 对应的条件可以通过查看入口边的类型得到

def resolve_branch_condition(state):
    il_bb = state.il_basic_block
    assert len(il_bb.incoming_edges) <= 1
    if len(il_bb.incoming_edges) == 1:
        return il_bb.incoming_edges[0].type == BranchType.TrueBranch
    else:
        return True

到这反混淆所需信息就完全获取到了.

以上我主要说明了思路, 省略了很多细节.

例如cff中下面这种case

  62 @ 00000814  bool cond:5_1 = x19_1.w19 == 0xcb0c4ceb
  63 @ 0000081c  uint64_t x7_1 = 0xd40c7864
  64 @ 00000820  uint64_t x20 = zx.q(x1.w1)
  65 @ 00000824  if (cond:5_1) then 16 @ 0x768 else 76 @ 0x828

这个基本块既是case入口,又是出口,还是分发器代码的一部分.

vdog JNI_OnLoad里面的一个case:

 313 @ 00070e54  bool cond:60_1 = x9.w9 != x8_22.w8
 314 @ 00070e58  uint64_t x8_1 = zx.q(x9.w9)
 315 @ 00070e5c  if (cond:60_1) then 10 @ 0x704f0 else 320 @ 0x70e64

313处, 在分发器里面,状态变量(x9.w9)跟另外一个变量比较(x8_22.w8), 这时候x8_22.w8的值是多少?
上面两个问题我在代码里面都有处理,有兴趣可以参考代码.
即使没有处理也没有关系,我反混淆的修复是保守的,对于无法处理的情况,仍然会走原来逻辑,只是最终反混淆效果会差一点.

下面开始修复部分内容,修复难度在我看来要比分析难. 修复cff这个看起来简单的样本要比vdog难.

修复

代码修复主要有两个难点:

• patch二进制
• 处理编译器优化移动的代码

patch二进制

修复时,在代码中寻找用来patch代码空洞还是比较困难的.
之前考虑使用IDA微码进行反混淆,这是最主要的原因.
llvm-deobfuscator是把混淆框架代码作为空洞使用.
而我反混淆目标是为了在IDA中, 使用他的反编译器进行静态分析, 不需要创建一个新的可执行的二进制, 所有我是用IDA创建一个新的代码段来存放patch代码.
这种处理方法能让我保留原来的分发器,有意的保留分发器, 可以在未识别到真实后继基本块或者case出入口的情况下,走原来分发器流程.
如果所有状态的后继都被我处理了, 分发器就变成不可达代码, IDA的反编译器会自动把它优化掉.

处理编译器优化移动的代码

目前看到的反混淆文章好像都没有提到如何处理这个问题的.
如下函数:

void foo1()
{
    int state_var = 0;
    while(1) {
        switch (state_var) {
            case 0: {
                        puts("enter case 0");
                        state_var = 1;
                        break;
                    }
            case 1: {
                        puts("enter case 1 or 2");
                        puts("enter case 1");
                        state_var = 2;
                        puts("exit case 1 or 2");
                        break;
                    }
            case 2: {
                        puts("enter case 1 or 2");
                        puts("enter case 2");
                        state_var = 3;
                        puts("exit case 1 or 2");
                        break;
                    }
            case 3: {
                        puts("enter case 3");
                        state_var = 4;
                        break;
                    }
        }
        if (state_var == 4) {
            break;
        }
    }
}

有可能会被编译器优化成:

void foo2()
{
    int state_var = 0;
    while(1) {
        switch (state_var) { // 分发器入口
            case 0: {
                        puts("enter case 0");
                        state_var = 1;
                        break;
                    }
            case 1: case 2: {
                           puts("enter case 1 or 2"); // 1, 如何处理这部分代码?
                           if (state_var == 1) {
                               puts("enter case 1");  // case 1 入口
                               state_var = 2;
                           } else {
                               puts("enter case 2");  // 2, 用上文提到的方法只能识别到case 1的入口, 怎么确定这是case 2的入口?
                               state_var = 3;
                           }
                           puts("exit case 1 or 2");  // 3, 如何处理这部分代码?
                           break;
                       }
            case 3: {
                        puts("enter case 3");
                        state_var = 4;
                        break;
                    }
        }
        if (state_var == 4) {
            break;
        }
    }
}

我解决的办法是通过代码拷贝,把foo2转换成foo1.具体做法是

• 拷贝从分发器入口,到case入口的所有代码到patch代码区域,并在执行case代码前,执行这些复制过来的指令.
• 同样的,在离开case时, 拷贝case出口到分发器入口所有代码到patch代码区域,并在执行后继case代码前,执行这些复制过来的指令.

问题2, 属于分析阶段的问题, 我现在还没有处理.
当前反混淆方案会在进入case 1之后, 由于state 2对应case 2的入口没有识别到, 控制流会重新进入分发器, 从分发器进入case 2.

现实代码中,还会出现下面的情况

CMP             W9, #0
CSET            W9, GT
EOR             W8, W9, W8
TBNZ            W8, #0, to_dispatcher ; 出口1
CBZ             W0, to_dispatcher     ; 出口2
...
CMP             W8, #0x30 ; '0'
MOV             W8, #0xdeadbeef     ; next case
CSEL            W24, W24, W8, EQ
B               to_dispatcher       ; 出口3

case有多个出口情况,伪码:

...
while(1) {
    switch (state_var) {
    ....
        case x: {
                    state_var = next_case; // 设置跳转目标
                    // 真实后继case只有一个, 但这个case有多个出口
                    if (cond) {
                        puts("exit 1");
                        break;
                    }
                    puts("exit 2");
                    break;
                }
    ....
}

为了处理这种代码, 我们在修复的时候, 需要找到case的所有出口,在每个出口处都进行patch.

综上,我们需要进行如下修复操作:

• 找到case的所有出口
• patch case 的出口, 使其跳转到我们的path代码
• 拷贝patch case 出口时覆盖掉的指令到patch代码区域
• 拷贝case出口到分发器入口所有代码到patch代码区域
• 拷贝从分发器入口,到case入口的所有代码到patch代码区域
• 使用汇编器,生成从patch代码到真实目标跳转指令

修复后的代码有如下两种布局.

• 只有一个跳转目标的代码

;原始代码
tbnz w8,  #0, to_dispatcher ; 出口1
cont:
cbz  w0, to_dispatcher     ; 出口2

;修复出口1后的代码
b   patch_code ;  跳转到我们的patch代码
cont:
cbz w0, to_dispatcher     ; 出口2

; patch 代码区域
patch_code:
tbnz w8, #0, to_case_entry ; 准备进入真实目标
b cont ; 返回
to_case_entry:
patch时覆盖掉的指令
离开当前基本块到进入分发器的所有指令
离开分发器到目标case的所有指令
跳转到目标case

• 有两个跳转目标的代码

这个基本块位于cff 0x00000798
csel    w7, w15, w14, eq
mov     w20, w0
b       to_dispatcher

cset    w7, eq ; !!!不能在此直接跳转到patch代码, 下面的mov指令是活跃的!!!
mov     w20, w0
b       patch_code

; patch代码区域
patch_code:
cbnz    w7, true_branch (0x8)
cbz     w7, false_branch

true_branch:
patch时覆盖掉的指令
离开当前基本块到进入分发器的所有指令
离开分发器到真分支入口的所有指令
跳转到真分支


false_branch:
patch时覆盖掉的指令
离开当前基本块到进入分发器的所有指令
离开分发器到假分支的所有指令
跳转到假分支

下面是两个具体的修复实例.

• 修复cff函数入口跳转到真实目标

cff样本的分发器位于0x00000768
分发器入口代码

MOV             W0, W20 ; W0活跃
MOV             W19, W7
CMP             W19, W10

这个块内的W0是函数返回值,不可以删除这条指令.
从函数入口到真实后继的修复代码:

loc_4000000
MOV             W0, W20 ; 复制的dispatcher代码
MOV             W19, W7
CMP             W19, W10

CMP             W19, W11 
CMP             W19, W8
MOV             W7, W19
MOV             W20, W0
B               loc_7D0 ; 0x2495548b 的后继

可以看到,修复代码复制了分发器到case入口路径上的所有指令.

• 修复vdog

再来看下vdog中起始地址为0x000704dc的基本块

STR             W9, [X19,#0x1C]
B               loc_704F0 ; 跳转到分发器

从函数入口到真实后继的修复代码:

loc_4000000

STR             W9, [X19,#0x1C] ; 0x000704dc基本块指令

MOV             W9, W8 ; 分发器指令
CMP             W9, W27
CMP             W9, W23
CMP             W9, W26
CMP             W9, W20
MOV             W8, #0x76579ACD
CMP             W9, W8
...
MOV             W8, #0x667472C5
CMP             W9, W8
MOV             W8, W9
B               loc_707E0 ; 0x667472c5对应的case入口

0x000704dc基本块另外一个前驱

loc_704CC
LDR             X8, [X19,#0x80]
MOV             W8, #0x6FA40FC9
LDR             W9, [X19,#0x18] ; 该指令将被覆盖
; 下落到0x000704dc
STR             W9, [X19,#0x1C]
B               loc_704F0 ; 跳转到分发器

修复后:

loc_704CC
LDR             X8, [X19,#0x80]
MOV             W8, #0x6FA40FC9
B               loc_4006800 ; 跳转到修复代码, 这里覆盖掉了原始指令 LDR W9, [X19,#0x18]

loc_4006800
LDR             W9, [X19,#0x18] ; loc_704CC被覆盖的指令

STR             W9, [X19,#0x1C] ; 0x000704dc基本块指令

MOV             W9, W8          ; 复制分发器代码
CMP             W9, W27
CMP             W9, W23
CMP             W9, W26
CMP             W9, W20
MOV             W8, #0x76579ACD
CMP             W9, W8
...
MOV             W8, #0x6FA40FC9
CMP             W9, W8
MOV             W8, W9
B               loc_70778 ; 0x6fa40fc9的后继

改进

• 拷贝指令时,过滤死代码

当前实现拷贝了大量的垃圾指令,有时候函数过大会导致IDA无法反编译;同时也会增加IDA分析用时.修复vdog JNI_OnLoad大概用了21K字节代码,还原用时15分.

• 拷贝时修复pc指令

拷贝pc相关指令,如函数调用,全局变量引用,需要进行重定位修复.

• 自动查找状态变量和分发器

vdog的JNI_OnLoad里面有6个分发器,不知道是改了ollvm还是inline进来的.

参考资源

• 思路和部分代码源于llvm-deobfuscator
• z3相关代码源于f-ing-around-with-binaryninja

附件包含所有的代码和样本.
所有代码和样本也可从github下载: ollvm-breaker
另外, 反混淆脚本是在binja GUI-less模式下运行, 需要Binary Ninja商业版.

最后,放效果.

在IDA中打开cff或vdog后,运行对应的fix-xxx.py脚本反混淆.
我修复了vdog五个函数,JNI_OnLoad,crazy::GetPackageName,prevent_attach_one,attach_thread_scn,crazy::CheckDex.在IDA中运行修复脚本,重新分析分析程序后,可以查看这些函数的反混淆效果.

先看cff的原始代码

unsigned int target_function(unsigned int n)
__attribute((__annotate__(("fla"))))
__attribute((noinline))
{
  unsigned int mod = n % 4;
  unsigned int result = 0;

  if (mod == 0) result = (n | 0xBAAAD0BF) * (2 ^ n);

  else if (mod == 1) result = (n & 0xBAAAD0BF) * (3 + n);

  else if (mod == 2) result = (n ^ 0xBAAAD0BF) * (4 | n);

  else result = (n + 0xBAAAD0BF) * (5 & n);

  return result;
}

还原后

unsigned int __fastcall target_function(unsigned int n)
{
  unsigned int v2; // [xsp+Ch] [xbp-14h]

  v2 = n & 3;
  if ( (n & 3) == 0 )
    return (n | 0xBAAAD0BF) * (n ^ 2);
  if ( v2 == 1 )
    return (n & 0xBAAAD0BF) * (n + 3);
  if ( v2 == 2 )
    return (n ^ 0xBAAAD0BF) * (n | 4);
  return (n - 1163210561) * (n & 5);
}

vdog的JNI_OnLoad还原后

jint JNI_OnLoad(JavaVM *vm, void *reserved)
{
  int v2; // w9
  _JNIEnv *v3; // x1
  _BOOL4 v5; // w8
  crazy *v6; // x0
  int v7; // w8
  crazy *v8; // x0
  _JNIEnv *v9; // x1
  const char *v10; // x0
  _JNIEnv *v12; // x1
  crazy *v13; // x0
  char *v14; // x0
  const char *v15; // x0
  crazy *v16; // x0
  _JNIEnv *v17; // x1
  int v18; // w0
  crazy *v19; // x8
  unsigned int v20; // w0
  crazy *v21; // x0
  __int64 v23; // [xsp-FD0h] [xbp-1240h]
  __int64 v24; // [xsp-FC0h] [xbp-1230h]
  __int64 v25; // [xsp-FA0h] [xbp-1210h]
  __int64 v26; // [xsp-7D0h] [xbp-A40h]
  char *v27; // [xsp+8h] [xbp-268h]
  void *v28; // [xsp+10h] [xbp-260h]
  int v29; // [xsp+18h] [xbp-258h]
  int v30; // [xsp+1Ch] [xbp-254h]
  JavaVM *v31; // [xsp+20h] [xbp-250h]
  __int64 *v32; // [xsp+28h] [xbp-248h]
  __int64 *v33; // [xsp+30h] [xbp-240h]
  crazy::String *v34; // [xsp+38h] [xbp-238h]
  void (__fastcall **v35)(JavaVM *, void *); // [xsp+40h] [xbp-230h]
  const char *v36; // [xsp+48h] [xbp-228h]
  int v37; // [xsp+54h] [xbp-21Ch]
  int v38; // [xsp+58h] [xbp-218h]
  int v39; // [xsp+5Ch] [xbp-214h]
  char *v40; // [xsp+60h] [xbp-210h]
  __int64 *v41; // [xsp+68h] [xbp-208h]
  const char *v42; // [xsp+70h] [xbp-200h]
  int v43; // [xsp+7Ch] [xbp-1F4h]
  __int64 *v44; // [xsp+80h] [xbp-1F0h]
  FILE *v45; // [xsp+88h] [xbp-1E8h]
  int v46; // [xsp+94h] [xbp-1DCh]
  crazy *v47; // [xsp+98h] [xbp-1D8h]
  __int64 v48; // [xsp+A0h] [xbp-1D0h]
  int v49; // [xsp+A8h] [xbp-1C8h]
  int v50; // [xsp+ACh] [xbp-1C4h]
  crazy *v51; // [xsp+B0h] [xbp-1C0h]
  char *v52; // [xsp+B8h] [xbp-1B8h]
  crazy *v53; // [xsp+C0h] [xbp-1B0h]
  crazy *v54; // [xsp+C8h] [xbp-1A8h]
  _QWORD v55[3]; // [xsp+D0h] [xbp-1A0h]
  _QWORD *v56; // [xsp+E8h] [xbp-188h]
  const char *v57; // [xsp+F0h] [xbp-180h]
  char *v58; // [xsp+F8h] [xbp-178h]
  int v59; // [xsp+104h] [xbp-16Ch]
  const char *v60; // [xsp+108h] [xbp-168h]
  JavaVM *v61; // [xsp+110h] [xbp-160h]
  _QWORD v62[32]; // [xsp+118h] [xbp-158h]
  __int64 v63; // [xsp+218h] [xbp-58h]

  v28 = reserved;
  v31 = vm;
  v63 = *(_QWORD *)off_DFF90;
  v29 = v2;
  v30 = v2;
  v32 = &v26;
  v33 = &v25;
  v34 = (crazy::String *)&v24;
  v35 = (void (__fastcall **)(JavaVM *, void *))&v23;
  v54 = 0LL;
  v61 = vm;
  v55[0] = (char *)*vm + 48;
  v62[0] = *(_QWORD *)v55[0];
  if ( ((unsigned int (__fastcall *)(JavaVM *, crazy **, __int64))v62[0])(vm, &v54, 65540LL) != 0 )
    return -1;
  v60 = (const char *)v54;
  v61 = *(JavaVM **)v54;
  v55[0] = v61 + 219;
  v62[0] = v61[219];
  ((void (*)(void))v62[0])();
  v16 = v54;
  *off_DFFF8 = (__int64)v54;
  v18 = crazy::GetApiLevel(v16, v17);
  v19 = v54;
  *off_DFF18 = v18;
  v47 = v19;
  v10 = (const char *)crazy::GetPlatformVersion(v19, v9);
  if ( strchr(v10, 77) != 0LL )
    *off_DFF18 = 23;
  v38 = *off_DFF18;
  if ( v38 > 23 )
    *off_DFEE8 = 1;
  v49 = sub_2E738();
  if ( v49 == 2 )
  {
    v53 = v54;
    v7 = sub_76F60(v53) & 1 ? -1618151004 : -990688990;
    if ( v7 > -990688991 )
      return -1;
  }
  v44 = v32;
  memset(v32, 0, 0x7D0u);
  v27 = (char *)v32;
  v20 = getpid();
  sprintf(v27, "/proc/%d/cmdline", v20);
  v45 = fopen(v27, "r");
  if ( v45 != 0LL )
  {
    v41 = v33;
    memset(v33, 0, 0x7D0u);
    v42 = (const char *)v33;
    fscanf(v45, "%s", v33);
    fclose(v45);
    v5 = strchr(v42, 58) == 0LL;
    if ( v5 || (v52 = strstr(v42, "sg.bigo.enterprise.live:service"), v52 != 0LL) )
      anti_debug_start();
  }
  v43 = *off_DFF18;
  if ( v43 == 15 )
    j_aop_init();
  anti_section_hook();
  v13 = (crazy *)crazy::checkSignature_1(v54, v12);
  if ( ((unsigned __int8)v13 & 1) == 0 )
    crazy::AbortProcess(v13);
  v14 = (char *)sub_2E998();
  v40 = v14;
  if ( *v14 )
  {
    crazy::GetPackageName((crazy *)v14);
    v62[0] = v34;
    v36 = *(const char **)v34;
    v6 = (crazy *)strcmp(v36, v40);
    v37 = (int)v6;
    if ( v37 != 0 )
      crazy::AbortProcess(v6);
    crazy::String::~String(v34);
  }
  v46 = sub_2E738();
  if ( v46 == 1 )
  {
    v50 = sub_F688();
    if ( v50 == 0 )
      return -1;
  }
  v51 = v54;
  v8 = (crazy *)crazy::checkdex_1(v54, v3);
  if ( ((unsigned __int8)v8 & 1) == 0 )
    crazy::AbortProcess(v8);
  v39 = sub_E7EC(*off_DFE98[0], "JNI_OnLoad", v35);
  if ( v39 != 0 )
    (*v35)(v31, v28);
  v15 = (const char *)sub_2E728();
  v48 = strlen(v15);
  if ( v48 != 0 )
  {
    v56 = v62;
    v21 = (crazy *)memset(v62, 0, sizeof(v62));
    crazy::GetPackageName(v21);
    v61 = (JavaVM *)v55;
    v57 = (const char *)v55[0];
    crazy::String::~String((crazy::String *)v55);
    v58 = (char *)v62;
    v60 = (const char *)sub_2E728();
    sprintf(v58, "/data/data/%s/.hide/%s", v57, v60);
    v59 = remove(v58);
  }
  return 65540;
}

[CTF入门培训]顶尖高校博士及硕士团队亲授《30小时教你玩转CTF》，视频+靶场+题目！助力进入CTF世界