移動 App 入侵與逆向破解技術

如果您有耐心看完這篇文章，您將懂得如何著手進行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 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在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] : [1;36m[WxMsgPreview] [m[0;36mTweak.xm:308[m [0;30;46mDEBUG:[m -[ 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] : [1;36m[WxMsgPreview] [m[0;36mTweak.xm:308[m [0;30;46mDEBUG:[m -[ addMessageNode:{m_uiMesLocalID=16, m_ui64MesSvrID=1452438635530425509, m_nsFromUsr=1037957572@chatroom, m_nsToUsr=ccg*675~9, m_uiStatus=4, type=49, msgSource="03"}  layout:1 addMoreMsg:0]

現在我們能分辨消息類型了，重點來了，怎么實現搶這個事呢，可能聰明人已經猜到了，從ui入手，先找到微信本身的搶紅包函數，我們自己來給它構造參數并調用他不就行了？

把紅包點開后，用cycript打印出當前view的層次，就像下面這個，一眼就可以看到重點，WCRedEnvelopesReceiveHomeView就是開紅包彈框的類名?

?知道類名后，用cycript追蹤它，點擊開紅包，在日志中找到了下圖中的內容，從名字來看，這是一個事件處理函數，我們現在要做的，就是把他還原成oc代碼，真正實現搶紅包功能

Administratorde-iPhone WeChat[91173] : [1;36m[WxMsgPreview] [m[0;36mTweak.xm:8[m [0;30;46mDEBUG:[m -[ 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];}}
}

剛才說了，有兩個疑難點沒有解決: