Frida 反检测三件套对比：Florida vs rusda vs fridare

本文为对比整理，基于三个项目的官方仓库与 README 编写

• Florida：https://github.com/Ylarod/Florida
• rusda：https://github.com/taisuii/rusda
• fridare：https://github.com/suifei/fridare

三者主题一致——都是让 Frida 绕过反检测，但实现路线和定位差别很大。本文对比它们的技术路线、适用场景，并给出选型建议。数据截至 2026-08。

为什么需要「反检测 frida」

Frida 好用，但也极容易被抓：它在进程里留了一大堆固定指纹，目标 App 一查一个准。常见检测点：

• 进程名 / 文件名：frida-server、frida-agent、frida-gadget
• 线程名（/proc/<pid>/task/*/comm）：gum-js-loop、gmain、gdbus
• 内存特征字符串（.rodata）：FridaScriptEngine、GumScript、GDBusProxy、GLib-GIO
• RPC 标识：frida:rpc
• memfd / maps：memfd:frida-agent
• 入口符号：frida_agent_main
• 默认端口：27042 / 27052（运行时行为，不是字符串）

所谓「反检测 frida」，就是把这些指纹尽量抹掉或改掉，同时不破坏 Frida 的功能和协议兼容。下面这三个项目，是目前中文圈子里最常被提到的方案。

一分钟速览

项目	一句话定位
Florida	跟随 Frida 上游、自动打补丁编译出反检测 frida-server，只做 Android，极简省心
rusda	源码 + 构建 + 二进制三层深度魔改的 Frida，原理讲得最透，直接给编好的 Release
fridare	重打包 / 魔改工具链（不是 Frida 本身），带 GUI，静态补丁 + Docker 重编双路线，跨平台

基础数据对比

	Florida	rusda	fridare
Star	★2160（最高）	★604	★877
语言	自动化脚本 / CI	Python（补丁、工具）	Go（工具本体）
License	GPL-3.0	无 ⚠️	MIT
建库	2023-07（最早）	2024-12	2024-06
平台	仅 Android	仅 Android	iOS / Android / Win / Linux
你拿到的是	编好的 server	编好的 server/inject/gadget	工具（拿去改自己的 Frida）

⚠️ rusda 无 License：默认保留所有权利，商用 / 分发前请与作者确认授权。

最关键的区别：它们「是什么」

三者不在同一层，这点先分清：

• Florida 和 rusda 给你「成品」——它们是魔改后的 frida-server，直接下 Release 用，把 frida-server 换成它们的即可。
• fridare 给你「工具」——它本身不是 Frida，而是一个去改 Frida 的自动化工具（Go 写的 CLI + GUI）。你把官方 Frida 喂给它，它帮你改名、改端口、改协议标识，甚至起 Docker 重新编译。

技术路线深挖

Florida —— 最简、最「上游同步」

核心价值是紧跟 Frida 上游版本自动 patch + CI 编译：Frida 一出新版，它很快就有对应的反检测版本。

• 补丁思路承袭 hluwa strong-frida、AntiFrida 那批前辈（README 里逐一致谢）。
• 优点：省心、更新快、Star 最高、社区最认。
• 取舍：原理它自己不展开讲，想深入得去翻它引用的参考项目；README 明确写了 “Don’t fork this repository”（靠 CI 出包，fork 没意义）。

rusda —— 原理最透、魔改分三层

三个里 README 写得最详细的，把反检测拆成三层，每层解决源码够不够得着的问题：

① 源码层（编译前打补丁）

直接改 frida-core / frida-gum 的 Vala / C 源码：

• 产物名 frida-* → rusda-*、资源目录 lib/frida/ → lib/rusda/
• frida:rpc 改成运行时拼接（不在二进制里留明文）
• 各种 frida-* 线程名改成运行时 XOR 解码
• frida_agent_main → main、进程名 g_set_prgname("frida") → "russell"
• memfd 名 → jit-cache（避免 maps 里露出 memfd:frida-agent）

② 构建层

改 meson 输出名、磁盘路径、符号前缀，保证改名后整条链一致、能正常链接；串行编四个架构（并行会把 SDK 搞坏）。

③ 二进制层（链接后 topatch）

有些字符串源码层够不着——要么在静态链进来的 GLib/GObject 里（GLib-GIO、GDBusProxy、gmain），要么是 Vala 自动生成的 GObject 类型名（FridaScriptEngine、GumScript）。这些只能等链接完直接对二进制动手，用 LIEF 处理：

• .rodata 里的类型名等长反转：FridaScriptEngine → enignEtpircSadirF、GumScript → tpircSmuG
• 线程名等长替换：gum-js-loop → russellloop、gmain → rmain

为什么是「等长反转」而不是删掉：ELF 里这些字符串的偏移、重定位都是定死的，只要长度不变就不动布局，二进制照常能跑；反转既等长，又让 strings 和内存扫描匹配不到原串。这是 rusda README 里讲得很漂亮的一点。

rusda 还带自检脚本 verify-patch.py（检查 7 个关键特征串是否清零）和真机测试报告（Pixel 6 Pro 过 Sentry 检测器），并诚实标注了边界：默认端口需自己换、深层 Frida* 类型名仍有残留、重度加固不一定够。适合想学原理或想二次开发的人。

fridare —— 工具化、跨平台、带 GUI

它是三者里唯一的「工具」而非「成品」，特点是覆盖面广：

• 双技术路线：A 静态 hex 补丁（秒级，改名改端口）/ B Docker 源码重编译（小时级，深度隐藏）。
• 唯一支持 iOS（DEB 重打包）和 Windows（MinGW server）。
• 有 Fyne 写的跨平台 GUI，还内置了 AI Agent 辅助。
• 深度魔改要点：魔改名固定 5 位小写字母；server 与 host client wheel 必须成对（同一 magic）；对象路径含 /re/{magic}/，避免只改 re.frida. 导致协议不匹配。
• README 里反复强调「不是免杀」——作者很克制，明确它只降低命中率。

适合要覆盖多平台、喜欢 GUI、要改 iOS 的场景。

选型建议

你的需求	推荐
只搞 Android、想省心跟新版	Florida（Star 最高、更新最快、社区最认）
想理解反检测原理 / 想深度定制	rusda（三层原理最清楚，有自检和真机验证）
要 iOS 或 Windows、要 GUI、要工具化流程	fridare（跨平台最全，MIT 最宽松）

三者还能配合：用 Florida / rusda 拿现成反检测 server，用 fridare 做跨平台 / iOS 的重打包和端口改造。

共同的坑（三者都逃不掉）

1. 默认端口 27042 / 27052 是运行时行为、不是字符串，魔改改不掉，得启动时用 -l 指定非默认端口：

   # 起服务时指定一个非默认端口（只监听本地）
   adb shell su -c '/data/local/tmp/rusda-server -l 127.0.0.1:8765'
   # 客户端走 USB，不依赖监听端口
   frida -U -f 包名

2. 都不是「免杀」——对付一般检测够用，重度加固 App 的深度内存扫描 / CRC 校验不一定过（fridare 直接把「不是免杀」写进每个版本说明）。

3. SELinux Enforcing 下 agent 通信可能被挡，需 setenforce 0——这是官方 Frida 的通病，非魔改本身的问题。

参考

• Florida：https://github.com/Ylarod/Florida
• rusda：https://github.com/taisuii/rusda
• fridare：https://github.com/suifei/fridare
• 相关阅读：Frida 脚本一键持久化（转载）

---

本文仅作技术学习与安全研究记录。请在合法合规、获得授权的前提下使用相关技术。