[原创] 記一次對某韓遊的反反調試-Android安全-看雪安全社区

[原创] 記一次對某韓遊的反反調試

发表于: 2025-3-18 21:31 52885

[原创] 記一次對某韓遊的反反調試

ngiokweng

2025-3-18 21:31

52885

> 樣本：Y29tLndlbWFkZS5uaWdodGNyb3dz
>

## 前言

聊點題外話，最近在找工作，一家公司說要搞NP，我果斷拒絕，還有一家公司給了一道面試題，內容是分析一款外掛( 針對他們家遊戲的 )和實現一個有效的外掛功能。當我興致勃勃下載好遊戲後，打開apk的lib目錄一看，發現`libtprt.so`、`libtersafe2.so`的特徵就知道67了。

眾所周知這是tx的MTP，我自認水平有限是搞不定的了，但還是硬著頭皮分析了一下，主要想分析他的CRC檢測，找到了幾處CRC邏輯，但都不是主要的邏輯，直到最後看到疑似vm虛擬機的東西，感覺他的核心檢測邏輯可能是在vm裡？看之後有沒有機會再分析看看吧。

小小分析完`libtprt.so`後，道心破碎，於是打算找個簡單點的來玩玩，正好前段時間一位大佬分享了一個樣本，就決定是你的。這是個UE5遊戲，主要看看他的檢測邏輯。

## frida閃退分析

frida注入後過1s左右會直接閃退，打印加載的so，看到只有一個`libdxbase.so`是APP本身的，顯然檢測邏輯在裡面。

![](upload/attach/202503/946537_WHQS8VKD56FVUEA.webp)

將`libdxbase.so`拉入IDA，沒有報錯，即so大概率沒有加固。

然後習慣先看看init_array，沒有太大發現，但看到`decrypt1`明顯是字符串解密函數，先記下來。

![](upload/attach/202503/946537_YAS45TH37RX9EY7.webp)

hook `RegisterNatives`，看到動態注冊了4個函數，遂一hook看看調用了哪個。

注：記`d`函數為`reg_func_d`，其他如此類推。

```cpp
[RegisterNatives] java_class: com.xshield.da name: d sig: (Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;IIIIIIII)Ljava/lang/String; fnPtr: 0x7137359258  fnOffset: 0x7137359258 libdxbase.so!0x18258  callee: 0x713736543c libdxbase.so!JNI_OnLoad+0x15e0

[RegisterNatives] java_class: com.xshield.da name: o sig: (II)I fnPtr: 0x7137348228  fnOffset: 0x7137348228 libdxbase.so!0x7228  callee: 0x713736543c libdxbase.so!JNI_OnLoad+0x15e0

[RegisterNatives] java_class: com.xshield.da name: p sig: (II)Ljava/lang/String; fnPtr: 0x7137347e78  fnOffset: 0x7137347e78 libdxbase.so!0x6e78  callee: 0x713736543c libdxbase.so!JNI_OnLoad+0x15e0

[RegisterNatives] java_class: com.xshield.da name: q sig: (Landroid/content/Context;ILjava/lang/String;)Ljava/lang/String; fnPtr: 0x7137360d60  fnOffset: 0x7137360d60 libdxbase.so!0x1fd60  callee: 0x713736543c libdxbase.so!JNI_OnLoad+0x15e0
```

結果是調用了`reg_func_d`，但只有Enter而沒有Leave，因此檢測邏輯可能在`reg_func_d`中。

`reg_func_d`的邏輯有差不多2000行，懶得靜態一點一點分析了，直接動調看看是在哪裡crash的。

### 虛假的time diff

crash的位置是在`exit_func(0xFFFFFFFE)`，而在調用`exit_func`前進行了一些time diff的操作，並根據time diff來決定是否走到`exit_func`那部份的邏輯。

![](upload/attach/202503/946537_Q33HPG86N4QR6FW.webp)

本以為上面只是個普通的time diff調試檢測，但frida hook `exit_func`並打印調用棧後發現是同一個地方，即frida hook時同樣會走到上述位置，然後調用`exit_func`閃退。

深入分析上圖那部份邏輯，發現一旦走到上圖那位置後，最終必然會走向`exit_func`。( 原因：`sub_8250`返回固定值、time diff永遠大於`v202` )。

```cpp
[exit_func] call in: 
7bb25dab70 is in libdxbase.so offset: 0x1ab70
7c1f940354 is in libart.so offset: 0x140354  
7c1f936470 is in libart.so offset: 0x136470
```

### 奇怪的time diff

從上圖位置向上尋找「生路」，看到`goto LABEL_215`，只要想辦法讓執行流進入任意一處`goto LABEL_215`的邏輯，就能避免走到上面那條「絕路」。

嘗試走紅框那裡的`goto LABEL_215`，條件1是`*(_DWORD *)(import_data + 9972)`為`0`，先嘗試滿足這條件。

![](upload/attach/202503/946537_R8NUUSNVEABDJYY.webp)

交叉引用找`(_DWORD *)(import_data + 9972)`賦值的地方，分析後可知`v197`是time diff，但具體是什麼東西之間的time diff，並不能從偽代碼裡直接看出。

![](upload/attach/202503/946537_KZHMV3NG7QPNMUQ.webp)

只能從匯編視圖看，上圖的`some_timestamp`是由`lstat`的`buf`( `x1` ) + `0x68`賦值。( `x0`為`/sbin` )

而且`[buf + 0x68]`的確是在調用`lstat`後才有值，但`buf`的結構為`struct stat`，大小似乎小於`0x68`，因此`buf[0x68]`正常來說並不屬於`struct stat`結構？猜測是內存對齊等原因導致的。

![](upload/attach/202503/946537_K63GPDQ77P9GVE3.webp)

從內存分佈可以看出`buf + 0x68`的位置應該是`struct stat`最後一個屬性( `struct stat`最後3個屬性都是時間 )，代表指定目錄`"上次狀態的更改時間"`。

![](upload/attach/202503/946537_DPS999GJB47B6SC.webp)

將`0x67517B0D`轉換下：

![](upload/attach/202503/946537_7CKG9Z2FNM3KVND.webp)

與`/sbin`的`ls -l`顯示的日期一致。

![](upload/attach/202503/946537_4VEAH62XZD8EM4K.webp)

用同樣方式找到time diff的另一個值，是`0x676631AB`。

![](upload/attach/202503/946537_FQD7RAM4A9MYBET.webp)

與`/system/lib`的`ls -l`顯示的日期一致。

![](upload/attach/202503/946537_N2RPDYQYYSTRD5Q.webp)

計算這兩個時間的time diff目的是什麼？

以下是普通Magisk環境的xiaomi手機，可以看到兩者的日期差很遠。

`sbin`的日期比較近是因為其中有個`shamiko`文件，大概是啟用/關閉shamiko模塊時都會刷新其日期。

![](upload/attach/202503/946537_TU2EX6PBUYVXQS6.webp)

而`/system/lib`的日期是一個超舊的時間。

![](upload/attach/202503/946537_4UEEYEV2JGQ9HXN.webp)

小結：這部份計算的time diff是`/system/lib`和`/sbin`之間的`"上次狀態的更改時間"` time diff，感覺這個time diff應該是在檢測Magisk之類的。

繼續向下看，判斷time diff是否大於0xF4240 sec，是則上述的條件1無法滿足。

0xF4240 sec → 277 hrs 46 min 40 sec，正常手機環境下的time diff應該不會大於這個值。

![](upload/attach/202503/946537_5PS233R6FEC8CZJ.webp)

bypass腳本：直接hook `lstat`。

```cpp
function hook_lstat() {
    let fake_time = Date.now();
    Interceptor.attach(Module.findExportByName(null, "lstat"), {
        onEnter: function(args) {
            this.name = args[0].readCString();
            this.statbuf = args[1];
        },
        onLeave: function(retval) {
            if (this.name == "/system/lib") {
                this.statbuf.add(0x68).writeU64(fake_time++);
                console.log("bypass lstat");
            }
            if (this.name == "/sbin") {
                this.statbuf.add(0x68).writeU64(fake_time++);
                console.log("bypass lstat");
            }
        }
    })
}
```

bypass這處time diff檢測後，Magisk環境的xiaomi手機依然會退出，大概是條件2`check1_res == 9 || !check1_res`沒有滿足。

![](upload/attach/202503/946537_5WKSRE3FVKDY6CG.webp)

### check1分析( root檢測 )

當`check1`返回`9`或`0`都能滿足條件2。接下來看看`check1`都檢測了什麼。

![](upload/attach/202503/946537_WMPHAPGHD8RGBNB.webp)

root檢測1：`popen("which su")`

![](upload/attach/202503/946537_5VY2PCK5VUDUPFF.webp)

root檢測2：獲取了一堆可能存在`su`的路徑，然後調用`check_exist_in_different_way`檢測指定路徑是否存在。

![](upload/attach/202503/946537_ZSYWQAEPRSKB4WN.webp)

`check_exist_in_different_way`內創建了`pthread_func2_check_path_exist`線程來處理。

![](upload/attach/202503/946537_WU3HZSACTU27ES7.webp)

其中用了以下方法來檢測傳入路徑是否存在：

`openat`、`syscall(__NR_openat)`、`scandir`、`lstat`、`stat`、`access`、`readlink`

![](upload/attach/202503/946537_R3HN3MQVKFUVJ7V.webp)

注：檢測的路徑大概有以下這些

```cpp
[decrypt1]  0x3a304 /system/bin/su
[decrypt1]  0x3a2f4 /system/xbin/su
[decrypt1]  0x3a313 /system/bin/.ext/.su
[decrypt1]  0x3a328 /system/xbin/.tmpsu
[decrypt1]  0x3a33c /vendor/bin/su
[decrypt1]  0x3a34b /sbin/su
[decrypt1]  0x3a354 /system/xbin/nosu
[decrypt1]  0x3a366 /system/bin/nosu
[decrypt1]  0x3a377 /system/xbin/su_bk
[decrypt1]  0x3a38a /system/bin/su_bk
[decrypt1]  0x3a39c /system/xbin/xsu
[decrypt1]  0x3a3ad /system/xbin/suu
[decrypt1]  0x3a3be /system/xbin/bstk/su
[decrypt1]  0x3a3d3 /system/RootTools/su
[decrypt1]  0x3a3e8 /data/data/bin/su
[decrypt1]  0x3a3fa /data/data/in/su
[decrypt1]  0x3a40b /data/data/n/bstk/su
[decrypt1]  0x3a420 /data/data/xbin/su
[decrypt1]  0x3a433 /res/su
[decrypt1]  0x3a43b /data/local/bin/su
[decrypt1]  0x3a44e /data/local/su
[decrypt1]  0x3a45d /data/local/xbin/su
[decrypt1]  0x3a471 /system/su
[decrypt1]  0x3a47c /data/su
[decrypt1]  0x3a485 /su/bin/su
[decrypt1]  0x3a490 /su/bin/sush
[decrypt1]  0x3a49d /system/bin/failsafe/su
[decrypt1]  0x3a4b5 /system/sbin/su
[decrypt1]  0x3a4c5 /system/sd/xbin/su
[decrypt1]  0x3a4d8 /system/xbin/noxsu
[decrypt1]  0x3a4eb /magisk/.core/bin/su
[decrypt1]  0x3a500 /sbin/.magisk
[decrypt1]  0x3a50e /sbin/.core
[decrypt1]  0x3b0c3 /system/usr/we-need-root/su
[decrypt1]  0x3b0df /cache/su
[decrypt1]  0x3b0e9 /dev/su
```

root檢測3：判斷fingerprint中是否包含`user-debug`、`eng/`、`Custom Phone`。

![](upload/attach/202503/946537_FBWEJNTA42TUPY5.webp)

對應的bypass腳本：

```cpp
function hook_popen() {
    Interceptor.attach(Module.findExportByName(null, "popen"), {
        onEnter: function(args) {
            if (args[0].readCString().indexOf(" su") != -1) {
                console.log("[popen] which su -> which xx");
                Memory.writeUtf8String(args[0], "which xx");
            }
        }
    })
}

// hook after dlopen libdxbase.so
function hook_pthread_func2() {
    Interceptor.attach(base.add(0x983C), {
        onEnter: function(args) {
            let check_path = args[0].readPointer().readCString();
            if (check_path.indexOf("/su") != -1) {
                Memory.writeUtf8String(args[0].readPointer(), check_path.replace("/su", "/XX"));

// console.log(`[pthread_func2]: ${check_path} -> ${args[0].readPointer().readCString()}`);
            }
            if (check_path.indexOf("magisk") != -1) {
                Memory.writeUtf8String(args[0].readPointer(), check_path.replace("magisk", "3Ag1sk"));

// console.log(`[pthread_func2]: ${check_path} -> ${args[0].readPointer().readCString()}`);
            }
            if (check_path.indexOf("/sbin") != -1) {
                Memory.writeUtf8String(args[0].readPointer(), check_path.replace("/sbin", "/ABCD"));

// console.log(`[pthread_func2]: ${check_path} -> ${args[0].readPointer().readCString()}`);
            }
            // console.log("[pthread_func2] check: ", check_path);
            this.a0 = args[0];
        }
    })
}
```

上述地方都bypass後，frida終於不再閃退，但畫面上仍顯示`ROOTED`。

而`j.rjshqqeirnhhbc.mq`其實是Magisk隨機的包名，代表其實是Magisk被檢測到。

![](upload/attach/202503/946537_NNKQFUTFSRSBTYA.webp)

## Magisk檢測分析

在bypass frida閃退後，hook `decrypt1`保存一份相對完整的解密字符串，用以配合分析，記為`decrypt_str.log`。

```cpp
function hook_decrypt1() {
    Interceptor.attach(base.add(0x5E84),{
        onEnter(args){
            this.a3 = args[3];
            this.len = args[4].toInt32();
            this.offset = this.a3.sub(base);
        },
        onLeave(retval){
            let dec_str = this.a3.readCString(this.len);
            console.log("[decrypt1] ", ptr(this.offset), dec_str);
        }
    })
}
```

### 回首Java層

再次hook那4個動態注冊的函數，會發現除了調用1次`reg_func_d`外，還不斷地在調用`reg_func_p`、`reg_func_q`，嘗試直接分析後2個函數，但沒有看出什麼。

改變思路，hook Java層的一些退出函數。

```cpp
function printStack(){
    console.log(Java.use("android.util.Log").getStackTraceString(Java.use("java.lang.Exception").$new()))
}
function hook_leave_java() {
    Java.perform(() => {
        let System = Java.use("java.lang.System");

System.exit.implementation = function() {
            console.log("exit....")
            printStack()
        }
    
        let Process = Java.use("android.os.Process");
    
        Process.killProcess.implementation = function() {
            console.log("killProcess....")
            printStack()
        }
    
    })
 
}
```

發現觸發了`System.exit`，調用棧如下，是由`com.xshield.x.run`類調用的。

```cpp
exit....
java.lang.Exception
        at java.lang.System.exit(Native Method)
        at com.xshield.x.run(dd.java:186)
        at java.lang.Thread.run(Thread.java:919)
```

Java層有混淆，用jeb打開可以默認去除一些簡單混淆( 如字符串混淆 )，方便分析。

從`com.xshield.x.run`向上跟到`call_exit_thread_xref2`函數，看到`"Scanrisk"`字符串本以為是相關邏輯，但hook後發現`v2 == 0`，因此根本不會走任意一處`"Scanrisk"`。

![](upload/attach/202503/946537_H3Y33E659XG4BXP.webp)

`call_exit_thread_xref2` → `u.call_exit_thread_xref1` → `exit`。

![](upload/attach/202503/946537_QV4PEEJ6VKUDVDE.webp)

嘗試直接讓`call_exit_thread_xref2`函數固定返回`1`，不走原本的邏輯。

結果是畫面不再顯示那個檢測介面，但過一段時間後同樣會退出，調用的是native層的`exit_func`。

```cpp
[exit_func] call in: 
7da42486a4 is in libdxbase.so offset: 0x86a4
7e96fb7894 is in libc.so offset: 0xe6894
7e96f55b70 is in libc.so offset: 0x84b70
```

由此猜測`call_exit_thread_xref2`只是構建那個檢測介面的邏輯，真正檢測的地方在另一處。

在`call_exit_thread_xref2`時機打印調用棧，繼續向上跟

```cpp
java.lang.Exception
        at com.xshield.da.IIiIiiIIII(Native Method)
        at com.xshield.da.IIiiiIIiIi(da.java:49)
        at com.xshield.k.run(da.java:103)
        at android.os.Handler.handleCallback(Handler.java:883)
        at android.os.Handler.dispatchMessage(Handler.java:100)
        at android.os.Looper.loop(Looper.java:224)
        at android.app.ActivityThread.main(ActivityThread.java:7520)
        at java.lang.reflect.Method.invoke(Native Method)
        at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:539)
        at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:950)
```

`com.xshield.k.run`如下，被檢測時走的是else分支，嘗試讓它走if分支。

結果同樣是畫面不再顯示那個檢測介面，但過一段時間後同樣會退出。因此還是要從native層入手。

注：`da.detectInfo`是我手動修改的名字。

![](upload/attach/202503/946537_8QKF3M3B6HWVX89.webp)

全局搜`detectInfo` ( 不要只按`x`找交叉引用，不太準 )，找到它是某次`reg_func_q`調用的返回值。

![](upload/attach/202503/946537_W6SJKDRSBG7SV6B.webp)

在其上方是一個`while`循環，根據特定的邏輯調用`da.q` ( 即`reg_func_q` )。

![](upload/attach/202503/946537_WCTUYNYR72JGAAF.webp)

hook `da.q`，看到某次的`result`果然是`detectInfo`。

同樣可以見到某次`reg_func_q`的參數是一堆包名，其中就包含`j.rjshqqeirnhhbc.mq`。

因此可以猜測Magisk的檢測邏輯為：Java層收集安裝APP的包名、路徑等信息 → 調用`da.q(ctx, 8, installed_app_info)`進行檢查 → 發現`j.rjshqqeirnhhbc.mq`的某些特徵 → 判斷是Magisk。

![](upload/attach/202503/946537_2P6DX7DG44S9CTT.webp)

根據猜測，嘗試置空`da.q`參數中的`j.rjshqqeirnhhbc.mq`，讓它不檢測`j.rjshqqeirnhhbc.mq`。

結果是APP不再顯示那個檢測介面，也不會自動退出，成功bypass掉Magisk檢測。

```cpp
function hook_reg_func_q() {
    let da = Java.use("com.xshield.da");
    da["q"].implementation = function (context, i, str) {
        // ;j.rjshqqeirnhhbc.mq;/data/app/j.rjshqqeirnhhbc.mq-YbP-hQjkQs0g9MZDz9dD0w==/base.apk;10205;tcp
        str = str.replace(";j.rjshqqeirnhhbc.mq;/data/app/j.rjshqqeirnhhbc.mq-YbP-hQjkQs0g9MZDz9dD0w==/base.apk;10205;tcp", "")
        console.log(`da.q is called: i=${i}, str=${str}`);
        let result = this["q"](context, i, str);
        console.log(`da.q result=${result}`);
        return result;
    };

}
```

由此確定了檢測邏輯的確是在`da.q(ctx, 8, installed_app_info)` ( 必須是`args[1]`為`8`的情況，才是進行上述檢測 )。

### native層：reg_func_q case 8分析

回到native層的`reg_func_q`分析檢測邏輯的具體實現，動調case 8的情況。

![](upload/attach/202503/946537_PX2T3PEBH3Y46H7.webp)

一開始先將傳入的`installed_app_info`寫入`cfdd35cd.dex`。

![](upload/attach/202503/946537_CQWWN5ZKNYMSSMK.webp)

其中的內容如下：

![](upload/attach/202503/946537_33538ZBJQQKW72E.webp)

最後會創建`reg_func_q_pthread1`線程，裡面才是真正檢測的地方。

![](upload/attach/202503/946537_9VTFTVWX8HYSE8Y.webp)

### reg_func_q_pthread1分析

不知什麼原因，動調時始終無法斷在`reg_func_q_pthread1`裡，因此只好通過hook和配合`decrypt_str.log`來進行分析( 主要依賴這兩者來確定執行流 )。

打開`XXX/base.apk` → fd反查( IO重定向檢測 ) → 解析`.apk`結構 → 獲取其`AndroidManifest.xml`。

![](upload/attach/202503/946537_TA3UMF5VHUNRHAR.webp)

判斷`AndroidManifest.xml`中，是否包含以下權限：

1. `UPDATE_PACKAGES_WITHOUT_USER_ACTION`
2. `QUERY_ALL_PACKAGES`
3. `FOREGROUND_SERVICE`
4. `REQUEST_INSTALL_PACKAGES`
5. `HIDE_OVERLAY_WINDOWS`

![](upload/attach/202503/946537_DXQAXQQGRYETRG7.webp)

而原版的Magisk正好包含上述的所有權限。

![](upload/attach/202503/946537_C2TDA5ZEM996NW9.webp)

僅憑權限來判斷，不會出現誤殺的情況？答案是會的，我在搜索相關資料時就發現有一堆用戶因被誤殺而在某論壇訴苦的情況，不過那時是21年，現在都25年了這問題應該也改善了不少。

可以看到它加了一些白名單來防止誤殺那些具有上述權限的正常APP。

![](upload/attach/202503/946537_Y2TYEZFXQUG6AKH.webp)

bypass腳本：hook `openat`，將`/data/app/j.rjshqqeirnhhbc.mq-YbP-hQjkQs0g9MZDz9dD0w==/base.apk`重定向為另一個正常apk。

注：這樣重向定不會被上述的fd反查檢測到，另一種`Interceptor.replace`才會。

```cpp
function hook_openat() {
    Interceptor.attach(Module.findExportByName(null, "openat"), {
        onEnter: function(args) {
            let path = args[1].readCString();
            if (path.indexOf("/data/app/j.rjshqqeirnhhbc") != -1 && path.indexOf("base.apk") != -1) {
                Memory.writeUtf8String(args[1], "/data/local/tmp/base.apk");
                console.log("[openat] bypass: ", path, args[1].readCString());
            }
            // Thread.backtrace(this.context, Backtracer.FUZZY).map(addr_in_so);

}
    })
}
```

上述腳本可以bypass Magisk檢測，但奇怪的是在`hook_openat`之後，即使下一次沒有`hook_openat`，依然不會再彈那個檢測介面，也不會退出。

連執行流也改變了，要重裝遊戲才會回復「正常」。感覺是該保護的一種BUG？不太確定。

## Debuggable檢測分析

改AOSP / 修改`AndroidManifest.xml`，這兩種賦予APP Debuggable權限的方法，都會被檢測到。

上次分析LIAPP時也有類似的檢測，那次沒分析明白，這次再來看看。

![](upload/attach/202503/946537_ETKMWRGPTRMVRKQ.webp)

注：在分析過程中發現`0xB11C`類似檢測處理函數，記為`mb_detect_handler`。

hook `mb_detect_handler`，在參數包含`AndroidManifest.xml`時打印調用棧。

看到相關邏輯在`0xb5bc`。

```cpp
[mb_detect_handler] 0x852 0x10000000 AndroidManifest.xml
LR: 0x7bb250b5bc
Function: 0xb5bc
moduleName: libdxbase.so

LR: 0x7ca37b6730
Function: _ZL15__pthread_startPv+0x28
moduleName: libc.so

LR: 0x7ca3757008
Function: __start_thread+0x44
moduleName: libc.so
```

記`0xb5bc`為`detected_APKMODE`，繼續向上跟，看到是由`g_APKMODE_flag1`和`g_APKMODE_flag2`決定是否創建`detected_APKMODE`線程的。

按`x`沒有看到`g_APKMODE_flag1`和`g_APKMODE_flag2`賦值的地方，嘗試使用frida的內存斷點，但沒什麼效果。

![](upload/attach/202503/946537_JWXYKG5CCVRTFCB.webp)

改用[這篇文章](https://bbs.kanxue.com/thread-278867.htm)自己實現的frida內存斷點，成功命中：

```cpp
// 用法: readwritebreak(base.add(0x3D700), 4, 1)
命中 : 0x7bb253e700  pc pointer :  0x7bb2519f0c
{"name":"libdxbase.so","base":"0x7bb2501000","size":258048,"path":"/data/app/com.wemade.nightcrows-3nZhg8hrtpfvU8YQT2BvZw==/lib/arm64/libdxbase.so"}
pc - - >  libdxbase.so  ->  0x18f0c
readwritebreak exit
```

去`libdxbase.so!0x18f0c`看看( 這裡位於`reg_func_d` )。

似乎`import_data + 9984`就是`g_APKMODE_flag1` ( 動調後發現的確如此 )，值來源是`a19`。

![](upload/attach/202503/946537_29ZXAPEW6S2DZWF.webp)

hook `reg_func_d`，在enter和leave時分別打印，的確是在leave時才有值，即`g_APKMODE_flag`都是在`reg_func_d`中賦值。

![](upload/attach/202503/946537_FMXCGQHUUB67T8U.webp)

而`a19`其實就是`reg_func_d`的`args[18]` ( 倒數第3個參數 )。

![](upload/attach/202503/946537_KJ4QBT5MCES9YTH.webp)

看Java層是怎樣傳值的，原來是`ApplicationInfo`的`flags`屬性。

![](upload/attach/202503/946537_3UV897Q5DQC3CH9.webp)

hook Java層的`reg_func_d`，去掉`FLAG_DEBUGGABLE`標誌。

結果是遊戲終於不再顯示`APKMOD`檢測介面，順利bypass它的Debuggable檢測。

```cpp
function hook_reg_func_d() {
    let da = Java.use("com.xshield.da");
    da["d"].implementation = function (str, str2, str3, str4, str5, str6, str7, str8, str9, str10, str11, i9, i10, i11, i12, i13, i14, i15, i16) {
        const FLAG_DEBUGGABLE = 0x2;
        i14 &= (~FLAG_DEBUGGABLE);
        console.log(`da.d is called: str=${str}, str2=${str2}, str3=${str3}, str4=${str4}, str5=${str5}, str6=${str6}, str7=${str7}, str8=${str8}, str9=${str9}, str10=${str10}, str11=${str11}, i9=${i9}, i10=${i10}, i11=${i11}, i12=${i12}, i13=${i13}, i14=${i14}, i15=${i15}, i16=${i16}`);
        let result = this["d"](str, str2, str3, str4, str5, str6, str7, str8, str9, str10, str11, i9, i10, i11, i12, i13, i14, i15, i16);
        console.log(`da.d result=${result}`);
        return result;
    };
}
```

## 完整bypass腳本

```cpp
function hook_dlopen(soName) {
    Interceptor.attach(Module.findExportByName(null, "dlopen"),
        {
            onEnter: function (args) {
                var pathptr = args[0];
                if (pathptr !== undefined && pathptr != null) {
                    var path = ptr(pathptr).readCString();
                    // console.log("[dlopen] ", path);
                    if (path.indexOf(soName) >= 0) {
                        this.is_can_hook = true;
                    }
                }
            },
            onLeave: function (retval) {
                if (this.is_can_hook) {
                    console.log("hook start...");
                    hook_func(soName)
                }
            }
        }
    );
 
    Interceptor.attach(Module.findExportByName(null, "android_dlopen_ext"),
        {
            onEnter: function (args) {
                var pathptr = args[0];
                if (pathptr !== undefined && pathptr != null) {
                    var path = ptr(pathptr).readCString();
                    // console.log("[android_dlopen_ext] ", path);
                    if (path.indexOf(soName) >= 0) {
                        this.is_can_hook = true;
                    }
                }
            },
            onLeave: function (retval) {
                if (this.is_can_hook) {
                    console.log("hook start...");
                    hook_func(soName)
                }
            }
        }
    );
}

function hook_popen() {
    Interceptor.attach(Module.findExportByName(null, "popen"), {
        onEnter: function(args) {
            if (args[0].readCString().indexOf(" su") != -1) {
                // bypass root check1
                console.log("[popen] which su -> which xx");
                Memory.writeUtf8String(args[0], "which xx");
            }
        }
    })
}

function printStack(){
    console.log(Java.use("android.util.Log").getStackTraceString(Java.use("java.lang.Exception").$new()))
}

}

function main() {
    hook_dlopen("libdxbase.so");
    hook_lstat();
    hook_popen();
    hook_java();
}

setImmediate(main)

```

## 結語

總的來說這個保護與之前分析的LIAPP差不多，都不難，只是比較麻煩。

( 各位有好玩的遊戲樣本也可以分享給我，有空會看看的^^ )

登录后可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最后于 2025-3-18 21:34 被ngiokweng编辑，原因：圖

#逆向分析

收藏・35

点赞・28

打赏

赞赏记录

参与人

雪币

留言

时间

铭信

你的帖子非常有用，感谢分享！

2026-9-7 21:55

doamzo

感谢你分享这么好的资源！

2026-6-25 08:49

carrys

谢谢你的细致分析，受益匪浅！

2026-6-12 10:23

mb_zfqvurgb

感谢你分享这么好的资源！

2025-10-1 17:37

berkedel

你的帖子非常有用，感谢分享！

2025-7-1 09:34

mb_spwfptaa

为你点赞！

2025-6-27 11:27

少姜

你的分享对大家帮助很大，非常感谢！

2025-5-10 17:22

方北七

谢谢你的细致分析，受益匪浅！

2025-4-28 18:09

by_Lin

期待更多优质内容的分享，论坛有你更精彩！

2025-4-23 15:09

P_Hac

谢谢你的细致分析，受益匪浅！

2025-4-9 19:42

养只猫不好么

这个讨论对我很有帮助，谢谢！

2025-4-7 14:31

xianyuuuan

感谢你分享这么好的资源！

2025-3-25 16:09

Aar0n

为你点赞！

2025-3-24 00:44

值得怀疑

感谢你分享这么好的资源！

2025-3-22 10:49

鱼木

谢谢你的细致分析，受益匪浅！

2025-3-21 11:07

墨穹呢

为你点赞！

2025-3-20 21:47

Shangwendada

+10

这个讨论对我很有帮助，谢谢！

2025-3-20 17:44

mb_vkwwpotw

感谢你的贡献，论坛因你而更加精彩！

2025-3-20 09:53

劫__

这个讨论对我很有帮助，谢谢！

2025-3-19 23:52

Our_OT

感谢你分享这么好的资源！

2025-3-19 20:20

陈可牛

这个讨论对我很有帮助，谢谢！

2025-3-19 18:02

SnowFox

感谢你的贡献，论坛因你而更加精彩！

2025-3-19 15:04

七星舞月

感谢你的贡献，论坛因你而更加精彩！

2025-3-19 11:29

.KK

期待更多优质内容的分享，论坛有你更精彩！

2025-3-19 10:10

逆天而行

感谢你的贡献，论坛因你而更加精彩！

2025-3-19 09:53

New对象处

+10

为你点赞！

2025-3-19 09:43

无事不觉

期待更多优质内容的分享，论坛有你更精彩！

2025-3-19 09:11

AL10000

这个讨论对我很有帮助，谢谢！

2025-3-18 22:09

最新回复 (48) 1 2 ▶
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 691 粉丝 7 关注私信	mb_ldbucrik 2 楼感谢分享 2025-3-18 22:09 0
AL10000 雪币： 1272 活跃值： (1820) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 56 粉丝 0 关注私信	AL10000 3 楼现在工作不好找哥们，有的做就不错了。 2025-3-18 22:15 0
安卓逆向test 雪币： 499 能力值： ( LV1，RANK：0 ) 在线值：发帖 10 回帖 47 粉丝 65 关注私信	安卓逆向test 4 楼 fairguard加固的游戏可以试一下，反注入也挺强的 2025-3-18 22:50 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 5 楼安卓逆向test fairguard加固的游戏可以试一下，反注入也挺强的有樣本嗎 2025-3-18 22:57 0
残月_374878 雪币： 0 活跃值： (616) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	残月_374878 6 楼真厉害啊，都看不懂 2025-3-19 08:39 0
New对象处雪币： 361 活跃值： (8070) 能力值： ( LV3，RANK：30 ) 在线值：发帖 6 回帖 182 粉丝 32 关注私信	New对象处 7 楼 ngiokweng 有樣本嗎[em_065] 游戏逆向这块工作不好找，前阵子遇到一个游戏，jp.gungho.bm，会释放子so来做检测，有点类似小红书的操作 2025-3-19 09:34 1
New对象处雪币： 361 活跃值： (8070) 能力值： ( LV3，RANK：30 ) 在线值：发帖 6 回帖 182 粉丝 32 关注私信	New对象处 8 楼好贴 2025-3-19 09:44 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 9 楼 New对象处游戏逆向这块工作不好找，前阵子遇到一个游戏，jp.gungho.bm，会释放子so来做检测，有点类似小红书的操作是的, 感覺逆向都不太好找, 感謝分享樣本 2025-3-19 09:59 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 10 楼 New对象处游戏逆向这块工作不好找，前阵子遇到一个游戏，jp.gungho.bm，会释放子so来做检测，有点类似小红书的操作 woc, 才發現之前研究過這家公司的另一款遊戲jp.gungho.padHT, 記得它有一個自定義的section, 還mmap了無數層, 分析了挺久的, 但沒看明白它的檢測邏輯, 大佬帶帶 2025-3-19 10:09 0
.KK 雪币： 4488 活跃值： (10810) 能力值： ( LV3，RANK：20 ) 在线值：发帖 6 回帖 63 粉丝 62 关注私信	.KK 11 楼 nb 一如既往的强~ 2025-3-19 10:12 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 12 楼 .KK nb 一如既往的强~ 不強 2025-3-19 10:16 0
安卓逆向test 雪币： 499 能力值： ( LV1，RANK：0 ) 在线值：发帖 10 回帖 47 粉丝 65 关注私信	安卓逆向test 13 楼 ngiokweng 有樣本嗎[em_065] 08eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6&6P5g2)9J5k6i4y4Z5K9i4W2#2k6g2)9J5k6h3y4G2L8g2)9J5c8X3@1`. 2025-3-19 10:56 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 14 楼安卓逆向test 006K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6&6P5g2)9J5k6i4y4Z5K9i4W2#2k6g2)9J5k6h3y4G2L8g2)9J5c8X3@1`. OK 2025-3-19 11:07 0
陈可牛雪币： 6559 活跃值： (6677) 能力值： ( LV5，RANK：76 ) 在线值：发帖 3 回帖 111 粉丝 37 关注私信	陈可牛 1 15 楼太强了 2025-3-19 18:08 0
mb_rjdrqvpa 雪币： 9064 活跃值： (10482) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 90 粉丝 3 关注私信	mb_rjdrqvpa 16 楼 ngiokweng woc, 才發現之前研究過這家公司的另一款遊戲jp.gungho.padHT, 記得它有一個自定義的section, 還mmap了無數層, 分析了挺久的, 但沒看明白它的檢測邏輯, 大佬帶帶[em_0 ... 你看一下WiFi万能钥匙，它从20年开始，核心so的文件结构就不正常，疑似采用了你说的保护 2025-3-19 19:49 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 17 楼 mb_rjdrqvpa 你看一下WiFi万能钥匙，它从20年开始，核心so的文件结构就不正常，疑似采用了你说的保护好, 有空看看 2025-3-19 20:38 0
mudebug 雪币： 12364 活跃值： (9905) 能力值： ( LV3，RANK：20 ) 在线值：发帖 10 回帖 334 粉丝 64 关注私信	mudebug 18 楼膜拜大佬 2025-3-19 22:03 0
mb_ripshzdx 雪币： 603 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 15 粉丝 0 关注私信	mb_ripshzdx 19 楼膜拜，非常厉害 2025-3-20 17:21 0
Shangwendada 雪币： 4336 活跃值： (5910) 能力值： ( LV12，RANK：260 ) 在线值：发帖 19 回帖 78 粉丝 223 关注私信	Shangwendada 4 20 楼唉，大佬啊 2025-3-20 17:46 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 21 楼 Shangwendada 唉，大佬啊佬, 為何唉聲嘆氣 2025-3-20 18:50 0
墨穹呢雪币： 4704 活跃值： (8122) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 224 粉丝 18 关注私信	墨穹呢 22 楼感谢分享 2025-3-20 21:47 0
Shangwendada 雪币： 4336 活跃值： (5910) 能力值： ( LV12，RANK：260 ) 在线值：发帖 19 回帖 78 粉丝 223 关注私信	Shangwendada 4 23 楼 ngiokweng 佬, 為何唉聲嘆氣[em_065] 叹气我太弱鸡哈哈 2025-3-21 11:19 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 24 楼 Shangwendada 叹气我太弱鸡哈哈唉, 太謙虛了佬 2025-3-21 12:47 0
mb_cbgtaveo 雪币： 292 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 253 粉丝 0 关注私信	mb_cbgtaveo 25 楼 666 2025-3-21 14:56 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

ngiokweng

发帖

172

回帖

280

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (48) 1 2 ▶
mb_ldbucrik 雪币： 6 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 691 粉丝 7 关注私信	mb_ldbucrik 2 楼感谢分享 2025-3-18 22:09 0
AL10000 雪币： 1272 活跃值： (1820) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 56 粉丝 0 关注私信	AL10000 3 楼现在工作不好找哥们，有的做就不错了。 2025-3-18 22:15 0
安卓逆向test 雪币： 499 能力值： ( LV1，RANK：0 ) 在线值：发帖 10 回帖 47 粉丝 65 关注私信	安卓逆向test 4 楼 fairguard加固的游戏可以试一下，反注入也挺强的 2025-3-18 22:50 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 5 楼安卓逆向test fairguard加固的游戏可以试一下，反注入也挺强的有樣本嗎 2025-3-18 22:57 0
残月_374878 雪币： 0 活跃值： (616) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 2 粉丝 0 关注私信	残月_374878 6 楼真厉害啊，都看不懂 2025-3-19 08:39 0
New对象处雪币： 361 活跃值： (8070) 能力值： ( LV3，RANK：30 ) 在线值：发帖 6 回帖 182 粉丝 32 关注私信	New对象处 7 楼 ngiokweng 有樣本嗎[em_065] 游戏逆向这块工作不好找，前阵子遇到一个游戏，jp.gungho.bm，会释放子so来做检测，有点类似小红书的操作 2025-3-19 09:34 1
New对象处雪币： 361 活跃值： (8070) 能力值： ( LV3，RANK：30 ) 在线值：发帖 6 回帖 182 粉丝 32 关注私信	New对象处 8 楼好贴 2025-3-19 09:44 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 9 楼 New对象处游戏逆向这块工作不好找，前阵子遇到一个游戏，jp.gungho.bm，会释放子so来做检测，有点类似小红书的操作是的, 感覺逆向都不太好找, 感謝分享樣本 2025-3-19 09:59 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 10 楼 New对象处游戏逆向这块工作不好找，前阵子遇到一个游戏，jp.gungho.bm，会释放子so来做检测，有点类似小红书的操作 woc, 才發現之前研究過這家公司的另一款遊戲jp.gungho.padHT, 記得它有一個自定義的section, 還mmap了無數層, 分析了挺久的, 但沒看明白它的檢測邏輯, 大佬帶帶 2025-3-19 10:09 0
.KK 雪币： 4488 活跃值： (10810) 能力值： ( LV3，RANK：20 ) 在线值：发帖 6 回帖 63 粉丝 62 关注私信	.KK 11 楼 nb 一如既往的强~ 2025-3-19 10:12 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 12 楼 .KK nb 一如既往的强~ 不強 2025-3-19 10:16 0
安卓逆向test 雪币： 499 能力值： ( LV1，RANK：0 ) 在线值：发帖 10 回帖 47 粉丝 65 关注私信	安卓逆向test 13 楼 ngiokweng 有樣本嗎[em_065] 08eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6&6P5g2)9J5k6i4y4Z5K9i4W2#2k6g2)9J5k6h3y4G2L8g2)9J5c8X3@1`. 2025-3-19 10:56 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 14 楼安卓逆向test 006K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6&6P5g2)9J5k6i4y4Z5K9i4W2#2k6g2)9J5k6h3y4G2L8g2)9J5c8X3@1`. OK 2025-3-19 11:07 0
陈可牛雪币： 6559 活跃值： (6677) 能力值： ( LV5，RANK：76 ) 在线值：发帖 3 回帖 111 粉丝 37 关注私信	陈可牛 1 15 楼太强了 2025-3-19 18:08 0
mb_rjdrqvpa 雪币： 9064 活跃值： (10482) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 90 粉丝 3 关注私信	mb_rjdrqvpa 16 楼 ngiokweng woc, 才發現之前研究過這家公司的另一款遊戲jp.gungho.padHT, 記得它有一個自定義的section, 還mmap了無數層, 分析了挺久的, 但沒看明白它的檢測邏輯, 大佬帶帶[em_0 ... 你看一下WiFi万能钥匙，它从20年开始，核心so的文件结构就不正常，疑似采用了你说的保护 2025-3-19 19:49 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 17 楼 mb_rjdrqvpa 你看一下WiFi万能钥匙，它从20年开始，核心so的文件结构就不正常，疑似采用了你说的保护好, 有空看看 2025-3-19 20:38 0
mudebug 雪币： 12364 活跃值： (9905) 能力值： ( LV3，RANK：20 ) 在线值：发帖 10 回帖 334 粉丝 64 关注私信	mudebug 18 楼膜拜大佬 2025-3-19 22:03 0
mb_ripshzdx 雪币： 603 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 15 粉丝 0 关注私信	mb_ripshzdx 19 楼膜拜，非常厉害 2025-3-20 17:21 0
Shangwendada 雪币： 4336 活跃值： (5910) 能力值： ( LV12，RANK：260 ) 在线值：发帖 19 回帖 78 粉丝 223 关注私信	Shangwendada 4 20 楼唉，大佬啊 2025-3-20 17:46 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 21 楼 Shangwendada 唉，大佬啊佬, 為何唉聲嘆氣 2025-3-20 18:50 0
墨穹呢雪币： 4704 活跃值： (8122) 能力值： ( LV3，RANK：20 ) 在线值：发帖 2 回帖 224 粉丝 18 关注私信	墨穹呢 22 楼感谢分享 2025-3-20 21:47 0
Shangwendada 雪币： 4336 活跃值： (5910) 能力值： ( LV12，RANK：260 ) 在线值：发帖 19 回帖 78 粉丝 223 关注私信	Shangwendada 4 23 楼 ngiokweng 佬, 為何唉聲嘆氣[em_065] 叹气我太弱鸡哈哈 2025-3-21 11:19 0
ngiokweng 雪币： 4000 活跃值： (7846) 能力值： ( LV12，RANK：280 ) 在线值：发帖 19 回帖 172 粉丝 297 关注私信	ngiokweng 5 24 楼 Shangwendada 叹气我太弱鸡哈哈唉, 太謙虛了佬 2025-3-21 12:47 0
mb_cbgtaveo 雪币： 292 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 253 粉丝 0 关注私信	mb_cbgtaveo 25 楼 666 2025-3-21 14:56 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复