自從上一篇文章發了以后，參加烏云眾測時發現小伙伴們真的提交了一些我所說的IOS低風險問題，真的是連一百塊都不留給我。但是我依然感到幸運，因為今天可以為IOS APP安全雜談寫個續集。
上一節我們主要說了三點：IOS APP本地文件安全；HTTP/HTTPS下通信數據安全性的思考；非安全從業者是中間人攻擊的重災區。這次我們將簡單的介紹一些方法和工具，來作為IOS APP安全測試的入門教程。由于本人能力有限，文章難免會有些錯誤，還望小伙伴們見諒。
在我剛剛開始接觸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是最新的，也無法保證是否被惡意篡改了邏輯結構。
《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認證。
其實上一節中說的那些工具和方法只是冰山一角，還有很多工具是在我們身陷囹囫時可以助我們一臂之力的。例如使用Reveal來分析APP的UI布局，使用Theos工具包開發越獄插件，使用Cycript操作運行時等。在《ios應用逆向工程》中作者更是將LLDB比喻成屠龍寶刀，IDA比喻成倚天劍（雖然我認為Hopper Disassembler更牛一些）。但是我想說的是，還有很多并不起眼的東西卻在無形中幫了我們大忙，記得微信剛出飛機大戰游戲的時候，有一款叫做“八門神器”軟件幫了很多人上了朋友圈的游戲榜首。還有一款應用叫Flex，他可以讓我們繞過APP的某些限制，例如去掉視頻軟件的廣告，去除視頻網站的會員限制等等。我更習慣把這些軟件叫做洛陽鏟（可能是前段時間剛看完盜墓筆記的緣故），雖然是為作弊、破解而生，但是其卻可以證明某APP存在設計缺陷。此處我附上一張工具圖表（忘了是在哪里看到的了，感謝作者）。
最近在烏云主站上有幾個小伙伴留言問我如何抓手機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接口就可以監聽其數據了。
這篇文章貌似我說的很多很雜，因為工具和方法有很多，漸漸的連我自己都覺得文章沒有任何條理可言，還望讀者見諒。此小節之所以叫做論持久戰是因為學習安全非一朝一夕的事情，更何況由于IOS系統自身的原因導致其資料有些匱乏，所以很多是靠經驗的積累才能掌握的，逆向更是需要我們有耐心去鉆研和學習。在此感謝烏云又給了我一次和小伙伴們一起學習的機會。