iOS 终极手段:系统服务篡改

篡改 locationd 之后，所有 App 的CLLocationManager拿到的都是假坐标——而 App 进程里没有多一个 dylib，没有改过一个字节。本文对比注入 Hook、内存修改、系统服务篡改三条路线的痕迹差异，拆解免越狱调试通道与守护进程注入方案。

1. 想让 App 拿到假数据，有三条路

先说清楚我们在研究什么问题：App 调系统函数拿到的数据，可以在哪一层被伪造？

以定位为例：
一个业务App想确认用户在哪，靠的是CLLocationManager的回调；
一个外挂想让游戏认为自己在家，靠的也是同一个回调；

想让这个回调吐出假坐标，从 App 进程往外看，有三条路：

前两条路线本博客拆解过（见文末延伸阅读）。

它们有一个共同的软肋：动作发生在 App 进程地址空间内。任何进程内自检都有机会抓到。

安全 SDK 这几年也确实是这么做的，而且做得越来越好。

第三条路线换了个思路：
既然数据是"别人送进来的"，那我改送数据的人。

App 进程从头到尾没被碰，进程内的所有检测全部扑空。

研究目的：理解攻击面才能设计检测。你是做风控的，你得知道对面最长的那条板子长什么样。

2. iOS 的系统数据是"供给制"

很多人对"系统函数"的直觉是错的。你以为CLLocationManager是个函数，其实它是个客户端桩（stub）——真正的数据生产在 App 沙盒外面。

iOS 的架构是供给制：

• 开机时launchd扫描/Library/LaunchDaemons/下的 plist，把对应的守护进程（daemon）拉起来，二进制多在/usr/libexec/下；
• 每个守护进程向launchd注册自己的 Mach 服务名；
• App 里的系统框架（CoreLocation、CoreBluetooth、NetworkExtension……）通过 XPC（底层是 Mach 消息）连到对应服务，拿数据、收回调。

GPS / WiFi / 基带 → 内核 → locationd（多源融合、权限管理、状态机）→ XPC → App 内的 CoreLocation 框架 → 你的回调

看图说话：①②③三个红点，分别打在链路的不同位置。位置不同，痕迹的性质完全不同：

• ① 改的是"App 怎么算"
  ——执行流被劫持，进程内的代码完整性检测有抓手；
• ② 改的是"App 记了什么"
  ——数据被离线改写，逻辑与数据的一致性检测有抓手；
• ③ 改的是"世界是什么样"
  ——App 进程一个字节都没变，它 faithfully 地接收了一个假世界。

这就是③的厉害之处，值得单独强调：①②是污染下游的某一瓶水，③是污染水源。
污染下游要一瓶一瓶改，还要躲过每瓶水自带的检测；
污染水源一次，全城的水都是假的——地图、微信、打车、外卖、银行，同一时刻全部拿到同一个假坐标，

而且每个 App 都理直气壮地认为自己没错。

进程内检测在这里失效不是工程问题，是逻辑问题：检测代码和被欺骗的代码住在同一个进程里，而这个进程根本不在案发现场。

3. 篡改 locationd 的三个入口

按门槛从低到高过一遍。机制讲透，参数脱敏。

3.1 免越狱入口：开发者调试通道（com.apple.dt.simulatelocation）

最反直觉的一个事实：免越狱改全局定位，用的是苹果自己开的正门。

Xcode 6 / iOS 8.0 起，苹果为调试场景提供了设备级位置模拟（GPX 文件模拟定位）。这个能力的链路是：

1. PC 端工具经 USB（usbmuxd）与设备通信，lockdownd受理请求；
2. 启动com.apple.dt.simulatelocation服务，用 plist 消息下发坐标或 GPX 轨迹；
3. locationd 内置的仿真入口接收注入，把模拟位置当作正常定位下发给全系统。

iOS 17+ 的架构跃迁：从 iOS 17 开始，苹果将该通道迁移到了RemoteServiceDiscovery (RSD)协议，并引入了CoreDevice架构。

致命的指纹：isSimulatedBySoftware
虽然“正门”进来的定位在进程内没有 Hook 痕迹，但苹果在CLLocation对象里留下了一个官方后门：从 iOS 15 开始，只要是经过该通道生成的坐标，其属性isSimulatedBySoftware会被标记为YES。

[!TIP]
这是一个廉价且极高权重的检测因子。如果你的 App 拿到一个坐标且该位为真，基本可以实锤用户正在使用 PC 端仿真工具。

这也是爱思助手等改定位软件的原理

这条通道的价值在于它揭示了机制本身：locationd 存在一个"仿真位置"的内部入口，调试通道只是众多触发方式里最体面的一个。门槛更低的触发方式，往下看。

3.2 越狱入口：向守护进程注入

越狱环境下，tweak 的注入目标不必是 App。把进程过滤规则指向locationd，你的代码就跑在守护进程里——这就是"改系统服务"的标准姿势。

// 伪代码
%hook /* locationd 内部的响应构造类 */
-(id)buildResponseForClient:(id)client {
    id original =%orig;// 先拿真实响应
return[self rewrite:original
             withSeed:/* 伪造 */];// 只改目标字段，其余保留
}
%end

4. 系统服务清单：能篡改什么，入口在哪

locationd 只是 200+ 个守护进程里的一个。这一节把对"数据伪造"有价值的服务按数据域整理出来。

先说怎么自己枚举：越狱设备上ls /usr/libexec/，社区有整理过的完整清单（参考资料 [6]）。

通用篡改模式只有三种，前面都出现过：

1. 内置调试 / 仿真入口
   （如 simulatelocation）——免越狱可用，但只存在于少数服务；
2. 向 daemon 注入，hook 响应构造
   ——越狱后的通用解，理论上对上表所有服务成立；
3. 伪造上游输入
   ——最深，需通过目标服务自身的一致性检验。

5. 参考资料

[1] Apple Developer Documentation — XPC，https://developer.apple.com/documentation/xpc
[2] Apple Developer Documentation — Simulating location in tests，https://developer.apple.com/documentation/xcode/simulating-location-in-tests
[3] pymobiledevice3（DDI 挂载与 simulate-location 实现），https://github.com/doronz88/pymobiledevice3
[4] 免越狱虚拟定位外挂的调试小记与检测方案（安全内参），https://www.secrss.com/articles/5630
[5] iOS 虚拟定位原理与预防，https://zhuanlan.zhihu.com/p/451765172
[6] r/jailbreak — List of iOS Daemons And What They Do，https://www.reddit.com/r/jailbreak/comments/10v7j59/tutorial_list_of_ios_daemons_and_what_they_do/
[7] The Apple Wiki — Filesystem: /System/Library/LaunchDaemons，https://theapplewiki.com/wiki/Filesystem:/System/Library/LaunchDaemons

6. 延伸阅读