这个版本允许宿主向 pattern 传入预处理器宏，修复了我在把 pattern 接入即将推出的 Luma 时遇到的一批 pattern 语言边界问题，并且感谢 @pandasauce，缩小了在 arm64 Linux 和 Android 上执行 hook 时的竞态窗口。Windows 方面也有修复：@tshivaneshk 修复了导入枚举，此外还为 Windows 9x 修复了一批 Barebone 问题。

宏定义

pattern 经常需要知道自己的数据来自哪里。磁盘上的文件格式会内联存放有效载荷，但当同一格式映射到内存后，头部后面跟随的可能变成一个指针。ImHex pattern 使用预处理器处理这类情况，现在我们的 pattern 也可以了：PatternCompiler 接受一个 defines 字典，其行为相当于在入口点顶部添加 #define。假设有一个 image.hexpat：

#pragma abi native

struct Header {
    u32 magic;
    u32 size;
};

struct Image {
    Header header;
#ifdef MAPPED
    u64 base;
#else
    u8 payload[header.size];
#endif
};

分别在定义和不定义 MAPPED 的情况下编译，同一份源码会产生两种不同的布局：

import frida

compiler = frida.PatternCompiler()

for defines in (None, {"MAPPED": 1}):
    options = {"platform": "darwin", "arch": "arm64"}
    if defines is not None:
        options["defines"] = defines
    module = compiler.compile("image.hexpat", **options)
    image = module.lookup("Image")
    fields = [(f.name, f.type_ref.display) for f in image.fields]
    print(f"defines={defines}: {fields}, size={image.size}")

defines=None: [('header', 'Header'), ('payload', 'u8[...]')], size=-1
defines={'MAPPED': 1}: [('header', 'Header'), ('base', 'u64')], size=16

宏定义会随模块一起传递，因此解码和 call_function() 看到的预处理器状态与编译时完全相同。语言服务器会在 workspace/didChangeConfiguration 时从 settings.patterns.defines 获取宏定义，使编辑器的诊断结果可以与宿主编译 pattern 的方式保持同步。正因如此，Luma 才能告诉 pattern 它正在解码文件还是已映射的镜像，而 pattern 无需了解任何 Luma 相关细节。

除此之外，我们用即将推出的 Luma 对真实世界的 pattern 进行了一周测试，暴露出实现中围绕模板、ref 参数、枚举名称和 array_index() 的一些边界情况。本版本已全部修复，详细内容见下方变更日志。

arm64 Linux 上的 Interceptor

Georgi Boiko（@pandasauce）追踪到了 Android 上的崩溃问题。它源于 arm64 重定向与线程之间的相互作用：这些线程恰好暂停在正在被 hook 的函数内部。在 arm64 上，默认 hook 会使用 ADRP+BR 或 LDR+BR+字面量序列重写函数开头的 16 字节；暂停在第一条指令之后任意位置的线程，恢复后可能进入只完成了一半修补的函数序言。

现在，对于至少有八个可重定位字节的默认 hook，Interceptor 会尝试在 Linux 和 Android 上于 B 指令可达范围内为 trampoline 寻找一个 slice，使重定向只需一条 B 指令。暂停的线程随后会从未经改动的原始字节恢复，而补丁本身只需一次对齐写入。恢复重定向也只需一次写入。为了更频繁地提供这样的邻近 slice，当完整的七页批次无法放入目标附近的空闲空间时，代码分配器现在会用单页重试邻近分配。

Arm 架构参考手册仍指出：当另一个核心可能正在执行某条任意指令时，用分支替换它的行为不可预测。因此，这项改动只是缩小了竞态窗口，并未彻底消除它，但实践中效果非常明显。还有一个需要注意的取舍：原本会使用 16 字节重定向的 hook，现在会更快耗尽目标附近的空间；而对于只有一条指令长的函数，由于其他方案都放不下，这些空间是执行 hook 的唯一选择。非常感谢 Georgi！

Windows

@tshivaneshk 注意到，Windows 上的 Module.enumerateImports() 会把每个导入的槽位都报告为 IAT 基址，并在导入模块中查找每个地址，而不是从 IAT 读取。现在它会在遍历查找表的同时遍历 IAT，报告每个条目及其绑定值；我们的测试也会检查报告的地址。感谢！

此外，Process.id 现在会在 QuickJS 中保持无符号。Windows 9x 会分配大于 2^31 的进程 ID，此前这些值在 JavaScript 运行时中会变成负数。

Barebone

说到 Windows 9x，我们使用 Barebone 后端与 Explorer 等程序进行的几次会话，暴露出注入用户进程的 agent 中存在五个错误：从模块加载破坏已退出线程的记录，到分离超时并导致客户机蓝屏。现已全部修复，详情见变更日志。

EOF

尽情使用吧！

变更日志

• patterns：允许宿主通过 PatternCompileOptions.defines 定义预处理器宏，并将其传递到解码和调用过程；语言服务器则通过 settings.patterns.defines 接收。（上文已介绍。）
• patterns：模板嵌套实例化达到 64 层后，报告无限模板递归。
• patterns：将 pattern 传给 ref 参数，使格式化位域或结构体的函数能够找到其成员。
• patterns：按名称查找模板局部变量和字段作为后备方案，用于多个外层类型共享的模板。
• patterns：支持在元素内部调用 array_index()。
• patterns：通过成员访问时保留枚举名称，并允许 formatted_value() 格式化标量和位域。
• interceptor：当 B 指令范围内存在可用 slice 时，在 arm64 Linux 和 Android 上使用 4 字节重定向。感谢 @pandasauce！
• codeallocator：在 Linux 和 Android 上用单页重试邻近批次分配。感谢 @pandasauce！
• windows：修复导入槽位和地址。感谢 @tshivaneshk！
• gumjs：在 QuickJS 中保持 Process.id 为无符号值。
• barebone：修复注入用户进程的 agent 中五个 Windows 9x 问题：模块加载破坏已退出线程的记录；主线程停驻在后续注入可能复用的内存中；启动栈泄漏；工作线程从未被唤醒导致分离超时；换出内存上的故障未交还 Windows 处理。
• swift：为 PatternCompiler.compile() 添加 defines。
• subprojects：回退 termux-elf-cleaner 升级，因为其新代码需要 C++20，而宿主工具构建并未使用 C++20。

这是一次快速跟进发布，用于修复 17.22.1 中的一项回归，以及期间合入的另外几个问题。

我们在 17.22.1 中为 glibc 添加的栈丢弃逻辑，假定每个正在退出的线程都是由我们设置的。GLib 仅仅接管的线程——例如外部 pthread 调用 GLib 时——退出时仍会执行 finalize，但从未经过 realize，因此栈丢弃逻辑会解引用 NULL，并让进程随之崩溃。一个 frida-node 使用方在完成附加、加载脚本并退出后会死于 SIGSEGV；长时间运行的测试中，只要其中一个此类线程在运行途中退出，也会发生同样的问题。@hsorbo 修复了这个问题：没有可供处理的基础数据时跳过栈丢弃，并添加了一个测试，用于接管外部线程并让其退出。

Håvard 还修复了 QuickJS 分支中一个长期存在的问题。当循环收集器释放对象时，会释放所有以该对象为键的 WeakMap 条目值。这些值是扫描后仍存活的对象；如果这种释放使其中某个对象的引用计数降为零，它会因为运行时正忙于移除循环而被忽略，此后也不会再得到处理。它会以零引用计数一直留到运行时销毁，此时其终结器可能访问已经不存在的状态。现在，这类对象会收集到延迟列表中，并在循环移除结束后释放，与其他引用计数降为零的对象相同。

最后，@mbv06 注意到新版 ART 会把启动镜像的 methods 节复制到自己的 memfd 映射，因此 Android 启动支持现在还会在 boot-image-methods.art 中查找 setArgV0() JNI 槽位。

尽情使用吧！

变更日志

• glibc：对接管的线程跳过栈丢弃，修复 17.22.1 引入的线程退出崩溃。感谢 @hsorbo！
• quickjs：释放移除循环期间被释放的存活对象，使循环收集过程中通过 WeakMap 条目释放的值能够运行终结器，而不会一直残留到运行时销毁。感谢 @hsorbo！
• android：在 boot-image-methods.art 中扫描 setArgV0() JNI 槽位，因为新版 ART 会单独映射启动镜像的 methods 节。感谢 @mbv06！

这是一个错误修复版本，其中大多数修复由 @hsorbo 完成，另有一位新贡献者让 C++ 绑定变得更完整。

内存扫描找到自身

Håvard 注意到，Linux 上的指针扫描可能会在一个已不再被任何线程使用的栈中找到它正在寻找的那些值。扫描工作线程会把搜索值溢出到自己的栈上；当线程池被释放、额外工作线程退出后，glibc 会保留这些栈以供复用，而退出栈帧之上的所有内容仍保持映射且可读。延迟清理逻辑取消隐藏这些区域后，下一次扫描就会愉快地找到自己留下的残余。任何曾在线程调度器的线程池上运行的内容也同样如此。

修复方法是在 Gum 线程退出时立即丢弃它溢出到栈上的内容。这项操作由 frida-glib 在线程自身执行的 finalize 回调完成，发生在线程库缓存该栈之前。其他 libc 会直接取消映射已退出线程的栈，因此只有 glibc 需要承担这次额外系统调用的开销。

其他修复

Håvard 还修复了另外两个 Linux 相关问题。当最后一个监听器的分离仍待处理时再次对函数插桩——GumJS 在脚本级事务中正是这样做的——可能会把过时的重定向解析到一个 trampoline，而后者随后会随旧上下文一同释放。现在该函数会被视为仍处于插桩状态；如果新旧插桩均为默认类型，就复用其上下文，否则立即将其停用。此外，对由 dlopen() 作为依赖项引入的模块调用 dlsym() 时不再崩溃；此前 glibc 尚未为我们用作句柄的 link map 计算局部作用域。

最后同样重要的是，@mnalmahmud 通过新的 ProbeListener 接口，让 C++ 绑定可以把探针附加到任意指令，因此不再需要降级使用 C API。

尽情使用吧！

变更日志

• glibc：线程退出时丢弃已终止 Gum 线程的栈，使内存扫描不再找到扫描工作线程或脚本调度器线程池留下的残余。感谢 @hsorbo 追踪到这个问题！
• interceptor：修复等待分离期间重新附加的问题；该问题可能把过时的重定向解析到随后被释放的 trampoline。感谢 @hsorbo！
• linux：通过使用 RTLD_NOLOAD 按需创建句柄，修复在 dlopen() 以依赖项形式发现的模块上调用 dlsym() 时的崩溃。感谢 @hsorbo！
• gumpp：添加探针监听器支持，把 gum_make_probe_listener() 公开为 ProbeListener 接口，并允许 Interceptor::attach() 和 detach() 接受它。感谢 @mnalmahmud！
• frida-compile：按需创建输出文件目录，frida-tools 和 npm 软件包均适用。感谢 @fourcels！

昨天的两个版本让 pattern 成为 Agent 和工具中的一等公民。本次发布着重于共享：frida-compile 现在可以构建库，因此 npm 包能够把 pattern 与 TypeScript 一同发布，任何人都可导入使用。还要感谢 @hsorbo，Swift ApiResolver 现已能在 Linux 上运行，Windows 支持也紧随其后。

库

假设你编写了一些 pattern 及其辅助函数，并希望发布给其他 Agent 使用。此前必须先运行一次 frida-compile 获取 pattern 类型定义，再用 tsc 生成包，同时还要仔细配置 tsconfig.json，使其与 Frida.Compiler 解析导入的方式一致。对同一份源码运行两个编译器实在多余。

使用 frida-compile –library 后，Frida.Compiler 会完成全部工作。下面是一个在游戏中查找玩家的包中的 lib/index.ts：

import { Player } from "./patterns/player.hexpat";

export function findPlayers(range: RangeDetails, health: number): Player[] {
    const pattern = Player.pattern({ health });
    return Memory.scanSync(range.base, range.size, pattern)
        .map(({ address }) => Player.at(address));
}

export function describe(player: Player): string {
    const { x, y, z } = player.position;
    return `health=${player.health} lives=${player.lives} at (${x}, ${y}, ${z})`;
}

旁边是 lib/patterns/player.hexpat：

#pragma abi native

struct Player {
    u32 health;
    u32 lives;
    Vec3 position;
};

struct Vec3 {
    float x;
    float y;
    float z;
};

源码就只有这些。package.json 不需要 typescript、@types/frida-gum 或 tsconfig.json，只需 npm 上的 frida-compile：

{
  "name": "frida-module-example",
  "version": "1.1.0",
  "main": "./dist/index.js",
  "types": "./dist/index.d.ts",
  "files": ["/dist"],
  "type": "module",
  "scripts": {
    "prepare": "frida-compile --library lib/index.ts -o dist"
  },
  "devDependencies": {
    "frida-compile": "^19.1.0"
  }
}

执行构建后得到：

$ frida-compile --library lib/index.ts -o dist
$ find dist -type f | sort
dist/index.d.ts
dist/index.js
dist/index.js.map
dist/patterns/player.hexpat
dist/patterns/player.hexpat.d.ts

每个源文件对应一个模块和一个声明文件，pattern 会一并复制，其生成的类型定义也放在旁边。声明内容正如你所期待：

import { Player } from "./patterns/player.hexpat";
export declare function findPlayers(range: RangeDetails, health: number): Player[];
export declare function describe(player: Player): string;

请注意，pattern 以源码形式发布，而不是 Frida.Compiler 转换后的 JavaScript。这是有意为之：生成的代码依赖使用方构建所提供的运行时，并可跨包去重；其他 pattern 以及 Luma 等工具也能导入它；而且 pattern 语言比我们生成的代码稳定得多。使用方的 Frida.Compiler 会在构建过程中用几毫秒完成编译，并缓存结果。

接下来看看使用方。执行 npm install frida-module-example 后，Agent 既可使用辅助函数，也可直接使用 pattern：

import { findPlayers, describe } from "frida-module-example";
import { Player } from "frida-module-example/dist/patterns/player.hexpat";

const arena = Memory.alloc(Player.size * 2);
const alice = Player.at(arena);
alice.health = 100;
alice.lives = 3;
alice.position.z = 1.5;

for (const player of findPlayers({ base: arena, size: Player.size * 2 } as RangeDetails, 100))
  console.log(describe(player));

$ frida -q -p 0 -l agent.ts
health=100 lives=3 at (0, 0, 1.5)

再补充一些细节：

• -w 会在编辑时持续更新库；同时迭代包和应用时，它与 npm link 配合得很好。
• source map 会生成在各模块旁边，并内联源码，因此无需发布 lib/，使用方也能获得真实的堆栈跟踪。传入 -S 可不生成它们。
• 错误报告方式与 Agent 构建相同，路径相对于项目；只要存在错误，就不会写入任何内容：

lib/broken.ts:1:14 - error TS2322: Type 'string' is not assignable to type 'number'.
compilation failed

• 输出会在公共目录下镜像源码树，因此 lib/index.ts 会生成到 dist/index.js。如果 tsconfig.json 设置了 rootDir，则会遵循该设置。
• 此功能对应 frida-core 中的 Compiler.build_library() 和 Compiler.watch_library()，因此所有语言绑定都可使用；frida-compile 则同时在 frida-tools 和 npm 包中公开它。

Swift

Swift ApiResolver 昨天刚获得查找类型、协议及其遵循关系的能力，但此前只能在 Apple 平台工作。它会查找 libswiftCore.dylib，从 libsystem_malloc 借用 free()，并按 Mach-O 名称匹配元数据节，因此 Linux 上的每次查询都会以“unsupported Swift runtime”失败。

Håvard 修复了所有这些问题：解析器现在按平台确定 Swift 核心库和元数据节名称；没有 libsystem_malloc 时，从 C 运行时获取 free()；还为每个实例分别保存名称还原器，因为 Linux 上的 dlclose() 会取消映射 libswiftCore，缓存的指针可能比它存活更久。他还让 Swift 测试真正运行在 Linux CI 上——此前它们一直被静默跳过——并将跳过正确报告为跳过，而不是通过。非常感谢 Håvard！

有了这些基础，Windows 支持只是很小的一步：使用 swiftCore.dll、.sw5* 节，并通过 UCRT 释放还原后的名称。Windows 有个值得注意的特点：swiftrt.obj 会在每个元数据节两端放置清零的起止标记，解析器现在会跳过它们。因此，只要加载了 Swift 运行时，new ApiResolver(‘swift’) 及其 functions:、types:、protocols: 和 conformances: 查询在各平台都能以相同方式工作。

结语

尽情体验吧！

变更日志

• compiler：通过 Compiler.build_library() 和 Compiler.watch_library() 新增库构建，并以 frida-compile –library 公开。（上文已介绍。）
• swift-api-resolver：新增 Linux 支持，按平台确定 Swift 核心库和元数据节名称，并为每个解析器实例保存名称还原器。感谢 @hsorbo！
• swift-api-resolver：新增 Windows 支持，包括跳过 swiftrt.obj 生成的清零节标记。
• swift-api-resolver：在测试中查找 Swift 工具链，使其在 GitHub 的 Ubuntu runner 上真正运行，而不是静默跳过。感谢 @hsorbo！
• gumjs：解析指令操作数时处理所有 arm64 向量排列。v0.b[0] 等单通道和窄排列此前会进入不可达的默认分支；编译时移除断言后会导致进程崩溃。感谢 @hsorbo！
• windows：修复节名称和大小。恰好八个字符的名称没有 NUL 终止符；大小现在使用加载器所见的虚拟大小，而不是按文件对齐的原始大小。
• swift：为库构建重新生成绑定。

一天发布两个版本？软件开发很难，API 设计更难。但这次值得：@hsorbo 让 Swift ApiResolver 学会查找类型、协议和协议遵循关系；新的 PatternCompiler API 也重塑为基于文件工作，使 pattern 在主机端也能相互导入。

Swift

Frida 的 ApiResolver(‘swift’) 已推出一段时间，可用 glob 按还原后的名称查找 Swift 函数。它在幕后遍历编译器写入每个 Swift 二进制文件的 Swift 元数据，类型和协议信息也存放在那里。Håvard 从 2023 年起持续改进这个解析器；在 17.20.0 中，他改用运行 Swift 代码时始终存在的 libswiftCore 来还原名称，而不是通常不存在的 libswiftDemangle，使其可在更多进程中工作。

在此基础上，本版本新增三类查询。首先，types: 和 protocols: 按完整名称匹配名义类型和协议，并返回上下文描述符的地址：

const resolver = new ApiResolver('swift');

for (const { name, address } of resolver.enumerateMatches('types:*!Swift.Int'))
  console.log(name, address);

for (const { name, address } of resolver.enumerateMatches('protocols:*!Swift.Hashable'))
  console.log(name, address);

/usr/lib/swift/libswiftCore.dylib!Swift.Int 0x19bf8009c
/usr/lib/swift/libswiftCore.dylib!Swift.Hashable 0x19bf7c490

与其他解析器一样，! 前面的部分匹配模块，因此 types:*libswiftCore*!Swift.Dictionary* 可将范围缩小到特定库，并查找嵌套类型：

/usr/lib/swift/libswiftCore.dylib!Swift.Dictionary 0x19bf7abe8
/usr/lib/swift/libswiftCore.dylib!Swift.Dictionary.Keys 0x19bf7ac54
/usr/lib/swift/libswiftCore.dylib!Swift.Dictionary.Values 0x19bf7ac90
/usr/lib/swift/libswiftCore.dylib!Swift.Dictionary.Keys.Iterator 0x19bf7accc
/usr/lib/swift/libswiftCore.dylib!Swift.Dictionary.Values.Iterator 0x19bf7ad08

其次，conformances: 按类型名和协议名匹配协议遵循关系，并返回遵循关系描述符的地址。这是我最兴奋的功能，因为它能回答“这个类型实现了哪些协议？”之类的问题：

for (const { name, address } of resolver.enumerateMatches('conformances:Swift.Int!Swift.*'))
  console.log(name, address);

Swift.Int!Swift.Encodable 0x19bf5f6c4
Swift.Int!Swift.Decodable 0x19bf5f6d4
Swift.Int!Swift.CodingKeyRepresentable 0x19bf5f984
Swift.Int!Swift.CustomReflectable 0x19bf612ec
Swift.Int!Swift._CustomPlaygroundQuickLookable 0x19bf612fc
...

反过来也能回答“哪些类型实现了这个协议？”，这在大型应用中尤其有趣：

const encodable = resolver.enumerateMatches('conformances:*!Swift.Encodable');
console.log(encodable.length, 'types conform to Encodable');
for (const { name, address } of encodable.slice(0, 3))
  console.log(name, address);

3735 types conform to Encodable
UIIntelligenceSupport.IntelligenceElement.Axis!Swift.Encodable 0x2a5e0a1c8
UIIntelligenceSupport.IntelligenceElement.Image!Swift.Encodable 0x2a5e0a9d0
UIIntelligenceSupport.IntelligenceElement.CustomAppEntity!Swift.Encodable 0x2a5e0b0e8

从遵循关系描述符可以找到 witness table，从上下文描述符则可找到类型的元数据、字段和方法。因此，它们是任何希望在运行时理解 Swift 程序类型的工具的基础构件，从美化输出某个值，到 Hook 实现特定协议的每个类型。未来会有更多功能构建在其上。

他还修复了 /i 后缀；Swift 解析器此前虽然接受它，却没有真正生效。非常感谢 Håvard 完成这些出色工作！

PatternCompiler

今天早些时候的版本引入了 PatternCompiler API，可在主机上编译 pattern，并据此解码内存。它原本接收源码字符串，看似方便，却无法知道源码位于何处，因此 pattern 除 std 库外不能导入任何内容。现在已经修复，API 与 Compiler.build() 对齐：传入路径，还可选择传入项目根目录；省略后者时会根据入口点推断。假设有 proj/player.hexpat，它从 proj/common.pat 导入 Vec3：

#pragma abi native

import common;

struct Player {
    u32 health;
    Vec3 position;
};

导入解析方式与 Frida.Compiler 构建 Agent 时完全相同：先相对于导入文件解析，再从 node_modules 中解析。现在每种类型都会说明其声明文件，每条诊断也一样；路径相对于项目根目录，与构建诊断的报告方式相同：

import frida

module = frida.PatternCompiler().compile("proj/player.hexpat")
for d in module.diagnostics:
    print(f"{d.file}:{d.line + 1}:{d.character + 1}: {d.message}")
for t in module.types:
    print(f"{t.file}: {t.kind} {t.name}, {t.size} bytes")

如果 common.pat 缺少分号，会报告：

proj/common.pat:5:1: expected ;

修复后则输出：

proj/common.pat: struct Vec3, 12 bytes
proj/player.hexpat: struct Player, 16 bytes

语言服务器也进行了相同改造，因此 .hexpat 导入另一标签页中尚未保存的缓冲区时也能解析，而且问题仍归属其所在文件。Swift 绑定已相应重新生成，其他绑定会自动获得这些变化。

这是对今天早上刚发布 API 的破坏性变更，希望尚无人基于它构建内容。如果已经使用，迁移方法是把 pattern 写入文件并传入其路径。

结语

尽情体验吧！

变更日志

• swift-api-resolver：新增 types: 和 protocols: 查询，按完整名称匹配 __swift5_types、__swift5_types2 和 __swift5_protos 中的描述符。感谢 @hsorbo！
• swift-api-resolver：新增 conformances: 查询，按类型名和协议名匹配 __swift5_proto 记录，并让 /i 真正生效。感谢 @hsorbo！
• compiler：从文件编译 pattern；导入和 include 的解析方式与 Agent 构建相同；每种类型和诊断的文件名都相对于项目根目录。（上文已介绍。）
• compiler：修复项目根目录为相对路径时的崩溃；此前 TypeScript 编译器虚拟文件系统内部的错误会导致整个进程退出。
• swift：重新生成 PatternCompiler 绑定。

从 Frida 诞生以来，处理结构体一直是它的薄弱环节之一。假设你在游戏中找到了一个 Player 结构体，并想读取它的 lives 字段，最终往往会写出这样的代码：

const lives = player.add(4).readU32();

那个神秘的 4 是你手工算出的偏移量，readU32() 也是你手工确定的类型；除了这一行， 这些信息没有记录在任何地方。把这种情况乘以你关心的每个结构体中的每个字段，最后得到的 脚本既脆弱又难读，结构布局也几乎无法与别人共享。如果结构体在 32 位和 64 位环境中的 布局不同，你还得维护两套偏移量。

这些年来我一直在思考这个问题。我真正想要的是一种类型安全的方法，让 TypeScript 编译器知道有哪些字段以及它们各自的类型，从而在编译时发现拼写错误，并让编辑器自动补全 字段名。这显然需要一个代码生成步骤，而我始终觉得让用户承担这一步的成本太高。

后来 Frida.Compiler 出现了。它并非从一开始就存在，但如今已经为 frida-compile、REPL 以及 Luma 等工具提供支持，代码生成步骤可以完全隐藏起来。这正是本次发布的主题。

模式

我们没有再发明一种结构体描述语言，而是采用了 ImHex 的模式语言。 这是一种用于描述二进制数据的类 C 语言，最初为 ImHex 的十六进制编辑器而创建，支持 结构体、联合体、枚举、位域、指针、条件、动态长度数组以及标准库。ImHex-Patterns 仓库收录了大量常见文件格式的模式，此后这门语言也被其他工具采用：x64dbg 通过 DataExplorer 插件提供支持，radare2 则通过 r2hexpat 提供支持。因此，你很可能 能找到可直接复用的现有模式；为 Frida 编写的模式也同样能用于这些工具。

Frida 17.20.0 使用 Go 在 Frida.Compiler 中实现了这门语言，与 TypeScript 编译器并列。 下面来试试看。这是 game.hexpat：

#pragma abi native

struct Player {
    u32 health;
    u32 lives;
    Role role;
    Vec3 position;
    Player* next;
};

struct Vec3 {
    float x;
    float y;
    float z;
};

enum Role : u8 {
    Warrior,
    Mage,
    Rogue,
};

如果你写过 C 结构体，就已经知道该如何阅读它。唯一显眼的是 #pragma abi native，稍后我们会回到这一点。

随后在 agent.ts 中像导入其他模块一样导入该模式：

import { Player, Role } from "./game.hexpat";

const roster = Memory.alloc(Player.size * 3);

const alice = Player.at(roster);
alice.health = 100;
alice.lives = 3;
alice.role = Role.Mage;
alice.position.x = 1.5;
alice.position.y = -2;
alice.position.z = 3;

const bob = Player.at(roster.add(Player.size));
bob.health = 42;
bob.lives = 1;
bob.role = Role.Warrior;
alice.next = bob;

const carol = Player.at(roster.add(Player.size * 2));
carol.health = 100;
carol.lives = 3;
carol.role = Role.Rogue;
bob.next = carol;

console.log("Player.size:", Player.size);
console.log(JSON.stringify(alice, null, 2));
console.log("alice.next.next.role:", Role[alice.next!.next!.role]);

在真实场景中，这些结构体显然由游戏自身持有，我们会通过 Interceptor、内存扫描或类似 方式找到它们。为了让示例自包含，这里由我们自己分配三个实例。

运行它：

$ frida -q -p 0 -l agent.ts
Compiling agent.ts...
Compiled agent.ts (20 ms)
Player.size: 32
{
  "health": 100,
  "lives": 3,
  "role": 1,
  "position": {
    "x": 1.5,
    "y": -2,
    "z": 3
  },
  "next": "0x140cb5bc0"
}
alice.next.next.role: Rogue

这里有几点值得注意：

• 每个结构体都会变成一个类。Player.at(address) 提供该地址处内存的实时视图， 每个属性都直接读写底层内存。不会复制任何内容，因此你看到的始终是内存中的当前值。
• position 这样的嵌套结构体同样是视图；next 这样的指针字段会提供其所指对象的 视图，或返回 null。给指针字段赋值时，可以传入视图或 NativePointer。
• 枚举会变成带反向映射的对象，因此 Role[alice.role] 会得到 “Mage”。
• Player.size 是结构体的字节大小，JSON.stringify() 也可直接使用。
• 没有任何内容经过预编译。REPL 将 agent.ts 交给 Frida.Compiler；后者发现 .hexpat 导入后，把模式编译为 JavaScript，并与 agent 一起打包。运行 frida-compile agent.ts -o _agent.js 时也会执行同样的流程，生成的包是自包含的， 可由我们的任意语言绑定加载。

原生布局

由于模式语言是为文件格式设计的，ImHex 会以紧凑方式布局结构体，字段之间没有填充， 因为文件格式通常就是这样。另一方面，Frida 还需要处理由 C 编译器布局的内存中结构体， 而这类结构体会按自然对齐方式填充。这就是 #pragma abi native 的用途。它只存在于 Frida 的语言方言中，用来告诉编译器按照目标平台 C 编译器的方式布局结构体。在上面的 示例中，role 占一个字节，随后有三个填充字节，使 position 达到 4 字节对齐； 在 64 位进程中，next 则达到 8 字节对齐。因此 Player.size 是 32 而不是 25。 省略该 pragma 后会得到 ImHex 的紧凑布局，这正是解码恰好映射到内存中的文件格式时 所需要的布局。

生成的 JavaScript 也会考虑目标平台的 ABI。next 等指针字段在 64 位进程中占 8 字节， 在 32 位进程中占 4 字节，这会改变其后所有字段的偏移量；而且 32 位 Windows 与 32 位 Linux 等平台的对齐规则也不同。Frida.Compiler 会在编译时计算所有这些布局， 生成的代码则根据最终运行所在的进程在运行时选择正确布局。因此，一个编译后的 agent 就能支持 Frida 支持的任意目标，无需维护各架构专用的偏移量。

类型安全

这是最令我兴奋的部分。Frida.Compiler 加载 .hexpat 时，还会为它生成 TypeScript 声明，并以 game.hexpat.d.ts 的形式写在模式文件旁边：

export declare class Player {
    constructor(address: NativePointer);
    static at(address: NativePointer): Player;
    static readonly size: number;
    static pattern(fields: Player.Fields): string;
    static parse(address: NativePointer, size?: number): Player.Parsed;
    readonly $address: NativePointer;
    readonly $size: number;
    health: number;
    lives: number;
    role: Role;
    readonly position: Vec3;
    get next(): Player | null;
    set next(value: Player | NativePointer | null);
    toJSON(): Player.Values;
}

这意味着 TypeScript 编译器能准确知道有哪些字段以及它们的类型。拼错字段名会得到编译 错误，编辑器也能自动补全字段名。在结构体中加入 char name[16] 后，它会显示为只读 string；如果尝试给它赋值，编译器会发出提示。（我写这篇文章时就被提示过。）模式本身 的错误也会像 TypeScript 错误一样，连同文件和行号一起报告：

$ frida-compile agent.ts -o _agent.js
game.hexpat:5:5 - error TS-1: unknown type Badge
compilation failed

你可能需要将 *.hexpat.d.ts 加入 .gitignore，因为每次构建都会重新生成这些文件。

扫描

现在来看让这一切如同魔法的部分。假设我们要寻找一个生命值全满且有三条命的 Player， 但完全不知道它位于内存中的什么位置。每个生成的类都有一个静态 pattern() 方法， 它接收字段的一个子集，并为 Memory.scan() 生成匹配模式；省略的字段会变成通配符：

const pattern = Player.pattern({ health: 100, lives: 3 });
console.log("pattern:", pattern);

for (const { address } of Memory.scanSync(roster, Player.size * 3, pattern)) {
  const p = Player.at(address);
  console.log(`${address}: ${Role[p.role]} with ${p.lives} lives`);
}

结果如下：

pattern: 64 00 00 00 03 00 00 00 ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
0x140cb5ba0: Mage with 3 lives
0x140cb5be0: Rogue with 3 lives

字节序、字段偏移量和填充都已自动处理。在真实游戏中，你会扫描 Process.enumerateRanges(‘rw-‘) 返回的堆范围，而不是这个小小的 roster；还可以加入 枚举值或嵌套字段来缩小范围，例如 Player.pattern({ role: Role.Rogue, position: { z: 3 } })。

超越视图

实时视图覆盖纯数据结构体，而进程内部遇到的大多数结构体都属于这一类。但模式语言还能 做到更多：由前置字段决定长度的数组、条件、具有自定义基址的指针、局部变量、函数、 [[format]] 和 [[color]] 等属性、std 库等等。对于这些功能，可以使用 parse()， 它以完整的 ImHex 语义解码内存快照。下面用 macOS 和 iOS 上每个进程都有的内容来试验： 主可执行文件的 Mach-O 头。将以下内容写入 macho.hexpat：

#pragma endian little

struct MachO {
    MachHeader header;
    LoadCommand commands[header.ncmds];
};

struct MachHeader {
    u32 magic [[color("FF8800")]];
    CpuType cputype;
    u32 cpusubtype;
    FileType filetype;
    u32 ncmds;
    u32 sizeofcmds;
    u32 flags;
    u32 reserved;
};

struct LoadCommand {
    u32 cmd;
    u32 cmdsize;
    u8 payload[cmdsize - 8] [[sealed]];
};

enum CpuType : u32 {
    X86_64 = 0x01000007,
    ARM64 = 0x0100000C,
};

enum FileType : u32 {
    Object = 1,
    Execute = 2,
    Dylib = 6,
};

MachO macho @ 0x00;

请注意，这里没有 #pragma abi native，因为这是文件格式。还要注意末尾的 placement， ImHex 模式通常用这种方式声明文件开头的内容。在本例中，“文件”是一段内存，而带有 placement 的模式会为我们提供一个用于解码它们的 parse() 导出：

import { parse, MachHeader, CpuType, FileType } from "./macho.hexpat";

const base = Process.mainModule.base;

const header = MachHeader.at(base);
console.log("magic:", header.magic.toString(16), CpuType[header.cputype],
    FileType[header.filetype]);
console.log("ncmds:", header.ncmds);

const image = parse(base, 4096).macho;
console.log("commands:", image.commands.length);
for (const cmd of image.commands.slice(0, 3)) {
  console.log(`  cmd=0x${cmd.cmd.toString(16)} cmdsize=${cmd.cmdsize}`,
      `@ ${cmd.$address}`);
}

$ frida -q -p 0 -l macho.ts
Compiling macho.ts...
Compiled macho.ts (19 ms)
magic: feedfacf ARM64 Execute
ncmds: 20
commands: 20
  cmd=0x19 cmdsize=72 @ 0x102a64020
  cmd=0x19 cmdsize=312 @ 0x102a64068
  cmd=0x19 cmdsize=152 @ 0x102a641a0

parse() 的第二个参数限制它最多可以读取多少内存。当模式中数组的长度取决于尚未完全 信任的数据时，这样做很有必要。结果是一棵普通值组成的树，每个结构体都带有 $address 和 $size，因此可以知道每部分来自哪里。由于该结构体是纯数据， MachHeader.at() 仍可同时作为实时视图使用。

模式可以导入其他模式。导入项会先相对于发起导入的文件解析，再从 node_modules 解析，因此模式可以作为 npm 包发布。std 库已内置，所以 import std.mem; 可直接使用。 我们的测试套件会运行 ImHex-Patterns 语料库，其中 312 个模式有 303 个无需修改即可编译； 其余模式要么依赖 ImHex 本身，要么在那里也会失败。可视化器（即 hex::visualize()）由接下来介绍的宿主端 API 求值，在 agent 内部则会被忽略。

PatternCompiler

Frida.Compiler 负责处理 agent，但构建在 Frida 之上的工具通常希望在宿主端解码内存， 而不向目标注入任何模式代码。为此，frida-core 新增了 PatternCompiler API，自动生成的 frida-python、frida-node 和 frida-swift 等绑定会自动获得它。你向它提供模式源代码， 它会返回一个 PatternModule：该模块描述模式声明的类型，并能按照其中任意类型解码 一段字节。下面从 Python 使用它，解码前面查看过的同一个 Mach-O 头：

from pathlib import Path

import frida

session = frida.attach(0)
script = session.create_script("""
rpc.exports = {
  mainModule() {
    const { base, name } = Process.mainModule;
    return [name, base.toString()];
  },
  read(address, size) {
    return ptr(address).readByteArray(size);
  },
};
""")
script.load()

name, base = script.exports_sync.main_module()
base = int(base, 16)
data = script.exports_sync.read(base, 4096)

module = frida.PatternCompiler().compile(Path("macho.hexpat").read_text(),
                                         platform="darwin", arch="arm64")
assert len(module.diagnostics) == 0

macho = module.decode("MachO", data, base)
header = macho.fields[0]
print(f"{name} @ {macho.address:#x}")
for field in header.fields:
    print(f"  {field.name:<11} {field.type_name:<10} "
          f"{field.label or field.value!s:<10} {field.color or ''}")
commands = macho.fields[1]
print(f"  {commands.name}: {commands.count} load commands, "
      f"{commands.size} bytes")

$ python3 decode.py
Python @ 0x104ec0000
  magic       le u32     4277009103 FF8800
  cputype     CpuType    ARM64
  cpusubtype  le u32     0
  filetype    FileType   Execute
  ncmds       le u32     20
  sizeofcmds  le u32     1232
  flags       le u32     2097285
  reserved    le u32     0
  commands: 20 load commands, 1232 bytes

解码后的树包含 UI 所需的一切：每个值的地址、偏移量和大小，枚举标签，[[format]] 输出，[[comment]]、[[color]]，以及模式附加的任何可视化器及其求值后的参数。 具体如何渲染由工具决定。模块还会描述已声明的类型及其字段、偏移量和大小，因此无需 解码任何内容即可构建类型浏览器。模式可以声明 in 变量，解码时按名称提供；如果模式 附加了 button 可视化器，call_function() 可用于按下它。编译错误不会抛出异常， 而是连同行号和列号放入 diagnostics，以便显示在编辑器中。

说到编辑器：17.18.0 引入的 Frida.LanguageServer API 现在也支持 .hexpat 和 .pat 文档，提供诊断、补全、悬停信息、文档符号、折叠范围、语义 token、跳转到定义， 以及 [[color]] 属性的色板。补全功能了解 std 库和可视化器名称。编写导入模式的 TypeScript agent 时，生成的声明还会免费带来字段补全。

Luma

在即将发布的版本中，Frida 官方 GUI Luma 已经用上了上述所有功能。Luma 的侧边栏 新增 Patterns 区域，用于存放模式和共享库，并配有语言服务器支持的编辑器：

每个文件展开后都会显示它声明的类型，因此可以直接跳转到结构体。无论十六进制视图来自 内存洞察还是 REPL hexdump，都会获得“Decode at … as…”上下文菜单，其中列出模式库中的 类型。选择一种类型后，各字段对应的字节会亮起彩色轮廓，旁边的树则显示名称、类型和值。 单击某个字节会选中它所属的字段，选择字段则会将十六进制视图滚动到对应位置。下面是直接 从运行中进程解码出的 Mach-O 头：

真正有趣的是可视化器。模式语言允许给字段附加可视化器，例如图像、折线图、3D 模型、 地图坐标、音频采样、时间戳、以数字信号显示的位域或反汇编，而 Luma 会将它们渲染出来：

由于 Luma 的 REPL、自定义仪器和 tracer hook 都通过 Frida.Compiler 编译，它们会获得与 上面所写 agent 相同的能力：导入一个模式，即可得到实时视图、用于扫描的 pattern()、 支持完整语言的 parse()，以及输入时的字段补全。

结语

本次发布还有许多其他变更，务必查看下面的变更日志。

尽情享用吧！

变更日志

• compiler：添加 ImHex 模式语言支持。（上文已详细介绍。）
• gumjs：允许 NativePointer 的读写操作接收可选偏移量，例如 p.readU32(4)，从而无需 为字段地址分配 NativePointer 即可访问字段。生成的模式视图底层也采用这种方式。
• gumjs：让 writeVolatile() 返回指针，以便与其他写入方法保持一致。
• api-resolver：当导出查询是字面量前缀加末尾通配符（如 exports:*!pthread_*）时，沿 Darwin 导出 trie 向下查找，而不再枚举每个匹配 模块的所有导出。在加载 676 个模块时，243 次此类查询从 35 秒缩短到 65 毫秒。 感谢 @hsorbo！
• swift-api-resolver：使用 Swift 进程中始终存在的 libswiftCore 所提供的 swift_demangle() 进行反修饰，不再使用通常未加载的 libswiftDemangle。解析过程 也改为延迟执行，因此 libswiftCore 加载后解析器便会开始工作。感谢 @hsorbo！
• arm64：限制重定位器的可达性扫描。此前每个块都会重置 1024 字节预算，导致扫描无限 跟随分支目标；在 Android 上，这会让挂钩分支繁多的代码时，每个目标耗费数百毫秒。
• exceptor：不再在每次 try 时保存信号掩码；这一步并非必需，却会让每次尝试产生一次 系统调用。
• payload：修复 Android agent 加载时崩溃的问题。原因是模块注册表在 libc shim 建立 stdio 注册表之前读取了 /proc/self/auxv。
• barebone：将 macOS Android 模拟器提升为一等目标。shim 已重写为 CModule，使热路径 能够无锁运行；现在会恢复所有核心、将寄存器直接推送到 vcpu、处理被捕获的调试寄存器 访问而不再中止虚拟机，并在原生层过滤空闲调度器命中。现在也可以枚举和启动应用。
• barebone：将 agent 注入 SMP arm64 Linux；在 Linux 上报告线程状态和寄存器；根据 cmdline 命名 Linux 进程；并避免将 arm64 副本放在大页上。
• linux-kernel-image：从 32 位内核和 VA_BITS=48 的 arm64 内核中提取 kallsyms， 包括长度超过 80 个字符的 Rust 符号名。
• barebone：修复不带 Droidy 后端时的构建，以及 32 位 Arm 构建。
• base：不在 API 中暴露 Posix 类型，使 frida-base 使用者不再需要 posix.vapi。
• compiler：在 Windows 上使用 cgo 构建时优先选择 UCRT64，并针对每种 flavor 探测 MinGW 编译器。
• node：转义参数名中的保留字，并将从对象构造的 options 中的 GValue 清零。
• python：将 null variant 编组为 None。
• swift：绑定模式编译器类型以及 variant、列表和字典；释放拥有所有权的返回值； 并使用其 C 类型声明 out 参数，使 UInt64 out 参数能在 LP64 Linux 上编译。

本次发布将 Frida 带到了 PlayStation 5，扩展了 Barebone 对虚拟机和内核的覆盖范围， 并修复了一系列注入和插桩问题。

• prospero：添加 PS5 后端，并提供 frida-server、portal、inject、Gadget 和 devkit 的构建版本。 在游戏机的限制范围内，该后端可以枚举应用、启动程序和应用，以及注入代理。
• barebone：添加对 Android 模拟器的支持。内核符号发现现在可以处理更多 Linux 映像和旧版内核， 新增的 hostlink 选项则包括基于 vsock 的管道和串行连接。
• barebone：将 WinNT 支持扩展到 arm64，包括进程注入，并添加对 VirtualBox 和 Parallels 客户机的支持。大量修复提升了代理在 Windows 和 Linux 内核上的可靠性。
• device：添加连接进度事件，使应用可以在设备连接或上传 Barebone 代理时显示 Frida 正在执行的操作。 绑定中也提供了这些新信号。
• fruity：修复 macOS 27 上的 RSD 端口发现；找不到新发布的服务时会刷新服务快照。 新增的 force_transport=usbmux 通道选项允许调用方即使在隧道可用时也选择 usbmux。 感谢 @mrmacete 提供该选项。
• darwin：修复 iOS 27 上的注入泄漏；该问题可能导致每次附加后都保留一个 40 MB 的代理 blob。 同时改进内存保护处理，并在放宽策略期间保持暂停状态。感谢 @jiska 完成这些修复。
• gum：改进 arm64 重定位以及 Interceptor 对函数序言的处理，包括 X16 和 X17 同时被占用的情况。 Grafting 现在使用 Arm64Relocator，从而可以重定位 PC 相对指令。感谢 @jiska 和 @daniillnull 在这方面所做的工作。
• interceptor：跟踪与每个帧关联的 C 栈，改进对有栈协程的处理。感谢 @wertyutreethgfd 的贡献。
• linux：在内核辅助注入后回收临时栈和 TLS 映射，并在代理卸载时释放加载器区域。 读取辅助向量中的程序头之前先进行验证，修复 Wine 预加载器暴露出来的问题。 感谢 @tntljc 完成后一项修复。
• socket：处理对等端在 WebSocket 握手与接受连接之间断开的情况，避免中止进程。 感谢 @it4ch1-007 完成该修复。
• darwin：在可用时使用越狱环境提供的内存挂钩。感谢 @devnoname120 的贡献。
• gdb：改进线程选择、超时和停止处理，并增强与不支持二进制写入的存根的兼容性。

此外还修复了 Windows 中通过 Interceptor 跳板进行栈展开的问题、Swift 事件传递和变体生命周期问题、 生成的绑定问题，以及各种平台特定的构建问题。

Frida 17.18.0 已经发布，Barebone 也向前迈出了一大步。XNU agent 现在可作为 macOS 内核扩展加载；Linux agent 获得了更广泛的体系结构支持，并能访问内核自身的类型信息；后端还能在 Linux、XNU、Windows NT 乃至 Windows 9x 上同时为内核本身和用户态进程插桩。我们还将 Frida.Compiler 升级到 TypeScript 7.0，并新增配套的 Frida.LanguageServer API。

一项令人兴奋的新功能是能够把 XNU agent 构建为 .kext。以前，要让它进入内核，必须通过兼容 GDB 的远程 stub（例如 QEMU 的 stub）从外部注入，或使用 JTAG/SWD 硬件调试器。现在 macOS 可以自行加载 agent，/dev/frida 则提供配置和通信通道。这为使用 Frida 进行内核插桩开辟了另一种方式。kext 目前支持内核侧；要在用户进程中放置 agent 副本，仍需使用注入式 XNU agent。

本版本的 Barebone 还有更多内容。注入式 agent 现在把熟悉的 Frida 工作流带入客户机进程：枚举进程、附加、运行脚本、挂钩函数，以及在程序开始运行前就完成插桩并启动它。相关工作覆盖 Linux、XNU、两种字长的 Windows NT，以及 32 位 Windows 9x。Linux agent 注入现在支持 x86、x86-64、Arm 和 Arm64；Linux agent 既可注入运行中的内核，也可作为内核模块加载。

在 Linux 上，脚本现在可以发现已加载的内核模块及其符号，模块注册表会跟踪驱动的加载与卸载。新的 Btf 命名空间还允许脚本在可用时查询内核的 BTF 类型信息。结构体大小、字段偏移与类型、枚举、常量和函数签名都可直接从 JavaScript 获取。例如：

if (Btf.available) {
  const module = Btf.getStruct('module');
  console.log('struct module size:', module.size);
  console.log('name offset:', module.getOffsetOf('name'));
  console.log('name field:', JSON.stringify(module.fields.name));
  console.log('MODULE_STATE_LIVE:', Btf.getConstant('MODULE_STATE_LIVE'));
}

这意味着脚本可以询问内核其结构体如何布局，避免使用绑定到特定构建的硬编码偏移。底层是一个新的 GumJS 原生 API 注册表，使嵌入方能够独立于所用 JavaScript 运行时公开原生函数命名空间。

与此同时，Frida.Compiler 已升级到 TypeScript 7.0。新的 Frida.LanguageServer API 将同一编译器的语言服务带给嵌入 Frida 的工具。它为 TypeScript 和 JavaScript 项目实现 Language Server Protocol：可以为项目目录创建并启动服务器，通过 post() 发送 JSON-RPC 消息，再通过 message 信号接收回复和通知。这样便可结合 Frida 内置的类型定义和编译器配置，集成代码补全等编辑器功能。编译器和语言服务器还共享解析缓存，因此相同文件内容无需分别解析。

其他亮点和修复：

• barebone：添加用于增删 Barebone 设备的公共 API，ID、名称和图标由调用方提供。公开注入式和常驻 agent 的配置，包括显式 hostlink 地址。
• barebone：为 Linux、XNU 和 Windows agent 添加进程启动和启动门控；在 XNU 和 Windows 上添加应用枚举，并在 XNU 上添加应用启动。
• barebone：改进模块和线程观察、故障恢复、进程清理，以及对 agent 自身线程和映射的隐藏。
• barebone：改进各 agent 的传输交付和唤醒，包括大消息和二进制脚本消息载荷。会话分离时保持常驻 agent 存活。
• barebone：通过可写别名添加 XNU 内核文本修补，并改进内核边界处的代码分配和指针认证。
• barebone：从 kallsyms 和导出表公开 Linux 内核模块符号，并在清理期间注销 API 和模块观察器。
• barebone：将 Linux 内存操作移入客户机，正确处理可写与可执行映射。把重映射和修补扩展到 x86、x86-64、Arm 和 Arm64。
• barebone：访问 QEMU 物理内存模式时暂停客户机，并修复影子页源自 Linux 线性映射时内核文本补丁被静默丢弃的问题。
• barebone：在内核空间放置 x86 别名，修复 CModule 访问其数据时的故障。允许虚拟内存扫描跨越多个叶表。
• barebone：添加 Arm 地址转换和内核空间别名，扩宽 32 位重映射请求中的页地址，并直接刷新 Arm 指令缓存，而不是尝试从内核发起用户空间系统调用。
• barebone：向 JavaScript 运行时报告实际可用栈空间，防止普通脚本递归溢出 Linux 内核栈。
• barebone：使用 _end 确定 Linux 内核大小，避免无关映射使 32 位内核看起来大出数 GB。通过 GumElfModule 读取复制的内核映像，不解引用指向实时内核的指针。
• barebone：修复并完善 Linux 内核模块构建，包括构造函数数组边界和特定变体的运行时依赖。
• linux：加载 Frida 内核模块时添加内核辅助注入；模块不存在时回退到现有注入路径。
• gdb：内存写入使用二进制数据包，并遵循目标寄存器大小。
• interceptor：修复可写视图和可执行视图使用不同映射时 Arm trampoline 的寻址。
• memory：查找指针时跳过坏页。感谢 @IPMegladon！
• memory：允许扫描模式边缘使用通配符，包括 Barebone。感谢 @Xoffio！
• arm64：没有可用着陆垫时避免 BTI。感谢 @inforcqb！
• arm64：检测进入正在重定位指令的分支，使 Interceptor 能选择更小的重定向，避免分支进入已覆盖代码并崩溃。感谢 @WHW0x455！
• cmodule：将 CModule 从 GumJS 移入 Gum，使其可独立于 JavaScript 绑定使用。感谢 @cputnam-a11y！
• elf-module：从文件读取程序头，修复程序头被 patchelf 等工具移动的模块；仅有实时映射可用时限制后备读取范围。感谢 @tracyliving！
• windows：调整 ACL 以提高注入成功率。感谢 @jamiechapmanbrn！
• python：修复 Python 3.11 之前版本的 typing 导入。
• ci：构建 XNU 内核扩展、额外 Linux agent 和所需 Barebone SDK 与 devkit。在 Android 上启用 Barebone 后端。
• deps：精简 Barebone SDK 中的 Capstone，将归档从约 29 MB 减至 4.4 MB。允许独立式 GLib 构建使用 C 库较小的 printf 实现，并精简区域设置和文件名转换支持。
• deps：优化 QuickJS 以减少栈消耗，并调整 GLib 以减小 Barebone 场景中的体积。

这是一个包含大量裸机好料的大版本。Barebone agent 使用 Rust 编写并嵌入 GumJS devkit， 之前只支持 XNU。现在它也能运行在 Linux 内核中，由一个小型 C shim 提供内核粘合层。

agent 被打包为 .ko：使用 insmod 加载，然后通过 /dev/frida 交换带长度前缀的 GVariant 消息。 将 Barebone 后端配置为使用该传输，并在设备上运行 frida-server --device=barebone。 下图是它在我的 Pixel 6 Pro 上运行的样子：

为你的设备构建模块

发布页面提供了面向 none-arm64-softfloat 目标的 GumJS devkit。你不需要自行构建 Gum。 下面的步骤将为 Pixel 6 Pro 制作 frida-agent.ko。其他 arm64 Linux 系统使用相同步骤，只需换用不同内核。

请在 x86-64 Linux 主机上完成构建。内核构建树中包含 x86-64 程序。

1. 安装工具：

   sudo apt-get install build-essential clang binutils-aarch64-linux-gnu
   rustup target add aarch64-unknown-none
   rustup component add rust-src
   

   clang 必须为 19 或更高版本。GCC 未实现软浮点 ABI。

2. 下载源码：

   git clone --recurse-submodules https://github.com/frida/frida-core.git
   cd frida-core
   

3. 下载 devkit：

   version=17.17.0
   base=https://github.com/frida/frida/releases/download/$version
   curl -LO $base/frida-gumjs-devkit-$version-none-arm64-softfloat.tar.xz
   mkdir -p ~/gumjs-devkit
   tar -C ~/gumjs-devkit -xf frida-gumjs-devkit-$version-none-arm64-softfloat.tar.xz
   

4. 下载 SDK：

   releng/deps.py sync sdk none-arm64-softfloat_nopic ~/sdk-none-arm64-softfloat_nopic
   

   SDK 包含 picolibc 和 compiler-rt builtins。devkit 需要它们。

5. 从设备读取内核版本：

   adb shell uname -r
   6.1.145-android14-11-gc1de4747ac59-ab14219743
   

   名称以 GKI commit 和构建号结尾。这里的 commit 是 c1de4747ac59，构建号是 14219743。

6. 下载内核文件：

   commit=c1de4747ac59
   build=14219743
   ci=https://ci.android.com/builds/submitted/$build/kernel_aarch64/latest/raw
   mkdir -p ~/kernel-prepared ~/kernel-source
   curl -sSL $ci/modules_prepare_outdir.tar.gz | tar -xz -C ~/kernel-prepared
   curl -sSL $ci/kernel_aarch64_Module.symvers -o ~/kernel-prepared/Module.symvers
   curl -sSL https://android.googlesource.com/kernel/common/+archive/$commit.tar.gz \
       | tar -xz -C ~/kernel-source
   

7. 构建模块：

   make -C src/barebone/agent/linux \
       FRIDA_SDK=$HOME/sdk-none-arm64-softfloat_nopic \
       GUMJS_DEVKIT_DIR=$HOME/gumjs-devkit \
       AGENT_LD=aarch64-linux-gnu-ld \
       AGENT_AR=aarch64-linux-gnu-ar \
       AGENT_NM=aarch64-linux-gnu-nm \
       AGENT_OBJCOPY=aarch64-linux-gnu-objcopy \
       KDIR=$HOME/kernel-source \
       KOUT=$HOME/kernel-prepared \
       LLVM=1
   

8. 加载模块：

   adb push src/barebone/agent/linux/frida-agent.ko /data/local/tmp/
   adb shell su -c 'insmod /data/local/tmp/frida-agent.ko'
   

该模块只能加载到与构建时完全相同的内核上。内核会精确比较版本字符串。即便是同一内核分支的不同构建也无法工作。

更多信息请阅读module README。

完整更改日志：

• gumjs：修复 JS 内部的原生故障被后续处理器恢复后，分离时挂起的问题。 现在当线程存活时，我们会重新平衡 Interceptor 事务，而不是将其结束两次。感谢 @pandasauce 报告此问题并帮助追查。
• arm64：检测跳入正在重定位的范围的分支，防止 Interceptor 重写某个分支后，使其落在自身重定向补丁中间。 感谢 @WHW0x455 提供此修复。
• python：修复 attach() 的 linker_notifier_offsets 关键字参数，恢复 Script.enable_debugger() 的默认端口，并恢复对远程设备和相关 API 的证书选项进行编组。
• barebone：支持将 agent 作为 Linux 内核模块运行。agent 现在以 .ko 形式在目标内部启动， 暴露用于传输的字符设备，并可通过普通的 frida-server --device=barebone 实例访问。
• deps：添加一个由 picolibc 和 compiler-rt 组成的软浮点裸机 SDK。这为 none-arm64-softfloat 变体提供了在通用寄存器中传递浮点值方面保持一致的 libc 和运行时。
• deps：在 CI 中构建软浮点 SDK，在花时间安装工具链之前检查已发布的 bundle，将 libc 头文件排除在 devkit 头文件外， 使用 SDK 作为 sysroot，并确保配置时的链接检查能正确解析 libc。
• deps：升级 GLib、libffi 和 QuickJS，以获得 freestanding 修复、向量汇编器指令修复、优先级爬升解析器和相应的 x18 修复。
• arm64：在软浮点目标上，通过为 memcpy、指针扫描和 Interceptor 的寄存器重排使用标量回退，避免 FP 和 SIMD 代码。
• gumjs：在裸机上限制 QuickJS 栈，重新启用其栈检查，使解析器在耗尽这类主机可能提供的小栈之前停止。

这是一个快速错误修复版本，用于恢复近期 bindgen 重写中发生回归的部分 Python 绑定 API 和类型定义范围：

• bindgen：恢复其余公共名称。cancellable 装饰器、RPCResult、make_rpc_call_request()、make_auth_callback() 和 ScriptExportsAsync 现在重新从 frida.core 公开。
• bindgen：为 facade 的 on()/off() 辅助函数生成信号回调重载。这意味着格式错误的信号处理程序现在会被类型检查器捕获，而不是悄悄地被当作任意可调用对象放行。
• bindgen：恢复基于 .gir 的生成器遗漏的 facade 成员：get_device()、get_device_matching()、enumerate_devices()、shutdown()、Cancellable.connect() 和 Cancellable.disconnect()。
• bindgen：恢复 facade 的类型定义范围。生成的软件包再次附带预期的类型别名和注解，包括模块函数、只读选项属性，以及此前缺失的 _frida.pyi 条目。

又一次快速错误修复版本，解决 Python 绑定中的两个问题：

• bindgen：修复可选关键字参数的编组。现在会省略 None 值，而不是将其传给带类型的 setter。
• bindgen：修复集合值关键字参数；遍历父链时，会将它们映射到适当的 select_ 或 add_ 方法。这会影响 specs、omits、externals、PID 和 identifiers。

又一个快速错误修复版本，修复 Darwin 和 Linux 上的 frida-helper 会让嵌入方 stdio 管道保持打开的问题。

此前 helper 会在启动时继承这些流，以便之后供 Device#spawn() 配合 stdio='inherit' 使用。现在，这些流会随每个此类请求传给 helper。

• darwin：将 helper 自身的 stdin、stdout 和 stderr 重定向到 /dev/null。
• linux：应用与 Darwin 相同的修复。

这是一次快速的错误修复版本，包含两项以 Darwin 为重点的修复：

• apple：不再强制使用经典链接器。这是针对 Xcode 15.0 beta 7 问题的临时方案，当时现代链接器会过度链接 libresolv。现代链接器已不再这样做，而 ld-classic 会遗漏 __DATA_CONST 上的 SG_READ_ONLY，导致较新的 dyld 拒绝我们的映像。
• darwin：将 CodeSegment 限制到旧内核。恢复后的签名 dylib realize 路径会让现代 XNU 接受我们的签名并映射页面，随后可能在 iOS 15.6.1 及更高版本上触发内核恐慌。现代内核现在会回退到 mprotect，并像以前一样暂停线程；需要该路径的旧越狱内核仍可使用签名段路径。

这次是一个大型版本，包含安全加固、平台修复和多项 API 打磨。非常感谢 @hsorbo 和 @SamSunNV 的贡献。

主要变化包括：

• spawn-gating：使其具备故障安全能力并限定作用域。系统级 Linux eBPF spawn gater 现在需通过新的 SpawnGatingScope 显式启用；所有会挂起进程的 gater 共享一个看门狗，若捕获的进程挂起过久，就禁用 gating 并恢复全部进程。这样可避免客户端消失或停止恢复 spawn 时卡死全系统的进程创建。
• spawn-gating：在 HostSession 上新增 spawn_gating_disabled(reason) 信号并向上传递到 Device，使客户端知道看门狗何时介入。
• python：根据 Frida GIR 自动生成 Python 绑定，并通过新的 frida.aio 包支持 asyncio。
• swift：根据 Frida GIR 自动生成 Swift 绑定。
• auth：关闭认证通道前刷新待发送的 INVALID_ARGUMENT 回复，使客户端可靠看到令牌被拒绝，而不是连接直接关闭。
• fruity：在执行 threaded 和 chained fixup 前应用各段保护，修复 arm64e 上的上传注入。可写数据段因此能无故障地接收重定位和认证后的指针，同时仍避免任何 rwx 映射。感谢 @hsorbo！
• darwin：生成带 exec-segment 字段和非空标识符的现代 SHA-256 CodeDirectory，使现代 iOS 重新支持 CodeSegment 实现。实现会先探测现代形式，必要时回退到旧形式，并缓存可用策略。
• darwin：通过修补暂存页面在运行时探测 CodeSegment 支持，不再依赖 XNU 版本猜测这种因内核而异的行为。
• gumjs：在 iOS 上避开 macOS 专用 MAP_JIT 路径，改用 Gum 自身的 JIT 分配路径，使 V8 能在 iOS 应用沙箱内执行 JIT。
• darwin：在 add-image 桩经 resident notifier handler 指针跳转前为其签名，修复 arm64e attach 崩溃。
• darwin-mapper：对 threaded bind 跳过存储；解析后的目标已位于链处理器符号表中，而默认段/偏移可能指向只读 __TEXT。感谢 @hsorbo！
• arm64-writer：新增 PACIA 和 MOVK 指令生成器，可用于内联签名指针和在生成代码中构建 ptrauth discriminator。感谢 @hsorbo！
• x86：在 Stalker 中保留 AVX-512 状态。在 AVX-512 主机上保存并恢复 zmm0-15 的上半部分、zmm16-31 和 k0-k7 opmask 寄存器，修复跟踪使用 EVEX 的 libc 例程时的崩溃。
• x86：新增 AVX-512 CPU 特性检测，以及 Stalker 保存寄存器所需的 writer 生成器。
• x86：在 CpuContext 中公开 XMM 寄存器；可用时以实时保存区为后端，并新增 gum_cpu_context_copy() 和 boxed 类型以安全持久化。感谢 @hsorbo 带来的愉快协作！
• interceptor：模块卸载时丢弃 Hook，不再尝试恢复已取消映射内存中的函数序言。感谢 @SamSunNV！
• module-registry：修复程序头未映射在 ELF 头旁边的模块（如 libgit2）的 ELF 范围计算。尽可能根据程序头计算，仅在必要时回退到 /proc/self/maps。
• memory：完成内部调用方到 gum_memory_allocate() 和 gum_memory_free() 的迁移，并移除旧 gum_alloc_n_pages() 系列。
• windows：展开 <arch>、在各架构目录中查找辅助程序，并由管理器生成唯一 rendezvous 名称传给所有辅助服务，以修复已安装资源中的辅助程序发现。
• windows：改进 MSVC 交叉构建：保持 arm64->x86 构建为交叉构建；各编译器使用自己的 include 和库路径；为原生构建机工具保留环境中的 INCLUDE/LIB。
• build：通过新的 glib.wrap 预先解析 GLib；根据 GLib 变体确定树内载荷；为交叉构建配置原生语言；避免把父构建机选项转发到 compat 构建。
• deps：使用当前 GitHub Actions Xcode 重建预构建包，采用更新后的 arm64e ABI。
• compiler/barebone：将 @types/frida-gum 升级到 19.10.0。
• tests：字节码测试在丢弃最后一个引用前先卸载脚本，修复负载下偶发的拆卸竞态。感谢 @hsorbo！

这是一个快速错误修复版本，包含 @dezige131 提供的 Android 修复，以及 @hsorbo 提供的多项 Darwin 和 Gum.Memory 改进：

• android：当目标进程未映射启动映像时，容忍暂时性的 USAP 补丁未命中。
• darwin：在较新的内核上重新启用 CodeSegment。vm_remap 的 OVERWRITE 技巧在 iOS 17.6 及更高版本上再次有效，因此可重新启用 CodeSegment。
• memory：修复 patch_code 中的挂起死锁。现在先在暂存缓冲区准备补丁，使 apply 回调能在挂起其他线程并无锁复制回原处之前自由分配内存。
• memory：提高 patch_code 在并发和失败情况下的安全性。提交任何字节前先将全部目标页面设为可写；只复制已修改的字节；刷新指令缓存前将页面恢复为 RX。
• memory：把三种补丁策略提取到各自的辅助函数中，在不改变行为的情况下简化分派器。

这个快速发布的版本带来了几项实用改进：

• gumjs：添加 Checksum copy 和 peek 方法。感谢 @mrmacete！
• defs：添加对 Capstone 6 的支持。感谢 @kripticni！
• darwin-symbolicator：补上缺失的锁，并在跳转到清理流程前初始化模块。 感谢 @comex！
• qml：在较新的 clang 上抑制 Qt __yield 错误。
• barebone、compiler：将 @types/frida-gum 升级到 19.8.0。
• 将 FridaCore 升级到 17.15.3。

这是一次快速的错误修复版本，于当天晚些时候发布，因为软件开发很难，而且它显然很喜欢提醒我们这一点。

• darwin：在激活 interceptor 前填充模块注册表。第一次 gum_interceptor_obtain() 会激活 unwind broker，其后端通过模块注册表解析 libdyld。在获取初始快照前这样做，可能重新进入空注册表，并在查询 NULL 模块时崩溃。现在会先为模块生成快照，再开始跟踪变更。

这是一个快速错误修复版本，包含 @wave-sky 针对 Android 10 上生成进程的修复：

• linux：修复 Android 10 上的载荷基址选择。由于 Android 的 XOM 机制使 libstagefright.so 仅可执行，生成进程可能因远程连接错误而失败。现在选择目标库时 不再要求读取权限，同时会考虑更多媒体共享库，并强制设置读取与执行权限，以便载荷运行。

这是一个快速错误修复版本，包含以下修复：

• darwin：修复非 arm64e 构建中的未使用变量警告。
• linux：修复涉及多个 GumModuleRegistry 实例时 musl RTLD 调用点的发现逻辑。现在改为扫描链接器的磁盘镜像而非实时内存，从而保留原始指令，并允许链式拦截器挂钩相同的已加载地址。

是时候发布新版本了，本次在 Gum 和我们的动态链接器集成中带来了一些令人兴奋的改进：

• gumjs：添加 Process.getThreadById() 和 Process.findThreadById()，底层由新的原生 find_thread_by_id() API 支持，可按 ID 查找单个线程，无需枚举所有线程。
• gumjs：添加 Process.getFunctionRange()，这是一个便捷包装器，与现有 findFunctionRange() 匹配，它会抛出异常而不是返回 null。
• gumjs：修复附加线程观察器时的线程枚举死锁。现在我们会在执行原生枚举时释放 JS 运行时锁，并在之后构建 JS 对象。
• gumjs：将剩余通过字符串拼接生成的查找错误现代化为模板字符串。
• darwin：重做现代 dyld 的模块观察。近期 dyld 会在受保护栈上持有加载器写锁时调用其映像加载通知器，这意味着观察器无法安全地回调 dyld。我们现在为 FULL teardown 使用常驻的 _dyld_register_func_for_add_image() trampoline，在脱离写锁的普通栈上交付，并挂钩 RuntimeState::decDlRefCount 以处理移除。
• darwin：无需 dlopen() 即可解析模块导出。这避免在 dyld 仍在加载映像时强制运行模块初始化器，包括 Objective-C +load。
• linux：修复 musl RTLD 通知器挂钩。我们不再内联挂钩只有一条指令的 _dl_debug_state stub 并破坏后续的 __dl_seterr，而是挂钩链接器的调用点。
• ci：将 GitHub Actions 的使用从已弃用的 Node.js 20 运行时上迁移。
• barebone, compiler：将 @types/frida-gum 升级到 19.7.0。

这是一个修复 GumJS 问题的快速错误修复版本：

• gumjs：修复 ControlFlowGraph.toJSON() 中的栈溢出。序列化循环块图时会无限 递归，因为 BasicBlock.toJSON() 会将 successors、predecessors 和 immediateDominator 生成为新的 BasicBlock 对象。这意味着 JSON 基于对象身份的 循环检测始终不会触发，最终导致原生栈溢出。现在相邻块改为以起始地址表示， 而顶层仍会完整列出各个块。

今天发布的版本旨在降低失控脚本带来的风险。衷心感谢 @tpetsas 提交最初的 Gum PR，推动了这项工作。

• script：添加 Script.interrupt()，它会中止当前正在执行的任何 JavaScript， 同时让脚本保持加载并可再次运行。这对于希望通过 Ctrl+C 从失控求值中恢复的 REPL 尤其方便。在没有代码执行时进行中断不会产生任何效果，因此操作刚结束后 到达的 Ctrl+C 不会干扰下一个操作。
• script：添加 Script.terminate()，它会中断执行并卸载脚本，因此陷入长时间 运行或无限操作的脚本仍可被彻底清理。
• gumjs：为 QuickJS 和 V8 实现中断与终止支持。QuickJS 现在会轮询每个脚本的 中断标志，而 V8 使用 Isolate::TerminateExecution()，并在执行展开后清除 粘滞的终止状态。
• core：通过 AgentSession、载荷脚本引擎和公共 Script 类接通新 API。 Barebone 会话会将这些操作报告为不受支持。
• core：从 enumerate_processes() 以 metadata 范围公开进程 argv，与 path 一致，而不再将其限制在 full 范围。

又到了发布新版 Frida 的时候，本版本带来了一些 API 和内省方面的改进：

• core：向枚举到的进程参数添加 argv。请求完整范围时，Frida 现在会在 Windows、macOS、Linux 和 FreeBSD 上公开目标进程的命令行参数。
• swift：通过类型化访问器公开新的 argv 进程参数；后端提供此参数时，返回目标的命令行参数。
• gumjs：为 ControlFlowGraph 及相关类添加 toJSON() 支持，使它们传给 JSON.stringify() 时能得到良好呈现。
• gir：在合成的文档中输出文件名和行信息，便于将生成的 API 文档追溯到源代码。

新版本带来了 Gum/GumJS 中全新的代码形态分析工具箱、大量 Linux 注入器 加固与清理修复、大幅提升 Windows arm64 稳定性的工作，以及 Gum 和 Core 各处已有文档说明的公共 API。

亮点：

• gum：添加原生控制流图模块，包括基于解析器的图构建、 Cooper-Harvey-Kennedy 支配节点算法，以及按最近优先顺序枚举支配位置。
• gumjs：添加 ControlFlowGraph 和 BasicBlock。
• gum：添加 Process.find_function_range()。它不需要符号，因此也适用于 已剥离符号的二进制文件。
• gumjs：添加 Process.findFunctionRange()。
• interceptor：添加按函数和按监听器刷新，使调用方能够等待自己的 Hook 排空，而不会被无关的待处理工作阻塞。
• linux：当采样 PC 落在很小的系统调用包装函数中时，通过遍历栈来寻找 可 Hook 的触发点，从而提高多线程目标中的注入器可靠性。
• linux：通过 /proc/<pid>/fd 而不是 /proc/self/fd 加载 agent， 使附加的调试器解析出的对象路径与目标进程一致。
• linux：以与安装对称的方式恢复被修补的触发函数，避免另一个线程执行 写入到一半的序言时产生竞态。
• linux：捕获 libbpf 诊断信息并将其包含在抛出的错误中，不再泄漏到 stderr。
• linux：使用实际的 bootstrap stub 确定触发候选项大小，避免无谓拒绝 体积较小但频繁执行的 libc 例程。
• linux：当缺少权限导致 eBPF/perf 采样不可用时，回退为轮询 /proc/<pid>/task/<tid>/syscall。
• linux：在清理时排空线程注册表，修复卸载期间线程频繁变化所导致的 use-after-free。
• linux：使用新的 CFG 机制重定位 start_thread Hook，使 Hook 落在安全的 支配指令上，而不是覆盖仍在使用的调用位置。
• linux：通过反复进行锚点探测和锁交叉检查，直到两者结果一致，增强高频线程 变化情况下的 pthread 布局检测。
• x86：使 can_relocate() 能够感知重定位场景，拒绝那些必须跨越调用或 类系统调用指令的在线重定位。
• meson：构建捆绑的 Capstone 时启用所有架构，与预构建 SDK 保持一致， 让跨架构反汇编随处可用。
• stalker：修复代码 slab 相距超过 128 MB 时远距离 backpatch 尾声丢失 BL 的问题；该问题会破坏栈并导致崩溃，在 Windows arm64 的宽广地址空间中暴露。
• stalker：检测 Windows 上的线程退出，从而不再跟踪正在终止的线程进入 ntdll 的清理流程。
• exceptor：在 Windows arm64 上通过 RtlRestoreContext() 而不是 longjmp() 恢复执行，修复崩溃恢复；后者的栈展开会拒绝我们的合成帧并终止进程。
• gdb：修复 iOS debugserver 等 LLDB stub 上的寄存器访问；此前会表现为 “Failed to attach: invalid integer value: E03”。
• gum：为公共 API 编写文档：Interceptor、Stalker、Exceptor、Module、 ModuleMap、ModuleRegistry、MemoryMap、MemoryAccessMonitor 和 DarwinGrafter。
• core：为公共 API 编写文档，并将 Vala 文档注释注入 GIR。
• ci：发布 GObject 内省数据。
• ci：添加 windows-arm64 原生任务。
• barebone/compiler：将 @types/frida-gum 升级到 19.6.0。

这是一个内容丰富的版本，重点是让 Frida 进入更棘手的环境，并投入大量精力改进 Barebone 后端、Linux 注入路径和 Gum 底层机制。感谢 @hsorbo 与我们共同度过愉快的 iOS 内核黑客松，并提交增加 Segger J-Link 支持的 PR；也感谢 @ltlly 对 Stalker 的贡献。

主要变化：

• linux：为 ptrace 槽已被其他跟踪器占用的目标新增无 ptrace 注入后备方案。Frida 会改用 /proc/$pid/mem，把引导代码写入目标以映射并运行加载器，支持 x86、x86_64 和 arm64。对于从不调用 malloc 的安静目标，Frida 会采样 CPU 活动，解析最热的 libc 叶函数并改在该处 Hook。
• barebone：Virtualization framework 客体的内核内插桩取得重大进展，包括 VZ 内核 GDB 桩客户端、物理内存桥接、fileset kernelcache 和 kext 处理、按段重定位，以及通过主机修补内核文本。
• barebone：通过 vsock 建立内核内 hostlink，包括 PAC 签名回调和异步连接处理。W^X 操作现在通过 RPC 完成，使 NativeCallback、Interceptor、Memory.patchCode() 等无需依赖会让研究内核 panic 的 BRK 回调。
• barebone：让 Interceptor 和 Stalker 在内核中工作，包括经物理桥接实现可写重映射、修改页表后刷新 TLB、从 Stalker 排除 Agent 自身范围，以及让线程 ID 可安全地经 JavaScript 往返。
• barebone：提升内核注入稳健性。Agent 就位后分离调试桩；调用函数时容忍线程迁移；从缓存 MMU 参数查询页面大小；就近分配失败时返回 NULL 而不是 panic。
• barebone：为 none-arm64 资源、devkit 和 Barebone Agent 添加 CI。
• barebone：省略 Arm64 向量上下文，避免溢出狭小的内核栈。
• gdb：改进远程桩兼容性。缺少 g/G 时回退到逐寄存器访问；检测 vCont 支持并提供后备；接受空 qRcmd 回复；按 qXfer 支持加载目标属性；访问寄存器前切换线程；始终发送正确校验和。感谢 @hsorbo！
• compiler：修复归档符号重命名。现在只在字符串表中重写符号，而不是匹配整个归档中的字节；同时更新归档索引，使 COFF 归档重命名后仍能正确链接。
• module：为 GumExportDetails 新增 size，通过 QuickJS 和 V8 中的 enumerateExports() 公开导出大小。ELF 报告 st_size；无法提供信息的平台报告 -1。
• memory：在 Linux 6.11 及更高版本使用 PROCMAP_QUERY ioctl 加速保护查询，并缓存回退到解析 /proc/self/maps。让代码可读时也会保留页面保护，并共享旧版 manylinux 工具链所需的 O_CLOEXEC 后备。
• stalker：在 Arm 和 Arm64 后端为待处理字面量预留空间，使每条指令都带 callout 的大型无分支代码块不再溢出 slab 并破坏相邻内存。感谢 @ltlly！
• process：限制 aarch64 ucontext 记录遍历，避免畸形记录或 libunwind 较小的上下文布局让回溯器崩溃。
• vapi：新增 X86Writer 绑定，使 Vala 代码能生成 x86 和 x86_64 指令，与现有 Arm64Writer 支持一致。

这是一个错误修复版本，其中还加入了一个崭新的内存扫描辅助函数，以及一些 Darwin、Android 和构建系统修复。非常感谢 @cylentsec 和 @AeonLucid 的贡献。

• darwin：在 launchd 代理中支持 ElleKit/palera1n。现在会检测 ElleKit 的注入器门函数， 并让它对 Frida 管理的 PID 返回 false，从而防止已启动进程遭到重复注入。感谢 @cylentsec！
• darwin：恢复选择性异常掩码，并将非断点异常转发给系统处理程序，同时保持现有 arm64e PAC 修正路径有效，以此修复 ElleKit 的进程启动兼容性。修复 #1239。感谢 @cylentsec！
• android：修复 Nothing OS 上的辅助程序初始化。感谢 @AeonLucid！
• gumjs：公开 Memory.findPointers()，其底层由新的 gum_memory_find_pointers() 辅助函数支持。 它提供一种专门且经过 SIMD 加速的方式，可在一个或多个范围中查找与一个或多个值匹配的 指针对齐字。
• memory：添加 gum_memory_find_pointers()，支持并行范围分片以及 SSE2、NEON 等各架构内核。
• interceptor：修复 x86 stdcall 离开时的回收问题。由被调用方清理栈的返回可能使调用栈无法追踪 正在返回的帧，进而发生崩溃。
• process：拒绝过期的 Darwin 文件映射结果，修复 Rosetta 下匿名区域被错误归属于无关文件映射的问题。
• vapi：将 gum_darwin_read 的 length 绑定为 gsize，避免向 4 字节槽位写入 8 字节数据。
• gir：确保内省辅助可执行文件在 g-ir-scanner 尝试运行它之前完成链接，修复 Ubuntu noble 暴露出来的竞争条件。
• ci：由于 GitHub 的 Intel macOS runner 已下线，现在通过 Rosetta 在 arm64 主机上构建， 继续维持 macOS/x86_64 覆盖。
• build：修复针对 arm64e 构建时的警告。
• bindings：将 @types/frida-gum 升级到 19.4.0。

Frida 17.10.0 已发布，为 Gum 内部机制带来大量新能力，并打磨了许多棱角。

主要变化：

• gum：为生成代码新增通用展开代理。Interceptor 创建时即获得展开支持，使异常和回溯可穿过跳板传播；Stalker 则在 Darwin 和 Linux 上改为始终执行 PC 转换。
• core：将 Darwin 展开机制迁移到 Gum 新的通用 UnwindBroker 和 UnwindSectionsProvider API；旧 UnwindSitter 现在只注册入侵者范围。
• interceptor：用可组合选项结构替换旧 attach 标志，覆盖暂存寄存器选择、在线/离线场景、重定位策略、替换数据和监听器数据。
• gumjs：向 JavaScript 公开新的 Interceptor 插桩选项；attach()、replace() 和 replaceFast() 现在可接收包含目标和新插桩配置的选项对象。
• interceptor：支持自定义重定向生成器和进程级默认选项。调用方可提供写入被 Hook 函数序言的指令序列，使 Hook 点更难预测。
• gumjs：在 QuickJS 和 V8 运行时中公开自定义重定向生成器、重定向空间提示和默认 Interceptor 选项。
• interceptor：修复异常或 longjmp() 越过被 Hook 调用后发生的挂起。现在会正确回收未到达 on-leave 跳板的调用帧，防止 gum_interceptor_flush() 永久自旋。
• unwind-broker：支持 32 位 ARM EH ABI，包括 ARM 特有的 personality 和 exidx 处理。
• unwind-broker：通过原始展开例程读取 throw 和 resume 指令指针，修复经过 Stalker 代码的异常处理。
• stalker-x86：在 Android 上启用展开支持，与 arm64 后端一致。
• stalker-arm64：不再要求就近分配 slab，代码和数据 slab 可分配在任意位置。
• memory：代码补丁完成后恢复页面保护；除非原本为 RWX，否则重新收紧为 RX。
• exceptor：新增仅处理器模式，安装 Frida 信号处理器但不 Hook signal() 和 sigaction()。
• module-registry：允许在 ELF 和 Darwin 上自定义 RTLD 通知器偏移，有助于提高 Frida 隐蔽性。
• core：通过 SessionOptions 公开 Agent 功能开关和链接器通知器偏移，包括 exceptor 模式、展开代理、退出监视器和线程挂起监视器设置。
• base：修复使用 frida-1.0/<arch>/ 的已安装布局中的资源解析；此前探测的路径仍包含字面量 <arch> 标记。
• devkit：使 Gum 示例与新的 attach 选项同步。
• deps：将依赖升级到 20260531，包括 Capstone d536b15，并把 @types/frida-gum 更新到 19.3.0。

这是一个快速错误修复版本，进一步改进了 Darwin 加固兼容性，完善了一些 Barebone 目标，并包含 @Lixhr 贡献的 arm32 重定位器修复：

• agent：在加固的 Darwin 任务上启用 Gum.Exceptor。旧的选择退出机制源自 Mach 异常端口时期，而得益于 Gum 最近的改进，POSIX 信号后端现在已可在 arm64e 上运行。
• darwin：先通过匿名页面洗净嵌入式 agent，再将其重新映射到目标中。这样可避免 在较新的加固内核上携带 frida-server 自身 __DATA 映射的代码签名状态。
• exceptor：通过 trampoline 执行 long jump，让异常处理程序能够在 arm64e 上 重定向 PC 和修改寄存器，从而绕过 XNU 的 sigreturn 验证。
• exceptor：直接从信号处理程序执行 long jump，而不是尝试通过信号上下文重定向 PC，从而修复 arm64e 作用域恢复。
• darwin：操作当前任务时跳过 pid_for_task()，省去一次 Mach 往返。
• process-darwin：在较新的 arm64e 系统上从进程外读取 dyld 镜像元数据时剥离 PAC， 并妥善处理 NULL 读取。
• process-darwin：容忍 sysctlbyname("kern.version") 在受限 XPC 沙箱中失败。
• arm32-relocator：重定位 B<cond> 时保留条件码。
• meson：在没有 libsoup 的 barebone 目标上跳过 inspector。
• vapi：绑定 gum_memory_allocate() 系列 API。

这是一个包含两项修复的快速错误修复版本，让一切继续顺畅运行：

• android：匹配待处理的启动请求时处理 android:process。声明自定义进程的 Activity 最终会获得一个由 zygote fork、名称类似 com.example.app:foo 的进程，而启动请求以包名作为键。现在会在匹配前移除冒号后缀，从而避免启动超时。感谢 @pakbaz-dev 追踪并修复此问题。
• package-manager：修复 @scope/name 这类 scoped 软件包名称的解析。此前我们把 scope/name 当作版本范围并获取注册表根目录，最终以误导性的 missing dist-tags 错误失败。

又一个快速错误修复版本，重点处理 GumJS 边界情况，并由 @agent-polyblank 完善 README：

• gumjs：预先将 NativeCallback 返回值清零，并在转换失败时跳过复制 FFI 值。这修复了一项回归：未初始化的栈数据可能返回给原生代码，包括返回结构体的情况。
• gumjs：在 QuickJS 运行时中，当结构体的数组长度与字段数量不匹配时抛出异常，而不再静默转换失败。
• gumjs：在 V8 未处理异常接收器中处理空栈跟踪，避免 Error 来源不在任何 JavaScript 栈帧中时发生崩溃。
• readme：添加构建与测试说明。感谢 @agent-polyblank！

这是一个快速发布，包含一项 GumJS 错误修复、一项小型 API 改进以及编译器类型版本升级。非常感谢 vfsfitvnm 和 Francesco Tamagni 对 GumJS 的改进：

• gumjs：修复 NativeCallback 返回结构体。libffi 针对 FFI_TYPE_STRUCT 的闭包结果路径此前未实现，会触发 g_assert_not_reached()。现在会遍历结构体返回值（包括嵌套结构体），并把各叶字段的自然字节复制到返回缓冲区。QuickJS 和 V8 回调调用器也会按 rtype->size 确定临时返回缓冲区大小，使结构体能按预期容纳。感谢 @vfsfitvnm 提供修复。
• gumjs：为 Memory.alloc() 的选项对象新增可选 protection 字段，默认值为 "rw"，以保持现有行为。这样便能在内存无法从 rw 切换为 rx 的环境中分配页面对齐的可执行内存，例如未越狱的 iOS 26+。感谢 @mrmacete。
• compiler：将 @types/frida-gum 升级到 19.1.0。

这是一个快速错误修复版本，包含对 Darwin 后端、Stalker 和 Compiler 的修复：

• darwin：在强制执行调试器映射时，确保新分配的代码页包含在页计划中。这修复了较新 Apple 设备上 iOS 26+ 中的 Interceptor 和 Memory.patchCode：在这些设备上，即使是新分配的可执行页，也需要页计划才能在执行时满足代码签名检查。感谢 @mrmacete 提供修复。
• stalker-x86：避免在 Windows 7 WoW64 上保存和恢复 AVX2 YMM 的高半部分。从 Stalker 的 JIT 代码执行此操作可能损坏 wow64cpu 状态，使下一次系统调用在 wow64cpu!CpupReturnFromSimulatedCode 中崩溃。由于 fxsave 已覆盖低 128 位，且 x86 Windows ABI 不会在调用之间保留 YMM 的高半部分，我们现在会在 NT 6.1 WoW64 上跳过此操作。感谢 @fitblip 提供修复。
• compiler：修复使用 Go/cgo 后端时的 Windows 崩溃。我们原先用 mingw 的 CRT 分配回调字符串，却让 Vala 端使用 MSVC 的 UCRT 释放它们，这意味着涉及不同的堆，Windows 很合理地以 STATUS_HEAP_CORRUPTION 紧急刹车。这些字符串现在会在回调返回后由 Go 端释放，Vala 端则将其视为非所有，并在需要时复制。

这是一个快速错误修复版本，用于解决 rootless iOS 上的回归：Darwin 后端此前对路径前缀处理得过于积极。

• darwin：修复 rootless iOS 上的 Agent 路径。Frida.agent_path 现在是已解析的绝对路径，因此再在前面添加 sysroot 或 CRYPTEX_MOUNT_PATH 会重复 rootless 前缀并生成不存在的路径。服务器现在把检测到的前缀直接传给 TemporaryDirectory.use_sysroot，修复 #1232。

事实证明软件开发很难，所以这里又有一个当天发布的错误修复版本。此版本改进了 Darwin 后端：

• darwin：握手出错时回收辅助进程。GDBus 可能会在 ChildExitMonitor 观察到子进程退出前报告 EOF，导致 child_exited 仍为 false，并使 obtain() 跳过 arm64e 后备重试。

Frida 17.9.4 已发布，重点修复并改进 Darwin、Apple TLS 兼容性，以及几个棘手的正确性问题：

• darwin：把辅助程序临时文件存放在容器的 Caches 目录，而不是 ~/.Trash。xctest 沙箱禁止从 .Trash 执行，而 Caches 在所需场景中均可写且可执行。
• darwin：用 socketpair 替换辅助程序握手所用的文件系统 socket，避免 HOME 深度嵌套（如沙箱容器内）时触及 macOS 104 字节 sun_path 限制。dyld 启动期间辅助程序崩溃现在会更可靠地表现为 PROCESS_NOT_FOUND。
• darwin：在 installed 模式下也把辅助程序裁剪为 arm64，使用相同的通用二进制后备方案，无需发布两个产物。
• darwin：跳过无操作的 stdio dup2() 动作。当源 fd 是从 Node 等父进程继承的 FIFO 时，posix_spawn 会以 EBADF 拒绝 dup2(fd, fd)。
• darwin：使用 posix_spawn 返回值修复错误报告，因为它可能不更新 errno；失败不再显示为“Undefined error: 0”。
• macos：使用 NSWorkspace 和 LaunchServices 元数据实现 applications API，并支持按 bundle 标识符启动应用。
• build：确保 lipo 目标存在并安装通用 frida-agent.dylib，在 shared+installed 模式下正确安装 frida-agent。
• base：在 AssetLocation 中新增平面布局后备，使未安装构建能解析放在库旁边的资源。
• compat：父构建使用 gioapple 时，在 Apple 平台用 OpenSSL TLS 构建 frida-agent，避免向目标注入 Security、Network 和 CoreFoundation；注入器无法安全完成这种注入。
• agent：compat 已拥有主机架构 Agent 时避免重复构建，修复 Darwin 通用 lipo 失败。
• value：修复 Json.Reader 根节点所有权，保持解析器拥有的原始节点存活，避免 json-glib 有缺陷的节点复制行为导致子节点父指针仍指向已释放节点。
• interceptor：为 dispatcher thunk 指针签名，修复 arm64e 上的共享 deflector。
• tests：新增 Darwin 启动应用覆盖，并在设置未配置时容忍空的 nvram boot-args 输出。

又是一个快速错误修复版本，因为软件开发很难，而且它显然很喜欢每天不止一次提醒我们这一点。

• asset-location：修复 frida-core 静态链接时的已安装资产路径解析。AssetLocation.detect() 可能从主机可执行文件中运行，因此安装在 bin/ 或 sbin/ 下的二进制文件可能让我们 相对于该目录查找资产，而不是相对于已配置的 libdir，例如查找 /usr/sbin/frida-1.0/... 而不是 /usr/lib/frida-1.0/...。我们现在会通过 Meson 配置的 libdir 进行重定向， 同时处理 sbin，并且在 Darwin 上不追加 <arch>：由于肥二进制，默认资产路径没有架构组件。

Frida 17.9.2 已发布。这个版本重点打磨构建系统和打包基础设施，同时还带来了新 API、Swift 绑定改进以及大量错误修复。

主要变化：

• fruity：保持共享 LLDB 会话存活，直至使用它们的最后一个 Gadget 分离。感谢 @mrmacete。
• elf：更妥善地处理 ELF 后备文件缺失的情况。
• exceptor：从异常详情中的 arm64e PC 移除 PAC 位。
• module-registry：使用 r_debug 同步 Linux RTLD 通知，以避免重新进入动态链接器。
• fruity-syscall-trace：当某个 PID 的符号解析器签名查找失败时，回退到最小签名并继续跟踪。感谢 joe。
• syscall-trace：添加 include-syscall 支持。感谢 @IPMegladon。
• stalker-x86：销毁时释放 slow slab，并添加相应辅助函数。感谢 @buherator。
• compat/build：修复允许的预构建集合为空时的源码构建问题，惠及 FreeBSD 等平台。感谢 @cl45h。
• build：添加一等的发行版打包支持。Frida Core 现在可以依赖上游 GLib 和系统依赖项构建为共享库；已安装资源位于 lib/frida-1.0 下；支持可重定位的资源发现；生成更干净的 .pc/GIR/typelib 输出；并减少泄漏到安装前缀中的内部子项目产物。
• apple：在 Darwin 上弃用 OpenSSL。TLS 现在使用 gioapple，证书生成使用 SecKey，libnice 使用 CommonCrypto 和 arc4random_buf，XPC UUID 生成使用 GLib.Uuid，而 macOS 构建会跳过需要 OpenSSL 的 Fruity 代码。此外还新增了 –with-apple-min-os 配置标志，用于提高 Apple 部署目标的最低版本。
• fruity：把可移植的配对/隧道代码拆分到独立文件；在非 macOS 平台上直接通过 OpenSSL 驱动 TLS-PSK；并修复二进制 plist 序列化器针对 Bytes 值的哈希与相等性判断。
• core：通过固定已解析的根节点，规避 JSON-GLib 的 Json.Reader 生命周期陷阱，修复启用运行时检查的 GLib 构建中的中止问题。
• core：修复后续调用 frida_init() 时覆盖 frida_init_with_runtime() 的问题。
• api：添加 WebRequestHandler、WebRequest、WebResponse 以及端点请求处理程序支持；公开 PortalService 额外端点注册功能。
• host-session：用捆绑的 PNG 资源替换旧有的硬编码提供程序图标数据，并为本地和模拟器提供程序添加图标。
• compiler：让动态加载的后端常驻内存。
• swift：通过 pkg-config 添加 Linux 支持；在 Apple 平台上提供 USE_SYSTEM_FRIDA 逃生开关；添加 WebRequestHandler 绑定、PortalService 端点绑定和 DeviceChange 异步流；扩大 Variant 反序列化覆盖范围；并完善 Swift 6 Sendable 支持。
• swift：修复 Apple 平台上的 NSNumber JSON 分类、仅使用 CoreFoundation 辅助函数导致的 Linux 构建失败，以及 MSVC 上 Int32/UInt32 枚举原始值不匹配的问题。
• build：按机器隔离 pkg-config；保留调用方的 PKG_CONFIG_PATH；避开 Strawberry Perl 中损坏的 pkg-config。

这是一个快速错误修复版本，包含以下改进：

• package-manager：修复 semver 预发布标识符溢出。此前 "202508252028" 等数字预发布标识符会验证失败，因为 parse_uint() 拒绝超过 UINT32_MAX 的值；使用 uint 的版本比较也受同一溢出影响。现在验证遵循 semver 规则，数字标识符不得包含前导零；比较则改用带长度前缀的字符串比较，可正确处理任意大的数字标识符。

本版本在 Fruity、Droidy、Linux 和打包层面带来了一批实用性改进和新能力：

• device：添加 override_option()，用于在创建主机会话时覆盖特定于后端的选项；如果已建立会话，更新将在下一次连接时立即生效。
• fruity：添加 control-endpoint 后端选项。默认值为 tcp:27042。仅支持 TCP 端点。
• droidy：添加 control-endpoint 后端选项。默认值为 tcp:27042，但可设为 ADB 支持的任何端点，例如 localabstract:/my-frida-server。
• android：在仅支持 64 位的系统上跳过 32 位 helper，避免浪费时间尝试启动它。
• linux：添加基于 eBPF 的 spawn gater 实现。感谢 @NSEcho！
• linux：支持向组停止状态的 PID 注入。
• gum：添加将 devkit 打包为 XCFramework 的工具。感谢 @sewerynplazuk！
• python：添加 spawn gating 示例。
• python：修复 child gating 示例。

祝使用愉快！

本版本带来了又一轮修复和文档改进：

修复

• fruity：修复大于 8192 字节的延迟 CDTunnel TLS 记录导致的 TcpTunnelConnection 停滞。需要时发送最小的虚拟 IPv6 数据报，以触发延迟数据的交付并提高可靠性。感谢 @hsorbo 报告并帮助追踪此问题，也感谢 @tux-mind 确定根本原因。

• fruity：修复 iOS 26.4 beta 版本上受限环境中的 spawn()。感谢 @mrmacete！

• fruity：修复 TreeSet 比较器行为：分数相同的传输可能被视为相等而丢弃，导致 Frida 在 macOS 上明明已有 CoreDevice 隧道可用，却优先选择带 lwIP 的 usbmuxd。感谢 @tux-mind 报告并帮助追踪此问题。

• fruity：处理隧道过早丢失的情况，例如 remotepairingdeviced 崩溃时。

• android：如果 dlopen(libart) 失败，则调整 RTLD 路径。感谢 @sam0holix！

文档

• docs：修订 README 中的 macOS 证书标识符，以更好地支持拥有多个 Apple Development 证书的设置，并避免 make 期间出现模糊的证书选择。感谢 @samykamkar！

• docs：更新 README，在 frida-trace 所需的安装说明中加入 websockets 软件包。感谢 @samykamkar！

这是一个小型后续版本，为 Android 和 Node.js 绑定带来几项修复与完善：

• android：同时在匿名内存中检测 setArgV0()。
• bindings：将 .withTimeout 和 .combine 重新加入 Cancellable；迁移到自动生成的绑定时曾意外遗漏它们。感谢 @hsorbo！

此版本为 Android、Linux、基于 musl 的系统和较新的 LLVM 工具链带来了大量修复 与兼容性改进：

• android：仅在 ART 命名空间确实存在时才在其中加载。
• android：处理 Chrome 的 zygote 进程，使其不受 spawn gating 影响而保持不可见， 同时其子进程继续按预期接受 gating。
• android：升级到 Android NDK r29，并在所有架构上以 API 21 为目标，因为最新 NDK 已不再支持更低的 API 级别。
• linux：改进进程枚举，确保始终存在 uid，提高用户查找的稳健性，并正确处理 状态不确定或容量不足的 getpwuid_r() 缓冲区。
• linux：避免 musl 上的 rtld 通知器死锁。
• linux：在调试器检查中处理 /proc 缺失的情况。
• compiler：添加兼容 musl 的后端模式，以持久辅助进程的形式在进程外运行 Go 编译器后端，避免 frida-core 在启动后加载或通过 dlopen() 加载时受到 TLS 限制。
• libc-shim：补齐更多 stdio API，包括 setbuf()、setlinebuf()、setbuffer()、 __srget()，并修复 glibc + musl 上的 setbuffer() 签名。
• meson：在需要时使用 FreeBSD 专用版本脚本，修复现代 LLVM/LLD 工具链上的链接。

祝你使用愉快！

本版本在各方面都带来了重大改进。

系统调用跟踪器

有时，观察特定目标进程内部发生的系统调用很有用。当目标包含某种 Frida 检测、root 检测或其他形式的运行时应用自我保护（RASP）时，尤其如此。在这种情况下，发现用于检查痕迹的系统调用，意味着你可以快速确定需要应用何种插桩或补丁才能绕过这些检查。

正因如此，从 Frida 17.8.0 和 frida-tools 14.6.1 开始，现在可以这样做：

$ frida-strace -U -f com.dexprotector.detector.envchecks

或者，连接一台运行最新 iOS 的 iPhone（无需越狱）：

$ frida-strace -U -f com.toyopagroup.picaboo

你还可以任意多次重复 -f 以启动多个程序或应用，也可与 -p $pid 和 -u $username 开关组合使用。不过，iOS 不支持按用户指定目标。这项功能在 Android 上尤其有用，因为每个应用都有自己的用户账户：通过这种方式，可以观察属于特定应用的所有进程中的系统调用。

结束语

本版本还包含许多其他好东西。请务必查看下方的变更日志，了解完整细节。

祝使用愉快！

变更日志

• fruity：基于 CoreProfile ktrace/kdebug 实现系统调用跟踪，具备系统调用解码、文件系统相关调用的路径重建、拼接调用栈以及符号化支持。
• 支持启动不可调试的应用：当无法通过 LLDB 启动时，回退到 ProcessControlService，并通过信号暂停它们。
• dtx：添加 CoreProfileService，扩展 ProcessControlService，升级协议处理，取消缓冲限制，并改进对 nil 参数和批量数据的处理。
• linux：使 Linux 系统调用跟踪器的 eBPF 后端对验证器更友好，增大 BPF 日志缓冲区，并使 Linux 系统调用跟踪协议与最新的跨平台格式对齐。
• android：加载 ART/Dalvik VM，并在进程内运行 frida-helper.dex。这消除了大量边缘情况，包括 ROM 兼容性问题。
• android-helper：通过使用 Looper.prepareMainLooper() 修复某些传音系 ROM 上的初始化崩溃。感谢 @depreciating！
• android：修复新版 Android 上的链接器检测和导出解析。
• libc-shim：扩大 stdio 覆盖范围，为 libstdc++ 添加带版本的 fopen/fopen64 支持，并且除非明确请求，否则跳过反初始化，以避免关闭期间的未定义行为。
• elf-module：必要时回退到 .dynsym，以改进符号枚举，并收紧符号名边界检查。感谢 @danielbaier！
• gumjs：向 SQLite API 添加列元数据。感谢 @codecolorist！
• objc-api-resolver：在复制方法前实现已收集的类，避免崩溃和未定义行为。感谢 @mrmacete！
• websocket/network-stack：通过暂停 libsoup 输入来避免饥饿，并异步处理传入数据报，改善高负载下的公平性。感谢 @mrmacete 和 @hsorbo！
• atomics：修复 guint64 未自然按 8 字节对齐的 ABI 上的 -Watomic-alignment 警告。
• gum：添加 Gum.Android vapi 绑定。

另外，也感谢 @hsorbo 一起对 Fruity 相关部分进行愉快的结对编程！

这是一次快速跟进版本，包含若干 Linux 系统调用跟踪器改进和修复：

• syscall-tracer：解码 timespec 值。识别 timespec 指针参数，并将其解码为结构化值，而不是不透明字节数组。支持 __kernel_timespec 和 old_timespec32 两种布局。
• syscall-tracer：修复原始附件生命周期。此前 GVariant 是根据返回前已释放的数据创建的，导致其中留下悬空指针。
• syscall-tracer：通过编码每个附件预留的空间大小，修复多附件解析。

这是一次快速跟进版本，包含 Variant 和 XPC 服务层中的若干修复与清理：

• python：增加转换为 uint64 Variant 的支持。
• node：不再接受多余的 uint64 Variant 转换。创建 uint64 GVariant 值时请使用 BigInt。
• node：修复 Variant 转换逻辑错误处理中存在的泄漏。
• xpc-service：移除对多余转换的支持。

这是一个快速错误修复版本，因为软件开发很难，而且它显然还喜欢在同一天加演一场：

• android：将启动完成推迟到 setArgV0()，具体做法是在 selinux_android_setcontext() 中只记录软件包名称，并延迟到 setArgV0() 才联系 RoboLauncher。这样可确保 ART 已准备就绪，使 frida-java-bridge 能够附加到虚拟机。

• android：重构 Zymbiote 代码并改进命名。

此版本带来了几项重要的新 Linux 能力、改进的服务连接机制，以及覆盖 Darwin、 Android 和 API 表面的少量平台专用修复。

亮点包括：

• linux：添加由 eBPF 驱动的新 SyscallTracer 服务，并为未来的活动采样奠定基础。
• droidy：支持使用远程服务以及在本地实现服务。
• darwin：在 macOS 26 上接受 __dyld_apis dyld 段。
• android：修复较新操作系统上的生成包名逻辑。
• icons：图标尺寸使用 uint16，并在 macOS 上省略 PNG 图标的宽度/高度， 以与其他平台保持一致。
• node：扩展 GVariant 封送支持，对 64 位整数使用 BigInt，并修复可能导致 引用计数下溢和内存损坏的 Service.request() 生命周期问题。

感谢 @veecore 修复 macOS 26 兼容性，也感谢 @hsorbo 共同完成部分 Linux 系统调用和 BPF map 工作。

这个版本为多个平台和组件带来了一系列稳定性与兼容性改进：

• fruity：恢复在 FLUSHING 状态期间调用 handle_events_completed，使 pending_usb_ops 最终能够清空，从而修复 PortableCoreDevice flush 无限循环。感谢 @mrmacete。
• compiler：重命名存在冲突的 Go 符号。感谢 @NSEcho。
• compiler：通过 memfd 加载后端并提供后备方案，从而在可行时继续享受避免临时文件的优势。
• linux：修复 memfd 受限时的系统会话问题（在 Android 的 Termux 环境中观察到）。
• elf-module：将 {Section,Symbol}Details 改为 boxed 类型，通过添加 ref/copy/free 语义并更新 Vala 绑定，使绑定能够安全地传递和持有它们。
• process：让 ThreadDetails free 函数能安全处理 NULL。
• darwin-module：让 Image free 函数能安全处理 NULL。
• linux：初始化变量，消除编译器无法证明返回 TRUE 时输出参数已初始化所产生的警告。
• linux：处理解释器 exec 包装二进制文件（例如 ld.so <program>）：检测 AT_BASE == 0，并从 /proc/self/maps 恢复真正的程序和解释器映射。

这是一个规模虽小却很重要的维护版本：修复了最近重新设计的 Android Zygote 插桩在启用 BTI 的 arm64 系统上的崩溃，扩大了设备兼容范围；同时修复了一项 GumJS 崩溃，并改进了对 Termux 环境的开箱即用支持。

• android：把 zymbiote 有效载荷放入更安全的地址范围，避免与 Zygote 使用的内存范围冲突（在 fork 出的应用/服务有机会在意此事之前就会还原）。
• android：确保注入的有效载荷在构建时启用 BTI，使间接分支跳入其中时不会触发故障，从而修复全新、低侵入性的 Zygote 插桩在启用 BTI 的 arm64 系统上的崩溃。
• android：调整静态链接的 OpenSSL，使其自动使用 Termux 的 ca-certificates，让 Frida.PackageManager（frida-pm）无需设置 SSL_CERT_FILE 即可在 Termux 上开箱即用。
• compiler：避免使用 memfd 路径，修复 Android 上的后端加载问题。该路径可能因使用更严格的权限重新打开同一底层文件而失败。现在，即使支持 memfd，我们也会使用临时文件。
• gumjs：NativeCallback 构造失败时（例如参数类型无效）避免释放 NULL ffi_closure，从而防止 libffi 崩溃，并允许 JavaScript 异常继续传播。

感谢 @leg1tsoul 修复 GumJS，也感谢 @as0ler 和 @ApkUnpacker 协助追踪 Android Zygote 插桩问题。

这个版本让我非常兴奋。在 Android 上，我们消除了两大系统不稳定来源：过去对 Zygote 和 system_server 侵入性很强的插桩。感谢 @mrmacete，Apple 平台上的 DebugSymbol 性能也得到显著提升，并包含多项稳定性修复。此外，各方面还普遍增强了稳健性。

Android

下面仔细看看 Android 端的稳定性工作。

在深入 Zygote 和 system_server 之前，先说明一项重要基础工作：感谢 @AeonLucid，SELinux 用户空间库已变基到更新得多的上游版本，在保留 Android M 特有行为的同时支持现代二进制策略格式。

过去，Zygote 处理依赖注入 frida-agent，以便通过子进程门控功能观察 fork() 转换。必须在这里注入代码，是因为除非应用标记为可调试，否则系统不允许以暂停状态启动它。

这种注入代价高昂：它需要停止并重启线程，会在之后的所有子进程中留下痕迹，并且在多个方面都很脆弱。

例如，必须小心隐藏文件描述符，防止 Zygote 调用 abort()。如果 frida-core（通常作为 frida-server 的一部分）恰好在不合适的时机执行注入，例如应用或服务启动期间，就可能使该进程崩溃，并拖垮用户空间的大部分内容。

我们通过 ptrace() 跟踪 Zygote，直到它到达一个被认为表示空闲状态的系统调用，以此缓解问题。但我一直没有为清理实现相同逻辑，所以那部分始终存在风险。

更糟的是，系统调用跟踪机制本身存在错误，会随机失败。我最初打算修复它们，但在发布此版本前有了另一个想法：能否用轻量且专用的方案替代这一切复杂性？

我与 @hsorbo 结对开始工作。最终方案从外部完成全部插桩，完全避开 ptrace()，转而依赖 /proc/$pid/mem：

1. 打开 /proc/$pid/mem 并扫描相关内存范围，定位 android.os.Process.setArgV0Native() 的 ArtMethod（或 Dalvik 等效项）。这是 libandroid_runtime.so 中实现的 native 方法，因此先确定模块基址，再使用 Gum 的 ELF 解析器（Gum.ElfModule）计算精确函数指针。该方法也非常适合子进程门控：它运行时 SELinux 转换已经完成，软件包名称也已知，并作为新的 argv0 传入。
2. 不再像以前那样做内联挂钩（技术上仍然可行），而是直接替换方法结构中的函数指针。
3. 选择一段包含可执行代码的内存范围；其中的代码要么已经运行且不会再次运行，要么只会在 fork() 后运行，例如子进程使用特定多媒体 API 时才会到达的代码。
4. 将 “zymbiote” 载荷写入该区域。它很小——arm64 上目前为 920 字节——因此无需覆盖太多内容。
5. 更新方法结构的函数指针，使其指向载荷。
6. 载荷恢复原始函数指针、调用真实实现，然后连接到抽象 UNIX socket。它发送 PID、PPID 和软件包名称，再等待 ACK。
7. 如果该软件包有待处理的 spawn() 请求，或已启用启动门控，frida-core 会暂缓发送 ACK，直到应用使用给定 PID 调用 resume()。这样客户端便有机会 attach() 并应用早期插桩。
8. 如果 connect() 失败或发生 socket 错误，载荷直接返回，因此 frida-core 崩溃不会拖垮用户空间。
9. 如果通信成功并收到 ACK，载荷尾调用 raise(SIGSTOP)。尾调用对于保证下一步安全十分重要。
10. frida-core 观察到进程处于停止状态后——意味着它不再于载荷内部执行——会回滚所有更改并发送 SIGCONT。任何未由 Frida 插桩的子进程都会保持完全原始的状态。过去并非如此，一些应用会因为 RASP 系统检测到先前加载 frida-agent 后残留（但已失效）的痕迹而崩溃。

这就是最终采用的方案，结果相当直截了当。整个载荷只有 295 行 C 代码（包括用于尾调用的少量内联汇编）。由于完全不再涉及 ptrace()，与其他工具的互操作性也显著改善。

system_server 端的工作量小得多。我们已有一个用于非 root Android 的小型辅助程序 frida-helper.dex。我们会把它写入临时文件，让 app_process 指向它，并与其通信以枚举已安装应用、运行中进程等。

本版本将该方案通用化：辅助程序现在由 Linux 和 Droidy 后端共享，并扩展支持其他请求类型，例如启动 activity 和发送广播。

除了显而易见的稳定性收益，这也意味着 frida-core 不再依赖 frida-java-bridge。因此，未来操作系统版本或 Play Store 更新引入的 libart.so 兼容性问题不会损害 Frida 的核心功能。

不再向 system_server 注入内部 agent 的一个缺点是，我们失去了禁用系统默认应用启动超时的能力。我认为可以接受，因为必要时仍可向 system_server 注入一个小脚本来实现同样效果。

结束语

本版本还包含许多其他改进。请务必查看下面的变更日志了解完整细节。

祝使用愉快！

变更日志

• android：将 SELinux 用户空间库变基到更新的上游版本，在保留 Android M 特性的同时支持现代二进制策略格式。（感谢 @AeonLucid）
• android：改用轻量级 Zygote 挂钩：修补 android.os.Process.setArgV0Native()，使其通过小型载荷跳转并回连 frida-core 进行插桩。此方案取代此前在 Zygote 中放置内部 agent 的做法，并移除对 frida-java-bridge 的依赖。（共同作者：@hsorbo）
• android：全面迁移到 frida-helper.dex，消除向 system_server 注入代码的需求。
• libc-shim：修复长期存在的 Android SELinux getline() 分配器不匹配问题，该问题会导致堆损坏和未定义行为。
• darwin：通过重写的解析器加快按地址查找 Objective-C 方法，并用 GumModuleRegistry 信号替换 symbolutil 缓存失效器。后者修复了交换 dyld 通知场景中的 SIGBUS。（感谢 @mrmacete）
• fruity：在关闭状态下执行 TCP 写入时抛出 CLOSED，避免无限轮询循环。（感谢 @mrmacete）
• fruity：修复可能导致 USB 工作线程死锁的 USB 启动/关闭竞态，使枚举和关闭过程具有确定性。
• linux：修复 ptrace 信号等待器转发和系统调用跟踪不同步，使存在 ptrace 内部停止和真实信号时的 spawn/attach 流程更加稳健。
• linux：修复 arm64 ucontext 记录解析。（感谢 @MarlinDiary）
• android：处理新版 Android 中的 __pthread_start 符号后缀，使线程枚举不再错误地把系统视为不受支持。（感谢 @MarlinDiary）
• android：在 enumerateRanges() 中处理 APK 库。（感谢 @monkeywave）
• arm64：不可行时避免尝试 Interceptor 快速修补。（感谢 @Jiay1C）
• interceptor：添加 FORCE attach 标志，即使函数太小而无法安全修补，也允许内联挂钩。这可能覆盖函数末尾之后的字节，应谨慎使用。
• elf：必要时强制挂钩 RTLD 通知器，并改进 ELF 模块哈希解析和验证，包括正确解析 ELF32 的 GNU 哈希。
• frida-node：使用 Symbol 描述而非强制转换，避免 XPC 相关用法中的 “Cannot convert a Symbol value to a string” 错误。（感谢 @mrmacete）

本次发布提高了 Windows 上模块导出信息的准确性，让 Darwin 上的辅助程序启动更加稳健， 并通过 SwiftPM 和新的 FridaCore xcframework 为 Swift 用户带来重大增强：

• windows：修复 Module 导出元数据，使 type 属性准确反映真实导出类型，而不是始终报告为函数。 感谢 @Ninja3047！
• darwin：启动辅助程序时使用 DO_NOT_REAP_CHILD，使辅助程序在未使用 -arm64e_preview_abi 启动的系统上更稳健，同时让宿主进程免受信号相关副作用影响。
• python：改进类型标注。感谢 @EtienneMaheux！
• swift：添加 SwiftPM 软件包清单和支持；将 Frida_Private 模块重命名为 FridaCore； 实现 LocalizedError（Foundation 可用时）并添加错误说明；完善 RPC API，并允许丢弃调用结果； 对 Device 实例去重，并修复 AsyncEventSource 中 yield/finish 的竞争条件。
• swift：添加 AuthenticationService、PortalService、EndpointParameters、PackageManager 和 Compiler 的绑定；添加最小化的 GLib 绑定（MainLoop、File、Uuid、TlsCertificate、DateTime/TimeZone）， 并将 GLib 和 JSONGLib 移入子命名空间。
• ci：随 frida-core 发布 .xcframework。

新鲜出炉：Frida 17.5.1！🍞

此版本包含一项重要错误修复：

• darwin-mapper：为本地共享缓存查找添加验证。看似位于缓存中的符号， 现在不会再解析到潜藏在缓存外的 dylib（例如 libsystem_pthread.dylib 的 introspection 构建）。衷心感谢 @hsorbo 与我们结对调查！

祝你逆向愉快！🧠💥

喝完几杯新鲜的 ☕，又堆积了一大批提交后，我们带着一个功能丰富的版本回来了。亮点包括更聪明的编译器、更稳固的 Darwin 内部实现，以及大规模的 Swift 重构——绑定现在优先使用 async/await，不再依赖委托，并且大体上与平台无关。

亮点

• compiler：向 CompilerOptions 添加 platform 和 externals 选项，并将它们一路传递到 Go 后端。这让 frida-compile（以及 Frida.Compiler）能针对目标平台定制输出，并将选定的模块视为外部依赖——例如为 GumJS agent 构建插件时，agent 公开的 API 应在运行时链接，而不是打包进去。（感谢 @leonitousconforti）
• darwin：重写 query_shared_cache_range()，改为解析 dyld 共享缓存头，而不是从 AllImageInfos 中找到的基址开始遍历虚拟内存区域。这消除了猜测，并确保页面发生写时复制后仍能得到正确的区间。（感谢 @hsorbo 参与结对编程）
• darwin：AllImageInfos 现在会报告 Dyld Shared Cache 的 UUID 和滑动值。（感谢 @hsorbo 参与结对编程）
• simmy：spawn() 现已正确接入 argv 和 env，因此模拟器的行为更接近真实设备。
• frida-node：生成的 from_value() 辅助函数现在会包含继承的属性，因此 externals 等选项能正确传递。
• frida-python：修复 PackageManager 规格选项解析中一处很小但会泄漏的角落问题。

Swift 绑定：现代化的跨平台革新 🍎

Frida Swift 绑定已经进行了大规模重构，使其符合 Swift 习惯、优先并发，并支持跨平台。

• 全面采用 async/await——大多数 API 现在使用 Swift Concurrency，并通过 GCancellable 支持取消 Task。
• 移除委托——基于委托的回调已替换为 异步事件流（AsyncStream），使事件处理更符合习惯，也更易于组合。
• 线程友好——api: Support invocation from any thread 允许从非主线程安全调用。（感谢 @hsorbo 参与结对编程。）
• 纯 Swift 核心与跨平台支持——核心绑定现已不依赖 Foundation 和 Dispatch，并使用纯 Swift 类型（二进制数据表示为 [UInt8]）。目前仍有两个小缺口：Marshal 辅助函数中的 JSON 编解码当前使用 Foundation；以后会添加不依赖 Foundation 的后备实现。
• SwiftUI 友好——新增 DeviceListModel，它是一个 @MainActor ObservableObject，公开 @Published devices 和 discoveryState，便于顺滑集成 SwiftUI。
• 图标可移植性——用可移植的 Icon 枚举取代特定于平台的图像处理，并为 CGImage、NSImage、UIImage 和 SwiftUI.Image 提供平台适配器。
• API 稳定性改进——公开枚举标注了 @frozen，并在必要时将一些复杂引用类型标记为 @unchecked Sendable。

注：本版本不包含 frida-swift 预构建二进制文件；如果你使用 Swift 绑定，应执行 git clone 并从 main 构建，以获得最新变更。

还请注意，Swift 绑定仍然处于实验和演进阶段——虽然新 API 向前迈出了一大步，但在即将推出的版本中 Swift 层稳定之前，它们可能还会继续变化。

快速示例（来自 frida-swift README）

DeviceListModel（界面友好的模型）：

import Combine

@MainActor
public final class DeviceListModel: ObservableObject {
    @Published public private(set) var devices: [Device] = []
    @Published public private(set) var discoveryState: DiscoveryState = .discovering

    @frozen
    public enum DiscoveryState: Equatable {
        case discovering
        case ready
    }

    public let manager: DeviceManager

    public init(manager: DeviceManager) { … }
}

现在可以这样使用：

import Frida
import SwiftUI

struct DevicesView: View {
    @StateObject private var model = DeviceListModel(manager: DeviceManager())
    @State private var selectedDevice: Device?
    @State private var session: Session?

    var body: some View {
        NavigationStack {
            List(model.devices, id: \.id) { device in
                Button {
                    Task {
                        selectedDevice = device
                        session = try? await device.attach(to: 12345)
                    }
                } label: {
                    VStack(alignment: .leading) {
                        Text(device.name)
                            .font(.headline)
                        Text(device.kind.rawValue)
                            .font(.subheadline)
                            .foregroundStyle(.secondary)
                    }
                }
            }
            .navigationTitle("Frida Devices")
            .overlay {
                if model.devices.isEmpty {
                    ProgressView("Searching for devices…")
                }
            }
        }
    }
}

完整脚本生命周期示例：

func testFullCycle() async throws {
    let manager = DeviceManager()

    for await devices in await manager.snapshots() {
        guard let local = devices.first(where: { $0.kind == .local }) else {
            continue
        }

        let session = try await local.attach(to: 12345)
        let script = try await session.createScript("""
            console.log("hello");
            send(1337);
        """)

        Task {
            for await event in script.events {
                switch event {
                case .message(let message, _):
                    print("Message:", message)
                case .destroyed:
                    print("Script destroyed")
                }
            }
        }

        try await script.load()
        break
    }
}

祝使用愉快。一如既往，如果遇到任何问题，请告诉我们！

这是面向 Darwin 用户的一项虽小但重要的更新：

• darwin：在有根系统上运行时，恢复 iOS ≥ 16 的应用列表和启动功能。frida-core 提交 8108d4d 在修复两个 Interceptor 单例泄漏时破坏了 dccb612，本次更新使后者重新生效。事实证明，springboard.m 中的泄漏是有意为之，它承担只初始化一次且不需要清理的逻辑；没有它，我们应用的插桩会立即被还原。感谢 @alexhude 提醒。

万圣季带来了一小批修复和改进：

• simmy：启用系统完整性保护（SIP）时，让依赖注入 SpringBoard 的功能优雅降级。这意味着 get_frontmost_application() 和图标获取现在会使用后备方案，而不会直接崩溃。

• simmy：修复请求部分 bundle ID 时对已安装应用的枚举。感谢 @hsorbo 协助！

• docs：更新 README 的 Apple 证书章节，以反映当前实际情况。感谢 @gemesa 发现并修复过时内容！

尽情使用，祝各位逆向愉快！

本周轮到一批 Simmy 后端改进登场。感谢 @hsorbo 参与结对编程，带来以下改进：

• simmy：实现 get_frontmost_application()，轻松确定当前位于前台的是谁。
• simmy：修复 query_system_parameters() 所报告的 hardware.product， 例如返回 iPhone18,2 而不是“iPhone 17 Pro Max”。
• simmy：接通应用图标。

祝你使用愉快！

这是一个小巧可口的后续版本，让势头继续保持：

• android：升级 system-server 中的 frida-java-bridge，纳入最新的稳定性改进：
  • android：处理静态 trampoline 修正，将每个 ArtMethod 回滚到之前的入口点，避免挂钩被绕过。
  • android：在 GC 后同步 ArtMethod 类字段，避免替换用的 ArtMethod 实例失效并导致未定义行为。 感谢 @hsorbo 一起结对编程。
• devkit-assets：将 GumJS 示例升级到新的 Frida 17 GumJS API。感谢 @Hexploitable 促成此事。
• freebsd：接入 PTY 支持，使依赖控制终端的启动/附加操作开箱即用。

祝使用愉快！

又到了发布功能丰富的新版本的时候！主要变化：

• simmy：全新的后端，通过 CoreSimulator.framework 与 Apple 模拟器通信。启动应用、对进程插桩，并像对待其他设备一样使用模拟器——全部都能在 Frida 中轻松完成。

• darwin：支持对 dyld_sim 进行早期插桩，因此即使模拟进程中的动态加载器尚未完成自举，也可以附加并加载脚本。

• darwin：修复最新版 iOS 18 模拟器上的 sysroot 检测；其中 dyld_sim 现在不会出现在 _dyld_image_count 和 TASK_DYLD_ALL_IMAGE_INFO_64 中。感谢 @CodeColorist 追踪到这个问题！

• fruity：遇到 InvalidHostID 错误时自动取消配对，使下一次配对尝试能够成功。感谢 @mrmacete 的出色工作！

• android：将 system-server 更新至 frida-java-bridge 7.0.9。变更如下：
  • 修复 Android 16 上的 Java.deoptimize*() 和 Java.backtrace()。感谢 @hsorbo！
  • 改进类型定义。感谢 @yotamN！

• host-session：添加跨后端通信，使通过一个后端发现的设备现在可以供另一个后端的内部逻辑使用。

• base：引入 StdioPipes 和 FileDescriptor 辅助工具，由 Darwin、Linux 和 FreeBSD 后端共享。

• value：新增 VariantReader.list_members() 辅助方法，使内省更加容易。

尽情使用吧！

新版本已经准备好了！本次发布专注于进一步榨取 Fruity 后端的性能：

• fruity：批量传递数据报，使跨线程交接更具确定性，并减少上下文切换开销。
• ncm：重新设计宿主到设备的调度。现在会维护一个 OUT 传输滑动窗口，并在任意 URB 完成后立即补充，让 bulk pipe 始终保持繁忙；在我们的测试中，HS 吞吐量从约 29 MB/s 提升到约 34 MB/s。
• ncm：改用固定槽位的 NDP 布局，把 O(k²) 的“缩小直到能够装入”打包器变为 O(k)。对于 256 MiB 的传输，布局时间从约 1.1 秒降至噪声水平。

尽情使用，也请告诉我们实际效果如何！

刚刚出炉的维护版本，大幅提升了 Fruity CoreDevice 隧道的性能。

新鲜出炉的新功能！本次发布为 Barebone 和 Fruity 后端带来了令人兴奋的新能力， 同时也打磨了一些不够顺畅之处：

• barebone：添加对 XNU 注入的基本支持，已在 QEMU 中的 iOS 14.0 上成功测试。 与 @hsorbo 共同完成。
• barebone：公开带下划线前缀的 CModule 符号，使其可以在 Frida 脚本中使用。
• fruity：隧道超时或遇到其他传输错误时回退到 usbmux。感谢 @Xplo8E 的推动。
• fruity：处理 CoreDevice 配对事件，并使用 FIFO 而不是序列号来匹配配对请求与响应。 非常感谢 @hsorbo。
• fruity：处理清理过程中的少数边缘情况。感谢 @mrmacete。

尽情享用吧！

版本虽小，影响很大：@mrmacete 提供的两个单行修复确保 Interceptor 在新版 iOS 上行为正确。

• code-allocator：使用 pc 检查切片地址，使 data 与 pc 不同时（例如 iOS 26 上）is_near 和 is_aligned 仍保持一致。感谢 @mrmacete！

这个新的维护版本全面带来了少量修复和易用性改进：

• gumjs：确保 onLeave 只会在与之匹配的 onEnter 确实运行后调用，从而消除 在调用途中附加 Hook 时出现的不可预测行为。感谢 @mrmacete！
• darwin-module：对 dyld “all image infos”中的 lldb_image_notifier 指针 进行 swap-hook，使模块注册表即使在通知器只有一条指令的现代 iOS 设备上也能 正常工作。感谢 @mrmacete！
• barebone：添加 try_remap_writable_pages()。
• barebone：允许覆盖 query_rwx_support()，以便针对特殊平台定制 RWX 能力探测。
• frida-node：在 TypeScript 阶段遵循 package-lock.json，使 JS 依赖树完全确定。

这个版本酝酿了一段时间，现在一大批好东西终于落地：

• darwin / fruity：通过双重映射支持 iOS 26，并在 palera1n 上启用注入。特别感谢 @mrmacete 推动这项工作。
• android：升级 system-server 中的 frida-java-bridge，以纳入 @AeonLucid 对 ART 偏移查找的改进。
• platform：添加初步的 visionOS 支持。衷心感谢 @demonguy 开拓这片全新领域。
• freebsd：加入 x86（32 位）支持。感谢 @saruman9 完成实现。
• threads：在 Linux 和 Darwin 上接通 ARM/arm64 的 NEON 寄存器访问——感谢 @londek 贡献这组补丁。
• barebone：为 NativeFunction / NativeCallback 添加 uint 类型支持，并在 MMU 被禁用时进行优雅处理。
• buffer：修复 BufferReader.read_pointer()，此前我们错误地认为需要传入偏移量。

尽情使用吧！

此版本对 Cloak API 和模块处理进行了多项改进，同时还包含一些必要的更新和 错误修复。特别感谢 @AeonLucid 为 Android 支持作出的贡献。

• android： 更新 system-server 中的 frida-java-bridge，纳入 @AeonLucid 改进的 ART 偏移查找。详情请参阅 frida-java-bridge#362。

• cloak： 在 Android 上添加对 Art::GetOsThreadStat 的支持，解决一个 与 frida-core#500 类似的问题：Zygote 会等待进程变为单线程后再继续， 否则就会崩溃。此变更适配了 art::GetOsThreadStat 的新用法。（感谢 @AeonLucid）

• cloak： 修复 ThreadCountCloaker.dispose() 中的内存泄漏，原因是此前 未能向上调用 GObject.dispose()。

• module： 添加可选的 get_version() 虚函数。

• module： 将大多数接口方法改为可选，以减少 Barebone 集成所需的样板代码。

• darwin： 实现 Module.get_version()，在可用时公开 LC_SOURCE_VERSION。

• darwin-module： 添加 source-version 属性，以在存在时公开 LC_SOURCE_VERSION。

• darwin-module： 支持在非 Darwin 环境中以内存方式使用，例如在 XNU 内部。

• gumjs： 向 JavaScript 公开 Module#version。

• barebone： 支持注册模块。

• compiler： 将 @types/frida-gum 升级到 19.0.1。

这是一个快速错误修复版本：

• android：升级 system-server 中的 frida-java-bridge，以包含 @AeonLucid 提供的 ART 偏移检测修复。
• barebone：支持实现 DebugSymbol API。

我们很高兴宣布 Frida 17.2.12 发布。此版本初步支持在没有操作系统的情况下运行 Gum， 显著增强了 Barebone 后端，并带来多项改进和修复。

• android：升级 system-server 中的 frida-java-bridge，包含一项针对 ART 类规格偏移检测错误的修复。 这可防止 libart.so 独立于 SDK 版本更新时因偏移不匹配而崩溃。现在的修复通过已知类在运行时检测， 而不是使用 SDK 启发式规则，从而提高了跨 Android 更新的可靠性。

  非常感谢 @AeonLucid 带头推动这项工作——这是一次真正英雄般的努力， 面对不断变化的 ART 内部机制，它为 Frida 的 Android 支持带来了坚如磐石的可靠性。

• gum：初步支持在没有操作系统的情况下运行，使 Frida 能在裸机目标上运行。集成者使用特定于目标/固件的实现 覆盖所需的弱符号。我们正在开发一个 XNU agent，它让我们可以在 Apple 的 OS 内核中运行 JavaScript。

• barebone：在 arm64 后端添加对 APRR 的支持（感谢 @hsorbo 与我结对编程）。

• barebone：添加对 R_AARCH64_PREL32 重定位的支持（感谢 @hsorbo），改善与更多 ARM64 二进制文件的兼容性。

• barebone：实现 Memory.protect()，提供在裸机目标上更改内存保护的能力。

• fruity：上传前对 Gadget 的 r-x 页面进行喷洒，将其变为调试器映射（感谢 @hsorbo、@mrmacete 和 @as0ler）， 修复新一代硬件上的问题。

• buffer：添加新方法：read_bytes()、write_bytes()、write_int64()、 write_uint32()、write_int32()、write_uint16()、write_int16()、 write_uint8()、write_int8()，扩展 Buffer API 对各种数据类型的处理能力。

• gumjs：避免使用正则表达式解析内联 source map，以减少栈使用，提高在栈大小受限平台上的稳定性。

• build：添加对以 ‘armv6kz-‘ 为前缀的工具链的支持（感谢 @zetierhg），改善与更多工具链的兼容性。

• build：修复 Python < 3.9 的 typings（感谢 @oriori1703），确保与旧版 Python 兼容。

• build：为 FreeBSD linker 特别处理 ld 脚本，以修复构建问题（感谢 @grimler），改善 FreeBSD 支持。

• devkit：让符号前缀变为可选（感谢 @Hexploitable），允许使用者选择是否为第三方符号添加前缀以避免冲突。

就在我们以为一切都已搞定时，软件又提醒我们它能有多难！感谢 @mrmacete、@hsorbo 和 [@0xmurphy][]，我们迅速解决问题并带来以下修复：

• frida-node：修复 fdn_keep_alive_until() 的 TSFN 生命周期问题。此前我们会把 TSFN 设为 NULL，当其他引用持有者尝试安排清理时会导致崩溃。

• fruity：修复终止预热目标时的问题。在 spawn 时终止预热进程会产生“connection closed”错误；现在会捕获该错误，从而可以启动新实例。

这是一个快速发布的错误修复版本，解决了两个重要问题：

• frida-node：修复保活 ThreadSafeFunction 的清理。在保活场景中使用 napi_release_threadsafe_function()，使待处理的微任务能在 libuv 句柄被丢弃前有时间运行。 这可以防止清理期间出现“unsettled top-level await”。由 @as0ler、@hsorbo 和 @mrmacete 共同完成。

• barebone：确保 RustModule 的 C ABI 入口点能够在垃圾回收后保留下来。 较新的 Rust 工具链使用 --gc-sections，它会剥离未使用的段。我们重构了 make_linker_script()，扫描 Rust 源代码中预期公开的符号，并生成 KEEP(*(.text.<symbol>)) 指令，从而保留这些入口点。

这次我们带来了初步的 iOS 26 支持，并修复了 Node.js 绑定中的一个错误：

• fruity：支持在强制调试器映射的 iOS 目标（iOS 26）上注入 gadget；在这种情况下， 我们无法从目标进程内将内存保护重新改为可执行。遇到这类情况时，在 Interceptor 支持强制调试器映射之前，gadget 配置的 code_signing 将被设为 required。感谢 @mrmacete！

• device：修复 stdio 选项未传递给 spawn() 的问题，该问题导致子进程始终继承 stdio。 与 @hsorbo 共同完成。

这是一次快速的错误修复版本，用于解决影响 Windows 用户的问题：

• package-manager：修复 Windows 上损坏的 #if。错误的预处理器指令会导致在 Windows 平台上编译时构建失败。

我们很高兴宣布 Frida 17.2.7 发布，此版本对软件包管理器进行了显著改进。

• package-manager：改进解析和提升，以更贴近 npm 的行为。与 @hsorbo 共同完成。感谢你的帮助！
• package-manager：为 install() 添加 role 选项，实现与 npm install 的 --save-* 开关等价的效果。
• package-manager：为 install() 添加 omits 选项，实现与 npm install 的 --omit=x 开关等价的效果。
• package-manager：改进对可选软件包的处理。
• package-manager：在非 Windows 系统上解压时处理文件模式。
• package-manager：修复 has_install_script 逻辑，使其也考虑 preinstall 和 postinstall 脚本。
• meson：说清 Vala 构建系统说明。Vala README 过去只提到 autotools 说明， 而以该方式编译 Vala 时，版本字符串不会添加 -frida 后缀，导致 frida-core 对 Vala 的检查失败。现在我们已明确，Vala 需要使用 Meson 从源码构建。感谢 @grimler 指出此问题！

我们很高兴发布 Frida 17.2.6，其中包含两项重要修复：

• buffer：修复 read_fixed_string() 中的 max_length。

  现在会同时按请求大小和缓冲区大小正确限制 max_length。

  感谢 @mrmacete！

• agent：在模拟 realm 中禁用 Exceptor。

  Exceptor 需要 Hook signal() 和 sigaction()，但它们位于 libc 中。这会导致 gum_mprotect() 因无法修改 libc 的只读映射而中止。此修复避免了在 Android 14 和 15 AVD 上使用 frida-server 或 frida-inject 时出现的崩溃。

  感谢 @ptrstr！

此版本为 Frida 带来了重要修复和改进。以下是主要亮点：

• frida-node：在 promise settled 之前保持 TSFN 存活，避免可能导致 Node.js 提前退出并显示“Detected unsettled top-level await”警告的竞态条件。感谢 @mrmacete 和 @hsorbo 协助追踪这个问题。

• frida-node：简化 findMatchingDevice()（由 @hsorbo 共同完成）。

• package-manager：仅在明确请求时提升版本。

• package-manager：修复 dev 逻辑。

• docs：修复 README 中的 Mapper URL（感谢 @cmdlinescan）。

这是又一个改进软件包管理器的快速错误修复版本，@hsorbo 和我一直在努力开发这部分。 以下是新内容：

• package-manager：修复依赖项安装死锁。当某个软件包的子依赖同时也是安装栈中 更高层另一个软件包的依赖时，可能发生死锁。该子依赖会等待高层软件包在物理上安装完成， 但该软件包又要等子依赖解决后才能完成自身安装，从而形成循环等待。
• package-manager：改进 manifest 处理，使其行为更接近 npm。（与 @hsorbo 共同完成。）
• package-manager：改进进度报告。

这是一个专注于改进软件包管理器的快速错误修复版本：

• package-manager：修复对 scoped spec 的处理。

• package-manager：处理包含根级条目的 tarball。

  该修复确保能正确处理包含“package/”目录条目或位于根层的任意文件的 tarball。

我们又带来了一个快速错误修复版本：

• package-manager：修复锁文件已为最新时的处理路径。
• package-manager：仅报告已安装的软件包。不再包含那些未经改动的顶层软件包。 同时还简化了 install() 逻辑。

又一个快速错误修复版本，解决了上一版本发布后发现的多个问题：

• compiler：在 Android 上将后端改为共享库，以避免线程局部存储导致的动态链接问题。
• python：公开 PackageManager.registry 属性。
• python：修复 Compiler、PackageManager 和 FileMonitor 缺失的顶层计数器逻辑，确保信号能够正确发出。
• python：为 PackageManager 类型添加 __repr__ 方法，便于调试。
• core：修复将 libsoup 用作子项目时的构建问题。

我很高兴地宣布 Frida 17.2.0 正式发布。本次发布的重点是让软件包发现变得极其简单。

查找现有的 Frida 专用软件包就是这么容易：

使用其中任何一个软件包也同样简单：

亮点

• 🔍 frida-pm search – 零干扰结果（按 keywords:frida-gum 过滤）。
• 📦 一条命令即可安装 – 即使没有 Node.js，frida-pm install <pkg> 也能工作。
• 🧩 编程接口 – 从 Python、C 等语言使用时具有相同的接口。

你在这里看到的是 frida-pm 命令行工具，它随 frida-tools 14.2.0 一同推出。 它的 Python 代码不到 300 行，因为它只是底层 Frida.PackageManager 实现的一层薄封装。

高级用户和软件包维护者通常仍会使用 npm、yarn 等工具，但我认为，如果要求初次接触 Frida 的用户同时熟悉更庞大的 JavaScript 生态系统，很可能会让他们不知所措并感到困惑。

frida-pm / Frida.PackageManager 的巧妙之处在于，搜索只会显示 Frida 专用软件包。 这是通过在搜索查询中内置 keywords:frida-gum 来实现的。

如果你在维护 Frida 专用软件包，请务必将 frida-gum 添加到 package.json 的 keywords 字段中。如果你的软件包是语言/运行时桥接，还请同时添加 frida-gum-bridge。

因此，可发现性是这里的一项关键功能。另一项功能是，它可以在没有 Node.js + npm 的系统上运行。 虽然我们默认使用 npm 的注册表作为后端，但你可以将它指向任何自己喜欢的注册表。

你还可以通过编程方式使用全部功能。例如，如果你想使用 Python 绑定执行搜索：

import frida

pm = frida.PackageManager()
result = pm.search("il2cpp", limit=3)
print(result)
print(result.packages)

你会看到类似下面的内容：

$ python search.py
PackageSearchResult(packages=[<3 packages>], total=13)
[Package(name="frida-il2cpp-bridge", version="0.12.0", description="A Frida module to dump, trace or hijack any Il2Cpp application at runtime, without needing the global-metadata.dat file.", url="https://npm.im/frida-il2cpp-bridge"),
 Package(name="frida-objc-bridge", version="8.0.5", description="Objective-C runtime interop from Frida", url="https://npm.im/frida-objc-bridge"),
 Package(name="frida-java-bridge", version="7.0.4", description="Java runtime interop from Frida", url="https://npm.im/frida-java-bridge")]
$

或者，你可能想安装几个软件包：

import frida

pm = frida.PackageManager()
result = pm.install(specs=["[email protected]", "frida-il2cpp-bridge"])
print(result)
print(result.packages)

运行后的结果可能类似这样：

$ python install.py
PackageInstallResult(packages=[<2 packages>])
[Package(name="frida-java-bridge", version="7.0.4", description="Java runtime interop from Frida"),
 Package(name="frida-il2cpp-bridge", version="0.12.0", description="A Frida module to dump, trace or hijack any Il2Cpp application at runtime, without needing the global-metadata.dat file.")]
$

添加安装进度也很容易：

import frida

def on_install_progress(phase, fraction, details):
    print({
        "phase": phase,
        "fraction": fraction,
        "details": details,
    })

pm = frida.PackageManager()
pm.on("install-progress", on_install_progress)
result = pm.install(specs=["frida-java-bridge", "frida-il2cpp-bridge"])
print(result)
print(result.packages)

输出可能类似下面这样：

$ python install.py
{'phase': 'initializing', 'fraction': 0.0, 'details': None}
{'phase': 'preparing-dependencies', 'fraction': 0.05, 'details': None}
{'phase': 'resolving-package',
 'fraction': -1.0,
 'details': 'frida-java-bridge@latest'}
…

我们已经看过如何从 Python 使用 PackageManager API，我或许还应该说明： 从 C 使用这个 API（几乎）同样简单：

#include <frida-core.h>

int
main (int argc,
      char * argv[])
{
  GCancellable * cancellable = NULL;
  GError * error = NULL;

  frida_init ();

  FridaPackageManager * manager = frida_package_manager_new ();

  FridaPackageInstallOptions * opts = frida_package_install_options_new ();
  frida_package_install_options_add_spec (opts, "[email protected]");
  frida_package_install_options_add_spec (opts, "frida-il2cpp-bridge");

  frida_package_manager_install_sync (manager, opts, cancellable, &error);
  if (error != NULL)
    g_printerr ("%s\n", error->message);

  return (error == NULL) ? 0 : 1;
}

如果你想试试这个示例，请从我们的发布页面下载 frida-core devkit。

你可以像下面这样构建并运行它：

$ gcc install.c -o install -I. -L. -lfrida-core -Wl,--gc-sections
$ ./install

（frida-core-example.c 顶部提供了一条示例命令行，它针对该 devkit 所适用的特定操作系统/架构进行了调整。）

请注意，可以通过传入 NULL 来省略 opts。在这种情况下，如果 package.json 中定义的软件包 尚未安装，或已安装版本不匹配，就会安装这些软件包。与 npm 一样，如果你没有 package.json 文件， 而是直接安装一些软件包，系统会为你创建 package.json。

本次发布还包含其他一些改进和修复：

• Compiler：
  • 将 @frida/net 升级到 5.0.0。
  • 修复缺失的 shim 资源（感谢 @imlihe）。
• frida-node：
  • 更改 Device.openChannel() 的返回类型，以公开带有 destroy() 的更具体类型。

要升级，请运行：

$ pip install --upgrade frida frida-tools

尽情享用吧！

关键错误修复：恢复与 Android 14–15 的兼容性；上个版本添加 Android 16 支持时意外破坏了它。感谢 @tbodt 提供修复。

很高兴宣布 Frida 17.1.4，它带来了多项重要修复和改进——最值得注意的是支持 Android 16。以下是新内容：

• Compiler：将 esbuild 的 platform 切换为 node，使 package.json 中的 main 和 exports 按 Node.js 方式解析，恢复与依赖该行为的软件包的兼容性。感谢 @hsorbo 帮助追踪此问题。
• Plist：修复二进制属性列表的 offsetIntSize，确保与 Core Foundation 兼容。感谢 @mrmacete 帮助追踪此问题。
• Plist：XML 输出中的空字典和数组现在使用自闭合标签（例如 <dict/>），与 Apple 的编码器保持一致。
• Android：将 system_server agent 中的 frida-java-bridge 升级到 7.0.3，添加 Android 16 支持。感谢 @tbodt——同时也感谢 @thinhbuzz 贡献错误处理补丁，解决了某些 Android 12 设备上无法工作的问题。
• Darwin：将内部 agent 中的 frida-objc-bridge 升级到 8.0.5。
• GumJS：修复 FFI 参数的大端处理。

我们建议所有用户尽快升级。请确保同时升级到刚刚发布的 frida-tools 14.1.2。

本次发布为多个组件带来了一系列改进和错误修复。主要内容如下：

• 重命名 Compiler 后端中存在冲突的 Go 符号，避免链接到 Go 二进制文件时发生冲突。 这可确保与 Go 项目集成时保持兼容。
• 在 Linux 上修复与线程列表锚点相关的问题，以防止误报。此前，锚点可能被错误地添加到线程列表， 导致行为不正确。
• 修正 gadget 和 GumJS 中的 QuickJS 大端字节码检查。此前的检查在大端系统上不正确。
• 向 API 添加版本定义和宏，为开发者提供更明确的版本信息。

看来软件开发确实很难！17.1.1 发布仅仅几小时后，我们又带来了后续版本， 对 frida-core 和 frida-node 进行了完善。

frida-core

• Compiler – DeviceManager 构造函数参数现在可以省略。 为保持 ABI 兼容性，它仍保留在函数签名中，但已不再使用。

frida-node（Node.js / N-API 绑定）

• 信号处理
  • 处理程序现在能正确接收 GVariant 参数。
  • 处理程序内部抛出的异常会向上传播，不再被吞掉。
• Compiler – 只要还有任何 output 信号处理程序处于连接状态，就让运行时保持存活， 防止过早退出。

祝你玩得开心！

喝着刚泡好的咖啡，我完成了以下改进：

• 构建系统改进：
  • 以下组件改用 ESBuild 打包：
    • reportcrash.js on Darwin.
    • osanalytics.js on Darwin.
    • system-server.js on Linux.
    • Barebone 后端中的运行时。
• Barebone 后端修复：
  • 修复 ESM 处理：此前未等待返回的 Promise 会吞掉错误，现在所有错误都会得到正确报告。
  • 移除过期的桥接全局变量。

这是一次包含多项精彩改进的重大更新！

首先，我们在 Compiler 后端中改用了 ESBuild 和 typescript-go，性能获得大幅提升；由于不再需要维护打包器，维护负担也随之减轻。我们还添加了用于配置输出和打包格式的选项，并支持禁用类型检查。

其次，我们现在终于提供 Windows/ARM64 二进制文件。GitHub 向公众开放 Windows ARM64 托管运行器后，阻碍这项工作的因素也随之消除。

特别感谢 @mrmacete 修复 Interceptor 单例泄漏，也感谢 @fesily 在 Windows 上实现 Module#enumerateSections()，并改进 Module#enumerateImports() 以公开 slot。

以下是完整变更列表：

• Compiler 改进：
  • Compiler 后端改用 ESBuild 和 typescript-go。
  • 添加用于配置输出和打包格式的选项，并支持禁用类型检查。
• Windows/ARM64 支持：
  • 更新 CI，以发布 Windows/arm64 二进制文件。
• 社区贡献：
  • 修复 Thumb 地址的 32 位 ARM 断点逻辑。
  • 修复 Interceptor 单例泄漏（@mrmacete）。
  • 在 Windows 上实现 Module#enumerateSections() 并接通导入槽位（@fesily）。

本次发布包含几项重要修复：

• device：允许代理会话在释放前分离，以稳健应对乱序分离可能导致释放时无限挂起的情况。 感谢 @mrmacete！
• darwin：销毁模块解析器索引，避免在使用短生命周期解析器的场景中 （例如不同任务中）泄漏原生模块。感谢 @mrmacete！
• stalker：处理没有内联缓存条目的代码块。

这是一个快速错误修复版本，其中包含 @londek 的一项重要贡献。本版本解决了以下问题：

• darwin：修复 launchd agent。它仍在使用一个现已移除的旧 GumJS API，导致该 agent 无法在已越狱的 iOS/iPadOS/tvOS 系统上运行。

这是一个快速错误修复版本，用于修复最新版 frida-compile 生成的 Agent。随着 TypeScript 编译器更加符合规范并开始生成 CommonJS 胶水代码，我们需要把内部 Agent 显式声明为 ESM。此修复覆盖 Darwin 和 Android Agent，以及 Barebone 后端的脚本运行时。

此版本改进了 Compiler 实现，它为 frida-tools 中的 frida-compile CLI 工具提供 底层支持。具体变更如下：

• 升级到 frida-compile 18，现在包含 TypeScript 5.8.3、最新版 frida-fs 等。
• 修复 Windows 上的资源打包逻辑，此前虚拟路径使用了错误的路径分隔符。

软件开发很难，对吧？紧随上一个版本，这里有一项快速修复：

• compiler：更新 @frida/rollup-plugin-node-polyfills 以解决一个依赖问题，其仍依赖旧的 frida-fs。

此版本带来了几项错误修复：

• Compiler：将 frida-compile 和 frida-fs 更新到最新版本。
• gum：既然 GObject 已恢复为必需库，修复与其相关却被遗忘的 diet 位。
• gumjs：修复禁用断言进行构建时的 assigned-but-not-used 警告。

惊喜！在 17.0.0 发布的同一天，我们又带来了一个快速补丁版本。事实证明，软件开发很难！

此版本包含以下修复：

• Core：更新接口版本，使其与主版本一致。
• Darwin：将 frida-objc-bridge 升级到 8.0.4。
• Android：将 frida-java-bridge 升级到 7.0.1。
• frida-node：修复 Device.openChannel() 的返回类型，避免暴露未来可能需要更改的实现细节。

在喝掉数不清的咖啡、经历许多愉快的编程时光后，@hsorbo 和我很高兴为大家带来 Frida 17.0.0。距离上一次主版本升级已近三年，我们一直苦于找不到合适的时机引入破坏性变更，现在终于决定是时候了。

运行时桥接

长期以来，最困扰我们的一点是运行时桥接，也就是 frida-{objc,swift,java}-bridge，都捆绑在 Frida 的 GumJS 运行时中。这带来了几个主要痛点：

• 惯性：它们受制于 Frida 的发布周期。
• 臃肿：用户可能并不需要某个特定的运行时桥接。
• 可扩展性：我们希望看到面向各种运行时的桥接，但加入 Frida 的桥接越多，惯性和臃肿问题就越严重。
• 可发现性：社区维护的桥接更难被发现，因为使用它们需要另一套工作流。

不过，我一直不愿停止捆绑这些桥接，因为要求自定义 agent 必须经过构建步骤，似乎会增加太多阻力。而且，一想到这会破坏书籍、博客文章和 CodeShare 等处的示例，我也难以接受。

正因为构建阻力，我们在 15.2 中引入了 frida.Compiler API，同时 frida-tools 还附带了基于它构建的 CLI 工具 frida-compile。我们的 REPL 也得到改进，支持直接加载 .ts（TypeScript），其背后使用的正是 frida.Compiler。

但这仍然多了一步，对于一次性脚本，以及使用 Frida REPL 或 frida-trace 进行的早期原型开发来说，这一步还是太麻烦了。而且，它会破坏大量现有示例。为解决这个问题，刚刚发布的 frida-tools 14.0.0 已将这三个桥接内置进 REPL 和 frida-trace agent。

我们的桥接也已迁移到 ESM，因此可以由最新版 frida-compile 使用。（感谢 @yotamN 将 frida-java-bridge 迁移到 ESM ♥️）

从源码构建 Frida 的用户还可能注意到构建速度有所提升。由于不再捆绑这些桥接，我们终于可以移除 Gum 对 frida-compile 的依赖，并让 Gum 本身不再依赖 Node.js + npm。

我们仍然保留 GumJS 自己的运行时，它实现了 console.log() 等内置功能；不过，将它移植到 ESM，并直接逐个嵌入各模块后，我们就不再需要 JavaScript 打包器了。这意味着 Gum 自身的构建速度更快：在运行 Linux 的 i9-12900K 系统上，构建时间从约 24 秒降至约 6 秒。

可以在桥接文档中查看快速参考教程。

旧式枚举 API

过去，我们所有同步枚举 API 都是这样的：

Process.enumerateModules({
  onMatch(module) {
    console.log(module.name);
  },
  onComplete() {
  }
});

此外还有一个名称带 Sync 后缀的等效方法；在这个例子中就是 Process.enumerateModulesSync()。当初的想法是，底层实现未来可能变为异步；但在当时，大多数实现并非异步，所以带 Sync 后缀的实现只是套在那个看起来像异步的 API 外的一层薄包装。

后来，随着支持的平台越来越多，我意识到所有这些假装异步的实现始终都是快速且低开销的操作。因此，提供异步形式毫无意义。而少数从一开始就真正异步的 API，例如 Memory.scan()，继续保持异步仍然合理。

不过，我不愿直接破坏 API，于是选择为每个不带后缀的实现增加一项检查：如果省略回调参数，它就会像带 Sync 后缀的对应方法一样工作。为了推动用户迁离旧式 API，我还更新了 TypeScript 绑定，使其中只包含现代形式。

对应的现代写法如下：

for (const module of Process.enumerateModules()) {
  console.log(module.name);
}

其中 Process.enumerateModules() 返回一个 Module 对象数组。

这些旧式 API 现在终于全部移除了。使用 TypeScript 编写 agent 的用户无需做任何改动，除非你使用的是非常古老的类型定义版本。

内存读写 API

过去，你会这样访问内存：

const playerHealthLocation = ptr('0x1234');
const playerHealth = Memory.readU32(playerHealthLocation);
Memory.writeU32(playerHealthLocation, 100);

现代等效写法是：

const playerHealthLocation = ptr('0x1234');
const playerHealth = playerHealthLocation.readU32();
playerHealthLocation.writeU32(100);

每个写入方法都会返回 NativePointer 本身，以支持链式调用：

const playerData = ptr('0x1234');
playerData
    .add(4).writeU32(13)
    .add(4).writeU16(37)
    .add(2).writeU16(42)
    ;

这些旧版 API 现在也已移除；它们从 TypeScript 绑定中消失的时间和旧式枚举 API 一样久。因此，大多数用户应该也不会察觉这项变化。

静态 Module API

接下来介绍同样会影响那些在 19.0.0（与 Frida 17 同时发布）之前一直使用最新版 TypeScript 绑定的用户的破坏性变更。以下静态 Module 方法现已移除：

• Module.ensureInitialized()
• Module.findBaseAddress()
• Module.getBaseAddress()
• Module.findExportByName()
• Module.getExportByName()
• Module.findSymbolByName()
• Module.getSymbolByName()

从这些方法迁移都很直接。

不过，先来看看其中比较特殊的一个：

Module.getSymbolByName(null, 'open')

现在要这样实现：

Module.getGlobalExportByName('open')

对于其余方法，需要先查找 Module，再访问其上的所需属性或方法。例如，不再这样写：

Module.getExportByName('libc.so', 'open')

新的写法是：

Process.getModuleByName('libc.so').getExportByName('open')

Module.getBaseAddress() 的等效写法因此是：

Process.getModuleByName('libc.so').base

这意味着 Module 内省现在只有一种方式，而且 API 设计会引导你编写高性能代码。例如，过去你可能会想这样写：

const openImpl = Process.getExportByName('libc.so', 'open');
const readImpl = Process.getExportByName('libc.so', 'read');

但现在，在写出下面这样的代码之前，你可能会多考虑一下：

const openImpl = Process.getModuleByName('libc.so').getExportByName('open');
const readImpl = Process.getModuleByName('libc.so').getExportByName('read');

而会改成这样：

const libc = Process.getModuleByName('libc.so');
const openImpl = libc.getExportByName('open');
const readImpl = libc.getExportByName('read');

这种写法既更易读，性能也更好。

最后同样重要的是，Module.enumerateExports() 等静态枚举 API 现在也已移除。不过，它们很早以前就从 TypeScript 绑定中删除了，所以大多数用户应该无需处理。如果确实需要迁移，方式与上面完全相同。

EOF

大致就是这些。祝各位逆向愉快！

此版本改进了 glibc 下的 Linux 线程枚举，并加固静态 OpenSSL 构建，防止意外 加载配置。

变更：

• linux：跳过 tid = 0（已退出但尚未 join）的 glibc 线程，以避免错误的 “Unsupported Linux system” panic。
• linux：按创建顺序（最早的在前）列出 glibc 线程，以反映真实的线程生命周期。
• deps (TLS)：使用 OPENSSL_NO_AUTOLOAD_CONFIG 构建 OpenSSL，阻止加载任何 系统配置文件，避免 TLS 初始化时崩溃。

版本接连发布！软件开发很难，有时我们需要快速推送修复，确保一切顺畅运行。 以下是此版本的新变化：

• frida-node 修复 Device.openChannel() 返回类型相比以前发生变化的回归问题。
• Fruity 后端改进：使用 Apple 的 CoreDeviceProxy 作为回退方案，从而支持 NCM 存在问题的系统。同时每 250 ms 重传一次 mDNS-SD 请求，以增强稳健性。

祝你逆向愉快！

这个版本为 Fruity 后端带来多项改进和修复，增强了跨平台兼容性与错误处理。以下是本版本包含的变更：

• fruity：必要时也在 macOS 上发起配对。
• fruity：调整 macOS CreateAssertion 错误处理，使失败时能够提供清晰的错误消息。
• fruity：处理 OPACK 布尔值和紧凑整数。iOS 18.4.1 上的配对需要后者支持。
• fruity：改进便携隧道错误处理。当我们使用 lockdown 判断 iDevice 是否支持隧道，却因缺少 lockdown 级别配对而失败时，直接假定操作系统支持隧道。
• fruity：为 Linux netif 等待逻辑添加超时。
• fruity：处理 NetworkManager 的 DISCONNECTED+CARRIER 状态。这样，当设备快速经过 state=DISCONNECTED、reason=CARRIER 时，我们会真正等待设备就绪。

又一个快速错误修复版本，因为软件开发很难！此版本解决以下问题：

• node：修复并非从源码构建时的模块解析。事实证明，构建目录中生成的 package.json 干扰了 bindings 软件包的模块根目录检测。这意味着我们的 搜索路径实际有误，只是依赖了这次误检测。

我们很高兴宣布 Node.js 绑定迎来重大更新！它们已经从头重写。过去，绑定依赖 Node.js 和 V8 API，而这些 API 不可避免地会随版本变化，因此每种 ABI 都需要单独构建；现在，我们的绑定改为面向 Node-API。这意味着单个二进制文件可以用于所有现代版本的 Node.js、Electron、nw.js 等。每种 OS/架构/libc 组合只需构建一个二进制文件。不仅如此，新绑定还是自动生成的，确保 frida-core 中的 API 变更能够立即反映出来；如有需要，只需调整自定义部分。

这个版本还包含其他一些好东西：

• DeviceManager：修复 HostSessionService 的 start() 被取消时，过早调用 close() 导致的崩溃。
• Web Service：修复 TLS 连接处理，因为远程地址逻辑此前没有考虑它们。
• API：修正 .gir 文件中的 FridaBase 引用。
• Bus：移除原本不应公开的 device 属性。

一如既往，衷心感谢所有贡献者和用户的支持。

此版本改进了对 Google 最新 32 位 ARM ART 运行时的支持、Linux 上的错误处理，以及对大端 ARM 架构的支持。

主要变化如下：

• 改进 frida-java-bridge，以支持 Google 最新的 32 位 ARM 二进制文件。 感谢 @Rwkeith。
• Linux 后端失败时向上传递 ptrace 错误。 感谢 @DoranekoSystems。
• 改进对大端 ARM 架构（armbe8、arm64be、arm64beilp32）的支持。
• 移除 Linux 后端中多余的硬件断点代码。

一如既往，感谢所有贡献者为改进 Frida 付出的宝贵努力。

这是一个解决 ELF 解析器问题的快速错误修复版本：

• elf-module：修复回退到实时内存时 check_str_bounds() 中的递归。该函数假定 ELF 由文件支持；回退到实时内存可能触发无限递归。现在添加了显式实时内存检查， 改为返回错误。

本次发布带来了几项重要改进和修复：

• interceptor：避免暂停期间分配堆内存。将已暂停线程的 ID 存入 GumMetalArray 而不是 GQueue， 可以防止已暂停线程持有 dlmalloc 锁时发生死锁。感谢 @mrmacete 做出这项改进。
• linux：修复缺少 ELF 时的 ModuleRegistry 初始化。枚举 RTLD 通知器和已加载模块以查找 DT_DEBUG 条目时，我们不再假定 ELF 文件存在。这修复了程序从 memfd 加载且在没有文件的 情况下启动时的问题。
• elf-module：无法映射文件时使用实时内存。对于以 memfd 为后端的模块，如果无法映射文件， 现在会使用内存中的 ELF，而不是直接放弃。
• linux：重做 glibc pthread 内部结构检测。不再通过解析机器代码来确定内部结构， 而是启动线程，以更稳健的方式解开这个谜题。

这是一个快速错误修复版本，改进了 Fruity 后端，并初步支持 iOS 18.4：

• darwin：更新 iOS 18.4 的注入器 dyld 初始化检测。

• fruity：更新 iOS 18.4 的注入器 dyld 初始化检测（#1154）。感谢 @pachoo 作出这项贡献。

• network-stack：缩短两次写入之间的延迟。一旦有部分空间可用就标记为可写， 不再等待低水位线。感谢 @mrmacete 作出这项改进。

• network-stack：修复 TCP 写入块长度（#1156）。这是 @mrmacete 带来的另一项修复。

• network-stack：始终发送已入队的数据。此变更确保即使队列中没有更多可用空间， 也会调用 pcb.output()，从而避免停滞。感谢 @mrmacete 消除这些恼人的停滞。

我们很高兴宣布 Frida 16.7.10，带来多项稳定性改进。特别感谢 @mrmacete 找出所有这些问题的根本原因，并修复 Apple 操作系统上的一处死锁。

本版本包含以下变更：

• network-stack：修复 TcpConnection 发送逻辑。
• network-stack：改进 VirtualStream 锁定机制，以增强批处理并避免在 Frida 线程上进行不必要的调度。
• virtual-stream：为了方便起见，允许在不持有锁的情况下调用 update_pending_io()，适用于子类在调用前无需更新其他状态的场景。我们的一个子类假定可以这样做，因为在把通用逻辑提取到 VirtualStream 基类之前，它一直如此工作。这意味着 16.7.4 中的重构引入了竞态条件，而此项变更将其修复。
• darwin：通过避免使用 flags 来优化线程枚举。这消除了堆分配，降低了 Interceptor 等使用场景中的死锁风险；在这些场景中，线程枚举用于按 ID 暂停和恢复线程。（由 @mrmacete 贡献。）

尽情使用吧！

事实证明软件开发真难！在上一个版本发布的同一天，我们又推出了一个快速错误修复版本， 用于解决出现的一些问题。非常感谢 @mrmacete 的贡献。以下是新内容：

• channel：遇到空缓冲区时跳出读取循环。（感谢 @mrmacete！）
• device-manager：修复拆除逻辑：之前在 HostSessionService 尚未被 start() 的情况下， 我们也会调用其 stop()。

这是一个快速错误修复版本，用于修复 Apple 操作系统上的崩溃。

感谢 @mrmacete 提供以下修复：

• darwin：修复 find_module_by_address 中的模块类型。此前的类型混淆会导致难以察觉的崩溃。

软件开发确实不容易，对吧？这是一个用于解决编译问题的快速修复版本：

• freebsd：解除 Binjector 的 sealed 限制以修复编译。目前 C 胶水代码仍依赖它的字段。

谁能想到软件开发会这么难呢？这里再提供一个快速修复，让一切继续顺利运行：

• qnx：取消 Qinjector 的 sealed 限制以修复编译问题。目前 C 胶水代码仍依赖其字段。

我们很高兴宣布 Frida 16.7.5 发布。此版本改进了构建系统和 API，并为 Darwin 平台 带来重要修复。以下是新内容：

• Darwin：修复 find_module_by_address 中的双重释放。（感谢 @mrmacete。）

• Darwin：更新线程列表指针切分，以支持近期 iOS 版本。在这些版本上， pthread_from_mach_thread_np() 内的线程列表指针通过 ADRP + LDR 引用， 而不是 ADRP + ADD。（感谢 @mrmacete 贡献。）

• API：修复 sealed 类的 VAPI 条目。

• API：移除一些意外暴露的类型。

• API：封闭不应被子类化的类，防止意外的子类化。

• 构建系统：为方便起见提供 Gio-2.0.gir，因此用户在构建语言绑定并将 Frida 作为子项目使用时，无需安装任何 GObject Introspection 软件包。

• 构建系统：修复未安装情况下的 frida_girdir。它现在会正确指向包含精炼后 .gir 文件的目录，而不是 Vala 编译器产生的原始文件。

本版本包含多项改进和修复，包括支持远程服务与通道，以及其他增强：

• Core：
  • 在主机会话中添加远程服务和通道支持，使 ControlService/frida-server 能够提供服务会话和通道。
  • 修复 ControlService 中远程设备的会话逻辑。
• Compiler：
  • 将 frida-compile 和 @types/frida-gum 升级到最新版本。
• Python 绑定：
  • 修复 IOStream.read_all() 对流结束的处理。

一如既往，祝你玩得开心！

好吧，软件开发有时确实很难。这里有一个修复 CI 的快速更新：

• ci：暂时从 package-linux 任务中移除 arm64beilp32。由于部分组件尚未移植到 此架构，在移植工作完成前，我们暂停将其纳入 Linux 软件包。

• ci：将 pypa/gh-action-pypi-publish 升级到最新版 v1。

同一天又发布了一个快速错误修复版本——事实证明，软件开发很难！

我挽起袖子修复了以下问题：

• droidy：修复 MAX_MESSAGE_LENGTH 声明。新的最大值超出了 uint16 的范围。

很高兴宣布 Frida 16.7.1 发布！此版本改进了多种架构支持，并修复一些棘手问题。非常感谢 @jpstotz 和 @philippmao 的宝贵贡献！

主要变化包括：

• fruity：跳过 UDID 为空的设备，修复 Windows 上的 Input/Output Error。（感谢 @jpstotz）

• droidy：提高消息大小限制，支持超过约 8 台 ADB 连接设备。（感谢 @philippmao）

• thumb-relocator：在 can_relocate() 中利用 LLD 对齐填充，提高 Hook Android 现代工具链生成的微小函数时的成功率。

• thumb-relocator：要求最后一条指令位于四字节边界且为双字节指令，从而限制填充检测。

• module-registry：在 Hook 前填充注册表，使 CodeAllocator 能找到附近的 ELF 头，从而修复微小 ELF 通知器的 Hook。

• ci：在 Linux CI 中新增 arm64be、armbe8 和 armhf-musl。

• env：在 32 位 ARM 上启用 Thumb 代码生成，以得到更小的二进制文件。

• linux：为 32 位 ARM 上的 musl 新增 pthread 探测。

• build：修复 musl 的 armhf triplet 解析。

• devkit：也为 Gum devkit 定义 GUM_STATIC，使用方无需自行定义。

• devkit-assets：现代化 Gum 示例。

• compiler：将 @types/frida-gum 升级到 18.8.1。

一如既往，祝你玩得开心！

对软件进行插桩时，一个具有挑战性的方面是处理各种事物的动态特性：线程会启动和终止， 模块会加载和卸载。

例如，如果使用 Stalker 跟踪正在执行的线程，那么在考虑插桩本身之前，就会遇到几个基本 挑战。

哪些线程？

你可以使用 Interceptor 在某处放置内联挂钩，当线程执行某项有趣的操作时，再使用 Stalker 跟踪其执行。不过，有时你会更愿意调用 Process.enumerateThreads()，并跟踪 自己认为有趣的线程。

每个线程都可能有可供使用的 name；如果没有，通常只能采用较模糊的办法。你可以查看 context 属性提供的 CPU 寄存器，也可以将它传给 Thread.backtrace() 来生成线程“指纹”， 或者观察在某项操作期间哪些线程占用了最多 CPU 时间。

但如果能够确定线程的入口点例程及其参数呢？现在可以了：

$ frida -p 163431
Local::PID::163431 ]-> Process.enumerateThreads()
[
    …
    {
        "id": 163560,
        "name": "SDLAudioP1",
        "state": "waiting",
        "context": { … },
        "entrypoint": {
            "parameter": "0x561210844900",
            "routine": "0x7fc7781237c0"
        }
    }
]

未来的线程

接下来的挑战是跟踪尚未启动的线程。在此之前，这需要挂钩操作系统专用的内部机制，而维护 跨平台 Agent 中的这类代码相当复杂。

我很高兴地宣布，现在我们提供了专门解决这个问题的 API：

const observer = Process.attachThreadObserver({
  onAdded(thread) {
    …
  },
  onRemoved(thread) {
    …
  },
  onRenamed(thread, previousName) {
    …
  }
});

onAdded 回调会立即接收所有现有线程，因此无需担心竞态条件，就能轻松处理初始状态与 后续更新。如果参数是刚创建的新线程，此调用会从该新线程同步发生。因此，这正是对它调用 Stalker.follow() 的理想位置，不会错过早期执行的任何指令。

相应地，onRemoved 回调会在线程即将终止时通知你。该调用从相应线程同步发生，因此仍有 机会在线程上下文中执行一些最后的代码。

最后，onRenamed 回调会在线程的 name 刚刚变化时通知你，同时提供旧名称；如果之前 没有名称，则为 null。

所有回调都是可选的，但必须至少提供一个。

之后如果想停止观察，只需执行：

observer.detach();

未来的模块

线程会来去，模块/共享库也一样。你可能会很早应用插桩，以免错过初期活动。然而，应用插桩 越早，应用其他部分尚未加载的可能性就越大。

卸载也许根本不会发生，可能是因为应用不会这样做，也可能是动态加载器不支持；但它仍是你 可能需要处理的一个方面。

过去，处理这一切需要挂钩操作系统专用的内部机制，而维护用于跨平台 Agent 的这类代码会 带来所有相关复杂性。

我非常高兴地告诉大家，现在我们也为此提供了 API：

const observer = Process.attachModuleObserver({
  onAdded(module) {
    …
  },
  onRemoved(module) {
    …
  }
});

与 Process.attachThreadObserver() 一样，onAdded 回调会立即接收所有现有模块，因此无需 担心竞态条件，就能轻松处理初始状态与后续更新。如果参数是一个全新模块，此调用会在模块 加载完成后、应用有机会使用它之前同步发生。这是使用 Interceptor 等工具应用插桩的好时机。

相应地，onRemoved 回调会在模块消失时通知你。

两个回调都是可选的，但必须至少提供一个。

之后如果想停止观察，与线程观察器 API 一样，只需执行：

observer.detach();

分析代码性能

Frida 核心 C 库 Gum 中有一项鲜为人知的功能：名为 gum-prof 的库。它为代码性能分析提供 了一些轻量构件。从本次发布开始，我们终于将其开放给 JavaScript。

先从主要组件 Profiler API 开始。它是一个基于 Interceptor 构建的简单最坏情况分析器：

const profiler = new Profiler();
const sampler = new BusyCycleSampler();
for (const e of Process.getModuleByName('app-core.so')
      .enumerateExports()
      .filter(e => e.type === 'function')) {
  profiler.instrument(e.address, sampler);
}

传统分析器会按一定频率对调用栈采样，而在这里，你可以精确决定希望分析哪些函数。这正是 事情变得有趣的地方。

这些函数中的任何一个被调用时，分析器都会在进入时获取一个样本，在返回时再获取一个。 然后两者相减，计算本次调用的开销。如果结果大于此前为该函数看到的值，它就会成为新的 最坏情况。

发现新的最坏情况时，只知道大部分时间/周期等花在某个函数上不一定足够。例如，该函数 可能只在接收某些输入参数时才变慢。

在这种情况下，调用 instrument() 时可以为特定函数传入 describe() 回调。回调应从 参数列表和/或其他状态中捕获相关上下文，并返回描述刚刚发现的新最坏情况的字符串。

之后调用 generateReport() 时，会发现计算出的描述嵌入在每条最坏情况记录中。

Sampler

你可能已经在刚刚介绍的 Profiler 示例代码中注意到，我们现在还引入了“sampler”的概念。 实际上共有六种不同实现。它们都实现同一个 sample() 方法，返回表示最新测量值的 bigint。 具体表示什么取决于 sampler，但 Profiler 并不关心，因为它只关注两个时间点之间的变化量。

不过，这些 sampler 也可以直接用于其他目的。

以下是全新的 sampler：

• CycleSampler：测量 CPU 周期，例如在 x86 上使用 RDTSC 指令
• BusyCycleSampler：只测量当前线程消耗的 CPU 周期，例如在 Windows 上使用 QueryThreadCycleTime()
• WallClockSampler：测量经过的时间
• UserTimeSampler：测量特定线程在用户空间中花费的时间
• MallocCountSampler：统计 malloc()、calloc() 和 realloc() 的调用次数
• CallCountSampler：统计你所选函数的调用次数

UserTimeSampler 的一个有趣用法是使用线程 ID 构造它，让它测量该特定线程在用户空间中 花费的时间。为每个线程构造一个这样的 sampler，并分别采集一个样本后，可以用某种特定 方式操作应用，例如确保它收到某个特定网络数据包。然后从每个 sampler 采集第二个样本， 减去之前的样本，计算变化量/增量。由此可知哪个线程在用户空间中花费的时间最多，也就知道 接下来可能应该对哪个线程调用 Stalker.follow() 进行深入研究。

结语

此外还有一系列令人兴奋的变更，请务必查看下面的变更日志。

感谢 @hsorbo 与我一起对线程和模块观察功能的各个随机部分进行了愉快而高效的结对 编程！🙌 也感谢 @mrmacete 和 @as0ler 帮助测试和排查错误 🥳

尽情使用吧！

变更日志

• 引入 Process.attachThreadObserver() 和 ThreadRegistry，用于监视线程创建、终止和重命名。
• 引入 Process.attachModuleObserver() 和 ModuleRegistry，用于监视模块加载和卸载。
• gumjs：向 JavaScript 公开 Gum 的 Profiler 和 Sampler API。
• gumjs：添加 NativePointer#writeVolatile() API。感谢 @DoranekoSystems！
• fruity：修复 Linux getifaddrs() 逻辑中的崩溃，该逻辑未正确处理没有地址的接口。
• memory-access-monitor：提供对线程 ID 和寄存器的访问。
• darwin：修复拆卸期间存在竞态的内存泄漏。
• linux：避免注入期间出现虚假的 .so 范围。
• linux：处理注入期间的兼容范围。
• server：添加 –device，用于提供指定设备。
• compiler：将 @types/frida-gum 升级到 18.8.0。

本次发布带来了重要的错误修复，并优化了 Linux 和 Android 上的易失内存写入。 非常感谢 @DoranekoSystems 的贡献。

• fruity：修复上一版本引入的通过 CoreDevice 执行 lockdown 时的回归；为了支持 com.apple.crashreportmover 等服务的网络 lockdown，RSDCheckin 现在包含 EscrowBag。 事实证明，这会破坏某些无权与 AppleKeyStoreUserClient 通信的服务。现在我们维护一份 此类服务的列表，对它们省略 EscrowBag。感谢 @as0ler 报告并协助排查问题。

• darwin：修复 Apple Silicon 上的 sysroot 检测，使我们能够正确解析模拟器进程中的模块。 感谢 @stacksmashing 报告问题。

• linux：针对 Linux/Android 优化 NativePointer#writeVolatile()（JS）/ gum_memory_write()（C）（感谢 @DoranekoSystems）。如果内核支持，便使用 process_vm_writev()，从而避免解析内存映射。这意味着它现在快了数千倍。

本次发布带来一系列 Linux 和 Android 支持方面的改进与修复，其中包含 @kaftejiman 和 @DoranekoSystems 的贡献。我们还改进了通过网络与 Apple 设备通信的方式。

新增内容如下：

• linux：改进注入器，避免对 memfd 区域进行有风险的代码交换（感谢 @kaftejiman）。 Memfd 区域可能不可写，而且与常规区域不同，缺少可写位时 ptrace() 也帮不上忙。

• linux：放宽注入器对 Android libc 的匹配条件（感谢 @kaftejiman）。 这意味着即使 APEX 被绑定挂载，我们仍然可以匹配它们。

• linux：针对 Linux/Android 优化 NativePointer#readVolatile()（JS）/ gum_memory_read()（C）（感谢 @DoranekoSystems）。如果内核支持，便使用 process_vm_readv()，从而避免解析内存映射。这意味着，与直接访问相比， 它不再慢 1000 多倍，而是只慢约 1.45 倍。

• fruity：支持 CoreDevice 的网络 lockdown。我们需要在 RSDCheckin 中提供远程解锁主机密钥。 感谢 @as0ler 和 @mrmacete 报告问题并协助查明根本原因。

此版本带来重要修复与改进：

• objc：处理扩展的 block 类型编码（感谢 @mrmacete）。
• module：撤销此前对 NativeModule 生命周期的优化，因为 GLib 补丁中的底层性能问题已经解决。
• darwin：修复使用别名时 Module.load() 可能失败的问题。在 macOS >= 13 上，现在使用 _dyld_get_dlopen_image_header() 按地址解析模块。
• linux：恢复 ARM BE8 支持，重新兼容大端 ARM 系统。

此版本的主要变化是恢复 Windows 注入器；近期的 Gum.Module 重构曾破坏它。此外，我们还提升了各平台底层 GLib 原语的性能，重点改进实现静态分配清理的补丁。之所以需要这样做，是因为 Frida 注入的载荷寿命可能短于其所在进程。

尽情体验吧！

新一轮改进与修复进一步提升了 Frida 的稳定性和性能，感谢 @mrmacete 提供宝贵反馈。本次更新如下：

• gumjs：通过 idle source 延迟 unref，修复 Module 终结器中的崩溃。这既避免了 QuickJS 挂起/恢复补丁不支持从终结器调用所导致的问题，也省去了大量模块销毁期间反复挂起和恢复 JS 执行的开销。更好的长期方案是引入 ModuleObserver 管理 Module 生命周期，并在模块添加或移除时发出信号。

• module：为所有 Module 对象使用同一把锁，加快 NativeModule 生命周期处理。此更改提升了性能；待 GLib 静态分配清理补丁改用更适合跟踪互斥锁的数据结构后，我们会再次审视这一方案。

这是一个包含若干重要修复和改进的新版本：

• gumjs：在减少模块引用计数时放弃 JS 锁。这可避免 dispose() 释放缓存句柄时发生死锁。这类操作通常需要获取运行时链接器锁。另一个线程可能已持有该锁，同时等待 JS 锁。发生这种情况的常见场景是，agent 向运行时链接器注册了一个回调，每当加载或卸载模块时就会调用。

  感谢 @mrmacete 报告。

• agent：在版本脚本中排除特定于操作系统/体系结构的符号。FreeBSD 14.2 的默认工具链等较新的工具链，不接受对不存在符号的引用。我们不再列出只为 Android 构建定义的 JNI_OnLoad，而是为 Android 使用单独的版本脚本。

• ci：将 CI 从已经结束生命周期的 FreeBSD 14.0 迁移到 FreeBSD 14.2。我们的 FreeBSD CI 在过去几周的某个时候坏了，一直没被发现，直到它导致上一个版本未能发布。糟糕！

很高兴宣布 Frida 16.6.0 发布，它显著改进了模块符号处理和性能，并修复了一些错误。

以下是主要亮点：

• android：改善 ART 兼容性：
  • 当缺少导出项时查找符号，因为 Frida 现已支持解析 .gnu_debugdata。
  • 处理 runFlip 签名的变化（感谢 @matbrik）。
• android：修复 enumerateLoadedClasses() 中的溢出（感谢 @123edi10）。 现在会逐步创建和清理全局引用，而不是在开始和结束时一次性处理全部引用。
• android：在 registerClass() 中支持静态方法（感谢 @5andr0）。
• java：修复 32 位系统上由 JVMTI 驱动的 Java.choose()。
• module：将 Module API 改为实例方法，以便高效执行多次查询。之前只在 JavaScript（GumJS）层以这种方式建模，其中这类 JS 对象会将模块路径作为字符串传给 enumerateExports() 等每次查询。底层 C API 现在也以相同方式建模。
• gumjs：添加 findSymbolByName() 和 getSymbolByName() 方法。 直接以原生方式按名称查找符号，而不是枚举所有符号后再在 JavaScript 中过滤。
• module：优化 find_symbol_by_name() 的回退路径。当 Module 实现缺少优化的符号查找方法时， 构建排序索引并对其进行二分搜索。
• elf-module：未找到符号时使用 MiniDebugInfo。当 enumerate_symbols() 遇到内存中 没有符号的 ELF 时，实例化一个离线 ElfModule 实例并解析 .gnu_debugdata 节。 解压其中嵌入的 ELF，并将其符号作为回退。
• ncm：将每次传输的数据报上限设为 16，改善用户空间 USB CDC-NCM 驱动的性能 （感谢 @hsorbo 与我结对编程！）。
• 移植到新的 Gum.Module API。已转为实例方法，以便高效执行多次查询。
• 停止支持在无 GObject 的情况下运行。节省的体积很小，不足以抵消增加的复杂性和降低的代码可读性。
• gumjs：修复 V8 NativeCallback 释放后使用问题（非 Interceptor），其中 CpuContext 的作用域过窄。

一如既往，祝大家黑客愉快！

糟糕，软件开发真难！这里又有一个快速发布，用于解决我们今天早些时候遗漏的问题。

我们修复了 Meson 构建脚本中的一个问题：在 frida-core 最近的变更之后，modulemap 依赖项 没有被正确指定。具体而言，core_public_h 现在是一个自定义目标索引，因此不能再直接使用。 我们现在改为依赖它的父目标 core_api。

特别感谢 @hsorbo 与我共同完成此项修复。

这个令人兴奋的新版本为多个组件带来性能提升和错误修复，尤其是 Fruity 后端。@hsorbo 与我合作完成了以下改进：

• fruity： 通过多重传输提升 NCM 性能和数据传输效率。
• fruity： 改进用户空间 NCM 驱动以执行批处理，减少突发流量时的丢包。
• fruity： 启用 lwIP TCP 时间戳和 SACK，与 Linux IP 栈默认值保持一致并提升网络性能。
• fruity： 将 lwIP TCP 最大报文段长度（MSS）提升到 4036，改善 TCP 隧道性能。
• fruity： 考虑 frida-server 的 bind() 延迟，提高连接建立可靠性。
• fruity： 修复拆卸期间创建 USB 操作时的崩溃。
• fruity： 在内核 NCM 可用时避免不必要的 USB 访问，改进非 macOS 系统上的 USB 设备处理。
• fruity： 确保即使存在冲突服务也能正确建立连接，修复直连通道可靠性。感谢 @mrmacete 协助定位。

• fruity： 改进 TcpTunnelConnection 拆卸，确保远端关闭连接时正确清理。

• api： 生成正确的 GObject Introspection Repository（GIR），包含必要类型并省略内部类型。
• api： 避免在 API 中公开内部类型。

• api： 省略涉及 HostSession 的 API。

• build： 修改输出逻辑，避免重复写入输出文件，加快增量构建。
• build： 利用 Meson 的 custom_target() 多输出支持，避免多次解析 API。
• compat： 创建相对子项目符号链接，使源码树移动后仍可构建。

• compat： 修复 compat.symlink_to() 对子项目的错误处理。

• windows： 修复 PID 不存在时的 cpu_type_from_pid()。
• windows： 在 Windows 11+ 上使用 GetProcessInformation()，确保正确使用 ProcessMachineTypeInfo。

一如既往，非常感谢 @hsorbo 和 @mrmacete 为本次发布作出的宝贵贡献。

这是一个令人兴奋的新版本，包含跨平台的改进和新功能。以下是新内容：

Fruity 后端改进

@hsorbo 和我一直在努力增强 Fruity 后端，我们很高兴分享以下改进：

• 添加对 TCP 隧道协议的支持，并将其设为默认值，以匹配 Apple 的新行为。 可以使用 FRIDA_FRUITY_TUNNEL_PROTOCOL 环境变量切回 QUIC。
• 修复旧版 OS 的隧道逻辑边界情况，即使 usbmuxd 不可用也能确保可靠运行。
• 优雅关闭 TunnelConnection，以提高稳定性。
• 修复拆除期间启动 USB 操作时可能出现的挂起，防止传输卡住。
• 修复 QuicTunnelConnection 拆除逻辑，正确处理关闭操作期间的错误。
• 放宽 NCM 接口存在性检查，只需一个可用的网络接口。
• 调整为始终先尝试 USB 传输，因为网络传输可能更慢或不可用。
• 改进跳过受限回退时对超时情况的处理。
• 现在预期网络设备会快速响应与配对服务的连接，从而在设备已休眠时改善用户体验。
• 修复新式设备的 CoreDevice UDID 逻辑。

Android

• 当 extractNativeLibs 设为 false 时，Gadget 现在支持从 APK 加载资产， 改善了对现代 Android 应用的兼容性（感谢 @gergesh）。
• 恢复注入器对共享 libc 区间的处理，当目标进程最低的 libc.so 区间是共享映射时， 确保行为正确（感谢 @lx866）。

Linux

• 改善注入器与 MUSL 的兼容性，处理 loader 字符串的差异（感谢 @luckycat889）。
• 支持在构建 helper 时覆盖配置，为构建提供更大灵活性（感谢 @luckycat889）。
• 为注入器的远程调用分配栈，改善与 Go 应用等使用小栈的程序的兼容性（感谢 @ajwerner）。
• 添加重建 helper 二进制文件的 CI，确保源码与已检入的二进制文件保持一致（感谢 @ajwerner）。
• 当 $TMPDIR 为 noexec 时选择其他临时目录

跨平台

• 在构建系统中添加对非 UTF-8 locale 的支持，确保更好地兼容使用各种 locale 设置的系统 （感谢 @JunGe-Y）。
• 在构建系统中添加对 PowerPC 架构的支持。
• 在 frida-inject 和 RpcClient 内部添加对二进制数据处理的支持。

祝大家黑客愉快！

这是一个快速错误修复版本，进一步改进 Fruity 后端。@hsorbo 和我给咖啡杯续满咖啡，集中完成了以下修复：

• fruity：修复 TcpConnection 中的释放后使用。错误回调可能在 PCB 已被释放后才调用，因此清除其用户数据会造成释放后使用，把 NULL 指针写入未知位置。
• fruity：修复 DTXArgumentList.parse() 的 GValue 初始化；遇到对象时我们使用了错误的 setter。GLib 的运行时检查捕获了此问题，但由于我们通常不启用这些检查进行构建，它一直未被发现。
• payload：修复 AddressSanitizer 构建回归。

原来 Frida 16.5.3 中混入了一项严重的稳定性回归：当收到不是来自 CoreDevice 隧道的 入站连接时，frida-server 会崩溃。感谢 @mrmacete 在有问题的版本发布后仅几小时 就完成调查和修复。🎉 尽情享用！

上一版本的二进制文件未能发布，原因是一个本不应升级 frida-node NAN 依赖的脚本将其升级，而最新代码又破坏了 Electron 支持。此版本回滚了该变更，同时将 frida.Compiler 的 @types/frida-gum 升级到 18.7.1。

很高兴为大家带来又一个错误修复版本，进一步改进 Fruity 后端和 iOS 稳定性， 并修复使用正则表达式扫描内存时的问题。

下文未特别注明作者的改动，均由 [@hsorbo][] 和我在一系列愉快的结对编程中完成。

长话短说，改动如下：

• memory：将内存扫描的正则表达式模式设为原始模式，使搜索在并非有效 UTF-8 的二进制区域中 也能可靠工作。感谢 @mrmacete！
• web-service：关闭已移除动态接口的连接，避免它们一直残留，直至耗尽文件描述符。
• network-stack：处理 TcpConnection 被突然销毁的情况。此前我们会释放 TCP PCB， 却未能通知任何仍然存活的 TcpIOSource 实例和被阻塞的 TcpInputStream.read() 调用。
• network-stack：修复对等端关闭时竞争条件导致的 TCP 数据丢失。关闭操作会让我们释放 PCB， 随后 recv() 逻辑因为 PCB 已不存在而提前返回。此时 RX 缓冲区中可能仍有数据， 但应用无法看到它们。
• network-stack：修复 TcpInputStream.read() 中的竞争条件：notify::pending-io 信号在调用 is_readable() 之后、连接信号处理程序之前触发。
• fruity：使用 USB 产品字符串作为传输名称。
• fruity：修复 iOS < 16 上的 USB 模式解析；此时模式是一个 3 字节 blob。
• fruity：向上传递 USB 权限错误。
• fruity：遇到 17 之前版本的 iOS 隧道服务时退出，而不是崩溃。
• control-service：修复 CoreDevice 系统上的可靠性问题。在所有接口上监听的单个传输代理， 可能会在尝试从隧道内部与其通信时导致过早的 TCP RST。具体原因尚不清楚， 但我们已经确认，为每个动态接口/隧道设置一个代理可以解决问题。我们还观察到， 监听所有接口但仅限 IPv6 也能避免该问题。
• meson：修复以 GLib 作为子项目时的 i/tvOS 编译。
• meson：在 FreeBSD 上禁用 Fruity 及相关组件，因为我们现在依赖一个仅存在于自有 libusb 中的 API。如果有人希望在 FreeBSD 上使用这些后端，修复起来应该不会太难，非常欢迎提交 PR。

这是一个进一步改善 Fruity 后端的快速错误修复版本。@hsorbo 和我倒满咖啡， 一起敲定了以下修复和调整：

• fruity：隧道设置失败时复用 NCM 对端。
• fruity：处理 iDevice 尚未与任何主机配对的情况。
• fruity：处理 USB TunnelConnection 断开。
• fruity：修复不可靠的模式切换激活。
• fruity：修复使用我们的 NCM 驱动时的拆除逻辑。
• fruity：修复非 macOS 平台上 find_tunnel() 的错误编组。
• fruity：广播我们对 RemoteXPC 协议的支持。

由于 watchOS 上的一项构建回归，上一个版本的二进制文件未能发布；本版本迅速修复了 这个问题。

有些人可能遇到过这种情况：内存中的某段数据看起来很有意思，你想定位负责处理它的代码。你或许尝试过 Frida 的 MemoryAccessMonitor API，却发现页面粒度很难使用。也就是说，可能必须收集大量样本，才有机会捕获访问该页面上特定字节的代码。在使用 4K 页面的系统上已经很困难，在使用 16K 页面的现代 Apple 系统上则更糟。

为解决这个问题，@hsorbo 和我倒满咖啡开始工作，实现了硬件断点和观察点支持。简而言之，Process.enumerateThreads() 返回的线程对象现在提供 setHardwareBreakpoint()、setHardwareWatchpoint()，以及之后用于取消它们的对应方法。将这些方法与 Process.setExceptionHandler() 结合使用：在异常处理器中调用取消方法并返回 true，表示异常已处理，应恢复执行。

演示时间

来实际试用这些新 API。目标选择 id Software 在 2024 年全新再版的 DOOM + DOOM II。

首先要弄清子弹数量存储在内存中的什么位置。编写一个小型 Agent 来帮助完成：

let matches = [];

function scan(pattern) {
  const locations = new Set();
  for (const r of Process.enumerateMallocRanges()) {
    for (const match of Memory.scanSync(r.base, r.size, pattern)) {
      locations.add(match.address.toString());
    }
  }
  matches = Array.from(locations).map(ptr);
  console.log('Found', matches.length, 'matches');
}

function reduce(val) {
  matches = matches.filter(location => location.readU32() === val);
  console.log('Filtered down to:');
  console.log(JSON.stringify(matches));
}

function patternFromU32(val) {
  return new MatchPattern(ptr(val).toMatchPattern().substr(0, 11));
}

然后把它加载到游戏中：

$ frida -n doom.exe -l demo.js
…
[Local::doom.exe ]->

已知当前有 50 发子弹，因此查找所有包含数值 50 的堆分配；该值以原生 uint32 编码：

[Local::doom.exe ]-> scan(patternFromU32(50))
Found 6947 matches

结果相当多。发射一发子弹，再检查哪些位置现在包含数值 49，以此缩小范围：

[Local::doom.exe ]-> reduce(49)
Filtered down to:
["0x1fbf5191884"]

找到了！既然知道子弹数量存储在何处，下一步就是找到开火时更新子弹数量的代码。为 Agent 再添加一个辅助函数：

function installWatchpoint(address, size, conditions) {
  const thread = Process.enumerateThreads()[0];

  Process.setExceptionHandler(e => {
    console.log(`\n=== Handler got ${e.type} exception at ${e.context.pc}`);

    if (Process.getCurrentThreadId() === thread.id &&
        ['breakpoint', 'single-step'].includes(e.type)) {
      thread.unsetHardwareWatchpoint(0);
      console.log('\tDisabled hardware watchpoint');
      return true;
    }

    console.log('\tPassing to application');
    return false;
  });

  thread.setHardwareWatchpoint(0, address, size, conditions);

  console.log('Ready');
}

调用它：

[Local::doom.exe ]-> installWatchpoint(ptr('0x1fbf5191884'), 4, 'w')
Ready

接着切回游戏，再发射一发子弹：

[Local::doom.exe ]->
=== Handler got system exception at 0x7ffc2bc2fabc
        Passing to application

=== Handler got single-step exception at 0x7ff6f0a21010
        Disabled hardware watchpoint

很好，看起来很有希望。来解析该地址的符号：

[Local::doom.exe ]-> ammoCode = ptr('0x7ff6f0a21010')
"0x7ff6f0a21010"
[Local::doom.exe ]-> ammoModule = Process.getModuleByAddress(ammoCode)
{
    "base": "0x7ff6f0730000",
    "name": "DOOM.exe",
    "path": "C:\\Program Files (x86)\\Steam\\steamapps\\common\\Ultimate Doom\\rerelease\\DOOM.exe",
    "size": 15495168
}
[Local::doom.exe ]-> offset = ammoCode.sub(ammoModule.base)
"0x2f1010"

使用 r2 仔细查看：

可以看到，异常处理器中观察到的程序计数器位于触发观察点的 sub 指令之后一条指令上。

因此可以设置一个内联 Hook，每次开火时都会触发：

Interceptor.attach(Module.getBaseAddress('doom.exe').add(0x2f1010), function () {
  const ammoLeft = this.context.rax.add(4).readU32();
  console.log(`Shots fired! Ammo left: ${ammoLeft}`);
});

[Local::doom.exe ]-> Shots fired! Ammo left: 42
Shots fired! Ammo left: 41
Shots fired! Ammo left: 40
Shots fired! Ammo left: 39
Shots fired! Ammo left: 38

同样可以轻松制作无限弹药作弊功能：

Interceptor.attach(Module.getBaseAddress('doom.exe').add(0x2f100d), function () {
  this.context.rbx = ptr(0);
  console.log(`Shots fired! Pretending no ammo was actually used`);
});

[Local::doom.exe ]-> Shots fired! Pretending no ammo was actually used
Shots fired! Pretending no ammo was actually used
Shots fired! Pretending no ammo was actually used
Shots fired! Pretending no ammo was actually used
Shots fired! Pretending no ammo was actually used

看，无限弹药！

注意，也可以用 Memory.patchCode() 把 sub 替换为 3 字节 nop 来实现，X86Writer 可通过 putNopPadding(3) 完成。Interceptor Hook 的优势是脚本卸载时会自动回滚，而且便于执行任意代码。

ARM 上的 Windows

此版本另一项亮点是支持 ARM 上的 Windows。这意味着 arm64 版 Frida 可以注入原生 arm64 进程，也可注入模拟的 x86_64 和 x86 进程。

不过我们尚未提供二进制文件，因为仍在等待 GitHub 向开源项目提供 arm64 runner；目前只有 Team 和 Enterprise Cloud 客户可以使用。技术上可以从 x86_64 构建机交叉编译，但我们很快遇到 Meson 的 MSVC 支持问题，因此决定暂缓。

结语

此外还有许多令人兴奋的变化，请务必查看下面的变更日志。

尽情体验吧！

变更日志

• thread：支持硬件断点和观察点。
• fruity：修复 perform_on_lwip_thread() 中的死锁。
• windows：新增 arm64 支持。
• windows：将 Exceptor 迁移到 Microsoft 的 VEH API。
• linux：分离时处理进程已退出的情况。感谢 @ajwerner！
• linux：修复 MIPS 上的 clone() 包装器。
• java：处理 Android GC 周期处理器未导出的情况。感谢 @thinhbuzz！
• java：初步支持 Windows 上的 OpenJDK 17。感谢 @FrankSpierings！
• meson：将 frida-netif 加入公共 frida-core，使 frida-core devkit 包含所有所需符号。
• node：新增便利工厂函数 Cancellable.withTimeout()。感谢 @hsorbo！
• node：新增便利方法 Cancellable.combine()。感谢 @hsorbo！

这是一个进一步改进 Fruity 后端的快速错误修复版本；@hsorbo 和我装满咖啡杯， 一鼓作气完成了以下修复：

• tunnel-connection：接通缺失的流关闭逻辑。
• tunnel-connection：确保 JSON 请求独占一个 UDP 数据包。打开隧道时，如果一个 数据报和流数据落在同一个 UDP 数据包中，似乎会出现问题。我们增大了虚拟数据报 以避免这种情况。
• tunnel-connection：连接断开后始终避免写入，否则会导致崩溃。
• network-stack：从 lwIP 线程调用 perform_on_lwip_thread() 时直接处理， 而不是发生死锁。

这是一个解决若干问题的快速错误修复版本：

• tunnel-interface-observer：修复 SCDynamicStoreCopyKeyList() 失败时 i/tvOS 上的 start() 崩溃。感谢 @mrmacete！
• darwin-mapper：在构造函数之前初始化 TLV。感谢 @jiska！
• darwin-mapper：修复 arm64 的 TLV 初始化运行时代码。感谢 @jiska！
• arm64-writer：修复 UBFM 和 LS{L,R} 的编码。感谢 @jiska！

这是一个进一步改进 Fruity 后端的快速错误修复版本：

• lockdown-client：向上传播 CONNECTION_CLOSED 错误。感谢 @hsorbo！
• fruity：使 find_usbmux_device() 不再抛出异常。感谢 @hsorbo！
• fruity：防止 lockdown 发生 open.- ->close 循环。
• fruity：修复已关闭 lockdown client 的失效处理。感谢 @hsorbo！

这是一个解决 Windows 崩溃的快速错误修复版本：

• fruity：修复在 Windows 上枚举网络接口时的崩溃。部分接口没有单播地址， 因此需要忽略。感谢 @xiofee！

此版本包含大量改进：

• fruity：如果存在，则使用 USB 传输层的 UsbmuxDevice，以便访问环回接口并 获得更好的性能。
• fruity：在非 macOS 平台上处理不支持隧道的设备。
• fruity：如果存在，则公开 USB 传输层中的名称。使用 UsbmuxTransport 时， 它提供的名称描述性更强。
• gumjs：确保在构建 devkit 前先构建 Gum .a。感谢 @Hexploitable！
• gumjs：生成更简单的枚举值查找代码。
• spinlock：整合为单一实现。
• java：修复 Android >= 15 的 art::Thread::DecodeJObject。感谢 @esauvisky！

这是一次快速的错误修复版本，解决了几个问题：

• xpc-client：在 request() 中接入 cancellable，以支持取消 Fruity macOS CoreDevice 后端中的 remotepairingd 请求。
• java：正确处理 Android ART CMC GC 策略。感谢 @mbricchi！
• java：修复较新 ART APEX 上的 Java.choose()。感谢 @mbricchi！