文中提及的逆向工程思路仅供学习参考，请支持正版软件。
付费授权模式在商业软件中十分常见，它也为公司提供了收回软件开发成本的可能，或是让个人开发者过上小资生活（想多了）。
在之前尝试绕开 iStat Menus 6（下称「ISM6」）的授权验证时，曾被授权验证函数间传递的 NSDictionary 中的 Keys ——「CPU」和「Memory」所迷惑，这样做也是在一定程度上降低了敏感字符串暴露的风险。正如上一篇文章所分析的一样，ISM6 并未使用第三方的授权管理 SDK，而是选择了自己在最终用户端使用 Security Framework 进行验证。
可以说，大部分工具软件都在使用这类相对简单但也能保留部分强壮性（Robustness）的验证模式。毕竟，实现一套完整的授权管理体系所需要操心的事情并不少，支付订单管理、授权发放和管理以及最终用户端的验证及反破解等，综合算下来可能要比开发一个工具类软件还复杂。
因此一些着手解决此类问题的第三方平台便开始提供软件授权管理服务，开发者只需要接入 SDK 便可以轻松地管理自己的软件授权，从此高枕无忧。
可是，事实真的如此吗？我们先分析，再来讨论这个问题。
本来今天上午要去看牙医，但年后医院的人实在是太多没有挂到号。下午外面还下起了大雪，那就趁着机会总结一下对 Gifox 的授权模式分析吧。
在上次分析 ISM6 时，静态和动态的方式都用上了，因此这次我决定先静态分析看看。
Gifox 的字符串像一锅浆糊一样，以往靠直接查找敏感关键词的方法并不是很好用。但在粗略分析后，我发现真正的验证工作可能不在它本身。如果尝试点击「Lost license」来恢复购买，你会发现跳转到的网站并不是 Gifox 的官方支持页面，而是一个第三方授权管理平台的网站。
从这里开始，我开始怀疑它使用了我们开头所说的第三方 SDK。这也是绕开验证的突破口。
在有了思路之后，我找到了它的实现者。这回静态分析的目标变成了这个在最终用户端实现授权验证的 Framework。
很快便找到了控制授权验证的函数，看流程图（太长所以我把它们 (ﾉ*･ω･)ﾉ 推倒了）也能看出来是一棵充满条件分支的老树。
当然，这里为了绕开验证流程，我们只需要对 rax（绒布球寄存器） 下手就好了。mov rax, 1 总归是好用的。
实测去除了 10 秒的录制以及水印显示/隐藏开关的限制。
静态分析的时候还看到了用 sysctl 检查是否有 Debugger 附加的函数，也一起改掉了。
不过动态调试的时候发现这个函数并没有显式的影响程序的正常启动，不像有一些软件在遇到 Debugger 的时候便华丽丽的 SIGKILL 自杀。反调试的手段和近期研究的一些带壳 Android 软件所用的也并没有太大差异。
现在回到开始时的问题——真的高枕无忧吗？并不是。
既然是第三方授权管理平台，除了 Gifox 必然还会有其他的软件或开发者在使用，而第三方 SDK 的天然特性又限制了它对出现的安全性问题的快速响应和修补能力。
如果说这是一个特例，那么替换掉使用同样第三方授权管理平台的软件中的 Framework。
Bang. It works.
现在可以肯定的说，第三方平台并不能让开发者高枕无忧的管理收入。
破解和反破解，正如反破解和反反破解一样，是宿敌无疑。即便使用了高级的壳子，也总归要在最终用户的设备上运行，也总归要在运行效率和安全性之间做出权衡。
破解和未被破解，只是时间的问题。作恶与不作恶，也只是底线的问题。
交给最终用户，总归是不安全的。
就说到这里，雪还在下。
咱继续写个人的项目去了。