闲鱼|iOS-逆向开发五阿里巴巴

通过前面的说明，大家应该已经能大致了解逆向要怎么学习怎么做了。那我们肯定会有担心，如果自己的App被HOOK了要怎么办，有没有办法可以防护自己的App的办法？那么接下来我们就来讲一下逆向的防护。

一：防护method swizzling的方法
这里使用fishHook进行防护， method swizzling中经常用到的方法交换想必大家都很熟悉了，这里就以method_exchangeImplementations为例。 fishHook依然是在load方法中进行代码编写。通过rebinding的name、replacement、和replaced属性进行交换，最后使用revind_symbols方法。然后就是打包工程了。通过之前我们逆向的操作Framework ，再利用method_exchangeImplementations进行HOOK ，发现依然可以HOOK住，这是为什么呢？不要自我怀疑，我们可以通过直接在工程中HOOK的方式测试，发现是没问题的，但是如果我们Framework的方式注入就会出现问题，这又是什么问题呢？
Framework 进行防护其实只是忽略了一个问题而已：执行顺序。从我们之前分析HOOK的文章中可以知道，如果想要更改代码执行的顺序，肯定要在执行之前拿到这个方法。我们这里是通过fishHook进行的HOOK防护，它其实也是在执行之前，将method_exchangeImplementations 函数进行了交换，换成了 XX_method_exchangeImplementations 。这说明：method_exchangeImplementations 没有被交换成 XX_method_exchangeImplementations ，至少在破解代码之前没有进行交换。大家可以调试一下，以便证明这个结论：
在防护代码中创建也创建一个Framework ，看执行顺序，会发现是Framework是先执行的。这就能够解释了出问题的原因：因为Framework中的代码已经执行了，所以HOOK已经生效了；但当执行到防护代码ViewController中的时候，早已经HOOK完毕，就造成防护没有起到作用。（DYLD会先加载插入的Framework ，然后才是慢慢进入主程序，执行我们所写的代码。 DYLD的加载过程：配置环境——加载共享缓存——初始化MechO——加载插入动态库——初始化主程序——objc_init给DYLD一个回调——load_images——load）。
完全防护我们已经知道插入Framework的执行是在我们的代码之前，于是想要进行安全防护，肯定是需要将防护代码写在别人恶意执行之前才行。那么要怎么做呢？其实就是将防护写在Framework中。
二：防护Tweak插件
Tweak原理：Tweak在Make package的时候，会生成一个deb包，我们解压后会发现里面是一个动态库和一个plist文件，这个plist文件里面包含该dylib要注入到进程的BundleId 。当这个deb包安装到手机上时，就会把这两个文件放到/var/Library/MobileSubstrate/DynamicLibraries这个路径下。 App启动时就会通过DYLD_INSERT_LIBRARIES这种方式将动态库注入到进程中，从而实现注入，因此防护Tweak ，其实就是要防止DYLD_INSERT_LIBRARIES注入。（这里推荐苹果开源代码下载dyld的源码，了解DYLD_INSERT_LIBRARIES注入的流程，逆向分析源码）。
要解决这个问题就要一步步分析，首先我们需要定位关键字DYLD_INSERT_LIBRARIES 。而我们只需要让这段代码不执行就可以了，所以接着查找如何让这段代码不执行，找到是哪里修改了sEnv.DYLD_INSERT_LIBRARIES 。我们只需找到processDyldEnvironmentVariable-> checkEnvironmentVariables-> (!gLinkContext.allowEnvVarsPrint &&! gLinkContext.allowEnvVarsPath && !gLinkContext.allowEnvVarsSharedCache ， 最终要确认的是hasRestrictedSegment方法，到底是怎么判断的。