58同城iOS客户端安全加固原理与实践

iOS 系统向来以安全著称，苹果为保证系统安全，采用了 App 签名、沙盒机制、地址随机化诸多安全防护措施。iOS 系统虽然安全，但并非坚不可破。iOS 系统的安全，更是让许多开发者忽略了自身 App 的安全。

在越狱设备中可以访问 App 中的沙盒数据、Keychain 存储的数据；使用 class-dump 工具可以导出 Objective-C 中的头文件；借助 IDA、Hooper 等反汇编、反编译工具可以静态分析代码逻辑；运用 Cycript、debugserver+lldb 可以动态调试程序；另外攻击者还可以编写 tweak 注入到 App 中，篡改应用逻辑，二次打包实现 App 多开。

目前市场上 BAT、TMD、网易等一线大厂 App 做了一定的安全防护，然而大多数 App 都没有基本的安全防护。App 如果不进行安全加固，在越狱环境下犹如裸奔，严重者被黑产利用，给公司造成经济损失。

本文主要介绍代码混淆、反调试防护、签名信息校验、异常数据检测和处理等 iOS 中常见的安全防护技术，以及在 58 同城 iOS 客户端的实践应用。

1. 核心代码混淆

1.1 代码混淆概述

在 iOS 逆向过程中，攻击者通常基于类名、函数名等符号，作为突破口，分析破解应用。使用 class-dump 工具，可以还原 Objective-C 中的头文件信息，包括类名、属性、方法、协议。在 Hopper 、IDA 等反汇编、反编译工具中，搜索类名、方法名即可快速定位到对应的函数实现，静态分析代码逻辑。因此将 App 敏感业务中的类、方法进行混淆，替换为晦涩的符号，可以增加攻击者的逆向难度。

虽然代码混淆是一种简单有效的安全防护手段，然而笔者调研了微信、支付宝、美团、抖音等 App，发现符号混淆并未被广泛使用。在项目中，我们基本上都会使用到 Objective -C 的 Runtime 特性，基于字符串，动态创建类，调用方法。符号混淆存在着潜在的风险，要考虑各种复杂情况，稍有不慎就会导致程序异常，并且难于跟踪调试。另外大量使用混淆，也不被苹果所允许，有审核被拒的风险。尽管在项目中大规模使用代码混淆不甚现实，但只针对核心业务代码混淆，未尝不是一种行之有效的方法。

在 Objective-C 中核心函数及其参数、返回值等使用 block 实现， 敏感业务代码使用 C 或 C++ 实现，也可以增大逆向分析难度。

1.2  代码混淆实践

对方法名及返回值混淆后，使用 class-dump 导出头文件，查看混淆后的效果如下：

代码混淆效果

2. 反调试防护

2.1 反调试防护原理

与静态分析对应的是动态分析，也是攻击者常用的破解手段。在越狱设备中，使用 debugserver、lldb 工具，可以动态调试分析 App 运行逻辑，设置断点，查看函数调用堆栈，打印输出变量值。据笔者研究，支付宝、美团、抖音等 App 都实现了反调试防护，为防止攻击者动态调试分析 App，在程序中增加反调制机制很有必要。

反调试从逻辑上可以划分为两种，一种是阻止调试器挂载，如 ptrace；另一种是获取进程信息，检测当前进程是否被调试，例如 sysctl。

a) 使用 ptrace 阻止调试器挂载

ptrace 是一个系统调用，主要用来跟踪调试应用程序，其函数原型如下：

int ptrace(int request, pid_t pid, caddr_t addr, int data);

其中第一个参数 request 指定了要执行的操作，当该参数设定为 PT_DENY_ATTACH 值时，应用程序会通知系统自己不允许被跟踪调试。尝试跟踪调试应用进程，都会被拒绝，并且应用程序会收到一个段错误。

  一段简单的 iOS ptrace 反调试代码示例如下：

#import <dlfcn.h>#import <sys/types.h>
typedef int (*ptrace_ptr_t)(int _request, pid_t _pid, caddr_t _addr, int _data);#if !defined(PT_DENY_ATTACH)#define PT_DENY_ATTACH 31#endif
static __attribute__((always_inline)) void antidebug_ptrace() {    void* handle = dlopen(0, RTLD_GLOBAL | RTLD_NOW);    ptrace_ptr_t ptrace_ptr = dlsym(handle, "ptrace");    ptrace_ptr(PT_DENY_ATTACH, 0, 0, 0);    dlclose(handle);}

注：上述代码参考于：https://www.theiphonewiki.com/wiki/Bugging_Debuggers

另外，ptrace 还可以通过系统调用实现，ptrace 对应的系统调用编号为 26，PT_DENY_ATTACH 的值为 31，示例代码如下：

static __attribute__((always_inline)) void antidebug_syscall_ptrace() {    syscall(26, 31, 0, 0);}

b)     通过 sysctl 检测进程信息

与 ptrace 通过阻止调试器挂载到进程不同，sysctl 通过获取进程信息，检测当前进程是否被调试。

sysctl 函数定义如下：

int sysctl(int *name, u_int namelen, void *oldp, size_t*oldlenp, void *newp, size_t newlen);

其中，第一个参数 name 是一个整型数组，描述了要请求信息；第二个参数 namelen 为指针数组 name 的长度；第三个参数用来存储输出的数据，当函数返回时，请求的信息会赋值到该变量；第四个参数为相应的输出数据大小。

输出数据类型是一个 kinfo_proc 结构体，该结构体包含另外一个 extern_proc 类型的结构体（kp_proc），kp_proc 中的字段 p_flag 标记着当前进程是否被调试。

sysctl 反调试代码示例如下：

#include <stdio.h>  #include <sys/types.h>  #include <unistd.h>  #include <sys/sysctl.h>  #include <stdlib.h>   static __attribute__((always_inline)) static int antidebug_sysctl(void){      int name[4];      struct kinfo_proc info;      size_t info_size = sizeof(info);          info.kp_proc.p_flag = 0;          name[0] = CTL_KERN;      name[1] = KERN_PROC;      name[2] = KERN_PROC_PID;      name[3] = getpid();          if (sysctl(name, 4, &info, &info_size, NULL, 0) == -1) {          exit(-1);      }      return ((info.kp_proc.p_flag & P_TRACED) != 0);  }

注：上述代码参考于：https://www.coredump.gr/articles/ios-anti-debugging-protections-part-2/

c) 基于汇编实现 ptrace 系统调用

直接使用 ptrace 和 sysctl 函数符号的反调试，容易被攻击者反反调试，绕过防护。使用 fishhook hook 上述 C 函数，修改代码逻辑，会导致防护失效。与显示使用函数符号实现反调试相比，通过汇编实现，安全系数更高，不会被轻易 hook 绕过。

使用汇编实现 ptrace 系统调用，代码如下：

static __attribute__((always_inline)) void antidebug_asm_ptrace() {#ifdef __arm64__    asm volatile (                "mov x0, #26\n"                "mov x1, #31\n"                "mov x2, #0\n"                "mov x3, #0\n"                "mov x16, #0\n"                "svc #0x80\n"                );#endif}

代码参考于：https://github.com/vtky/ios-antidebugging

上述代码等价于 syscall(26, 31, 0, 0)。在 ARM 汇编中，内核入口通过 svc 指令完成，使用 svc 进行系统中断调用需要明确 3 个点：中断号、系统调用号，以及参数。

2.2  反调试防护实践

在 App 中实现 ptrace 反调试后，在越狱环境下，使用 debugserver 调试加固后的 App，会阻止调试器挂载，产生段错误，效果如下：

ptrace 反调试

3.  签名信息校验

攻击者在逆向破解应用后，通常会二次打包，分发应用。校验 App 签名信息是否完整，是一种必要的安全防护手段。常见的签名信息校验有以下几种方式:

a) 判断 App Bundle ID 是否被篡改

通过系统 API 读取 App Bundle ID，判断 Bundle ID 是否被篡改，是最容易想到的方法。遗憾的是直接使用系统 API 容易被攻击者 hook 绕过检测；另外使用通配符 App ID 重签名，可以做到 Bundle ID 不变，因此该方法不完全有效。

b) 读取 App 主目录下是否存在 embedded.mobileprovision 文件以及该文件中的签名信息

App 重签名后，主目录下通常会存在 embedded.mobileprovision 文件，解析 mobileprovision 文件，读取签名信息，即使 App Bundle ID 不变，也可以通过校验其他信息，判断 App 是否被篡改。但凡事总有个例外，一些工具重签名 App 后，主目录下并不存在 embedded.mobileprovision 文件，因此该方法也不够完善。

c) 从 Mach-O 可执行文件中读取 App 签名信息，校验签名信息完整性

相比与上述两种方法，从 Mach-O 可执行文件中读取签名信息，是一种相对安全，不容易被破解的方法。从 Mach-O 文件中读取签名信息，主要步骤如下：

LC_CODE_SIGNATURE 类型的 Load Command

iii. 代码签名指令集中存储着签名数据的偏移量和数据大小，据此可以计算并定位代码签名数据段在文件中的位置。

代码签名信息

iv. 签名数据段起始部分为 CS_SuperBlob结构体，其中 magic 字段指明了Blob 数据类型，length 字段指明了 SuperBlob 大小，count字段指明了接下来会有多少个子条目。据此解析签名数据，即可获取应用标识符。

签名信息解析结果示例

简单使用上述一种方法检测 App 签名信息很容易被攻击者绕过破解，签名信息校验可以在程序的不同地方，组合使用上述校验方法，更大程序度上保证签名信息校验有效性。单纯使用签名信息实现 App 多开检测也不能保证完全有效，应尽可能使用多种检测手段，如SignerIdentity检测，使检测更加精确有效。

4.  异常数据检测及处理

除了代码混淆、反调试防护、签名信息校验等防护手段外，还可以通过检测 App 异常数据，上报至服务器端，作为业务风控参考指标。当 App 遭受注入、调试、钩子、篡改等攻击行为时，对用户发出警告，严重者封号，甚至直接终止 App 运行。

4.1  越狱设备检测

通常 App 逆向破解都是从越狱设备着手，因此检测设备是否越狱十分必要。越狱检测可以从以下方面实现：

a) 检测是否存在越狱相关的文件、路径，如：

/Library/MobileSubstrate/MobileSubstrate.dylib/Applications/Cydia.app、/usr/bin/cycript等

MobileSubstrate.dylib越狱文件

b) 私有文件写入权限校验

越狱手机拥有 root 权限，可以往 App 沙盒外的目录写入文件。例如尝试在 /private 目录写入文件，如果文件创建成功，则说明设备已越狱，示例代码如下：

NSError *error;NSString *stringToBeWritten = @"This is a test.";[stringToBeWritten writeToFile:@"/private/jailbreak.txt" atomically:YESencoding:NSUTF8StringEncoding error:&error];if(error==nil){//Device is jailbrokenreturn YES;} else {//Device is not jailbroken[[NSFileManager defaultManager] removeItemAtPath:@"/private/jailbreak.txt" error:nil];}

注：代码引自：https://mobile-security.gitbook.io/mobile-security-testing-guide/

c) 越狱设备通常会安装 cydia 等工具，可以尝试判断能否打开 cydia scheme URL，检测设备是否越狱

4.2  App 加密检测

在苹果官方渠道下载的 App 都是加密的，而开发者重签名，二次打包后的 App 都未加密。解析 Mach-O 可执行文件中 LC_ENCRYPTION_INFO 类型的 Load Command，判断 App 是否加密，检测 App 是否来源是否合法。

otool  查看Mach-O 文件是否加密

4.3  动态库注入检测

在越狱设备中，攻击者通常通过注入动态库，篡改应用逻辑。可以使用 getenv读取 DYLD_INSERT_LIBRARIES  环境变量是否有值，检测是否有注入动态库，如下图：

getenv  查看动态库注入

动态库注入检测还可以通过增加动态库白名单，使用 dyld_image_count 获取程序链接动态库数据个数，遍历数据读取映象名称（dyld_get_image_name），与白名单比对，检测是否有链接 MobileSubstrate.dylib、RevealServer等异常动态库。

4.4  异常处理

在检测到 App 异常行为后，可以上报至服务器端，结合业务应用场景，警告用户，禁用某些功能，甚至封号。

发现异常后，直接终止 App 运行，是一种简单粗暴有效的异常处理方式。终止 App 运行，可以通过抛出异常或调用 exit 函数实现。显示调用 exit 函数，容易被攻击者反向定位到程序退出位置，通过系统调用或内联汇编实现程序终止，是一种更高明的方式。

本文结合 iOS 逆向破解中常用的技术手段，阐述了代码混淆、反调试、签名信息校验、异常数据检测及处理等安全防护原理与实践。iOS 系统并非想象的那么安全，开发者必须提高自己的代码安全意识，不能仅依赖 iOS 系统的安全措施。使用上述防护加固方法，在一定程度上可以增强 App 的安全性，防止攻击者轻易破解应用。但没有绝对的安全，混淆、加密、反调试等等加固手段只是安全防护的一道道锁，用来增加攻击者的破解难度。

单纯依靠客户端的加固，要实现 App 的安全防护也远远不够，安全更要从整个系统来考虑，前、后端协同努力，才能更大程度上保证系统安全。App 的安全加固更非一朝一夕就能实现，是在攻击与防护长期对抗中，发现问题，分析问题，解决问题，持续升级完善的，攻防相长，此之谓也。 

参考文献

1. iOS 安全攻防：https://blog.csdn.net/yiyaaixuexi/article/category/1302847

2. 对 iOS App 进行安全加固：https://zhuanlan.zhihu.com/p/33109826

3. iOS App的加固保护原理：https://zhuanlan.zhihu.com/p/33109826

4. 浅谈关于iOS加固的几种方法：http://www.blogfshare.com/ios-protect.html

5. Mach-O文件格式：https://feicong.github.io/2017/01/13/macho/

6. iOS 多开检测，反多开检测，反反多开检测：http://iosre.com/t/ios/11611

7. 关于反调试&反反调试那些事：http://iosre.com/t/topic/8179

8. 反调试与绕过的奇淫技巧：http://bbs.iosre.com/t/topic/9351

9. iOS Anti-Debugging Protections #1：https://www.coredump.gr/articles/ios-anti-debugging-protections-part-1/

10. iOS Anti-Debugging Protections #2：https://www.coredump.gr/articles/ios-anti-debugging-protections-part-2/

11. Bugging Debuggers：https://www.theiphonewiki.com/wiki/Bugging_Debuggers

12. Mobile Security Testing Guide: https://mobile-security.gitbook.io/mobile-security-testing-guide/

作者简介

贾学文，58 同城用户价值增长部高级研发工程师，主要负责 App 安全加固及暗黑模式适配研发工作。