Frida魔改反检测初探
字数 4069
更新时间 2026-03-24 15:18:35

Frida源码编译与魔改反检测入门指南

概述

本文档旨在系统性地指导如何从源码编译Frida，并基于开源魔改项目进行反检测修改，以绕过移动应用对Frida的动态检测机制。整个流程涵盖环境搭建、源码编译、补丁应用、源码级修改及编译优化。

一、Frida源码编译

1. 环境准备

推荐在Ubuntu虚拟机中进行，需安装以下必备组件：

  • Git：用于克隆Frida源码仓库。

    apt install git

  • Android NDK：编译Android版Frida Server的核心工具链。建议使用r25c版本。

    # 下载 NDK r25c
cd $HOME
wget https://dl.google.com/android/repository/android-ndk-r25c-linux.zip
unzip android-ndk-r25c-linux.zip
# 设置环境变量
export ANDROID_NDK_ROOT=$HOME/android-ndk-r25c
echo 'export ANDROID_NDK_ROOT=$HOME/android-ndk-r25c' >> ~/.bashrc

  • Python 3 及 lief库：用于后续的二进制patch脚本。Ubuntu系统通常内置Python3，但需安装lief库。

    pip3 install lief --break-system-packages

    注意：在Ubuntu 20.04+系统中，--break-system-packages参数用于绕过系统对pip修改全局Python包的安全限制。

  • Node.js 和 npm：

    sudo apt-get install nodejs npm

  • 基础编译工具集：

    sudo apt-get install build-essential git lib32stdc++-9-dev libc6-dev-i386 nodejs npm

  • 网络代理：由于需要下载大量依赖，建议在Linux虚拟机中配置全局代理，以加速下载过程。

2. 下载与编译Frida源码

  1. 克隆源码：需要克隆包含所有子模块的完整仓库，指定版本为16.2.1。

    git clone --recurse-submodules -b 16.2.1 https://github.com/frida/frida.git

  2. 构建SDK：Frida没有为Android ARM提供预编译的SDK，必须先自行构建。-j5用于启用多核并行编译以提速，ARCH=arm64指定为安卓ARM64架构编译，可节省时间。

    make -f Makefile.sdk.mk ARCH=arm64 -j5

  3. 编译核心：编译适用于Android ARM64的Frida核心组件。

    make core-android-arm64 FRIDA_HOST=android-arm64
    • 时间评估：首次完整编译通常需要1小时以上，请耐心等待。
    • 编译产物：成功编译后，安卓版的frida-server可执行文件将位于build/ffrida-android-arm64/bin/目录下。

  4. 常见错误处理：

    • zlib链接错误：如果编译报错提示uncompress, inflateInit_, crc32, deflate等zlib库函数未定义，说明NDK或SDK编译不完整。解决方法是清理编译缓存后重新执行SDK构建命令： 
      make clean
make -f Makefile.sdk.mk ARCH=arm64 -j5
    • 网络问题：确保虚拟机已配置有效的全局代理。

二、Frida魔改反检测

1. 背景知识

  • Patch文件：本质是一份“代码修改说明书”，以.patch格式记录了特定文件的哪些行被增、删、改。常用命令有：

    • git diff > xxx.patch: 生成补丁文件。
    • git apply xxx.patch: 应用补丁（不生成git提交记录）。
    • git am xxx.patch: 应用补丁（同时生成提交记录）。

  • 编译加速：在反复测试魔改时，清理构建缓存可加快后续编译速度。使用make clean命令会保留build目录中已编译好的SDK和工具链，只清理其他中间文件，从而将重新编译时间从超过1小时缩短到约10分钟。

2. 魔改项目与反检测点分析

本指南以开源魔改项目 https://github.com/taisuii/rusda 为例，分析其关键反检测修改。

2.1 frida-gum 文件夹修改

frida-gum是Frida的底层注入和Hook库。

  • gum.c.patch:

    • 修改：将 g_set_prgname ("frida"); 改为 g_set_prgname ("russell");
    • 目的：g_set_prgname()用于设置程序名。此修改旨在绕过基于字符串"frida"的静态特征检测。

  • mapper.c.patch:

    • 修改：将查找的入口点符号从"frida_agent_main"改为"main"。
    • 目的：避免目标进程通过扫描动态库导出符号表，发现包含"frida"的特征。

2.2 frida-core 文件夹修改

frida-core是Frida的核心库，负责进程管理、脚本加载和通信。

  • agent-container.vala.patch:

    • 修改：将加载代理时查找的符号从"frida_agent_main"改为"main"。
    • 目的：使入口函数名看起来像普通程序入口，降低被特征检测的概率。

  • frida-helper-backend.vala.patch:

    • 修改：将memfd_create系统调用创建匿名内存文件时使用的名称固定为"jit-cache"，而非原本可能包含"frida"的名称。
    • 目的："jit-cache"是一个通用的、类似JS引擎JIT缓存的无害名称，用于规避对特定memfd文件名的检测。

  • server.vala.patch:

    • 修改：将Frida Server在运行时会创建的临时IPC通信目录名从"re.frida.server"改为"re.rusda.server"。
    • 目的：绕过基于固定字符串匹配的文件系统路径检测。

  • rpc.vala.patch:

    • 修改：这是关键且复杂的修改，旨在隐藏RPC通信中的特征字符串"frida:rpc"。
      1. 增加一个getRpcStr函数，该函数对编码后的字符串"Wm5KcFpHRTZjbkJq"进行双重Base64解码，最终得到"frida:rpc"。
      2. 将所有直接引用"frida:rpc"字符串的地方，替换为调用getRpcStr(false)（用于变量比较）或getRpcStr(true)（用于JSON字符串匹配）。
    • 目的：使"frida:rpc"字符串在二进制文件和内存中不以明文形式存在，增加内存扫描的难度。

  • topatch.py (关键脚本):
    此Python脚本在编译过程中被调用，直接对编译生成的二进制文件（.so）进行patch，实现更深层次的特征隐藏。它主要修改三个方面：

    1. 符号表检测：遍历ELF符号表，将包含frida/FRIDA的符号名替换为随机名称（如rusda），并将frida_agent_main重命名为main。
    2. 字符串特征检测：在二进制文件的.rodata（只读数据）段中，搜索硬编码的特征字符串（如"FridaScriptEngine", "GLib-GIO", "GDBusProxy", "GumScript"），并将这些字符串反转后写回原位置（例如"Frida"变成"adirF"）。
    3. 线程名检测：使用sed命令直接修改二进制文件中的硬编码线程名，例如将gum-js-loop、gmain、gdbus分别替换为随机名称。

    注意：topatch.py脚本并非在make编译之后手动运行，而是由embed-agent.sh.patch在编译流程中自动调用。使用时需在embed-agent.sh.patch中将其相对路径修改为Ubuntu系统中的实际绝对路径，例如/home/bbc/Desktop/frida/frida/topatch.py。

3. 魔改项目的自定义修改

  1. 可直接在Patch和脚本中修改的内容：

    • 对魔改项目提供的.patch文件中的字符串（如将main改为bmain）进行修改，然后应用这些patch。
    • 对topatch.py脚本中的字符串和随机名称进行修改。

  2. 需要直接修改源码的内容：

    • 当需要修改的函数核心逻辑（如参数、返回值、新增逻辑）与现有patch文件记录的代码行不匹配时，直接在源码上修改，而不是修改patch文件。否则应用patch时会因“行号/代码片段”对不上而失败（报“hunk FAILED”）。
    • 示例：rpc.vala.patch中使用的双重Base64编码已成为公开特征，可以改为更复杂的自定义混淆算法。这需要直接编辑frida-core/lib/rpc.vala源码文件。
    • 编辑工具建议：
      • （推荐） 在Windows上使用VSCode + Remote SSH插件，连接Ubuntu虚拟机，直接编辑虚拟机中的源码文件，利用VSCode的Vala语言插件避免语法错误。
      • 或在Linux本地安装VSCode并配置Vala插件。

4. 魔改编译流程与验证

  1. Patch检查：在应用patch前，先进行检查，避免因环境或版本问题导致应用失败。

    • 单文件检查：git apply --check <patch_file>
    • 可使用Python脚本批量检查目录下所有patch文件。

  2. 应用Patch：检查无误后，应用所有patch。可以使用Shell脚本批量应用，并在出错时停止。

    for p in *.patch; do
    echo "Applying patch: $p"
    git apply "$p"
    if [ $? -ne 0 ]; then
        echo "Failed to apply $p"
        break
    fi
done

  3. 编译与验证：

    • 执行编译命令，并过滤输出查看patch脚本是否被执行： 
      make core-android-arm64 | grep Patch
    • 成功标志：在编译输出中，能看到topatch.py脚本对各个.so文件进行处理的日志，例如： 
      [*] Patch frida-agent: .../frida-agent-64.so
[*] Patch `frida` to `custom`
[*] Patching section name=.rodata offset=0x1c4a1f orig:FridaScriptEngine new:enignEtpircSadirF
...
[*] Patch `gum-js-loop` to `customloop`
[*] Patch Finish
    • 如果编译失败，需先清理缓存再重新编译： 
      make clean
make core-android-arm64 | grep Patch
    • 如果编译输出中没有Patch相关的日志，说明topatch.py未被成功调用，需检查embed-agent.sh.patch中的脚本路径是否正确。

三、总结与后续方向

通过上述步骤，可以完成Frida源码的编译和基础反检测魔改。但仅靠修改已知开源项目的检测点，可能不足以应对所有检测手段。

后续可深入研究的方向包括：

  1. 自动化检测点识别：利用AI辅助工具（如IDA-MCP插件）对目标APP进行反编译，自动识别其用于检测Frida的代码逻辑（如特征字符串扫描、端口检测、进程枚举等），并针对性地生成魔改方案。
  2. 智能化魔改与快速迭代：魔改Frida源码需要兼顾编程语法、运行时逻辑和反检测效果，细微改动可能导致编译失败或功能异常。且每次测试都需要约10分钟的编译周期，迭代效率低。未来可探索让AI学习Frida代码结构，在保证编译通过和功能正常的前提下，自动生成更隐蔽、更多样化的混淆代码，并建立快速验证机制。
相似文章
相似文章
 全屏