趁著元旦假期，花了一天的時間了解了一下 iOS 和 Mac App 的逆向技術。第一次涉足逆向工程，原本只是打算了解一下逆向的知識，然后發現原來還可以利用逆向做點有趣的事，于是在完成之后記錄一下下~
實踐結果
通過這次逆向，最終我實現了 iOS 端微信消息的防撤回 和 運動步數的修改 以及 Mac 端微信消息的防撤回 和 迅雷的免登陸免會員使用離線下載 功能 。
當然，軟件的權利應當受到保護，逆向的技術亦不應被非法利用。因此本文并非為了破解任何的軟件，只是取一些常用的 App 作例子，從技術的角度闡述一下逆向的知識點。
前提條件
由于我的 iOS 設備都系統都在 9.3.5 以上（手動捂臉），因此本次逆向的前提條件是在非越獄的設備上運行的。
前期準備
想要實現 Mac 系（macOS、iOS） Apps 的逆向，首先需要一些工具的協助：
如果有越獄的設備，則還需要 dumpdecrypted 對應用進行 “敲殼” 。由于前提條件，這次就不談論這個了。
從 Mac 端微信開始
鑒于 Mac 端微信的逆向比較簡單，這次就先從這開始吧。這次我們的目標是使得對方的撤回功能失效，即即使對方撤回了消息，我們還能看到對方的消息。那先用 class-dump ，導出微信的頭文件吧。
看了一下，40+M 的二進制文件竟然包含了 2000+ 的頭文件。好吧，那得 search 一下了。既然是撤回消息，應該其方法名稱就包含 ”撤回“ 了吧。Search 一下，目標瞬間縮小成個位數了。
然后我關注到了 MessageService 中有一個方法：
- (void)onRevokeMsg:(id)arg1;
猜測應該就是收到 ”撤回消息“ 這一條消息的時候要執行的方法了，于是試一下吧。
把微信的 Mach-O 文件扔進 Hopper ，然后修改一下其匯編指令，讓它不執行任何操作直接返回吧。
重新生成可執行文件之后直接替換掉原來的文件，然后重新運行微信，發現就成功了：）
整個過程為：
Binary --> Assembly Language --> Modification --> Assembly Language --> Binary
至于 iOS 端
同樣的功能，在 iOS 端上要實現看起來就要麻煩多了。由于 未越獄的 iOS 并不允許運行未經簽名的應用 ，因此在修改之后還需要對 app 進行 重新簽名 。同時，在 App Store 里下載到的應用都是經過加密的，因此不能直接就 dump 出其頭文件。（同時由于前提條件無法自行敲殼）于是只好直接去 PP助手 下載一個越獄版的 ipa 了。
這次要實現的是 消息防撤回 和 修改微信運動步數 兩個功能，于是我們利用 method-swizzling hook 一下，通過動態修改其本該調用的方法來實現。
在得到了已敲殼的 ipa 之后，就能 dump 出頭文件了。在 dump 出來之后，我收到了驚嚇。。。竟然有高達 8000 個頭文件。。。 真是一個好龐大的工程啊。
好吧，然后結果發現 iOS 版的微信 ”撤回“ 功能在 CMessageMgr 中，方法同樣是這個呢。
- (void)onRevokeMsg:(id)arg1;
然后用上面同樣的方法，在 WCDeviceStepObject 里找到了對應步數的兩個屬性：
@property(nonatomic) unsigned long hkStepCount;
@property(nonatomic) unsigned long m7StepCount;
猜一下，這里應該就是根據 HealthKit 是否可用然后去取不同的屬性吧。那把他們兩個的 get 方法都替換了就好~ 利用 iOSOpenDev 創建一個 hook 的模板，就連手動調用 method-swizzling 的代碼也省了。
然后加入對應要的 hook 的三個方法，讓 onRevokeMsg 不執行任何操作，讓 getters 直接返回想要的數值：
@class CMessageMgr;
CHDeclareClass(CMessageMgr);
CHOptimizedMethod(1, self, void, CMessageMgr, onRevokeMsg, id, value1) {
}
@class WCDeviceStepObject;
CHDeclareClass(WCDeviceStepObject);
CHOptimizedMethod(0, self, unsigned long, WCDeviceStepObject, m7StepCount) {
return 66666;
}
CHOptimizedMethod(0, self, unsigned long, WCDeviceStepObject, hkStepCount) {
return 66666;
}
CHConstructor {
@autoreleasepool {
CHLoadLateClass(CMessageMgr);
CHLoadLateClass(WCDeviceStepObject);
CHHook(1, CMessageMgr, onRevokeMsg);
CHHook(0, WCDeviceStepObject, m7StepCount);
CHHook(0, WCDeviceStepObject, hkStepCount);
}
}
這樣就好了，build 一下生成 .dylib ，再用 dylib_insert 把動態庫的地址注入 Mach-O 就會生成一個新的 Mach-O 文件。
/insert_dylib @executable_path/JustATry.dylib ~/Desktop/WeChat
用 MachOView 就能看到新的動態庫已經被注入了：
最后把這個文件改名重新改回 WeChat ，再連同動態庫放入原 WeChat.app 并替換原來的文件，再用 iOS App Signer 對其進行重新簽名。搞定。
整個過程：
Decrypted Binary --> Insert dylib --> Resign
由于 Objective-C 動態的特性，這次我們可以不用對二進制文件進行反編譯，然后再對匯編指令進行修改，只需要直接添加一個動態庫就能實現功能的更改了。
至于迅雷的破解
其實迅雷的破解跟 Mac 版微信的破解思路是類似的。
[UserController isLogined];
[UserController isVip]:
[UserController isPlatinum];
[UserController isDiamond];
[LocalTask isValidLixianTask];
讓以上五個方法全部返回 YES 即可。
到這吧。
2017-1-28
結尾再送個彩蛋。關于某度云客戶端對非會員用戶默默地實行最高 80k 的下載速度的事情。原本可以通過使用舊版本 "XX同步盤" 來免受速度的限制，而后來 "XX同步盤" 在啟動后檢查版本的時候加入了更新提醒并自動退出了程序。而新版的 "XX網盤" 貌似是用 swift 和 objective-c 混編的。
于是直接對舊版 "XX同步盤" 的檢查更新方法處理一下就可以繼續使用咯。
2017-2-4 再更。
剛發現上述同步盤的彩蛋已失效。原本其通過強制升級來禁止用戶使用，而如今改成了在用戶登錄的時候加入了版本的檢測，若使用了舊版本的應用，則會提示登錄失敗。通過查看 errorMsg 得知是 tpl 的錯誤：
對比一下舊版本與新版本的請求后發現 tpl 從 mybox 改成 netdisk 了。
舊版本
新版本
當然，由于還有請求簽名的存在，這次就不能再僅僅通過動態庫修改 tpl 來繞過了。
