非越狱下 iOS代码注入&HOOK微信登陆

 在以前这篇iOS应用脚本重签名中，咱们对脱壳的微信安装包进行重签名，并成功在真机上运行起来，完成了iOS逆向的准备工做。这一篇咱们将经过演示如何HOOK微信登陆事件并获取到用户密码，把iOS代码注入的几种方式串起来作个简单地概述。无论作逆向仍是正向开发，这些都能为你提供一些在应用安全攻防方面的思路。
 当拿到别人的脱壳包，想要HOOK别人的方法作些小插件，首先须要程序执行你写的代码，你才有机会利用runtime的运行时机制去作本身的事情，关于方法混淆的注意事项请参考这一篇。让程序执行咱们写的代码就须要修改MachO文件，关于MachO我在这一篇里详细讲解了，这篇主要讲代码注入的事儿：

1. Framework注入

   添加本身的Framework：
   写好测试代码，在上一篇重签名脚本的基础上加一行修改MachO加载路径的代码：yololib "$TARGET_APP_PATH/$APP_BINARY" "Frameworks/SharonFramework.framework/SharonFramework"，Framework文件名为你本身刚刚添加的。直接Run！
   大功告成。

2. Dylib注入

   添加本身的Dylib：
    要注意的是这样添加的MacOS的Dylib须要将BuildSetting-->Base SDK改成iOS，BuildSetting-->CODE SIGN IDENTITY改成iPhone Developer便可在iPhone上运行。
   另外，与Framework不一样的是它须要手动添加关联库：
   一样在重签名脚本中加一行修改MachO可执行文件路径的代码：yololib "$TARGET_APP_PATH/$APP_BINARY" "Frameworks/libSharonLibrary.dylib"，dylib文件名为你本身刚刚添加的。直接Run！

 至此咱们已经完成了代码注入的第一步，让别人的应用在运行时执行咱们写的代码，这个过程当中你可能会碰到签名不成功等各类各样的奇葩问题，不要慌，静下心分析，实在不行你能够留言^_^ ~，接下来咱们要尝试HOOK微信的登陆按钮事件。

 同步几个共识：

• +load 方法的调用发生在类或分类被 runtime 加载（编译后的可执行文件被装载到内存中）时，只调用1次。
• 子类的 +load 方法会在它的全部父类的 +load 方法以后执行，而分类的 +load 方法会在它的主类的 +load 方法以后执行。
• 若是子类没有实现 +load 方法，那么当它被加载时 runtime 是不会去调用父类的 +load 方法的。同理，当一个类和它的分类都实现了 +load 方法时，两个方法都会被调用。
• 不一样的类之间的 +load 方法的调用顺序是不肯定的。
• 基于+load方法的上述特色，它是实现方法混淆的最佳入口。

经过viewDebug+头文件分析目标Method

如上图所示，咱们很快定位到登陆按钮的target为WCAccountLoginControlLogic，action为onFirstViewLogin，咱们在经过头文件分析一下，class-dump怎么用相信你Google一下就搞得定，这里就不赘述啦，拿到微信的全部头文件丢到sublime里全局搜索：

果真，找到了目标文件，点击进入头文件查看Method列表：

验证了咱们的分析是正确的。 用一样的方式咱们定位帐号密码输入页登陆按钮的target为WCAccountMainLoginViewController，action为onNext：

咱们将经过HOOK登陆按钮点击事件获取密码输入框里的内容。

MethodSwizzling的几种姿式

1. class_replaceMethod

class_replaceMethod自己会尝试调用class_addMethod和method_setImplementation，因此直接调用class_replaceMethod就能够了。

2. class_getInstanceMethod & method_setImplementation

3. method_exchangeImplementations

   心细的同窗必定会发现，在这个场景下，若是直接写个OC方法而后用method_exchangeImplementations交换新旧方法的实现有问题：
   由于my_next中的self是WCAccountMainLoginViewController，调用my_next会找不到方法。解决方案是手动为WCAccountMainLoginViewController添加my_next方法。
    由此咱们也发现，method_exchangeImplementations在分类或子类中对主/父类重载的方法进行交换时更方便些，不会出现上述问题。因此在逆向中通常不直接使用method_exchangeImplementations，更倾向于前两种方式。