利用 memgraph 文件追踪 App 内存信息

Share

memgraph 文件导出方法

  1. 在 App 调试状态下点击 View Memory Graph Hierarchy
Untitled

或者点击这里

Untitled
  1. 生成 memgraph 文件后,点击 File → Export Memory Graph
Untitled

memgraph 文件可以用 Xcode 直接打开,但是直接打开查看的话,信息比较混杂,难以查找到自己想要的信息。下面就介绍一些在终端利用 memgraph 文件查看各种内存信息的指令。

使用 vmmap 查看虚拟内存信息

拿到 memgraph 文件后,在终端输入下面指令可以获取 App 进程占用的虚拟内存信息:

vmmap filename.memgraph > output_vmmap.txt

输出文件中,首先展现的是不可写的内存区域,比如一些 framework,可执行文件,资源包等。

Untitled
Untitled

接着是可写内存区域:

Untitled

我们可以据此优化一下 App 启动时占用的内存,比如静态库/动态库。

如果想看虚拟内存的概览信息,可以添加 -summary 参数:

vmmap -summary filename.memgraph > output_vmmapSummary.txt
Untitled

从输出结果中可以看到不同类型的虚拟内存所占用的内存块的大小。对于内存问题,我们应主要关注 DIRTY SIZESWAPPED SIZE 这两列。其中 DIRTY SIZE 是应用实际已经写入的内存,包括 heap 中的对象、图像解码缓冲以及加载到内存中的 framework等,系统无法自动回收;SWAPPED SIZE 在 iOS 设备上叫做 Compressed Memory ,因为 iOS 等移动设备系统并没有实际意义上的内存交换机制。

使用 malloc_history 获取内存分配的堆栈信息

顾名思义,malloc_history 这个指令能够获取对象内存分配的详细调用栈信息。使用这项能力需要我们先开启 Xcode 记录堆栈信息的开关:

Untitled

之后编译并运行 App,在内存达到一个比较高的值时(方便定位 OOM 问题),导出 memgraph 文件。

最后输入指令:

malloc_history filename.memgraph --callTree > output.txt

其中,malloc_history 可以指定的模式包括:-allBySize -allByCount -allEvents -callTree。一般使用 -callTree 模式获取堆栈信息即可,比较清晰明了。output.txt 为指定的输出文件名,malloc_history 输出的内容比较多,所以需要将输出定向到文件中,方便查看。

指令运行结束后,打开输出文件。可以看到详细的内存分配大小以及分配堆栈信息:

Untitled

输出信息一般是按照分配内存大小的降序排列的,这样咱们就知道了具体哪一连串的方法调用申请了一块比较大的内存。

使用 leaks 检测内存泄漏情况

检测内存泄漏同样需要咱们打开堆栈记录开关,跟 malloc_history 一样。

输入下面指令:

leaks --fullStacks filename.memgraph > output_leaks.txt

在输出文件中可以看到详细的内存泄漏位置、内存泄漏大小以及堆栈回溯信息:

Untitled
Untitled

使用 heap 查看堆内存分配情况

输入下面指令:

heap -s filename.memgraph > output_heap.txt

-s 表示按内存大小排序,可以在输出文件中查看 App 堆内存分配情况:

Untitled

或者加上 --addresses 参数查看对象实例虚拟内存地址:

heap -s --addresses=all filename.memgraph > output_heapSortedWithAddresses.txt

在输出文件中可以看到每个实例的虚拟内存地址:

Untitled

也可以带上具体的类名,查看该类的所有实例内存地址:

Untitled

有了内存地址,我们再利用 malloc_history 工具就可以获取对应的堆栈回溯信息。

Read more

在 AI 时代,做 iOS 逆向分析有哪些高效手段

在 AI 时代,做 iOS 逆向分析有哪些高效手段

AI 发展如此迅猛,传统的代码手艺活已经被 AI 取代了很大一部分。除了生成代码外,AI 在其他的研发流程也能提升很多效率,例如这次要说的 AI 逆向分析。 在手工时代,我们逆向分析一个 iOS app,通常是使用 Hopper 或者 IDA 等软件查看解密的 Mach-O,然后利用软件提供的能力加上人工去分析逻辑流程。这个过程还要求我们懂一些基础的汇编语法。有时候还要去猜测哪些类哪些方法是负责某个逻辑,靠试验去验证。 现在来到了大模型时代,AI 不仅能自己通过一些简单的工具去分析 ipa 和 Mach-O ,也能使用更准更稳的 MCP、Skill 工具来做深度的分析。 Hopper MCP Hopper 在新版本支持了 MCP Server。 把 framework、Mach-O 或者解密后的 IPA 直接丢给它,

By Gray
Cinder:基于 Swift Macro 与 Mach-O Section 的解耦注册机制

Cinder:基于 Swift Macro 与 Mach-O Section 的解耦注册机制

Cinder(Github) 是一个无需逐模块启动注册、支持字符串、类型和函数调用的 Swift 编译期注册框架。 Cinder 是什么 在 iOS app 里借助 Mach-O 注册能力做一些二进制的插桩操作并不罕见。以往这些操作大都使用 objc runtime ,借助 __attribute__((used)) 和 __attribute__((section("name"))) 实现。在 Swift 上实现有一些难度,因为 Swift runtime 能力弱,以及早期的版本没有类似 objc 的 __attribute__ 能力。 * 在 Swift 5.10 版本,Apple 提供了 @_used 和

By Gray