Eksploit Performa Server UEFN Dijelaskan: Memperkuat Netcode Unreal Engine Anda
Setiap pengembang Multiplayer tahu skenario mimpi buruk ini: satu aktor jahat terhubung ke server Anda, melakukan serangkaian tindakan yang tampaknya tidak berbahaya, dan tiba-tiba tick rate Anda merosot dari 60Hz ke satu digit. Seluruh server terhenti, memengaruhi puluhan pemain yang tidak bersalah.
Baru-baru ini, eksploit performa server UEFN yang kritis dilaporkan di forum Unreal Engine oleh pengembang Vysena Woyka. Laporan tersebut menguraikan teknik yang 100% dapat direproduksi yang menyebabkan degradasi parah di seluruh server pada peta Unreal Editor for Fortnite (UEFN). Eksploit ini meningkat keparahannya seiring bertambahnya jumlah pemain yang bergabung, sama sekali tidak memerlukan alat pihak ketiga, dan berpotensi menyebabkan ketidakstabilan server total dengan eksekusi yang lama.
Karena langkah-langkah reproduksi yang tepat dirahasiakan untuk mencegah penyalahgunaan yang meluas, banyak pengembang bertanya-tanya: Bagaimana eksploit seperti ini sebenarnya bekerja di balik layar? dan yang lebih penting, Bagaimana cara melindungi Unreal Engine dedicated servers kustom saya sendiri dari serangan serupa?
Dalam pembahasan teknis mendalam ini, kita akan membedah arsitektur degradasi performa sisi server di Unreal Engine. Kita akan mengeksplorasi vektor umum yang digunakan pemain jahat untuk mencekik dedicated servers, cara menerapkan validasi sisi server yang ketat menggunakan C++, dan cara merancang infrastruktur Anda untuk ketahanan maksimum.
Anatomi Eksploit Server Unreal Engine
Untuk memahami bagaimana seorang pemain dapat menjatuhkan server tanpa alat peretasan eksternal, Anda harus memahami bagaimana Unreal Engine menangani Main Game Loop-nya. Unreal Engine dedicated servers sebagian besar bersifat single-threaded dalam hal Game Logic. Meskipun tugas-tugas seperti Physics Simulation (melalui mesin fisika Chaos) dan pemuatan asinkron dapat dialihkan ke worker threads, fungsi Tick inti dari Actor Anda, Replication Serialization, dan eksekusi RPC (Remote Procedure Call) semuanya terjadi di Game Thread.
Jika server berjalan pada 30 tick per detik (30Hz), ia memiliki tepat 33,3 milidetik untuk memproses semua player inputs, memperbarui Game State, menghitung fisika, dan menserialisasikan data jaringan untuk frame berikutnya. Jika seorang pemain dapat memaksa server untuk mengeksekusi operasi yang memakan waktu 50 milidetik untuk diproses, tick rate server akan langsung turun menjadi 20Hz.
Ketika tick rate server Anda turun drastis, Anda tidak hanya mendapatkan lag visual—Anda mendapatkan divergensi status (state divergence) yang katastropik. Kami telah membahas dampak dari hal ini secara ekstensif dalam panduan teknis kami tentang The Unreal Engine Multiplayer Sync Bug Ruining Your World States And How To Fix It.
Tanpa menggunakan memory injectors atau packet editors, eksploit performa dalam game biasanya mengandalkan salah satu dari tiga vektor: RPC Flooding, Physics/Collision Overload, atau Replication Saturation.
Vektor 1: RPC Flooding dan Kegagalan Validasi
Cara paling umum untuk merusak atau mendegradasi server Unreal Engine adalah dengan melakukan spam Server RPCs. Jika klien mengikat Server RPC ke roda mouse mereka atau input framerate yang tidak terkunci, mereka dapat mengirim ratusan permintaan per detik ke server.
Jika Server RPC Anda berisi logika yang kompleks—seperti memunculkan Actor, melakukan line trace (Raycast), atau mengiterasi array besar—server dipaksa untuk mengeksekusi logika mahal tersebut ratusan kali per frame.
Unreal Engine menyediakan makro WithValidation untuk RPC, tetapi banyak pengembang hanya menggunakan ini untuk memeriksa apakah pointer valid, dan sepenuhnya mengabaikan Rate Limiting.
Solusi: Menerapkan RPC Rate Limiter C++
Untuk melindungi server Anda, Anda harus menerapkan Rate Limiting yang ketat pada semua komunikasi klien-ke-server. Berikut adalah pendekatan yang telah teruji untuk membatasi Server RPCs menggunakan Actor Component kustom di C++.
Pertama, kita tentukan logika pembatasan rate kita di file header:
// RateLimiterComponent.h
#pragma once
#include "CoreMinimal.h"
#include "Components/ActorComponent.h"
#include "RateLimiterComponent.generated."
UCLASS( ClassGroup=(Custom), meta=(BlueprintSpawnableComponent) )
class MULTIPLAYER_API URateLimiterComponent : public UActorComponent
{
GENERATED_BODY()
public:
URateLimiterComponent();
// Checks if the action is allowed. Returns false if the client is spamming.
UFUNCTION(BlueprintCallable, Category = "Security")
bool CanExecuteAction(FName ActionName, float CooldownTime);
private:
// Maps action names to the last time they were executed
TMap<FName, float> LastExecutionTimes;
// Threshold for maximum allowed actions per second before flagging the player
const int32 MaxActionsPerSecond = 20;
int32 CurrentActionCount;
float LastResetTime;
};
Selanjutnya, kita terapkan logika validasi di file CPP. Perhatikan bagaimana kita menggunakan waktu server (GetWorld()->GetTimeSeconds()) untuk memastikan klien tidak dapat memalsukan waktu lokal mereka untuk melewati cooldown.
// RateLimiterComponent.cpp
#include "RateLimiterComponent.h"
URateLimiterComponent::URateLimiterComponent()
{
PrimaryComponentTick.bCanEverTick = false;
CurrentActionCount = 0;
LastResetTime = 0.0f;
}
bool URateLimiterComponent::CanExecuteAction(FName ActionName, float CooldownTime)
{
// Only run this logic on the server
if (!GetOwner()->HasAuthority())
{
return false;
}
float CurrentTime = GetWorld()->GetTimeSeconds();
// Reset the global action counter every second
if (CurrentTime - LastResetTime >= 1.0f)
{
CurrentActionCount = 0;
LastResetTime = CurrentTime;
}
// Global spam check
CurrentActionCount++;
if (CurrentActionCount > MaxActionsPerSecond)
{
UE_LOG(LogTemp, Warning, TEXT("Player %s is exceeding global RPC limits!"), *GetOwner()->GetName());
return false;
}
// Specific action cooldown check
if (LastExecutionTimes.Contains(ActionName))
{
float LastTime = LastExecutionTimes[ActionName];
if (CurrentTime - LastTime < CooldownTime)
{
// Client is spamming this specific action
return false;
}
}
// Update the execution time and allow the action
LastExecutionTimes.Add(ActionName, CurrentTime);
return true;
}
Sekarang, saat Anda menerapkan fungsi Server_PerformAction_Validate, Anda dapat menolak RPC secara dinamis jika klien melakukan spam:
bool AMyPlayerController::Server_PerformExpensiveAction_Validate()
{
// If the rate limiter returns false, the RPC is rejected and the client is disconnected
if (URateLimiterComponent* RateLimiter = GetComponentByClass<URateLimiterComponent>())
{
return RateLimiter->CanExecuteAction(FName("ExpensiveAction"), 0.5f);
}
return true;
}
Vektor 2: Physics dan Collision Overload
Vektor eksploit umum lainnya (dan yang sangat dicurigai dalam lingkungan sandbox seperti UEFN) adalah kelebihan beban fisika. Jika pemain dapat memunculkan objek, menjatuhkan item, atau memanipulasi Physics Bodies, mereka dapat dengan sengaja menumpuk ratusan objek di ruang terbatas.
Ketika Physics Bodies tumpang tindih, mesin fisika Chaos mencoba menyelesaikan tabrakan tersebut. Jika 500 objek dipaksa masuk ke ruang koordinat yang sama, matematika penyelesaian tabrakan tumbuh secara eksponensial, menyebabkan penguncian CPU total pada server.
Selain itu, jika objek-objek ini memiliki bGenerateOverlapEvents yang disetel ke true, server akan memicu OnComponentBeginOverlap ratusan ribu kali per frame.
Solusi: Collision Culling yang Agresif
Untuk mencegah degradasi server berbasis fisika, Anda harus memisahkan fisika visual dari validasi tabrakan sisi server.
- Nonaktifkan Overlap pada Item yang Dijatuhkan: Jika pemain menjatuhkan item, nonaktifkan
bGenerateOverlapEventsdi server setelah item tersebut berhenti bergerak. - Batasi Limit Spawn: Tentukan secara kaku kepadatan maksimum objek fisika per sektor grid.
- Batasi Logika Overlap: Jika Anda harus menggunakan overlap, jangan mengeksekusi logika kompleks secara langsung di dalam event overlap. Sebaliknya, setel dirty flag dan proses overlap dalam batch yang terkontrol selama fungsi
Tick.
Vektor 3: Replication Saturation dan Pencekikan Bandwidth
Sistem replikasi Unreal Engine sangat kuat, tetapi juga sangat bergantung pada CPU. Server harus mengiterasi setiap Actor yang direplikasi, memeriksa apakah itu relevan untuk klien tertentu, membandingkan propertinya dengan status terakhir yang diakui, dan menserialisasikan perubahannya.
Pemain jahat dapat mengeksploitasi ini dengan mengubah variabel yang direplikasi secara cepat (seperti data kustomisasi karakter atau status inventaris) bolak-balik. Ini memaksa server untuk terus-menerus menserialisasikan potongan besar data, menjenuhkan CPU server dan batas bandwidth.
Solusi: Mengoptimalkan NetUpdateFrequency
Jangan pernah membiarkan NetUpdateFrequency pada nilai default-nya (100.0) untuk actor yang tidak kritis. Anda harus menskalakan frekuensi replikasi secara dinamis berdasarkan kedekatan pemain dan status tindakan.
Selain itu, Anda harus menggunakan DefaultEngine.ini untuk menegakkan batas bandwidth yang ketat pada dedicated server Anda. Ini mencegah satu klien jahat memaksa server untuk memproses aliran paket yang masif:
[/Script/OnlineSubsystemUtils.IpNetDriver]
MaxClientRate=15000
MaxInternetClientRate=10000
NetServerMaxTickRate=30
LanServerMaxTickRate=30
ConnectionTimeout=15.0
InitialConnectTimeout=30.0
Dengan membatasi MaxClientRate, server hanya akan membuang paket berlebih dari klien yang mencoba membanjiri saluran jaringan, menjaga siklus CPU untuk pemain yang sah.
Ketahanan Infrastruktur: Menangani Hal yang Tak Terelakkan
Bahkan dengan kode C++ yang sempurna, eksploit zero-day akan tetap terjadi. Ketika eksploit seperti bug performa server UEFN menghantam game kustom Anda, node server Anda pasti akan melonjak hingga 100% penggunaan CPU dan crash.
Jika seluruh arsitektur armada server Anda rentan terhadap satu titik kegagalan, Anda berisiko kehilangan pemain secara permanen. Membangun infrastruktur yang tangguh dengan perutean fallback yang tepat adalah sesuatu yang sangat kami anjurkan, seperti yang kami bahas dalam analisis arsitektur kami tentang The Stop Killing Games Campaign Vs Live Ops Architecting Server Fallbacks.
Ketika server crash karena eksploit, backend Anda harus secara instan mendeteksi node yang mati, menjalankan instance baru, dan memigrasikan pemain yang terdampak kembali ke antrean matchmaking dengan anggun tanpa kehilangan data persisten mereka.
Membangun ini sendiri memerlukan pengaturan load balancers kustom, database sharding, orkestrasi kontainer (seperti Kubernetes), dan manajemen sertifikat SSL—setidaknya 4-6 bulan pekerjaan teknik khusus. Dengan horizOn, layanan backend ini sudah dikonfigurasi sebelumnya. Infrastruktur kami secara otomatis memantau kesehatan server, melakukan auto-scale instance berdasarkan beban CPU, dan menangani perutean sesi pemain, membiarkan Anda fokus pada perbaikan kode game alih-alih melawan infrastruktur Anda.
5 Praktik Terbaik untuk Stabilitas Server
Untuk melindungi game Multiplayer Unreal Engine Anda dari eksploit performa, terapkan lima aturan arsitektur ini segera:
- Terapkan Kuota RPC yang Ketat: Jangan pernah mempercayai input rate klien. Gunakan komponen rate limiter C++ yang dirinci di atas untuk menegakkan cooldown keras pada setiap Server RPC.
- Sanitasi Vektor Pergerakan: Eksploit speed hack dan teleportasi bekerja dengan mengirimkan vektor masif ke server. Selalu batasi permintaan
AddMovementInputdanSetActorLocationdi sisi server terhadap kecepatan gerakan teoretis maksimum karakter. - Gunakan Replication Graph: Jika game Anda mendukung lebih dari 40 pemain, sistem replikasi default akan menjadi hambatan. Terapkan Unreal Engine Replication Graph untuk mengelompokkan actor secara spasial dan secara drastis mengurangi overhead CPU dari pemeriksaan relevansi.
- Nonaktifkan Visual Sisi Server: Dedicated servers tidak boleh memuat UI, sistem partikel, atau animasi skeletal mesh. Pastikan pengaturan proyek Anda secara ketat menghapus aset-aset ini dari build dedicated server untuk membebaskan memori dan siklus CPU.
- Pantau Tick Rate Secara Dinamis: Terapkan subsistem sisi server yang memantau rata-rata delta time. Jika server mendeteksi tick rate turun di bawah 15Hz selama lebih dari 5 detik, ia harus secara otomatis menjeda tugas latar belakang yang tidak penting (seperti spawning AI atau pembuatan event ambient) untuk pulih.
Kesimpulan
Eksploit performa server UEFN baru-baru ini adalah pengingat keras bahwa pengembangan game Multiplayer pada dasarnya adalah latihan dalam keamanan siber. Anda tidak bisa begitu saja percaya bahwa pemain akan berinteraksi dengan game Anda sebagaimana mestinya. Setiap RPC, setiap interaksi fisika, dan setiap variabel yang direplikasi adalah vektor serangan potensial.
Dengan mengubah pola pikir Anda ke model "Server-Authoritative, Client-Distrusted", mengoptimalkan logika replikasi C++ Anda secara mendalam, dan menerapkan batas rate yang ketat, Anda dapat memperkuat game Anda terhadap jenis crash performa yang katastropik ini.
Ketika Anda menggabungkan kode game yang antipeluru dengan infrastruktur server yang dapat melakukan auto-scaling dan self-healing, Anda menciptakan lingkungan di mana eksploit menjadi gangguan kecil alih-alih bencana yang mematikan game. Siap untuk menskalakan backend Multiplayer Anda tanpa pusing dev-ops? Coba horizOn secara gratis dan biarkan kami menangani orkestrasi server Anda.