前言：本文适合像笔者一样，对逆向几乎零基础的同学阅读
一点小建议：环境这块快速略过，能正常使用就行，无需过分纠结。
环境
越狱
如何越狱
通过体验，目前iOS 14及以前使用爱思助手即可实现一键越狱。遇到的坑：
-
unc0ver越狱默认是7.0.7版本，在此版本上，非常容易出现报错。因此将改版改为5.3.1即可解决报错问题。
取包
如何直接导出设备上的ipa
打开SSH通道
<img referrerPolicy="no-referrer" referrerPolicy="no-referrer" src="https://tva1.sinaimg.cn/large/008i3skNly1gxleo662upj30og0dc0tc.jpg" alt="image-20211221134750265" style="zoom:50%;" />
根据爱思助手提示的IP、端口、账号、密码通过MAC cmd请求连接
# sudo ssh -p 2223 root@127.0.0.1
查看所有进程
首先打开目标APP，然后通过命令查看所有进程，此步骤主要是为了找到对应的APP的路径。
# ps -ef
导出ipa
找到路径后，对文件进行打包压缩。
# cd /var/containers/Bundle/Application/7E9BC1B6-8F35-4697-BFB2-D40056B8A35C
# tar -cvf /tmp/xxx.ipa ./
# scp /tmp/xxx.ipa a58@10.252.220.145:~/Desktop/
砸壳并导出ipa
如果我们从App Store下载的APP，直接导出后并没有脱壳，因此需要了解如何砸壳。
安装frida
-
Mac安装，需要安装Python3# pip3 install frida-toolsbrew-update报错Error: homebrew-core is a shallow clone.可尝试：# /bin/zsh -c "$(curl -fsSL https://gitee.com/cunkai/HomebrewCN/raw/master/Homebrew.sh)" -
iOS通过Cydia安装frida
使用frida
常见命令及说明，命令需要在Mac cmd运行：
-
frida-ls-devices：查看连接的iOS设备信息。 -
frida-ps -U：查看USB连接设备的所有进程。注意：这里可能会报错（Failed to enumerate processes: unable to connect (connection refused)），原因是
iOS的frida与Mac的frida版本不一致。此时需要更新或者重新安装两端中低版本的frida，iOS需要在Cydia上进行更新，如有必要重新添加源：http://build.frida.re。Cydia下载frida如果失败则重新尝试几次。 -
frida-ps -Ua:：查看USB连接设备的正在运行的APP。 -
frida-ps -Uai：查看USB连接设备的已安装的APP。 -
frida-ps -D <iOS UDID>：通过UDID查看设备的进程。 -
frida-trace -U -f <bundleId> -m "-[* *]"：用于方法追踪，支持正则表达式。
利用frida-ios-dump砸壳
目前frida砸壳是主流的砸壳方式之一。网上资料非常多， 但是非常容易出现各种各样的安装异常。其实没有那么复杂，从frida-ios-dump下载code，并在打开SSH通道后运行dump.py即可。各种安装方式本质就是运行脚本。保证脚本中的IP、端口、账号、密码正确就能一键砸壳。
# python3 dump.py 安居客
调试
MonkeyDev
install
详见：MonkeyDev 安装
可能存在的问题：
- 在安装新建项目后，Xcode可能无法正常打开，因此在安装前请做好备份。
- 创建的项目中，fishhook版本过老，因此需要更新下fishhook。
use
将导出的砸壳后的ipa 拖入指定位置即可。这里需要注意的是，如果项目编译链接后安装不成功，那么需要clean下工程重新安装。不建议使用Personal Team进行签名。启动成功后，即可各种hook操作，验证你的想法。
实战演练
问题描述
58APP根据地域动态调整桌面icon图标，但是在线上我们发现，存在16%的用户在更换图标时存在error。经过验证发现，如果在后台时触发更换图标的API则会触发error，那除此场景外，是否还存在其他场景导致报错呢？因此我们想通过逆向的方式，了解下系统报错的机制。其API如下：
[[UIApplication sharedApplication] setAlternateIconName:iconName completionHandler:^(NSError * _Nullable error) {
if (error) {
//失败埋点
return;
}
//成功埋点
}]
确认目标系统库
首先需要确认当前这个函数在哪个系统库，我们可以通过dladdr来准确地确认系统库。
<font color=red>首先需要将Main Thread Checker关闭 ！</font>
Dl_info info;
IMP imp = class_getMethodImplementation(UIApplication.class,@selector(setAlternateIconName:completionHandler:));
dladdr((void*)imp, &info);
基于上述方法我们很容易就可以确定函数在 UIKitCore中
imp = 0x000000022a65e070 (UIKitCore`-[UIApplication(UIAlternateApplicationIcons) setAlternateIconName:completionHandler:])
在Xcode控制台中通过image list可以获取到所有的动态库的路径。
[280] A1F463BF-CF9B-3796-BA9E-7C2B40617FAE 0x0000000229d80000 /Users/a58/Library/Developer/Xcode/iOS DeviceSupport/12.4.4 (16G140)/Symbols/System/Library/PrivateFrameworks/UIKitCore.framework/UIKitCore
静态分析
通过IDA分析我们可以看出如果函数
LSApplicationProxyForSettingCurrentApplicationIcon()
调用失败，那么会报3328异常，另外，如果APP状态非活跃状态则会报3072的错误，这一点与我们的测试能对应上。
image-20211228111843964
但是我们在测试时发现，如果要更换图标不存在，那么会报error code = 4这一点从源码上没有体现出来。因此需要继续查看核心方法
setAlternateIconName:withResult:
但是此时就会涉及到一个问题，v29寄存器记录的是谁？到哪里去查看setAlternateIconName:withResult:函数？从上文的伪代码可以看出v29寄存器的值来自于LSApplicationProxyForSettingCurrentApplicationIcon()，因此尝试查看LSApplicationProxyForSettingCurrentApplicationIcon()函数的伪代码。
aaa
但是从伪代码中找不到思路，因为0x1ba0afce0所记录的值到底是什么，从这里看不出来。因此换了思路，通过全局断点查看信息是个不错的方法。
(lldb) br s -S setAlternateIconName:withResult:
Breakpoint 2: where = CoreServices`-[LSApplicationProxy setAlternateIconName:withResult:], address = 0x0000000226787290
因此可以需要继续查看CoreServices的相关伪代码。
image-20211228152047854
继续查看-[LSApplicationProxy setAlternateIconName:withResult:] 可以发现，系统调用了2个函数，如果返回值不为0的话则进入流程，否则报错。但是函数名在工具中看不到，因此我们需要针对性地解决这个问题。
PS：由于感觉
hopper界面更好看些，所以工具换成了hopper，
image-20211228152414236
将Remove potentially dead code关闭后可以查看到报错的code码为0xd00，报错信息为"alternateIcons not allowed"
小技巧
初次尝试逆向分析，不知道为什么hopper和IDA都没能把对应的地址转成字符。因此这一步需要我们自己尝试进行解析。为了方便下文的介绍，我们先来定义几个名词：
-
file vm addr：这里是指静态文件上，记录和引用的地址，例如我们通过hopper或者IDA看到的地址都是文件上的静态地址。 -
runtime addr：运行期间的真实地址，例如我们用到的类和函数，我们在代码中动态获取到的真实地址。 -
slide：随机偏移，运行期间才能获取到。这是系统给我们每个镜像分配的随机偏移，file vm addr加上slide就能获取到运行期间的真实地址。
通过dyld打印所有的系统库和镜像信息，这一步的目的是获取到CoreServices的slide：
int count = _dyld_image_count();
for (int i = 0; i < count; i ++) {
const char * name = _dyld_get_image_name(i);
uint64_t slide = _dyld_get_image_vmaddr_slide(i);
printf("0x%lx -> %s\n",slide,name);
}
通过打印信息我们可以知道CoreServices的slide为0x7cf88000 ，因此我们可以推断出上文中没有解析出来的函数0x1adbf7e78和0x1adce2cff在运行调试期间的地址分别为0x000000022ab7fe78和0x000000022ac6acff。
image-20211228154837719
因此可以得知分别调用的是sharedInstance和allowsAlternateIcons。进一步跟踪发现allowsAlternateIcons取决于inEducationMode，不了解这个模式因此不再跟踪，这种情况下的报错为NSOSStatusErrorDomain code = -4。
总结
总的来说error code找的不全，但是整体思路和相关技巧应该都已经探索过了。目前笔者对arm64指令集和hopper等工具的使用还不是很熟悉，如果文章有纰漏敬请指正~
网友评论