非越獄下 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，更傾向於前兩種方式。