逆向学习笔记

前言：本文适合像笔者一样，对逆向几乎零基础的同学阅读

一点小建议：环境这块快速略过，能正常使用就行，无需过分纠结。

环境

越狱

如何越狱

通过体验，目前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-tools

    brew-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等工具的使用还不是很熟悉，如果文章有纰漏敬请指正~

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
平台声明：文章内容（如有图片或视频亦包括在内）由作者上传并发布，文章内容仅代表作者本人观点，简书系信息发布平台，仅提供信息存储服务。

推荐阅读更多精彩内容