本文來自於騰訊bugly開發者社群，非經作者同意，請勿轉載，原文地址：http://dev.qq.com/topic/577e0acc896e9ebb6865f321
如果您有耐心看完這篇文章，您將懂得如何著手進行app的分析、追蹤、注入等實用的破解技術，另外，通過“入侵”，將幫助您理解如何規避常見的安全漏洞，文章大綱：
- 簡單介紹ios二進位制檔案結構與入侵的原理
- 介紹入侵常用的工具和方法，包括pc端和手機端
- 講解黑客技術中的靜態分析和動態分析法
- 通過一個簡單的例項，來介紹如何綜合運用砸殼、尋找注入點、lldb遠端除錯、追蹤、反彙編技術來進行黑客實戰
- 講解越獄破解補丁和不需越獄的破解補丁製作方法和差別
黑客的素養
-
敏銳的嗅覺
有時候通過一個函式名，一個類名，就能大致的判斷出它的作用，這就是嗅覺；功力已臻化境時，甚至可以使用第六感判斷出一些注入點 -
面對失敗的勇氣
破解有時候很耗時，和程式開發正好相反，它耗時不是耗在寫程式碼上，而是耗在尋找注入點和逆向工程上，有可能你花了3天時間去找程式的破綻，但是最終的破解程式碼可能就2行，不到一分鐘就搞定了；但是你也需要做好面對失敗的準備，如果路選錯了，有可能你這3天完全是在浪費腦細胞 -
洪荒之力
洪荒之力－即入侵過程中需要藉助的各種工具，工欲善其事，必先利其器，工具都是前人智慧的結晶，能用工具解決的，絕不要手動去搞iOS黑客關鍵字
iOS的入侵離不開越獄開發，一切的破解、入侵都是建立在越獄的基礎上的，如果沒有拿到系統級許可權，一切的想法都是空談了，當然，市面上存在免越獄的破解補丁，但是它的開發過程，也是基於越獄環境的
tweak
在iOS的黑客界，要做破解或越獄開發，就必須瞭解tweak，它是各種破解補丁的統稱，在google上，如果你想搜尋一些越獄開發資料或者開源的破解補丁程式碼，它是最好的關鍵字。
iOS的tweak大致分為兩種：
-
第一種是在cydia上釋出的，需要越獄才能安裝，大部分是deb格式的安裝包，iOS在越獄後，會預設安裝一個名叫mobilesubstrate的動態庫，它的作用是提供一個系統級的入侵管道，所有的tweak都可以依賴它來進行開發，目前主流的開發工具有theos和iOSOpenDev，前者是採用makefile的一個編譯框架，後者提供了一套xcode專案模版，可以直接使用xcode開發可除錯，但是這個專案已經停止更新了，對高版本的xcode支援不好，大家酌情選擇（本文中的例子全部採用theos）
-
第二種是直接打包成ipa安裝包，並使用自己的開發證書或者企業證書籤名，不需越獄也可以安裝，可直接放到自己的網站上，可實現線上安裝；對於沒有越獄的手機，由於許可權的限制，我們是沒有辦法寫系統級的tweak的，例如springboard的補丁是沒法執行的，這種tweak大多是針對某個app，把目標app進行修改注入處理，再重新簽名和釋出，有點類似於windows軟體的xxx破解版、xxx免註冊版
沒有越獄的機器由於系統中沒有mobilesubstrate這個庫，我們有二個選擇，第一個是直接把這個庫打包進ipa當中，使用它的api實現注入，第二個是直接修改彙編程式碼；第一個適用於較為複雜的破解行為，而且越獄tweak程式碼可以複用，第二種適用於破解一些if…else…之類的條件語句
Mobilesubstrate
下面的圖展示的就是oc屆著名的method swizzling技術，他就是iOS的注入原理，類似於windows的鉤子，所以我們注入也稱為hook
Mobilesubstrate為了方便tweak開發，提供了三個重要的模組：
-
MobileHooker 就是用來做上面所說的這件事的，它定義一系列的巨集和函式，底層呼叫objc－runtime和fishhook來替換系統或者目標應用的函式
-
MobileLoader 用來在目標程式啟動時根據規則把指定目錄的第三方的動態庫載入進去，第三方的動態庫也就是我們寫的破解程式，他的原理下面會簡單講解一下
-
Safe mode 類似於windows的安全模式，比如我們寫的一些系統級的hook程式碼發生crash時，mobilesubstrate會自動進入安全模式，安全模式下，會禁用所有的第三方動態庫
app注入原理
上面講到了mobileloader，他是怎麼做到把第三方的lib注入進目標程式的呢？這個我們要從二進位制檔案的結構說起，從下面的圖來看，Mach-O檔案的資料主體可分為三大部分，分別是頭部（Header）、載入命令（Load commands）、和最終的資料（Data）。mobileloader會在目標程式啟動時，會根據指定的規則檢查指定目錄是否存在第三方庫，如果有，則會通過修改二進位制的loadCommands，來把自己注入進所有的app當中，然後載入第三方庫。
為了讓大家看的更清楚，下面我用machoview來開啟一個真實的二進位制檔案給大家看看，可以看出，二進位制當中所有引用到的動態庫都放在Load commands段當中，所以，通過給這個段增加記錄，就可以注入我們自己寫的動態庫了
那麼問題來了，在這裡插入我們自己的動態庫有什麼用？我們自己寫的程式碼沒有執行的入口，我們一樣沒發乾壞事，嗯，恭喜你問到點子上了，我們還需要一個”main”函式來執行我們自己的程式碼，這個”main”函式在oc裡面稱為建構函式，只要在函式前宣告 “attribute((constructor)) static” 即可，有了它我們就可以發揮想象力，進行偷天換日干點壞事了：
#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); }到這裡為止，我們已經知道了怎麼在目標程式注入自己的程式碼，那麼我們怎麼知道需要hook哪些方法？怎麼找到關鍵點進行實際的破解呢？下面講一下常見的app入侵分析方法
iOS逆向分析方法
逆向分析最常用的有三種方法：
-
網路分析
通過分析和篡改介面資料，可以有效的破解通過介面資料來控制客戶端行為的app，常用的抓包工具有Tcpdump, WireShark, Charles等，windows平臺有fidller -
靜態分析
通過砸殼、反彙編、classdump標頭檔案等技術來分析app行為，通過這種方式可以有效的分析出app實用的一些第三方庫，甚至分析出app的架構等內容，常用的工具有dumpdecrypted（砸殼）、hopper disassembler（反彙編）、class_dump（導標頭檔案） -
動態分析
有靜就有動，萬物都是相生相剋的，動態分析指的是通過分析app的執行時資料，來定位注入點或者獲取關鍵資料，常用的工具有cycript（執行時控制檯）、 lldb+debugserver（遠端斷點除錯）、logify（追蹤）
demo:微信搶紅包外掛
上面講了很多原理性的東西，相信大家已經看的不耐煩了，下面我們一起動點真格的，我們從頭開始，一步一步的做一個微信的自動搶紅包外掛，當然，網上可能已經有相關的開原始碼了，但是我這裡要講的是，這些程式碼是怎麼得出來的，我麼重點講一講分析過程
工欲善其事，必先利其器
一臺越獄的手機，並裝有以下軟體
- cycript
- dumpdecrypted
- debug server
- openssh
一臺蘋果電腦，並裝有以下軟體
- class_dump
- Theos
- Hopper Disassembler v3
- xcode
- insert_dylib
- pp助手
尋找注入點
砸殼
首先我們要做的就是把微信的殼砸掉，砸殼其實是為了把它的標頭檔案classdump出來，因為從appstore下載的app二進位制都是經過加密的，直接進行classdump操作是啥也看不出來的
-
-
用pp助手把dumpdecrypted.dylib檔案copy到微信的documents目錄
- ssh到手機的終端，cd到documents目錄中，執行下面的命令進行砸殼操作
xxx$ cp /usr/lib/dumpdecrypted.dylib /path/to/app/document xxx$ DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib /path/to/WeChat -
最後砸殼完成後會在documents目錄生成砸了殼後的二進位制檔案，用pp助手copy出來並class-dump他的標頭檔案備用
執行完這幾行命令後，會在微信的documents目錄生成一個WeChat.decrypted檔案，這就是砸殼後的二進位制檔案；當然了，這一步不是必須的，我們可以直接從91或者pp助手下載一個已經砸過殼的版本
動態分析－cycript
要想實現自動搶紅包，我們必須找到收到紅包訊息的handler方法，怎麼入手呢？我們先從介面出發，進入微信的訊息首發視窗:
-
ssh進手機的終端，輸入ps命令，查詢到微信的程式id
ps aux | grep WeChat -
祭起神器cycript，根據上一步找到的pid注入到微信的程式
cycript -p pidxxx -
在cycript的終端輸入這一串方法，作用就是列印出當前介面的view層級，（cycript還有很多妙用，大家可以上官網看文件，這裡不詳細介紹）
UIApp.keyWindow.recursiveDescription().toString()最終的輸出如下，內容太多，大家肯定看不清楚，不過沒關係，這個不是重點，這裡只是展示一下列印的結果形式：
我們可以隨機的選取一個節點不要太靠樹葉，也不要太靠樹根，例如我選的是標紅的部分，把這個節點的記憶體地址copy出來，這個記憶體地址，就代表了這個節點的view物件，ios開發的老油條們都知道，通過view的nextResponder方法，可以找出它所屬的檢視控制器ViewController，所以我麼在cycript的控制檯中持續輸入如下的命令：
看到沒有，通過四個nextResponder方法呼叫，我麼找到了當前聊天視窗的ViewController類名，他就是BaseMsgContentViewController，現在我們縮小了目標範圍，下面我們還需要繼續縮小範圍，要找到具體的訊息處理函式才行。
動態分析－Logify
要繼續縮小範圍，就得祭起神器Logify了，它是theos的一個模組，作用就是根據標頭檔案自動生成tweak，生成的tweak會在標頭檔案的所有方法中注入NSLog來列印方法的入參和出參，非常適合追蹤方法的呼叫和資料傳遞
現在我們根據此前砸殼後class_dump出來的標頭檔案，找到BaseMsgContentViewController在pc終端執行如下命令：
logify.pl /path/to/BaseMsgContentViewController.h > /out/to/Tweak.xm輸出的tweak檔案大概是這個樣子的：
這裡帶百分號的關鍵字，例如 %hook、%log、%orig 都是mobilesubstrate的MobileHooker模組提供的巨集，其實也就是把method swizzling相關的方法封裝成了各種巨集標記，使用起來更簡單，大家想要更深入瞭解各種標記，可以google一下logos語言
theos建立tweak
上面我們用logify生成了一個tweak程式碼，我們要把它安裝到手機上，首先需要使用theos進行編譯，安裝了theos之後，在pc終端輸入nic.pl：
首先選擇專案模版當然是tweak啦，然後是專案名稱、作者，後面兩個選項要注意：
-
首先是bundle filter，這個需要填你需要注入的目標app的bundle id，MobileLoader模組會根據它來尋找你的tweak的注入目標
-
最後是list id applications to terminate upon installation，這裡指定當tweak安裝成功之後，需要kill的程式，我們要hook微信，這裡就填微信的二進位制檔名就可以了，為什麼要kill？ 因為我麼的外掛是需要在app啟動時載入進去的，如果不重啟app，外掛是不會生效的
最後一切都完成後，在當前目錄會生成下列檔案：
把上面logify生成的tweak檔案覆蓋到當前目錄，並用文字編輯器開啟makefile檔案，在檔案的開頭增加你的ios裝置的ip地址和ssh埠：
最後在pc終端進入專案目錄，輸入 make package install 命令：
期間會讓你輸入裝置的ssh密碼，越獄機器的預設ssh密碼是alpine，make命令會生成deb安裝包，放在debs目錄，我們如果想對外發布自己的外掛，可以把生成的安裝包上傳到cydia即可
安裝成功後再次進入微信的聊天介面，並使用另外一個微信在群裡發個普通訊息，連線xcode開啟越獄機器控制檯，檢視輸出，會發現有類似下面的輸出：
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]看出來了吧，訊息處理函式是BaseMsgContentViewController的addMessageNode:layout:addMoreMsg:方法，大家可以看出，方法的引數內容也列印出來了
動態分析－lldb
到目前為止，我麼已經把範圍縮小到了具體的函式，看起來注入點已經找到了，但是請大家思考一下，如果我們在這個函式中注入搶紅包邏輯，那我們的tweak會不會有什麼致命的缺陷？
是的，因為BaseMsgContentViewController這個類是微信群聊天視窗對應的controller，我麼必須進入到群的聊天介面，這個類才會建立，如果不進入聊天視窗，我們的外掛就不生效了，而且，即使進入聊天視窗，也只是能自動槍當前群的紅包而已，其他群就無能為力了，是不是有點low？
所以為了使我們的外掛顯得上流一些，我麼還要繼續追根溯源，尋找訊息的源頭，這裡就用到了lldb遠端除錯，使用lldb打斷點的方式，通過呼叫棧，我們可以就可以看到當訊息來到時，方法的呼叫順序，找到最先執行的訊息處理函式。
要在剛剛追蹤到的addMessageNode:layout:addMoreMsg:方法中打斷點，首先我們得知道它在執行時的記憶體地址，那麼記憶體地址怎麼來呢？有這麼一個公式：
- 記憶體地址＝程式記憶體基地址＋函式在二進位制中的偏移量
首先偏移量我們可以通過反彙編工具hooper來查，在pc上用hooper開啟微信的二進位制檔案（注意，開啟時會讓你選擇armv7或者arm64，這需要根據你越獄手機的cpu型別來選，一定要和你的手機一致），hooper的介面非常簡潔，左側有個搜尋框，可以輸入函式名，直接找到函式在二進位制中的位置
通過左側的搜尋框搜addMessageNode關鍵字，找到它的偏移量是0x00000001017d7c6c：
找到了偏移量，還需要程式的基地址，這個地址需要連lldb，所以下面講一下如何連線lldb進行遠端除錯，先ssh進越獄手機的終端，在終端輸入如下命令（注意，你的手機必須連xcode除錯過才會有這個命令）：
debugserver *:19999 -a WeChat然後在pc端新起一個終端視窗，輸入如下命令來連線手機端進行除錯：
lldb -> process connect connect://deviceIP:19999如果連線成功，會進入lldb的控制檯，我們在lldb的控制檯輸入如下命令來獲取微信程式的基地址：
image list -o -f執行這個命令會列印很多行資料，像下面圖中這樣，我麼要找到微信的二進位制檔案所在的行，記錄它的記憶體地址0X00000000000E800：
到這裡我們兩個地址都找到了，再通過br命令打斷點：
br s -a '0X00000000000E800+0x00000001017d7c6c'打好斷點後繼續向群裡面發訊息，我們會發現程式被斷掉了，這時輸入bt指令，就可以看到當前的呼叫棧，就像下圖這樣：
分析堆疊的時候，重點找出模組時WeChat的項，這些都是微信模組的方法呼叫，有了堆疊，我們需要根據堆疊的記憶體地址找出它的具體函式名，思路還是先根據上面講到的公式來計算出棧地址在二進位制中的偏移量，然後用hooper找到偏移量對應的函式名
- 函式在二進位制中的偏移量＝記憶體地址 - 程式記憶體基地址
例如根據箭頭所指的記憶體地址和剛剛得到的程式基地址，計算偏移量：
0x0000000101ad02f4 – 0x00000000000e8000 = 1019E82F4然後在hooper中搜尋這個地址，得到結果如下：
最終把所有的棧都進行還原，得出呼叫棧是這個樣子的：
-[CMessageMgr MainThreadNotifyToExt:]: –> -[BaseMsgContentLogicController OnAddMsg:MsgWrap:]: ——> -[RoomContentLogicController DidAddMsg:] ———-> -[BaseMsgContentLogicController DidAddMsg:] —————-> -[BaseMsgContentViewController addMessageNode:layout:addMoreMsg:]:CMessageMgr這個類浮出水面了，是時候發揮黑客的嗅覺了，根據方法名我們能判斷出MainThreadNotifyToExt:這個方法僅僅是用來傳送通知的，如果hook這個方法，我們是拿不到訊息內容的
由於這裡可能是一個非同步呼叫，用斷點的方式，可能已經列印不出來棧資訊了，所以還得使用logify來繼續追蹤CMessageMgr這個類，講過的內容我就不重複了，直接得到最終的訊息處理函式：
-(void)AsyncOnAddMsg:(id)message MsgWrap:(CMessageWrap* )msgWrap
實現“搶”的動作
上一節我們已經找到了hook的關鍵點，那麼該如何去實現搶的動作？同樣我們需要結合動態分析和靜態分析，首先得到紅包訊息體的資料特徵，然後再分析處理訊息的關鍵點
資料包分析
首先我們的程式碼需要分辨哪些才是紅包訊息，方法很簡單，用logify追蹤BaseMsgContentViewController，然後向微信群發一個紅包，觀察手機日誌輸出，我們可以看出訊息的資料結構中有個type欄位，值是49，這個type應該就是標記訊息型別的，如果不確定，可以再發個圖片或者文字之類的訊息，這個值是不同的：
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]
現在我們能分辨訊息型別了，重點來了，怎麼實現搶這個事呢，可能聰明人已經猜到了，從ui入手，先找到微信本身的搶紅包函式，我們自己來給它構造引數並呼叫他不就行了？
把紅包點開後，用cycript列印出當前view的層次，就像下面這個，一眼就可以看到重點，WCRedEnvelopesReceiveHomeView就是開紅包彈框的類名
知道類名後，用cycript追蹤它，點選開紅包，在日誌中找到了下圖中的內容，從名字來看，這是一個事件處理函式，我們現在要做的，就是把他還原成oc程式碼，真正實現搶紅包功能
Administratorde-iPhone WeChat[91173] <Notice>: [1;36m[WxMsgPreview] [m[0;36mTweak.xm:8[m [0;30;46mDEBUG:[m -[<WCRedEnvelopesReceiveHomeView: 0x13cdda8c0> OnOpenRedEnvelopes]
靜態分析法
怎麼把他還原成oc程式碼，真正實現搶紅包功能呢？還得藉助一點點彙編技能，只是一點點而已，因為現在的反彙編工具已經很強大了，我們不需要挨個去看暫存器了
在pc上用hooper開啟微信的二進位制檔案，搜尋OnOpenRedEnvelopes，檢視彙編程式碼，注意在圖片中最後一行呼叫了一個WCRedEnvelopesReceiveHomeViewOpenRedEnvelopes函式
繼續搜尋WCRedEnvelopesReceiveHomeViewOpenRedEnvelopes這個方法，找到它的彙編程式碼
- 首先他不知道從哪裡獲取了一個payinfoitem
- 然後又獲取了payinfo的m_c2cNativeUrl屬性
-
然後呼叫substringfromindex吧navtiveurl的字首截斷，並呼叫bizutil的一個方法把url引數轉換成了一個字典
最終反解出的程式碼如下，是不是很簡單？
NSString *nativeUrl = [[msgWrap m_oWCPayInfoItem] m_c2cNativeUrl]; nativeUrl = [nativeUrl substringFromIndex:[@"wxpay://c2cbizmessagehandler/hongbao/receivehongbao?" length]]; NSDictionary *nativeUrlDict = [%c(WCBizUtil) dictionaryWithDecodedComponets:nativeUrl separator:@"&"];
繼續往下看, 在這裡前面三行建立了一個mutable dictionary：
- 緊接著下面三個框框處都是呼叫了setobject：forkey：向裡面填東西，那填的東西是啥呢？
-
其實這裡已經可以看的很清楚了，第一個key是msgtype，值是字串1，第二個sendid，值是呼叫了一個objectforkey從另一個字典中取出來的，很顯然，另一個字典就是上面從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"];
繼續往下看從箭頭所指的幾處，我們可以看見，它的程式碼是這樣的，共分為四步
- 第一個箭頭呼叫了mmservicecenter的defaultcenter方法來獲取mmservicecenter例項
- 第二個箭頭呼叫了CContactMgr的class方法
- 第三個箭頭呼叫了第一步獲取的mmservicecenter例項的getservice方法，而這個方法是把第二步得到的class作為引數
-
第四個箭頭很明白了吧，第三步得到了CContactMgr例項，這裡就是呼叫CContactMgr例項的getselfcontact方法獲取自己的賬戶資料
最終還原的到的程式碼如下：
CContactMgr *contactManager = [[%c(MMServiceCenter) defaultCenter] getService:[%c(CContactMgr) class]]; CContact *selfContact = [contactManager getSelfContact];
繼續往下看，這裡使用剛剛得到的selfcontact來獲取displayname和headimgurl，並把它們設定到剛剛的字典裡面了，key分別是nickname和headimg
最終的程式碼：
[args setObject:[selfContact getContactDisplayName] forKey:@"nickName"];
[args setObject:[selfContact m_nsHeadImgUrl] forKey:@"headImg"];
接著看，接下來這兩段就比較蛋疼了，完全是從記憶體地址裡面取的值，我也不知道他從哪裡來，怎麼辦呢？有沒有不懂彙編就能搞定它的捷徑呢，答案是有！
- 對於第一個，我可以通過它的key猜出來，還記得最開始的時候我們取過payinfo的一個nativeurl屬性吧，我們姑且把他傳進去
-
對於第二個，我們可以猜測sessionUserName大概是會話名稱，也就是群名稱的意思，從哪裡取這個值呢？我們先把也設定成虛擬碼
最終的結果如下：
[args setObject:nativeUrl forKey:@"nativeUrl"]; [args setObject:xxx forKey:@"sessionUserName"];
繼續往下看，接下來這一段還是用mmservicecenter來獲取WCRedLogicMgr物件，然後呼叫WCRedLogicMgr的open方法來拆紅包，可以想象open方法的引數就是上面我們辛苦組裝的字典
程式碼如下：
[[[%c(MMServiceCenter) defaultCenter] getService:[%c(WCRedEnvelopesLogicMgr) class]] OpenRedEnvelopesRequest:args];
領紅包邏輯
到這裡，我們再總結一下我們上面分析的過程……
- 得到m_oWCPayInfoItem屬性
- 解析m_oWCPayInfoItem的m_c2cNativeUrl屬性
- 得到selfcontact
- 組裝相關引數
-
呼叫OpenRedEnvelopesRequest:領取紅包
最終的搶紅包程式碼合併起來如下：
#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剛才說了，有兩個疑難點沒有解決:
-
第一：我們不知道payinfo是哪裡來的，
-
第二：sessionusername我們也不知道是哪裡來的
這時候我們可以從我們注入點的引數入手，首先用logify列印出addmsg方法的引數資訊，會發現，它的第二個引數剛好有一個payinfo的屬性，這樣第一個問題迎刃而解了
第二個我們已經猜測到它代表群名稱，所以我們從修改幾次群名稱，然後再觀察logify列印出的引數值的變化，就可以確認出從哪裡取了
通過一番折騰，得出了搶紅包的核心程式碼，再結合上面章節所講的theos製作tweak包的方法，打包並安裝到手機，發個紅包試試，是不是秒搶？
免越獄外掛
檢查依賴項
如果裝置沒有越獄，是沒有mobilesubstrate等環境的，而且一些系統目錄是沒有讀寫許可權的，這時我麼只能從目標app的二進位制檔案入手，通過手動修改load commands來載入自己的dylib，那麼上面我們的外掛又是使用theos基於mobilesubstrate編譯的，有沒有辦法確定我們的dylib有沒有依賴其他的庫呢？
使用osx自帶的otool工具即可，可以看出，我們的lib是依賴於substrate庫的，其他的都是系統庫，所以我們從越獄裝置中把cydiasubstrate檔案copy出來重新命名為libsunstrate.dylib，和我們的dylib一起放入wechat.app目錄中
最後使用install_name_tool命令修改動態庫的路徑把它指向app二進位制檔案的同級目錄
製作安裝包
解決了依賴問題，然後要把我們的庫注入到二進位制weixin的二進位制檔案，這一步使用開源的insert_dylib即可 （@executable_path是一個環境變數，指的是二進位制檔案所在的路徑）
insert_dylib命令格式：
./insert_dylib 動態庫路徑 目標二進位制檔案
//注入動態庫
./insert_dylib @executable_path/wxmsgpreview.dylib WeChat
//打包成ipa
xcrun -sdk iphoneos PackageApplication -v WeChat.app -o ~/WeChat.ipa
最後使用用企業證書或者開發證書籤名對ipa重新簽名，就可以放到自己的渠道進行釋出了！
結語
通過綜合運用各種工具，進行靜態和動態分析，我們通過實戰破解了微信的搶紅包邏輯，明白了入侵常用的工具，上面的搶紅包程式碼還有很多改進之處，比如沒有判斷紅包的傳送者是不是自己、也沒有判斷紅包裡面的文字是不是搶錯三倍，有興趣的童鞋可以嘗試優化一下！
更多精彩內容歡迎關注bugly的微信公眾賬號：
騰訊 Bugly是一款專為移動開發者打造的質量監控工具，幫助開發者快速，便捷的定位線上應用崩潰的情況以及解決方案。智慧合併功能幫助開發同學把每天上報的數千條 Crash 根據根因合併分類，每日日報會列出影響使用者數最多的崩潰，精準定位功能幫助開發同學定位到出問題的程式碼行，實時上報可以在釋出後快速的瞭解應用的質量情況，適配最新的 iOS, Android 官方作業系統，鵝廠的工程師都在使用，快來加入我們吧！