前言

最近分析了一款外掛軟件的卡密校驗，過程挺有趣的，故記錄下來。

正文

該軟件的界面如下圖：

登錄卡密是該界面的一個按鈕，首先是獲取該界面的類名，如下：

該界面所在的類是com.app.batman.MainActivity，獲取到該界面所在的類之后，下一步的目標是定位到發送請求的方法，這一次我的定位方法不同于以往，以前我的定位方法是搜索字符串或者hook關鍵函數打印調用棧，這一次我所采用的方法是trace，那么什么是trace呢？hook了大量的函數就是trace，使用的腳本是r0trace(項目地址)。我trace了MainActivity類下的所有的函數，從而定位到SignUp這個關鍵函數，如下圖：

在jadx中反編譯的代碼如下：

該方法是一個native方法，所以要找到注冊該函數的so文件，首先我們假設它是動態注冊的，因此可以使用frida hook RegistNatives，這里使用yang神的腳本(項目地址)，運行結果如下：

發現找不到SignUp函數，那么該函數大概率是靜態注冊的，那么靜態注冊的方法該如何定位so文件呢？可以使用frida-trace，還需要注意，靜態注冊的函數命名是有規則的：Java_ + 包名 + 類名 + 方法名，并且".“都替換成”_"，運行結果如下：

可以看到，靜態注冊該函數的so文件是ban，命名很奇怪，在jadx中找到該so文件的加載位置，如下：

ban文件是經過System.load進行動態加載的，一般都是把該文件進行加密，然后在動態加載是進行解密，先把cache目錄下的ban文件放在IDA中看一眼，如下：

我采取的對抗手段是dump出內存中的ban文件，因為程序已經運行起來了，這時候內存中的ban文件是已經解密了的，frida dump腳本如下：

function dumpso(so_name){var libso = Process.findModuleByName(so_name);if (libso == null) {return -1;}Memory.protect(ptr(libso.base), libso.size, 'rwx');var libso_buffer = ptr(libso.base).readByteArray(libso.size);libso.buffer = libso_buffer;var f = new File("/data/data/com.tencent.tmgp.pubgmhd/cache/ban.so","wb")f.write(libso.buffer)f.flush()f.close()console.log("success dump ban.so")console.log("ban.so base address --> " + libso.base) } function main(){dumpso("ban") } setImmediate(main)

但這個時候的so是不能分析的，還需要修復一下，修復工具使用的是elf-dump-fix(項目地址)，把修復后的so文件放進IDA中進行反編譯，SignUp的偽代碼如下：

發現已經能夠正常識別了，下面就是找到發送請求的邏輯，關鍵代碼如下：

上面圖中標注的很清楚了，核心邏輯就是判斷響應體中的內容的長度是否為32，如果長度為32位，則卡密校驗成功，否則卡密校驗失敗。卡密校驗成功之后調用了MainActivity類下面的TOAC方法，下面看看該函數的邏輯：

代碼很簡單，就是開啟了一個服務，那么有沒有什么辦法看到服務開啟后的效果呢？很簡單，使用frida進行主動調用就行了，腳本代碼及運行效果如下：

在主動調用了TOAC方法之后，外掛的功能模板就彈出來了。那么我們只要修改登錄卡密之后的邏輯，讓其不論校驗成功還是校驗失敗都調用TOAC方法，這樣也就繞過了卡密的校驗，具體的過程不再展示。

修改并重打包之后，功能一切正常，但在點開繪制初始化開關之后軟件直接閃退了，因此可以判斷該軟件有簽名校驗。那么我判斷的依據是什么呢？很簡單，就是之前我使用frida進行主動調用過卡密校驗的時候軟件并沒有閃退，開關也能正常打開，但是在重打包之后打開開關就閃退。

下面開始繞過簽名校驗，首先嘗試在jadx中搜索signatures，如下:

直接根據包名進行過濾，在java層中并沒有我們想要的結果，那么在ban這個so文件里面進行搜索，如下：

可以看到，程序調用了android.content.pm.Signature類下的hashcode方法獲取了簽名的hash值，并且拿該值與一個特定的值進行比較，如果不相等則直接退出程序，因此這里就是簽名校驗的關鍵點。

既然找到了程序校驗簽名的邏輯，那么我們該如何繞過呢？起初我想的是直接修改so文件，把exit的調用直接nop掉，但是別忘了這個so文件是從內存中dump出來的，其原本的狀態是加密的，所以是沒辦法直接進行修改。那么就可以寫xposed模塊，去hook hashcode這個方法，讓其返回那個正確的hash值，這樣也能繞過檢驗。但是考慮到使用Xposed的環境要求比較苛刻，需要手機進行root，因此我也拋棄了這個方案。

其實即使不root也是能夠去hook的，這個方案也被許多知名的軟件應用了，比如太極、VirtualXposed、應用轉生等等，這也就是我采用的方案，我使用的AOP框架是epic(項目地址)，核心代碼如下：

然后把編譯好的dex文件添加進軟件中，并主動調用這段代碼也就實現了非root下的hook。

重打包后程序正常運行，至此逆向分析結束。

總結

以上是生活随笔為你收集整理的某直装外挂卡密校验逆向分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。