第一次聽說這比賽是上年偶然和舍友聊天時他告訴我的，沒想到還有以遊戲安全為主的比賽，當時看到有安卓的賽道就報名了，然後比賽時就被那門卡了2天，然後就沒有然後了。

今年沒意外的話是我大學生涯的最後一年，也許也是最後一年打這個比賽了吧，下年也不知道有沒有空看看題。

以下是我的解題記錄，一部份是比賽時寫的，一部份是賽後補充的，有寫錯的還請指正。

版本：4.27

GName：0xADF07C0

GObject：0xAE34A98

dump sdk by GObject，記為SDKO.txt

dump all objects，記為Objects.txt

題目說明如下，純粹的UE4逆向，無任何反調試。

hook pthread_create，patch掉libGame.so創建唯一一個線程後，速度不再異常。

由此可知相關邏輯就在libGame.so創建的線程中。接下來分析它的實現原理。

用IDA動調線程回調函數sub_1B9C。

進入後會看到明顯的控制流平坦化，先不管。

打斷點進入case 12623，分析後發現就是通過/proc/self/maps獲取libUE4.so的基址。

之後本想手動還原下控制流，但突然想起IDA有個D-810插件貌似能解控制流混淆，嘗試下，發現效果很好。

獲取了libUE4_base後會賦給infos[19]。

然後*(_QWORD *)(libUE4_base_1 + 0xAFAC398)獲取了libUE4.so的一個全局變量，猜測是GWorld。

用ue4dumper來驗證，發現能順利dump出SDK，由此可知0xAFAC398的確是GWorld。

記dump出來的文件為SDKW.txt。

獲取GWorld後，就能通過遍歷其中的屬性定位到FirstPersonCharacter_C，具體原理如下，這是用frida實現的。

其中用了vtabs( UObject的第0個成員屬性，虛表 )的函數偏移是否等於0xA63BE28來確定是否FirstPersonCharacter_C對象，0xA63BE28大概是FirstPersonCharacter_C的一個特徵？

最終通過修改CharacterMovementComponent的MaxAcceleration和MaxWalkSpeed來改變人物速度。

在SDKO.txt裡可以看到我的角色類裡有個ProjectileClass成員，而它有個OnHit成員函數

嘗試hook OnHit，分別在enter和leave時打印CameraRotation，發現兩者相等，即在enter前就已經完成自瞄，代表相關的自瞄邏輯不在這裡。

對CameraRotation下硬斷( 寫 )，命中信息如下：

命中PC：0x799F6637C0

libUE4 base：0x7996b2b000

計算得Offset為0x8B387C0

IDA跳到0x8B387C0，如下：

記0x8B387C0所在函數為mb_aimbot，嘗試直接patch掉mb_aimbot，發現patch後人物無法轉動視角。

hook mb_aimbot，打印調用棧，未點擊時，調用棧如下

點擊後，多了一個不同的調用棧0x670f3fc。

嘗試patch掉0x670f3fc所在函數0x670F110，雖然點擊後不會再自動瞄到某處，但子彈射不出。

由此猜測0x670F110是射擊的回調函數，自瞄邏輯應該就在裡面。

記0x670F110為process_before_shoot。

在0x670F110中從調用mb_aimbot處向上分析，發現是否調用mb_aimbot邏輯是由sub_680B790(v32, "E")決定的。

hook sub_680B790，打印參數和返回值。

注：hexdump後可知是unicode編碼的字符串，因此要用readUtf16String。

輸出如下，可以看出是字符串對比函數，res是a0、a1第1個不相等字符的差值，若相等則為0( 不區分大小寫 )。記sub_680B790為utf16_cmp。

可以看到前面一直在和EditorCube8對比，明顯它就是自瞄的目標，

嘗試在a1為EditorCube8時將返回值固定replace為一個大於0的值。

結果是射擊時不再自動瞄到指定目標，但手槍在射完後會向上抬一下，類似後座力？不知是否屬於異常點。

下面簡單看看它的自瞄實現原理：

從process_before_shoot開始看，一開始先遍歷自瞄目標。

然後調用calcTargetOffset計算自瞄值，然後根據這個值來設置CameraRotation( 人物相機的轉向，使它朝向目標以實現自瞄的效果 )。

calcTargetOffset實現大概像這樣：利用目標location與人物的location向量來計算。

可以明顯看出子彈發射的起始位置是隨機的。

猜測可能與MyProjectCharacter的GunOffset有關。

對GunOffset下硬斷( 讀 )。

命中如下兩處地址：

0x6930A6C所在函數是sub_6930A3C。

hook sub_6930A3C打印調用棧。

其中0x670f658位於0x670F110函數( 即process_before_shoot )。

process_before_shoot中有調用rand()生成隨機值，猜測這與槍口的隨機有關。

嘗試hook rand固定其返回值。

結果是子彈發射位置固定了，但是固定在了人物的頭上偏左的位置。

繼續嘗試其他修復思路。

讓process_before_shoot中的a1[0x14A] & 1不為0，目的是讓執行流無法走到上述的0x6930A6C位置。

結果同樣可以固定子彈發射的位置，但這次是在人物的下方固定向正前方發射，上下抬頭時不會改變發射方向。

以下部份是賽後的分析。

若a1[0x14A] & 1為0，會調用about_bullt_loc1生成一些隨機值，調用about_bullt_loc2生成一個基於GunOffset等參數而來的值，最終傳入mb_process_bullet_shoot_loc做最後的處理。

而當a1[0x14A] & 1為1時，則會從VR_MuzzleLocation裡獲取一些參數，最終同樣傳入mb_process_bullet_shoot_loc。

注：通過hook所在函數，將*((QWORD*)a1 + 155)當成UObject來打印它的名字，從而確定它是VR_MuzzleLocation對象。

但VR_MuzzleLocation看名字來說是給VR設備使用的，安卓設備感覺是使用FP_MuzzleLocation才對。

因此合理懷疑這也是一個異常點。

hook process_before_shoot，從IDA裡可知args[0].add(0x4D8)保存著VR_MuzzleLocation對象的地址，嘗試將它改為FP_MuzzleLocation的地址。

結果是子彈終於會隨著槍口的變化而變化，但卻是從槍口往左發射的，正常應該是往前才對。

接下來嘗試修改FP_MuzzleLocation裡的一些參數，看看能否改變發射方向。

FP_MuzzleLocation屬於USceneComponent類，其中有以下這兩個屬性：

利用K2_SetRelativeLocation和K2_SetRelativeRotation函數來修改。通過不斷嘗試，發現只需要將Rotation設置為[0, 90, 0]即可，相當於旋轉了90度。完整修複代碼如下：

注：不能直接通過內存來修改，要用API來修改。

在Objects.txt裡可以看到FirstPersonCharacter_C和ThirdPersonCharacter_C，它們分別是我控制的人物和假人。

嘗試一：替換Material。( 沒效果 )

嘗試二：設置bDisableDepthTest為0。( 沒效果 )

嘗試三：利用SetTexture隨便設置一個Texture。( 沒效果 )

以下部份是賽後的分析。

找資料時發現類似這遊戲的人物透視效果基本上有以下兩種實現思路：

但嘗試後發現遊戲似乎不是用上述方法實現透視效果的( 不太確定，也有可能是我修改的地方不對 )？

找了很久都沒有什麼思路，最終只好退而求其次，用一種「掩耳盜鈴」的方式來修復，具體思路如下：

具體調用LineTraceSingle、獲取HitResult.Distance的代碼如下：

時機選擇在Actor類的ReceiveTick函數，在其中判斷是否渲染：

當然這肯定不是正解，而且效果也非常一般，之後看看有沒有其他大佬分析下正解吧。

子彈射在白色的Cube上不會反彈。

白色的Cube應是就是EditorCubeN。

子彈射在EditorCubeN上會瞬間消失，但EditorCubeN是有被擊退的效果，而子彈射在黑色的Cube上能正常被反彈。

嘗試一：看看是否因為物理模擬未啟用。( 沒效果 )

嘗試二：設置物理材質的反彈系數為1。( 沒效果 )

嘗試三：設置與所有物體的碰撞響應都為Block( 具體值是2 )。( 沒效果 )

經過上述嘗試，可知子彈消失大概率與Collision無關。

猜測子彈是在擊中EditorCubeN時執行了一段Destroy邏輯。

hook MyProjectProjectile的OnHit，打印調用棧：

Destroy邏輯可能就在其中，但沒時間看了。。

以下部份是賽後的分析。

OnHit最後調會return sub_88A8D2C((__int64)v4, 0, 1)，而sub_88A8D2C函數如下。

about_ActorDestroying中有"ActorDestroying"字符串，猜測會不會就是那段Destroy邏輯。

嘗試直接patch掉該函數，使其固定返回1。

結果是射到EditorCubeN時也會正常反彈，成功修復該異常點。

在測試過程中還發現以下一些不確定算不算異常點的：

frida -U -f com.ACE2025.Game -l final.js

今年跟上年一樣是UE4的題型，猜到了會出UE4，賽前本想找些遊戲來練練手，但一直沒找到合適的，只能說可惜了。這也導致了比賽前2天基本都在熟悉UE4，直到最後也沒有完整地修復幾個異常點。

本以為決賽無望的，沒想到運氣挺好居然進了，算是圓了上一年的遺憾吧。

[培训]Windows内核深度攻防：从Hook技术到Rootkit实战！