前言

书接上文，在理解了 frida 是如何对代码进行 hook 的以后，接下来笔者打算研究一下 Frida 是如何与用户进行交互实现动态的 hook 。因此还是按照前文的逻辑，我们从 frida-core 开始。

前篇：《Frida-gum 源代码速通笔记》

本文内容目录

本文主要涉及的是 Frida-core 模块的实现代码分析，大致内容包括：

• Frida-Core
  • Frida-Server
    • 进程注入
    • frida-server 工作流程
    • frida-agent
    • frida-helper
  • Frida-Gadget
  • launchd
  • 总结 / 以及一个奇怪的问题

Frida-Core

进程注入

首先要解决的第一个问题是，我们尽管知道 Frida-gum 能够对程序进行动态插桩，并也在上一节中介绍过它的工作原理，但是也正如我们所知，无论在 Android 还是 iOS 或者其他平台，进程和进程直接相互是透明的，就算对 Frida 来说目标进程并非透明的，但是对目标进程来说，至少 Frida 也该是透明的。但是现实情况显然是，二者往往需要相互之间识别并交互。

那么解决方案似乎也呼之欲出了，既然两个进程不能相互识别，那么让它们成为一个进程不就好了？

由于笔者本文主要是面向 iOS 的，因此下文中笔者会选择 darwin 平台的代码进行分析。对于 Android 平台，frida 的实现是有所不同的，不过大体的逻辑还是有些相似的，仅供参考。

本部分的代码主要定义在 inject/src/darwin/darwin-host-session.vala 中，可以注意到，它是由 vala 编写的语言，这对我来说有些陌生。不过好在它的语法结构和 C 很像，并且编译 vala 的过程其实就是把它先转为 C 代码再使用 C 的编译器完成的，因此大体上还是能够从语意上理解逻辑。

糟糕的是，我的 VSCode 不再支持代码跟踪了，即便装了插件也还是如此，要命。

跟入 inject_library_file ：

因此再次跟入 inject_library_file ：

好吧，我们再次跟入：

继续跟入 _inject ：

可以看见此处将会使用 _inject_into_task 实现进程注入的方式，这里跟入 _frida_darwin_helper_backend_inject_into_task ，由于函数体比较大，这里省略部分代码：

正如注释中所述，其实就是通过 iOS 平台本身提供的 api 往进程的内存空间中开辟内存段。

关键是接下来的部分。如果该平台允许存在 rwx 段那么将执行如下代码：

注意，对于已越狱的 iOS 设备，这么做是可行的；但是对于非越狱设备，系统并不允许由用户分配带有执行权限的内存段，同理也不允许修改段段权限为可执行。

而对于不支持上述条件的情况，包括设备未越狱，那么则使用如下分支：

笔者大致查了一下，在 iOS 中，程序的代码段都是需要经过签名验证的，因此对于未经过签名的代码段是会因此而产生异常的，所以在 iOS 上不能使用 smc 也是这个原因，因为代码要么不可变要么不可执行。但反过来，它们允许用户删除对代码段的执行权限，这是合法的。

这里我们跟入 gum_code_segment_realize 看看是如何得到可执行内存段的：

以上操作完成了构造一个 dylib 的行为，接下来程序将会调用 gum_code_segment_try_map 将该动态库映射到内存中：

注意到此处使用 mmap 去映射文件到 target_address 并给出了可读可执行的权限标志。接下来这段内存就已经被注入到进程中去了。

其实这个地方用到的就是一个小 trick。正如前文所说，iOS 不允许让一个 rw 页面变为 rx，也不允许让 rx 页面变为 rwx ，但是加载可执行文件的行为是不被禁止的，因为那属于正常的诉求，因此这里用需要注入的代码去构建可执行文件，最后再将其映射到内存中去，这样就没有修改任何页面了权限了。

其实实际原因是，对于正常组织的代码段，有一个 max_protection 去限制能够允许 mprotect 设定权限的范围，默认情况下会被限制为 rx，也就是说只允许对这段内存给出 rx 中的范围。但是通过 mmap 创建的内存段的 max_protection 是允许给出 rwx 权限的。所以实际是只要最后是用 mmap 去构建注入内存，总会有办法解决的。

您也可以参考本文：

最后调用 mach_vm_remap 把这段内存重新映射回去即可。

frida-server

在介绍了大致的 frida 进程注入的原理以后，接下来我们正式开始跟一下 frida 具体是如何开始工作的。

在启动 frida 后，程序将从 run_application 开始向下调用 application.run ，然后再往下调用 start.begin，此时，它将通过 service.start 去启动一个 ControlService ：

接下来我们跟入 WebService ：

而 handle_start_request 会向下调用 do_start 完成具体的工作，包括监听地址，设置处理函数等：

跟入 on_websocket_opened ：

此处发送了 incoming 信号，而对应的处理被在构造函数中可见：

从 on_server_connection 跟入 handle_server_connection ：

对于不需要认证的情况，将会调用 setup_control_channel 完成初始化，而该函数将会返回一个 ControlChannel 对象，其构造函数如下：

该对象在构造时将会把 HostSession 、AuthenticationService 和 TransportBroker 都注册到 Dbus 对象中，这会使得远程的电脑端能够直接调用这些类中的方法从而实现通信。

而主要的负责通信的部分都由 ControlChannel 中的函数负责实现，常见的几个函数实现如下：

可以看到，当我们使用 spawn 或者 attach 去附加或启动某个进程时，最终还是调用了 host_session 中的对应函数。

这里的 parent 指的是 ControlService 对象

而 host_session 其实是一个 BaseDBusHostSession 对象，该对象是平台相关的，不同平台又不同的实现方法，以 drawin 为例，我们跟一下 spawn：

可以看出，实际上它只是一个封装，会向下调用 frida-helper 中的 spawn 去实现。对于 darwin 平台，helper 是一个 DarwinHelperBackend ，顺带一提，host_session 其实是 DarwinHostSession 。

我们跟入实际的函数：

到此我们就完成启动了，对于 spawn 模式启动的进程，将在启动后挂起等待附加，接下来我们跟一下 attach 。该函数也是平台相关的，最终的附加部分会由 perform_attach_to 实现：

此处可以看出，frida 调用 inject_agent 将 frida-agant 注入到进程中去。

frida-agant

在 inject_agent 中注入 agant 之后，entrypoint 为 frida_agent_main ，该函数也由 vala 转换而来，其实现定义在 lib/agant/agant.vala 中：

从 create_and_run 一路往下跟：

此处开始之后会先调用 start.run 完成各项初始化任务，然后在 main_loop.run() 中进入循环，直到进程退出。

而此处 start.begin() 实际上执行的是如下函数：

可以看到，这里分别初始化了 ScriptBackend 和 Interceptor 。并连接到启动时指定的 transport_uri 建立通信隧道。

frida-helper

其实这部分已经在前面介绍过了。frida-helper 的作用其实就是用于实现包括通信、注入进程、启动进程等各项功能等模块。这里就不再赘述了。

frida-gadget

源代码来自于 lib/gadget/gadget.vala，这部分也是笔者一直比较关心的部分，因为它允许我们在非越狱环境下使用 frida。

直接跟进主要函数：

首先 Frida-gadget 在被加载时会自动搜索配置文件，如果找到了则根据配置文件处理。

随后完成一系列工作以后，在进入主循环以前会调用 start 加载脚本：

在 perform_start 中会调用 controller.start () ，此时调用的函数将会根据先前用户配置文件中选择的类型完成。

比方说常用的 Listen 类型就会调用 ControlServer 下的 on_start ：

然后该服务就会监听特定地址了，如果用户传递了文件或代码等，则会与 frida-agant 通过 IPC 服务通信，由对方去负责具体的 hook 行为。

又比如指定一个脚本令其自动运行：

此处会调用 load 完成加载和启动的操作，我们跟入：

其中的 call_init 负责通过 rpc 服务去调用 init ：

在完成以上操作后，frida 会进入 main_loop，而被启动的应用会等待被 resume。

然后是 perform_start 的后半：

由于该函数是以回调函数的形式被注册的，因此附加的进程在每次触发请求的时候都会重新调用该函数处理。

然后我们再看看使用这种方式的情况下是如何附加进程和启动进程的。

在前文中曾说过，通过 IPC 的方式，主机端能够直接调用类中的方法，其中一个比较关键的类是 ControlChannel ，它负责了几个关键行为的设定。

对于 spawn 方式的启动，由于所有模块都被打包在同一个进程中，因此当前进程就是将要附加的进程，因此 spawn 可以直接返回当前进程的 pid。

attach 倒是没太大变化：

它仍然调用 parent.attach 去附加。

总结一下就是：

• frida-gadget 被注入以后会在加载该库的时候调用 load 方法
• 该方法根据用户提供的配置文件选择接下来的行为
• 对于 Listen 则是监听地址端口并触发回调完成交互
• 如果用户在配置中指定来 resume，那么此前会先调用 resume 恢复进程
• 对于 Script 则是读取给定路径下的脚本解析并加载
• 如果需要监听文件变化时候动态修改 hook ，那么还需要额外操作

launchd

上文大致介绍完了 frida 的大体逻辑，但是还有一个细节上的小问题没有解决。具体来说就是，“frida 到底是怎么通过 spawn 启动的进程？”

实际上，frida 除了对进程本身进行注入以外，还会对 launchd 进行注入：

这个地方直接把 __posix_spawn 给 hook 掉了，并且加上了 POSIX_SPAWN_START_SUSPENDED 的 flag，该标记能够让进程在启动后被挂起。

总结

各个组件的功能如下：

• frida-server / 一个服务端。负责在设备上与本机通讯
• frida-agant / 被注入到进程中去的动态库，通常由 frida-server 释放注入，负责编译脚本注入进程
• frida-helper / 负责具体的进程注入、启动进程等功能
• frida-gadgat / frida-server+frida-agant+frida-helper ，将三者的功能全都集成在一个动态库中，由用户手动注入到应用中

这里引出一个小问题，对于被注入 Frida-gadget 的 app 来说，如果我不使用 frida 去启动它，而是通过点击图标的方式原生启动应用，那么应用还能正常启动吗？

如果仅凭上文的分析，主机端通过 IPC 通信去调用设备上对应的函数从而启动了应用，但是原生启动是不通过 IPC 的，这种情况下，frida-gadget 要如何工作呢？它还会正常去启动应用吗？

问了一些师傅，他们表示 Android 平台下，即便注入的 frida-gadget 也是可以正常点击打开的，但是笔者在 iOS16 上测试发现这将导致闪退，但是诡异的是，我能够用 frida -U -f bundleid 正常打开应用。
而在 iOS14 上，笔者发现应用将会停在启动页面无法继续执行，并且 frida 也没办法附加，以及 frida -U -f bundleid 也无法正常启动了，唯独 Xcode 启动时，一切正常，这十分的诡异。

以上问题目前笔者还不清楚原因，欢迎师傅们讨论。