IOS - 标签 - 有价值炮灰 https://evilpan.com/tags/ios/ IOS - 标签 - 有价值炮灰 Hugo -- gohugo.iozh-CNi@pppan.net (evilpan) i@pppan.net (evilpan)This work is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.Sun, 22 Sep 2024 14:40:00 +0800 在非越狱 iOS 上实现全流量抓包 https://evilpan.com/2024/09/22/ios-netcap/ Sun, 22 Sep 2024 14:40:00 +0800 evilpan https://evilpan.com/2024/09/22/ios-netcap/

昨晚在测试一个手机应用抓包的时候发现使用 WiFi 的 HTTP 代理无法抓到包，并且在 Burp 的日志中没有看到任何 SSL Alert，因此可以判断不是证书问题；另外虽然没有抓到包但是应用依然可以正常收发数据，这说明代理的配置被绕过了。

应用开发者要想绕过用户端的代理配置有很多办法，这种情况在笔者之前的博文中已经介绍过不少了，比如：

但是这次的情况有点不一样。首先笔者常用的用于近源钓鱼的 WiFi 热点工具没有带回家，其次手头上没有 Andorid 手机只有一个 iPhone，且手机由于日常使用并没有越狱(属于是强行给自己上强度了)。

初步尝试

在现有条件下，还是先尝试了正常的抓包方案，使用 Burpsuite 启动代理并在手机端安装好证书，正常抓包发现没有问题。但是正如前面所说，在使用目标应用时发现在一些关键流量上并没有展现，由此判断是应用代码中特意忽略了系统代理配置。

这种情况下一般需要尝试透明代理或者 VPN 抓包方案，我们先考虑后者。在 iOS 中我们有 shadowsxxksR、Surge 等应用，不过都要收费，而且这些软件主要还是用于非 MITM 场景的代理。

在互联网上检索一番发现有个叫 Stream 的免费软件，基于 iOS 9+ 的 Network Extension Api 进行 HTTP/HTTPS 网络流量的劫持。虽然最近一次更新已经是 4 年前了，但现在基本功能还是可用的。

使用该工具点点点之后发现已经能抓到我们想要的请求包了。按理说，我们的任务已经完成了，但是，用别人现成的工具，你的价值体现在哪里？ 这件事为什么是你做不是别人做？ 当初招你进来的时候……

……开个玩笑。其实这个工具也有一些不是很完美的地方，比如抓包和改包只能在手机上点，不适合自动化； 还比如对于一些非 HTTP 流量其实也没有办法抓到。

因此我们接着看有没有其他更优雅的解决方案。

WireGuard

既然手法限制在了 VPN 抓包，那就不得不提 WireGuard 了。

WireGuard 是一种新型的 VPN（虚拟专用网络）协议和免费开源软件，通过 UDP 封装 IP 数据包，提供了一种既安全又高效的 VPN 解决方案。它适用于点对点连接、中心辐射型网络拓扑以及全网状网络拓扑。其设计哲学是简化 VPN 的配置和使用，同时不牺牲安全性和性能。

WireGuard 的安装和使用可以参考官网的文章：

WireGuard 的配置核心在于秘钥路由特性(Cryptokey Routing)。作为一个网络接口(eth0、wlan0、tun0)，会根据路由表进行实际传入和传出网络的分发。WireGuard 同样运行在网络接口层，只不过会在分发前进行网络包的加解密，并且使用 UDP 进行传输。

在 Linux 中新建网卡和设置路由表都可以通过 ip 命令操作，这里新建一个名为 wg0 的网络接口：

# 网卡配置
ip link add wg0 type wireguard
ip addr add 10.0.0.1/24 dev wg0
ip link set wg0 up

然后使用 wg 命令对该接口进行配置，包括设置私钥、端口和 peer 等信息。

# 生成公私钥
wg genkey > private
# 添加私钥
wg set wg0 private-key ./private
# 设置端口
wg set wg0 listen-port 51820
# 添加端点
wg set wg0 peer <peer-公钥> allowed-ips 192.168.88.0/24 endpoint 209.202.254.14:8172

# 可以组合成一句话
wg set wg0 listen-port 51820 private-key './private' peer 'ABCDEF...' allowed-ips '192.168.88.0/24' endpoint '209.202.254.14:8172'

这些配置何况使用配置文件的方式进行管理。

wg setconf wg0 ./config.ini

也可以不用手动创建网卡而是使用 wg-quick 脚本一键部署：

sudo wg-quick up config.ini

wg 和 wg-quick 都是 wireguard-tools 的一部分

以下面一个 Server 的配置为例：

[Interface]
PrivateKey = yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
ListenPort = 51820

[Peer]
PublicKey = xTIBA5rboUvnH4htodjb6e697QjLERt1NAB4mZqp8Dg=
AllowedIPs = 10.192.122.3/32, 10.192.124.1/24

[Peer]
PublicKey = gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
AllowedIPs = 10.10.10.230/32

其中 Interface 指定接口的私钥和监听端口，Peer 则指定了客户端的公钥和 IP 网段。用简化的说法，对于发送到子网 10.10.10.230/32 的请求，会使用该 Peer 的公钥进行加密；对于发送到本机接口的请求，则用本地私钥进行解密。

对应 Client 的配置如下：

[Interface]
PrivateKey = gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE=
ListenPort = 21841

[Peer]
PublicKey = HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=
Endpoint = 192.95.5.69:51820
AllowedIPs = 0.0.0.0/0

其中在 Interface 字段指定了本机的私钥，Peer 字段指定服务器的公钥和地址信息。前面用到 wg genkey 命令来生成私钥，同时也可以用 wg pubkey 查看对应私钥的公钥：

$ wg pubkey <<< gI6EdUSYvn8ugXOt8QQD6Yc+JyiZxIhp3GInSWRfWGE=
gN65BkIKy1eCE9pP1wdc8ROUtkHLF2PfAqYdyYBz6EA=
$ wg pubkey <<< yAnz5TF+lXXJte14tji3zlMNq+hd2rYUIgJBgB3fBmk=
HIgo9xNzJMWLKASShiTqIybxZ0U3wGLiUeJ1PKf8ykw=

可以看到客户端和服务端配置的一大区别是客户端配置指定的 Peer 包含 Endpoint 字段，指定服务器的地址和端口。

服务端上除了 WireGuard 本身的配置还要注意网卡的配置，一般情况下可能需要调整本机防火墙的策略，对于需要将虚拟网卡流量转发到实际网络接口上的场景还需要配置内核 IP 转发以及路由转发的规则，详情可参考：

我们可以在手机上使用 WireGuard 作为 VPN 客户端，同时在 PC 上运行 WireGuard 服务端即可以获取所有手机上的网络流量。不过这里有个问题是网卡收到的数据是加密的 UDP 数据，因此我们需要先将其解密还原成原始数据。

其实在 Wireshark 中已经支持了 WireGuard 流量解密的功能。在 Wireshark Edit -> Preferences -> Protocols -> WireGuard 中可以设置 static key 和 keylog 对加密的 UDP 流量进行解密。

这个解密过程和 SSL/TLS 的解密过程类似，其中需要 wireguard-tools 中的 extract-handshakes.sh 脚本来在获取 WireGuard 握手过程中的临时秘钥，该脚本基于 kprobe 来 hook 内核中 wireguard 驱动的相关代码来提取秘钥，因此只能用于 Linux 系统。

为什么即使有双方的 Peer 私钥也无法对会话进行解密？因为握手过程使用随机生成的临时公私钥对进行 Diffie-Hellman 密钥交换，以生成共享会话密钥。这些临时密钥不会被存储且仅用于当前会话，可以认为 Peer 私钥仅参与验证而不参与加密，因此也就无法解密流量。即便某一个会话的秘钥泄露也不会影响其他会话的保密性，这个就叫前向安全(Forward Security)。

不过话说回来，对于我们的抓包场景其实还不需要介入到解密过程，因为实际流量是进入到我们自己的机器上，然后才转发到实际的服务器，后者的流量是已经解密的。因此我们可以直接抓取网络网卡(如 eth0)其实也是能看到解密后的流量的。甚至我们可以直接抓取 Wireguard 网卡(如 wg0) 也能获得明文流量，从而实现了 “全流量抓包” 的愿景。

使用 WireGuard+Wireshark 我们已经实现了在 iOS 中抓取所有流量的目的，包括 UDP 和 TCP 的链接也包括 ICMP 等 IP 层数据。不过还是有一点点小瑕疵，其中获取到的 HTTPS 流量还是 TLS 加密的。

解决这个问题的方法也很多，一个最直接的方法是通过 iptables 将进入本机(server) 443 端口的 TCP 流量转发到其他透明 HTTP 代理端口，比如 Burpsuite 或者 Yakit，借助他们的 MITM 功能来实现 HTTPS 流量加解密和重放。

不过，既然都引入了三方抓包工具，其实有一个更为便捷的方案。那就是使用 MITMProxy，其在 9.0 版本之后引入了了一种新的透明代理模式，即 wireguard mode，使用方法非常简单，如下所示：

mitmproxy -m wireguard

其会自动生成一个 WireGuard 客户端配置文件，例如：

[Interface]
PrivateKey = mLorvtz8GDGUH+Qm+voV4wFg2r6yJFN/tCRq4fY/Rm8=
Address = 10.0.0.1/32
DNS = 10.0.0.53

[Peer]
PublicKey = lyZoK//28trI/gSaTTaxKEce4RlU2Sxx9VafyWlqR34=
AllowedIPs = 0.0.0.0/0
Endpoint = 192.168.31.21:51820

在手机上直接使用 WireGuard 导入该配置或者将其转为二维码扫描即可连入基于 MITMProxy 的 VPN，所有流量都会被 MITMProxy 进行劫持和转发，从而实现便捷的抓包。

值得一提的是在该模式下 MITMProxy 并不会真正地使用 WireGuard 内核模块，而是使用了其自身的应用层实现，mitmproxy-wireguard。所以观察网卡也不会看到 wg0 等虚拟接口。这样的好处是避免了系统的依赖性，同时功能也会有所裁剪，比如传统 VPN 的子网互通就无法实现。

mitmproxy-wireguard 用 Rust 编写，目前已经转移到了 mitmproxy_rs 仓库中，感兴趣的可以去查看其源码实现。

总结

本文探讨了几种在非越狱 iOS 手机上进行抓包的方案，除了使用如 Surge、Stream 等商业工具，还可以使用 WireGuard、Wireshark、MITMProxy 等开源工具实现最初的目标。在基于 WireGuard 的方案中，Wireshark 可以确保抓取所有流量不会有遗漏，在某些游戏应用中可能会遇到类似的自定义 TCP/UDP 数据流；而使用 MITMProxy 则可以方便地对 HTTPS 流量进行解密，同时基于应用层可以实现平台无关性。

与 Android 相比，如果只是日常抓包可能 iOS 会更方便一点。因为 Android 7 及其以后都默认不信任用户添加的根证书，想加证书抓包要么 root 要么重打包，相对门槛会高一些；而 iOS 还是一如既往的可以随意添加证书，对于日常使用偶尔抓包分析的场景倒是比较方便了。

版权声明: 自由转载-非商用-非衍生-保持署名 (CC 4.0 BY-SA)
原文地址: https://evilpan.com/2024/09/22/ios-netcap/
微信订阅: 『有价值炮灰』
– TO BE CONTINUED.

]]> 从微信扔骰子看iOS应用安全与逆向分析 https://evilpan.com/2021/04/11/ios-hacking-101/ Sun, 11 Apr 2021 12:40:00 +0800 evilpan https://evilpan.com/2021/04/11/ios-hacking-101/

以微信扔骰子小游戏为例，记录一次完整 iOS 逆向分析的过程。

前言

在之前《免越狱调试与分析黑盒iOS应用》以及前几篇文章中已经介绍了如何开始分析iOS应用，不过都是基于非越狱的机器，其本意是为了能够在自己的主力设备中进行简单的分析和调试。但是执着于免越狱其实在很多情况下需要额外的工作，如果想要在iOS上做进一步研究的话，完全的访问权限是很有必要的。

Jailbreak

因为主要讨论的是应用安全，所以关于越狱实现的部分不做深入介绍。关于XNU内核漏洞的分析和利用网上有很多相关的文章或书籍，比如：

看一些公开的漏洞利用代码对加深印象也很有帮助，比如oob_timestamp的利用。对于本文而言只需要站在巨人的肩膀上使用这些封装好的利用即可。iOS越狱和Android root的的一个很大不同是前者系统封闭性高，碎片化较低，因此提权的方法也相对单一，不支持刷机，大部分都是通过漏洞去获取更高的权限(tfp0)。既然是专注应用层安全，就抓大放小，使用现有的越狱工具，站在前人肩膀上即可。

砸壳

越狱之后总算可以通过 ssh 进入到系统中，也就是相当于安卓世界的 adb shell 而已。既然是逆向分析，下一步就是获取应用的安装包，这在安卓中是一条adb pull命令，但苹果里要复杂一些。

iOS 中大部分应用都从 Apple Store 即应用商店下载，而从应用商店下载的 app 是通过苹果签名和加密保护的，这是苹果 FairPlay DRM 数字版权保护的重要部分。为了能使用逆向工具进行分析，需要先对其进行解密，即俗称的砸壳。网上关于砸壳的资料和工具都很多，比如:

  • stefanesser/dumpdecrypted：手动将动态库注入进程获取解密后的文件，不包括动态库
  • conradev/dumpdecrypted：更新版，支持对每个模块进行解密
  • Clutch：通过posix_spawnp创建进程并解密文件，支持重新打包为ipa (iOS12之后这类静态砸壳方法基本上都不行了)
  • frida-ios-dump：使用frida进行动态解密，并支持重新打包为ipa
  • bagbak：和前者类似，不过是基于 nodejs 的 frida binding

这里面有些工具已经年代久远年久失修了，比如我就注意到 dumpdecrypted 在文件沙盒的处理上有点问题导致无法保存文件，需要经过简单 patch 。

上面的这些工具大部分都是基于内存 dump，也就是需要通过 exec 执行目标程序才实现砸壳，这可能会让一些 App 通过在初始化函数中自我检测来对抗砸壳。如果出现这种情况，可以通过基于 mremap_encrypted 的方式进行解密，直接调用内核接口，无需启动目标程序实现静态砸壳。

抓手

狱也越了，壳也砸了，接下来呢？直接丢到 IDA 里分析？不是不可以，但 iOS 的应用主体是一个巨大的 mach-o 文件，直接分析是很难的。还是以微信为例，主程序解密后单 arm64 架构的可执行文件就有 218 MB，即便在逆向工具里分析也会让人无从下手。这时候就需要一个入手点，用互联网的黑话来说，就是需要一个抓手。

一个最常见的入手点就是 UI 界面。在安卓应用分析中一般通过 Android Studio 提供的uiautomatorviewer可以进行目标应用的 UI 分析，并通过 UI 的 ID 在反编译的代码中查找引用。不过这个方法我一般不用，而是直接获取顶层 Activity 然后找对应的类去分析。

在 iOS 中，UI 分析却是一个有效的入手点，因为 iOS 应用都是基于 MVC 结构，View 中触发的事件由对应的 Controller 去实现。不管是基于 Springboard 的拖拖拽拽还是通过代码布局，MVC 的基调是不变的。在 Xcode 中有视图层级调试功能(Debug View Hierarchy)，但需要目标开启调试。除此之外，更为常用的是一些视图调试框架，比如 Reveal 或者开源的 FLEX。

用 FLEX 直接注入到进程中可实现 UI 的分析:

flex.gif
使用 cycript 注入 libflex

这里用到了 cycript，后文再细说。或者可以用 Reveal 在电脑端分析，当然还是需要将 RevealServer.dylib 注入到目标进程中并调用[IBARevealLoader startServer]，参考官方的 lldb 脚本，启动后 PC 端界面如下:

Reveal

点击发送骰子的区域是一个 UIImageView，其本身是没有响应点击事件的，因此要找对应的 ViewController 或者 Gesture Recognizer。

动态分析

根据 UI 信息能知道的是当前界面的 Controller 类是 BaseMsgContentViewController，所以我们可以通过脚本去跟踪发送骰子时该类所有的函数调用，如下所示:

[-] 13:04:24.188 Hooked: -[BaseMsgContentViewController didRotateFromInterfaceOrientation:]
[-] 13:04:24.188 Hooked: -[BaseMsgContentViewController previewingContext:viewControllerForLocation:]
[-] 13:04:24.188 Hooked: -[BaseMsgContentViewController previewingContext:commitViewController:]
[-] 13:04:24.188 Hooked: -[BaseMsgContentViewController previewActionItems]
[-] 13:04:24.189 Hooked: -[BaseMsgContentViewController m_delegate]
[!] 13:04:24.291 Failed to hook: -[BaseMsgContentViewController willShow]
[-] 13:04:24.291 Hooked: -[BaseMsgContentViewController canPasteImage]
[-] 13:04:24.292 Hooked: -[BaseMsgContentViewController setTableFooterView:]
[-] 13:04:24.292 Hooked: -[BaseMsgContentViewController documentInteractionControllerViewControllerForPreview:]
[-] 13:04:24.292 Hooked: -[BaseMsgContentViewController willAppear]
[-] 13:04:24.292 Hooked: -[BaseMsgContentViewController showLoadingView]
[-] 13:04:24.293 Hooked: -[BaseMsgContentViewController initTableView]
[-] 13:04:24.293 Hooked: 614 methods for class BaseMsgContentViewController

# 点击骰子图标发送表情
[-] 13:04:35.075 ENTER -[BaseMsgContentViewController useTransparentNavibar]
[-] 13:04:35.076 ENTER -[BaseMsgContentViewController useTransparentNavibar]
[-] 13:04:35.078 ENTER -[BaseMsgContentViewController shouldInteractivePop]
[-] 13:04:35.078 ENTER -[BaseMsgContentViewController toolView]
[-] 13:04:35.132 ENTER -[BaseMsgContentViewController SendEmoticonMesssageToolView:]
[-] 13:04:35.148 ENTER -[BaseMsgContentViewController findNodeDataByLocalId:]
[-] 13:04:35.148 ENTER -[BaseMsgContentViewController addMessageNode:layout:addMoreMsg:]
[-] 13:04:35.148 ENTER -[BaseMsgContentViewController findNodeDataByLocalId:]
[-] 13:04:35.148 ENTER -[BaseMsgContentViewController getCurContentSizeHeight]
...

其中SendEmoticonMesssageToolView是个值得关注的函数，可以直接用 frida 打印函数堆栈:

import { kObjC } from "../../agent/objc";
import { kNative } from "../../agent/native";

// kObjC.traceClass("BaseMsgContentViewController");
kObjC.traceMethod("BaseMsgContentViewController", "- SendEmoticonMesssageToolView:", {
  onEnter: function(args) {
    log.i("SendEmoticonMesssageToolView", args[0], args[1]);
    kNative.printStackTrace(this.context);
  }
});

输出结果如下:

[-] 13:10:32.079 Hooked: -[BaseMsgContentViewController SendEmoticonMesssageToolView:]
[+] 13:10:37.212 SendEmoticonMesssageToolView 0x11f8a1800 0x10bf6e8ba
[-] 13:10:37.636 backtrace:
0x104e06de4 WeChat!0x2676de4
0x10294cde8 WeChat!0x1bcde8
0x1041bb930 WeChat!0x1a2b930
0x1b8331e34 UIKitCore!-[UICollectionView _selectItemAtIndexPath:animated:scrollPosition:notifyDelegate:deselectPrevious:]
0x1b83464b0 UIKitCore!-[UICollectionView _cellForItemAtIndexPath:includePrefetchedCells:]
0x1b8359e10 UIKitCore!-[UICollectionView touchesEnded:withEvent:]
0x1b46ef730 libsystem_malloc.dylib!nanov2_calloc
0x1b46f4100 libsystem_malloc.dylib!calloc
0x1b48ddae4 CoreFoundation!-[__NSSetM addObject:]
0x1b473926c libobjc.A.dylib!objc_autoreleasePoolPop
0x1b4a14320 CoreFoundation!_CFAutoreleasePoolPop
0x1b48dd594 CoreFoundation!-[__NSSetM enumerateObjectsWithOptions:usingBlock:]
0x1b498bc7c CoreFoundation!__NSSetM_new
0x1bb64e208 QuartzCore!CA::Layer::retain_parent(CA::Transaction*) const
0x1b8b5d9e8 UIKitCore!forwardTouchMethod
0x1b8b5dae4 UIKitCore!-[UIResponder touchesEnded:withEvent:]

在 WeChat 部分的回溯没有符号，因为已经去掉了。

在 lldb 中也可以看到类似的结果:

(lldbinit) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
  * frame #0: 0x0000000105334f04 WeChat`___lldb_unnamed_symbol201841$$WeChat
    frame #1: 0x0000000104b32f80 WeChat`___lldb_unnamed_symbol170264$$WeChat + 160
    frame #2: 0x0000000104e06de4 WeChat`___lldb_unnamed_symbol182196$$WeChat + 2600
    frame #3: 0x000000010294cde8 WeChat`___lldb_unnamed_symbol8796$$WeChat + 248
    frame #4: 0x00000001041bb930 WeChat`___lldb_unnamed_symbol129751$$WeChat + 624
    frame #5: 0x00000001b8331e34 UIKitCore`-[UICollectionView _selectItemAtIndexPath:animated:scrollPosition:notifyDelegate:deselectPrevious:] + 952
    frame #6: 0x00000001b8359e10 UIKitCore`-[UICollectionView touchesEnded:withEvent:] + 572
    frame #7: 0x00000001b8b5d9e8 UIKitCore`forwardTouchMethod + 332
    frame #8: 0x00000001b8b5dae4 UIKitCore`-[UIResponder touchesEnded:withEvent:] + 64
    frame #9: 0x00000001b8b5d9e8 UIKitCore`forwardTouchMethod + 332
    frame #10: 0x00000001b8b5dae4 UIKitCore`-[UIResponder touchesEnded:withEvent:] + 64
    frame #11: 0x00000001b8b5d9e8 UIKitCore`forwardTouchMethod + 332
    frame #12: 0x00000001b8b5dae4 UIKitCore`-[UIResponder touchesEnded:withEvent:] + 64
    frame #13: 0x00000001b86e6478 UIKitCore`_UIGestureEnvironmentUpdate + 6992
    frame #14: 0x00000001b86e48dc UIKitCore`-[UIGestureEnvironment _deliverEvent:toGestureRecognizers:usingBlock:] + 380
    frame #15: 0x00000001b86e4698 UIKitCore`-[UIGestureEnvironment _updateForEvent:window:] + 248
    frame #16: 0x00000001b8b6d654 UIKitCore`-[UIWindow sendEvent:] + 3512
    frame #17: 0x00000001b8b48840 UIKitCore`-[UIApplication sendEvent:] + 348
    frame #18: 0x0000000103de4920 WeChat`___lldb_unnamed_symbol111457$$WeChat + 404
    frame #19: 0x00000001ebaaa87c UIKit`-[UIApplicationAccessibility sendEvent:] + 100

有符号更好，没有也无所谓，我们还是可以通过地址在逆向工具中查看代码。不过考虑到 ASLR 的存在，需要确认一下镜像的加载地址:

(lldbinit) vmmap /WeChat
000102790000 - 00010d6d4000  af44000 R-X /private/var/containers/Bundle/Application/2A5D623F-5F8E-4A99-96C8-8CBD00D8B6BE/WeChat.app/WeChat        0 __TEXT
00010d6d4000 - 00010fc40000  256c000 RW- /private/var/containers/Bundle/Application/2A5D623F-5F8E-4A99-96C8-8CBD00D8B6BE/WeChat.app/WeChat  af44000 __DATA
00010fc40000 - 000110ac4000   e84000 R-- /private/var/containers/Bundle/Application/2A5D623F-5F8E-4A99-96C8-8CBD00D8B6BE/WeChat.app/WeChat  cb68000 __LINKEDIT

vmmap 是我自己定义的一个 lldb 命令，参考了 gef 和 pwndbg 在 gdb 中的实现

这里加载地址是 0x000102790000，而在 IDA 中 text 段的加载地址是 0x100004000，可以在后者进行 rebase，但是因为函数不多，所以先手动查找。另外用 lldb 也可以直接查看对应函数地址的偏移:

(lldbinit) image lookup -a 0x0000000105334f04
      Address: WeChat[0x0000000102ba4f04] (WeChat.__TEXT.__text + 45747972)
      Summary: WeChat`___lldb_unnamed_symbol201841$$WeChat
(lldbinit) image lookup -a 0x0000000104b32f80
      Address: WeChat[0x00000001023a2f80] (WeChat.__TEXT.__text + 37351296)
      Summary: WeChat`___lldb_unnamed_symbol170264$$WeChat + 160
(lldbinit) image lookup -a 0x0000000104e06de4
      Address: WeChat[0x0000000102676de4] (WeChat.__TEXT.__text + 40316388)
      Summary: WeChat`___lldb_unnamed_symbol182196$$WeChat + 2600
(lldbinit) image lookup -a 0x000000010294cde8
      Address: WeChat[0x00000001001bcde8] (WeChat.__TEXT.__text + 1805800)
      Summary: WeChat`___lldb_unnamed_symbol8796$$WeChat + 248
(lldbinit) image lookup -a 0x00000001041bb930
      Address: WeChat[0x0000000101a2b930] (WeChat.__TEXT.__text + 27425072)
      Summary: WeChat`___lldb_unnamed_symbol129751$$WeChat + 624

根据 lldb 中每个函数地址在 TEXT 段中的偏移，可以在 IDA 中直接跳转到对应函数(返回值)，整理对应的调用函数分别是:

  • -[BaseMsgContentViewController SendEmoticonMesssageToolView:] (45747972)
  • -[MMInputToolView didSelectorSelfDefinedEmotcion:] (37351296)
  • -[EmoticonBoardView onTapEmoticonWrap:atIndex:maxCountPerLine:fromSection:] (40316388)
  • -[EmoticonBoardCrossCollectionController onEmoticonPageCellTapEmoticonWrap:atIndex:pid:maxCountPerLine:] (1805800)
  • -[EmoticonBoardCrossCollectionEmoticonPageCell collectionView:didSelectItemAtIndexPath:] (27425072)

既然 IDA 可以识别出对应 OC 函数的符号，那么理论上这些符号也是可以还原的，如果经常需要进行动态分析，那么可以通过一些方法自动化恢复对应的符号，可以参考 iOS符号表恢复 以及 restore-symbol 等项目。

静态分析

通过动态分析找到了着手点，以及通过回溯调用栈找到了一些相关函数，其中并没有一目了然的设置骰子点数的函数 setDiceValue，所以要想改点数还需要对上面的函数进行进一步分析。到这里，逆向工程是不可避免了，一般而言我是能躺着绝不坐着，能坐着绝不站着，不到万不得已是不去逆向的。

花开两朵，各表一枝，在前面砸完壳的第一时间我就预感到需要逆向，所以早早地把 200MB 的 MachO 丢进了 IDA，在文章写到这里时已经过去了四个小时，期间看了两集动漫，但是 IDA 还是没有全部分析完。所以在等待的时间里，先来简单介绍些 ObjectiveC 的底层实现。

在学习 OC 的时候，总会看到说 OC 语言实现面向对象是通过发送消息，具体是怎么发送呢？因此在实际逆向之前，我们先来自己写一个程序来进行分析，以便了解 OC 的调用原理。

以下面简单的 helloworld 为例:

#import <Foundation/Foundation.h>

@interface MyClass: NSObject
 - (void)insMethod:(const char *)a1 arg2:(int)a2;
 + (void)clsMethod:(const char *)a1 arg2:(int)a2;
@end

@implementation MyClass
 - (void)insMethod:(const char *)a1 arg2:(int)a2 {
     NSLog(@"insMethod called, self=%p, a1=%s", self, a1);
 }
 + (void)clsMethod:(const char *)a1 arg2:(int)a2 {
     NSLog(@"clsMethod called, self=%p, a1=%s", self, a1);
 }
@end

int main() {
    MyClass *c = [[MyClass alloc] init];
    [MyClass clsMethod:"hello" arg2:1];
    [c insMethod:"world" arg2:2];
    return 0;
}

主要调用了两个方法，一个类方法和一个成员方法，编译后查看其汇编代码如下:

(lldbinit) disassemble
main @ test_hello:
    0x100003e90: push   rbp
    0x100003e91: mov    rbp, rsp
    0x100003e94: sub    rsp, 0x10
    0x100003e98: mov    dword ptr [rbp - 0x4], 0x0
->  0x100003e9f: mov    rax, qword ptr [rip + 0x424a] ; (void *)0x0000000100008120: MyClass
    0x100003ea6: mov    rdi, rax
    0x100003ea9: call   0x100003f04               ; symbol stub for: objc_alloc_init
    0x100003eae: mov    qword ptr [rbp - 0x10], rax
    0x100003eb2: mov    rax, qword ptr [rip + 0x4237] ; (void *)0x0000000100008120: MyClass
    0x100003eb9: mov    rsi, qword ptr [rip + 0x4220] ; "clsMethod:arg2:"
    0x100003ec0: mov    rdi, rax
    0x100003ec3: lea    rdx, [rip + 0xa8]         ; "hello"
    0x100003eca: mov    ecx, 0x1
    0x100003ecf: call   qword ptr [rip + 0x12b]   ; (void *)0x00007fff20439d00: objc_msgSend
    0x100003ed5: mov    rax, qword ptr [rbp - 0x10]
    0x100003ed9: mov    rsi, qword ptr [rip + 0x4208] ; "insMethod:arg2:"
    0x100003ee0: mov    rdi, rax
    0x100003ee3: lea    rdx, [rip + 0x8e]         ; "world"
    0x100003eea: mov    ecx, 0x2
    0x100003eef: call   qword ptr [rip + 0x10b]   ; (void *)0x00007fff20439d00: objc_msgSend
    0x100003ef5: xor    eax, eax
    0x100003ef7: add    rsp, 0x10
    0x100003efb: pop    rbp
    0x100003efc: ret

且不管初始化部分，后面两个函数调用最终都进入了 objc_msgSend 函数，在苹果官网可以看到其函数原型:

id objc_msgSend(self, op, ...);

其中各个参数为:

  1. self: 消息的接收方，对于类方法为指向类的指针，对于对象方法而言为对象指针；
  2. op: 为消息的标识符，也称为 selector，实际上是一个表示对应方法名称的字符串；
  3. … 其他方法参数；

回到上面的例子，第一次类方法调用的参数为:

(lldbinit) p/x $rdi
(unsigned long) $29 = 0x0000000100008120
(lldbinit) x/1s $rsi
0x100003f86: "clsMethod:arg2:"
(lldbinit) x/1s $rdx
0x100003f72: "hello"
(lldbinit) p/x $rcx
(unsigned long) $32 = 0x0000000000000001

第二次成员方法的调用参数为:

(lldbinit) p/x $rdi
(unsigned long) $54 = 0x0000000100208340
(lldbinit) x/1s $rsi
0x100003f96: "insMethod:arg2:"
(lldbinit) x/1s $rdx
0x100003f78: "world"
(lldbinit) p/x $rcx
(unsigned long) $57 = 0x0000000000000002

程序的输出如下:

2021-04-10 22:54:19.487148+0800 test_hello[99332:5120374] clsMethod called, self=0x100008120, a1=hello
2021-04-10 22:54:54.565229+0800 test_hello[99332:5120374] insMethod called, self=0x100208340, a1=world

所以，ObjectiveC 在实现上还是挺接近 C 语言的，这对于我们逆向而言方便很多。

了解了简单的 OC 逆向之后，IDA 也跑的差不多了。根据栈回溯对应 OC 函数的名称，逐级往上看。首先是 didSelectorSelfDefinedEmotcion这个函数，表示选中了某个自定义表情，里面只是一些发送操作，所以并不是我们想要的；

然后是 -[EmoticonBoardView onTapEmoticonWrap:atIndex:maxCountPerLine:fromSection:] ，该函数中主要是判断所选择的表情是否为自拍表情或者自定义表情，如果是的话就进行异步上传。其调用didSelectorSelfDefinedEmotcion 的参数为 a3，即一个对象指针，虽然还不知道是哪个对象，但知道其包含这些属性(方法):

  • m_emojiInfo
  • m_isAsyncUpload
  • attachObject:forKey:

在 class-dump 导出的头文件中搜索，可以发现是CEmoticonWrap 类:

#import <objc/NSObject.h>

#import "PBCoding-Protocol.h"

@class EmojiInfoObj, NSData, NSString;

@interface CEmoticonWrap : NSObject <PBCoding>
{
    _Bool m_bCanDelete;
    _Bool m_isAsyncUpload;
    _Bool m_isRemoteRecommed;
    _Bool m_isLastSended;
    unsigned int m_uiType;
    unsigned int m_uiGameType;
    unsigned int m_lastUsedTime;
    unsigned int m_extFlag;
    NSString *m_nsAppID;
    NSString *m_nsThumbImgPath;
    NSString *m_query;
    EmojiInfoObj *m_emojiInfo;
    NSData *_m_imageData;
}

该函数主要是执行上传并记录一些信息，更新一些 emojiInfo 的字段，所以还是要继续往上走；

接着是-[EmoticonBoardView onTapEmoticonWrap:atIndex:maxCountPerLine:fromSection:]，该函数主要是作为 delegate 进行转发，没有什么实际功能。但是从名字可以猜测自定义表情栏是通过不同的行实现，而每行中每个表情又对应一个 Cell。

按照回溯的堆栈都看完了，也没有发现和骰子相关的代码。不管怎样，骰子的点数总归是在设置骰子图片之前确定的，而根据上面的逆向可以知道，自定义表情的图片应该是定义在 [CEmoticonWrap m_emojiInfo]中，该类的属性如下:

@interface EmojiInfoObj : MMObject <PBCoding, NSCopying>
{
    _Bool _disableExtern;
    NSString *md5;
    NSString *url;
    NSString *thumbUrl;
    NSString *designerId;
    NSString *encryptUrl;
    NSString *aesKey;
    NSString *productId;
    NSString *externUrl;
    NSString *attachedText;
    NSString *externMd5;
    NSString *activityId;
    NSString *attachedTextColor;
    NSString *lensId;
    NSString *linkId;
    NSString *_tpUrlString;
    NSString *_authkey;
}

接下来还是要通过结合动态分析来确定骰子图片加载的时机。

还是回到SendEmoticonMesssageToolView函数，通过逆向可以得知其参数为CEmoticonWrap类型，修改前面打印栈 callback 的脚本，令其打印参数的各个字段，如下:

[+] 21:50:18.958 Called SendEmoticonMesssageToolView:
[+] 21:50:18.958 emotion: <CEmoticonWrap: self.m_uiType=1, self.m_bCanDelete=1, self.m_uiGameType=2, self.m_nsAppID=(null), self.m_extFlag=0, self.m_nsThumbImgPath=(null), self.m_lastUsedTime=0, self.m_isAsyncUpload=0, self.m_isRemoteRecommed=0, self.m_isLastSended=0, self.m_query=(null), self.m_emojiInfo=<EmojiInfoObj: 0x2813c77b0> {
    activityId = <nil>;
    aesKey = <nil>;
    attachedText = <nil>;
    attachedTextColor = <nil>;
    authkey = <nil>;
    designerId = <nil>;
    disableExtern = 0;
    encryptUrl = <nil>;
    externMd5 = <nil>;
    externUrl = <nil>;
    lensId = <nil>;
    linkId = <nil>;
    md5 = "dice_emoticon_md5";
    productId = "custom_emoticon_pid";
    thumbUrl = <nil>;
    tpUrlString = <nil>;
    url = <nil>
}>

也就是说进入函数之时这些参数都是空的，m_emojiInfo 的 md5 为 “dice_emoticon_md5”，此时骰子图像并没有真正生成，所以印证了我们之前的猜想，即实际的操作还在后面。那么栈回溯是不是白看了？也不尽然，至少至少了参数格式和调用流程(逆向嘛，总是要学会安慰自己)。

回过头来继续看这个函数:

void __cdecl -[BaseMsgContentViewController SendEmoticonMesssageToolView:](BaseMsgContentViewController *self, SEL a2, id emotion)
{
  id v4; // x19
  id v5; // x20
  id *v6; // x21
  id v7; // x24
  unsigned __int8 v8; // w23
  id *v9; // x21
  id v10; // x0
  id *v11; // x21
  void *v12; // x20
  id v13; // x24
  unsigned int v14; // w22
  id *v15; // x21

  v4 = objc_retain(emotion);
  v5 = objc_loadWeakRetained((id *)&self->m_delegate);
  if ( ((unsigned int)objc_msgSend(v5, "respondsToSelector:", "CanSendEmoticonMessage") & 1) == 0 )
    goto LABEL_6;
  v7 = objc_loadWeakRetained(v6);
  v8 = (unsigned __int8)objc_msgSend(v7, "CanSendEmoticonMessage");
  objc_release(v7);
  objc_release(v5);
  if ( (v8 & 1) != 0 )
  {
    v10 = objc_loadWeakRetained(v9);
    if ( v10 )
    {
      v12 = v10;
      v13 = objc_loadWeakRetained(v11);
      v14 = (unsigned int)objc_msgSend(v13, "respondsToSelector:", "SendEmoticonMessage:");
      objc_release(v13);
      objc_release(v12);
      if ( v14 )
      {
        v5 = objc_loadWeakRetained(v15);
        objc_msgSend(v5, "SendEmoticonMessage:", v4);
LABEL_6:
        objc_release(v5);
        goto LABEL_7;
      }
    }
  }
LABEL_7:
  objc_release(v4);
}

又是一个 delegate 模式，直接打印出实例:

kObjC.traceMethod("BaseMsgContentViewController", "- SendEmoticonMesssageToolView:", {
  onEnter(args) {
    log.i("Called", args[1].readCString());
    const vc = new ObjC.Object(args[0]);
    const emotion = new ObjC.Object(args[2]);
    log.i("vc:", vc);
    log.i("m_delegate:", vc.valueForKey_("m_delegate"));
  }
});

结果如下:

[+] 19:15:24.203 Called SendEmoticonMesssageToolView:
[+] 19:15:24.204 vc: <BaseMsgContentViewController: 0x1200b8e00>
[+] 19:15:24.206 m_delegate: <WeixinContentLogicController: 0x11f340a90>

是个 WeixinContentLogicController，那就继续找它的SendEmoticonMessage:方法，没有的话就在父类或者 Category 里找。因为程序太大，我的破电脑在 IDA 里搜索比较卡，所以有个小技巧是直接通过函数名跳转，对应的 IDA 函数为名为 -[WeixinContentLogicController SendEmoticonMessage:]，当然实际并没有这个函数，而是在父类中定义的 -[BaseMsgContentLogicController SendEmoticonMessage:]。

ida.png

在上面高亮的一行，IDA 反编译的结果有点问题，显示 V7 是未初始化的，遇到这种情况直接看汇编即可，汇编是不会骗人的:

asm

即第一个参数实际上是 PluginUtil 类的地址，这里调用的则是类方法+[PluginUtil isPluginUserName:]。其中 m_uiGameType 前面已经通过 frida 打印出来了，其值是 2，继续动态分析得知进入 else 分支。按照这种动静结合的策略，最终分析得到向前的调用过程:

  • -[BaseMsgContentLogicController SendEmoticonMessage:]
  • +[GameController GameEmoticonMsgForEmoticonWrap:]
  • +[GameController SetGameContentForMsgWrap:] (参数类型是 CMessageWrap)

最终设置内容如下:

random

看到这逻辑应该很明显了，如果游戏类型为 1，则有:

content = 1 + rand - rand / 3 * 3 = 1 + rand % 3

如果游戏类型为 2，则有:

content = 4 + rand - rand / 6 * 6 = 4 + rand % 6

由于我们选的是扔骰子，游戏类型为 2，骰子的 content 取值范围为 4 ~ 9，正好对应 6 个点数；有理由猜测前面一个 3 个点数的应该就对应剪刀石头布游戏。

这里有两个值得注意的点，一是 random 函数调用了两次，但是后面一次的结果并没有使用，因此目的可能通过减少随机数连续性增加破解伪随机序列的难度；另外一个点是随机后的内容经过了 md5，所以修改点数的时候可能要一并修改哈希，否则会导致校验失败，或者直接修改 random 函数的返回值也是可以的。

kNative.trace(null, "random", {
  onLeave(retval) {
    log.i("random:", retval.toInt32());
    retval.replace(ptr(5));
  }
});

实现效果如下:

dice

至此，修改骰子点数的核心功能就分析完毕了。

再谈 Hook

说实话最近听 hook 这个词已经听到腻了，不管是 plt hook 还是 inline hook，其本质都是在运行时修改现有的代码，进而达到修改控制流的目的。对于二进制汇编代码的修改大同小异，不过对于 iOS 程序而言其实也有其他选择，下面逐一介绍:

这是最为通用的 hook 方式，即在指定地址前增加跳转指令，保存现场并跳转到用户指令，执行完后还原现场并返回执行。inline hook 可以实现汇编指令级别的 trace，也是大部分动态跟踪工具实现的基础。下图为 frida-gum 实现 inline hook 的的大致流程:

frida
OSDC 2015: The engineering behind the reverse engineering

当然原理归原理，要基于公式实现核弹在工程上还要做很多工作，比如代码段通常是不可修改的，因此需要 mmap 拷贝一份到自己的地盘去进行修改；另外保存和恢复现场的操作大多只能用汇编写，因此要实现跨平台还要针对不同指令集进行测试等等。这一切繁重的工作别人都已经为我们做好了，我们需要做的就只是调用一下 Interceptor.attach ，不得不感慨生活真幸福。

前面我们说过，Objective-C 实现面向对象是基于消息的发送，那么针对 Objc 的调用，我们其实可以动态的修改某个 selector 对应的实现，这个过程就称之为 method swizzling。苹果官方也提供了对应的 API:

void method_exchangeImplementations(Method m1, Method m2);

该方法相当于下面指令的原子实现:

IMP imp1 = method_getImplementation(m1);
IMP imp2 = method_getImplementation(m2);
method_setImplementation(m1, imp2);
method_setImplementation(m2, imp1);

还是那句老话，原理是简单的，实现是复杂的。现实中很少这样直接交换两个方法实现，而是在之前进行一些必要的检查，如下所示:

+ (void)load
{
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        Class aClass = [self class];
        
        SEL originalSelector = @selector(method_original:);
        SEL swizzledSelector = @selector(method_swizzle:);
        
        Method originalMethod = class_getInstanceMethod(aClass, originalSelector);
        Method swizzledMethod = class_getInstanceMethod(aClass, swizzledSelector);
        BOOL didAddMethod =
        class_addMethod(aClass,
                        originalSelector,
                        method_getImplementation(swizzledMethod),
                        method_getTypeEncoding(swizzledMethod));
        
        if (didAddMethod) {
            class_replaceMethod(aClass,
                                               swizzledSelector,
                                               method_getImplementation(originalMethod),
                                               method_getTypeEncoding(originalMethod));
        } else {
            method_exchangeImplementations(originalMethod, swizzledMethod);
        }
    });
}

直接交换方法是危险的，因为如果类中没有实现该方法，那么 class_getInstanceMethod 会返回某个父类中的 Method 对象，实际交换的则是父类的方法，这样其他父类和子类的调用就会出现意想不到的问题。因此上面的代码会判断 selector 方法不存在的情况。

另外还要注意的是 selector 命名冲突问题、重复 swizzling 问题以及 _cmd 被修改的问题等等，因此也就有了 RSSwizzle 或者 jrswizzle 这些完善的实现方案。对于开发人员来说这是个需要仔细考虑的问题，毕竟这影响了程序的稳定性。

值得一提的是，frida 中对于 Objc 也提供了基于 method swizzling 的 hook 方案:

const myMethod_ = ObjC.classes.MyClass.myMethod_;
myMethod_.implementation = ObjC.implement(myMethod_, function (handle, selector, arg0) {
  log.i(`self=${handle}, selector=${selector}, arg0=${arg0}`);
});

在 Java 中，我们可以通过 java.lang.reflect.Proxy 基于反射机制来实现方法的动态代理，这种方式在很多地方被应用于 AOP 即切面编程。而 Objective-C 也有类似的方式，即 NSProxy，该类的定义如下:

/*	NSProxy.h
	Copyright (c) 1994-2019, Apple Inc. All rights reserved.
*/

#import <Foundation/NSObject.h>

@class NSMethodSignature, NSInvocation;

NS_ASSUME_NONNULL_BEGIN

NS_ROOT_CLASS
@interface NSProxy <NSObject> {
    __ptrauth_objc_isa_pointer Class	isa;
}

+ (id)alloc;
+ (id)allocWithZone:(nullable NSZone *)zone NS_AUTOMATED_REFCOUNT_UNAVAILABLE;
+ (Class)class;

- (void)forwardInvocation:(NSInvocation *)invocation;
- (nullable NSMethodSignature *)methodSignatureForSelector:(SEL)sel NS_SWIFT_UNAVAILABLE("NSInvocation and related APIs not available");
- (void)dealloc;
- (void)finalize;
@property (readonly, copy) NSString *description;
@property (readonly, copy) NSString *debugDescription;
+ (BOOL)respondsToSelector:(SEL)aSelector;

- (BOOL)allowsWeakReference API_UNAVAILABLE(macos, ios, watchos, tvos);
- (BOOL)retainWeakReference API_UNAVAILABLE(macos, ios, watchos, tvos);

// - (id)forwardingTargetForSelector:(SEL)aSelector;

@end

NS_ASSUME_NONNULL_END

可以看到其遵守 NSObject protocol，并且第一个 ivar 是 isa 指针，因此可以当成是一个 NSObject 或者其派生类使用，但是它并不是一个 NSObject 的子类。使用上只需要实现两个方法:

- (void)forwardInvocation:(NSInvocation *)invocation;
- (nullable NSMethodSignature *)methodSignatureForSelector:(SEL)sel;

NSInvocation 封装了一个方法调用的全部信息，包括调用参数和返回值。一个示例实现如下:

#import <Foundation/Foundation.h>

@interface MyProxy : NSProxy {
    id victim_;
}
+ (id)hookObject:(id)obj;
@end

@implementation MyProxy
+ (id)hookObject:(id)obj {
    MyProxy *p = [MyProxy alloc];
    p->victim_ = obj;
    return p;
}
- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel {
    return [victim_ methodSignatureForSelector:sel];
}
- (void)forwardInvocation:(NSInvocation *)invocation {
    if ([victim_ respondsToSelector:invocation.selector]) {
        NSString *selectorName = NSStringFromSelector(invocation.selector);
        NSLog(@"ENTER %@", selectorName);
        [invocation invokeWithTarget:victim_];
        NSLog(@"LEAVE %@", selectorName);
    }
}
@end
  
int main(int argc, char *argv[]) {
    dispatch_semaphore_t sem = dispatch_semaphore_create(0);
    
    NSURL *url = [MyProxy hookObject:[NSURL URLWithString:@"https://evilpan.com"]];
    NSURLSessionDataTask *task = [[NSURLSession sharedSession] dataTaskWithURL:url completionHandler:^(NSData * _Nullable data, NSURLResponse * _Nullable response, NSError * _Nullable error) {
        dispatch_semaphore_signal(sem);
    }];
    [task resume];
    dispatch_semaphore_wait(sem, DISPATCH_TIME_FOREVER);
    return 0;
}

输出:

$ ./test_proxy
2021-04-11 11:18:55.193 test_proxy[15011:5637371] ENTER absoluteURL
2021-04-11 11:18:55.194 test_proxy[15011:5637371] LEAVE absoluteURL

直接用我们的 MyProxy 对象替换了原始的 NSURL 对象，这样 NSURL 对象中所调用的所有方法都由我们的 Proxy 对象来进行代理，因此可以在执行原始函数之前以及返回之前执行我们自己的操作，从而实现 hook 的功能。

其他

补充一些前面没有提到的东西。

Mach-O程序是支持多架构的，例如同一个程序既能运行在arm32位也能运行在64位机器上。多架构(multiarch)的应用通常比原程序体积要大，但是比两个单架构的程序要小，因为多架构应用会共享资源。

iOS应用开发者为了保证兼容性通常会选择同时支持armv7和arm64，但对于逆向分析却不必要。因此，我们可以先对其进行瘦身(thin)，只保留arm64架构即可。首先查看应用是否为多架构：

# 通过file命令查看
$ file pp2048/Payload/2048.app/2048
pp2048/Payload/2048.app/2048: Mach-O universal binary with 2 architectures: [arm_v7:Mach-O executable arm_v7] [arm64]
pp2048/Payload/2048.app/2048 (for architecture armv7):	Mach-O executable arm_v7
pp2048/Payload/2048.app/2048 (for architecture arm64):	Mach-O 64-bit executable arm64

# 或者通过lipo命令查看
$ lipo -detailed_info pp2048/Payload/2048.app/2048
Fat header in: pp2048/Payload/2048.app/2048
fat_magic 0xcafebabe
nfat_arch 2
architecture armv7
    cputype CPU_TYPE_ARM
    cpusubtype CPU_SUBTYPE_ARM_V7
    offset 16384
    size 8838944
    align 2^14 (16384)
architecture arm64
    cputype CPU_TYPE_ARM64
    cpusubtype CPU_SUBTYPE_ARM64_ALL
    offset 8863744
    size 10265808
    align 2^14 (16384)

只保留arm64，可以使用lipo或者ditto，二者都是苹果自带的：

# 使用lipo工具
$ lipo -thin arm64 pp2048/Payload/2048.app/2048 -output thin_2048

# 或者使用ditto工具
$ ditto --arch arm64 pp2048/Payload/2048.app/2048 thin_2048

输出的文件是一样的。

前文中有用到 cycript 来注入动态库进行 UI 界面分析，这里再补充一下。cycript 由 saurik 大神开发，在 JavaScript REPL 中支持 ObjectiveC 的混合语法，使用起来比较直观。比如:

cy# [[UIApplication sharedApplication] keyWindow]
#"<iConsoleWindow: 0x11581f120; baseClass = UIWindow; frame = (0 0; 1194 834); gestureRecognizers = <NSArray: 0x2800d0570>; layer = <UIWindowLayer: 0x280eb1800>>"

支持直接调用 c 函数，并且直接使用 enum 常量:

cy# dlopen
(extern "C" void *dlopen(char const*, int))
cy# RTLD_NOW
2
cy# dlopen("/usr/lib/libFLEX.dylib", RTLD_NOW);
(typedef void*)(0x11a23e180)

前面使用 FLEX 进行 UI 分析就是直接通过 dlopen 注入动态库实现的(其实注入 Reveal 也是)。cycript 的功能很强大，但是文档不多，主要是参考官方的 manual。一些参考网站如下:

在越狱 iOS 中有类似于 Andoid Xposed 的 patch 框架 Cydia Substrate，其提供了 C API 给越狱 APP 的开发者来实现对特定方法的动态修改，还提供了基于 plist 的声明文件，让开发者可以选择指定的 APP 进行 hook，同时也很好地处理了同一个方法被 Hook 多次的问题。基于 Substrate 开发的 dylib 称为 Tweak，由 Substrate 根据 plist 在应用启动时选择进行注入。

一个 hook 示例如下:

NSString *(*oldDescription)(id self, SEL _cmd);

// implicit self and _cmd are explicit with IMP ABI
NSString *newDescription(id self, SEL _cmd) {
    NSString *description = (*oldDescription)(self, _cmd);
    description = [description stringByAppendingString:@"!"];
    return description;
}

MSHookMessageEx(
    [NSObject class], @selector(description),
    &newDescription, &oldDescription
);

如果觉得这样写还是太麻烦，可以使用 Logos 来简化代码，这是个基于预处理库的组件，包含一系列以%开头的宏方便编写 hook 代码，示例如下:

%hook SBApplicationController
-(void)uninstallApplication:(SBApplication *)application {
	NSLog(@"Hey, we're hooking uninstallApplication:!");
	%orig; // Call the original implementation of this method
	return;
}
%end

Logos 现在是 Theos 组件的一部分，可以通过 NIC 工程模板系统快速地创建一个基于 Makefile 的 Tweak 项目。初学者可以通过参考一些 开源的 Tweaks 来熟悉开发流程。

LLDB是个功能十分强大的调试器，在有些场景下比GDB还要好用。关于GDB命令可以参考GDB调试笔记，而GDB命令对应的LLDB命令可以参考GDB and LLDB Command Examples，这里只介绍一些常用的例子:

在一个ObjectiveC类中的所有方法下设置断点(正则表达式)：

(lldb) breakpoint set -r '\[ClassName .*\]$'

打印 Objective-C 对象:

(lldb) po addr

查看各个模块的映射地址(target module list)：

(lldb) image list -h -f

设置zero flag，常用于修改跳转指令:

(lldb) register write rflags `$rflags|0x40`

更详细的功能以及 lldb 脚本的编写可以参考下面的链接:

后记

本文以微信扔骰子小游戏为例，介绍了一次完整的 iOS 逆向分析过程。以最初的越狱开始，分别介绍了砸壳、UI 分析、动态分析和静态分析的具体操作，最后还介绍了 iOS 中常见的 hook 方案以及一些越狱开发相关的工具。之前分析过 Android 中微信的扔骰子，里面大部分代码都经过了混淆，相比之下 iOS 中逆向代码就直观很多。现今很多应用都是同时支持两个平台，在一个平台中受阻可以切换到另一个平台说不定有意想不到的收获，比如对于 Unity3D 中 C# 代码的逆向，Android 平台就比 iOS 要方便点 (因为 IL2CPP)。因此，对于有志深造的逆向工程师而言，保持灵活和开放的心态也是至关重要的。

参考资料

]]> USB 协议核心概念与实践 https://evilpan.com/2021/01/24/usb-fun/ Sun, 24 Jan 2021 12:40:00 +0800 evilpan https://evilpan.com/2021/01/24/usb-fun/ USB，全称是 Universal Serial Bus，即通用串行总线，既是一个针对电缆和连接器的工业标准，也指代其中使用的连接协议。本文不会过多介绍标准中的细节，而是从软件工程师的角度出发，介绍一些重要的基本概念，以及实际的主机和从机应用。最后作为实际案例，从 USB 协议实现的角度分析了checkm8漏洞的成因。

USB 101

首先要明确的一点，USB 协议是以主机为中心的 (Host Centric)，也就是说只有主机端向设备端请求数据后，设备端才能向主机发送数据。从数据的角度来看，开发者最直接接触的就是端点 (Endpoint)，端点可以看做是数据收发的管道。

当主机给设备发送数据时，通常流程是:

  • 调用用户层 API，如 libusb_bulk_transfer
  • 对内核的 USB 驱动执行对应系统调用，添加发送队列，如 ioctl(IOCTL_USBFS_SUBMITURB)
  • 内核驱动中通过 HCI 接口向 USB 设备发送请求+数据
  • 数据发送到设备端的 Controller -> HCI -> Host

设备给主机发送请求也是类似，只不过由于是主机中心，发送的数据会保存在缓存中，等待主机发送 IN TOKEN 之后才真正发送到主机。在介绍数据发送流程之前，我们先来看下描述符。

所有的 USB 设备端设备，都使用一系列层级的描述符 (Descriptors) 来向主机描述自身信息。这些描述符包括:

  • Device Descriptors: 设备描述
  • Configuration Descriptors: 配置描述
  • Interface Descriptors: 接口描述
  • Endpoint Descriptors: 端点描述
  • String Descriptors: 字符串描述

它们之间的层级结构关系如下:

des.png

每种描述符都有对应的数据结构，定义在标准中的第九章，俗称 ch9。下面以 Linux 内核的实现为例来简要介绍各个描述符，主要参考头文件 include/uapi/linux/usb/ch9.h。

每个 USB 设备只能有一个设备描述(Device Descriptor)，该描述符中包括了设备的 USB 版本、厂商、产品 ID 以及包含的配置描述符个数等信息，如下所示:

/* USB_DT_DEVICE: Device descriptor */
struct usb_device_descriptor {
	__u8  bLength; // 18 字节
	__u8  bDescriptorType; // 0x01

	__le16 bcdUSB; // 设备所依从的 USB 版本号
	__u8  bDeviceClass; // 设备类型
	__u8  bDeviceSubClass; // 设备子类型
	__u8  bDeviceProtocol; // 设备协议
	__u8  bMaxPacketSize0; // ep0 的最大包长度，有效值为 8，6，32，64
	__le16 idVendor; // 厂商号
	__le16 idProduct; // 产品号
	__le16 bcdDevice; // 设备版本号
	__u8  iManufacturer; // 产商字名称
	__u8  iProduct; // 产品名称
	__u8  iSerialNumber; // 序列号
	__u8  bNumConfigurations; // 配置描述符的个数
} __attribute__ ((packed));

#define USB_DT_DEVICE_SIZE		18

每个字段的含义都写在注释中了，其中有几点值得一提。

  • 设备类型、子类型和协议码，是由 USB 组织定义的；
  • 产商号也是由 USB 组织定义的，但是产品号可以由厂商自行定义；
  • 厂商、产品和序列号分别只有 1 字节，表示在字符串描述符中的索引；

BCD: binary­ coded decimal

每种不同的配置描述(Configuration Descriptor)中分别指定了 USB 设备所支持的配置，如功率等信息；一个 USB 设备可以包含多个配置，但同一时间只能有一个配置是激活状态。实际上大部分的 USB 设备都只包含一个配置描述符。

/* USB_DT_CONFIG: Configuration descriptor information.
 *
 * USB_DT_OTHER_SPEED_CONFIG is the same descriptor, except that the
 * descriptor type is different.  Highspeed-capable devices can look
 * different depending on what speed they're currently running.  Only
 * devices with a USB_DT_DEVICE_QUALIFIER have any OTHER_SPEED_CONFIG
 * descriptors.
 */
struct usb_config_descriptor {
	__u8  bLength; // 9
	__u8  bDescriptorType; // 0x02

	__le16 wTotalLength; // 返回数据的总长度
	__u8  bNumInterfaces; // 接口描述符的个数
	__u8  bConfigurationValue; // 当前配置描述符的值 (用来选择该配置)
	__u8  iConfiguration; // 该配置的字符串信息 (在字符串描述符中的索引)
	__u8  bmAttributes; // 属性信息
	__u8  bMaxPower; // 最大功耗，以 2mA 为单位
} __attribute__ ((packed));

#define USB_DT_CONFIG_SIZE		9

当主设备读取配置描述的时候，从设备会返回该配置下所有的其他描述符，如接口、端点和字符串描述符，因此需要 wTotalLength 来表示返回数据的总长度。

bmAttributes 指定了该配置的电源参数信息，D6 表示是否为自电源驱动；D5 表示是否支持远程唤醒；D7 在 USB1.0 中曾用于表示是否为总线供电的设备，但是在 USB2.0 中被 bMaxPower 字段取代了，该字段表示设备从总线上消耗的电压最大值，以 2mA 为单位，因此最大电流大约是 0xff * 2mA = 510mA。

一个配置下有多个接口，可以看成是一组相似功能的端点的集合，每个接口描述符的结构如下:

/* USB_DT_INTERFACE: Interface descriptor */
struct usb_interface_descriptor {
	__u8  bLength;
	__u8  bDescriptorType; // 0x04

	__u8  bInterfaceNumber; // 接口序号
	__u8  bAlternateSetting;
	__u8  bNumEndpoints;
	__u8  bInterfaceClass;
	__u8  bInterfaceSubClass;
	__u8  bInterfaceProtocol;
	__u8  iInterface; // 接口的字符串描述，同上
} __attribute__ ((packed));

#define USB_DT_INTERFACE_SIZE		9

其中接口类型、子类型和协议与前面遇到的类似，都是由 USB 组织定义的。在 Linux 内核中，每个接口封装成一个高层级的功能，即逻辑链接(Logical Connection)，例如对 USB 摄像头而言，接口可以分为视频流、音频流和键盘(摄像头上的控制按键)等。

还有值得一提的是 bAlternateSetting，每个 USB 接口都可以有不同的参数设置，例如对于音频接口可以有不同的带宽设置。实际上 Alternate Settings 就是用来控制周期性的端点参数的，比如 isochronous endpoint。

端点描述符用来描述除了零端点(ep0)之外的其他端点，零端点总是被假定为控制端点，并且在开始请求任意描述符之前就已经被配置好了。端点(Endpoint)，可以认为是一个单向数据信道的抽象，因此端点描述符中包括传输的速率和带宽等信息，如下所示:

/* USB_DT_ENDPOINT: Endpoint descriptor */
struct usb_endpoint_descriptor {
	__u8  bLength;
	__u8  bDescriptorType; // 0x05

	__u8  bEndpointAddress; // 端点地址
	__u8  bmAttributes;	// 端点属性
	__le16 wMaxPacketSize; // 该端点收发的最大包大小
	__u8  bInterval; // 轮询间隔，只对 Isochronous 和 interrupt 传输类型的端点有效 (见下)

	/* NOTE:  these two are _only_ in audio endpoints. */
	/* use USB_DT_ENDPOINT*_SIZE in bLength, not sizeof. */
	__u8  bRefresh;
	__u8  bSynchAddress;
} __attribute__ ((packed));

#define USB_DT_ENDPOINT_SIZE		7
#define USB_DT_ENDPOINT_AUDIO_SIZE	9	/* Audio extension */

bEndpointAddress 8位数据分别代表:

  • Bit 0-3: 端点号
  • Bit 4-6: 保留，值为0
  • Bit 7: 数据方向，0 为 OUT，1 为 IN

bmAttributes 8位数据分别代表:

  • Bit 0-1: 传输类型
    • 00: Control
    • 01: Isochronous
    • 10: Bulk
    • 11: Interrupt
  • Bit 2-7: 对非 Isochronous 端点来说是保留位，对 Isochronous 端点而言表示 Synchronisation Type 和 Usage Type，不赘述；

每种端点类型对应一种传输类型，详见后文。

字符串描述符(String Descriptor)中包含了可选的可读字符串信息，如果没提供，则前文所述的字符串索引应该都设置为0，字符串表结构如下:

/* USB_DT_STRING: String descriptor */
struct usb_string_descriptor {
	__u8  bLength;
	__u8  bDescriptorType; // 0x03

	__le16 wData[1];		/* UTF-16LE encoded */
} __attribute__ ((packed));

/* note that "string" zero is special, it holds language codes that
 * the device supports, not Unicode characters.
 */

字符串表中的字符都以 Unicode 格式编码，并且可以支持多种语言。0号字符串表较为特殊，其中 wData 包含一组所支持的语言代码，每个语言码为 2 字节，例如 0x0409 表示英文。

不像 RS-232 和其他类似的串口协议，USB 实际上由多层协议构造而成，不过大部分底层的协议都在 Controller 端上的硬件或者固件进行处理了，最终开发者所要关心的只有上层协议。

在 HCI 之下，实际传输的数据包称为 Packet，每次上层 USB 传输都会涉及到 2-3 次底层的 Packet 传输，分别是:

  • Token Packet: 总是由主机发起，指示一次新的传输或者事件
    • In: 告诉 USB 设备，主机我想要读点信息
    • Out: 告诉 USB 设备，主机我想要写点信息
    • Setup: 用于开始 Control Transfer
  • Data Packet: 可选，表示传输的数据，可以是主机发送到设备，也可以是设备发送到主机
    • Data0
    • Data1
  • Status Packet: 状态包，用于响应传输，以及提供纠错功能
    • Handshake Packets: ACK/NAK/STALL
    • Start of Frame Packets

基于这些底层包，USB 协议定义了四种不同的传输类型，分别对应上节中的四种端点类型，分别是:

Control Transfers: 主要用来发送状态和命令，比如用来请求设备、配置等描述以及选择和设置指定的描述符。只有控制端点是双向的。

Interrupt Transfers: 由于 USB 协议是主机主导的，设备端的中断信息需要被及时响应，就要用到中断传输，其提供了有保证的延迟以及错误检测和重传功能。中断传输通常是非周期性的，并且传输过程保留部分带宽，常用于时间敏感的数据，比如键盘、鼠标等 HID 设备。

Isochronous Transfers: 等时传输，如其名字所言，该类传输是连续和周期性的，通常包含时间敏感的信息，比如音频或视频流。因此这类传输不保证到达，即没有 ACK 响应。

Bulk Transfers: 用于传输大块的突发数据(小块也可以)，不保留带宽。提供了错误校验(CRC16)和重传机制来保证传输数据的完整性。块传输只支持高速/全速模式。

这里以控制传输(Control Transfers)为例，来看看底层 Packet 如何组成一次完整的传输。控制传输实际上又可能最多包含三个阶段，每个阶段在应用层可以看成是一次 “USB 传输” (在Wireshark中占一行)，分别是:

  • Setup Stage: 主机发送到设备的请求，包含三次底层数据传输

    1. Setup Token Packet: 指定地址和端点号(应为0)
    2. Data0 Packet: 请求数据，假设是 8 字节的 Device Descriptor Request
    3. ACK Handshake Packet: 设备的响应， 不允许用 STALL 或者 NAK 来响应 Setup Packet

  • Data Stage: 可选阶段，包含一个或者多个 IN/OUT 传输，以 IN 为例，也包含三次传输

    1. IN Token Packet: 表示主机端要从设备端读数据
    2. Datax Packet: 如果上面 Setup Stage 是 Device Descriptor Request， 这里返回 Device Descriptor Response (的前8字节，然后再根据实际长度再 IN 一次)。
    3. ACK/STALL/NAK Status Packet

  • Status Stage: 报告本次请求的状态，底层也是三次传输，但是和方向有关:

    • 如果在 Data Stage 发送的是 IN Token，则该阶段包括:
      1. OUT Token
      2. Data0 ZLP(zero length packet): 主机发送长度为0的数据
      3. ACK/NACK/STALL: 设备返回给主机
    • 如果在 Data Stage 发送的是 OUT Token，则该阶段包括:
      1. IN Token
      2. Data0 ZLP: 设备发送给主机，表示正常完成，否则发送 NACK/STALL
      3. ACK: 如果是 ZLP，主机响应设备，双向确认

每个阶段的数据都有自己的格式，例如 Setup Stage 的 Request，即 Data0 部分发送的 8 字节数据结构如下:

struct usb_ctrlrequest {
	__u8 bRequestType; // 对应 USB 协议中的 bmRequestType，包含请求的方向、类型和指定接受者
	__u8 bRequest; // 决定所要执行的请求
	__le16 wValue; // 请求参数
	__le16 wIndex; // 同上
	__le16 wLength; // 如果请求包含 Data Stage，则指定数据的长度
} __attribute__ ((packed));

下面是一些标准请求的示例:

bmRequestType bRequest wValue wIndex wLength Data
1000 0000b GET_STATUS (0x00) Zero Zero Two Device Status
0000 0000b CLEAR_FEATURE (0x01) Feature Selector Zero Zero None
0000 0000b SET_FEATURE (0x03) Feature Selector Zero Zero None
0000 0000b SET_ADDRESS (0x05) Device Address Zero Zero None
1000 0000b GET_DESCRIPTOR (0x06) Descriptor Type & Index Zero or Language ID Descriptor Length Descriptor
0000 0000b SET_DESCRIPTOR (0x07) Descriptor Type & Index Zero or Language ID Descriptor Length Descriptor
1000 0000b GET_CONFIGURATION (0x08) Zero Zero 1 Configuration Value
0000 0000b SET_CONFIGURATION (0x09) Configuration Value Zero Zero None

ref: https://www.beyondlogic.org/usbnutshell/usb6.shtml

虽然 HCI 之下传输的数据包大部分情况下对应用开发者透明，但是了解底层协议发生了什么也有助于加深我们对 USB 的理解，后文中介绍 checkm8 漏洞时候就用到了相关知识。

主机端

在主机端能做的事情相对有限，主要是分析和使用对应的 USB 设备。

使用 wireshark 可以分析 USB 流量，根据上面介绍的描述符字段以及 USB 传输过程进行对照，可以加深我们对 USB 协议的理解。如下是对某个安卓设备的 Device Descriptor Response 响应:

device.png

也就是所谓安卓变砖恢复时经常用到的高通 9008 模式。说个题外话，最近对于高通芯片 BootROM 的研究发现了一些有趣的东西，后面可能会另外分享，Stay Tune！

对于应用开发者而言，通常是使用封装好的库，早期只有 libusb，后来更新了 libusb1.0，早期的版本变成 libusb0.1，然后又有了 OpenUSB 和其他的 USB 库。但不管用哪个库，调用的流程都是大同小异的。以 Python 的封装 pyusb 为例，官方给的示例如下:

import usb.core
import usb.util

# find our device
dev = usb.core.find(idVendor=0xfffe, idProduct=0x0001)

# was it found?
if dev is None:
    raise ValueError('Device not found')

# set the active configuration. With no arguments, the first
# configuration will be the active one
dev.set_configuration()

# get an endpoint instance
cfg = dev.get_active_configuration()
intf = cfg[(0,0)]

ep = usb.util.find_descriptor(
    intf,
    # match the first OUT endpoint
    custom_match = \
    lambda e: \
        usb.util.endpoint_direction(e.bEndpointAddress) == \
        usb.util.ENDPOINT_OUT)

assert ep is not None

# write the data
ep.write('test')

总的来说分为几步，

  1. 根据设备描述符查找到指定的设备
  2. 获取该设备的配置描述符，选择并激活其中一个
  3. 在指定的配置中查找接口和端点描述符
  4. 使用端点描述符进行数据传输

如果不清楚 USB 的工作原理，会觉得上面代码的调用流程很奇怪，往 USB 上读写数据需要那么复杂吗？但正是因为 USB 协议的高度拓展性，才得以支持这么多种类的外设，从而流行至今。

设备端

对于想要开发设备端 USB 功能的开发者而言，使用最广泛的要数树莓派 Zero了，毕竟这是树莓派系列中唯一支持 USB OTG 的型号。网上已经有很多资料教我们如何将树莓派 Zero 配置成 USB 键盘、打印机、网卡等 USB 设备的教程。当然使用其他硬件也是可以的，配置自定义的 USB 设备端可以让我们做很多有趣的事情，比如网卡中间人或者 Bad USB 这种近源渗透方式。后文中我们会使用 Zero 进行简单测试。

一些相关的配置资料可以参考:

在介绍应用之间，我们先看看内核的实现。还是以 Linux 内核为例，具体来说，我们想了解如何通过添加内核模块的方式实现一个新的自定义 USB 设备。俗话说得好，添加 Linux 驱动的最好方式是参看现有的驱动，毕竟当前内核中大部分都是驱动代码。

因为 Linux 内核既能运行在主机端，也能运行在设备端，因此设备端的 USB 驱动有个不同的名字: gadget driver。对于不同设备，也提供不同的内核接口，即 Host-Side API 和 Gadget API。既然我们是想实现自己的设备，就需要从 gadget 驱动入手。

g_zero.ko 就是这么一个驱动，代码在 drivers/usb/gadget/legacy/zero.c。该驱动实现了一个简单的 USB 设备，包含 2 个配置描述，各包含 1 个功能，分别是 sink 和 loopback，前者接收数据并返回 0，后者接收数据并原样返回:

  • drivers/usb/gadget/function/f_sourcesink.c
  • drivers/usb/gadget/function/f_loopback.c

代码量不多，感兴趣的自行 RTFSC。另外值得一提的是，对于运行于 USB device 端的系统而言，内核中至少有三个层级处理 USB 协议，可能用户层还有更多。gadget API 属于三层的中间层。至底向上，三层分别是:

  1. USB Controller Driver: 这是软件的最底层，通过寄存器、FIFO、DMA、IRQ 等其他手段直接和硬件打交道，通常称为 UDC (USB Device Controller) Driver。
  2. Gadget Driver: 作为承上启下的部分，通过调用抽象的 UDC 驱动接口，底层实现了硬件无关的 USB function。主要用于实现前面提到的 USB 功能，包括处理 setup packet (ep0)、返回各类描述符、处理各类修改配置情况、处理各类 USB 事件以及 IN/OUT 的传输等等。
  3. Upper Level: 通过 Gadget Driver 抽象的接口，实现基于 USB 协议的上层应用，比如 USB 网卡、声卡、文件存储、HID 设备等。

关于 Linux USB 子系统的详细设计结构，可以参考源码中的文档: Linux USB API，以及其他一些资料，如下所示:

参考现有的 Linux 驱动，依葫芦画瓢可以很容易实现一个自定义的 USB Gadget。但是这样存在一些问题，如果我想实现一个八声道的麦克风，还要重新写一遍驱动、编译、安装，明明内核中麦克风的功能已经有了，复制粘贴就显得很不优雅。

那么，有没有什么办法可以方便组合和复用现有的 gadget function 呢？在 Linux 3.11 中，引入了 USB Gadget ConfigFS，提供了用户态的 API 来方便创建新的 USB 设备，并可以组合复用现有内核中的驱动。

gfs.png

前文提到的基于树莓派 Zero 实现的各类 USB 设备，大部分都是基于 Gadget ConfigFS 接口实现的。基于 configfs 创建 USB gadget 的步骤一般如下:

CONFIGFS_HOME=/sys/kernel/config/usb_gadget

# 1. 新建一个 gadget，并写入实际的设备描述
mkdir $CONFIGFS_HOME/mydev # 创建设备目录后，该目录下自动创建并初始化了一个设备模板
cd $CONFIGFS_HOME/mydev
echo 0x0100 > bcdDevice # Version 1.0.0
echo 0x0200 > bcdUSB # USB 2.0
echo 0x00 > bDeviceClass
echo 0x00 > bDeviceProtocol
echo 0x40 > bMaxPacketSize0
echo 0x0104 > idProduct # Multifunction Composite Gadget
echo 0x1d6b > idVendor # Linux Foundation

# 2. 新建一个配置，并写入实际的配置描述
mkdir configs/c.1 # 创建一个配置实例: <config name>.<config number>
cd configs/c.1
echo 0x01 > MaxPower
echo 0x80 > bmAttributes

# 3. 新建一个接口(function)，或者将已有接口链接到当前配置下
cd $CONFIGFS_HOME/mydev
mkdir functions/hid.usb0 # 创建一个 function 实例: <function type>.<instance name>
echo 1 > functions/hid.usb0/protocol
echo 8 > functions/hid.usb0/report_length # 8-byte reports
echo 1 > functions/hid.usb0/subclass
ln -s functions/hid.usb0 configs/c.1

# 4. 将当前 USB 设备绑定到 UDC 驱动中
echo ls /sys/class/udc > $CONFIGFS_HOME/mydev/UDC

这样就实现了一个最简单的 USB gadget，当然要完整实现的话还可以添加字符串描述，以及增加各个端点的功能。使用 configfs 实现一个 USB 键盘的示例可以参考网上其他文章，比如 Using RPi Zero as a Keyboard，或者 Github 上的开源项目，比如 P4wnP1。

有些人觉得 ConfigFS 配置起来很繁琐，所以开发了一些函数库(如 libusbgx) 来通过调用创建 gadget；有人觉得通过函数操作也还是繁琐，就创建了一些工具(如 gt) 来通过处理一个类似于 libconfig 的配置文件直接创建 gadget，不过笔者用得不多。

FunctionFS 最初是对 GadgetFS 的重写，用于支持实现用户态的 gadget function，并组合到现有设备中。这里说的 FunctionFS 实际上是新版基于 ConfigFS 的 GadgetFS 拓展。在上一节中说到创建设备 gadget 的第四步就是给对应的 configuration 添加 function，格式为 function—type.instance-name，type 对应一个已有的内核驱动，比如上节中是 hid。

如果要使用当前内核中没有的 function 实现自定义的功能，那么内核还提供了一个驱动可以方便在用户态创建接口，该驱动就是 ffs 即 FunctionFS。使用 ffs 的方式也很简单，将上面第三步替换为:

cd $CONFIGFS_HOME/mydev
mkdir functions/ffs.usb0
ln -s functions/ffs.usb0 configs/c.1

创建一个类型为 ffs，名称为 usb0 的function，然后挂载到任意目录:

cd /mnt
mount usb0 ffs -t functionfs

挂载完后，/mnt/ffs/ 目录下就已经有了一个 ep0 文件，如名字所言正是 USB 设备的零端点，用于收发 Controller Transfer 数据以及各类事件。在该目录中可以创建其他的端点，并使用类似文件读写的操作去实现端点的读写，内核源码中提供了一个用户态应用示例，代码在 tools/usb/ffs-test.c。如果嫌 C 代码写起来复杂，还可以使用 Python 编写 ffs 实现，比如 python-functionfs。

案例分析: checkm8 漏洞

checkm8 漏洞就不用过多介绍了，曾经的神洞，影响了一系列苹果设备，存在于 BootROM 中，不可通过软件更新来修复，一度 Make iOS Jailbreak Great Again。当然现在可以通过 SEP 的检查来对该漏洞进行缓解，这是后话。

关于 checkm8 的分析已经有很多了，我们就不再鹦鹉学舌，更多是通过 checkm8 的成因，来从漏洞角度加深对 USB device 开发的理解。

checkm8 漏洞发生在苹果的救砖模式 DFU (Device Firmware Upgrade)，即通过 USB 向苹果设备刷机的协议。该协议是基于 USB 协议的一个拓展，具体来说:

  • 基于 USB Control Transfer
  • bmRequestType[6:5] 为 0x20，即 Type 为 Class
  • bmRequestType[4:0] 为 0x01，即 Recipient 为 Interface
  • bRequest 为 DFU 相关操作，比如 Detach、Download、Upload、GetStatus、Abort 等

DFU 接口初始化的代码片段如下:

dfu.png

Control Transfer 主要是在 ep0 上传输，因此 ep0 的读写回调中就会根据收到的数据来派发到不同的 handler，对于 DFU 协议的分发伪代码如下:

static byte *data_buf;
static size_t data_rcvd;
static size_t data_size;
static struct usb_ctrlrequest setup_request; 

void handle_ctr_transfer_recv(byte *buf, int len, int *p_stage, int is_setup) {
  *p_stage = 0;
  if (!is_setup) {
    handle_data_recv(buf, len, p_stage);
  }
  // handle control request
  memcpy(&setup_request, buf, 8);
  switch(setup_request.bRequestType & 0x60) {
    case STANDARD:
      // ...
    case VENDOR:
      // ...
    case CLASS:
      if (setup_request.bRequestType & 0x1f == INTERFACE) {
        int n = intf_handlers[setup_request.wIndex]->handle_request(&setup_request, &data_buf);
        if (n > 0) {
          data_size = n;
        }
      }
    default:
    // ...
  }
}

其中 intf_handlers 是 usb_core_regisger_interface 函数中添加到的的全局函数数组。handle_reuqest 中传入的是一个指针的指针，并在处理函数中复制为 io_buffer 的地址。而开头的 data stage 阶段，内部实现就是将收到的数据拷贝到 data_buf 即 io_buffer 中。

io_buffer 一直是有效的吗？并不尽然，因为 io_buffer 在 DFU 退出阶段会被 free 释放掉，此后 data_buf 仍然持有着无效指针，就构成了一个典型的 UAF 场景，这正是 checkm8 的漏洞所在。至于如何触发以及如何构造利用，可以需要额外的篇幅去进行介绍，感兴趣的朋友可以参考文末的文章。

从 checkm8 漏洞中我们可以看到出现漏洞的根本成因:

  • 大量使用全局变量
  • 在处理 USB 内部状态机出现异常时，没有充分清除全局变量的值，比如只将 io_buffer 置零而没有将 data_buf 置零
  • 在重新进入状态机时，全局变量仍然有残留，导致进入异常状态或者处理异常数据

网上有人评论说这么简单的漏洞为什么没有通过自动化测试发现出来，个人感觉这其实涉及到模糊测试的两大难题:

一是针对 stateful 的数据测试，每增加一种内部状态，测试的分支就成指数级别增长，从而增加了控制流覆盖到目标代码的难度；

二是硬件依赖，要测试这个 USB 状态机，需要 mock 出底层的驱动接口，工作量和写一个新的 USB 驱动差不多，更不用说 DFU 本身还会涉及存储设备的读写，这部分接口是不是也要模拟？

因此这类漏洞的更多是通过代码审计发现出来，不过厂商又执着于 Security by Obsecurity，这就导致投入的更多是利益驱动的组织，对个人用户安全而言并不算是件好事。如果 iBoot 开源，那么估计这个漏洞早就被提交给苹果 SRC，成本也就几千欢乐豆的事，也不至于闹出这么大的舆情，甚至以 checkm8 为跳板，把 SEPOS 也撸了个遍。

后记

本文是最近对 USB 相关的一些学习记录，虽然文章是从前往后写的，但实际研究却是从后往前做的。即先看到了网上分析 checkm8 的文章，为了复现去写一个 USB 设备，然后再去学习 USB 协议的细节，可以算是个 Leaning By Hacking 的案例吧。个人感觉这种方式前期较为痛苦，但后期将点连成线之后还是挺醍醐灌顶的，也算是一种值得推荐的研究方法。

参考资料

]]> 用手机打 CTF 种什么体验 https://evilpan.com/2020/11/22/ish-fun/ Sun, 22 Nov 2020 12:40:00 +0800 evilpan https://evilpan.com/2020/11/22/ish-fun/

尝试不用电脑，只拿一台iPhone去参加看雪CTF2020 (娱乐向)

视频地址: https://www.bilibili.com/video/BV1Da4y1p7F3

背景

最近 iSH 在 Apple Store 上架了，之前一直抢不到 testflight 的配额，难得强管控的苹果会让这种 Terminal 类的应用发布，所以第一时间下载来玩玩。测试之后发现可以当做是一个简单的 Linux 虚拟机，至少常用的命令都没什么问题，正好看到看雪论坛有个 CTF，于是就试一下，能不能用手机来打一局 CTF :)

环境

iSH 是一个开源的 Terminal Emulator，在 iOS 中运行，使用用户态的 x86 指令模拟以及 syscall 翻译实现。iSH 中使用的是 Alphine Linux 镜像，用过 Docker 的应该都不会陌生。Alphine 是个非常轻量级的 Linux 发行版，在官网上可以直接下载各个平台预编译的镜像，平时有测试内核需求又不满足于 ramfs 的可以使用下载的镜像进行方便测试。

在 iSH 中已经有了一个简单的 Alphine 环境，可能是是因为苹果商店审核的原因，在其中并没有预置包管理工具。我们可以下载一个完整的 iso 重新挂载，但是有更简单的方法，直接从 Alphine Packages 中下载静态编译版本的 apk-tools-static:

wget http://dl-cdn.alpinelinux.org/alpine/latest-stable/main/x86/apk-tools-static-2.10.5-r1.apk
tar -zxvf apk-tools-static-2.10.5-r1.apk
./sbin/apk.static -X https://mirrors.tuna.tsinghua.edu.cn --initdb add apk-tools
apk update
rm -rf ./sbin

我们用下载的 apk-tools-static 来安装 apk-tools，然后包管理工具 apk 就可以正常使用了。如果初始化的时候没有指定镜像源，可以使用下面的命令修改为清华大学的镜像源，加快国内的访问速度:

sed -i 's/dl-cdn.alpinelinux.org/mirrors.tuna.tsinghua.edu.cn/g' /etc/apk/repositories

之后需要的工具就可以自行安装了，我这里只需要 radare2 和 Python:

apk add radare2
apk add python3

题目是看雪 CTF2020 的签到题: https://ctf.pediy.com/game-season_fight-158.htm

Write Up

解题过程在文章开头的视频中已经可以看到了，这里还是用文字介绍下解题思路。

首先 rabin2 查看目标程序的信息:

$ rabin2 -I kctf2020.exe
arch     x86
baddr    0x140000000
binsz    12288
bintype  pe
bits     64
canary   false
retguard false
class    PE32+
cmp.csum 0x0000bcb6
compiled Thu Nov 12 03:49:32 2020
crypto   false
dbg_file D:\Users\admin\Documents\Visual Studio 2015\Projects\ctf2020\ConsoleApplication1\x64\Release\ConsoleApplication1.pdb
endian   little
havecode true
hdr.csum 0x00000000
guid     4EF50FB8F5E74CC481D01589FC111B1A1
laddr    0x0
lang     c
linenum  false
lsyms    false
machine  AMD 64
maxopsz  16
minopsz  1
nx       true
os       windows
overlay  false
cc       ms
pcalign  0
pic      true
relocs   false
signed   false
sanitiz  false
static   false
stripped false
subsys   Windows CUI
va       true

可以看到是 PE64 的的程序，鉴于是签到题，所以就直接逆向分析了:

$ r2 kctf2020.exe
 -- 💺
[0x14000154c]> s main
[0x140001000]> af
[0x140001000]> pd 20
            ;-- section..text:
┌ 459: int main (int argc, char **argv, char **envp);
│ bp: 7 (vars 7, args 0)
│ sp: 14 (vars 14, args 0)
│ rg: 0 (vars 0, args 0)
│           0x140001000      4055           push rbp                   ; [00] -r-x section size 8192 named .text
│           0x140001002      488dac24c0fe.  lea rbp, [rsp - 0x140]
│           0x14000100a      4881ec400200.  sub rsp, 0x240
│           0x140001011      488b05e82f00.  mov rax, qword [section..data] ; [0x140004000:8]=0x2b992ddfa232 ; "2\xa2\xdf-\x99+"
│           0x140001018      4833c4         xor rax, rsp
│           0x14000101b      488985300100.  mov qword [var_130h], rax
│           0x140001022      33d2           xor edx, edx
│           0x140001024      488d4c2430     lea rcx, [var_30h]
│           0x140001029      41b800010000   mov r8d, 0x100             ; 256
│           0x14000102f      e8ce0e0000     call 0x140001f02
│           0x140001034      33d2           xor edx, edx
│           0x140001036      488d4d30       lea rcx, [var_bp_30h]
│           0x14000103a      41b800010000   mov r8d, 0x100             ; 256
│           0x140001040      e8bd0e0000     call 0x140001f02
│           0x140001045      488d0dd42100.  lea rcx, str.KCTF_2020     ; 0x140003220 ; "KCTF 2020!\n"
│           0x14000104c      e8ff010000     call 0x140001250
│           0x140001051      488d0dd82100.  lea rcx, str.http:__bbs.pediy.com ; 0x140003230 ; "http://bbs.pediy.com\n"
│           0x140001058      e8f3010000     call 0x140001250
│           0x14000105d      488d0de42100.  lea rcx, str.Please_input_your_flag: ; 0x140003248 ; "Please input your flag: "
│           0x140001064      e8e7010000     call 0x140001250

在 0x140001250 地址处经常有调用，根据参数可以猜测是打印函数，验证一下:

[0x140001000]> s 0x140001250
[0x140001250]> af
[0x140001250]> pdf
            ; CALL XREFS from main @ 0x14000104c, 0x140001058, 0x140001064, 0x14000119b, 0x1400011ab
┌ 85: int printf (const char *format);
│           ; var int64_t var_20h_2 @ rsp+0x20
│           ; var int64_t var_8h @ rsp+0x50
│           ; var int64_t var_10h @ rsp+0x58
│           ; var int64_t var_18h @ rsp+0x60
│           ; var int64_t var_20h @ rsp+0x68
│           ; arg int64_t arg1 @ rcx
│           ; arg int64_t arg2 @ rdx
│           ; arg int64_t arg3 @ r8
│           ; arg int64_t arg4 @ r9
│           0x140001250      48894c2408     mov qword [var_8h], rcx    ; arg1
│           0x140001255      4889542410     mov qword [var_10h], rdx   ; arg2
│           0x14000125a      4c89442418     mov qword [var_18h], r8    ; arg3
│           0x14000125f      4c894c2420     mov qword [var_20h], r9    ; arg4
│           0x140001264      53             push rbx
│           0x140001265      56             push rsi
│           0x140001266      57             push rdi
│           0x140001267      4883ec30       sub rsp, 0x30
│           0x14000126b      488bf9         mov rdi, rcx
│           0x14000126e      488d742458     lea rsi, [var_10h]
│           0x140001273      b901000000     mov ecx, 1
│           0x140001278      ff150a1f0000   call qword [sym.imp.api_ms_win_crt_stdio_l1_1_0.dll___acrt_iob_func] ; [0x140003188:8]=0x3a98 reloc.api_ms_win_crt_stdio_l1_1_0.dll___acrt_iob_func
│           0x14000127e      488bd8         mov rbx, rax
│           0x140001281      e8baffffff     call fcn.140001240
│           0x140001286      4533c9         xor r9d, r9d
│           0x140001289      4889742420     mov qword [var_20h_2], rsi
│           0x14000128e      4c8bc7         mov r8, rdi
│           0x140001291      488bd3         mov rdx, rbx
│           0x140001294      488b08         mov rcx, qword [rax]
│           0x140001297      ff15e31e0000   call qword [sym.imp.api_ms_win_crt_stdio_l1_1_0.dll___stdio_common_vfprintf] ; [0x140003180:8]=0x3aaa reloc.api_ms_win_crt_stdio_l1_1_0.dll___stdio_common_vfprintf
│           0x14000129d      4883c430       add rsp, 0x30
│           0x1400012a1      5f             pop rdi
│           0x1400012a2      5e             pop rsi
│           0x1400012a3      5b             pop rbx
└           0x1400012a4      c3             ret

果然是打印函数，直接重命名一下，清爽一些:

[0x140001250]> af printf
[0x140001250]> s-
[0x140001000]> pd 20
            ;-- section..text:
┌ 459: int main (int argc, char **argv, char **envp);
│ bp: 7 (vars 7, args 0)
│ sp: 14 (vars 14, args 0)
│ rg: 0 (vars 0, args 0)
│           0x140001000      4055           push rbp                   ; [00] -r-x section size 8192 named .text
│           0x140001002      488dac24c0fe.  lea rbp, [rsp - 0x140]
│           0x14000100a      4881ec400200.  sub rsp, 0x240
│           0x140001011      488b05e82f00.  mov rax, qword [section..data] ; [0x140004000:8]=0x2b992ddfa232 ; "2\xa2\xdf-\x99+"
│           0x140001018      4833c4         xor rax, rsp
│           0x14000101b      488985300100.  mov qword [var_130h], rax
│           0x140001022      33d2           xor edx, edx
│           0x140001024      488d4c2430     lea rcx, [var_30h]
│           0x140001029      41b800010000   mov r8d, 0x100             ; 256
│           0x14000102f      e8ce0e0000     call 0x140001f02
│           0x140001034      33d2           xor edx, edx
│           0x140001036      488d4d30       lea rcx, [var_bp_30h]
│           0x14000103a      41b800010000   mov r8d, 0x100             ; 256
│           0x140001040      e8bd0e0000     call 0x140001f02
│           0x140001045      488d0dd42100.  lea rcx, str.KCTF_2020     ; 0x140003220 ; "KCTF 2020!\n"
│           0x14000104c      e8ff010000     call printf                ; int printf(const char *format)
│           0x140001051      488d0dd82100.  lea rcx, str.http:__bbs.pediy.com ; 0x140003230 ; "http://bbs.pediy.com\n"
│           0x140001058      e8f3010000     call printf                ; int printf(const char *format)
│           0x14000105d      488d0de42100.  lea rcx, str.Please_input_your_flag: ; 0x140003248 ; "Please input your flag: "
│           0x140001064      e8e7010000     call printf                ; int printf(const char *format)

同理，把 scanf 也重命名上，先看程序开头的逻辑:

│           0x140001069      41b800010000   mov r8d, 0x100             ; 256
│           0x14000106f      488d542430     lea rdx, [var_30h]
│           0x140001074      488d0de92100.  lea rcx, [0x140003264]     ; "%s"
│           0x14000107b      e860010000     call scanf                 ; int scanf(const char *format)
│           0x140001080      488d542430     lea rdx, [var_30h]
│           0x140001085      4883c9ff       or rcx, 0xffffffffffffffff
│           0x140001089      0f1f80000000.  nop dword [rax]
│       ┌─> 0x140001090      48ffc1         inc rcx
│       ╎   0x140001093      803c0a00       cmp byte [rdx + rcx], 0
│       └─< 0x140001097      75f7           jne 0x140001090
│           0x140001099      83f90c         cmp ecx, 0xc               ; 12
│       ┌─< 0x14000109c      0f8502010000   jne 0x1400011a4
│       │   0x1400010a2      807c243066     cmp byte [var_30h], 0x66
│      ┌──< 0x1400010a7      0f85f7000000   jne 0x1400011a4
│      ││   0x1400010ad      807c24316c     cmp byte [var_31h], 0x6c
│     ┌───< 0x1400010b2      0f85ec000000   jne 0x1400011a4
│     │││   0x1400010b8      807c243261     cmp byte [var_32h], 0x61
│    ┌────< 0x1400010bd      0f85e1000000   jne 0x1400011a4
│    ││││   0x1400010c3      807c243367     cmp byte [var_33h], 0x67
│   ┌─────< 0x1400010c8      0f85d6000000   jne 0x1400011a4
│   │││││   0x1400010ce      807c24347b     cmp byte [var_34h], 0x7b
│  ┌──────< 0x1400010d3      0f85cb000000   jne 0x1400011a4
│  ││││││   0x1400010d9      807c243b7d     cmp byte [var_3bh], 0x7d
│ ┌───────< 0x1400010de      0f85c0000000   jne 0x1400011a4

var_30h 是输入的字符串，分别进行字节和长度比对，要求输入字符串长度为 12，并且格式为 flag{xxxxxx}，这里有个技巧是 radare2 中 VV 模式下的跳转:

  • tab/shift+tab: 跳转到下一个/前一个 basic block
  • t/f: 跳转到 true/false 分支
  • u/U: undo/redo 跳转

然后是 flag 中间字符的判断:

0x1400010e4      440fb74c2439   movzx r9d, word [var_39h]
0x1400010ea      4c8d442420     lea r8, [var_20h]
0x1400010ef      448b542435     mov r10d, dword [var_35h]
0x1400010f4      33c0           xor eax, eax
0x1400010f6      6644894c2424   mov word [var_24h], r9w
0x1400010fc      8bd0           mov edx, eax
0x1400010fe      4489542420     mov dword [var_20h], r10d
0x140001103      0f1f4000       nop dword [rax]
0x140001107      660f1f840000.  nop word [rax + rax]

这里使用 mov dword 来进行拷贝，将 var_35h 拷贝 到 var_20h 中，同时 r8 寄存器指向 var_20h。接着先循环逐个判断字符c - 0x30是否小于 9，如果有大于 9 的就报错:

 ┌─> 0x140001110      410fb608       movzx ecx, byte [r8]
 ╎   0x140001114      80e930         sub cl, 0x30               ; 48
 ╎   0x140001117      80f909         cmp cl, 9                  ; 9
┌──< 0x14000111a      0f8784000000   ja 0x1400011a4
│╎   0x140001120      ffc2           inc edx
│╎   0x140001122      49ffc0         inc r8
│╎   0x140001125      83fa06         cmp edx, 6                 ; 6
│└─< 0x140001128      72e6           jb 0x140001110
│    0x14000112a      ...

接着经过下面的判断，记得 var_30h 是我们的输入，长度为 12，格式为 flag{xxxxxx}:

     0x14000112a      0fb6542437     movzx edx, byte [var_37h]
     0x14000112f      4c8d053e2100.  lea r8, [0x140003274]      ; "2;=EFI"
     0x140001136      0fb64c2436     movzx ecx, byte [var_36h]
     0x14000113b      80ea30         sub dl, 0x30               ; 48
     0x14000113e      80e930         sub cl, 0x30               ; 48
     0x140001141      44885530       mov byte [var_bp_30h], r10b
     0x140001145      4102ca         add cl, r10b
     0x140001148      4180e930       sub r9b, 0x30              ; 48
     0x14000114c      02d1           add dl, cl
     0x14000114e      884d31         mov byte [var_bp_31h], cl
     0x140001151      0fb64c2438     movzx ecx, byte [var_38h]
     0x140001156      80e930         sub cl, 0x30               ; 48
     0x140001159      885532         mov byte [var_bp_32h], dl
     0x14000115c      02ca           add cl, dl
     0x14000115e      488d5530       lea rdx, [var_bp_30h]
     0x140001162      4402c9         add r9b, cl
     0x140001165      884d33         mov byte [var_bp_33h], cl
     0x140001168      0fb64c243a     movzx ecx, byte [var_3ah]
     0x14000116d      80e930         sub cl, 0x30               ; 48
     0x140001170      44884d34       mov byte [var_bp_34h], r9b
     0x140001174      4102c9         add cl, r9b
     0x140001177      884d35         mov byte [var_bp_35h], cl
     0x14000117a      660f1f440000   nop word [rax + rax]
 ┌─> 0x140001180      0fb60c02       movzx ecx, byte [rdx + rax]
 ╎   0x140001184      48ffc0         inc rax
 ╎   0x140001187      413a4c00ff     cmp cl, byte [r8 + rax - 1]
┌──< 0x14000118c      7516           jne 0x1400011a4
│╎   0x14000118e      4883f807       cmp rax, 7                 ; 7
│└─< 0x140001192      75ec           jne 0x140001180
│    0x140001194      488d0de52000.  lea rcx, [0x140003280]     ; "You are winner!\n"
│    0x14000119b      e8b0000000     call printf                ; int printf(const char *format)

设flag{}中间的内容为flag，这里的逻辑可以写成伪代码:

buf[0] = flag[0]
buf[1] = buf[0] + flag[1] - 48
buf[2] = buf[1] + flag[2] - 48
buf[3] = buf[2] + flag[3] - 48
buf[4] = buf[3] + flag[4] - 48
buf[5] = buf[4] + flag[5] - 48
if buf == "2;=EFI":
  printf("You are winner!\n")

反向计算，可得:

flag[0] = buf[0]
flag[1] = buf[1] - buf[0] + 48
flag[2] = buf[2] - buf[1] + 48
flag[3] = buf[3] - buf[2] + 48
flag[4] = buf[4] - buf[3] + 48
flag[5] = buf[5] - buf[4] + 48

所以计算的 flag 为:

$ ./solve.py
flag: b'292813'

最终答案应该是 flag{292813}，如果有 windows 环境的话可以进行动态验证，在 Linux/MacOS 环境中可以用 wine 来进行验证，如下:

$ wine64 kctf2020.exe
0025:err:plugplay:runloop_thread Couldn't open IOHIDManager.
0009:fixme:vcruntime:__telemetry_main_invoke_trigger (0x0)
KCTF 2020!
http://bbs.pediy.com
Please input your flag: 0009:fixme:msvcrt:MSVCRT__stdio_common_vfscanf options 3 not handled
flag{292813}
You are winner!
0009:fixme:vcruntime:__telemetry_main_return_trigger (0x0)

后记

安装了 iSH 之后，我的手机时间分配一度变成了这样:

time

手机上的 Terminal 可以用来做什么呢？这里可以列举一些:

  1. 用来 ssh 登录到服务器进行管理
  2. 用来随时查看 man page
  3. 用来编写和运行自动化脚本
  4. 进行一些简单的命令行操作
  5. …

其中 ssh 对我来说是个刚需，因为在此之前苹果上一直没有一个好用且免费的 ssh client，只能用 Termius 勉强度日。不过可惜的是由于苹果的策略，iSH 暂时还不能在后台运行，不然直接 ssh -R 还能当做隧道用，岂不美哉？

当然，iSH 还是有很多局限性的，比如只能模拟 x86 的指令集，而且由于是软件模拟，因此运行效率比较低。如果要执行复杂的任务，比如 gcc 编译大型项目，还是最好在 PC 上运行了。

]]> 深入浅出MachO https://evilpan.com/2020/09/06/macho-inside-out/ Sun, 06 Sep 2020 22:40:00 +0800 evilpan https://evilpan.com/2020/09/06/macho-inside-out/ 之前写了一篇深入浅出ELF，作为姊妹篇这次就来聊聊MacOS的可执行文件格式MachO。

Mach-O 101

在之前的文章中我们说过，可执行文件的使命有两个，一是方便开发者在编译、链接时提供可扩展的封装结构；二是在执行时能给操作系统(内核)提供内存映射信息。MachO也不例外。

MachO本身没有什么特别的含义，就是Mach object的简写，而Mach是早期的一个微内核。和ELF一样，MachO也极具拓展性，从全局视角来看，MachO文件可以分为三个部分，分别是:

  1. Mach Header: 文件头信息
  2. 可变长度的LOAD_COMMAND信息
  3. 上述LOAD_COMMAND中所用到的具体信息(segments)

这里的segment可以理解为一段连续的内存空间，拥有对应的读/写/执行权限，并且在内存中总是页对齐的。每个segment由一个或者多个section组成，section表示特定含义数据或者代码的集合(不需要页对齐)。在macOS中，通常约定segment的名称为双下划线加全大写字母(如__TEXT)，section的名称为双下划线加小写字母(如__text)。

下面对这三个部分进行分别介绍。

注: MachO文件结构的表示通常分为32位和64位两种，本文以64位为例，毕竟这是历史的进程。

文件头信息参考mach-o/loader.h中的定义如下:

/*
 * The 64-bit mach header appears at the very beginning of object files for
 * 64-bit architectures.
 */
struct mach_header_64 {
	uint32_t	magic;		/* mach magic number identifier */
	cpu_type_t	cputype;	/* cpu specifier */
	cpu_subtype_t	cpusubtype;	/* machine specifier */
	uint32_t	filetype;	/* type of file */
	uint32_t	ncmds;		/* number of load commands */
	uint32_t	sizeofcmds;	/* the size of all the load commands */
	uint32_t	flags;		/* flags */
	uint32_t	reserved;	/* reserved */
};

/* Constant for the magic field of the mach_header_64 (64-bit architectures) */
#define MH_MAGIC_64 0xfeedfacf /* the 64-bit mach magic number */
#define MH_CIGAM_64 0xcffaedfe /* NXSwapInt(MH_MAGIC_64) */

filetype表示类型，常见的有:

  • MH_OBJECT: 可重定向的目标文件
  • MH_EXECUTE: 可执行文件
  • MH_DYLIB: 动态绑定的共享库文件
  • …

flags为不同的文件标签的组合，每个标签占一个位，可以用位或来进行组合，常见的标签有:

  • MH_NOUNDEFS: 该文件没有未定义的引用
  • MH_DYLDLINK: 该文件将要作为动态链接器的输入，不能再被静态链接器修改
  • MH_TWOLEVEL: 该文件使用两级名字空间绑定
  • MH_PIE: 可执行文件会被加载到随机地址，只对MH_EXECUTE有效
  • …

另外一个值得关注的就是ncmds和sizeofcmds，分别指定了 LOAD_COMMAND 的个数以及总大小，从这里也大概能猜到，每个 command 的大小是可变的。

LOAD_COMMAND是体现MachO文件拓展性的地方，每个 command 的头两个word分别表示类型和大小，如下:

struct load_command {
	uint32_t cmd;		/* type of load command */
	uint32_t cmdsize;	/* total size of command in bytes */
};

不同的cmd类型都会有其对应的结构体来描述其内容，cmdsize表示的是整个cmd的大小，即包括头部和内容。也就是说在处理的时候当前cmd的位置加上cmdsize就是下一个cmd的位置。注意每个command的大小(即cmdsize)需要word对齐，对于32位CPU来说是4字节，64位则是8字节；同时对齐末尾的填充部分必须是0。

loader.h中绝大部分的篇幅就是用来定义各种不同command类型的结构体了，这里挑选一些比较常见的来进行介绍。

LC_SEGMENT/LC_SEGMENT64可以说是最重要的一个command。表示当前文件的一部分将会映射到目标进程(task)的地址空间中，包括程序运行所需要的所有代码和数据。假设当前MachO文件的起始地址为begin，则映射的内容为:

  • 原始地址(文件地址): begin + fileoff，大小为filesize
  • 目的地址(进程虚址): vmaddr，大小为vmsize

其中vmsize >= filesize，如果有多出来的部分需要填充为零。segment_command的结构体表示如下:

struct segment_command_64 { /* for 64-bit architectures */
	uint32_t	cmd;		/* LC_SEGMENT_64 */
	uint32_t	cmdsize;	/* includes sizeof section_64 structs */
	char		segname[16];	/* segment name */
	uint64_t	vmaddr;		/* memory address of this segment */
	uint64_t	vmsize;		/* memory size of this segment */
	uint64_t	fileoff;	/* file offset of this segment */
	uint64_t	filesize;	/* amount to map from the file */
	vm_prot_t	maxprot;	/* maximum VM protection */
	vm_prot_t	initprot;	/* initial VM protection */
	uint32_t	nsects;		/* number of sections in segment */
	uint32_t	flags;		/* flags */
};

maxprot/initprot表示对应segment虚拟地址空间的RWX权限。如果segment包含一个或者多个section，那么在该segment结构体之后就紧跟着对应各个section头，总大小也包括在cmdsize之中，其结构如下:

struct section_64 { /* for 64-bit architectures */
	char		sectname[16];	/* name of this section */
	char		segname[16];	/* segment this section goes in */
	uint64_t	addr;		/* memory address of this section */
	uint64_t	size;		/* size in bytes of this section */
	uint32_t	offset;		/* file offset of this section */
	uint32_t	align;		/* section alignment (power of 2) */
	uint32_t	reloff;		/* file offset of relocation entries */
	uint32_t	nreloc;		/* number of relocation entries */
	uint32_t	flags;		/* flags (section type and attributes)*/
	uint32_t	reserved1;	/* reserved (for offset or index) */
	uint32_t	reserved2;	/* reserved (for count or sizeof) */
	uint32_t	reserved3;	/* reserved */
};

每个section头对应一个section，位置在相对文件起始地址的offset处，大小为size字节，对应的虚拟地址为addr。这里的align对齐指的是在虚拟地址空间中的对齐，实际上在文件中是连续存放的，因为有size指定大小。reloff和nreloc与符号的重定向有关，在下面的加载过程一节中再进行介绍。

从这里可以看出，section的内容和segment是不连续存放的，只是section header在对应segment之后。而segment的vmsize实际上会大于segment+section_header的大小(即cmdsize)，猜测多出来的空间是内核加载MachO时将对应section内容填充进去，后面将会对这一猜测进行验证。

TEXT

__TEXT段包含__text、__stubs、__stub_helper、__cstring等section，一般用来存放不可修改的数据，比如代码和const字符串，可以用otool查看对应的section内容:

$ otool -V main -s __TEXT __stubs
main:
Contents of (__TEXT,__stubs) section
0000000100000f6a	jmpq	*0xa8(%rip) ## literal pool symbol address: _printf
0000000100000f70	jmpq	*0xaa(%rip) ## literal pool symbol address: _set_foo

在实际的MachO可执行文件中观察发现TEXT的fileoff为0，也就是说TEXT段映射的时候会将当前文件头部分也映射到进程空间中。

(lldbinit) image dump sections main
Sections for '/Users/evilpan/temp/macho-test/main' (x86_64):
  SectID     Type             Load Address                             Perm File Off.  File Size  Flags      Section Name
  ---------- ---------------- ---------------------------------------  ---- ---------- ---------- ---------- ----------------------------
  0x00000100 container        [0x0000000000000000-0x0000000100000000)* ---  0x00000000 0x00000000 0x00000000 main.__PAGEZERO
  0x00000200 container        [0x0000000100000000-0x0000000100001000)  r-x  0x00000000 0x00001000 0x00000000 main.__TEXT
  0x00000001 code             [0x0000000100000ee0-0x0000000100000f6a)  r-x  0x00000ee0 0x0000008a 0x80000400 main.__TEXT.__text
  0x00000002 code             [0x0000000100000f6a-0x0000000100000f76)  r-x  0x00000f6a 0x0000000c 0x80000408 main.__TEXT.__stubs
  0x00000003 code             [0x0000000100000f78-0x0000000100000f9c)  r-x  0x00000f78 0x00000024 0x80000400 main.__TEXT.__stub_helper
  0x00000004 data-cstr        [0x0000000100000f9c-0x0000000100000fb0)  r-x  0x00000f9c 0x00000014 0x00000002 main.__TEXT.__cstring
  0x00000005 compact-unwind   [0x0000000100000fb0-0x0000000100000ff8)  r-x  0x00000fb0 0x00000048 0x00000000 main.__TEXT.__unwind_info
  0x00000300 container        [0x0000000100001000-0x0000000100002000)  rw-  0x00001000 0x00001000 0x00000000 main.__DATA
  0x00000006 data-ptrs        [0x0000000100001000-0x0000000100001008)  rw-  0x00001000 0x00000008 0x00000006 main.__DATA.__nl_symbol_ptr
  0x00000007 data-ptrs        [0x0000000100001008-0x0000000100001018)  rw-  0x00001008 0x00000010 0x00000006 main.__DATA.__got
  0x00000008 data-ptrs        [0x0000000100001018-0x0000000100001028)  rw-  0x00001018 0x00000010 0x00000007 main.__DATA.__la_symbol_ptr
  0x00000009 zero-fill        [0x0000000100001028-0x000000010000102c)  rw-  0x00000000 0x00000000 0x00000001 main.__DATA.__common
  0x00000400 container        [0x0000000100002000-0x0000000100007000)  r--  0x00002000 0x00004a90 0x00000000 main.__LINKEDIT

上面例子中__TEXT段的的vm_size和file_size都是0x1000，这个大小在文件中正好是第一个__DATAsection的起始地址:

data.png

__PAGEZERO是一个特殊的段，主要目的是将低地址占用，防止用户空间访问。个人理解这是对空指针引用类型漏洞的一种缓解措施，Linux内核中也有mmap_min_addr来限制用户可以mmap映射的最低地址。

__DATA段则包含__got、__nl_symbol_ptr、__la_symbol_ptr等section，一般包括可读写的内容。

另外一个重要的段为__LINKEDIT，其中包含需要被动态链接器使用的信息，包括符号表、字符串表、重定位项表、签名等。该段和PAGEZERO一样的是末尾没有额外的section信息，所以cmdsize都等于72(sizeof(struct segment_command_64))。其内容即begin + fileoff指向的地方保存linkedit command的内容，这个内容的格式根据具体cmd的不同而不同。LINKEDIT可以理解为元数据，值得一提的是，经过观察，fileoff +filesize 即为MachO文件末尾，也就是等于文件的大小。

那么LINKEDIT块中的内容是什么格式呢？其实大部分有其专门的格式，比如对Dynamic Loader Info来说是字节码，对于符号表来说是符号表结构体，对于函数地址项来说是uleb128编码的地址值，……因此LINKEDIT可谓包罗万象，需要具体问题具体分析，下面介绍的几个command就是其中几个例子。

Signature Command指定当前文件的签名信息，没有单独的结构体，而是使用下面这个结构来表示:

struct linkedit_data_command {
    uint32_t	cmd;		/* LC_CODE_SIGNATURE, LC_SEGMENT_SPLIT_INFO,
                                   LC_FUNCTION_STARTS, LC_DATA_IN_CODE,
				   LC_DYLIB_CODE_SIGN_DRS or
				   LC_LINKER_OPTIMIZATION_HINT. */
    uint32_t	cmdsize;	/* sizeof(struct linkedit_data_command) */
    uint32_t	dataoff;	/* file offset of data in __LINKEDIT segment */
    uint32_t	datasize;	/* file size of data in __LINKEDIT segment  */
};

cmd/cmdsize和前面LC_SEGMENT的含义类似，只不过cmdsize是个常数，等于当前结构体的大小。dataoff表示前面信息在LINKEDIT数据中的偏移，注意这里不是相对文件头的偏移；datasize则表示签名信息的大小。

苹果的签名数据格式并不是常规类型，对其详细介绍超过了本文的范围，对于具体的签名实现有兴趣的可以参考Jonathan大神的*OS Internal或者Code Signing – Hashed Out。使用jtool工具可以打印出详细的签名信息，如下所示:

$ jtool2 --sig -v main
An embedded signature of 1953 bytes, with 3 blobs:
	Blob 0: Type: 0 @36: Code Directory (213 bytes)
		Version:     20100
		Flags:       none
		CodeLimit:   0x22c0
		Identifier:  main (@0x30)
		CDHash:	     f3d8c9a75487ecc6f3adbddca11ad987a171e8974e6df15e857d2ac962e4b886 (computed)
		# of hashes: 3 code (4K pages) + 2 special
		Hashes @117 size: 32 Type: SHA-256
	Blob 1: Type: 2 @249: Requirement Set (80 bytes) with 1 requirement:
Unknown opcode 14 - has Apple changed the op codes?Please notify J!
		0: Designated Requirement (@20, 48 bytes): Ident(main) AND
	Blob 2: Type: 10000 @329: Blob Wrapper (1624 bytes) (0x10000 is CMS (RFC3852) signature)
		Timestamp: 00:12:38 2020/09/06

当然官方的codesign -d也可以。

这个Command的信息主要是提供给动态链接器dyld的，其结构如下:

struct dyld_info_command {
   uint32_t   cmd;		/* LC_DYLD_INFO or LC_DYLD_INFO_ONLY */
   uint32_t   cmdsize;		/* sizeof(struct dyld_info_command) */
   uint32_t   rebase_off;	/* file offset to rebase info  */
   uint32_t   rebase_size;	/* size of rebase info   */
   uint32_t   bind_off;	/* file offset to binding info   */
   uint32_t   bind_size;	/* size of binding info  */
	 uint32_t   weak_bind_off;	/* file offset to weak binding info   */
   uint32_t   weak_bind_size;  /* size of weak binding info  */
   uint32_t   lazy_bind_off;	/* file offset to lazy binding info */
   uint32_t   lazy_bind_size;  /* size of lazy binding infs */
   uint32_t   export_off;	/* file offset to lazy binding info */
   uint32_t   export_size;	/* size of lazy binding infs */
}

虽然看起来很复杂，但实际上它的目的就是为了给dyld提供能够加载目标MachO所需要的必要信息: 因为可能加载到随机地址，所以需要rebase信息；如果进程依赖其他镜像的符号，则绑定需要bind信息；对于C++程序而言可能需要weak bind实现代码/数据复用；对于一些外部符号不需要立即绑定的可以延时加载，这就需要lazy bind信息；对于导出符号也需要对应的export信息。

为了描述这些rebase/bind信息，dyld定义了一套伪指令，用来描述具体的操作(opcode)及其操作数据。以延时绑定为例，操作符看起来是这样:

opcode.png

其表达的实际含义用中文来描述就是:

  1. _printf符号(来自libSystem.B.dylib)延时绑定到0x1018偏移地址；
  2. _set_foo符号(来自libfoo.dylib)延时绑定到0x1020偏移地址；

其中0x1018/0x1020地址在__DATA段，更准确来说是在__la_symbol_ptr这个section中，可以自行编译验证。

LC_LOAD_{,WEAK_}DYLIB用来告诉内核(实际上是dyld)当前可执行文件需要使用哪些动态库，而其结构如下:

struct dylib {
    union lc_str  name;			/* library's path name */
    uint32_t timestamp;			/* library's build time stamp */
    uint32_t current_version;		/* library's current version number */
    uint32_t compatibility_version;	/* library's compatibility vers number*/
};

struct dylib_command {
	uint32_t	cmd;		/* LC_ID_DYLIB, LC_LOAD_{,WEAK_}DYLIB, LC_REEXPORT_DYLIB */
	uint32_t	cmdsize;	/* includes pathname string */
	struct dylib	dylib;		/* the library identification */
};

动态库(filetype为MH_DYLIB)中会包含 LC_ID_DYLIB command 来说明自己是个什么库，包括名称、版本、时间戳等信息。需要注意的是lc_str并不是字符串本身，而是字符串的偏移值，字符串信息在command的内容之后，该偏移指的是距离command起始位置的偏移。

LC_REEXPORT_DYLIB表示加载并重新导出dylib

除了上面的介绍，还有许多其他类型的 command ，比如LC_FUNCTION_STARTS表示函数入口地址，LC_MAIN表示主函数地址，LC_ENCRYPTION_INFO表示加密的segment段等等，可以在遇到的时候用查看loader.h的定义，这里就不再赘述了。

加载过程

MachO的加载和ELF的加载过程没有太大区别，还是系统调用->内核处理->返回执行的一般流程，对于静态链接程序返回执行是直接返回到程序入口地址，而动态链接程序则需要在程序开始执行之前进行重定向，因此这里也按照这个顺序介绍。

内核空间的主要任务是创建新 task 并初始化内存页和对应的权限，我们主要关注MachO文件的处理部分，即parse_machfile函数，文件为bsd/kern/mach_loader.c，其主要功能为检查header以及cmdsize等长度符合预期，然后通过4次循环来处理不同的信息，如下:

	/*
	 *  Scan through the commands, processing each one as necessary.
	 *  We parse in three passes through the headers:
	 *  0: determine if TEXT and DATA boundary can be page-aligned
	 *  1: thread state, uuid, code signature
	 *  2: segments
	 *  3: dyld, encryption, check entry point
	 */

这里重点关注pass2，关键代码如下:

		offset = mach_header_sz;
		ncmds = header->ncmds;

		while (ncmds--) {

			/* ensure enough space for a minimal load command */
			if (offset + sizeof(struct load_command) > cmds_size) {
				ret = LOAD_BADMACHO;
				break;
			}

			/*
			 *	Get a pointer to the command.
			 */
			lcp = (struct load_command *)(addr + offset);
			oldoffset = offset;

      // offset = offset + lcp->cmdsize 
			if (os_add_overflow(offset, lcp->cmdsize, &offset) ||
					lcp->cmdsize < sizeof(struct load_command) ||
					offset > cmds_size) {
				ret = LOAD_BADMACHO;
				break;
			}
      
			switch(lcp->cmd) {
			case LC_SEGMENT: {/* 32位... */}
			case LC_SEGMENT_64: {
				struct segment_command_64 *scp64 = (struct segment_command_64 *)lcp;
				// pass 0/1 的处理
        // ...
				if (pass != 2)
					break;
				ret = load_segment(lcp /*, ... */);
        // ...
				break;
      }
			case LC_MAIN:
				// ...
				ret = load_main((struct entry_point_command *)lcp /*, ... */);
				break;
			case LC_CODE_SIGNATURE:
        // ...
				ret = load_code_signature((struct linkedit_data_command *)lcp /*, ... */);
        got_code_signatures = ret == LOAD_SUCCESS ? TRUE : FALSE;
				if (got_code_signatures) {
					while (off < alloc_size && ret == LOAD_SUCCESS) {
					     valid = cs_validate_range(vp,
								       NULL,
								       file_offset + off,
								       addr + off,
								       PAGE_SIZE,
								       &tainted);
            // ...
          }
        }
        break;
#if CONFIG_CODE_DECRYPTION
			case LC_ENCRYPTION_INFO:
			case LC_ENCRYPTION_INFO_64:
        if (pass != 3) break;
      	// 处理加密的segment，用于iOS中的Apple Store应用的加密，在macOS的内核中未启用
        // 内核中只是设置好decrypter，并没有真正解密
				ret = set_code_unprotect( (struct encryption_info_command *) lcp /*, ...*/)；
#endif
      // ...
			default:
				/* Other commands are ignored by the kernel */
				ret = LOAD_SUCCESS;
				break;
      }

其中很多command比如LC_LOAD_DYLIB、LC_DYLD_INFO_ONLY等不在内核态中进行处理，直接进入default分支忽略。

这个函数主要负责加载segment到内存中，实现有几个值得一提的点:

  • total_section_size = lcp->cmdsize - sizeof(struct segment_command_64)；这是文件后面section的大小
  • LC_SEGMENT_32会转换为LC_SEGMENT_64，使用widen_segment_command
  • 映射的内存地址是slide + scp->vmaddr，slide为随机化的地址偏移(如果有的话)，映射的内存大小是scp->vmsize
  • 文件中对应内容起始位置是scp->fileoff，大小为scp->filesize
  • file_offset = pager_offset + scp->fileoff，是该segment在内核空间中的地址，需要页对齐
  • 对于0地址页的映射，由于用户空间不能访问，因此直接增加了vm能访问的最低地址值(vm_map_raise_min_offset)，仅允许对PAGEZERO段执行0地址的映射命令

对于映射的地址和大小，都需要是4k页对齐的，并且最终使用map_segment进行映射:

file_start = vm_map_trunc_page(file_offset, effective_page_mask);
file_end = vm_map_round_page(file_offset + file_size, effective_page_mask);
vm_start = vm_map_trunc_page(vm_offset, effective_page_mask);
vm_end = vm_map_round_page(vm_offset + vm_size, effective_page_mask);
ret = map_segment(map, vm_start, vm_end, control, file_start, file_end,
                  initprot, maxprot, result);

根据对代码的分析，内核中并不关心具体section的内容，即不解析单个section头的具体字段，而是以segment为单位进行映射。一般而言映射的是具体内容的值，比如__DATA段就映射了数据段。前面也说过__TEXT段比较特别，它是从文件开头开始映射的，一直到代码段的末尾(数据段的开头)。

MachO和ELF的一个最大不同点，或者说XNU和Linux的不同点是前者原生支持了对可执行文件的签名认证，文件的签名信息保存在LINKEDIT数据段，在前面我们已经介绍过了LC_CODE_SIGNATURE的内容。

load_main函数主要用来处理LC_MAIN命令，这里面包括了可执行文件的入口地址以及栈大小信息。但是在内核中并不需要关心main函数信息，而只需要关心入口信息(entry_point)。因此在load_main中只对栈和线程进行初始化，并且修改对应的result信息:

	result->user_stack = addr;
	result->user_stack -= slide;

	result->needs_dynlinker = TRUE;
	result->using_lcmain = TRUE;

	ret = thread_state_initialize( thread );

此时result->entry_point还是0(MACH_VM_MIN_ADDRESS)。

另外一个能决定入口地址的command是LC_UNIXTHREAD，类似于UNIX中直接将start符号导出，该符号应该是在crt1.o里的，但苹果并不默认提供。也就是说如果想要静态编译，需要自己下载源文件自己去编译，或者自己链接并导出这个符号。苹果不支持静态编译的原因是出于兼容性的考虑。

在load_main结束后，需要加载动态链接器:

		/* Make sure if we need dyld, we got it */
		if (result->needs_dynlinker && !dlp) {
			ret = LOAD_FAILURE;
		}

		if ((ret == LOAD_SUCCESS) && (dlp != 0)) {
			/*
			 * load the dylinker, and slide it by the independent DYLD ASLR
			 * offset regardless of the PIE-ness of the main binary.
			 */
			ret = load_dylinker(dlp, dlarchbits, map, thread, depth,
					    dyld_aslr_offset, result, imgp);
		}

动态链接器就是dyld，在LC_LOAD_DYLINKER命令中指定，通常是/usr/lib/dyld。load_dylinker内部也同样调用了parse_machfile函数，因此大部分操作是类似的。注意到这里其实涉及到了递归调用，因此需要在该函数中加depth参数表示递归层数。

dyld文件中有LC_UNIXTHREAD命令，因此其result->entry_point将被设置，在原先的parse_mach返回到load_machfile后，则初始化新的内核task并将执行流交还给用户空间，对于大部分程序而言，就是跳转到dyld的起始地址执行。

从内核回到用户空间，便跳转到目标的入口地址开始执行。对于静态链接链接程序，实际上执行的是dyld中的指令，该程序的源码可以参考opensource-apple/dyld。

dyld的起始地址固定为0x1000，这个地址对应的符号是__dyld_start，文件定义在src/dyldStartup.s。这部分代码和crt0.o中的代码是一样的，主要是用来初始化C Runtime，唯一的不同点是有个额外的参数用来指定MachO文件头的地址。

初始化完成后调用call __ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm，demangle之后为下面的函数:

//
//  This is code to bootstrap dyld.  This work in normally done for a program by dyld and crt.
//  In dyld we have to do this manually.
//
uintptr_t start(const struct macho_header* appsMachHeader, int argc, const char* argv[], 
				intptr_t slide, const struct macho_header* dyldsMachHeader,
				uintptr_t* startGlue) {
  	// if kernel had to slide dyld, we need to fix up load sensitive locations
	// we have to do this before using any global variables
	if ( slide != 0 ) {
		rebaseDyld(dyldsMachHeader, slide);
	}

	// allow dyld to use mach messaging
	mach_init();

	// kernel sets up env pointer to be just past end of agv array
	const char** envp = &argv[argc+1];
	
	// kernel sets up apple pointer to be just past end of envp array
	const char** apple = envp;
	while(*apple != NULL) { ++apple; }
	++apple;

	// set up random value for stack canary
	__guard_setup(apple);

#if DYLD_INITIALIZER_SUPPORT
	// run all C++ initializers inside dyld
	runDyldInitializers(dyldsMachHeader, slide, argc, argv, envp, apple);
#endif

	// now that we are done bootstrapping dyld, call dyld's main
	uintptr_t appsSlide = slideOfMainExecutable(appsMachHeader);
	return dyld::_main(appsMachHeader, appsSlide, argc, argv, envp, apple, startGlue);
}

所以dyld真正的入口地址是dyld::_main，该函数的功能主要有:

  1. 初始化上下文(setContext)
  2. 将可执行文件的路径转为绝对路径
  3. 处理环境变量
  4. 判断是否需要加载共享缓存库，如果需要加载则直接映射到内存中(mapSharedCache)
  5. 加载注入的动态库(sEnv.DYLD_INSERT_LIBRARIES)
  6. 链接主程序(dyld::link)，实际上用的是虚函数ImageLoader::link
  7. initializeMainExecutable: 运行初始化函数(__mod_init_funcs)
  8. 执行最终的目标程序(LC_MAIN/LC_UNIXTHREAD)

最终目标程序正常执行，就像自己直接启动一样。下面挑几个比较关键的点进行深入分析。

链接是dyld的主要功能，执行实际动态链接功能的是link函数，除了链接待执行的目标程序，还链接所有插入的其他动态库:

		// link main executable
		gLinkContext.linkingMainExecutable = true;
		link(sMainExecutable, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL));
		// link any inserted libraries
		// do this after linking main executable so that any dylibs pulled in by inserted 
		// dylibs (e.g. libSystem) will not be in front of dylibs the program uses
		if ( sInsertedDylibCount > 0 ) {
			for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
				ImageLoader* image = sAllImages[i+1];
				link(image, sEnv.DYLD_BIND_AT_LAUNCH, true, ImageLoader::RPathChain(NULL, NULL));
				image->setNeverUnloadRecursive();
			}
			// only INSERTED libraries can interpose
			// register interposing info after all inserted libraries are bound so chaining works
			for(unsigned int i=0; i < sInsertedDylibCount; ++i) {
				ImageLoader* image = sAllImages[i+1];
				image->registerInterposing();
			}
		}

而dyld:link使用的是具体ImageLoader的link多态实现:

void link(ImageLoader* image, bool forceLazysBound, bool neverUnload, const ImageLoader::RPathChain& loaderRPaths)
{
	// add to list of known images.  This did not happen at creation time for bundles
	if ( image->isBundle() && !image->isLinked() )
		addImage(image);

	// we detect root images as those not linked in yet 
	if ( !image->isLinked() )
		addRootImage(image);
	
	// process images
	try {
		image->link(gLinkContext, forceLazysBound, false, neverUnload, loaderRPaths);
	}
	catch (const char* msg) {
		garbageCollectImages();
		throw;
	}
}

sMainExecutable的实现在开源代码中并没有给出，不过参考基类的默认实现如下:

void ImageLoader::link(const LinkContext& context, bool forceLazysBound, bool preflightOnly, bool neverUnload, const RPathChain& loaderRPaths)
{
	//dyld::log("ImageLoader::link(%s) refCount=%d, neverUnload=%d\n", this->getPath(), fDlopenReferenceCount, fNeverUnload);
	
	// clear error strings
	(*context.setErrorStrings)(dyld_error_kind_none, NULL, NULL, NULL);

	uint64_t t0 = mach_absolute_time();
	this->recursiveLoadLibraries(context, preflightOnly, loaderRPaths);
	context.notifyBatch(dyld_image_state_dependents_mapped);
	
	// we only do the loading step for preflights
	if ( preflightOnly )
		return;
		
	uint64_t t1 = mach_absolute_time();
	context.clearAllDepths();
	this->recursiveUpdateDepth(context.imageCount());

	uint64_t t2 = mach_absolute_time();
 	this->recursiveRebase(context);
	context.notifyBatch(dyld_image_state_rebased);
	
	uint64_t t3 = mach_absolute_time();
 	this->recursiveBind(context, forceLazysBound, neverUnload);

	uint64_t t4 = mach_absolute_time();
	if ( !context.linkingMainExecutable )
		this->weakBind(context);
	uint64_t t5 = mach_absolute_time();	

	context.notifyBatch(dyld_image_state_bound);
	uint64_t t6 = mach_absolute_time();	

	std::vector<DOFInfo> dofs;
	this->recursiveGetDOFSections(context, dofs);
	context.registerDOFs(dofs);
	uint64_t t7 = mach_absolute_time();	

	// interpose any dynamically loaded images
	if ( !context.linkingMainExecutable && (fgInterposingTuples.size() != 0) ) {
		this->recursiveApplyInterposing(context);
	}
	
	// clear error strings
  // ...
}

主要做的就是这几步:

  1. recursiveLoadLibraries
  2. recursiveUpdateDepth
  3. recursiveRebase
  4. recursiveBind
  5. weakBind
  6. recursiveGetDOFSections

根据名字不难看出其作用，其中大部分函数名称带recursive，这是因为动态库本身也可能会依赖其他的动态库，因此需要递归进行处理(当然循环依赖会有对应的处理)。其中recursiveUpdateDepth不太直观，其实作用只是为了对镜像进行排序，被依赖的库会出现在依赖者之前。

在上面第4步中说到要加载共享缓存库，这是个什么东西呢？这一步的目的其实是为了加速动态库的加载过程。对于我们自己编译的macOS命令行程序可能还好，但是对于图形界面应用来说，每个应用启动时需要加载的动态库可能有上百个，而其中很大一部分是系统库，比如UIKit、Foundation等。因此苹果就事先把这些常用的库打包成缓存，程序启动时候直接映射到内存中，而无需逐个执行繁琐的处理和解析。

映射共享缓存库的函数为mapSharedCache，首先检查共享缓存库是否已经映射过:

static int __attribute__((noinline)) _shared_region_check_np(uint64_t* start_address)
{
	if ( gLinkContext.sharedRegionMode == ImageLoader::kUseSharedRegion ) 
		return syscall(294, start_address);
	return -1;
}

294号系统调用定义在内核中(bsd/kern/syscalls.master):

294	AUE_NULL	ALL	{ int shared_region_check_np(uint64_t *start_address) NO_SYSCALL_STUB; }
295	AUE_NULL	ALL	{ int shared_region_map_np(int fd, uint32_t count, const struct shared_file_mapping_np *mappings) NO_SYSCALL_STUB; }

内核中的实现也比较简单，忽略错误检查，关键的代码如下:

int shared_region_check_np(
	__unused struct proc			*p,
	struct shared_region_check_np_args	*uap,
	__unused int				*retvalp) {
  // ...
  shared_region = vm_shared_region_get(current_task());
	if (shared_region != NULL) {
    		/* retrieve address of its first mapping... */
		kr = vm_shared_region_start_address(shared_region,
						    &start_address);
    		/* ... and give it to the caller */
		error = copyout(&start_address,
					(user_addr_t) uap->start_address,
					sizeof (start_address));
    // ...
		vm_shared_region_deallocate(shared_region);
  }
}

其内部实现姑且不管，继续回到用户空间，所返回的地址可以强制转换为dyld_cache_header格式:

struct dyld_cache_header
{
	char		magic[16];				// e.g. "dyld_v0    i386"
	uint32_t	mappingOffset;			// file offset to first dyld_cache_mapping_info
	uint32_t	mappingCount;			// number of dyld_cache_mapping_info entries
	uint32_t	imagesOffset;			// file offset to first dyld_cache_image_info
	uint32_t	imagesCount;			// number of dyld_cache_image_info entries
	uint64_t	dyldBaseAddress;		// base address of dyld when cache was built
	uint64_t	codeSignatureOffset;	// file offset of code signature blob
	uint64_t	codeSignatureSize;		// size of code signature blob (zero means to end of file)
	uint64_t	slideInfoOffset;		// file offset of kernel slid info
	uint64_t	slideInfoSize;			// size of kernel slid info
	uint64_t	localSymbolsOffset;		// file offset of where local symbols are stored
	uint64_t	localSymbolsSize;		// size of local symbols information
	uint8_t		uuid[16];				// unique value for each shared cache file
	uint64_t	cacheType;				// 1 for development, 0 for optimized
};

检查共享缓存空间存在则直接复制其UUID到进程的sharedCacheUUID中，然后直接使用该缓存。

如果不存在，就需要进行创建，创建的过程如下:

  1. 如果是x86环境，需要判断当前是否为安全启动模式，则会删除之前余留的cache文件，路径为/var/db/dyld/dyld_shared_cache_$arch
  2. 打开sharedCache文件，对于IPhone路径为/System/Library/Caches/com.apple.dyld/dyld_shared_cache_$arch
  3. 读取文件的前8192字节转换为struct dyld_cache_header，并做一些合法性检查
  4. 处理cache文件，主要是将mapping信息提取出来，保存为一个数组mappings[]
  5. 调用_shared_region_map_and_slide_np映射每个mapping

mapping信息如下:

struct dyld_cache_mapping_info {
	uint64_t	address;
	uint64_t	size;
	uint64_t	fileOffset;
	uint32_t	maxProt;
	uint32_t	initProt;
};

和之前提到的segment信息类似，没有feilsize，因为不存在padding。

_shared_region_map_and_slide_np函数分别处理每个mapping，并最终使用mmap来完成cache到内存的映射操作。

每个mapping info对应一个struct shared_file_mapping_np，但是这个结构体的定义在开源代码中没找到，并且在苹果文档中也进行了隐藏，见: https://developer.apple.com/documentation/kernel/shared_file_mapping_np

后记

本文通过对MachO文件的文件格式研究，介绍了MacOS和iOS中可执行文件的加载过程，从内核中的处理一直到动态连接器dyld的代码分析。可以看出MachO与ELF相比实现方式各有千秋，但是在内核中原生增加了对代码的签名和加密，其实ELF也很容易实现类似的功能，但开放系统需要更多考虑兼容性的问题，不像苹果可以大刀阔斧的随便改。

对于MachO的深入理解其实也有助于日常的相关研究，比如Apple Store的加密实现以及代码签名的大致原理，还有针对dyld_cache的处理等，其中每一项都值得去深入挖掘。而且本文也没有介绍到全部的MachO特性，比如Objective-C相关的段，具体的实战部分后面有时间会再去整理一下。

参考资料

]]> MOSEC-2020参会小记 https://evilpan.com/2020/07/25/mosec2020/ Sat, 25 Jul 2020 22:40:00 +0800 evilpan https://evilpan.com/2020/07/25/mosec2020/

昨天去参加了mosec2020的安全会议，这也是我第一次参加mosec，议题质量比预料中的要高，因此在这记录一下其中几个有意思的议题。

IO80211Family

第一个议题是王宇师傅(@keenjoy95)关于苹果WiFi子系统的安全研究分享，其实王宇在前一段时间就提了一大波苹果蓝牙子系统的漏洞，看来手里的料还是挺多的。之所以去撸WiFi子系统，也是因为“之前的一个0day在升级系统后不work了”，……说回思路方面，研究入口的寻找个人认为比较有启发性，利用Kemon的内核挂钩能力，确实可以做到往上拳打daemon process，往下脚踢kernel driver或firmware。

km
km

IO80211Family V1/V2的这些漏洞，也是因为在接口上发现有巨大的参数传入。一方面通过修改Kemon实现Passive Fuzzer，另一方面去逆向对于这些参数的处理和校验从而优化样本。效果怎么样呢？也就是“每天和panic打交道，对于一些品相不好的panic都懒得去分析”的地步吧。

另外，对于这些复杂的设备驱动，可以参考开源代码(AppleIntelWiFiMVM)，甚至自己去实现一遍，这样可能在分析时会有不一样的理解。

像WiFi、蓝牙、NFC这些攻击面其实影响是很大的，而这部分驱动或者firmware的开发者由于自恃功能复杂天知地知或者抱着能用就行的心理，对一些不可信数据没有意识添加完善的边界检查，导致实现往往在遇到非预期输入时存在bug或者漏洞从而引起内存破坏。这部分分析一个绕不过的门槛是逆向的基本功，安全研究人员做好头发的保养工作还是很有必要的。

另外王宇也提到了他在macbook touchbar图像驱动中也是有0day的，感兴趣的同学也可以尝试去撞一下:)

DroidCorn: 无源码Android Binary Fuzzing

这个议题是flanker(@Flanker_017)介绍了他(们？)做的一个无源码fuzzing框架。说到无源码fuzz，常见的两个流派就是binary patch和dynamic instrument，而DroidCorn听名字也大概能猜到了，就是基于Unicorn开发的动态插桩式执行引擎。

该引擎架构大致分为以下部分:

  • Crash Triager
    • Trace Recorder
    • Symbolizer
  • Mini Runtime
    • ELF linker
    • Mini Heap
    • Mini Hooker
  • Mini Kernel
    • Memory Layer
    • Syscall Handler
  • Processor
    • Unicorn(patched)
    • ForkServer
    • Tracer

无源fuzz的思路和AFL-unicorn类似，在QEMU执行Translation Block的时候插入afl_maybe_log记录执行覆盖率。Unicorn本身只是QEMU中CPU Emulation部分代码提炼出来的可编程框架，要实现二进制程序的加载和运行还需要依赖于linker和内核的正确处理。DroidCorn中在这部分做了不少工作，实现自定义的ELF Linker、Runtime以及根据不同应用实现不同的内核系统调用(~20个)，这让我想起了另一个类似的框架qiling.io。最后作为PoC，展示了三星手机图片库中找到的一些漏洞，不过工具想必近期是不会开源了，自己动手丰衣足食吧。

也许以后这类更偏向实战的无源fuzz会是一大热点。CPU指令的软件模拟运行的虽然可以做很多优化，但性能终究是比不上原生虚拟化的支持，ARM Server FTW？

深入浅出JSC优化措施

大宝(@S0rryMybad)的议题，讲得太深，而且又是我的知识盲区，所以不多介绍。唯一的收获是学会了面向RCE的“倒序挖洞法”，针对类型混淆去搜寻JS Array类型改变和检查的地方并寻找潜在的非预期状态。C/C++的代码审计和php有很大不同，但是现在网上更多的资料是关于后者，这个未来有时间也值得谈谈。

暗涌2020

slipper的议题，光听名字完全不知道说啥，副标题是小米5c中国产自研手机芯片澎湃S1分析，其实我觉得标题应该改成“小米5c: 年轻人的第一个fullchain” :)。

虽然标题说是芯片，不过和芯片本身没什么太大关系。议题本身还是很精彩的，从头到尾介绍了如何实现one-click获得小米5c的持久化root权限(准确来说可以达到S-EL1的权限)。

由于安卓的碎片化，小米ROM中其实还是Android7.1，所以在攻击链中有几部分使用了n-day，比如webview和sepolicy的问题。小米5c使用了OP-TEE作为TEE的实现，从其中某个TA里发现漏洞函数，通过在用户态发送消息可以触发。一般TA中都是没有现代mitigation的，所以直接栈溢出+ROP来返回内核并进行patch从而获取了root权限；最后则是通过分析firstboot(LK+aboot)发现特殊入口绕过SecureBoot从而实现持久化。

最近中美关系紧张，可能会出现更多的国产芯片。除了芯片本身的硬件实现外，软件设施也需要跟上时代。华为海思是个很好的例子，虽然其TEE(iTrustee，之前是Trusted Core)也曾经有过漏洞，但至少是和国际持平的。开源实现也不是不能用，不过开发者移植的时候最好先有个全面理解，这样也不至于把开源项目的测试接口原汁原味编译进release版本中，然后被安全研究员在大会上公开diss了:)

攻击SEP的安全启动

徐昊(@windknown)的压轴议题，这也是我觉得最有干货的一个议题了。在checkm8出来后，攻击者号称这是ROM的代码漏洞无法被修复，但是苹果计划在iOS14中修复这个问题，修复方法之一就是通过SEP。SEP是安全处理器(Secure Enclave Processor)，与ARM提供的Truszone总线隔离不同，而是使用了一个独立的处理器来专门处理敏感信息。

关于SEP的公开信息并不多，曾经在2016年BlackHatUS中的议题“Demystifying the Secure Enclave Processor”介绍过，此后很长一段时间都没有相关的安全分析。SEP同样也是一个ARM处理器，拥有独立的RAM和外设，如加密引擎(GID/UID)和TRNG，但同时也有部分和应用处理器共用的资源，比如电源管理(PMGR)、Mailbox和共享内存。

Mailbox是SEP和AP之间唯一的通信信道，基于双方都能访问的映射IO寄存器实现。AP端的映射基地址是0x20da04000，SEP端映射的虚拟地址是0xcda00b80(物理地址为0x20da00b80)。Mailbox信息(messages)的大小是8字节，其中4字节为data，数据结构如下:

struct __attribute__((packed)) sep_message {
	unsigned __int8 endpoint;
	unsigned __int8 tag;
	unsigned __int8 opcode;
	unsigned __int8 param;
	unsigned int data;
}

sep
sep

这个议题本身更多关注与安全启动部分，作者逆向分析了SEP ROM中的代码，分析地址映射和地址保护初始化的逻辑，并寻找其中的攻击点，最终在部分型号下实现SEP的memory读写。可能由于作者还没有完全撸完，所以后面留了一手，不过总的来说也算给其他研究者提供了一个指引方向，后面应该会针对SEP有个小爆发。

Baijiu Con

会后的环节是白酒Con，想上台讲的喝一杯白酒讲五分钟，挺新颖的形式。其中也有一些有趣的议题，比如:

  • 王宇介绍了SEP研究的一些其他相关资料和最新进展
  • 王勇(ThomasKing2014)介绍了一种名为Arch-flip的奇淫技巧，在运行时切换ARM32/64位的运行环境，可用来辅助写chrome exp或者反逆向
  • Rancho介绍了Windows打印驱动的安全研究
  • redra1n介绍了供应链攻击，red on red，用魔法打败魔法(●—●)
  • 360的小哥介绍了奔驰汽车安全研究，进入汽车系统后发现一个越权远程控制任意奔驰的漏洞(还好买不起)
  • iOS in 2020: 秀了一把最新iOS 14的越狱，不说了，盘古NB
  • Chromium Series in TCTF: 分享CTF中遇到的Chromium的漏洞利用技巧

虽然会议视频和slides没有公开，但是CTF主播slipper在斗鱼直播间中直播了Baijiu Con部分的演讲，感兴趣的可以去看看，直播间号码是7851291

]]> 免越狱调试与分析黑盒iOS应用 https://evilpan.com/2019/04/07/ios-reverse-basics/ Sun, 07 Apr 2019 22:40:00 +0800 evilpan https://evilpan.com/2019/04/07/ios-reverse-basics/ 上篇文章我们从开发者的角度介绍了如何建立iOS项目并且在真机上运行， 上上篇文章则介绍了Objective-C的基本概念和用法。而这一切，都是为了这次的铺垫。 今天，我们就要从攻击者的角度，尝试对黑盒iOS应用进行调试与动态跟踪(instrument)。

前言

为什么要执着于免越狱呢？因为随着iOS系统的不断更新，其安全性也越来越高， 挖掘越狱漏洞也越来越难，很多新版本都已经没有公开的越狱方案了。 近来苹果也会给提交越狱漏洞的白帽不菲的奖励， 加上越狱对于普通用户的好处也越来越少， 很多越狱工具的开发者也逐渐不再更新维护。因此，免越狱分析，很有可能是未来唯一的方法。

How

其实免越狱测试应用也不是什么新技术了，Android中也有类似免root测试的方法。 而这两个方法其实本质上都是一样的，那就是 —— 重打包。

对于Android来说，就是将安装包解压后注入字节码，使得应用在启动前加载我们准备的.so动态库， 从而实现在应用的上下文执行任意代码的目的；对于iOS也是一样，区别是所注入的动态库为.dylib。

获取目标

在上篇文章中其实有说了，开发者在编译iOS或者MacOS项目时，最终生成的应该是.app文件， 但在iOS中还需要对app文件进行打包，生成.ipa文件。AppStore下载的应用实际上是加密ipa， 一般而言可以使用下面的工具来进行还原，这一步俗称砸壳。

砸壳操作本质上是在运行时从内存里将原始文件导出，因此都需要有在源程序上下文中执行代码的能力， 也就是说，需要越狱。对于我们的场景而言，可以在第三方应用市场去下载已经解密的ipa文件， 比如AppCake或者PP助手（以及各种xx助手）等。

Tips：

对于PP助手，可以用下面的地址搜索对应应用：
    https://www.25pp.com/ios/search_app_0/关键词
在应用详情界面中，通过查看网页源代码即可看到base64编码的ipa的下载地址。

以2048小游戏为例，我们把下载的越狱程序保存为pp2048.ipa，前面也说过，ipa本质上是zip格式， 将其解压后目录结构如下：

$ unzip pp2048.ipa -d pp2048
$ tree -d 1 pp2048
1 [error opening dir]
pp2048
├── META-INF
└── Payload
    └── 2048.app
        ├── 2048
        ├── Frameworks
        ├── _CodeSignature
        ├── en.lproj
        ├── es.lproj
        ├── fr.lproj
        ├── ...
        └── zh-Hans.lproj

otool命令可以输出app的load commands，可通过查看cryptid标志位来判断app加密状态。 其中1代表加密，0代表已解密：

$ otool -l pp2048/Payload/2048.app/2048  | egrep 'LC_ENCRYPTION_INFO|cryptid'
          cmd LC_ENCRYPTION_INFO
      cryptid 0
          cmd LC_ENCRYPTION_INFO_64
      cryptid 0

这一步对于我们后续的分析是必须的，因为如果app没有解密，那么后面即使重打包安装了， 也依然无法运行。

签名与重打包

有了解密的应用程序，接下来要做的就是对其进行重打包从而注入我们的代码了。 在重打包之前，可以先查看一下原APP的签名信息。

解压后可以看到Payloads下有2048.app文件夹，这便是我们需要的应用程序。 可以用苹果自带的codesign工具验证和查看签名信息：

验证签名：

$ codesign --verify pp2048/Payload/2048.app
pp2048/Payload/2048.app: invalid signature (code or signature have been modified)
In architecture: armv7

可以看到签名验证失败，一般越狱应用都会去除掉签名信息，如下：

$ codesign -d -vv pp2048/Payload/2048.app
Executable=/reverse/iOS/pp2048/Payload/2048.app/2048
Identifier=com.ketchapp.2048
Format=app bundle with Mach-O universal (armv7 arm64)
CodeDirectory v=20200 size=68369 flags=0x0(none) hashes=2129+5 location=embedded
Signature size=4297
Authority=(unavailable)
Info.plist=not bound
TeamIdentifier=BB5K34ZCVK
Sealed Resources version=2 rules=11 files=95
Internal requirements count=1 size=100

这一步不是必须的，但是有助于我们了解目标应用程序。

在注入代码之前，我们可以先尝试修改应用内的资源文件来重新打包看是否能正常运行。 步步为营，这样排除由于注入代码而导致的错误。

要做的很简单，向app中添加一个文本文件：

echo "Leave Me" > pp2048/Payload/2048.app/evilpan.txt

然后重新打包：

cd pp2048 && zip -qry ../pp2048-repack.ipa Payload

这样就生成了新的pp2048-repack.ipa文件。这时候的ipa还不能用，需要对其进行签名。

苹果要求ipa需要经过签名才能部署，Xcode7后可以使用个人Apple ID来进行provision签名， 用于在自己的设备上对应用进行测试。值得一提的是，ipa的签名和app签名还不太一样， 后者是用codesign工具进行签名，而ipa则需要第三方工具的帮助。

可以用于给ipa（重）签名的工具有一大把，比如：

还有很多没列举到的，这里使用node-appsign来签名：

applesign -i $SIGNID -m /path/to/embedded.mobileprovision pp2048-repack.ipa -o pp2048-resign.ipa

其中SIGNID指定用于签名的私钥，可用security命令来查看当前可用于给代码签名的SIGNID：

$ security find-identity -v -p codesigning
  1) CDC7************************************ "iPhone Developer: evilpan (V2KHK9DD9)"
  2) A3BB************************************ "org.radare.radare2"
     2 valid identities found

实际测试中发现似乎只能用第一个也就是Apple ID生成的私钥来进行签名。

在签名的命令中，还有一个需要提供的文件就是embedded.mobileprovision， 即provision profiles，这个文件可以在我们自己的iOS项目生成文件中找到，比如：

/Users/Peter/Library/Developer/Xcode/DerivedData/HelloWorld-dnyjqrgxcjjobvfzytzhtzpmjlmx/Build/Products/Debug-iphoneos/HelloWorld.app/embedded.mobileprovision
# 或者
~/Library/MobileDevice/Provisioning Profiles/

provision profiles是将签名，授权和沙盒联系起来文件，每个iOS开发者应该都不会陌生。 关于iOS/OSX代码签名和授权机制的介绍，强烈推荐这篇文章，这里就不展开了。

签名完成后的ipa就可以部署到真机上了，比如用我们上一篇文章说到的ios-deploy：

ios-deploy -b pp2048-resign.ipa

安装成功！如果是第一次启动，会提示不受信任的开发者，安装提示允许即可正常运行。

注入代码灵魂

现在我们已经验证了重打包应用的可行性，接下来就要开始做点有用的事情了。 为了在应用中执行我们自己的代码，我们可以直接修改二进制的2048.app/2048文件， 毕竟，它只是一个运行于ARM平台的普通Mach-O文件而已：

$ file pp2048/Payload/2048.app/2048
pp2048/Payload/2048.app/2048: Mach-O universal binary with 2 architectures: [arm_v7:Mach-O executable arm_v7] [arm64]
pp2048/Payload/2048.app/2048 (for architecture armv7):	Mach-O executable arm_v7
pp2048/Payload/2048.app/2048 (for architecture arm64):	Mach-O 64-bit executable arm64

可以使用十六进制编辑器如radare2对其进行patch，不过这种方式太原始，做点简单修改还行， 不方便做太复杂的操作。所以，一般还是直接在Mach-O中注入少量指令，并使其在运行时加载我们的动态库， 这样就可以在动态库中实现复杂的操作了。

在给iOS注入动态库之前，我们先在Mac下面测试一下注入动态库的可行性，二者平台是比较类似的。 首先编译一个简单的Mach-O可执行文件，如下：

$ cat hello.m
#import <Foundation/Foundation.h>

int main (int argc, const char * argv[])
{
    @autoreleasepool {
        NSLog (@"Hello, World!");
    }
    return 0;
}

$ clang -framework Foundation hello.m -o hello
$ ./hello
2019-04-07 12:38:10.031 hello[17348:3859846] Hello, World!

然后准备一个动态库文件libtest.m：

#import <Foundation/Foundation.h>

__attribute__((constructor)) void dylibMain()
{
    @autoreleasepool {
        NSLog(@"libtest LOADED!!!!!!!");
    }

}

__attribute__((constructor))宏描述dylibMain为动态库的constructor，即入口。 编译动态库的方法为：

$ clang -framework Foundation libtest.m -shared -o libtest.dylib
$ file libtest.dylib
libtest.dylib: Mach-O 64-bit dynamically linked shared library x86_64

在Linux中注入动态库最简单的方法就是使用LD_LIBRARY环境变量， Mac下也有类似的环境变量，为DYLD_INSERT_LIBRARIES，如下：

$ DYLD_INSERT_LIBRARIES=libtest.dylib ./hello
2019-04-07 12:44:08.810 hello[17497:3861923] libtest LOADED!!!!!!!
2019-04-07 12:44:08.812 hello[17497:3861923] Hello, World!

可以看到动态库中的代码已经被调用了，而且是在main函数之前。

在没越狱的iOS中，我们无法轻易给目标进程添加环境变量。不过既然能修改文件， 我们也可以将其改成在启动是自己加载指定动态库。有很多自动化工具可以帮助我们完成这个操作：

这些工具的作用都是在Mach-O的Load Commands段中添加一条LC_LOAD_DYLIB。 关于Mach-O的详细文件格式可以参考PARSING MACH-O FILES。

以insert_dylib为例，注入dylib只需一条命令：

$ ./hello
2019-04-07 12:57:42.274 hello[17728:3865999] Hello, World!

$ insert_dylib libtest.dylib hello
Added LC_LOAD_DYLIB to hello_patched

$ ./hello_patched
2019-04-07 12:57:58.425 hello_patched[17752:3866077] libtest LOADED!!!!!!!
2019-04-07 12:57:58.425 hello_patched[17752:3866077] Hello, World!

现在我们已经（在Mac上）验证了向二进制文件中注入动态库的可行性，接下来就是iOS了。 和Mac不同的是，iOS应用一般是ARM/ARM64版本，因此在x86的笔记本上，就需要交叉编译。 通过clang和Xcode提供的SDK，我们可以很方便在Mac上交叉编译iOS的应用或动态库：

clang -framework Foundation libtest.m -shared -o libtest.dylib -arch armv7 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk -mios-simulator-version-min=6

和ELF不同的是，Mach-O支持多架构，也就是说我们可以指定多个arch，生成的文件如下：

$ file libtest.dylib
libtest.dylib: Mach-O universal binary with 2 architectures: [arm_v7:Mach-O dynamically linked shared library arm_v7] [arm64:Mach-O 64-bit dynamically linked shared library arm64]
libtest.dylib (for architecture armv7):	Mach-O dynamically linked shared library arm_v7
libtest.dylib (for architecture arm64):	Mach-O 64-bit dynamically linked shared library arm64

但是一般只需要支持armv7即可，因为iOS新的CPU会兼容老的架构，详见iOS Support Matrix。

新生成的libtest.dylib此时还不能直接添加到ipa中，要时刻记住在iOS中， 所有的代码都需要有合法的签名。

$ codesign -f -v -s $SIGNID libtest.dylib
libtest.dylib: signed Mach-O universal (armv7 arm64) [libtest]

将libtest.dylib拷贝到ipa，并注入到可执行文件中，参考上面简单重打包的方法， 对最后的ipa进行重新打包签名。这里为了看到标准输出，直接使用lldb调试启动：

$ unzip pp2048-resign.ipa -d pp2048-resign
$ ios-deploy -b pp2048-resign/Payload/2048.app --debug -W
(lldb)     connect
(lldb)     run
success
libtest LOADED!!!!!!!
2019-04-07 13:49:49.731657+0800 2048[14630:3523860] [Accessibility] ****************** Loading GAX Client Bundle ****************
2019-04-07 13:49:50.085734+0800 2048[14630:3523860] [aurioc] 1029: failed: '!pla' (enable 2, outf< 2 ch,  44100 Hz, Float32, non-inter> inf< 2 ch,      0 Hz, Float32, non-inter>)
2019-04-07 13:49:50.127830+0800 2048[14630:3523860] error loading sound: a004
Process 14630 exited with status = 1 (0x00000001)
(lldb)

可以看到，libtest已经成功加载并执行了！这里需要一提的是我把libtest.m中的NSLog改成了printf， 因为测试中发现前者在运行时根本没有打印，这问题也令我测试了好久。

动态调试

终于，我们成功在目标iOS应用中注入了我们自己的动态库！由于动态库的代码是我们自己写的， 因此可以编写复杂的插件，在应用上下文执行任意代码。

刚刚启动时我们使用了ios-deploy的--debug参数来启动lldbserver/client 并自动attach，lldb是LLVM中功能强大的调试器，功能与gdb类似，如下：

(lldb) process interrupt
Process 14675 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00000002230efea4 libsystem_kernel.dylib`mach_msg_trap + 8
libsystem_kernel.dylib`mach_msg_trap:
->  0x2230efea4 <+8>: ret

libsystem_kernel.dylib`mach_msg_overwrite_trap:
    0x2230efea8 <+0>: mov    x16, #-0x20
    0x2230efeac <+4>: svc    #0x80
    0x2230efeb0 <+8>: ret
Target 0: (2048) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00000002230efea4 libsystem_kernel.dylib`mach_msg_trap + 8
    frame #1: 0x00000002230ef37c libsystem_kernel.dylib`mach_msg + 72
    frame #2: 0x00000002234f5ad8 CoreFoundation`__CFRunLoopServiceMachPort + 236
    frame #3: 0x00000002234f0974 CoreFoundation`__CFRunLoopRun + 1396
    frame #4: 0x00000002234f00e0 CoreFoundation`CFRunLoopRunSpecific + 436
    frame #5: 0x0000000225769584 GraphicsServices`GSEventRunModal + 100
    frame #6: 0x0000000250740c00 UIKitCore`UIApplicationMain + 212
    frame #7: 0x000000010298ca20 2048`___lldb_unnamed_symbol49$$2048 + 88
    frame #8: 0x0000000222faebb4 libdyld.dylib`start + 4
(lldb)

例如，使用lldb来对抗ptrace反调试：

# 设置断点
b ptrace

# 继续执行
continue

# 触发断点后直接跳转到返回地址
register write pc `$lr`

# 绕开ptrace继续运行
continue

lldb还支持python扩展，从而实现更丰富的自定义功能，详见LLDB-Python。

除了使用调试器，我们还可以使用frida来进行动态的hook， 其ObjC 接口提供了许多针对ObjectiveC的封装，对于Objective-C项目， 可以使用frida很轻松地修改应用程序逻辑。

在非越狱场景使用frida主要是通过frida-gadget，即通过重打包注入 frida-gadget.dylib动态库，流程和注入我们自己编译的libtest.dylib一模一样。 关于frida的详细使用方法可以多看看其官方文档。

使用insert_dylib注入frida-gadget.dylib例子如下：

cp frida-gadget.dylib pp2048/Payload/2048.app/
insert_dylib --strip-codesig --inplace '@executable_path/frida-gadget.dylib' pp2048/Payload/2048.app/2048

小结

至此，免越狱对应用进行动态分析的部分已经介绍完毕，这对于真正分析一个iOS程序还不完整， 但却是最重要的部分。分析一个iOS应用和其他应用一样，无非就是逆向分析与动态调试， 对于静态分析来说，一般也是使用Reveal定位关键点， 然后把Mach-O拖进逆向分析工具如IDA/radare2/Ghidra进行分析，复杂点的需要面对混淆和对抗， 因此动态分析也能帮助理解静态代码。而动态分析除了用于分析还能用于持久化， 这对于日常工作生活而言，或许是更为实用的。

参考链接

]]> iOS应用构建与部署小结 https://evilpan.com/2019/04/06/ios-basics/ Sat, 06 Apr 2019 22:40:00 +0800 evilpan https://evilpan.com/2019/04/06/ios-basics/ 上篇文章介绍了Objective-C的基本概念，本文就来接着看如何创建我们的第一个简单iOS应用， 本着简单可复现的方式，我们会以尽可能小的成本来构建并在真机运行iOS应用。 也就是说， 不用越狱， 也无需开发者账号。当然，一台iPhone手机还是需要的，最好还有一台Mac。

Xcode

iOS的应用必须要用Xcode来创建，步骤很简单：

  1. 下载并打开Xcode
  2. 选择ios -> Single View Application
  3. 填写项目名、开发组、包名（Identifier）

项目创建成功后，目录结构如下：

$ tree HelloWorld/
HelloWorld/
├── HelloWorld
│   ├── AppDelegate.h
│   ├── AppDelegate.m
│   ├── Assets.xcassets
│   │   ├── AppIcon.appiconset
│   │   │   └── Contents.json
│   │   └── Contents.json
│   ├── Base.lproj
│   │   ├── LaunchScreen.storyboard
│   │   └── Main.storyboard
│   ├── Info.plist
│   ├── ViewController.h
│   ├── ViewController.m
│   └── main.m
└── HelloWorld.xcodeproj
    ├── project.pbxproj
    ├── project.xcworkspace
    │   ├── contents.xcworkspacedata
    │   ├── xcshareddata
    │   │   └── IDEWorkspaceChecks.plist
    │   └── xcuserdata
    │       └── pan.xcuserdatad
    │           └── UserInterfaceState.xcuserstate
    └── xcuserdata
        └── pan.xcuserdatad
            ├── xcdebugger
            │   └── Breakpoints_v2.xcbkptlist
            └── xcschemes
                └── xcschememanagement.plist

可以看到项目下有两个文夹，分别是源代码文件HelloWorld，以及工程文件HelloWorld.xcodeproj。 作为示例，我们可以修改ViewController.m文件，如下：

#import "ViewController.h"

@interface ViewController ()

@end

@implementation ViewController

- (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.
    
    // 创建控件
    UILabel* label = [[UILabel alloc]init];
    label.text = @"Hello World";
    // 自适应大小
    [label sizeToFit];
    // 居中
    label.center = self.view.center;
    // 添加控件
    [self.view addSubview :label];
}


@end

这样，一个Hello World小程序就完成了，左上角运行按钮，即可编译并在模拟器中运行，如下：

imgSim.jpg

在源代码框下方Products区域也能看到编译出的HelloWorld.app。 是不是很简单？好我们今天的文章就这样结束了，… 才怪！

命令行编译

为了更好地了解编译过程，我们可以脱离Xcode IDE，在命令行编译该项目：

首先，在项目目录中查看Schemes：

$ xcodebuild -list -project HelloWorld.xcodeproj
Information about project "HelloWorld":
    Targets:
        HelloWorld

    Build Configurations:
        Debug
        Release

    If no build configuration is specified and -scheme is not passed then "Release" is used.

    Schemes:
        HelloWorld

然后，选择一个scheme进行编译，这里是HelloWorld：

$ xcodebuild -scheme HelloWorld build
note: Using new build system
note: Planning build
note: Using build description from disk
Build system information
error: Signing for "HelloWorld" requires a development team. Select a development team in the project editor. (in target 'HelloWorld')

** BUILD FAILED **

凹，编译失败了，签名出错，因为万恶的资本主义坏苹果要求必须要每年99$或者299$去购买 Apple Developer Program 会员资格才能对应用进行合法签名，从而发布并运行我们创建的app。

但是这里写的这个简单APP只需要在我自己的手机上运行，所以并不需要这一步，禁用签名进行编译即可：

$ xcodebuild -scheme HelloWorld build CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO
Build settings from command line:
    CODE_SIGN_IDENTITY =
    CODE_SIGNING_REQUIRED = NO

note: Using new build system
note: Planning build
note: Constructing build description
Build system information
warning: HelloWorld isn't code signed but requires entitlements. It is not possible to add entitlements to a binary without signing it. (in target 'HelloWorld')
...
Validate /Users/pan/Library/Developer/Xcode/DerivedData/HelloWorld-dnyjqrgxcjjobvfzytzhtzpmjlmx/Build/Products/Debug-iphoneos/HelloWorld.app (in target: HelloWorld)
...
Touch /Users/pan/Library/Developer/Xcode/DerivedData/HelloWorld-dnyjqrgxcjjobvfzytzhtzpmjlmx/Build/Products/Debug-iphoneos/HelloWorld.app (in target: HelloWorld)
...
** BUILD SUCCEEDED **

编译成功了！中间省略了很多输出信息，这里就不贴了。值得一提的是，生成的app并不是在当前项目目录下， 而是在$HOME/Library/Developer/Xcode/DerivedData/$PROJECT-xxxx/{...}/HelloWorld.app中， xxxx看起来是一段随机数。HelloWorld.app就是一个传统的苹果应用，其目录结构如下：

$ tree HelloWorld.app
HelloWorld.app
├── Base.lproj
│   ├── LaunchScreen.storyboardc
│   │   ├── 01J-lp-oVM-view-Ze5-6b-2t3.nib
│   │   ├── Info.plist
│   │   └── UIViewController-01J-lp-oVM.nib
│   └── Main.storyboardc
│       ├── BYZ-38-t0r-view-8bC-Xf-vdC.nib
│       ├── Info.plist
│       └── UIViewController-BYZ-38-t0r.nib
├── HelloWorld
├── Info.plist
└── PkgInfo

其中HelloWorld就是ARM64的Mach-O文件：

$ file HelloWorld.app/HelloWorld
HelloWorld.app/HelloWorld: Mach-O 64-bit executable arm64

iOS模拟器除了可以在Xcode启动，也可以通过命令行进行管理，如：

xcrun simctl help

查看具体帮助：

$ xcrun simctl help install
Install an app on a device.
Usage: simctl install <device> <path>

例如，我们要想在模拟器中启动上节编译好的HelloWorld.app，可以用以下命令：

# 查看当前设备列表，选择一个设备UDID
xcrun simctl list devices
# 打开并启动设备
open -a Simulator --args -CurrentDeviceUDID $UDID
# 在启动的设备中安装我们的应用，注意需要app支持x86架构
xcrun simctl install booted /path/to/HelloWorld.app

关于simctl的更多使用示例可以参考这篇文章。

签名与ipa

上节说到我们可以不签名来编译APP，但对于真机而言，要想运行应用，签名是必须的。 在Xcode7以后，开发者可以只用自己的Apple ID来在自己的设备上运行iOS应用，设置如下：

imgSign.jpg

这样就可以通过USB在物理机上运行iOS应用了，不过要注意的是第一次启动时会提示不可信的开发者， 需要到设置-通用中进行信任。

iOS应用与Android应用类似的一点是，最后安装到系统中的都是一个zip压缩包，对于Android而言后缀是apk， 而对于iOS而言则是ipa（iPhone Application Archive）。通常ipa会通过苹果加密（使用FairPlay DRM技术）。 所以一般我们想从手机上已经安装的应用还原出ipa需要先解密，也通常称为砸壳。

常见的解密方法有如下几种：

当然这些都是需要越狱的，在非越狱的机器上可以通过iMazing提取，热门应用可以直接在第三方应用商店下载， 比如AppCake。

对于有源码的应用，我们可以使用Xcode进行打包，打包流程可以参考stackoverflow中的一个回答。 不过这需要有开发者账号。由于我们是自己使用，因此要找一种无需开发者账号的方法。

无需开发者账号的打包方式有很多，比如：

这里使用命令行方式进行打包（archive&export）：

# archive
xcodebuild archive -project HelloWorld/HelloWorld.xcodeproj -scheme HelloWorld -configuration Debug  -archivePath ./build/HelloWorld

# export
xcodebuild -exportArchive -archivePath ./build/HelloWorld.xcarchive -exportOptionsPlist exportOptions.plist -exportPath ./build

这样就在./build目录下生成HelloWorld.ipa包了。其中exportOptions.plist如下：

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>method</key>
    <string>development</string>
</dict>
</plist>

详细exportOptions的key/value值可以通过xcodebuild -help查看。

ipa安装

无需AppStore的ipa的安装方法有下面几种（欢迎补充）：

  • 使用Apple Configurator 2 工具（只支持MacOS）
  • 使用Xcode安装
  • 使用OTA部署方式安装
  • 其他

Apple Configurator 2是苹果公司提供的一个部署和配置工具，可以直接从AppStore下载。 USB连接苹果手机后打开工具，图形界面操作，依次选择：

Add -> Apps -> Choose from my Mac

然后点击生成的ipa文件即可。不是很推荐这个工具，如果一定要用图形界面，还不如用下面的Xcode。

同样是图形界面操作，USB连接手机后依次选择：

Window -> Devices and Simulators -> Devices

选择自己的手机后，点击+添加或者直接把ipa文件拖拽进来即可。

OTA部署支持使用HTTPS的方式部署和分发你的ipa包，一个示例OTA链接地址如下：

itms-services://?action=download-manifest&url=https://example.com/ota.plist

itms-services是苹果上的自定义协议，会根据action下载并处理目标plist文件， ota.plist内容如下：

<plist version="1.0">
  <dict>
    <key>items</key>
    <array>
      <dict>
        <key>assets</key>
        <array>
          <dict>
            <key>kind</key>
            <string>software-package</string>
            <key>url</key>
            <string>
              https://example.com/app.ipa
            </string>
          </dict>
        </array>
        <key>metadata</key>
        <dict>
          <key>bundle-identifier</key>
          <string>com.evilpan.helloworld</string>
          <key>bundle-version</key>
          <string>1</string>
          <key>kind</key>
          <string>software</string>
          <key>title</key>
          <string>一个有趣的APP</string>
        </dict>
      </dict>
    </array>
  </dict>
</plist>

解析后会从https://example.com/app.ipa下载应用，用户点击确定即可安装。 这里注意不论是ota.plist还是app.ipa的地址都是强制要求为HTTPS的， 因此若想以这种形式安装，还必须要去注册一个合法的SSL证书，也可以用免费的。

由于AppStore审核很严格，很多私人用的或者不合规的iOS软件都是通过OTA部署的形式分发的， 并且在会在安装说明中指引用户去设置->通用->描述文件与设备管理中手动点击信任该个人/企业开发者。

除了上述方式，还有一些开源脚本可以帮助我们安装部署自己的应用，如ios-deploy， 只要连接USB输入以下命令即可安装：

$ ios-deploy -b HelloWorld.ipa
[....] Waiting for iOS device to be connected
------ Install phase ------
...
[ 65%] InstallingEmbeddedProfile
[ 70%] VerifyingApplication
[ 75%] CreatingContainer
[ 80%] InstallingApplication
[ 85%] PostflightingApplication
[ 90%] SandboxingApplication
[ 95%] GeneratingApplicationMap
[100%] Installed package HelloWorld.ipa

有点类似于Android的adb install，相当方便。个人建议直接使用源码编译而不是npm安装。

后记

本文从开发者的角度，介绍了iOS应用创建、编译、打包、测试、部署等方面， 从零开始构建并运行我们的第一个iOS程序。 既介绍了模拟器的安装测试方式， 也介绍了物理机上的打包和部署过程。其中很多地方尽可能的使用命令行去运行， 这有利于后续自动化的操作，也有利于我们理解各个选项所使用到的参数作用。

为了降低工作量，我们特地在没有越狱以及没有开发者账号的情况下完成上述操作。 下一篇，我们将尝试从攻击者的角度，实际“破解”一个iOS应用，Stay Tuned！

参考链接

]]> Objective-C笔记 https://evilpan.com/2019/04/05/objc-basics/ Fri, 05 Apr 2019 22:40:00 +0800 evilpan https://evilpan.com/2019/04/05/objc-basics/ 为什么突然要搞ObjectiveC？因为清明比较闲，两三天正好用来学习下iOS的逆向分析。 逆向的第一步当然是先从正向了解，否则给你源代码都看不懂，反编译出来的就更别提了。 因此本篇文章作为简单学习ObjC的记录，不会涉及太深入的语法特性，简而言之就是——够用就行。

什么是Objective-C

Objective-C，简称OC，是一种通用、高级、面向对象的编程语言。它扩展了标准的ANSI C编程语言， 将Smalltalk式的消息传递机制加入到ANSI C中。当前主要支持的编译器有GCC和Clang（采用LLVM作为后端）。 Objective-C的商标权属于苹果公司，苹果公司也是这个编程语言的主要开发者。 苹果在开发NeXTSTEP操作系统时使用了Objective-C，之后被OS X和iOS继承下来。 现在Objective-C与Swift是OS X和iOS操作系统、及与其相关的API、Cocoa和Cocoa Touch的主要编程语言。

Objective-C是C语言的严格超集。这意味着任何C语言程序不经修改就可以直接通过Objective-C编译器， 在Objective-C中使用C语言代码也是完全合法的。Objective-C被描述为盖在C语言上的薄薄一层， 因为Objective-C的原意就是在C语言主体上加入面向对象的特性。OC项目中常用的拓展名如下：

扩展名 内容类型
.h 头文件。头文件包含类，类型，函数和常数的声明。
.m 源代码文件。这是典型的源代码文件扩展名，可以包含 Objective-C 和 C 代码。
.mm 源代码文件。带有这种扩展名的源代码文件，除了可以包含Objective-C和C代码以外还可以包含C++代码。仅在你的Objective-C代码中确实需要使用C++类或者特性的时候才用这种扩展名。

Hello, World!

学习任何一门语言之前，基本都需要做的就是编写并运行一个HelloWorld程序，对于OC而言则是如下：

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[])
{
    @autoreleasepool {
        NSLog (@"Hello, World!");
    }
    return 0;
}

使用clang进行编译：

clang -framework Foundation hello.m -o hello

运行：

$ ./hello
2019-04-05 09:33:22.579 hello[75742:3312942] Hello, World!

So easy！我们学习Objective-C时记住要重点关注概念而不是具体的语言细节，避免陷入学而无用的境地。

关键概念

Objective-C最大的特色是承自Smalltalk的消息传递模型（message passing）， 此机制与今日C++式之主流风格差异甚大。 Objective-C里，与其说对象互相调用方法， 不如说对象之间互相传递消息更为精确。此二种风格的主要差异在于调用方法/消息传递这个动作。 C++里类别与方法的关系严格清楚，一个方法必定属于一个类别，而且在编译时（compile time） 就已经紧密绑定，不可能调用一个不存在类别里的方法。但在Objective-C，类别与消息的关系比较松散， 调用方法视为对对象发送消息，所有方法都被视为对消息的回应。所有消息处理直到运行时（runtime） 才会动态决定，并交由类别自行决定如何处理收到的消息。也就是说，一个类别不保证一定会回应收到的消息， 如果类别收到了一个无法处理的消息，程序只会抛出异常，不会出错或崩溃。

C++里，送一个消息给对象（或者说调用一个方法）的语法如下：

obj.method(argument);

Objective-C则写成：

[obj method: argument];

此二种风格各有优劣。C++强制要求所有的方法都必须有对应的动作，且编译期绑定使得函数调用非常快速。 缺点是仅能借由virtual关键字提供有限的动态绑定能力。Objective-C天生即具备鸭子类型之动态绑定能力， 因为运行期才处理消息，允许发送未知消息给对象。可以送消息给整个对象集合而不需要一一检查每个对象的类型， 也具备消息转送机制。同时空对象nil接受消息后默认为不做事，所以送消息给nil也不用担心程序崩溃。

举例来说，定义下面的程序：

@interface MyClass: NSObject
// instance method
- (int) add: (int) num1 secondNumber:(int) num2;
// static method
+ (int) mul: (int) num1 secondNumber:(int) num2;
@end

@implementation MyClass
- (int) add: (int) num1 secondNumber:(int) num2 {
    return num1 + num2;
}
+ (int) mul: (int) num1 secondNumber:(int) num2 {
    return num1 * num2;
}
@end

其中add方法是实例函数，mul是类函数，调用过程如下：

int main() {

    int a = 3, b = 4;
    MyClass *myClass = [[MyClass alloc]init];
    int c = [myClass add:a secondNumber:b];
    int d = [MyClass mul:a secondNumber:b];
}

编译后在调试器中查看汇编可以看到，add方法的汇编是：

    0x100000ea2: mov    rsi, qword ptr [rbp - 0x18]
    0x100000ea6: mov    edx, dword ptr [rbp - 0x8]
    0x100000ea9: mov    ecx, dword ptr [rbp - 0xc]
    0x100000eac: mov    rdi, qword ptr [rip + 0x122d] ; "add:secondNumber:"
    0x100000eb3: mov    qword ptr [rbp - 0x28], rdi
    0x100000eb7: mov    rdi, rsi
    0x100000eba: mov    rsi, qword ptr [rbp - 0x28]
    0x100000ebe: call   qword ptr [rip + 0x13c]   ; (void *)0x00007fff6344e000: objc_msgSend

其实就是转换为：

objc_msgSend(myClass, "add:secondNumber:", 3, 4)

所有的Objective-C方法调用都通过objc_msgSend进行调用，且实例和方法名称分别为前两个参数。 这也是为什么OC方法调用称之为消息传递的原因。

作为C语言的超集，Objective-C 支持 C 语言字符串方面的约定。也就是说，单个字符被单引号包括， 字符串被双引号包括。然而，大多数Objective-C通常不使用C语言风格的字符串。 反之，大多数框架把字符串传递给NSString对象。NSString类提供了字符串的类包装， 包含了所有你期望的优点，包括对保存任意长度字符串的内建内存管理机制，支持Unicode，printf风格的格式化工具， 等等。因为这种字符串使用的非常频繁，Objective-C提供了一个助记符@可以方便地从常量值创建NSString对象。 如下面的例子所示：

// 从一个C语言字符串创建Objective-C字符串
NSString*  fromCString = [NSString stringWithCString:"A C string" 
encoding:NSASCIIStringEncoding];
// 使用助记符@
NSString* name = @"PANN";
NSString* line = [NSString stringWithFormat:@"Hello, %s\n", @"String"];

类是面向对象语言中最重要的一个概念，Objective-C同样支持类。下图是一个名为MyClass的类声明介绍： class.png

遵循C语言的规范，类声明一般定义在.h头文件中。类声明以关键字@interface作为开始，@end作为结束。 其中类方法前的+号表示类方法，-号表示实例方法。一个对应的C++类定义如下：

public MyClass : NSObject {
  protected:
  int count;
  id data;
  NSString *name;
  public:
  id intWithString(NSString *aName);
  static MyClass *createMyClassWithString(NSString *aName);
};

遵循C语言的规范，类实现一般定义在对应的.m文件中。类实现包含了公开方法的实现， 以及定义私有（private） 变量及方法。 以关键字@implementation作为区块起头，@end结尾。 上述类的一个实现如下：

@implementation MyClass {
  NSString *secret;
  -(id) initWithString: (NSString*)aName {
    self.name = aName;
    return 0;
  }
  +(MyClass)createMyClassWithString:(NSString*)aName {
    MyClass * my = [[MyClass alloc] init];
    my.name = aName;
    return my;
  }
}

头文件（类声明）中定义的属性默认为protected，方法为public。而类实现中定义的属性为private。 当然也可以使用@public、@private等助记符来覆盖默认行为。

实例化即创建对象。Objective-C创建对象需通过alloc以及init两个消息。alloc的作用是分配内存， init则是初始化对象。 init与alloc都是定义在NSObject里的方法，父对象收到这两个信息并做出正确回应后， 新对象才创建完毕。如上述类中：

MyClass * my = [[MyClass alloc] init];

在Objective-C 2.0里，若创建对象不需要参数，则可直接使用new：

MyClass * my = [MyClass new];

仅仅是语法上的精简，效果完全相同。

若要自己定义初始化的过程，可以重写init方法，来添加额外的工作。（用途类似C++ 的构造函数constructor）， 如下：

- (id) init {
    if ( self=[super init] ) {   // 必须调用父类的init
        // do something here ...
    }
    return self;
}

在上节介绍类的时候已经见过了一些方法的定义和使用，第一次接触Objective-C的人肯定会觉得很奇怪（比如我就觉得这语法比Golang还奇葩）， 但是只要接收了这种设定，还是可以慢慢习惯的。

下图为Objective-C内置数组类型的insertObject方法声明：

method.png

方法实际的名字(insertObject:atIndex:)是所有方法标识关键的级联，包含了冒号。冒号表明了参数的出现。 如果方法没有参数，你可以省略第一个(也是唯一的)方法标识关键字后面的冒号。本例中，这个方法有两个参数。 该函数转换成类似的C++表示如下：

void insertObject:atIndex:(id anObject, NSUInteger index);

调用一个方法实际上就是传递消息到对应的对象。这里消息就是方法标识符以及传递给方法的参数信息。 发送给对象的所有消息都会动态分发，这样有利于实现Objective-C类的多态行为。 也就是说，如果子类定义了跟父类的具有相同标识符的方法，那么子类首先收到消息， 然后可以有选择的把消息转发（也可以不转发）给他的父类。

消息被中括号( [ 和 ] )包括。括号中接收消息的对象在左边，消息及其参数在右边。 例如，给myArray变量传递消息insertObject:atIndex:消息，可以使用如下的语法：

[myArray insertObject:anObj atIndex:0];

消息允许嵌套。也就是说，假如你有一个myAppObject对象，该对象有getArray方法获取数组， 有getObjectToInsert方法获取元素，那么嵌套的消息可以写成：

[[myAppObject getArray] insertObject:[myAppObject getObjectToInsert] atIndex:0];

属性没什么好说的，和C++的类属性类似。不过在Objective-C 2.0引入了新的语法以声明变量为属性， 并包含一可选定义以配置访问方法的生成。属性总是为公共的，其目的为提供外部类访问（也可能为只读） 类的内部变量的方法。属性可以被声明为“readonly”，即只读的，也可以提供储存方法包括“assign”， “copy”或“retain”（简单的赋值、复制或增加1引用计数）。默认的属性是原子的， 即在访问时会加锁以避免多线程同时访问同一对象，也可以将属性声明为“nonatomic”（非原子的）， 避免产生锁。

定义属性的例子如下：

@interface Person : NSObject {
    @public
        NSString *name;
    @private
        int age;
}

@property(copy) NSString *name;
@property(readonly) int age;

-(id)initWithAge:(int)age;
@end

属性的访问方法由@synthesize关键字来实现，它由属性的声明自动的产生一对访问方法。 另外，也可以选择使用@dynamic关键字表明访问方法为手动提供。

@implementation Person
@synthesize name;
@dynamic age;

-(id)initWithAge:(int)initAge
{
    age = initAge; // 注意：直接赋给成员变量，而非属性
    return self;
}

-(int)age
{
    return 18; // 注意：并非返回真正的年龄
}
@end

属性可以利用传统的消息表达式、点表达式或"valueForKey:"/“setValue:forKey:“方法对来访问。如下：

Person *aPerson = [[Person alloc] initWithAge: 53];
// 修改属性
aPerson.name = @"Steve";
[aPerson setName: @"Steve"];
// 读取属性
NSString *tmp;
tmp = [aPerson name]; // 消息表达式
tmp = aPerson.name;	  // 点表达式
tmp = aPerson->name;  // 直接访问成员变量
tmp = [aPerson valueForKey:@"name"]; // property访问

协议是一组没有实现的方法列表，任何的类均可采纳协议并具体实现这组方法。简而言之就是接口， 可以类比Java的interface，或者C++的纯虚函数，表述一种is-a的概念。

协议以关键字@protocol作为区块起始，@end结束，中间为方法列表。如下：

@protocol Mutex
- (void)lock;
- (void)unlock;
@end

若要声明实现该协议，可以使用尖括号<>，如下：

@interface SomeClass : SomeSuperClass <Mutex>
@end

一旦SomeClass表明他采纳了Mutex协议，SomeClass就有义务实现Mutex协议中的两个方法：

@implementation SomeClass
- (void)lock {
  // 实现lock方法
}
- (void)unlock {
  // 实现unlock方法
}
@end

类似于Smalltalk，Objective-C具备动态类型：即消息可以发送给任何对象实体，无论该对象实体的公开接口中有没有对应的方法。 虽然Objective-C具备动态类型的能力， 但编译期的静态类型检查依旧可以应用到变量上。 以下三种声明在运行时效力是完全相同的， 但是三种声明提供了一个比一个更明显的类型信息， 附加的类型信息让编译器在编译时可以检查变量类型，并对类型不符的变量提出警告。

下面三个方法，差异仅在于参数的形态：

- setMyValue1:(id) foo;
- setMyValue2:(id <aProtocol>) foo;
- setMyValue3:(NSNumber*) foo;

Objective-C中的id类型类似于void指针，但是被严格限制只能使用在对象上。

一个对象收到消息之后，他有三种处理消息的可能手段，第一是回应该消息并运行方法，若无法回应， 则可以转发消息给其他对象，若以上两者均无，就要处理无法回应而抛出的例外。只要进行三者之其一， 该消息就算完成任务而被丢弃。若对"nil”（空对象指针）发送消息，该消息通常会被忽略， 只不过对于某些编译器选项可能会抛出异常。

Objective-C运行时在Object中定义了一对方法：

转发方法：

- (retval_t) forward:(SEL) sel :(arglist_t) args; // with GCC
- (id) forward:(SEL) sel :(marg_list) args; // with NeXT/Apple systems

响应方法：

- (retval_t) performv:(SEL) sel :(arglist_t) args;  // with GCC
- (id) performv:(SEL) sel :(marg_list) args; // with NeXT/Apple systems

GCC和NeXT/Apple编译器的区别是返回值和参数类型不同。

希望实现转发的对象只需用新的方法覆盖以上方法来定义其转发行为而无需重写响应方法performv::， 因为后者只是单纯的对响应对象发送消息并传递参数。其中，SEL类型是Objective-C中消息的类型。

Objective-C借用并扩展了Smalltalk实现中的"分类"概念，用以帮助达到分解代码的目的。

一个分类可以将方法的实现分解进一系列分离的文件。程序员可以将一组相关的方法放进一个分类， 使程序更具可读性。举例来讲，可以在字符串类中增加一个名为"拼写检查"的分类， 并将拼写检查的相关代码放进这个分类中。

分类中的方法是在运行时被加入类中的，这一特性允许程序员向现存的类中增加方法， 而无需持有原有的代码， 或是重新编译原有的类。 例如若系统提供的字符串类的实现中不包含拼写检查的功能，可以增加这样的功能而无需更改原有的字符串类的代码。

在运行时，分类中的方法与类原有的方法并无区别，其代码可以访问包括私有类成员变量在内的所有成员变量。 若分类声明了与类中原有方法同名的函数，则分类中的方法会被调用。因此分类不仅可以增加类的方法， 也可以代替原有的方法。这个特性可以用于修正原有代码中的错误，更可以从根本上改变程序中原有类的行为。 若两个分类中的方法同名，则被调用的方法是不可预测的。

分类的声明如下：

@interface ClassName (CategoryName)

@end

下面是一个具体的例子，通过MyAdditions分类，动态的给NSString类中添加getCopyRightString方法：

#import <Foundation/Foundation.h>

@interface NSString(MyAdditions)
+(NSString *)getCopyRightString;
@end

@implementation NSString(MyAdditions)

+(NSString *)getCopyRightString {
   return @"Copyright evilpan.com 2019";
}

@end

int main(int argc, const char * argv[]) {
   NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
   NSString *copyrightString = [NSString getCopyRightString];
   NSLog(@"Accessing Category: %@", copyrightString);
   
   [pool drain];
   return 0;
}

小结

现在，我们已经了解了Objective-C语言的基本语法和关键概念，可以开始自己编写简单的程序了。 一门语言只是一个工具，常用常新，如果不使用，学得再深也很容易遗忘。 当然，本文介绍的Objective-C特性只是一小部分，但我们仍然可以先用起来， 等遇到具体语法或者API时候再查阅文档（如spec、tutorialspoint等）即可。 使用得越多，需要查阅文档但频率也会越少，学习没有捷径可言。

]]>