0x00 序

---

自從上一篇文章發了以後，參加烏雲眾測時發現小夥伴們真的提交了一些我所說的IOS低風險問題，真的是連一百塊都不留給我。但是我依然感到幸運，因為今天可以為IOS APP安全雜談寫個續集。

上一節我們主要說了三點：IOS APP本地檔案安全；HTTP/HTTPS下通訊資料安全性的思考；非安全從業者是中間人攻擊的重災區。這次我們將簡單的介紹一些方法和工具，來作為IOS APP安全測試的入門教程。由於本人能力有限，文章難免會有些錯誤，還望小夥伴們見諒。

0x01 卸下厚厚的偽裝

---

在我剛剛開始接觸IOS逆向分析的時候想要一口吃個胖子，我從AppStore上下載APP進行安裝後，找到其目錄下的可執行檔案，然後直接扔到了IDA中。結果可想而知，我看到了一坨不知所云的函式，那時我還一度懷疑過自己是不是真的適合做這一行。好在後來去除了浮躁的心態，知道我這麼一個瘦子是無法變成胖子的，從前人的勞動成果中學習到從AppStore上下載的軟體都是經過加密的，可執行檔案被加上了一層厚厚的殼，這節我們只做一件事情，就是將APP厚厚的偽裝去掉。之所以說是偽裝，是因為加了密的APP想要解密並不是什麼難事，不像Android下的APP加殼種類那麼多。目標APP蘇寧易付寶錢包（這是一個良心廠商，獎勵了白帽子好多購物卡，這裡的演示僅供學習毫無惡意）。

下面我們來解密AppStore上下載的APP，解密方法也有很多：使用clutch解密、使用dumpdecrypted解密、使用gdb除錯工具解密等。在網上還看到一個工具叫AppCrackr，據說這個軟體簡單暴力，但是由於其助長了盜版的氣焰，其核心功能被迫關閉。這裡我們就簡單的演示一下使用dumpdecrypted進行解密。

（1）獲取並編譯dumpdecrypted dumpdecrypted下載後將其解壓，首先檢視自己裝置的系統版本，因為dumpdecrypted需要使用與IOS版本相同的SDK版本進行編譯，在終端輸入：SDK=‘xcrun --sdk iphoneos --show-sdk-path’來指定SDK版本，如果你的Mac上沒有和手機匹配的SDK版本，那你就像我一樣，下載一箇舊版本的Xcode，然後指定該舊版本Xcode中的SDK即可。

這裡附上《IOS應用逆向工程》作者沙梓社編譯好的檔案地址。

如果你的SDK版本是7.0，那麼可以在終端中直接進入dumpdecrypted-master（就是剛剛你下載的那個檔案）目錄中使用make進行編譯，如果不是7.0，需要修改dumpdecrypted-master目錄中Makefile中的 GCC\_UNIVERSAL=$(GCC\_BASE) -arch armv7 -arch armv7s -arch arm64改為 GCC\_UNIVERSAL=$(GCC\_BASE) -arch armv7 -arch armv7s再將dumpdecrypted.c第76行的if (lc->cmd ==LC\_ENCRYPTION\_INFO || lc->cmd == LC\_ENCRYPTION\_INFO\_64）改成 if(lc->cmd == LC\_ENCRYPTION_INFO)，儲存。然後再進行編譯，目錄下會生成dumpdecrypted.dylib檔案。

（2）定位可執行檔案 使用PP助手將dumpdecrypted.dylib檔案直接複製到目標APP中的Documents資料夾中。

在Mac終端下使用SSH連線到手機（手機的SSH可以透過PP助手的工具開啟），然後手機端關閉其他所用應用開啟目標APP，在終端執行ps –e（需要安裝adv-cmds），此時可以輕鬆找到目標的可執行檔案。

（3）解密可執行檔案 得到了所有的資訊後我們就可以進行APP可執行檔案的解密了，用大家常用的說法就是砸殼，我們在終端執行如下命令：DYLD\_INSERT\_LIBRARIES=/var/mobile/Applications/3B447828-D3B9-4575-8DE9-9DB335091F43/Documents/dumpdecrypted.dylib /var/mobile/Applications/3B447828-D3B9-4575-8DE9-9DB335091F43/SNYifubao.app/SNYifubao

如果不報錯的話則代表解密成功，解密的檔案在你進行解密操作時的目錄下（由於我當時是在/var/root目錄下操作的，所以解密後的檔案就在/var/root目錄下）。

（4）當然如果你不想那麼費勁，可以直接到PP助手或者91助手下載APP，安裝後找到可執行檔案，這個可執行檔案就是已經解密了的，不過美中不足的是無法保證你下載的APP是最新的，也無法保證是否被惡意篡改了邏輯結構。

0x02 知己更要知彼

---

《Hacking and Securing ios Applications》中的第七章介紹說Objective-C是一種反射式語言，它可以在執行時檢視和修改自己的行為。反射機制執行程式將指令看成資料，也允許在執行的時候對自己進行修改。Objective-C執行時環境不僅可以讓一個程式建立和呼叫臨時的方法，還可以實時建立類和方法…說了這麼多，其實就是想告訴我們IOS的執行時環境是可以被操作的。但是問題來了，我們操作執行時應該有個前提，那就是你要對這個APP足夠了解。

（1）使用class-dump 在ios中，可執行檔案、動態連結庫檔案等都是使用了一種名為Mach-O檔案格式，它由三部分組成：頭部，一系列的載入指令，以及資料段。而class-dump就是利用Objective-C語言的runtime特性，將儲存在Mach-O檔案中的標頭檔案資訊提取出來，並生成對應的.h檔案。透過提取出的檔案，就可以大致知道閉源App程式架構。安裝後終端下輸入class-dump -S -s -H Desktop/SNYifubao -o Desktop/SNY/，其中Desktop/SNYifubao為之前解密的可執行檔案（SNYifubao. Decrypted去掉字尾），Desktop/SNY/為我將匯出.h檔案的位置。

（2）使用Hopper Disassembler 前面透過dump標頭檔案已經基本可以判斷哪些類裡有哪些方法，哪些方法是如何實現的，而Hopper Disassembler則更為強大，可以執行在Mac、Linux和Windows下的除錯、反彙編和反編譯的互動式工具。將上次解密的檔案使用Hopper Disassembler開啟，我們可以檢視某處的虛擬碼，可以檢視某處的邏輯結構，還可以直接修改APP的設計邏輯。

網際網路上還有更多該軟體的使用方法，我就不一一介紹了，當然你想徹底去分析一款IOS軟體，還需要更多地去學習和了解ARM彙編相關的IOS逆向理論。而我在0x04小節中的（2）中就可以使用該方法為APP打補丁來繞過SSL認證。

0x03 洛陽鏟和屠龍刀

---

其實上一節中說的那些工具和方法只是冰山一角，還有很多工具是在我們身陷囹囫時可以助我們一臂之力的。例如使用Reveal來分析APP的UI佈局，使用Theos工具包開發越獄外掛，使用Cycript操作執行時等。在《ios應用逆向工程》中作者更是將LLDB比喻成屠龍寶刀，IDA比喻成倚天劍（雖然我認為Hopper Disassembler更牛一些）。但是我想說的是，還有很多並不起眼的東西卻在無形中幫了我們大忙，記得微信剛出飛機大戰遊戲的時候，有一款叫做“八門神器”軟體幫了很多人上了朋友圈的遊戲榜首。還有一款應用叫Flex，他可以讓我們繞過APP的某些限制，例如去掉影片軟體的廣告，去除影片網站的會員限制等等。我更習慣把這些軟體叫做洛陽鏟（可能是前段時間剛看完盜墓筆記的緣故），雖然是為作弊、破解而生，但是其卻可以證明某APP存在設計缺陷。此處我附上一張工具圖表（忘了是在哪裡看到的了，感謝作者）。

0x04 明修棧道暗度陳倉

---

最近在烏雲主站上有幾個小夥伴留言問我如何抓手機APP的通訊資料包，這個問題我想使用搜尋引擎就能找到非常好的答案。但是有時也會發現，有些資料我們是無法捕獲的，所謂明修棧道暗度陳倉，你看到的未必是對你有用的，這裡我分享一下出現這些問題的原因和解決方法。

（1）截獲幾種常見的通訊資料 HTTP：設定PC端，設定手機端，即可進行抓包和改包； HTTPS：設定PC端，設定手機端，手機端信任證書（分多種情況），即可進行抓包和改包； Socket：將IOS裝置線連到MAC上，使用rvictl命令讓IOS裝置上的網路流量經過MAC，啟動Wireshark監聽rvi介面上的資料。

（2）攔截HTTPS資料 HTTP的略過，我們說一下HTTPS吧，在測試了多家銀行和P2P金融公司的APP之後發現各個廠商對安全的重視程度不一，而對安全問題的響應速度也不一。在今年4月末時網爆流行IOS網路通訊庫AFNetworking SSL漏洞，影響銀聯、中國銀行、交通銀行在內的2.5萬個IOS應用，而在後面的兩個月內筆者發現銀行已經修復此類問題。其實如果APP在開發時就嚴格的按照SSL認證過程進行設計的話，APP的通訊資料還是非常安全的。（AFNetworking SSL漏洞檢測地址）。

情況一：信任任何證書。這種情況IOS的APP可以信任任何證書，所以開啟safari瀏覽器在位址列上手動輸入burp或者fiddler所在PC端的IP地址加上自己設定的埠號，burp點選CA Certificate安裝證書，fiddler點選FiddlerRoot certificate安裝證書，此時就可以抓取到該APP的HTTPS資料。出現這種情況的原因很有可能是使用的開源通訊庫存在缺陷，還有就是開發人員在開發過程中未連線生產環境的伺服器，為解決認證過程中證書報錯的問題只能暫時修改程式碼使其APP信任任意證書，而在上線前未對此程式碼進行處理。

情況二：信任證書管理機構（CA）頒發的證書。這種情況IOS的APP可以信任任何CA頒發的證書，據說這類的證書只需50美元就能買到。此類問題出在AFNetworking 2.5.2及之前的版本，也就是說如果某IOS APP使用了此版本的開源通訊庫，在不安全Wifi網路中的駭客、VPN網路中的職工或者國家支援的駭客，只要使用CA頒發的證書就可以對該APP的HTTPS加密資料進行監聽或者篡改。

情況三：信任合法的證書。這種情況IOS的APP只信任對自己而言合法的證書，首先我們看一下SSL認證的原理的前三步：① 客戶端向伺服器傳送客戶端SSL協議的版本號，加密演算法的種類，產生的隨機數，以及其他伺服器和客戶端之間通訊所需要的各種資訊。② 伺服器向客戶端傳送SSL協議的版本號，加密演算法的種類，隨機數以及其他相關資訊，同時伺服器還將向客戶端傳送自己的證書。③ 客戶利用服務端傳過來的資訊驗證伺服器的合法性，伺服器的合法性包括：證書是否過期，發行伺服器證書的CA是否可靠，發行者證書的公鑰能否正確解開伺服器證書的“發行者的數字簽名”，伺服器證書上的域名是否和伺服器的實際域名相匹配。如果合法性驗證沒有透過，通訊將斷開；如果合法性驗證透過，將繼續進行下一步。那麼如何讓IOS的APP信任非法的證書呢，看上文說到的第③步，我們只需要做到在合法性驗證的時候能夠欺騙APP，通訊就不會中斷。

這裡我附上一篇絕對有乾貨的文章，裡邊詳細描述瞭如何才能讓IOS信任任何證書的方法：Bypassing OpenSSL Certificate Pinning in iOS Apps。文章使用了兩種方法，第一種是使用Cycript或者Cydia Substrate來hook證書驗證函式，第二種是透過對目標APP的逆向分析，製作程式的二進位制補丁來繞過證書的“Pinning”機制。

情況四：這種情況是採用了伺服器和客戶端雙向認證的措施，即客戶端在確認伺服器是否合法之後，伺服器也要確認客戶端是否是合法的（伺服器要求客戶傳送客戶自己的證書。收到後，伺服器驗證客戶的證書，如果沒有透過驗證，拒絕連線；如果透過驗證，伺服器獲得使用者的公鑰）。正是這個原因，我們在測試APP時會發現儘管我們信任了burp或者fiddler的證書，可是在進行登入操作時APP依然會顯示網路連線錯誤，此時服務端已經知道客戶端可能是非法的，然後拒絕連線。如果你是開發人員，想分析HTTPS流量也很簡單：使用burp匯入客戶端證書，此時burp就可以與伺服器正常的建立連線，你也可以正常的擷取到資料包了。

（4）獲取Sockets介面資料 記得有一次遇到一個奇怪的現象，明明已經截獲了某金融APP的HTTP資料包和HTTPS資料包，但是在我輸入登入密碼和交易密碼時發現burp上並沒有顯示有資料包透過，當時真是too young too simple，後來才知道wifi＋burp模式是無法獲取到socket通訊的，有時也無法獲取EDGE／3G的資料包。後來借鑑了前人的勞動成果，使用RVI（Remote Virtual Interface）＋Wireshark的模式進行資料包分析。

Mac下獲取並安裝Wireshark,但是此時Wireshark是無法啟動的，還需要安裝另一款軟體X11（XQuartz），安裝完成後我們將IOS裝置透過usb連線到Mac上，然後開啟終端輸入連線命令：rvictl －s ［IOS UDID］，斷開連線的命令為：rvictl －x ［IOS UDID］，其中的UDID（裝置標識）可以透過iTunes或PP助手等工具檢視。

連線成功後IOS的網路流量都會經過其所連線的Mac，並且IOS資料還是走自己的網路。而Mac會出現一個對應的虛擬網路介面，名字是rvi0（如果有多個裝置則累加，rvi1，rvi2…），啟動Wireshark，監聽rvi介面就可以監聽其資料了。

0x05 論持久戰

這篇文章貌似我說的很多很雜，因為工具和方法有很多，漸漸的連我自己都覺得文章沒有任何條理可言，還望讀者見諒。此小節之所以叫做論持久戰是因為學習安全非一朝一夕的事情，更何況由於IOS系統自身的原因導致其資料有些匱乏，所以很多是靠經驗的積累才能掌握的，逆向更是需要我們有耐心去鑽研和學習。在此感謝烏雲又給了我一次和小夥伴們一起學習的機會。