O-MVLL:支持ARM64的基于LLVM的代码混淆模块

O-MVLL介绍

O-MVLL的开发灵感来自于另一个著名的基于LLVM的代码混淆项目ollvm，并在其基础上做了创新和改进。O-MVLL的混淆逻辑实现方式也是通过LLVM Pass，支持也仅会支持ARM64架构，根据作者所说，这是由于当初的设计选择。此外，作者还使用了pybind11，用户可以使用python脚本来对O-MVLL进行配置，从而灵活的运用作者封装好的各种代码混淆方式。

混淆后的可执行文件相比于正常编译的可执行文件来说，抵抗逆向工程的能力增强，但与源代码的功能相同，能够在一定程度上保护源代码和程序，增加逆向工程的分析成本。

作者的介绍文档： O-MVLL Documentation (obfuscator.re)

开源项目github地址： GitHub - open-obfuscator/o-mvll: O-MVLL is a LLVM-based obfuscator for native code (Android & iOS)

作者的工作邮箱： ping@obfuscator.re（可以向他提交bug和issues，也可以问他一些项目的问题，回复很快，赞）

目前项目包含了7种代码混淆方式，它们分别是：Anti-Hooking,Arithmetic Obfuscation,Control-Flow Breaking,Control-Flow Flattening,Opaque Constants,Opaque Fields Access Strings Encoding。它们的实现细节分析见下一篇随笔O-MVLL代码混淆方式 - Uiharu - 博客园 (cnblogs.com)。

 

项目编译安装

编译方式可见作者的介绍文档中，Compilation一栏。作者提供了Linux、macOS两个平台的编译方式，并且提供了docker file。这里简单介绍下使用docker 的编译安装方式

拉取docker镜像并下载依赖

$ docker pull openobfuscator/omvll-ndk
$ git clone https://github.com/open-obfuscator/o-mvll.git

$ curl -LO https://data.romainthomas.fr/omvll-deps-ndk-r25.tar
$ mkdir -p ./third-party
$ tar xvf omvll-deps-ndk-r25.tar -C ./third-party
$ docker run -it openobfuscator/omvll-ndk

进入docker容器内部，将下载的依赖和文件复制过来

$ docker cp ./third-party $你的容器id:/
$ docker cp ./o-mvll $你的容器id:/

之后给予文件运行权限并运行

$ chmod +x /o-mvll/scripts/docker/ndk_r25_compile.sh
$ sh /o-mvll/scripts/docker/ndk_r25_compile.sh

此时完成整个项目的构建。

下载Clang from NDK

项目构建完成后，需要使用ndk的clang来调用该项目作为编译过程中的插件，因此还需要安装ndk clang，可以在此处下载：NDK 下载  |  Android NDK  |  Android Developers (google.cn)

选择Linux64位的下载，解压后复制到docker容器中，解压后的文件夹中的toolchains/llvm/prebuilt/linux-x86_x64/bin中包含有ndk所使用的clang，为了方便调用，可以将该路径加入到环境变量当中，之后在命令行中使用clang，即表示使用该路径下的ndk的clang。

 

基本使用

现在我们编写了一个文件名为main.c的程序，将要使用O-MVLL对其进行混淆，可以使用如下指令得到一份混淆后的可执行文件main：

$ clang --target=aarch64-linux-android21 -fpass-plugin=libOMVLL.so main.c -o main

其中，-fpass-plugin指定的动态链接库即为O-MVLL项目编译出来的文件，其位置应该处于o-mvll/src/build_ndk_r25当中。由于O-MVLL仅支持aarch64，因此还需要使用--target指明目标架构。或者也可以直接使用

$ aarch64-linux-android21-clang -fpass-plugin=libOMVLL.so main.c -o main

这样就不用显式地使用target指明目标架构了

配置文件omvll_config.py

之前提到，O-MVLL做出的创新是使用pybind11提供了pythonAPI，以供用户配置代码混淆的方式，因此在执行上述指令之前，需要配置好omvll_config.py文件。

O-MVLL将会尝试在调用clang的目录下寻找该文件，如果找不到该文件，就会报错

...
error: ModuleNotFoundError: No module named 'omvll_config'
make: *** [Makefile:31: strings.bin] Error 1

可以通过环境变量来指明omvll_config.py的路径和文件名，像这样:

export OMVLL_CONFIG=~/project/obfu/config_test.py

这样O-MVLL就会去寻找~/project/obfu/config_test.py作为混淆的配置文件

配置文件中必须要实现一个名为omvll_get_config的函数，和一个继承自omvll.ObfuscationConfig的类，omvll_get_config的返回值必须是这个类才行。

这个函数由pass调用，从而访问用户定义的混淆方案，因为混淆的配置必须是唯一的，因此作者强烈建议使用@functools来包装这个函数：

import omvll
from functools import lru_cache

class MyConfig(omvll.ObfuscationConfig):
    def __init__(self):
        super().__init__()

@lru_cache(maxsize=1)
def omvll_get_config() -> omvll.ObfuscationConfig:
    """
    Return an instance of `ObfuscationConfig` which
    aims at describing the obfuscation scheme
    """
    return MyConfig()

现在，我们可以在MyConfig中配置我们的混淆方案了。例如调用字符串混淆时，就需要重写obfuscate_string(self, module: omvll.Module, func: omvll.Function, string: bytes)这个函数。

该函数的输入为继承自llvm:Module的omvll:Modul，继承自llvm:Function的omvll:Fcuntion以及传入的字符串，它会遍历每个模块当中每个函数中调用的字符串。当函数的返回值为true或者某个字符串时，启动字符串混淆

class MyConfig(omvll.ObfuscationConfig):
    def __init__(self):
        super().__init__()

    def obfuscate_string(self, module: omvll.Module, func: omvll.Function,
                               string: bytes):

        if func.name == "hello":
            return True

        if b"debug.cpp" in string:
            return "<REMOVED>"

        return False

上述配置，就会将函数名为hello的函数中的字符串进行加密，并且将程序中包含debug.cpp的字符串替换为<REMOVED>