首页
社区
课程
招聘
11
[原创] 2025騰訊遊戲安全大賽(安卓決賽)
发表于: 2025-4-14 10:53 4662

[原创] 2025騰訊遊戲安全大賽(安卓決賽)

2025-4-14 10:53
4662

上一年雖然止步於初賽,但之後找了時間復現了一下決賽,大概花了2、3周才復現完( 還是在有文章參考的情況下 ),內容很多,大致包括保護分析、vm分析、透視、自瞄實現。

今年的決賽比較不同,他給了2種外掛,考察的是外掛功能的分析和外掛檢測,如下圖。

我對外掛的實現與檢測都沒有太深入的研究,下文的檢測方式大多都是參考網上的文章現學現賣的,有寫錯的地方還請指正。

三件套與初賽一樣:

GName:0xADF07C0

GObject:0xAE34A98

GWorld:0xAFAC398

利用GObject來dump SDK,記為SDKO.txt

ACEInject這個Zygisk模塊會注入libGame.so,將其拉入IDA分析,發現沒有混淆。

.init_array裡發現它調用pthread_create創建了一個線程,對應線程回調函數如下。

具體邏輯是先獲取libUE4.so的基址,在sub_1618中修改libUE4_base + 0x6711AC4的權限( rwx ),然後將*(libUE4_base + 0x6711AC4)置為0x52A85908

最後的anti是一些反調試邏輯。

libUE4.so0x6711AC4處是一條mov指令。

0x52A85908對應的arm64匯編是mov w8, #0x42c80000

查看偽代碼,w8最終會賦給*(v5 + 0x460),而v5大概率是個UE4的對象。

hook後發現v5可能是以下uobj

SDKO.txt裡搜SphereComponent,發現它0x460偏移處是SphereRadius屬性,看來libGame.so中的修改目標就是它。

anti函數如下,主要是一些frida、hook、調試檢測。

調試檢測1:/proc/self/stat

端口檢測:包括IDA、frida的默認端口。

調試檢測2:TracerPid

frida檢測:

hook檢測( 應該 ):

從上述分析可知,libGame.so會修改libUE4.sosub_6711A54中某處的字節碼。

因此可以通過crc32來判斷sub_6711A54是否被修改,sub_6711A54原始的crc32是0x49d5c836

在線程中不斷調用is_sub_6711A54_modify來檢測是否被修改,當libGame.so注入後,成功檢測。

當然更通用的做法可能是對整個.text段進行crc32,或者對一些重要的函數分別進行crc32,這裡針對單一函數的做法只是作為一個演示。

注:不知為何我用Xiaomi8 Lite( Magisk環境 )在測試時發現有時雖然libGame.so成功注入,但卻修改失敗?有時卻能修改成功,有點玄學。而在另一部非Magisk環境的手機手動注入libGame.so時卻能100%修改成功,有點神奇。

elf可執行文件的起始執行函數是start,如下。

一開始以為br x16那裡會跳到具體邏輯,但嘗試用frida stalker hook那處地址時並沒有觸發。

用frida stalker簡單trace後發現,__libc_init會跳到0x241d90

注:後來用IDA9看才發現原來之前是因為沒有正確解析__libc_init的參數,導致看不到sub_241d90

0x241d90start_process,這裡會通過am start來啟動APP,啟動成功後會調用usleep等待APP加載so,然後調用sub_241BF0實現外掛邏輯。

sub_241BF0如下,一開始先初始化了ImGui,然後循環調用MainLoopStep

對比ImGui源碼,以此手動還原MainLoopStep中的一些符號。

可以看到點擊「初始化輔助」按鈕後,會調用init_cheat進行初始化,看看它的實現。

init_cheat初始化流程大致如下。

/proc/pidof com.ACE2025.Game/maps獲取libUE4.so的基址,保存到全局變量。

通過process_vm_readv系統調用來跨內存訪問訪問libUE4.so中的一些值,保存到全局變量。

遍歷獲取MyProjectCharacter對象( 暫時未知是基於libUE4的哪個全局變量來獲取的 ),然後保存其中的PlayerCameraManager屬性到全局變量。

將上述遍歷過程用frida實現,如下:

由此可以看出0xAF75B08指向的位置保存著Character對象數組,0xAF75B08 + 8指向的位置保存著數組大小。

最後調用get_ThirdPerson遍歷獲取 & 保存TP_ThirdPersonCharacter對象( 同上 ),後面還進行了一些操作,但應該不太重要,先不看了。

init_cheat初始化後,inited會置為true,然後會調用process_cheat_options處理勾選的外掛功能。

process_cheat_options是個巨大的函數,一開始會遍歷所有TP_ThirdPersonCharacter對象,收集它們的信息( 同樣利用process_vm_readv系統調用 ),用來計算繪制的參數。

中間一大片類似如下結構的代碼,應該是在獲取 & 處理UE4角色的骨骼信息。

最後根據勾選的參數來繪制。

總的來說process_cheat_options是個巨大的透視框、自瞄框繪制函數。

自瞄開關的bool值保存在g_aimbot


查看其交叉引用,有兩處,一開始以為所有外掛實現邏輯都在process_cheat_options,但分析了很久都沒有發現其中有實現自瞄的邏輯,基本上都是ImGui的繪制邏輯。

只好仔細分析另一處交叉引用,終於發現寫的操作,但它不是跨進程的寫,是如何實現自瞄的?

x找到g_dev_uinput_fd的初始化邏輯,如下:

首先調用get_dev_input_event2_fd遍歷/dev/input目錄,獲取指定的Input Event( 大概是觸控屏幕的事件 ),我的設備會返回/dev/input/event2

然後調用create_virtual_device創建 & 初始化一個虛擬設備。

查資料發現:「uinput是Linux用戶空間模擬輸入設備事件的機制,通過此機制,用戶空間程序可以向系統發送假的輸入事件。」

注:uinput是android內置的一個內核模塊,對其進行openreadwriteioctl等操作會觸發對應的回調( 這些回調定義在內核中 )。

最後會調用parse_dev_input_event2,應該是在解析/dev/input/event2?猜測是上述創建的虛擬設備需要其中的一些數據?

又或者是攔截了/dev/input/event2,使其中的事件重定向到上述創建的虛擬設備?

至此g_dev_input_event2_fd初始化成功,之後只要通過writeg_dev_input_event2_fd寫入數據( 特定事件 )即可實現屏幕控制。

回到之前一大堆對g_dev_uinput_fd進行write操作的地方,將該函數記為ctrl_uinput_to_aimbot,大概就是這裡實現的自瞄( 當然前面還進行了一大堆的計算 )。

思路一:/dev/kmsg中有cheat創建虛擬設備的記錄。

嘗試監控/dev/kmsg,但發現在so中沒有訪問/dev/kmsg的權限。

思路二:嘗試監測/sys/devices/virtual/input/目錄。

cheat啟動前:

cheat啟動後:多了個input47 ( 47是編號,不是固定的 )

它的名字是隨機的。

但APP的lib文件同樣沒有訪問/sys/devices/virtual/input/的權限。

偶然發現lstat能訪問/sys/devices/virtual/input/目錄以及其下的子目錄,觀察發現cheat創建的虛擬設備的st.st_mtimst.st_atimst.st_ctim這三者會相等,並且等於當前的時間。

因此檢測思路如下:

從上述「初始化輔助」分析可知,cheat會通過libUE4.so + 0xAF75B08來遍歷某個Character數組,記這數組為arr

因此檢測的思路是將arr的所有元素複製到一片新的內存( 記為fake_memory ),在fake_memory最後插入一個mmap返回的地址( 記為never_access_address ),然後令libUE4.so + 0xAF75B08指向fake_memory,並將數組長度+1。

正常情況下never_access_address永遠不會被訪問,即不會存在於物理內存空間。而執行init_cheat時會訪問這個地址,導致物理內存出現這個地址。

mincore函數能很方便地判斷一個地址是否存在於物理內存空間,具體檢測腳本如下:

點擊「初始化輔助」按鈕後,立即就被檢測到。

回顧一下,cheat程序是通過process_vm_readv來跨進程讀取libUE4.so的數據,然後繪制方框、射線等。

思路一:異常捕獲,通過mprotectlibUE4.so的某片內存權限置為0,然後注冊信號回調捕獲異常。

結果會導致外掛功能失靈,且無法捕獲cheat的誇內存訪問。

思路二:由分析可知cheat初始化時會通過/proc/<pid>/maps獲取libUE4.so的基址,因此嘗試利用inotify來監測/proc/<pid>/maps,當訪問次數超過n次時代表非法訪問。

結果是啟動cheat並初始化後,能順利監測到其訪問maps的行為,缺點是沒有更詳細的上下文。

又一個周末獻給了騰訊,所幸也是有所收獲,願各位讀者也是如此。

由於時間和能力有限,很多東西都沒有仔細深入分析,只能一筆帶過,屬實無奈。

./ue4dumper64 --sdku --newue+ --gname 0xADF07C0 --guobj 0xAE34A98 --package com.ACE2025.Game
./ue4dumper64 --sdku --newue+ --gname 0xADF07C0 --guobj 0xAE34A98 --package com.ACE2025.Game
[UObjectName]  SphereComp
[UObjectName]  SphereComp   
[UObjectName]  ProjectileComp
[UObjectName]  ProjectileComp
[UObjectName]  SphereComp
[UObjectName]  SphereComp
[UObjectName]  ProjectileComp
[UObjectName]  ProjectileComp
[UObjectName]  SphereComp
[UObjectName]  SphereComp   
[UObjectName]  ProjectileComp
[UObjectName]  ProjectileComp
[UObjectName]  SphereComp
[UObjectName]  SphereComp
[UObjectName]  ProjectileComp
[UObjectName]  ProjectileComp
Class: SphereComponent.ShapeComponent.PrimitiveComponent.SceneComponent.ActorComponent.Object
    float SphereRadius;//[Offset: 0x460, Size: 0x4]
Class: SphereComponent.ShapeComponent.PrimitiveComponent.SceneComponent.ActorComponent.Object
    float SphereRadius;//[Offset: 0x460, Size: 0x4]
uLong get_crc32(uint8_t* addr, size_t size) {
    return crc32(0, addr, size);
}
 
bool is_sub_6711A54_modify(uint64_t base) {
    // func offset: 0x6711A54
    // size: 0x224
    // orig sub_6711A54 crc32 = 0x49d5c836;
 
    uLong crc_val = get_crc32(reinterpret_cast<uint8_t*>(base + 0x6711A54), 0x224);
//    LOGD("crc_val: 0x%llx", crc_val);
    return crc_val != 0x49d5c836;
}
uLong get_crc32(uint8_t* addr, size_t size) {
    return crc32(0, addr, size);
}
 
bool is_sub_6711A54_modify(uint64_t base) {
    // func offset: 0x6711A54
    // size: 0x224
    // orig sub_6711A54 crc32 = 0x49d5c836;
 
    uLong crc_val = get_crc32(reinterpret_cast<uint8_t*>(base + 0x6711A54), 0x224);
//    LOGD("crc_val: 0x%llx", crc_val);
    return crc_val != 0x49d5c836;
}
0x241b04: bl #0x5f6bc47440
0x2b0440: adrp x16, #0x5f6bc4b000
0x2b0444: ldr x17, [x16, #0xfb0]
0x2b0448: add x16, x16, #0xfb0
0x2b044c: br x17
0x241d90: sub sp, sp, #0x70
0x241b04: bl #0x5f6bc47440
0x2b0440: adrp x16, #0x5f6bc4b000
0x2b0444: ldr x17, [x16, #0xfb0]
0x2b0448: add x16, x16, #0xfb0
0x2b044c: br x17
0x241d90: sub sp, sp, #0x70
function test_cheat_init() {
 
    let unknow1 = base.add(0xAF75B08).readPointer();
    let unknow2 = base.add(0xAF75B08).add(8).readU32();
    console.log("unknow1: ", hexdump(unknow1));
    console.log("FirstPersonCharacter_C: ", All_Objects["FirstPersonCharacter_C"]);
    for(let i = 0; i < unknow2; i++) {
        let uobj = unknow1.add(i * 24).readPointer();
        console.log(`${i}: ${uobj}`);
        printName(uobj);
    }
 
}
function test_cheat_init() {
 
    let unknow1 = base.add(0xAF75B08).readPointer();
    let unknow2 = base.add(0xAF75B08).add(8).readU32();
    console.log("unknow1: ", hexdump(unknow1));
    console.log("FirstPersonCharacter_C: ", All_Objects["FirstPersonCharacter_C"]);
    for(let i = 0; i < unknow2; i++) {
        let uobj = unknow1.add(i * 24).readPointer();
        console.log(`${i}: ${uobj}`);
        printName(uobj);
    }
 
}
void* watch_dev_kmesg(void* arg) {
    char path[] = "/dev/kmsg";
 
    int fd = open(path, O_RDONLY);
 
    if (fd < 0){
        LOGD("open %s fail", path);
        return nullptr;
    }
 
    fd_set readfds;
    char buf[0x1000] = {0};
 
    while (1) {
        FD_ZERO(&readfds);
        FD_SET(fd, &readfds);
 
        int r = select(fd + 1, &readfds, 0, 0, 0);
        if (-1 == r)
            break;
        read(fd, buf, 128);
        LOGD("%s: %s", path, buf);
    }
 
}
void* watch_dev_kmesg(void* arg) {
    char path[] = "/dev/kmsg";
 
    int fd = open(path, O_RDONLY);
 
    if (fd < 0){
        LOGD("open %s fail", path);
        return nullptr;
    }
 
    fd_set readfds;
    char buf[0x1000] = {0};
 
    while (1) {
        FD_ZERO(&readfds);
        FD_SET(fd, &readfds);
 
        int r = select(fd + 1, &readfds, 0, 0, 0);
        if (-1 == r)
            break;
        read(fd, buf, 128);
        LOGD("%s: %s", path, buf);
    }
 
}
void* check_virtual_devices(void* arg) {
    char base_path[] = "/sys/devices/virtual/input";
    bool loged = false;
 
    while (!loged) {
        struct timespec now;
        clock_gettime(CLOCK_REALTIME, &now);
        for(int i = 9; i < 256; i++) {
            char buf[0x100] = {0};
            struct stat st;
            sprintf(buf, "%s/input%d", base_path, i);
            int r = lstat(buf, &st);
            if (r != 0) {
                continue;
            }
            // 當st.st_mtim, st.st_atim, st.st_ctim 三者相等時, 滿足cheat創建的虛擬設備的第1個特徵
            if (st.st_mtim.tv_sec == st.st_atim.tv_sec && st.st_atim.tv_sec == st.st_ctim.tv_sec) {
                // 再與當前時間比較, 若大於當前時間, 或差值少於0x10, 代表它就是cheat創建的虛擬設備
                if (now.tv_sec <= st.st_mtim.tv_sec || (now.tv_sec - st.st_mtim.tv_sec) <= 0x10) {
                    logManager->writeLine("[Cheat Device] %s is cheat device", buf);
                    loged = true;
                    break;
                }
            }
        }
        sleep(1);
    }
 
    pthread_exit(0);
}
void* check_virtual_devices(void* arg) {
    char base_path[] = "/sys/devices/virtual/input";
    bool loged = false;
 
    while (!loged) {
        struct timespec now;
        clock_gettime(CLOCK_REALTIME, &now);
        for(int i = 9; i < 256; i++) {
            char buf[0x100] = {0};
            struct stat st;
            sprintf(buf, "%s/input%d", base_path, i);
            int r = lstat(buf, &st);
            if (r != 0) {
                continue;
            }
            // 當st.st_mtim, st.st_atim, st.st_ctim 三者相等時, 滿足cheat創建的虛擬設備的第1個特徵
            if (st.st_mtim.tv_sec == st.st_atim.tv_sec && st.st_atim.tv_sec == st.st_ctim.tv_sec) {
                // 再與當前時間比較, 若大於當前時間, 或差值少於0x10, 代表它就是cheat創建的虛擬設備
                if (now.tv_sec <= st.st_mtim.tv_sec || (now.tv_sec - st.st_mtim.tv_sec) <= 0x10) {
                    logManager->writeLine("[Cheat Device] %s is cheat device", buf);

[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课

收藏
免费 11
支持
分享
赞赏记录
参与人
雪币
留言
时间
Our_OT
你的帖子非常有用,感谢分享!
1小时前
by_Lin
你的帖子非常有用,感谢分享!
2天前
梧桐生
为你点赞!
2025-4-16 13:40
mb_iesvmzqc
非常支持你的观点!
2025-4-14 17:07
陈可牛
感谢你分享这么好的资源!
2025-4-14 14:24
逆天而行
期待更多优质内容的分享,论坛有你更精彩!
2025-4-14 14:21
TubituX
感谢你分享这么好的资源!
2025-4-14 12:24
5m10v3
你的帖子非常有用,感谢分享!
2025-4-14 12:02
Je2em1ah
谢谢你的细致分析,受益匪浅!
2025-4-14 11:57
New对象处
+6
你的帖子非常有用,感谢分享!
2025-4-14 11:43
东方玻璃
你的帖子非常有用,感谢分享!
2025-4-14 11:34
最新回复 (4)
雪    币: 2887
活跃值: (3542)
能力值: ( LV3,RANK:30 )
在线值:
发帖
回帖
粉丝
2
哇塞!我这次没参加 没有研究过游戏逆向
2025-4-14 14:22
0
雪    币: 2337
活跃值: (2943)
能力值: ( LV9,RANK:150 )
在线值:
发帖
回帖
粉丝
3
逆天而行 哇塞!我这次没参加 没有研究过游戏逆向
可以玩玩看, 手遊逆向還是挺有趣的
2025-4-14 14:34
0
雪    币: 446
能力值: ( LV1,RANK:0 )
在线值:
发帖
回帖
粉丝
4
分析的很好大佬 这次决赛二进制没怎么保护呀 主要考察的是内核api的使用
2025-4-15 22:17
0
雪    币: 2337
活跃值: (2943)
能力值: ( LV9,RANK:150 )
在线值:
发帖
回帖
粉丝
5
软件君子 分析的很好大佬 这次决赛二进制没怎么保护呀 主要考察的是内核api的使用
確實, 相比往幾年來說友善了很多, 不然光解混淆都不夠時間了
2025-4-15 22:45
0
游客
登录 | 注册 方可回帖
返回

账号登录
验证码登录

忘记密码?
没有账号?立即免费注册