hermes从刷机到Frida魔改一气呵成——这不是科幻，是真事。更可怕的是——它还在自动进化。

Hermes 是一个 CLI AI Agent，能自主执行复杂的工程任务。但它的真正可怕之处不在于「自动化」，而在于自动进化——每一次执行都在学习，每一次错误都在积累经验，每一次成功都在固化最优路径。与传统脚本按预设步骤机械执行不同，Hermes 展现出的是：

• 理解上下文：理解你的自然语言指令，自动推断操作意图和执行路径
• 自主决策：在执行过程中根据环境变化动态调整策略，选择最优方案
• 自我纠错：遇到错误时自己分析原因、寻找解决方案、重试直到成功
• 自动进化：错误不犯第二次，路径自动优化，知识跨任务迁移——越用越聪明，永不停歇

本文将以 Android 逆向环境搭建全流程为例，验证 Hermes 在真实工程场景中从刷机、Root 到 Frida 编译魔改的完整自动化能力与自动进化现象。

Hermes 安装与快速上手

别被它的能力吓到——让一个「会自己进化的 AI」跑起来，其实简单得离谱。

环境要求：

• Python 3.10+
• Linux / macOS / Windows（WSL2 体验最佳,这里使用Ubuntu24.0.4）
• 网络连接（用于下载依赖和模型推理）

安装步骤：

git clone 5b7K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6S2L8Y4c8Z5M7X3!0H3K9h3y4K6i4K6u0r3K9r3g2J5L8h3g2K6i4K6u0V1j5h3N6W2L8Y4c8Q4x3X3g2Y4K9i4b7`.
cd hermes-agent && pip install -e .

首次配置：

# 初始化工作环境
hermes init

# 配置 API Key（支持 OpenAI / Anthropic / DeepSeek 等多种后端）
hermes config set api_key your_api_key_here
hermes config set model deepseek-v4-pro

开始使用：

安装完成后，在终端中直接输入 hermes 即可进入交互模式。你只需要用自然语言描述你想做的事：

hermes "帮我下载并编译 frida-core Android arm64 版本"

然后你就可以眼睁睁看着它：自己理解需求 → 自己规划步骤 → 自己拉源码 → 自己配环境 → 自己下载 NDK → 自己编译 → 自己验证结果。你唯一需要做的，是坐在旁边喝咖啡。

进阶用法：

# 直接传入任务文件
hermes --task ./reverse_engineering_workflow.md

# 在代码项目中自动读入上下文
cd /path/to/your/project && hermes

安装完成后，Hermes 会持续学习你的工作环境和偏好——用的越多，它越懂你。

好了，装完了。现在你肯定想问：这东西到底能帮我省多少时间？能力边界在哪？别急——先看数据，再看现象。以下数字全部来自真实操作记录，不吹不黑。

0x01 先看数据再看现象：hermes自动进化到底有多强

在Android安全研究领域，有一个令人崩溃的现实：搭建一个完整的逆向调试环境，往往比逆向分析本身更耗时。但Hermes不仅仅是在自动化——它是在自动进化。每一次执行都不是简单的重复，而是对上一次的优化和升华。它将繁琐的流程封装成标准化、可复现的进化流水线，让安全研究人员专注于真正的逆向分析工作——而这条流水线本身，还在越变越快、越变越聪明。

效率对比——数据不说谎

六大自动进化现象——看完你会重新认识AI

• 上下文理解：你说"连手机"，它自己推断要检测状态→查型号→判解锁→扫描资源，一气呵成
• 自主决策：面对一堆固件自己匹配型号；编译Frida自己判断NDK版本；SELinux拦了能自己提方案
• 错误自愈：编译报错不甩锅，自己读日志→分析原因→装依赖→重试。比很多新人靠谱
• 知识迁移：一台设备上学到的经验，自动复用到新设备、新版本。教一次永不忘
• 流程优化：第一次10步，第二次优化到6步。越用越聪明，永不停歇
• 攻防理解：魔改Frida不只执行补丁，它懂了为什么要魔改——这不是执行任务，是在参与安全对抗

智能流水线架构

┌─────────┐      ┌─────────┐      ┌─────────┐
│  刷机阶段 │ ──→ │ Root阶段 │ ──→ │Frida阶段 │
└─────────┘      └─────────┘      └─────────┘
    ↓                 ↓                 ↓
 验收通过          验收通过          验收通过

数据看完了，流水线画好了。但说一千道一万，不如亲眼看着它干活。以下实战内容全部由 Hermes 自主驱动完成——无人工编写脚本，无预设流程，每一步都是它自己想、自己做的。

0x02 实战实录：眼睁睁看着hermes自己搞完了刷机和Root

2.1 一键刷机与Root——它比你想的聪明

我们对hermes只说了一句话：

连接的手机设备，安装最新版本的系统，不保留用户数据，并使用Kitsune Mask对设备进行root，所需文件我已放在D:\Downloads\gx\root

就这一句。没有详细步骤，没有参数说明，没有异常处理方案。就像跟一个同事说话一样。

然后hermes开始了它的表演——

hermes执行流程：

** 智能涌现时刻一：自主识别环境**

hermes没有上来就干，而是先**"观察"了一圈**：

• 自动检测设备连接状态
• 识别设备型号和系统版本
• 判断bootloader解锁状态
• 扫描可用资源文件

你品品这个行为——这不就是人类工程师拿到设备后做的第一件事吗？

这里试过让AI自动下载系统安装包和狐妖面具安装包，可以找到下载地址，但由于网页的反爬虫机制无法下载rom包，狐妖面具安装包可以下载但网速较慢，直接自己下载好放一个目录给他吧步骤1：自动检测设备信息

adb devices                                    # 检测设备连接
adb shell getprop ro.product.model            # 输出: laurus
adb shell getprop ro.build.fingerprint        # 输出: ...
adb shell getprop ro.boot.flash.locked        # 输出: 0 (已解锁)

hermes自己判断出：

• 设备型号：Xiaomi CC9e (laurus)
• Bootloader 状态：已解锁
• 当前系统：未知

** 智能涌现时刻二：智能匹配资源**

hermes不是把文件全试一遍，而是根据设备型号智能匹配：

• 从多个文件中精准筛选出匹配laurus的固件包
• 自动验证固件完整性
• 规划最优刷机路径

步骤2：自动匹配固件包

hermes自动从提供的目录找到固件包：

• 固件位置：D:\Downloads\gx\root\laurus_images_V12.5.5.0.QFMCNXM_20211122.0000.00_10.0_cn\
• 版本：MIUI V12.5.5.0.QFMCNXM (Android 10)

步骤3：自动执行刷机

hermes自动执行刷机脚本并等待设备启动。

步骤4：自动验证刷机成功

adb wait-for-device
adb shell getprop ro.build.fingerprint
# 输出: Xiaomi/laurus/laurus:10/QKQ1.200830.002/V12.5.5.0.QFMCNXM:user/release-keys

手机正常开机，成功刷机，继续下一步操作

⚠️ 需要动手的地方：

由于Android安全策略限制，hermes无法通过命令打开adb限制，这里要手动打开：

2.2 自动Root过程——行云流水

步骤1：自动下载并安装 Kitsune Mask

hermes自动从 GitHub 下载最新版本并安装。

⚠️ 需要手动操作：由于 MIUI 安全策略限制，需要手动同意安装。

步骤2：自动提取并推送 boot.img

hermes自动从固件包提取 boot.img 并推送到设备。

⚠️ 需要手动操作：在设备上操作 Kitsune Mask 应用修补 boot.img。

步骤3：自动拉取并刷入修补镜像

修补完成后，告诉hermes，hermes继续自动执行：

步骤4：自动验证 Root 成功

adb shell su -c id
# 输出: uid=0(root) gid=0(root) groups=0(root) context=u:r:su:s0

验证成功标志：

• ✅ uid=0(root) 表示已获得 Root 权限

• ✅ Kitsune Mask 应用显示"已安装"

• ✅ 可以使用 su 命令提权

** 自动进化观察**：注意 hermes 在整个刷机→Root 流程中的行为模式变化——

• 信息复用：第一次识别设备时查询了3条 adb 命令获取设备信息；后续操作中直接复用已获取的型号、解锁状态等参数，不再重复查询
• 策略自适应：需要多次等待设备重启时，hermes 自动调整了等待超时策略——第一次保守等待60秒，后续根据实际启动耗时缩短到了更合理的等待时间
• 模板固化：刷机成功后的验证步骤（检查指纹、确认开机状态），被 hermes 自动固化为后续 Root 阶段的前置检查模板

这不是预设好的优化规则，而是 hermes 在执行过程中自己形成的效率策略——这就是自动进化。

2.3 hermes的智能应对——出问题怎么办？

** 智能涌现时刻三：错误自愈——遇到问题自己扛**

整个Root流程中，hermes展现出了最实用的智能涌现：遇到问题不甩锅。

注意：hermes不是万能的神，Android安全策略它确实绕不过去。但它清楚地告诉你卡在哪、为什么、怎么解决——而且自己在不断尝试替代方案。这种能力本身就已经很惊人了。

0x03 更炸裂的来了：自己编译Frida，自己魔改反检测

用户指令：

下载 frida-core，并进行编译

3.1 编译环境准备——hermes比你更清楚依赖关系

hermes自动检测编译依赖：

我这里装过了，没有的话他会自己下载编译。

hermes自动匹配Frida 版本与 NDK 对应关系：

3.2 编译 Frida 最新版——全程自动

hermes执行流程：

步骤1：克隆源码

步骤2：配置编译

步骤3：执行编译

步骤4：验证编译结果

这里发现编译错版本了，改一下

** 自动进化观察**：hermes 首次编译时错误地编译了桌面版 frida-core。当用户指出后，hermes 不仅修正了当前编译目标，更重要的是——它将「编译 Android 版本需要指定 ANDROID_NDK_ROOT 和目标架构（arm64）」这一知识固化了。后续所有编译操作（3.3、3.4、3.5）都自动带上了正确的 Android 交叉编译参数，没有再犯同样的错误。

这就是自动进化的核心：从错误中学习，一次纠正，永久生效。

3.3 编译 Android arm64 版本——架构适配无压力

指令：

hermes执行流程：

步骤1：下载 NDK

步骤2：配置 Android 编译

步骤3：编译

编译成功：

** 自动进化观察**：对比 3.2 的首次编译与 3.3 的 Android arm64 编译——

这不是两条不同指令的结果差异——这是 hermes 在第一次失败后，自动总结了正确的 Android 编译范式，并在后续任务中零失误应用。从「试错」到「一次命中」，这就是自动进化的力量。

3.4 编译指定版本（Frida 16.5.6）——版本随意切

指令：

换个版本试试

编译 16.5.6 版本 frida-server android arm64

hermes执行流程：

1. 下载 NDK r25

2. 克隆指定版本

3. 配置并编译

hermes贴心对比编译产物大小：

** 自动进化观察**：从 17.9.2 切换到 16.5.6 版本时，hermes 展现出了「知识迁移」的自动进化——

• NDK 版本自动匹配：没有重新询问 NDK 版本信息，直接根据 16.5.x → NDK r25 的对应规则下载了正确版本
• 源码版本精准定位：克隆时自动使用 --branch 16.5.6 指定 tag，而非盲目拉取 master 分支
• 编译参数直接继承：Android arm64 交叉编译参数从 3.3 的经验中直接复用，无需重新探索
• 主动对比分析：更关键的是——hermes 还自动对比了两个版本的编译产物大小差异（54M vs 51M），这在传统脚本中是绝不会出现的「多余」行为。但这正是智能涌现：它不只是在执行，它在理解、比较、记录。

3.5 Frida 魔改实践——攻防博弈的终极理解

为什么需要魔改

许多应用会检测 Frida 的特征，导致注入失败：

• 线程名称：pool-frida、gmain、gdbus
• 函数名称：frida_agent_main
• 动态库：frida-agent.so
• 模块名称：GLib-GIO、GDBusProxy
• 还有源码中RPC 协议标识符随机化、工作目录名随机化、hermes 文件名随机化等问题，这里不再细致展示

用户指令：

帮我重新编译魔改 frida 16.5.6

hermes执行流程：

** 智能涌现时刻四：理解攻防本质**

这是最让我震惊的时刻。hermes不仅执行魔改，还真正理解了攻防博弈的本质：

• 能自己识别出哪些特征会被检测
• 自动选择最优的魔改策略
• 源码级和二进制级双重魔改——这不是执行命令，这是安全思维

步骤1：应用补丁

# 1. 应用 frida-core 补丁
cd frida-core-16.5.6
cp /home/x1ny/Desktop/gx/root/frida-core.patch .
git apply frida-core.patch
# 此时 src/ 下会出现 anti-frida.py

# 2. 应用 frida-gum 补丁
cd subprojects/frida-gum
cp /home/x1ny/Desktop/gx/root/frida-gum.patch .
git apply frida-gum.patch

修改源码中RPC 协议标识符随机化、工作目录名随机化、hermes 文件名随机化等问题，这里不再细致展示

步骤2：重新编译

cd frida-core-16.5.6
ANDROID_NDK_ROOT=$HOME/android-ndk-r25c make -j$(nproc)

编译魔改后的源码，生成包含源码级魔改的二进制文件

步骤3：执行魔改

# 准备环境
mkdir -p ~/frida-magic-output
cd ~/frida-magic-output
cp frida-core-16.5.6/build/server/frida-server .
cp frida-core-16.5.6/src/anti-frida.py .

# 安装依赖
pip3 install --break-system-packages lief

# 执行魔改
python3 anti-frida.py frida-server

魔改输出：

[*] Patch frida-agent: frida-server
[*] Patch `frida` to `dpCWV`
[*] Patching section name=.rodata offset=0xa5e4f orig:GLib-GIO new:NRPOhglH
[*] Patching section name=.rodata offset=0x8bc03 orig:GDBusProxy new:PZBCyzbNsE
[*] Patch `gum-js-loop` to `uilBHNMyIWc`
[*] Patch `gmain` to `XdJWC`
[*] Patch `gdbus` to `NFzHZ`
[*] Patch Finish

魔改效果对照表：

这里仅展示二进制修改的特征，源码修改的特征不再展示

修改方式说明：

• 补丁修改：通过 git patch 修改源码，在编译前生效
• 二进制修改：通过 anti-frida.py 修改编译后的二进制文件

二进制修改特点：

• 直接修改 ELF 文件的字符串表
• 替换 .rodata 段中的特征字符串
• 修改符号表中的函数名
• 不需要重新编译，直接处理二进制文件

验证魔改效果：

# 检查文件类型
file frida-server
# 输出: ELF 64-bit LSB shared object, ARM aarch64

# 检查字符串特征（应该看不到原始特征）
strings frida-server | grep -E "(pool-frida|gum-js-loop|gmain|gdbus)"
# 应该返回空或显示魔改后的字符串

参考项目：

• strongR-frida-android
• Florida

3.6 部署魔改后的 frida-server——一条指令搞定

指令：

帮我把魔改frida-server,推入手机并重命名为aabbcc,

hermes执行流程：

步骤1：停止旧的 frida-server 进程

adb shell "su -c 'killall frida-server'"

步骤2：推送魔改后的文件并重命名

# 推送新文件到手机并直接重命名为 aabbcc
adb push /home/x1ny/.codeartsdoer/skills/android-root-research-workflow/frida-core-16.5.6/build/server/frida-server /data/local/tmp/aabbcc
# 输出: 1 file pushed, 25.0 MB/s (56536800 bytes in 2.158s)

步骤3：设置执行权限

adb shell "chmod 755 /data/local/tmp/aabbcc"

步骤4：验证部署结果

# 检查文件列表
adb shell "ls -la /data/local/tmp/ | grep -E 'frida|aabbcc'"
# 输出:
# -rwxr-xr-x 1 shell shell 56536800 2026-04-24 17:33 aabbcc
# -rwxr-xr-x 1 shell shell 53103840 2026-04-24 14:51 frida-server

# 验证版本
adb shell "/data/local/tmp/aabbcc --version"
# 输出: 16.5.6

部署结果对比：

验证成功标志：

• ✅ 魔改版 frida-server 已推送到设备
• ✅ 文件已重命名为 aabbcc
• ✅ 执行权限已设置 (755)
• ✅ 版本验证通过 (16.5.6)
• ✅ 文件完整性验证通过 (56.5 MB)

使用方式：

# 启动魔改版 frida-server
adb shell "su -c '/data/local/tmp/aabbcc -l 0.0.0.0:27042 -D'"

# 验证运行状态
adb shell "ps -A | grep aabbcc"

魔改版优势：

• 绕过应用的 Frida 检测机制
• 隐藏线程名称和函数名称特征
• 提高注入成功率
• 自定义文件名进一步降低检测风险

验证魔改是否生效

指令

重新启动魔改的 frida-server 并验证魔改是否生效

hermes执行流程：

魔改生效，找个APP试一下

3.7 常见问题与解决方案

0x04 深度解析：hermes自动进化到底意味着什么？

4.1 自动进化的本质——从「执行」到「理解」的质变

回顾整个流程，Hermes在六个关键节点上展现出了超越自动化的能力：

• 涌现金时刻五——持续优化：第一次10步，第二次就优化到6步。编译参数自动精进，犯过的错不再犯第二次
• 涌现金时刻六——攻防理解：魔改Frida时，它不只照做，它理解了「为什么要魔改」，并主动提出源码级+二进制级双重策略

这六个时刻串在一起，揭示了一个本质：**Hermes不等同于自动化脚本，它是一个会学习的系统。**每一次失败都在积累经验，每一次成功都在固化最优路径。这不是被优化——这是自我进化。

4.2 魔改Frida的攻防博弈——一场没有终点的猫鼠游戏

Hermes理解了魔改不只是「改几个字符串」，而是参与了一场攻防博弈：

• 它知道「为什么要改」而不只是「改什么」
• 它能预判哪种魔改策略更可能绕过检测
• 它提出了源码级+二进制级双重魔改的策略

这不是在执行任务，这是在参与安全对抗。

当前主流检测手段：

• 端口检测（27042）
• 进程名检测（frida-server）
• 线程名检测（gmain、gdbus等）
• 动态库检测（frida-agent.so）
• 内存特征检测
• /proc/self/maps检测

魔改策略演进：

• 第一代：简单重命名（已过时）
• 第二代：二进制特征修改（部分有效）
• 第三代：源码级魔改 + 二进制魔改（当前主流）
• 第四代：注入方式创新（ptrace、inline hook等）（前沿方向）

未来趋势：魔改Frida只是手段，真正的方向是：

1. 更隐蔽的注入方式：不依赖frida-server的独立注入
2. 动态特征生成：每次编译生成不同的特征，让检测无从下手
3. 对抗性编译：针对特定检测方案定制魔改策略

4.3 自动进化的边界——Hermes不是神，但它已经足够震撼

Hermes能做什么？

• ✅ 标准化流程执行——全自动，无人工干预
• ✅ 错误自动定位与修复——比自己排查快95%
• ✅ 操作记录与复现——下次直接用，不再从头来
• ✅ 依赖环境自动配置——NDK、Vala、依赖库一条龙
• ✅ 智能决策与方案选择——比很多新手判断得准
• ✅ 错误自愈与自动修复——遇到问题自己想办法
• ✅ 知识迁移与新场景适配——学过就会，不重复踩坑

Hermes做不到什么？

• ❌ 替代对Android系统的深入理解——你还是得懂底层
• ❌ 解决所有兼容性问题——有些坑只能靠经验填
• ❌ 自动应对未知的检测机制——攻防是持续演进的
• ❌ 保证100%成功率——它不是魔法

关键认知：

Hermes是能力的放大器，不是能力的替代品。

自动进化不是魔法，而是基于对领域知识的不断积累。Hermes让你从繁琐的重复劳动中解放出来，把精力放在真正需要人类创造力的事情上。而当它持续进化时，这把「能力放大器」的倍数还在不断增长。

结语：自动进化——这可能是安全圈今年最值得关注的事

回顾整个实践过程，我们看到的不仅是一次技术测试，更是一场AI自动进化的现场直播。Hermes 在一条从刷机到 Frida 魔改的完整链路中，展现了让人头皮发麻的进化能力：第一次犯错，第二次修正；第一次试探，第二次命中；第一次10步，第二次6步。它不是被优化——它在自我优化。

上一节我们聊了攻防博弈和边界，这一节我们把镜头拉远——看看自动进化到底改变了什么，以及你该怎么用起来。

过去 vs 现在——时代真的变了

过去：

• 搭环境耗时数天，人快疯了
• 遇到问题无从下手，谷歌搜到手软
• 操作不可复现，每次都是全新折磨
• 大量时间浪费在重复劳动上
• AI只是个命令执行器，你说什么它做什么

现在——Hermes上场后：

• 环境搭建缩短到数小时，甚至可以挂着去喝咖啡
• 错误自动定位，快速解决，不用再盯着报错发呆
• 所有操作可追溯、可复现，团队协作不再靠口口相传
• 专注于真正的安全研究——挖漏洞、分析算法、设计方案
• Hermes展现出真正的自动进化：理解、决策、学习、进化——而且永不停歇

自动进化的哲学思考——我们正在见证什么？

Hermes的自动进化现象，迫使我们重新思考AI的本质：

• 它不是简单的规则执行，而是对复杂系统的深度理解
• 它不是预设脚本的运行，而是根据环境实时动态调整策略
• 它不是被动响应命令，而是主动规划最优路径
• 它不是孤立处理任务，而是在建立知识关联网络——一次学会，处处复用

更关键的是——**这不是静态的行为，而是动态的进化过程。**你亲眼看到了一个系统从「会执行」到「会理解、会决策、会学习、会进化」的连续跨越。这才是自动进化最让人头皮发麻的地方：它不是今天这样、明天还是这样——它明天会比今天更强。

正如上一节所说，Hermes是能力的放大器。而自动进化意味着：这个放大器的倍数，正在随时间自动增长。

Hermes自动进化的真正价值

不在于替代人的技术能力，而在于释放人的创造力。

当繁琐的流程被自动化封装，当AI能自己理解上下文、自己做决策、自己修bug、自己在一次次执行中变得更聪明——我们终于可以把精力投入到真正有价值的工作中：

• 深入分析应用的安全机制
• 发掘新的漏洞和攻击面
• 设计更有效的防护方案
• 推动安全技术的进步

而最让人震撼的是：这个过程不是一次性的，而是持续加速的。Hermes 今天比昨天快，明天会比今天更快。这不是优化——这是进化。

未来展望——这只是开始

随着AI技术的持续发展，自动进化现象会越来越明显、越来越深入。未来的安全研究工具可能会：

• 自动识别应用的保护机制——省去逆向分析的第一步
• 智能选择最优的绕过方案——不再需要手动试错
• 自动生成测试脚本——一条指令覆盖全场景
• 甚至辅助分析复杂的加密算法——展现出更深层次的推理和创造能力
• 自主发现0day漏洞——这也许是下一个进化跃迁

实践建议——给不同阶段的安全研究者

给初学者的建议：

1. 先手动走一遍完整流程，理解每个步骤的作用——别跳过基本功
2. 遇到错误时，先自己分析原因，再让Hermes帮忙——这样你能学到更多
3. 保存每次操作的完整日志，建立自己的知识库
4. 不要盲目追求最新版本，稳定优先

给进阶者的建议：

1. 深入研究Frida源码，理解其工作原理——AI帮你执行，但你得懂原理
2. 关注魔改技术的发展，攻防双方都在持续进化
3. 建立自己的自动化工具链，让Hermes成为你的效率倍增器
4. 参与开源社区，贡献经验——安全圈需要分享和传承

给团队的实践建议：

1. 建立标准化的设备管理流程
2. 统一Frida版本和魔改方案，减少协作成本
3. 建立编译产物的版本管理，方便回溯
4. 定期更新和验证自动化流程，跟上技术演进

最后的话

但无论工具如何进化，有一样东西永远无法被替代：人的判断力和创造力。

Hermes是剑，你是剑客。只有深刻理解底层原理，才能把这把剑挥舞到极致。而自动进化，让这把剑前所未有地锋利——更可怕的是，它在自我磨砺。

本文记录的不仅是一次技术实践，更是AI自动进化的重大见证。当Hermes能够自主理解流程、智能决策、错误自愈、知识迁移、持续优化时，我们看到的不是「AI有多聪明」，而是「AI能多快变聪明」。

希望本文能为Android安全研究社区贡献一份实践参考，也为AI自动进化研究提供一个真实的、有说服力的案例。

安全研究是一条漫漫长路，但这次，我们有了一个真正「会思考、会进化」的伙伴。

如果你在实践中遇到问题，欢迎交流讨论。让我们一起，见证并参与这场正在发生的自动进化革命。

参考资源：

• Frida官方文档
• strongR-frida-android - Frida魔改项目
• Florida - Frida补丁集合
• Kitsune Mask - Android Root方案
• Android NDK - 官方NDK下载

操作流程已生成skill方便后续使用，放附件啦

[培训]《冰与火的战歌：Windows内核攻防实战》！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。