Адкрыйце для сябе

Analisis Arsitektur Anti-Cheat pada Game Unity: Studi Perbandingan Backend Mono dan IL2CPP terhadap Ancaman Mod Loader dan Runtime Hooking

June 22, 2026 221 Праглядаў 0 Каментарыі

#blog-content-iframe { display: none !important; }

Analisis Arsitektur Anti-Cheat pada Game Unity: Studi Perbandingan Backend Mono dan IL2CPP terhadap Ancaman Mod Loader dan Runtime Hooking

Abstract
Cheating dan runtime tampering pada game modern berbasis Unity menjadi tantangan signifikan bagi developer, terutama pada game multiplayer dan live-service. Banyak developer pemula menerapkan mekanisme anti-cheat sederhana berbasis pemeriksaan keberadaan file dan folder menggunakan fungsi seperti `File.Exists()` dan `Directory.Exists()`. Pendekatan ini sering digunakan untuk mendeteksi mod loader seperti MelonLoader dan BepInEx. Namun, metode tersebut memiliki kelemahan mendasar karena loader modern dapat berjalan sebelum lifecycle Unity dimulai melalui mekanisme DLL proxying atau doorstop injection. Selain itu, runtime patching melalui managed hooking maupun native function interception dapat memanipulasi mekanisme anti-cheat tersebut. Penelitian ini menganalisis keterbatasan pendekatan anti-cheat client-side sederhana, membandingkan keamanan backend Mono dan IL2CPP pada Unity, serta mengevaluasi arsitektur anti-cheat hybrid yang mengombinasikan client integrity verification dan server-authoritative validation. Hasil analisis menunjukkan bahwa IL2CPP hanya meningkatkan kompleksitas reverse engineering tetapi tidak dapat dianggap sebagai security boundary terhadap attacker modern.
Keywords— Unity, Anti-Cheat, Mono, IL2CPP, Runtime Hooking, Game Security

I. Introduction
Industri game modern menghadapi peningkatan ancaman dari:

memory tampering
runtime injection
mod loaders
reverse engineering
packet manipulation

Game engine Unity menjadi target populer karena:

Dominasi market indie/mobile
Struktur runtime yang relatif mudah dianalisis
Dukungan scripting C#

Banyak developer pemula mencoba membangun anti-cheat sederhana seperti:

if (File.Exists("version.dll")) CheatDetected();
if (Directory.Exists("MelonLoader")) CheatDetected();

Pendekatan ini tampak efektif secara intuitif, tetapi gagal menghadapi attacker modern.
Masalah utama:

Anti-cheat Unity berbasis script sering berjalan terlambat dibanding loader cheat.
II. Background
A. Unity Execution Model
Secara umum lifecycle Unity:
Executable launch
↓
Native libraries loaded
↓
Unity runtime initialized
↓
Managed domain initialized
↓
Awake()
↓
Start()
↓
Update()
Anti-cheat yang ditulis dalam C# baru aktif setelah managed runtime aktif.
B. Mono Backend
Pada backend Mono, Unity menyimpan game logic dalam managed assembly:
Assembly-CSharp.dll
UnityEngine.CoreModule.dll
Kelebihan:
debugging mudah
rapid development
Kelemahan:
mudah di-decompile
mudah di-patch
reflection tersedia
Tool reverse engineering umum:
dnSpy
ILSpy
Harmony
C. IL2CPP Backend
Pada IL2CPP, Unity mengubah MSIL menjadi native C++.
Pipeline:
C#
↓
MSIL
↓
IL2CPP Conversion
↓
C++
↓
Native Binary
Output Windows:
GameAssembly.dll
global-metadata.dat
Kelebihan:
lebih sulit reverse engineer
tidak ada managed DLL utuh
Namun attacker modern tetap dapat melakukan analisis.
III. Threat Model
Penelitian ini memodelkan attacker dengan kemampuan:
DLL injection
Runtime patching
Native hooking
Managed hooking
Memory editing
Kategori attacker:

Tipe Kemampuan
Script Kiddie Tool publik
Intermediate Mod loader + patch
Advanced Native RE + custom hook
IV. Weakness of Simple Anti-Cheat
A. File Detection
Developer pemula sering mendeteksi:
version.dll
winhttp.dll
winmm.dll
Atau folder:
MelonLoader/
BepInEx/
imgui/
Mods/
Plugins/
Masalah:
File bisa di-rename
Loader custom bisa dipakai
Reflective injection tidak meninggalkan file
B. Early Loader Execution
Loader seperti MelonLoader dan BepInEx sering memakai:
DLL proxying
doorstop bootstrap
loader hijacking
Execution order:
Game.exe launched
↓
Windows loads proxy DLL
↓
Loader bootstrap executes
↓
Cheat code runs
↓
Unity starts
↓
Developer anti-cheat runs
Artinya:
Cheat dapat aktif sebelum Awake().
C. Managed Layer Vulnerability
Anti-cheat berbasis C# berjalan pada managed layer.
Jika attacker juga berada pada managed layer:
function interception mungkin dilakukan
runtime behavior bisa dimodifikasi
return value dapat dimanipulasi
Konsep serangan:
AntiCheat.Check()
↓
Hook intercepts
↓
Modified result
↓
Anti-cheat bypassed
Karena itu, proteksi managed-only sangat lemah.
V. Mono vs IL2CPP Security Analysis
A. Mono
Mono rentan terhadap:
direct assembly patching
reflection abuse
runtime patching
Risk level: High
B. IL2CPP
Banyak developer menganggap IL2CPP sebagai anti-cheat.
Namun tool modern seperti:
IL2CPP metadata parser
scaffold generator
runtime object inspector
tetap memungkinkan analisis mendalam.
IL2CPP hanya:
menaikkan cost
memperlambat attacker
menghambat beginner
Bukan security boundary.
C. Comparative Analysis

Parameter Mono IL2CPP
Decompile Ease Very High Medium
Runtime Hooking High High
Memory Tampering High High
Reverse Engineering Cost Low Medium
Cheat Prevention Low Low-Medium
VI. Native Hooking Threat
Walaupun managed loader diblokir, attacker masih bisa menggunakan native hooks.
Target:
player update loop
damage calculation
movement logic
render pipeline
Native hook memungkinkan:
parameter interception
execution redirection
code patching
Konsep:
Original Function
↓
Hook Installed
↓
Custom Logic
↓
Return
Ini membuat:
Mono vulnerable
IL2CPP juga vulnerable
VII. Proposed Anti-Cheat Architecture
Anti-cheat yang efektif membutuhkan hybrid architecture.
Client-Side Module
Tugas:
file scan
process scan
module enumeration
memory integrity
tamper detection
Diagram:
Unity Client
   ↓
Native Anti-Tamper Layer
   ↓
Integrity Scanner
   ↓
Telemetry Collector
Server-Side Module
Tugas:
validate movement
validate damage
validate inventory
anomaly detection
Diagram:
Client Input
   ↓
Server Validation
   ↓
Authoritative Simulation
   ↓
Approved State
Hybrid Architecture
+----------------------+
Unity Game Client
Managed Scripts
Native Anti-Tamper
Integrity Scanner
+----------+-----------+
           |
           v
+----------------------+
| Telemetry Pipeline   |
+----------+-----------+
           |
           v
+----------------------+
Server Anti-Cheat
Behavior Analysis
Movement Validation
Damage Verification
Ban Engine+----------------------+
VIII. Recommended Detection Layers
Layer 1 — Static Detection
suspicious files
suspicious modules
Layer 2 — Runtime Detection
integrity hash
memory section verification
Layer 3 — Behavioral Detection
Deteksi:
impossible movement
impossible DPS
impossible reaction speed
Layer 4 — Server Authority
Paling penting.
Server harus menentukan:
HP
damage
coins
cooldown
inventory
Bukan client.
IX. Discussion
Temuan utama penelitian:
Developer pemula terlalu percaya file detection
Mono lebih mudah di-cheat
IL2CPP tidak menghilangkan cheat
Client-side anti-cheat saja tidak cukup
Server-authoritative design paling penting
Kesalahan umum:
Menganggap IL2CPP = anti-cheat.
Padahal:
IL2CPP hanya obfuscation layer.
X. Conclusion
Pendekatan anti-cheat sederhana pada Unity yang hanya mengandalkan pemeriksaan file dan folder tidak cukup untuk menghadapi attacker modern. Loader seperti MelonLoader dan BepInEx dapat berjalan sebelum lifecycle Unity dimulai melalui mekanisme proxy DLL atau bootstrap injection. Selain itu, runtime patching dan native hooking dapat memanipulasi anti-cheat yang berjalan pada managed layer.
Perbandingan Mono dan IL2CPP menunjukkan bahwa IL2CPP memang meningkatkan kompleksitas reverse engineering, namun tidak dapat dianggap sebagai mekanisme keamanan utama. Solusi anti-cheat yang efektif memerlukan pendekatan hybrid yang mengombinasikan:
native anti-tamper
runtime integrity verification
behavioral analytics
server-authoritative architecture
Dengan demikian, keamanan game modern tidak boleh bergantung pada backend scripting saja, melainkan pada desain sistem keamanan end-to-end.
References
[1] Unity Documentation
[2] MelonLoader GitHub
[3] BepInEx GitHub
[4] Academic papers on game anti-cheat systems and runtime integrity verification

Рэагаваць

Дыскусія (0)

Калі ласка увайсці ў сістэму або зарэгістравацца далучыцца да абмеркавання.