在看雪论坛上看到了某软件防篡改分析，不过我看到的时候那篇帖子已经删掉了内容。在写这篇 post 的时候发现有人贴上了原始的文章，某软件防篡改分析。

一开始自己在做绕过的时候，只是大概猜到有防注入的措施，但是没有细研究，而是选择了另一个方式，同样实现了 dylib 的注入，并且不需要修改主程序。

该软件在 2.x 的某一个版本中，开始加入了与其 PC 端相似的一些功能，然后猜想是为了模块化开发，同时在非必要的时候不加载某些插件，这样可以提升应用的启动速度，而不是将那些功能和主程序一起编译，那么这也给了我们机会。站在事后诸葛亮的角度来分析的话，在最开始提到的 某软件防篡改分析 这篇 post 中，我们可以看到在 2.x 的版本中，这个软件是对主程序进行了抽样（每隔 1023 字节）的 MD5 校验。那么如果主程序有防注入／篡改的措施，我们不妨考虑从这些插件下手。

由于该软件使用了插件的方式，则在运行时必然会动态加载需要的插件（或者称为 bundle）。这里我们选择了某个在该软件启动的同时加载的 bundle。接下来将已经编译好的 dylib 插入到它的 load_commands 里面，然后启动该软件，就看到了如上图所示的效果。

这里我们对一个动态加载的 bundle 进行注入，就可以使可能非常严密的主程序保护失效。简单的解释是，因为动态加载的插件是和主程序在同一个进程的空间里的，而我们的 dylib 又在这个插件的 load_commands 里，所以这个 dylib 在主程序加载插件的同时，作为插件的依赖被一并加载到了主程序的进程空间中，因此可以对主程序的 Objective-C 方法进行 swizzling。

虽然不太清楚在 3.x 的版本中该软件具体是如何防注入／篡改的，但是通过上面的实例，可以看出仅仅验证主程序是远不够的。软件开发者若需要在自己的软件中、使用插件的形式分发某些可选加载的功能时，应该对所有分发的二进制文件进行防注入／篡改的保护（当然，还有很多其他的保护措施）。