當Frida來「敲」門

0x1 滲透測試瓶頸

目前，碰到越來越多的大客戶都會將核心資產業務集中在統一的APP上，或者對自己比較重要的APP，如自己的主業務，辦公APP進行加殼，流量加密，投入了很多精力在移動端的防護上。

而現在挖漏洞除了拿到shell以外，客戶又要求可以儘可能的挖到核心業務系統的漏洞，並將漏洞範圍訂在主域名，核心業務系統現在又基本集中在移動端，移動端現在都會進行APP加殼，流量加密。這就導致無法進行平常滲透測試過程，像老生常談的中間人攻擊，進行攔截，篡改數據包就很難進行。

接下來就嘗試解決中間人攻擊的問題，目標是

1.看到明文的request和response的數據包；

2.做到可以攔截，篡改數據包。

0x2 frida

frida是平臺原生app的Greasemonkey，說的專業一點，就是一種動態插樁工具，可以插入一些代碼到原生app的內存空間去,（動態地監視和修改其行為），這些原生平臺可以是Win、Mac、Linux、Android或者iOS。而且frida還是開源的。

環境需要越獄的IOS或者ROOT的Android。安裝的版本需要一致

MAC：

越獄Iphone：

通過USB連結越獄手機，可以執行frida-ps -aU 就代表環境安裝成功

0x3 越獄檢測繞過

啟動目標APP時，APP自身會進行環境檢測，如果處于越獄環境會提示如下：

點擊「我知道了」就直接退出APP。

所以先嘗試先繞過第一步越獄環境檢測。可以先嘗試搜索包含「jail,jeil,jb,break"關鍵字的函數

關於函數追蹤可以使用frida-trace，如：

# Trace recv* and send* APIs in Safari$ frida-trace -i "recv*" -i "send*" Safari# Trace ObjC method calls in Safari$ frida-trace -m "-[NSView drawRect:]" Safari​# Launch SnapChat on your iPhone and trace crypto API calls$ frida-trace -U -f com.toyopagroup.picaboo -I "libcommonCrypto*"

burp的插件brida也支持對函數名進行檢索hook，和"Jail"相關的越獄檢測函數如下：

**** Result of the search of JailOBJC: +[BLYDevice isJailBreak]OBJC: +[IFlySystemInfo isJailbroken]OBJC: +[UIScreen _shouldDisableJail]OBJC: +[UIStatusBarWindow isIncludedInClassicJail]OBJC: -[_UIHostedWindow _isConstrainedByScreenJail]OBJC: -[_UIRootWindow _isConstrainedByScreenJail]OBJC: -[_UISnapshotWindow _isConstrainedByScreenJail]OBJC: -[BLYDevice isJailbroken]OBJC: -[BLYDevice setJailbrokenStatus:]OBJC: -[RCCountly isJailbroken]OBJC: -[UIClassicWindow _isConstrainedByScreenJail]OBJC: -[UIDevice isJailbroken]OBJC: -[UIStatusBarWindow _isConstrainedByScreenJail]OBJC: -[UITextEffectsWindowHosted _isConstrainedByScreenJail]OBJC: -[UIWindow _clampPointToScreenJail:]OBJC: -[UIWindow _isConstrainedByScreenJail]

想將目標定在「OBJC: +[BLYDevice isJailBreak]」

frida啟動APP，並加載腳本的命令如下：

frida -U -f com.x.x -l js-scripts

js腳本編寫可以看官方文檔:https://frida.re/docs/javascript-api/

//hook傳入值，ObjC: args[0] = self, args[1] = selector, args[2-n] = arguments Interceptor.attach(myFunction.implementation, { onEnter: function(args) { var myString = new ObjC.Object(args[2]); console.log("String argument: " + myString.toString()); }});//hook返回值，Interceptor.attach(Module.getExportByName('libc.so', 'read'), { onEnter: function (args) { this.fileDescriptor = args[0].toInt32(); }, onLeave: function (retval) { if (retval.toInt32() > 0) { /* do something with this.fileDescriptor */ }}});

定義js腳本後，嘗試hook出「OBJC: +[BLYDevice isJailBreak]」的傳入值和返回值，

function hook_specific_method_of_class(className, funcName){ var hook = ObjC.classes[className][funcName]; Interceptor.attach(hook.implementation, { onEnter: function(args) { // args[0] is self // args[1] is selector (SEL "sendMessageWithText:") // args[2] holds the first function argument, an NSString console.log("\n\t[*] Class Name: " + className); console.log("[*] Method Name: " + funcName); //For viewing and manipulating arguments //console.log("\t[-] Value1: "+ObjC.Object(args[2])); //console.log("\t[-] Value2: "+(ObjC.Object(args[2])).toString()); console.log("\t[-]arg value "+args[2]); Interceptor.attach(hook.implementation, { onLeave: function(retval) { console.log("[*] Class Name: " + className); console.log("[*] Method Name: " + funcName); console.log("\t[-] Return Value: " + retval); }} ); } });}//Your class name and function name herehook_specific_method_of_class("BLYDevice", "- isJailbroken")

篡改後，發現未能繞過，可能不是這個函數做最終的邏輯判斷，想到竟然都彈窗提示了，和UI有關係。

那麼可能是「OBJC: -[UIDevice isJailbroken]這個類，最終構造繞過越獄檢測代碼如下：

if (ObjC.available){ try { var className = "UIDevice"; var funcName = "- isJailbroken"; var hook = eval('ObjC.classes.' + className + '["' + funcName + '"]');//目標類+方法 Interceptor.attach(hook.implementation, { onLeave: function(retval) { console.log("[*] Class Name: " + className); console.log("[*] Method Name: " + funcName); console.log("\t[-] Return Value: " + retval);//輸出原本的返回值 var newretval = ptr("0x0") retval.replace(newretval)//替換新的返回值 console.log("\t[-] New Return Value: " + newretval) }} ); } catch(err) { console.log("[!] Exception2: " + err.message); } }else{ console.log("Objective-C Runtime is not available!");}

執行結果如下：

成功繞過。

0x4 HOOK加解密函數

越獄檢測繞過後，進一步開始嘗試定位加解密的函數。

關於定位加解密函數這塊在Android可以嘗試使用traceview去分析追蹤函數。

https://developer.android.google.cn/studio/profile/traceview

IOS可以嘗試使用runtime去追蹤函數，uidump從界面按鈕入手，Nslog日誌等位置入手，或者直接找相關關鍵字的函數去入手。

例如crypt(decryot,encrypt),HTTP,Network,目標廠商的名字簡寫找不到，可以嘗試搜索NSString系統庫等。

這邊推薦一個大佬的GitHub項目。使用可以參考這個GitHub項目，非常好用，先用之前寫好的繞過越獄檢測的腳本啟動APP，這邊通過查找函數名找到對方關鍵的加解密函數「*encryptor」。

github項目：https://github.com/lyxhh/lxhToolHTTPDecrypt

hook此函數的所有方法，在點擊登錄按鈕後，觀察到有請求的數據包被當做參數傳入到-[XXEncryptor RSAEncrypt:]方法內，並返回了加密後的字符串。-[XXEncryptor setRSAPublicKey:]根據定義的方法名判斷應該是RSA公鑰信息。

其他方法則去處理了返回包。如-[XXEncrytor AESDecrypt:]方法，將服務端返回的加密欄位，使用AES對稱解密解密為明文。

之前我們在Hook請求包函數的時候發現明文的數據包裡面帶有aeskey，說明此處的邏輯應該是：

本地生成aeskey代入到request包->使用定義的RSA公鑰加密request->發送到服務端並解密request後->處理請求包內容，並使用AESkey加密Response返回到客戶端->客戶端在使用Aeskey解密服務端的Response包。

大概是這麼一個流程，事實也證明返回包確實可以使用hook到的aeskey進行解密。

後面的思路是hook[XXEncrytor AESDecrypt:]解密方法去解密請求包和返回包，返回包是可以解，但是突然想到請求包是RSA非對稱的，需要私鑰。想嘗試在客戶端找到RSA的私鑰或者RSA解密方法，結果也確實有RSADecrypt方法。

但是事實是，從頭到尾這個方法都沒有被使用過，沒有參數被傳入，也沒有返回值。所以想，可能本地不做請求包的解密。那麼調用他的函數解密返回包可行，但解密請求包不行。但是咱們之前是有Hook到明文的request,可以再request被傳入到-[XXEncryptor RSAEncrypt]方法前，先去修改arg。

具體操作方法可以參考lyxhh，將加密前的請求包轉入Burp後就可以實現篡改數據了。

lyxhh：https://github.com/lyxhh/lxhToolHTTPDecrypt

新手的話可以先用la0s的JS，先看看對方是不是使用了IOS統一封裝的Crypto庫,js腳本如下：

JS:https://la0s.github.io/2018/12/07/iOS_Crypto/

/ Intercept the CCCrypt call.Interceptor.attach(Module.findExportByName('libcommonCrypto.dylib', 'CCCrypt'), { onEnter: function (args) { // Save the arguments this.operation = args[0] this.CCAlgorithm = args[1] this.CCOptions = args[2] this.keyBytes = args[3] this.keyLength = args[4] this.ivBuffer = args[5] this.inBuffer = args[6] this.inLength = args[7] this.outBuffer = args[8] this.outLength = args[9] this.outCountPtr = args[10] console.log('CCCrypt(' + 'operation: ' + this.operation +', ' + 'CCAlgorithm: ' + this.CCAlgorithm +', ' + 'CCOptions: ' + this.CCOptions +', ' + 'keyBytes: ' + this.keyBytes +', ' + 'keyLength: ' + this.keyLength +', ' + 'ivBuffer: ' + this.ivBuffer +', ' + 'inBuffer: ' + this.inBuffer +', ' + 'inLength: ' + this.inLength +', ' + 'outBuffer: ' + this.outBuffer +', ' + 'outLength: ' + this.outLength +', ' + 'outCountPtr: ' + this.outCountPtr +')') if (this.operation == 0) { // Show the buffers here if this an encryption operation console.log("In buffer:") console.log(hexdump(ptr(this.inBuffer), { length: this.inLength.toInt32(), header: true, ansi: true })) console.log("Key: ") console.log(hexdump(ptr(this.keyBytes), { length: this.keyLength.toInt32(), header: true, ansi: true })) console.log("IV: ") console.log(hexdump(ptr(this.ivBuffer), { length: this.keyLength.toInt32(), header: true, ansi: true })) } }, onLeave: function (retVal) { if (this.operation == 1) { // Show the buffers here if this a decryption operation console.log("Out buffer:") console.log(hexdump(ptr(this.outBuffer), { length: Memory.readUInt(this.outCountPtr), header: true, ansi: true })) console.log("Key: ") console.log(hexdump(ptr(this.keyBytes), { length: this.keyLength.toInt32(), header: true, ansi: true })) console.log("IV: ") console.log(hexdump(ptr(this.ivBuffer), { length: this.keyLength.toInt32(), header: true, ansi: true })) } }})

如果只能hook到部分明文流量，再考慮去對方定義的函數裡去找關鍵的加密函數，如這個APP的關鍵的XXEncryptor類。