某日遊mmap模塊化保護簡單分析

前言

前前後後大概分析了這樣本4次左右，前3次都以失敗告終，或許對於普通人來說，失敗才是人生的主旋律，接觸逆向後對這句話越來越有感觸。

本文主要分析的目標是frida/hook檢測。

閃退情況描述

frida hook後會立即閃退，hook dlopen後可知是在加載lib__6dba__.so時閃退，具體是在lib__6dba__.so的.init_array裡。而.init_array中只有一個start函數。

frida hook了一次之後，下次就算不hook正常打開APP也會閃退，大概率檢測了frida的maps特徵。

start分析

一開始會調用get_custom_scetion獲取lib__6dba__.so中的加密數據。

具體實現如下：

首先用openat、lseek、read等系統調用打開並讀取lib__6dba__.so，然後遍歷獲取最後一個loadable segment的結束地址，記為last_loadseg_end。

用010查看last_loadseg_end偏移指向的數據，可以看出明顯是一些高熵數據，記這些數據為enc_data。

繼續向下看，它又遍歷shdr table獲取自定義的一個section。

從010可以看出，該section同樣是指向上述last_loadseg_end那附近。

雖然不知為何要分別通過phdr和shdr來定位enc_data，但總的來說get_custom_scetion函數的功能就是獲取enc_data。

回到start函數，獲取完enc_data後，調用decrypt1和decrypt2來解密。

解密出來的數據其實是一些可執行的邏輯，由於它是通過mmap映射 + mprotect賦予可執行權限的方式來執行，因此記這種形式為mmap模塊，根據創建順序記為mmap1模塊、mmap2模塊、…，如此類推。frida的檢邏邏輯明顯就在其中。

注：該保護使用了大量的系統調用( 上述的mmap和mprotect都是指系統調用 )，一些基礎函數如strcpy、strlen、memset等都是自實現的。

hook & dump mmap模塊

一開始我選擇通過動調來分析上述的mmap1模塊，發現mmap1中會創建和調用mmap2、mmap3、mmap4模塊，同理mmap2 ~ 4模塊又分別會創建和調用更多的mmap模塊，如此一來使得動調難以分析( 最主要是因為在mmap模塊中記錄的注釋、重命名變量名、函數名等都無法持久地保存 )。

但動調也並非毫無收獲，可以得知以下幾點：

每個mmap模塊的結構是非常相似的( 動調後會明白這句話的意思 )。
每個mmap模塊的大部份函數實現是一樣的，如字符串解密函數。
每個mmap模塊都有封裝系統調用，因此可以很方便地hook。
每個mmap模塊創建&調用另一個mmap模塊的方法是一樣的，都是通過mmap + mprotect系統調用

由於難以動調，只好以純hook的方式來分析，在此之前要先將所有mmap模塊dump下來，遊戲閃退前創建的mmap模塊共有13個。

可以通過frida或qbdi等方式來dump和trace所有mmap模塊，dump文件記為mmap_<base>_<size>_<idx>.bin，trace文件記為log.txt( 主要記錄函數調用關系，用利用qbdi可以很方便實現 )。

然後按字節特徵來判斷mmap1 ~ mmap13，獲取分別的基址，以此進行hook。hook mmap1 ~ 4的例子如下所示。

let hooked = false;
let mmap_history = {}
function hook_func_init(soName) {
    if (hooked) return;
    hooked = true;

    function hook_syscall() {
        function is_mmap1 (addr) {
            let byte_arr = [
                0xF0, 0x7B, 0xBF, 0xA9, 0x30, 0x01, 0x00, 0xB0, 0x11, 0x86, 
                0x42, 0xF9, 0x10, 0x22, 0x14, 0x91, 0x20, 0x02, 0x1F, 0xD6
            ]
            let offset = 0x440;
            for(let i = 0; i < byte_arr.length; i++) {
                if (addr.add(offset).add(i).readU8() != byte_arr[i]) return false;
            }
            return true;
        }
        
        function hook_mmap1(mmap_base) {
            Interceptor.attach(mmap_base.add(0xF9B0), {
                onEnter: function(args) {
                    this.sysno = args[7];
                    this.a0 = args[0]
                    this.a1 = args[1]
                    this.a2 = args[2]
                },
                onLeave: function(retval) {
                    if (this.sysno == 0xde) {
                        // console.log("[hook_mmap1_syscall] mmap addr: ", retval, "size: ", this.a1, "prot: ", this.a2);
                        mmap_history[retval] = this.a1;
                    }
    
                    if (this.sysno == 0xe2) {
                        console.log("[hook_mmap1_syscall] mprotect addr: ", this.a0, "size: ", this.a1 ,"prot: ", this.a2);
                        if (mmap_history[this.a0]) {
                            console.log(`\t[hook_mmap1_syscall] mmap addr: ${this.a0}  size: ${mmap_history[this.a0]}`);
                        }
                        if (is_mmap2(this.a0)) {
                            hook_mmap2(this.a0);
                        }
                        if (is_mmap3(this.a0)) {
                            hook_mmap3(this.a0);
                        }
                        if (is_mmap4(this.a0)) {
                            hook_mmap4(this.a0);
                        }
                    }
                }
            })
        }

        Interceptor.attach(base.add(0x5C84), {
            onEnter: function(args) {
                // console.log("[svc] sysno: ", args[7]);
                this.sysno = args[7];
                this.a0 = args[0]
                this.a1 = args[1]
                this.a2 = args[2]
            },
            onLeave: function(retval) {
                if (this.sysno == 0xde) {
                    // console.log("mmap addr: ", retval, "size: ", this.a1, "prot: ", this.a2);
                    mmap_history[retval] = this.a1;
                }

                if (this.sysno == 0xe2) {
                    console.log("[syscall] mprotect addr: ", this.a0, "size: ", this.a1 ,"prot: ", this.a2);
                    if (mmap_history[this.a0]) {
                        console.log(`\t[syscall] mmap addr: ${this.a0}  size: ${mmap_history[this.a0]}`);
                    }
                    if (is_mmap1(this.a0)) {
                        hook_mmap1(this.a0);
                    }
                }
            }
        })
    }

    var base = Module.findBaseAddress(soName);
    console.log("[hook_func_init] base: ", base);

    hook_syscall();

}

mmap13模塊分析

閃退前的最後一個模塊是mmap13，大概率會包含檢測frida的邏輯，因此重點分析這個模塊。

基礎分析

先找到字符串解密函數，其特徵如下，返回值就是解密後的字符串：

hook輸出如下：

[hook_mmap13_decrypt_str] retval:  %s/lib
[hook_mmap13_decrypt_str] retval:  %s/lib
[hook_mmap13_decrypt_str] retval:  /lib
[hook_mmap13_decrypt_str] retval:  arm64
[hook_mmap13_decrypt_str] retval:  %s/%s
[hook_mmap13_decrypt_str] retval:  %s/%s
[hook_mmap13_decrypt_str] retval:  %s/%s
[hook_mmap13_decrypt_str] retval:  /proc/self/maps
[hook_mmap13_decrypt_str] retval:  %s/%s
[hook_mmap13_decrypt_str] retval:  %s/%s
[hook_mmap13_decrypt_str] retval:  %s/%s
[hook_mmap13_decrypt_str] retval:  %s/%s
[hook_mmap13_decrypt_str] retval:  %s/%s
[hook_mmap13_decrypt_str] retval:  %s/%s

比較可疑的是/proc/self/maps，打印調用棧發現在mmap13!0xF348，而該地址所在函數的交叉引用在0x4D28。

bl sub_F2E8所在地址是0x4D28，加上mmap13的基址是0x7AB2D21D28。

在log.txt裡搜0x7AB2D21D28找到對應地方查看函數調用關系，發現以下函數調用順序：

openat + lseek + read讀取了/proc/self/maps中的數據。
通過vsnprintf拼接了APP自身3個so庫的完整路徑，其中就包括lib__6dba__.so的完整路徑。

0x14043be0 (0x7ab2d2bbe0): sub_1404712c() {
    0x140470c4 (0x7ab2d2f0c4): sub_14047068() {
        0x14047080 (0x7ab2d2f080): [SVC] sysno(0x38) -> openat(-100, "/proc/self/maps") => fd: 0x27
    }
}
0x14043c1c (0x7ab2d2bc1c): sub_140439a0() {
    0x140439b4 (0x7ab2d2b9b4): sub_14045e70() {
    }
    0x140439d4 (0x7ab2d2b9d4): sub_1404709c() {
        0x140470c4 (0x7ab2d2f0c4): sub_14047068() {
            0x14047080 (0x7ab2d2f080): [SVC] sysno(0xde) -> mmap(0x0, 0x80000, 0x3) => mmap address: 0x7ab1660000
        }
    }
}
0x14043c40 (0x7ab2d2bc40): sub_14043a44() {
    0x14043aa8 (0x7ab2d2baa8): sub_1404709c() {
        0x140470c4 (0x7ab2d2f0c4): sub_14047068() {
            0x14047080 (0x7ab2d2f080): [SVC] sysno(0x3e) -> lseek
        }
    }
    0x14043ad4 (0x7ab2d2bad4): sub_1404709c() {
        0x140470c4 (0x7ab2d2f0c4): sub_14047068() {
            0x14047080 (0x7ab2d2f080): [SVC] sysno(0x3f) -> read(0x27, "12c00000-12c40000 rw-p 00000000 ", 0x80000) => real read bytes: 0xf96
        }
    }
    0x14043ad4 (0x7ab2d2bad4): sub_1404709c() {
        0x140470c4 (0x7ab2d2f0c4): sub_14047068() {
            0x14047080 (0x7ab2d2f080): [SVC] sysno(0x3f) -> read(0x27, "71124000-71125000 rw-p 0003d000 ", 0x7f06a) => real read bytes: 0xfb7
        }
    }
    
// ...

0x1403b658 (0x7ab2d23658): sub_14040bb8() {
    0x14040c48 (0x7ab2d28c48): sub_14040ab0() {
        0x14040af4 (0x7ab2d28af4): sub_14037590() {     // nglog: mmap13 => 0xBAF4
            0x14040af4 (0x7ab2d28af4): [ExternalCall] vsnprintf("/data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/lib__6dba__.so", 0x400, "%s/%s") => res: 0x4b
        }
		}
}

由此猜測可能是在檢查自身的so庫有沒有被hook。

嘗試hook mmap13的vsnprintf，將lib__6dba__.so替換為另一個沒被hook的庫libpad.so ( 這個庫也是APP本身的 )。

function hook_vsnprintf () {
    Interceptor.attach(mmap_base.add(0xBBB8), {
        onEnter: function (args) {
            this.a0 = args[0];
        },
        onLeave: function (retval) {
            if (this.a0.readCString().indexOf("lib__6dba__.so") != -1) {
                console.log("replace!!!!!!!!!!!!")
                Memory.writeUtf8String(this.a0, this.a0.readCString().replace("lib__6dba__.so", "libpad.so"))
            }
            console.log("[mmap13_vsnprintf] this.a0: ", this.a0.readCString());
        }
    })
}

替換前，vsnprintf的輸出如下：

[mmap13_vsnprintf] this.a0:  /data/user/0/jp.gungho.padHT/lib
[mmap13_vsnprintf] this.a0:  /data/user/0/jp.gungho.padHT/lib
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libopenal.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libpad.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/lib__6dba__.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libopenal.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libpad.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/lib__6dba__.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libopenal.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libpad.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/lib__6dba__.so

替換後，vsnprintf的輸出如下，可以看到多了兩行關於libc.so的日志

[mmap13_vsnprintf] this.a0:  /data/user/0/jp.gungho.padHT/lib
[mmap13_vsnprintf] this.a0:  /data/user/0/jp.gungho.padHT/lib
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libopenal.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libpad.so
replace!!!!!!!!!!!!
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libpad.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libopenal.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libpad.so
replace!!!!!!!!!!!!
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libpad.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libopenal.so
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libpad.so
replace!!!!!!!!!!!!
[mmap13_vsnprintf] this.a0:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libpad.so
[mmap13_vsnprintf] this.a0:  /vendor/lib64/libc.so
[mmap13_vsnprintf] this.a0:  /system/lib64/libc.so

用同樣方法將libc.so替換為libz.so，發現APP終於不會在mmap13模塊之後馬上閃退，反而又再創建了其他模塊。

簡單小結，mmap13模塊應該是先檢測了lib__6dba__.so( APP本身的so庫 )有沒有被hook，若前者通過檢測，則再檢測libc.so( 系統so庫 )有沒有被hook，都通過後才會創建新模塊進行其他檢測，否則就用某些手段讓程序退出。

手動patch mmap13模塊後，多了很多新模塊，是在mmap3模塊裡創建的，索引由14開始，共有mmap14 ~ mmap30模塊。

if (this.sysno == 0xe2) {
    console.log("[hook_mmap3_syscall] mprotect addr: ", this.a0, "size: ", this.a1 ,"prot: ", this.a2);
    if (mmap_history[this.a0]) {
        console.log(`\t[hook_mmap3_syscall] mmap addr: ${this.a0}  size: ${mmap_history[this.a0]}`);
        // after patch mmap13 detect, use this to dump new mmap module
        if (is_hook_mmap13) {
            saveData(`/data/data/jp.gungho.padHT/mmap_${this.a0}_${mmap_history[this.a0]}_${idx++}.bin`, this.a0, mmap_history[this.a0].toInt32());
        }
    }
    // ...

local lib檢測分析

上一小節通過trace日志 + 經驗猜測的方式成功bypass了lib__6dba__.so中的hook檢測，這一小節嘗試分析看看具體的檢測原理。

hook mmap13模塊封裝的syscall，在系統調用是openat且path包含lib__6ba__.so時打印調用棧，然後一路向上跟，最終發現是在mmap13!0x3BF0裡打開lib__6ba__.so的。

詳細調用鏈如下：( ins addr代表指令地址，func addr代表函數起始地址 )

1	0x394C(ins addr) -> 0x485C(ins addr) -> 0x433C(ins addr) -> 0x3F7C(ins addr) -> 0x3BF0(func addr)

0x394C( 調用sub_4684的指令地址 )附近的邏輯如下，記所在函數為mmap13_main。

測試發現，按上述「hook mmap13的vsnprintf，將lib__6dba__.so替換為另一個沒被hook的庫libpad.so」後，sub_4C20函數會返回1，否則返回0。

由此可知sub_4C20要麼是具體的檢測函數，要麼是處理檢測結果的函數。記sub_4C20為mb_detect_func。

進入mb_detect_func分析，一路通過hook驗證，會發現get_so_info這個比較關鍵的函數。

一開始以為get_so_info是具體的檢測函數，因為hook發現get_so_info共調用了3次，而且hook mmap13的openat系統調用時，看到它打開了3個自身的so庫，正好與之對應。由此猜測前2次get_so_info執行後的a1為0是因為我沒有hook libopenal.so和libpad.so，而第3次不為0是因為hook了lib__6dba__.so被檢測到。

// hook mmap13 openat log:
[hook_mmap13_openat] a1:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libopenal.so
[hook_mmap13_openat] a1:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/libpad.so
[hook_mmap13_openat] a1:  /data/app/jp.gungho.padHT-RB7leURHfwOLGhr-1wOUew==/lib/arm64/lib__6dba__.so

// hook get_so_info log:
[mmap13_get_so_info] this.a1.readPointer:  0x0
[mmap13_get_so_info] this.a1.readPointer:  0x0
[mmap13_get_so_info] this.a1.readPointer:  0x7cfb84e000

但後來詳細分析get_so_info後發現它其實只是在解析、保存/proc/pid/maps裡的信息( so_info[0]保存著so的二進制信息 )，前2次的a1為0是因為這時機還未加載那兩個lib庫，因此才為0。

繼續向下看，so_info( so_img )之後會傳入do_something1函數，返回值保存在dest，然後會與*(_DWORD*)(v8+0x3C)對比，若不相等會導致最終走向wrong_branch。

由此猜測*(_DWORD *)(v8 + 0x3C)應該是原始lib__6dba_.so .text段的hash值，dest是/proc/pid/maps裡lib__6dba__.so .text段的hash值。

進入do_something1，一開始在通過so_img解析重定向表，但沒看出來有什麼用。

繼續向下可以看到關鍵的while循環。

其中的hash_sum是一堆計算，應該是在計算類似哈希值的東西，嘗試hook該函數會發現args[0]曾出現過lib__6dba__.so的.text段，args[1]是.text段的大小，args[2]保存計算結果。

而後發現，針對自身的每個so，總共會調用2次hash_sum( 在兩處不同的位置 )來計算哈希值：

第1次會對整個文件進行哈希，從下圖第1部份可以看出，0x1860df正是lib__6dba__.so的文件大小，而且在此之前調用openat打開了lib__6dba__.so。調用棧在mmap13!0x3DF0。
第2次會對.text段進行哈希，從下圖第2部份可以看出，0xcaf4正是lib__6dba__.so的.text段大小，而且在此之前調用openat打開了/proc/self/maps，因此可知這部份是從其中獲取的。調用棧在mmap13!0x6B98，這正是上述的do_something1那裡。

第1次大概是為了校驗完整性之類的，第2次顯然就是在校驗是否被hook，這樣使得常規的IO重定向似乎無法直接繞過？

小結：對於local lib( APP自身的庫 )，會調用hash_sum函數進行校驗，與之對比的值應該是提前計算好內置到so中的。

system lib檢測分析

通過上述的local lib檢測後，才會繼續調用check_libc函數來檢測libc.so( 貌似只檢測了libc這個系統庫 )。下圖所在函數是mmap13_main。

check_libc中調用了do_something2函數。

接下來詳細分析do_something2函數。

首先調用parse_elf_data函數來解析指定so，args[0]是libc.so映像的地址( 該映像是在此之前通過openat系統調用打開&讀取的 )。解析結果保存在soinfo中( 這並非linker那個soinfo )。

然後解密了一個關鍵字符串.text，傳入了get_section_info函數，它會返回libc.so的.bss段中的某段數據，其中包含指定section的信息，記為section_info。

如*(section_info+0x10)就是指定section的offset。

之後會遍歷maps_item( /proc/pid/maps的每一行我稱為一個maps_item )，當遍歷到libc.so的.text段的下一段時，才會滿足下圖的第1個if條件。

正常手機沒有啟動過frida時，會滿足第2個if條件( 即.text段的下一段一定大於等於.text段結束的位置 )，最終走到真正檢測libc的地方。

當不滿足上述第2個if條件時，會走下圖這裡，而且會循環多次。

第1個紅框代表最多循環10次，若遍歷完.text段的後10個maps_item仍沒有發現大於.text段結束的，代表有問題，最終會導致程序走向閃退的錯誤分支。

正常沒有被frida干預的程序流會在第2個紅框那裡直接goto LABEL 49。

而goto LABEL 49最終會走到這裡，調用do_check_libc進行真正的libc校驗。

do_check_libc函數裡有些關鍵字符串信息，如下。

而do_check_libc的具體原理，有興趣的靚仔可以自己分析看看。

完全繞過所有hook檢測的思路

通過hook mmap13模塊的vsnprintf繞過對lib__6dba__.so和libc.so的校驗後，會加載libopenal.so和libpad.so( 它們是APP自身的so庫 )，然後發現這兩個so庫同樣存在與lib__6dba__.so一樣的start函數，同樣存在上述的mmap模塊檢測，同樣會檢驗local lib和system lib。

好消息是它們大致使用了相同的mmap模塊來進行檢測，不同的只有mmap模塊創建的數量，如libopenal.so創建的mmap11模塊其實是lib__6dba__.so創建的mmap13模塊。

而mmap模塊會調用vsnprintf來拼接庫的完整路徑，因此可以hook vsnprintf來改變指定庫路徑，重定位到其他沒有被hook的庫，以此來繞過檢測。具體方式在上文中已經給出，就不再重複。