1. OLLVM与Android Native代码混淆基础第一次接触OLLVM是在2018年逆向分析一个金融类APP时发现它的so库反编译后出现了大量难以理解的switch-case结构这就是典型的控制流平坦化特征。OLLVM作为LLVM的官方分支项目通过编译器级别的代码转换实现了三种核心混淆技术控制流平坦化把if/for/while等结构化控制流改写成switch-case的跳转结构指令替换将简单算术运算替换为等效但更复杂的表达式组合虚假控制流插入永远不会执行的条件分支和死代码在Android安全领域Native代码JNI往往是核心算法的藏身之处。我见过不少开发者直接把AES密钥或签名算法写在so里这种裸奔的代码用IDA Pro半小时就能逆向出来。而经过OLLVM混淆的代码逆向工程师可能需要花费数天甚至数周时间分析。2. Ubuntu 20.04环境准备去年给团队搭建OLLVM环境时发现gcc版本是个大坑。Ubuntu 20.04默认的gcc-9会导致编译失败必须降级到gcc-8。这里分享我的标准化配置流程# 安装指定版本工具链 sudo apt-get install gcc-8 g-8 cmake -y # 配置版本优先级 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8 8 sudo update-alternatives --install /usr/bin/g g /usr/bin/g-8 8 # 切换默认版本 sudo update-alternatives --config gcc sudo update-alternatives --config g建议在虚拟机中操作前先做快照我曾经因为磁盘空间不足导致编译中断。可以通过以下命令检查df -h # 确保至少有20GB可用空间 sudo apt autoremove --purge snapd # 清理冗余软件包3. 编译OLLVM 4.0从GitHub拉取源码时需要特别注意分支git clone -b llvm-4.0 https://github.com/obfuscator-llvm/obfuscator.git编译前必须修改一个关键文件找到ollvm/include/llvm/ExecutionEngine/Orc/OrcRemoteTargetClient.h将690行的char改为uint8_t编译参数建议使用Release模式以优化性能mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease -DLLVM_INCLUDE_TESTSOFF ../obfuscator/ make -j$(nproc) # 使用所有CPU核心加速编译 sudo make install实测在4核8G的虚拟机中完整编译需要约90分钟。如果中途失败可以尝试先make clean再减少并行任务数。4. 集成Android NDK工具链要让OLLVM处理Android Native代码需要与NDK协同工作。以NDK r21d为例在Android/sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin目录下备份原版clang将编译好的ollvm-clang重命名为aarch64-linux-android21-clang修改CMakeLists.txt添加混淆参数set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -mllvm -fla -mllvm -bcf -mllvm -sub) set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -mllvm -fla -mllvm -bcf -mllvm -sub)最近在给某电商APP做安全加固时发现NDK版本兼容性问题。解决方案是在gradle中指定ABI过滤android { defaultConfig { ndk { abiFilters armeabi-v7a, arm64-v8a } } }5. 实战混淆JNI代码测试用例是最能说明问题的来看这个典型的JNI函数// native-lib.cpp extern C JNIEXPORT jstring JNICALL Java_com_example_app_MainActivity_getEncryptKey( JNIEnv* env, jobject thiz) { char key[32] {0x12,0x34,0x56,...}; // 原始密钥 return env-NewStringUTF(key); }使用OLLVM混淆后的反编译效果对比混淆前混淆后直接显示密钥数组密钥被拆分成多个片段线性控制流嵌套了5层switch-case无冗余代码插入大量数学运算垃圾代码构建命令示例$NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang \ -target aarch64-linux-android21 \ -mllvm -fla -mllvm -bcf_loop3 \ -shared -o libnative.so native-lib.cpp6. 高级混淆策略组合单一混淆方式容易被针对性破解推荐组合使用# 控制流平坦化基本块分割 clang -mllvm -fla -mllvm -split_num3 test.cpp -o test # 虚假控制流指令替换 clang -mllvm -bcf -mllvm -sub_loop2 test.cpp -o test # 全量混淆编译时间较长 clang -mllvm -fla -mllvm -bcf -mllvm -sub test.cpp -o test在金融类APP中我通常会根据代码敏感程度分级处理核心加密算法三级混淆字符串加密业务逻辑代码控制流平坦化虚假控制流工具类函数仅指令替换7. 常见问题排查**Q1编译时报错undefined reference tostd::cout?** A这是C标准库链接问题确保添加-lstdc参数Q2混淆后的so文件体积暴涨A正常现象可以通过-Oz优化级别压缩实测能减少30%体积Q3混淆导致性能下降严重A避免对性能敏感函数如视频解码做深度混淆可用__attribute__((no_obfuscate))标记去年给一个IoT设备做加固时发现混淆后的代码在ARMv7设备上崩溃。最终定位到是虚假控制流过度混淆导致寄存器溢出解决方案是调整概率参数-mllvm -bcf_prob20 # 将默认30%降低到20%8. 生产环境部署建议在企业级应用中建议建立自动化混淆流水线CI服务器集成OLLVM编译容器通过Jenkins参数控制混淆强度对输出so文件进行自动化测试版本化管理不同的混淆配置安全团队应该维护一个混淆字典记录每个版本使用的混淆参数这在排查线上崩溃时非常有用。例如版本号混淆参数备注1.0.0-fla -bcf_prob30基础防护1.1.0-fla -sub -bcf_loop2增强算法模块防护记得每次发布前用readelf检查动态符号表确保没有意外暴露敏感函数符号。
OLLVM实战：在Ubuntu 20.04上构建Android Native代码混淆工具链
1. OLLVM与Android Native代码混淆基础第一次接触OLLVM是在2018年逆向分析一个金融类APP时发现它的so库反编译后出现了大量难以理解的switch-case结构这就是典型的控制流平坦化特征。OLLVM作为LLVM的官方分支项目通过编译器级别的代码转换实现了三种核心混淆技术控制流平坦化把if/for/while等结构化控制流改写成switch-case的跳转结构指令替换将简单算术运算替换为等效但更复杂的表达式组合虚假控制流插入永远不会执行的条件分支和死代码在Android安全领域Native代码JNI往往是核心算法的藏身之处。我见过不少开发者直接把AES密钥或签名算法写在so里这种裸奔的代码用IDA Pro半小时就能逆向出来。而经过OLLVM混淆的代码逆向工程师可能需要花费数天甚至数周时间分析。2. Ubuntu 20.04环境准备去年给团队搭建OLLVM环境时发现gcc版本是个大坑。Ubuntu 20.04默认的gcc-9会导致编译失败必须降级到gcc-8。这里分享我的标准化配置流程# 安装指定版本工具链 sudo apt-get install gcc-8 g-8 cmake -y # 配置版本优先级 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8 8 sudo update-alternatives --install /usr/bin/g g /usr/bin/g-8 8 # 切换默认版本 sudo update-alternatives --config gcc sudo update-alternatives --config g建议在虚拟机中操作前先做快照我曾经因为磁盘空间不足导致编译中断。可以通过以下命令检查df -h # 确保至少有20GB可用空间 sudo apt autoremove --purge snapd # 清理冗余软件包3. 编译OLLVM 4.0从GitHub拉取源码时需要特别注意分支git clone -b llvm-4.0 https://github.com/obfuscator-llvm/obfuscator.git编译前必须修改一个关键文件找到ollvm/include/llvm/ExecutionEngine/Orc/OrcRemoteTargetClient.h将690行的char改为uint8_t编译参数建议使用Release模式以优化性能mkdir build cd build cmake -DCMAKE_BUILD_TYPERelease -DLLVM_INCLUDE_TESTSOFF ../obfuscator/ make -j$(nproc) # 使用所有CPU核心加速编译 sudo make install实测在4核8G的虚拟机中完整编译需要约90分钟。如果中途失败可以尝试先make clean再减少并行任务数。4. 集成Android NDK工具链要让OLLVM处理Android Native代码需要与NDK协同工作。以NDK r21d为例在Android/sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/bin目录下备份原版clang将编译好的ollvm-clang重命名为aarch64-linux-android21-clang修改CMakeLists.txt添加混淆参数set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} -mllvm -fla -mllvm -bcf -mllvm -sub) set(CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS} -mllvm -fla -mllvm -bcf -mllvm -sub)最近在给某电商APP做安全加固时发现NDK版本兼容性问题。解决方案是在gradle中指定ABI过滤android { defaultConfig { ndk { abiFilters armeabi-v7a, arm64-v8a } } }5. 实战混淆JNI代码测试用例是最能说明问题的来看这个典型的JNI函数// native-lib.cpp extern C JNIEXPORT jstring JNICALL Java_com_example_app_MainActivity_getEncryptKey( JNIEnv* env, jobject thiz) { char key[32] {0x12,0x34,0x56,...}; // 原始密钥 return env-NewStringUTF(key); }使用OLLVM混淆后的反编译效果对比混淆前混淆后直接显示密钥数组密钥被拆分成多个片段线性控制流嵌套了5层switch-case无冗余代码插入大量数学运算垃圾代码构建命令示例$NDK_HOME/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android21-clang \ -target aarch64-linux-android21 \ -mllvm -fla -mllvm -bcf_loop3 \ -shared -o libnative.so native-lib.cpp6. 高级混淆策略组合单一混淆方式容易被针对性破解推荐组合使用# 控制流平坦化基本块分割 clang -mllvm -fla -mllvm -split_num3 test.cpp -o test # 虚假控制流指令替换 clang -mllvm -bcf -mllvm -sub_loop2 test.cpp -o test # 全量混淆编译时间较长 clang -mllvm -fla -mllvm -bcf -mllvm -sub test.cpp -o test在金融类APP中我通常会根据代码敏感程度分级处理核心加密算法三级混淆字符串加密业务逻辑代码控制流平坦化虚假控制流工具类函数仅指令替换7. 常见问题排查**Q1编译时报错undefined reference tostd::cout?** A这是C标准库链接问题确保添加-lstdc参数Q2混淆后的so文件体积暴涨A正常现象可以通过-Oz优化级别压缩实测能减少30%体积Q3混淆导致性能下降严重A避免对性能敏感函数如视频解码做深度混淆可用__attribute__((no_obfuscate))标记去年给一个IoT设备做加固时发现混淆后的代码在ARMv7设备上崩溃。最终定位到是虚假控制流过度混淆导致寄存器溢出解决方案是调整概率参数-mllvm -bcf_prob20 # 将默认30%降低到20%8. 生产环境部署建议在企业级应用中建议建立自动化混淆流水线CI服务器集成OLLVM编译容器通过Jenkins参数控制混淆强度对输出so文件进行自动化测试版本化管理不同的混淆配置安全团队应该维护一个混淆字典记录每个版本使用的混淆参数这在排查线上崩溃时非常有用。例如版本号混淆参数备注1.0.0-fla -bcf_prob30基础防护1.1.0-fla -sub -bcf_loop2增强算法模块防护记得每次发布前用readelf检查动态符号表确保没有意外暴露敏感函数符号。
