逆向(一): 站在开发者的角度

原本没有计划整理这部分东西，但由于近期系统升级到了macOS26，我日常使用的一个应用，无法在新系统上运行，由于前几天没时间弄清楚原因，于是就体验了一下这个应用的竞品，体验几天，实在无法忍受，于是重新在官网下载了这个我重度依赖的应用，看着几十欧元的价格，心里不禁感慨万千，真是物有所值，不过我还是没有买😂，花了几分钟，逆向了一下这个应用，感慨万千，于是准备近期整理一下这些年逆向的一些经验和方法。

总结一下这些年逆向的一些经验和方法，仅供学习，请遵守相关法律法规，尊重他人劳动成果和知识产权。后续没有特别说明的情况下，均在macOS(arm64)上面进行相关操作。

逆向基础(一)

为什么逆向？

我相信绝大部分逆向的初衷都是处于想破解某个应用的收费功能，或者是出于对某个软件的好奇，想要了解其内部实现原理(比如注入动态连接库后，使用Reveal等工具查看应用的UI层级，了解内部实现)。

我们暂且从破解某个应用的收费功能这个角度来探讨逆向工程。站在软件作者的角度，作者是否希望自己的付费功能被破解呢？我认为答案是: 希望同时又不希望。看似矛盾，但实际上却是一个普遍的心理。

1. 有人研究破解应用，变相肯定了该应用的价值。
2. 破解只在很小的范围流行，变相对应用进行了推广，有利于提高应用知名度
3. 破解应用大规模流行破坏了应用的商业模式，导致开发者失去收入。

为什么要从开发者角度思考逆向工程？

上面的分析我们知道，某款应用如果存在竞品，并非用户唯一选择时，开发者对于破解的态度往往睁一只眼闭一只眼。为什么这么说？这个应用当前并没有取得垄断地位或者不可替代，那么开发者的开发重点就会放在如何提升用户体验和增加用户粘性上，而不是一味地去防范破解行为。因为防范破解的成本往往高于被破解带来的损失。同时也意味着应用开发过程测试和维护难度增加。

举个例子

比如一个应用通过http请求来验证用户是否付费，为了防止中间人攻击，应用可以内置公钥证书，并在请求中附带签名信息。这样，即使攻击者截获了请求，也无法伪造有效的请求。或者网络请求的报文内容使用加密算法进行加密，这样即使攻击者获取了请求内容，也无法理解其含义。但使用这些措施，虽然一定程度上提高了安全性，但也增加了开发和维护的复杂性，开发者很难再使用通用工具对应用进行调试和测试。

又比如，良好的代码，在变量和函数命名上遵循一致的规范，能够提高代码的可读性和可维护性。但如果开发者过于关注代码的安全性，可能会在命名上故意使用混淆的方式，导致代码变得难以理解和维护。对破解行为的防范也可能导致开发者在设计时过于复杂化，反而增加了被破解的风险。

哪些可以逆向？

以破解付费功能为例，首先得有一个基本的判断，检测能否使用付费功能的逻辑和付费功能的主要实现是存在于客户端还是服务端还是在硬件上。

例如:

1. 应用是一个本地应用，很少需要与服务器进行交互，或者交互的内容没有过多涉及付费功能。像本地视频播放器、记账软件、图像处理软件等等这里基本可以脱离网络进行使用，付费功能的实现也主要在客户端。

2. 应用是一个网络应用，脱离网络后，付费功能的实现可能会受到限制。例如，某些应用可能会在本地缓存付费内容，但一旦网络断开，就无法验证用户的付费状态，从而导致付费功能无法使用。付费内容下载需要服务器验证用户是否有权限。已经下载的内容短时间内仍然可以使用，但一旦过期，就需要重新验证。比如: Apple Music，下载的音乐在离线状态下仍然可以播放，但一旦过期(DRM加密)，就需要重新联网验证。部分加密解密需要配合芯片完成，但在进程的内存空间还是存在未加密的内容，破解对用户权限(root/越狱等等)要求也相对较高。

3. 比如苹果商店的应用，下载的应用是加密的，无法直接逆向应用，但应用运行后，会先将加密的内容解密到内存中，越狱后的设备，就可以直接访问内存，获取解密后的内容。

逆向的一些应用

• 破解系统对私有API的限制，比如苹果有一些私有API只提供给自家应用使用，对于第三方开发者，没有提供公开的头文件。比如: 创建虚拟显示器相关API、iOS设备USB通信相关的API、Sidecar投屏到iPad相关API等等。

• 破解第三方应用的付费功能。