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