Esat
Yeni Üye
- Katılım
- 21 Şub 2024
- Mesajlar
- 49
- Tepkime puanı
- 11
- Puanları
- 0
Stack walking genellikle bir fonksiyonun hook'lanması ve bu fonksiyonu kimin çağırdığını bulmak için stack'i dolaşmayı içerir. Bu, video oyunu hilelerinin klavye bilgilerini, konsola yazdırma veya matematiksel ifadeleri hesaplama gibi çeşitli amaçlar için kullandığı işlevler gibi yaygın işlevleri de içerir.
Video oyunu hileleri, varlıklarını bellekte veya diskte gizlemek için çabalarlar, böylece hile karşıtı yazılım tarafından bulunamazlar. Fakat, hile programlarının unuttuğu bir şey var: Diğer kütüphanelerdeki işlevleri düzenli olarak çağırırlar ve bu, bu bilinmeyen hileleri sezgisel olarak tespit etmek için kullanılabilir.
Örneğin,
gibi yaygın işlevler üzerinde bir stack walking yöntemi uygulayarak, kendilerini gizleseler bile bu hileleri bulabilirsiniz.
BattlEye, stack walking'i uygulayan ancak kamuya açık bir şekilde kanıtlanmamış bir yöntemdir. Burada "stack walking" terimi etrafındaki tırnak işaretlerine dikkat etmek önemlidir çünkü bu gerçek bir stack walking değildir. Bu, sadece bir dönüş adresi kontrolü ve bir arayan dökümüdür. Gerçek bir stack walker, yığını dolaşır ve düzgün bir çağrı yığını (call stack) oluşturur.
Hile karşıtı sistem, oyun oynarken oyun sürecine dinamik olarak shell kodu gönderir. Bu shell kodları farklı boyutlarda ve farklı amaçlar için kullanılır ve aynı anda yayınlanmazlar. Bu sistem, araştırmacıların rekabetçi bir maç sırasında anti-hileyi dinamik olarak analiz etmelerini gerektirir, bu da anti-hilenin özelliklerini belirlemeyi zorlaştırır.
Anti-hilenin farklı kullanıcılara farklı önlemler uygulamasına da olanak tanır. Örneğin, sadece anormal bir öldürme/ölüm oranına sahip bir kişiye daha invaziv bir modül yayınlayabilirler. Bu shell kodlarından biri, yığın analizini yapmaktan sorumlu olup marjinal olarak daha küçük boyutu nedeniyle shellcode8kb olarak adlandırılır. Bu küçük shell kodu, bir vektörlü exception handler kurarak başlar ve ardından belirli işlevlerde breakpoint tuzakları kurar.
Tuzaklar, yaygın olarak kullanılan işlevlerin ilk komutunu bir breakpointe ayarlayarak çalışır. Bu breakpoint ayarlandığında, ilgili işleve yapılan tüm çağrılar, tam kayıt ve yığın erişimine sahip olan istisna işleyiciden geçer. Bu erişimle, exception handler stack'ın en üstünden çağıran adresini döker ve belirli koşullar karşılanırsa, çağıran işlevin 32 baytını döker ve 0x31 rapor kimliğiyle BattlEye sunucularına gönderir.
Örnek raporu, exception handler'ın bellek sayfasının değiştirilmiş veya bilinen bir işlem modülüne ait olmayan tüm arayanları reddedeceğini görebiliriz. Ayrıca, NtQueryVirtualMemory çağrısının tamamen başarısız olduğu durumlarda, hilecilerin bu sistem çağrısını hook'lamasını ve modüllerini stack dumper'ından gizlemesini önler.
Bu koşul aslında oldukça ilginçtir. BattlEye geliştiricileri, insanların oyunlarında bu hile yöntemini kullandığını fark etti ve doğrudan hedef almaya karar verdi. BattlEye'ın sunucusuna gönderilen tam yapı şöyledir:
Uyarı: Bu yazı BattlEye gibi büyük bir anti-hile sağlayıcısının sezgisel tekniklerinden birine, yani stack walking'e odaklanmaktadır.
Kaynak: Secret.Club
Video oyunu hileleri, varlıklarını bellekte veya diskte gizlemek için çabalarlar, böylece hile karşıtı yazılım tarafından bulunamazlar. Fakat, hile programlarının unuttuğu bir şey var: Diğer kütüphanelerdeki işlevleri düzenli olarak çağırırlar ve bu, bu bilinmeyen hileleri sezgisel olarak tespit etmek için kullanılabilir.
Örneğin,
Kod:
stdrintBattlEye, stack walking'i uygulayan ancak kamuya açık bir şekilde kanıtlanmamış bir yöntemdir. Burada "stack walking" terimi etrafındaki tırnak işaretlerine dikkat etmek önemlidir çünkü bu gerçek bir stack walking değildir. Bu, sadece bir dönüş adresi kontrolü ve bir arayan dökümüdür. Gerçek bir stack walker, yığını dolaşır ve düzgün bir çağrı yığını (call stack) oluşturur.
Hile karşıtı sistem, oyun oynarken oyun sürecine dinamik olarak shell kodu gönderir. Bu shell kodları farklı boyutlarda ve farklı amaçlar için kullanılır ve aynı anda yayınlanmazlar. Bu sistem, araştırmacıların rekabetçi bir maç sırasında anti-hileyi dinamik olarak analiz etmelerini gerektirir, bu da anti-hilenin özelliklerini belirlemeyi zorlaştırır.
Anti-hilenin farklı kullanıcılara farklı önlemler uygulamasına da olanak tanır. Örneğin, sadece anormal bir öldürme/ölüm oranına sahip bir kişiye daha invaziv bir modül yayınlayabilirler. Bu shell kodlarından biri, yığın analizini yapmaktan sorumlu olup marjinal olarak daha küçük boyutu nedeniyle shellcode8kb olarak adlandırılır. Bu küçük shell kodu, bir vektörlü exception handler kurarak başlar ve ardından belirli işlevlerde breakpoint tuzakları kurar.
Tuzaklar, yaygın olarak kullanılan işlevlerin ilk komutunu bir breakpointe ayarlayarak çalışır. Bu breakpoint ayarlandığında, ilgili işleve yapılan tüm çağrılar, tam kayıt ve yığın erişimine sahip olan istisna işleyiciden geçer. Bu erişimle, exception handler stack'ın en üstünden çağıran adresini döker ve belirli koşullar karşılanırsa, çağıran işlevin 32 baytını döker ve 0x31 rapor kimliğiyle BattlEye sunucularına gönderir.
Örnek raporu, exception handler'ın bellek sayfasının değiştirilmiş veya bilinen bir işlem modülüne ait olmayan tüm arayanları reddedeceğini görebiliriz. Ayrıca, NtQueryVirtualMemory çağrısının tamamen başarısız olduğu durumlarda, hilecilerin bu sistem çağrısını hook'lamasını ve modüllerini stack dumper'ından gizlemesini önler.
Bu koşul aslında oldukça ilginçtir. BattlEye geliştiricileri, insanların oyunlarında bu hile yöntemini kullandığını fark etti ve doğrudan hedef almaya karar verdi. BattlEye'ın sunucusuna gönderilen tam yapı şöyledir:
Bash:
struct __unaligned battleye_stack_report
{
__int8 unknown;
__int8 report_id;
__int8 val0;
__int64 caller;
__int64 function_dump[4];
__int64 allocation_base;
__int64 base_address;
__int32 region_size;
__int32 type_protect_state;
};Uyarı: Bu yazı BattlEye gibi büyük bir anti-hile sağlayıcısının sezgisel tekniklerinden birine, yani stack walking'e odaklanmaktadır.
Kaynak: Secret.Club
Moderatör tarafında düzenlendi:
