轉(zhuǎn)自 https://segmentfault.com/a/1190000005908458
以下為個(gè)人備忘學(xué)習(xí)使用，感謝原作者的付出
如果您有耐心看完這篇文章，您將懂得如何著手進(jìn)行app的分析、追蹤、注入等實(shí)用的破解技術(shù)，另外，通過“入侵”，將幫助您理解如何規(guī)避常見的安全漏洞，文章大綱：
- 簡單介紹ios二進(jìn)制文件結(jié)構(gòu)與入侵的原理
- 介紹入侵常用的工具和方法，包括pc端和手機(jī)端
- 講解黑客技術(shù)中的靜態(tài)分析和動(dòng)態(tài)分析法
- 通過一個(gè)簡單的實(shí)例，來介紹如何綜合運(yùn)用砸殼、尋找注入點(diǎn)、lldb遠(yuǎn)程調(diào)試、追蹤、反匯編技術(shù)來進(jìn)行黑客實(shí)戰(zhàn)
- 講解越獄破解補(bǔ)丁和不需越獄的破解補(bǔ)丁制作方法和差別
黑客的素養(yǎng)
-
敏銳的嗅覺
有時(shí)候通過一個(gè)函數(shù)名，一個(gè)類名，就能大致的判斷出它的作用，這就是嗅覺；功力已臻化境時(shí)，甚至可以使用第六感判斷出一些注入點(diǎn)
-
面對失敗的勇氣
破解有時(shí)候很耗時(shí)，和程序開發(fā)正好相反，它耗時(shí)不是耗在寫代碼上，而是耗在尋找注入點(diǎn)和逆向工程上，有可能你花了3天時(shí)間去找程序的破綻，但是最終的破解代碼可能就2行，不到一分鐘就搞定了；但是你也需要做好面對失敗的準(zhǔn)備，如果路選錯(cuò)了，有可能你這3天完全是在浪費(fèi)腦細(xì)胞
-
洪荒之力
洪荒之力－即入侵過程中需要借助的各種工具，工欲善其事，必先利其器，工具都是前人智慧的結(jié)晶，能用工具解決的，絕不要手動(dòng)去搞
iOS黑客關(guān)鍵字
iOS的入侵離不開越獄開發(fā)，一切的破解、入侵都是建立在越獄的基礎(chǔ)上的，如果沒有拿到系統(tǒng)級權(quán)限，一切的想法都是空談了，當(dāng)然，市面上存在免越獄的破解補(bǔ)丁，但是它的開發(fā)過程，也是基于越獄環(huán)境的
tweak
在iOS的黑客界，要做破解或越獄開發(fā)，就必須了解tweak，它是各種破解補(bǔ)丁的統(tǒng)稱，在google上，如果你想搜索一些越獄開發(fā)資料或者開源的破解補(bǔ)丁代碼，它是最好的關(guān)鍵字。
iOS的tweak大致分為兩種：
- 第一種是在cydia上發(fā)布的，需要越獄才能安裝，大部分是deb格式的安裝包，iOS在越獄后，會(huì)默認(rèn)安裝一個(gè)名叫mobilesubstrate的動(dòng)態(tài)庫，它的作用是提供一個(gè)系統(tǒng)級的入侵管道，所有的tweak都可以依賴它來進(jìn)行開發(fā)，目前主流的開發(fā)工具有theos和iOSOpenDev，前者是采用makefile的一個(gè)編譯框架，后者提供了一套xcode項(xiàng)目模版，可以直接使用xcode開發(fā)可調(diào)試，但是這個(gè)項(xiàng)目已經(jīng)停止更新了，對高版本的xcode支持不好，大家酌情選擇（本文中的例子全部采用theos）
- 第二種是直接打包成ipa安裝包，并使用自己的開發(fā)證書或者企業(yè)證書簽名，不需越獄也可以安裝，可直接放到自己的網(wǎng)站上，可實(shí)現(xiàn)在線安裝；對于沒有越獄的手機(jī)，由于權(quán)限的限制，我們是沒有辦法寫系統(tǒng)級的tweak的，例如springboard的補(bǔ)丁是沒法運(yùn)行的，這種tweak大多是針對某個(gè)app，把目標(biāo)app進(jìn)行修改注入處理，再重新簽名和發(fā)布，有點(diǎn)類似于windows軟件的xxx破解版、xxx免注冊版
沒有越獄的機(jī)器由于系統(tǒng)中沒有mobilesubstrate這個(gè)庫，我們有二個(gè)選擇，第一個(gè)是直接把這個(gè)庫打包進(jìn)ipa當(dāng)中，使用它的api實(shí)現(xiàn)注入，第二個(gè)是直接修改匯編代碼；第一個(gè)適用于較為復(fù)雜的破解行為，而且越獄tweak代碼可以復(fù)用，第二種適用于破解一些if...else...之類的條件語句
Mobilesubstrate
下面的圖展示的就是oc屆著名的method swizzling技術(shù)，他就是iOS的注入原理，類似于windows的鉤子，所以我們注入也稱為hook
Mobilesubstrate為了方便tweak開發(fā)，提供了三個(gè)重要的模塊：
- MobileHooker 就是用來做上面所說的這件事的，它定義一系列的宏和函數(shù)，底層調(diào)用objc－runtime和fishhook來替換系統(tǒng)或者目標(biāo)應(yīng)用的函數(shù)
- MobileLoader 用來在目標(biāo)程序啟動(dòng)時(shí)根據(jù)規(guī)則把指定目錄的第三方的動(dòng)態(tài)庫加載進(jìn)去，第三方的動(dòng)態(tài)庫也就是我們寫的破解程序，他的原理下面會(huì)簡單講解一下
- Safe mode 類似于windows的安全模式，比如我們寫的一些系統(tǒng)級的hook代碼發(fā)生crash時(shí)，mobilesubstrate會(huì)自動(dòng)進(jìn)入安全模式，安全模式下，會(huì)禁用所有的第三方動(dòng)態(tài)庫
app注入原理
上面講到了mobileloader，他是怎么做到把第三方的lib注入進(jìn)目標(biāo)程序的呢？這個(gè)我們要從二進(jìn)制文件的結(jié)構(gòu)說起，從下面的圖來看，Mach-O文件的數(shù)據(jù)主體可分為三大部分，分別是頭部（Header）、加載命令（Load commands）、和最終的數(shù)據(jù)（Data）。mobileloader會(huì)在目標(biāo)程序啟動(dòng)時(shí)，會(huì)根據(jù)指定的規(guī)則檢查指定目錄是否存在第三方庫，如果有，則會(huì)通過修改二進(jìn)制的loadCommands，來把自己注入進(jìn)所有的app當(dāng)中，然后加載第三方庫。
為了讓大家看的更清楚，下面我用machoview來打開一個(gè)真實(shí)的二進(jìn)制文件給大家看看，可以看出，二進(jìn)制當(dāng)中所有引用到的動(dòng)態(tài)庫都放在Load commands段當(dāng)中，所以，通過給這個(gè)段增加記錄，就可以注入我們自己寫的動(dòng)態(tài)庫了
那么問題來了，在這里插入我們自己的動(dòng)態(tài)庫有什么用？我們自己寫的代碼沒有執(zhí)行的入口，我們一樣沒發(fā)干壞事，嗯，恭喜你問到點(diǎn)子上了，我們還需要一個(gè)"main"函數(shù)來執(zhí)行我們自己的代碼，這個(gè)"main"函數(shù)在oc里面稱為構(gòu)造函數(shù)，只要在函數(shù)前聲明 "attribute((constructor)) static" 即可，有了它我們就可以發(fā)揮想象力，進(jìn)行偷天換日干點(diǎn)壞事了：
#import <CaptainHook/CaptainHook.h>
CHDeclareClass(AnAppClass);
CHMethod(1, void, AnAppClass, say, id, arg1)
{
NSString* tmp=@"Hello, iOS!";
CHSuper(1, AnAppClass, say, tmp);
}
__attribute__((constructor)) static void entry()
{
NSLog(@"Hello, Ice And Fire!");
CHLoadLateClass(AnAppClass);
CHClassHook(1, AnAppClass,say);
}
到這里為止，我們已經(jīng)知道了怎么在目標(biāo)程序注入自己的代碼，那么我們怎么知道需要hook哪些方法？怎么找到關(guān)鍵點(diǎn)進(jìn)行實(shí)際的破解呢？下面講一下常見的app入侵分析方法
iOS逆向分析方法
逆向分析最常用的有三種方法：
1.網(wǎng)絡(luò)分析
通過分析和篡改接口數(shù)據(jù)，可以有效的破解通過接口數(shù)據(jù)來控制客戶端行為的app，常用的抓包工具有Tcpdump, WireShark, Charles等，windows平臺(tái)有fidller
2. 靜態(tài)分析
通過砸殼、反匯編、classdump頭文件等技術(shù)來分析app行為，通過這種方式可以有效的分析出app實(shí)用的一些第三方庫，甚至分析出app的架構(gòu)等內(nèi)容，常用的工具有dumpdecrypted（砸殼）、hopper disassembler（反匯編）、class_dump（導(dǎo)頭文件）
3. 動(dòng)態(tài)分析
有靜就有動(dòng)，萬物都是相生相克的，動(dòng)態(tài)分析指的是通過分析app的運(yùn)行時(shí)數(shù)據(jù)，來定位注入點(diǎn)或者獲取關(guān)鍵數(shù)據(jù)，常用的工具有cycript（運(yùn)行時(shí)控制臺(tái)）、 lldb+debugserver（遠(yuǎn)程斷點(diǎn)調(diào)試）、logify（追蹤）
Demo:微信搶紅包插件
上面講了很多原理性的東西，相信大家已經(jīng)看的不耐煩了，下面我們一起動(dòng)點(diǎn)真格的，我們從頭開始，一步一步的做一個(gè)微信的自動(dòng)搶紅包插件，當(dāng)然，網(wǎng)上可能已經(jīng)有相關(guān)的開源代碼了，但是我這里要講的是，這些代碼是怎么得出來的，我么重點(diǎn)講一講分析過程
工欲善其事，必先利其器
一臺(tái)越獄的手機(jī)，并裝有以下軟件
cycript
dumpdecrypted
debug server
openssh
一臺(tái)蘋果電腦，并裝有以下軟件class_dump
Theos
Hopper Disassembler v3
xcode
insert_dylib
pp助手
尋找注入點(diǎn)
砸殼
首先我們要做的就是把微信的殼砸掉，砸殼其實(shí)是為了把它的頭文件classdump出來，因?yàn)閺腶ppstore下載的app二進(jìn)制都是經(jīng)過加密的，直接進(jìn)行classdump操作是啥也看不出來的
- 用pp助手把dumpdecrypted.dylib文件copy到微信的documents目錄
- ssh到手機(jī)的終端，cd到documents目錄中，執(zhí)行下面的命令進(jìn)行砸殼操作
xxx$ cp /usr/lib/dumpdecrypted.dylib /path/to/app/document
xxx$ DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib /path/to/WeChat
- 最后砸殼完成后會(huì)在documents目錄生成砸了殼后的二進(jìn)制文件，用pp助手copy出來并class-dump他的頭文件備用
動(dòng)態(tài)分析－cycript
要想實(shí)現(xiàn)自動(dòng)搶紅包，我們必須找到收到紅包消息的handler方法，怎么入手呢？我們先從界面出發(fā)，進(jìn)入微信的消息首發(fā)窗口:
- ssh進(jìn)手機(jī)的終端，輸入ps命令，查找到微信的進(jìn)程id
ps aux | grep WeChat
- 祭起神器cycript，根據(jù)上一步找到的pid注入到微信的進(jìn)程
cycript -p pidxxx
- 在cycript的終端輸入這一串方法，作用就是打印出當(dāng)前界面的view層級，（cycript還有很多妙用，大家可以上官網(wǎng)看文檔，這里不詳細(xì)介紹）
UIApp.keyWindow.recursiveDescription().toString()
最終的輸出如下，內(nèi)容太多，大家肯定看不清楚，不過沒關(guān)系，這個(gè)不是重點(diǎn)，這里只是展示一下打印的結(jié)果形式：
我們可以隨機(jī)的選取一個(gè)節(jié)點(diǎn)不要太靠樹葉，也不要太靠樹根，例如我選的是標(biāo)紅的部分，把這個(gè)節(jié)點(diǎn)的內(nèi)存地址copy出來，這個(gè)內(nèi)存地址，就代表了這個(gè)節(jié)點(diǎn)的view對象，ios開發(fā)的老油條們都知道，通過view的nextResponder方法，可以找出它所屬的視圖控制器ViewController，所以我么在cycript的控制臺(tái)中持續(xù)輸入如下的命令：
看到?jīng)]有，通過四個(gè)nextResponder方法調(diào)用，我么找到了當(dāng)前聊天窗口的ViewController類名，他就是BaseMsgContentViewController，現(xiàn)在我們縮小了目標(biāo)范圍，下面我們還需要繼續(xù)縮小范圍，要找到具體的消息處理函數(shù)才行。
動(dòng)態(tài)分析－Logify
要繼續(xù)縮小范圍，就得祭起神器Logify了，它是theos的一個(gè)模塊，作用就是根據(jù)頭文件自動(dòng)生成tweak，生成的tweak會(huì)在頭文件的所有方法中注入NSLog來打印方法的入?yún)⒑统鰠ⅲ浅＿m合追蹤方法的調(diào)用和數(shù)據(jù)傳遞
現(xiàn)在我們根據(jù)此前砸殼后class_dump出來的頭文件，找到BaseMsgContentViewController在pc終端執(zhí)行如下命令：
logify.pl /path/to/BaseMsgContentViewController.h > /out/to/Tweak.xm
輸出的tweak文件大概是這個(gè)樣子的：
這里帶百分號的關(guān)鍵字，例如 %hook、%log、%orig 都是mobilesubstrate的MobileHooker模塊提供的宏，其實(shí)也就是把method swizzling相關(guān)的方法封裝成了各種宏標(biāo)記，使用起來更簡單，大家想要更深入了解各種標(biāo)記，可以google一下logos語言
theos創(chuàng)建tweak
上面我們用logify生成了一個(gè)tweak代碼，我們要把它安裝到手機(jī)上，首先需要使用theos進(jìn)行編譯，安裝了theos之后，在pc終端輸入nic.pl：
首先選擇項(xiàng)目模版當(dāng)然是tweak啦，然后是項(xiàng)目名稱、作者，后面兩個(gè)選項(xiàng)要注意：
- 首先是bundle filter，這個(gè)需要填你需要注入的目標(biāo)app的bundle id，MobileLoader模塊會(huì)根據(jù)它來尋找你的tweak的注入目標(biāo)
- 最后是list id applications to terminate upon installation，這里指定當(dāng)tweak安裝成功之后，需要kill的進(jìn)程，我們要hook微信，這里就填微信的二進(jìn)制文件名就可以了，為什么要kill？ 因?yàn)槲颐吹牟寮切枰赼pp啟動(dòng)時(shí)加載進(jìn)去的，如果不重啟app，插件是不會(huì)生效的
最后一切都完成后，在當(dāng)前目錄會(huì)生成下列文件：
把上面logify生成的tweak文件覆蓋到當(dāng)前目錄，并用文本編輯器打開makefile文件，在文件的開頭增加你的ios設(shè)備的ip地址和ssh端口：
最后在pc終端進(jìn)入項(xiàng)目目錄，輸入 make package install 命令：
期間會(huì)讓你輸入設(shè)備的ssh密碼，越獄機(jī)器的默認(rèn)ssh密碼是alpine，make命令會(huì)生成deb安裝包，放在debs目錄，我們?nèi)绻雽ν獍l(fā)布自己的插件，可以把生成的安裝包上傳到cydia即可
安裝成功后再次進(jìn)入微信的聊天界面，并使用另外一個(gè)微信在群里發(fā)個(gè)普通消息，連接xcode打開越獄機(jī)器控制臺(tái)，查看輸出，會(huì)發(fā)現(xiàn)有類似下面的輸出：
Jun 7 09:56:13 Administratorde-iPhone WeChat[85972] <Notice>: [1;36m[WxMsgPreview] [m[0;36mTweak.xm:308[m [0;30;46mDEBUG:[m -[<BaseMsgContentViewController: 0x15e0c9a00> addMessageNode:{m_uiMesLocalID=2, m_ui64MesSvrID=0, m_nsFromUsr=ccg*675~9, m_nsToUsr=1037957572@chatroom, m_uiStatus=1, type=1, msgSource="(null)"} layout:1 addMoreMsg:0]
看出來了吧，消息處理函數(shù)是BaseMsgContentViewController的addMessageNode:layout:addMoreMsg:方法，大家可以看出，方法的參數(shù)內(nèi)容也打印出來了
動(dòng)態(tài)分析－lldb
到目前為止，我么已經(jīng)把范圍縮小到了具體的函數(shù)，看起來注入點(diǎn)已經(jīng)找到了，但是請大家思考一下，如果我們在這個(gè)函數(shù)中注入搶紅包邏輯，那我們的tweak會(huì)不會(huì)有什么致命的缺陷？
是的，因?yàn)锽aseMsgContentViewController這個(gè)類是微信群聊天窗口對應(yīng)的controller，我么必須進(jìn)入到群的聊天界面，這個(gè)類才會(huì)創(chuàng)建，如果不進(jìn)入聊天窗口，我們的插件就不生效了，而且，即使進(jìn)入聊天窗口，也只是能自動(dòng)槍當(dāng)前群的紅包而已，其他群就無能為力了，是不是有點(diǎn)low？
所以為了使我們的插件顯得上流一些，我么還要繼續(xù)追根溯源，尋找消息的源頭，這里就用到了lldb遠(yuǎn)程調(diào)試，使用lldb打斷點(diǎn)的方式，通過調(diào)用棧，我們可以就可以看到當(dāng)消息來到時(shí)，方法的調(diào)用順序，找到最先執(zhí)行的消息處理函數(shù)。
要在剛剛追蹤到的addMessageNode:layout:addMoreMsg:方法中打斷點(diǎn)，首先我們得知道它在運(yùn)行時(shí)的內(nèi)存地址，那么內(nèi)存地址怎么來呢？有這么一個(gè)公式：
- 內(nèi)存地址＝進(jìn)程內(nèi)存基地址＋函數(shù)在二進(jìn)制中的偏移量
首先偏移量我們可以通過反匯編工具h(yuǎn)ooper來查，在pc上用hooper打開微信的二進(jìn)制文件（<font color=red>注意，打開時(shí)會(huì)讓你選擇armv7或者arm64，這需要根據(jù)你越獄手機(jī)的cpu類型來選，一定要和你的手機(jī)一致</font>），hooper的界面非常簡潔，左側(cè)有個(gè)搜索框，可以輸入函數(shù)名，直接找到函數(shù)在二進(jìn)制中的位置
通過左側(cè)的搜索框搜a(bǔ)ddMessageNode關(guān)鍵字，找到它的偏移量是0x00000001017d7c6c
找到了偏移量，還需要進(jìn)程的基地址，這個(gè)地址需要連lldb，所以下面講一下如何連接lldb進(jìn)行遠(yuǎn)程調(diào)試，先ssh進(jìn)越獄手機(jī)的終端，在終端輸入如下命令（注意，你的手機(jī)必須連xcode調(diào)試過才會(huì)有這個(gè)命令）：
debugserver *:19999 -a WeChat
然后在pc端新起一個(gè)終端窗口，輸入如下命令來連接手機(jī)端進(jìn)行調(diào)試：
lldb -> process connect connect://deviceIP:19999
如果連接成功，會(huì)進(jìn)入lldb的控制臺(tái)，我們在lldb的控制臺(tái)輸入如下命令來獲取微信進(jìn)程的基地址：
image list -o -f
執(zhí)行這個(gè)命令會(huì)打印很多行數(shù)據(jù)，像下面圖中這樣，我么要找到微信的二進(jìn)制文件所在的行，記錄它的內(nèi)存地址0X00000000000E800：
到這里我們兩個(gè)地址都找到了，再通過br命令打斷點(diǎn)：
br s -a '0X00000000000E800+0x00000001017d7c6c'
打好斷點(diǎn)后繼續(xù)向群里面發(fā)消息，我們會(huì)發(fā)現(xiàn)進(jìn)程被斷掉了，這時(shí)輸入bt指令，就可以看到當(dāng)前的調(diào)用棧，就像下圖這樣
分析堆棧的時(shí)候，重點(diǎn)找出模塊時(shí)WeChat的項(xiàng)，這些都是微信模塊的方法調(diào)用，有了堆棧，我們需要根據(jù)堆棧的內(nèi)存地址找出它的具體函數(shù)名，思路還是先根據(jù)上面講到的公式來計(jì)算出棧地址在二進(jìn)制中的偏移量，然后用hooper找到偏移量對應(yīng)的函數(shù)名
- 函數(shù)在二進(jìn)制中的偏移量＝內(nèi)存地址 - 進(jìn)程內(nèi)存基地址
例如根據(jù)箭頭所指的內(nèi)存地址和剛剛得到的進(jìn)程基地址，計(jì)算偏移量：
0x0000000101ad02f4 – 0x00000000000e8000 = 1019E82F4
然后在hooper中搜索這個(gè)地址，得到結(jié)果如下：
最終把所有的棧都進(jìn)行還原，得出調(diào)用棧是這個(gè)樣子的：
-[CMessageMgr MainThreadNotifyToExt:]:
–>
-[BaseMsgContentLogicController OnAddMsg:MsgWrap:]:
——>
-[RoomContentLogicController DidAddMsg:]
———->
-[BaseMsgContentLogicController DidAddMsg:]
—————->
-[BaseMsgContentViewController addMessageNode:layout:addMoreMsg:]:
CMessageMgr這個(gè)類浮出水面了，是時(shí)候發(fā)揮黑客的嗅覺了，根據(jù)方法名我們能判斷出MainThreadNotifyToExt:這個(gè)方法僅僅是用來發(fā)送通知的，如果hook這個(gè)方法，我們是拿不到消息內(nèi)容的
由于這里可能是一個(gè)異步調(diào)用，用斷點(diǎn)的方式，可能已經(jīng)打印不出來?xiàng)Ｐ畔⒘耍赃€得使用logify來繼續(xù)追蹤C(jī)MessageMgr這個(gè)類，講過的內(nèi)容我就不重復(fù)了，直接得到最終的消息處理函數(shù)：
-(void)AsyncOnAddMsg:(id)message MsgWrap:(CMessageWrap* )msgWrap
實(shí)現(xiàn)“搶”的動(dòng)作
上一節(jié)我們已經(jīng)找到了hook的關(guān)鍵點(diǎn)，那么該如何去實(shí)現(xiàn)搶的動(dòng)作？同樣我們需要結(jié)合動(dòng)態(tài)分析和靜態(tài)分析，首先得到紅包消息體的數(shù)據(jù)特征，然后再分析處理消息的關(guān)鍵點(diǎn)
數(shù)據(jù)包分析
首先我們的代碼需要分辨哪些才是紅包消息，方法很簡單，用logify追蹤BaseMsgContentViewController，然后向微信群發(fā)一個(gè)紅包，觀察手機(jī)日志輸出，我們可以看出消息的數(shù)據(jù)結(jié)構(gòu)中有個(gè)type字段，值是49，這個(gè)type應(yīng)該就是標(biāo)記消息類型的，如果不確定，可以再發(fā)個(gè)圖片或者文本之類的消息，這個(gè)值是不同的：
Administratorde-iPhone WeChat[47410] <Notice>: [1;36m[WxMsgPreview] [m[0;36mTweak.xm:308[m [0;30;46mDEBUG:[m -[<BaseMsgContentViewController: 0x15e0c9a00> addMessageNode:{m_uiMesLocalID=16, m_ui64MesSvrID=1452438635530425509, m_nsFromUsr=1037957572@chatroom, m_nsToUsr=ccg*675~9, m_uiStatus=4, type=49, msgSource="<msgsource>
<silence>0</silence>
<membercount>3</membercount>
</msgsource>
"} layout:1 addMoreMsg:0]
現(xiàn)在我們能分辨消息類型了，重點(diǎn)來了，怎么實(shí)現(xiàn)搶這個(gè)事呢，可能聰明人已經(jīng)猜到了，從ui入手，先找到微信本身的搶紅包函數(shù)，我們自己來給它構(gòu)造參數(shù)并調(diào)用他不就行了？
把紅包點(diǎn)開后，用cycript打印出當(dāng)前view的層次，就像下面這個(gè)，一眼就可以看到重點(diǎn)，WCRedEnvelopesReceiveHomeView就是開紅包彈框的類名
知道類名后，用cycript追蹤它，點(diǎn)擊開紅包，在日志中找到了下圖中的內(nèi)容，從名字來看，這是一個(gè)事件處理函數(shù)，我們現(xiàn)在要做的，就是把他還原成oc代碼，真正實(shí)現(xiàn)搶紅包功能
Administratorde-iPhone WeChat[91173] <Notice>: [1;36m[WxMsgPreview] [m[0;36mTweak.xm:8[m [0;30;46mDEBUG:[m -[<WCRedEnvelopesReceiveHomeView: 0x13cdda8c0> OnOpenRedEnvelopes]
靜態(tài)分析法
怎么把他還原成oc代碼，真正實(shí)現(xiàn)搶紅包功能呢？還得借助一點(diǎn)點(diǎn)匯編技能，只是一點(diǎn)點(diǎn)而已，因?yàn)楝F(xiàn)在的反匯編工具已經(jīng)很強(qiáng)大了，我們不需要挨個(gè)去看寄存器了
在pc上用hooper打開微信的二進(jìn)制文件，搜索OnOpenRedEnvelopes，查看匯編代碼，注意在圖片中最后一行調(diào)用了一個(gè)WCRedEnvelopesReceiveHomeViewOpenRedEnvelopes函數(shù)
繼續(xù)搜索WCRedEnvelopesReceiveHomeViewOpenRedEnvelopes這個(gè)方法，找到它的匯編代碼
- 首先他不知道從哪里獲取了一個(gè)payinfoitem
- 然后又獲取了payinfo的m_c2cNativeUrl屬性
- 然后調(diào)用substringfromindex吧navtiveurl的前綴截?cái)啵⒄{(diào)用bizutil的一個(gè)方法把url參數(shù)轉(zhuǎn)換成了一個(gè)字典
最終反解出的代碼如下，是不是很簡單？
NSString *nativeUrl = [[msgWrap m_oWCPayInfoItem] m_c2cNativeUrl];
nativeUrl = [nativeUrl substringFromIndex:[@"wxpay://c2cbizmessagehandler/hongbao/receivehongbao?" length]];
NSDictionary *nativeUrlDict = [%c(WCBizUtil) dictionaryWithDecodedComponets:nativeUrl separator:@"&"];
繼續(xù)往下看, 在這里前面三行創(chuàng)建了一個(gè)mutable dictionary：
- 緊接著下面三個(gè)框框處都是調(diào)用了setobject：forkey：向里面填東西，那填的東西是啥呢？
- 其實(shí)這里已經(jīng)可以看的很清楚了，第一個(gè)key是msgtype，值是字符串1，第二個(gè)sendid，值是調(diào)用了一個(gè)objectforkey從另一個(gè)字典中取出來的，很顯然，另一個(gè)字典就是上面從url解析得到的，后面的channelid也是同樣的道理
最終得到的代碼如下：
NSMutableDictionary *args = [[%c(NSMutableDictionary) alloc] init];
[args setObject:nativeUrlDict[@"msgtype"] forKey:@"msgType"];
[args setObject:nativeUrlDict[@"sendid"] forKey:@"sendId"];
[args setObject:nativeUrlDict[@"channelid"] forKey:@"channelId"];
繼續(xù)往下看從箭頭所指的幾處，我們可以看見，它的代碼是這樣的，共分為四步
- 第一個(gè)箭頭調(diào)用了mmservicecenter的defaultcenter方法來獲取mmservicecenter實(shí)例
- 第二個(gè)箭頭調(diào)用了CContactMgr的class方法
- 第三個(gè)箭頭調(diào)用了第一步獲取的mmservicecenter實(shí)例的getservice方法，而這個(gè)方法是把第二步得到的class作為參數(shù)
- 第四個(gè)箭頭很明白了吧，第三步得到了CContactMgr實(shí)例，這里就是調(diào)用CContactMgr實(shí)例的getselfcontact方法獲取自己的賬戶資料
最終還原的到的代碼如下：
CContactMgr *contactManager = [[%c(MMServiceCenter) defaultCenter] getService:[%c(CContactMgr) class]];
CContact *selfContact = [contactManager getSelfContact];
繼續(xù)往下看，這里使用剛剛得到的selfcontact來獲取displayname和headimgurl，并把它們設(shè)置到剛剛的字典里面了，key分別是nickname和headimg
最終的代碼：
[args setObject:[selfContact getContactDisplayName] forKey:@"nickName"];
[args setObject:[selfContact m_nsHeadImgUrl] forKey:@"headImg"];
接著看，接下來這兩段就比較蛋疼了，完全是從內(nèi)存地址里面取的值，我也不知道他從哪里來，怎么辦呢？有沒有不懂匯編就能搞定它的捷徑呢，答案是有！
- 對于第一個(gè)，我可以通過它的key猜出來，還記得最開始的時(shí)候我們?nèi)∵^payinfo的一個(gè)nativeurl屬性吧，我們姑且把他傳進(jìn)去
- 對于第二個(gè)，我們可以猜測sessionUserName大概是會(huì)話名稱，也就是群名稱的意思，從哪里取這個(gè)值呢？我們先把也設(shè)置成偽代碼
最終的結(jié)果如下：
[args setObject:nativeUrl forKey:@"nativeUrl"];
[args setObject:xxx forKey:@"sessionUserName"];
繼續(xù)往下看，接下來這一段還是用mmservicecenter來獲取WCRedLogicMgr對象，然后調(diào)用WCRedLogicMgr的open方法來拆紅包，可以想象open方法的參數(shù)就是上面我們辛苦組裝的字典
代碼如下：
[[[%c(MMServiceCenter) defaultCenter] getService:[%c(WCRedEnvelopesLogicMgr) class]] OpenRedEnvelopesRequest:args];
領(lǐng)紅包邏輯
到這里，我們再總結(jié)一下我們上面分析的過程......
- 得到m_oWCPayInfoItem屬性
- 解析m_oWCPayInfoItem的m_c2cNativeUrl屬性
- 得到selfcontact
- 組裝相關(guān)參數(shù)
- 調(diào)用OpenRedEnvelopesRequest:領(lǐng)取紅包
最終的搶紅包代碼合并起來如下：
#import "WxMsgPreview.h"
%hook CMessageMgr
-(void)AsyncOnAddMsg:(id)message MsgWrap:(CMessageWrap* )msgWrap {
%log;
%orig;
if(msgWrap.m_uiMessageType == 49){
CContactMgr *contactManager = [[%c(MMServiceCenter) defaultCenter] getService:[%c(CContactMgr) class]];
CContact *selfContact = [contactManager getSelfContact];
if ([msgWrap.m_nsContent rangeOfString:@"wxpay://c2cbizmessagehandler/hongbao/receivehongbao"].location != NSNotFound) { // 紅包
NSString *nativeUrl = [[msgWrap m_oWCPayInfoItem] m_c2cNativeUrl];
nativeUrl = [nativeUrl substringFromIndex:[@"wxpay://c2cbizmessagehandler/hongbao/receivehongbao?" length]];
NSDictionary *nativeUrlDict = [%c(WCBizUtil) dictionaryWithDecodedComponets:nativeUrl separator:@"&"];
NSMutableDictionary *args = [[%c(NSMutableDictionary) alloc] init];
[args setObject:nativeUrlDict[@"msgtype"] forKey:@"msgType"];
[args setObject:nativeUrlDict[@"sendid"] forKey:@"sendId"];
[args setObject:nativeUrlDict[@"channelid"] forKey:@"channelId"];
[args setObject:[selfContact getContactDisplayName] forKey:@"nickName"];
[args setObject:[selfContact m_nsHeadImgUrl] forKey:@"headImg"];
[args setObject:nativeUrl forKey:@"nativeUrl"];
[args setObject:msgWrap.m_nsFromUsr forKey:@"sessionUserName"];
[[[%c(MMServiceCenter) defaultCenter] getService:[%c(WCRedEnvelopesLogicMgr) class]] OpenRedEnvelopesRequest:args];
}
}
}
%end
剛才說了，有兩個(gè)疑難點(diǎn)沒有解決:
- 第一：我們不知道payinfo是哪里來的，
- 第二：sessionusername我們也不知道是哪里來的
這時(shí)候我們可以從我們注入點(diǎn)的參數(shù)入手，首先用logify打印出addmsg方法的參數(shù)信息，會(huì)發(fā)現(xiàn)，它的第二個(gè)參數(shù)剛好有一個(gè)payinfo的屬性，這樣第一個(gè)問題迎刃而解了
第二個(gè)我們已經(jīng)猜測到它代表群名稱，所以我們從修改幾次群名稱，然后再觀察logify打印出的參數(shù)值的變化，就可以確認(rèn)出從哪里取了
通過一番折騰，得出了搶紅包的核心代碼，再結(jié)合上面章節(jié)所講的theos制作tweak包的方法，打包并安裝到手機(jī)，發(fā)個(gè)紅包試試，是不是秒搶？
免越獄插件
檢查依賴項(xiàng)
如果設(shè)備沒有越獄，是沒有mobilesubstrate等環(huán)境的，而且一些系統(tǒng)目錄是沒有讀寫權(quán)限的，這時(shí)我么只能從目標(biāo)app的二進(jìn)制文件入手，通過手動(dòng)修改load commands來加載自己的dylib，那么上面我們的插件又是使用theos基于mobilesubstrate編譯的，有沒有辦法確定我們的dylib有沒有依賴其他的庫呢？
使用osx自帶的otool工具即可，可以看出，我們的lib是依賴于substrate庫的，其他的都是系統(tǒng)庫，所以我們從越獄設(shè)備中把cydiasubstrate文件copy出來重命名為libsunstrate.dylib，和我們的dylib一起放入wechat.app目錄中
最后使用install_name_tool命令修改動(dòng)態(tài)庫的路徑把它指向app二進(jìn)制文件的同級目錄
制作安裝包
解決了依賴問題，然后要把我們的庫注入到二進(jìn)制weixin的二進(jìn)制文件，這一步使用開源的insert_dylib即可 （@executable_path是一個(gè)環(huán)境變量，指的是二進(jìn)制文件所在的路徑）
insert_dylib命令格式： ./insert_dylib 動(dòng)態(tài)庫路徑 目標(biāo)二進(jìn)制文件
//注入動(dòng)態(tài)庫
./insert_dylib @executable_path/wxmsgpreview.dylib WeChat
//打包成ipa
xcrun -sdk iphoneos PackageApplication -v WeChat.app -o ~/WeChat.ipa
最后使用用企業(yè)證書或者開發(fā)證書簽名對ipa重新簽名，就可以放到自己的渠道進(jìn)行發(fā)布了！
結(jié)語
通過綜合運(yùn)用各種工具，進(jìn)行靜態(tài)和動(dòng)態(tài)分析，我們通過實(shí)戰(zhàn)破解了微信的搶紅包邏輯，明白了入侵常用的工具，上面的搶紅包代碼還有很多改進(jìn)之處，比如沒有判斷紅包的發(fā)送者是不是自己、也沒有判斷紅包里面的文字是不是搶錯(cuò)三倍，有興趣的童鞋可以嘗試優(yōu)化一下！
