Call of Duty Anti-Cheat’in Tersine Mühendislik Analizi

 (ssno.cc)
1 puan yazan GN⁺ 2025-01-21 | 1 yorum | WhatsApp'ta paylaş
  • Black Ops Cold War’daki TAC(Treyarch Anti-Cheat), Ricochet çekirdek sürücüsü olmayan kullanıcı modu bir anti-cheat olsa da, güncel Call of Duty serileriyle büyük ölçüde benzer bir kod yapısına sahip
  • Koruma katmanı, Arxan’ın çalıştırılabilir dosya şifreleme, checksum, jmp obfuscation ve entrypoint obfuscation özelliklerini Treyarch/IW serisi pointer şifrelemesiyle birlikte kullanıyor
  • TAC; çalışma zamanında API hash araması, API hook kalıbı denetimi, debug register kontrolü, Windows test imzası algılama, konsol ayırma algılama, DirectX/overlay tespiti gibi çeşitli kullanıcı modu tespitleri yapıyor
  • Harici overlay’ler için pencere stili, konumu, display affinity ve süreç modül listesi toplanıp sunucuya yükleniyor; Cheat Engine türü bellek tarayıcıları ise sanal bellek honeypot’u ile tespit edilebiliyor
  • En özgün teknik, şifrelenmiş özel syscall stub’ları: ntdll hook’larını atlatıyor ve syscall kaynağını başka bir ntdll fonksiyonu gibi göstererek izlemeyi zorlaştırıyor

Analiz hedefi ve kapsamı

  • Analiz hedefi, Black Ops Cold War içindeki kullanıcı modu anti-cheat; adlandırma olarak TAC(Treyarch Anti-Cheat) kullanılıyor
  • Black Ops Cold War’da Modern Warfare 2019 ve sonraki oyunlarda bulunan Ricochet’in çekirdek modu bileşeni yok
  • Güncel Call of Duty ile en büyük fark çekirdek modu sürücüsü; anti-cheat kodunun büyük bölümü kullanıcı modunda ve TAC ile çok benzer
  • Fonksiyon pseudocode’ları, gerçek decompile çıktıları obfuscation ve çözümleme kodları nedeniyle karmaşık olduğundan yeniden yapılandırılmış biçimde
  • Bazı içerikler, hile veya bypass tanıtımından kaçınmak için silinmiş

Arxan ve çalıştırılabilir dosya koruması

  • Arxan, Black Ops 3’ten beri birçok Call of Duty oyununda kullanılan bir obfuscation ve koruma aracı
  • Çalışma zamanında çalıştırılabilir dosya decryption’ı
    • Oyun çalıştırılabilir dosyası pack’lenmiş ve şifrelenmiş durumda
    • Arxan, başlangıç sürecine kod enjekte ederek gerçek oyun çalıştırılabilir dosyasını unpack edip decrypt ediyor
  • Çalıştırılabilir dosya checksum’u
    • Arxan, oyun çalıştırılabilir dosyasına yapılan patch’leri sürekli izliyor
    • Debugger veya checksum uyuşmazlığı tespit edilirse süreci sonlandırıyor
  • jmp obfuscation
    • Statik analizi zorlaştırmak için fonksiyondaki talimatların arasına çok sayıda jmp ekliyor
    • Büyük fonksiyonlara yüzlerce jump eklendiğinde IDA analizi bozuluyor ve harici araçlar gerekiyor
  • Entrypoint obfuscation
    • Korunan Arxan kodu gerçek entrypoint’i unpack edip çalıştırıyor
    • Bu bölüme de jmp obfuscation girebildiği için akış takibi zorlaşıyor

Pointer şifreleme

  • Önemli pointer’lar kullanılmadan hemen önce şifrelenip çözülüyor
    • Mevcut oyun global nesnesi
    • Entity dizisi
    • Object pointer’ları vb.
  • Aynı şifreleme yönteminin 16 varyantı var; hangi yöntemin kullanılacağını mevcut PEB adresi belirliyor
  • Bu yöntem Cheat Engine’in pointer scan’ini engelliyor
    • Global değerlerde yalnızca şifrelenmiş değer tutuluyor
    • Decrypt edilmiş değer yalnızca stack’te bulunuyor
  • Decrypt edilmiş pointer’ı elde etmek için decrypt talimatlarını izleyen bir araç kullanmak veya oyunun zaten decrypt ettiği noktaya hook koymak gerekiyor

Çalışma zamanında API araması ve hook tespiti

  • TAC inline edilmiş çalışma zamanı API arama fonksiyonları kullanıyor
    • Modül hash’i ve API adı hash’i alıyor
    • Yüklü modül listesini dolaşıp adları hash’liyor
    • Modülün export fonksiyonlarını dolaşıp compile-time hash ile karşılaştırıyor
  • Hash tanımlama, oyun sürecindeki yüklü modül listesi ve oyunun hashing fonksiyonu kullanılarak yapılıyor
    • Modül adı ve export adının hash’i hesaplanıyor
    • Decompile sonucundan base hash ve function hash manuel alınarak hangi API’nin çağrıldığı eşleştiriliyor
  • Hash’ler oyun sürümüne göre aynı değil
  • Fonksiyon pointer’ları global değişkenlerde saklandığı için, sanal adresi yüklü DLL’in export fonksiyonlarıyla karşılaştırarak da tanımlama yapılabiliyor
  • TAC’nin API hook tespiti şu anda yalnızca 7 kalıbı kontrol ediyor
    • push/movabs/xchg/ret serisi stub’lar
    • push imm ardından ret
    • call
    • jmp [rip+x]
  • Tüm önemli API’leri kontrol etmiyor; kendi kullandığı API’ler üzerindeki hook’ları kontrol ediyor

Debug register ve sürücü test imzası algılama

  • Debug register’lar, Arxan’ın .text patch izlemesini atlatan kod dışı patch hook yöntemi olarak kullanılabilir
  • TAC thread context içinde DR0~DR3 değerlerini kontrol ediyor
    • Değer varsa, mevcut sürecin içinde olup olmamasına göre farklı mesajla callback çağırıyor
    • Ardından akış sonlandırma fonksiyonuna gidiyor
  • DR0~DR3 privileged register olduğu için normal assembly ile doğrudan okunamaz; Windows kernel veya exception aktarımı yoluyla alınmaları gerekir
  • Windows test modu, normal imzası olmayan çekirdek modu sürücülerinin çalışmasına izin verir
  • TAC, NtQuerySystemInformation ile test imzasının etkin olup olmadığını kontrol ediyor
    • Yalnızca bu tespitle doğrudan ban uygulanmıyor, ancak hesap flag’leniyor

Süreci sonlandırma yöntemi

  • TAC süreci iki yöntemle sonlandırıyor
  • İlk yöntem, register’ları temizledikten sonra NtTerminateProcess çağırıyor
    • RCX değerini -1 olarak ayarlıyor
    • NtTerminateProcess hook’lanmış olarak tespit edilirse bu yöntemi kullanmıyor
  • İkinci yöntem, register’ları temizledikten sonra 0x0 adresine jump ederek süreci crash ettiriyor
  • İki yöntem de önemli register’ları temizlediği için kurtarma zor

Konsol, görselleştirme ve overlay tespiti

  • Dahili hileler log çıktısı veya menü uygulamak için AllocConsole kullanabilir
  • TAC, konsol penceresini veya PEB’deki ConsoleHandle değerini kontrol ederek konsol ayırmayı tespit ediyor
  • Dahili görselleştirme çoğunlukla grafik API hook’u ile ekrana çizilir
    • Güncel Call of Duty DirectX 12 kullanıyor
    • Yaygın hook hedefi IDXGISwapChain::Present
    • DirectX 12’de command queue gerekir; ID3D12CommandQueue::ExecuteCommandLists yaygın bir elde etme noktasıdır
  • OBS Studio, Streamlabs OBS, Discord oyun overlay’i ve Steam oyun overlay’i de benzer konumlarda çalışabilir
    • Steam ve Discord çizim yapar
    • OBS serisi, game capture kullanıldığında render edilen görüntüyü yakalar
  • TAC şu anda DXGI present fonksiyonunun kendisini taramıyor; vtable’daki present pointer’ını kontrol ediyor

Harici hileler ve pencere tabanlı tespit

  • Harici hilelerin oyun penceresinin üstünü kaplayan overlapped window oluşturma olasılığı yüksek
  • TAC tüm pencereleri dolaşıp GetWindowLongA ile WS_EX_LAYERED stilini kontrol ediyor
  • Ardından GetWindowRect ile oyun penceresiyle çakışıp çakışmadığını karşılaştırıyor
    • Çakışma oranı 0.5 veya üzerindeyse ve cache sayısı 8’den azsa ilgili hwnd değerini kaydediyor
    • Örnek ekran boyutu olarak 1920x1080 değerine karşılık gelen değer görünüyor
  • Cache’lenen pencereler ayrı bir fonksiyonda ek olarak inceleniyor
    • GetWindowTextW ile pencere metni kontrolü
    • GetClassNameA ile sınıf adı kontrolü
    • GetWindowDisplayAffinity ile display affinity kontrolü
  • Kayıt ve ekran görüntüsü araçlarından gizlenmek için SetWindowDisplayAffinity ve WDA_EXCLUDEFROMCAPTURE kullanılması durumunu da TAC kontrol ediyor
  • Pencereyle ilgili bilgiler şifreli buffer’a kaydedilip sunucuya yükleniyor
    • Pencere metni
    • Sınıf adı
    • Pencere konumu ve stili
    • Display affinity
    • Çakışan pencere sürecinin modül listesi ve exe adı
  • Çakışan pencere süreci OpenProcess(PROCESS_VM_READ | PROCESS_QUERY_INFORMATION) ile açılıyor; K32EnumProcessModules ve K32GetModuleFileNameExW ile modül adları toplanıyor

Cheat Engine türü bellek tarayıcılarını tespit etme

  • Cheat Engine, Windows sanal bellek davranışı nedeniyle kolay tespit edilir
  • Bir program VirtualAlloc ile sanal bellek ayırsa bile, erişilmeden önce fiziksel bellek tarafından backing yapılmaz
  • Oyun bellek ayırdıktan sonra onu kullanmayabilir
  • Cheat Engine veya Process Hacker’ın bellek sekmesi bu alanı tararsa erişim oluşur ve bellek valid duruma gelir
  • TAC tarzı honeypot, K32QueryWorkingSetEx ile ilgili sanal adrese gerçekten erişilip erişilmediğini kontrol ederek bellek tarayıcılarını tespit eder

Signature scan’i engelleme

  • Oyun hacker’ları, güncellemelerden sonra da hilelerin otomatik çalışması için sıkça signature scanning kullanır
  • Treyarch’ın fikri, tekrar çağrılmayacak bir fonksiyonda return address çevresini PAGE_NOACCESS ile korumak
  • Signature scanner, çalıştırılabilir dosya byte’larını baştan sona okuyarak kalıp arar
  • Her byte için erişilebilirlik sorgulanırsa çok yavaş olacağı için, PAGE_NOACCESS bölgesine ulaşıldığında süreç crash edebilir
  • Bu yöntem tam bir engel değildir, ancak birçok analizciyi zorlayabilir

Anti-debugging

  • TAC’nin kendi anti-debug kontrolleri basit, ancak Arxan da ayrı anti-debug teknikleri sağlıyor
  • TAC mevcut sürecin tüm thread’lerini dolaşıyor
    • CreateToolhelp32Snapshot ve thread snapshot kullanıyor
    • Her thread’in TEB’indeki DbgSsReserved değerini kontrol ederek DebugObject varlığını tespit ediyor
  • Geçersiz belleğe yazma yaparak access violation oluşturma tekniği de var
    • Kod exception sonrasındaki noktaya ulaşırsa debugger’ın exception’ı işlediği veya bypass ettiği varsayılıyor
  • CheckRemoteDebuggerPresent de kullanılıyor
  • ThreadHideFromDebugger, exception’ların debugger’a değil sürece gönderilmesini sağlıyor
    • Debugger süreci durdurmaya çalıştığında STATUS_BREAKPOINT exception’ı oluşup süreç sonlanabilir
    • Kullanıcı modunda bu flag unset edilemez
    • Bu taktik, çalıştırılabilir dosya entrypoint’inden önce TLS callback içinde çalıştırılıyor

Ağ trafiği izleme

  • TAC tüm aktif bağlantıları saklamıyor, yalnızca belirli koşulları arıyor
  • Tespit hedefi, oyun süreci içinde yerel ağ sunucusu oluşturma yöntemi
    • Hileci shellcode’u oyun sürecine yazıyor
    • Oyun süreci içinde ağ sunucusu başlatıyor
    • Harici uygulama bu yerel sunucuyla bilgi alışverişi yapıyor
  • TAC GetTcpTable2 ile TCP tablosunu alıyor; mevcut sürecin oluşturduğu bağlantılar ile başka süreçlerin port ilişkisini karşılaştırarak koşulu tespit ediyor

Şifrelenmiş özel syscall stub’ları

  • ntdll’in birçok export API’si içeride syscall gerçekleştirir
  • Özel syscall stub’ları kullanılırsa, kullanıcı modu hileleri ntdll fonksiyonlarını hook’lasa bile atlatılabilir
  • Syscall instrumentation callback’e görünebilir
    • Instrumentation callback syscall sonrasında çağrılır
    • Dönüş adresi syscall instruction’ın hemen sonrası olur
  • TAC, statik analizi zorlaştırmak için şifrelenmiş syscall stub’ları kullanıyor
  • Stub, .text section’ında ayrılan büyük bir alan write/execute olarak korunduktan sonra oluşturuluyor
  • NtReadFile içinde syscall instruction’ı buluyor ve CPU zaman değerini rastgelelik unsuru olarak kullanıp konumu değiştiriyor
  • İzleyen tarafta syscall rastgele bir ntdll fonksiyonundan gelmiş gibi görünebilir
    • Gerçek syscall NtReadFile olmayabilir
    • eax içindeki syscall index’i kontrol edilemezse hangi syscall olduğunu anlamak zorlaşır
  • Yeniden çalıştırıldığında syscall instruction konumunun değiştiğine dair örnek var

Anti-debugger gizleme bypass tespiti

  • ThreadHideFromDebugger ayarlamak için NtSetInformationThread çağrılmalıdır
  • Hileci bu API’yi hook’layıp başarı döndürmesini sağlayabilir
    • Böylece anti-cheat gizleme ayarının başarılı olduğuna inanır, ama gerçekte hiçbir şey olmayabilir
  • TAC, kötü yazılmış hook’ları yakalamak için hatalı argümanlar verip çağrı sonucunu kontrol ediyor
    • Uzunluk argümanı uymadığı için başarısız olması gereken çağrı başarılı olursa tespit ediyor
    • Debugger ve ScyllaHide ortamında farklı dönüş değerleri çıktığına dair örnek var
    • Sahte handle verip ThreadHideFromDebugger isteğine koşulsuz başarı döndüren hook’u da kontrol ediyor

Uzak thread oluşturmayı engelleme

  • TAC, STATUS_PRIVILEGED_INSTRUCTION exception’ında mevcut thread’e TerminateThread çağıran bir exception handler kuruyor
  • Manual mapping DLL’in uzak süreçte shellcode çalıştırmanın bir yoluna ihtiyacı vardır; yaygın yöntem CreateRemoteThread’dir
  • Windows PE’nin TLS callback’i, thread oluşturulduğunda thread entrypoint’inden önce çağrılabilir
  • TAC yeni thread context’inde başlangıç adresini kontrol ediyor
    • NtQueryInformationThread ile Win32 start address’i alıyor
    • Yüklü modül listesini dolaşıp başlangıç adresinin normal modül aralığında olup olmadığını kontrol ediyor
  • Başlangıç adresi yüklü herhangi bir modül aralığında değilse tespiti kaydediyor ve privileged instruction exception’ı oluşturarak ilgili thread’i sonlandırıyor

Diğer kontroller ve sonuç

  • Bilinmeyen bir kontrol olarak NtQuerySystemInformation içindeki AllocationGranularity değerinin 0x10000 olup olmadığını kontrol eden kod var
    • Sanal makineyi veya özel Windows sürümünü flag’liyor gibi görünüyor
  • TAC bağlı modül listesine büyük ölçüde bağımlı olduğundan, PEB’deki InMemoryOrderModuleList’in boş liste olup olmadığını kontrol ediyor
    • Boş liste haline getirilirse sürecin kendisinin bozulma olasılığı var
  • Sonuç olarak TAC şu özelliklere sahip kullanıcı modu bir anti-cheat
    • Çalışma zamanında API araması
    • Kötü yazılmış hook tespiti
    • Harici overlay tespiti
    • Dahili DirectX hook tespiti
    • Kullanılan API’lerde hook kontrolü
    • Debugger ve debugging izleri kontrolü
    • AllocConsole tespiti
    • CreateRemoteThread tespiti
    • spoofed ve encrypted syscall stub’ları
  • Arxan; güçlü obfuscation, statik analizi zorlaştırma, IDA Pro’yu bozan teknikler, .text değişikliklerini izleme ve kendi anti-debug özellikleriyle TAC’yi destekliyor
  • TAC’ye benzer kod modern Call of Duty oyunlarında da kullanılıyor

İlgili okumalar

1 yorum

 
GN⁺ 2025-01-21
Hacker News yorumları

  • 2021’de Linux CS:GO hesabımda güven faktörü sorunları yaşandı; önce sarıya, sonra kırmızıya düştü ve resmi bir ban olmasa da fiilen bir yaptırım gibi işliyordu.
    Sonuç olarak sürekli hilecilerle eşleştirildim ve takım arkadaşı bulmak zorlaştı.
    Daha sonra Radeon GPU ve 16 GB’tan fazla VRAM kullanan başka Linux kullanıcılarının da benzer sorunlar yaşadığını öğrendim ve sorunu takip etmek için bir GitHub issue’su açtım: https://github.com/ValveSoftware/csgo-osx-linux/issues/2630
    Araştırınca Valve’ın belirli donanım yapılandırmalarına, özellikle de o dönem oldukça yeni sayılan 16 GB+ VRAM’li Radeon kartlara sahip Linux kullanıcılarını cezalandırıyor gibi göründüğü anlaşıldı.
    Sonunda bir kullanıcı doğrudan gaben’e ulaştıktan sonra sorun düzeltildi: https://github.com/ValveSoftware/csgo-osx-linux/issues/2630#...
    Bunun, Steam Deck çıkışına hazırlanan Valve’ın Linux kullanıcı deneyimini önemsemesinin sonucu olabileceği tahmin ediliyor.

    • Belki de Gabe Newell sadece iyi bir insandır?
    • Linux kullanıcılarını cezalandırmanın Linux kullanıcı deneyimini nasıl iyileştirdiğini pek anlayamıyorum.
      Yine de ilginç.
    • Güven faktörünün sarıya, kırmızıya düştüğünü nasıl anlayabildiklerini merak ediyorum.
      Oyun kalitesi kötüleştiği için mi tahmin ettiler, yoksa bunu doğrulamanın bir yolu mu vardı bilmiyorum.
      Anladığım kadarıyla güven faktörü, kötüye kullanımı önlemek için gizli tutuluyor.

  • Hile eninde sonunda bir insan sorunu.
    Yazıda anlatılan güvenlik önlemleri ve sezgisel yöntemlerle bariz hilecilerin %90’ı yakalanabilir; böyle bir anti-cheat’in temelde doğru yönde olduğunu düşünüyorum.
    Ancak anti-cheat muhafazakâr çalışmalı ve nihai çözüm oyuncular ile yöneticilerden gelmeli.
    Çevrim içi çok oyunculu oyunlar mutlaka insanlar tarafından yönetilen sunucularda çalışmalı ve oyuncuların bağlı olduğu sürenin çoğunda bir yönetici bulunmalı.
    Mümkünse oyuncuların tanıdığı bir yönetici olması daha da iyi; yönetici yokken de oylamayla atma veya oylamayla banlama gibi daha hafif moderasyon yolları mümkün olmalı.
    Bir hileciyi uzaklaştırmak ile sohbeti kötüye kullanan birini uzaklaştırmak arasında özünde bir fark yok.
    Sonuçta çevrim içi çok oyunculu oyunlarda uygulanabilir tek sunucu biçiminin özel sunucular veya topluluk sunucuları olduğunu düşünüyorum.
    Hilecileri ve kötüye kullananları kontrol etme süreci, bir bildirim sistemiyle alınıp asenkron işlenecek şekilde olmamalı; oyun yöneticileri hızlıca atma veya banlama yapmalı.
    Çevrim içi oynanış yalnızca yayıncının matchmaking sunucularıyla mümkünse ve hileci ya da sohbeti kötüye kullananlara yönelik işlem sadece web formu üzerinden bildirimden ibaretse, o oyunu satın almayın veya oynamayın; cüzdanınızla oy verin.

    • Çevrim içi çok oyunculu oyunların mutlaka insanlar tarafından yönetilen sunucularda çalışması gerektiği şartı, ölçek düşünülünce epey saçma.
    • Bu, sanki her oyuna herkesin görebildiği bir hakem koyup her ihlalde video incelemesi yaptırma önerisi gibi geliyor.
      Hakemleri denetleyen ayrı bir organizasyon bile kurulabilir ama en iyisi sadece oyunu oynamak.
    • Neden insan yönetiminin tek uygulanabilir çözüm olduğunu düşündüğünü anlamıyorum.
      Apex Legends güçlü raporlama ve anti-cheat sistemleriyle gayet iyi işliyor; Rocket League’de de büyük ölçüde otomatik moderasyon etkili çalışıyor.
    • Genel olarak katılıyorum ama başka yollar da var.
      Telefon numarası, fotoğrafla manuel doğrulama, rekabetçi maçtan önce 10 saat oynama şartı, diğer oyuncuların referansları veya bunların üstüne 5 dolarlık tek seferlik oyun geçişi gibi yöntemler de mümkün.
      Henüz izlemediyseniz Valve’ın yapay zeka anti-cheat sunumunu öneririm.
      Çalışma oldukça ilginç ve hilecilerin %99’unu yakaladığını iddia ediyor.
      Elbette çok incelikli hile yöntemleri hâlâ var.

  • Activision’ın haksız kalıcı banını geri çevirmek için 2 yıllık bir hukuk mücadelesi verdim; Activision hileye dair tek bir kanıt sunamadı ve davayı kaybetti: https://antiblizzard.win/2025/01/18/my-two-year-fight-agains...

    • League of Legends’da da aynı şeyi yaşadım.
      Hiç hile yapmamış olmama rağmen açıklama yapılmadan banlandım; düzenli olarak oynadığım üç hesabım vardı ve diğer ikisi banlanmadı.
      Müşteri desteği sürekli yalnızca “inceleme sonucunda banın doğru olduğu görüldü” dedi ve neyi yanlış yaptığımı düzeltebilmem için hiçbir bilgi vermedi.
      Oyundaki en nadir skinlerden birkaçına sahibim, 2009’dan beri binlerce saat oynadım ve yalnızca ARAM oynuyorum; en casual modda, duygusal değeri yüksek bir hesabı riske atarak hile yaptığım fikri hiç mantıklı değil.
      Oyunlarla ilgili bundan daha stresli bir şey yaşamadım; sektörden bir tanıdığım içeriden kontrol ettirdiği için banım sebepsiz yere kaldırıldı.
      Hâlâ oynuyorum ama neredeyse her seferinde o haksız ban aklıma geliyor ve League, zaman ayıracağım son rekabetçi çok oyunculu oyun olacak gibi.
      Aynı şeyin tekrar yaşanmasından korktuğum için artık oynamak istemediğim de oluyor.
    • Ben de haksız kalıcı ban yedim.
      Konsolda hile yapmak neredeyse imkânsız; ranked’da zar zor vasat bir Gold 1’e çıkmam çok uzun sürdü ve herhangi bir davranışım nedeniyle hiç uyarı ya da rapor almadım, buna rağmen açıklamasız şekilde kalıcı banlandım.
      Yazarı gibi mücadele etmek yerine Activision ürünlerine bir daha para harcamamaya karar verdim; bence herkes de böyle yapmalı.
    • Oyunda iyi oynadığınızda birinin profilinize bakıp oynama sürenizi kontrol ederken doğrudan “Ben hileciyim” şeklinde kırmızı bir etiket görmesi kısmı, bu etiketin iftira sayılıp sayılamayacağını merak ettiriyor.
      ABD’de muhtemelen daha zordur ama Birleşik Krallık’ta ya da İngiltere’de, davalının bunun gerçek olduğunu kanıtlaması gerektiğini anlıyorum.
    • Böyle bir mücadele vermek zorunda kalmaları korkunç.
      Çok oyunculu shooter’ları neredeyse hiç oynamadığım için şanslıyım; koca Steam kütüphanemi kaybetmekten gerçekten nefret ederdim.
    • Bu yazı tek başına ayrı bir gönderiyi hak ediyor; çok ilginç bir yazı.

  • Jump obfuscation beni çok meraklandırıyor
    Tersine mühendislikle daha fazla uğraşmış biri yanıtlayabilirse iyi olurdu
    Koşulsuz jump'ların belirli ön koşullarla ayıklanamayacak kadar yaygın olup olmadığını merak ediyorum; fonksiyon sonlarında return olduğu için bulması kolay görünüyor ama stack'i analiz edip fonksiyonun nereye döndüğünü anlayarak return adresinin hemen önündeki call'u bulma yöntemi mümkün mü?
    x86 assembly programlamasını çok yapmadığım için çalışma şeklini yanlış anlamış olabilirim

    • angr veya https://github.com/cea-sec/miasm gibi emülatörlerle symbolic execution yaparak control flow graph flattening'i çözmeye yarayan harika teknikler var
      Intel'in PIN framework'üyle de ilginç analizler yapılabilir
      Yardımcı olabilecek yazılar şurada: https://calwa.re/reversing/obfuscation/binary-deobfuscation-..., https://www.nccgroup.com/us/research-blog/a-look-at-some-rea...
    • Koşulsuz jump'lar çok yaygındır ve optimizasyon sonrası x86 assembly genel olarak epey dağınıktır
      Birçok fonksiyon ret ile bitmez
    • Guitar Hero 3'ün bir bölümünü tersine mühendislikle inceleyen bu video, oyun kodunu güçlü biçimde obfuscate etmek için kullanılan benzer teknikleri ele aldığı için ilginç olabilir: https://www.youtube.com/watch?v=A9U5wK_boYM
    • Bazı yaygın sorunlar var
      Bazı jump'lar sahtedir, bazıları da bir komutun içine atlar
      Decompiler, aynı konumda iki komutun bulunduğu durumları işleyemez
      Örneğin jmp 0x1234 içinde jmp opcode'unu atlayıp 0x1234 kısmını geçerli bir komut varsaymak gibi
      Bazı dallarda stack bozulmuş olur, ama bu kasıtlı olarak exception oluşturmak için yapılmış olabilir
      Bu yüzden lea RAX, [rsp + 0x99999999999] gibi komutları nop ile değiştirip decompile işlemini düzeltebilirsiniz, ama kasıtlı exception'ı kaçırabilirsiniz
      IDA bunları iyi işleyemediği için Binary Ninja lisansı kullanıyorum; decompiler için fonksiyonları inline eden script'ler kolayca yazılabiliyor
      IDA'da jump'lar arasındaki kod parçaları yalnızca tek bir fonksiyona ait olabildiğinden, jump'ların kod parçalarını birbirleriyle yeniden kullandığı durumları düzgün işleyemediğini düşünüyorum
      Binary Ninja'nın Blizzard oyunlarında bir bug'ı olduğu için insanlar onu daha az kullanıyor gibi, ama yaklaşık 1 yıl önce bir bug raporuyla düzeltildi
    • Bu belirli jump'lar yeterince kolay filtrelenebilir görünüyor
      Yaygın hazır araçların, özellikle IDA Pro kullanıcılarının işini zorlaştırmak için yapılmış bir obfuscation
      Çoğu obfuscation'ın amacı, insanların başka projelere geçmesine yetecek kadar can sıkıcı olmaktır

  • Satıştan sonra ürün özelliklerini geri almak, sözleşmede veya EULA'da yer alsa bile yasayla engellenmeli
    Ban, oyunun mülkiyetini bizzat elinizden almamalı; eğer alıyorsa para iadesi yapılmalı
    İade ancak mahkeme kararına kadar gidilirse sağlanabiliyorsa, lisans ücreti, avukat masrafları ve mahkeme giderlerinin üstüne üç kat tazminat da olmalı
    Örneğin Steam'de banlanıp tüm satın alımların geçersiz sayılması hukuken imkânsız olmalı
    Hesaba giriş engellense bile item'lar ve envanter takas edilebilir olmalı; çünkü bunlar para ödemiş müşterinin gerçek zaman harcayarak elde ettiği şeyler
    Çok oyunculu bir oyunda etik kuralları uygulamak istiyorsanız ya oyun için para alamamalısınız ya da ücretli kullanıcıların ban konusunda hakları olmalı
    Ban'lar orantılılık ilkesine uymalı; insanın dahil olduğu, masrafın lisans fiyatıyla sınırlı olduğu ve yalnızca kaybedilirse üstlenilen bir temyiz/itiraz kurulu süreci ve kayıtları bulunmalı

    • Hile yapsanız bile Steam'den banlanmazsınız
      En kötü durumda VAC oyunlarında hesabınıza herkese açık bir utanç işareti eklenir
      İnsanlar eğlenmek ve başkalarıyla etkileşime girmek için çok oyunculu oyun oynar; dolayısıyla hile ya da başka kötü davranışlar başkalarını etkiliyorsa çok oyunculu hizmete erişim engellenmelidir
    • Bunun araç kullanırken hız yapmaktan ne farkı olduğunu bilmiyorum
      Topluma rahatsızlık verirsen bedel ödersin; bu oldukça evrensel bir ilke
    • Hilecinin hak ettiğini bulması bence sorun değil
      Gerçek para kaybetmesinde de sorun olmadığını düşünüyorum
      Ama yanlışlıkla banlanmak başka bir mesele
      Ayrıca banlanan şey tüm Steam hesabı değil, artık oynayamadığın ilgili oyun değil mi?
    • Bunun yerine hileci etiketi yapıştırıp sadece diğer hilecilerle oynamalarını sağlamak daha iyi olabilir
    • Hile yapıyorsan veya diğer oyuncuların oyununu mahvediyorsan erişim hakkını kaybetmeyi hak edersin
      Diğer oyuncular da para ödedi

  • COD'da hile yapmaya gerek bile yok
    O kadar çok bug var ki oyun bunu senin yerine yapıyor
    Ranked'da bıçak yerine silah yüklediği oluyor; ranked silah ekipmanı kontrolünde açıkça hatalı bir case veya if-else olduğu için bu mümkün oluyor ve ekipman seçicide görünen silaha izin verilmiyorsa varsayılan olarak XM4'e dönüyor gibi
    Bildiğim oyunlar içinde ranked sürümü casual sürümünden daha bozuk olan neredeyse tek oyun

  • İnsan bunun nerede öğrenildiğini merak ediyor
    Yazının yarısını bile anlayacak kadar daha fazla öğrenmek istiyorum ama nereden başlayacağımı bilmiyorum

    • Yaklaşık 15 yıl önce Eldad Eilam’ın Reversing: Secrets of Reverse Engineering adlı kitabını okuyarak çok şey öğrendim
      Eski bir kitap ama mükemmel; çeşitli teknikleri ve alıştırmaları adım adım takip ettiriyor
      Güncel araçlar o zamana göre biraz değişti ama x86 komut seti ve genel olarak assembly çok fazla değişmedi
      En büyük kazanımlardan biri crackme ile tanışmaktı
      Tersine mühendisliği öğrenmek için yapılmış küçük meydan okuma ikilileri; kilit açma topluluğundaki pratik kilitleri gibi
      Hatırladığım kadarıyla kitapla birlikte CD-ROM’da birkaç tane geliyordu, internette ararsanız da çok sayıda var
      Öğrenmenin yolu bu tür alıştırmaları bizzat yapmaktan geçiyor
      En baştan COD’yi tersine mühendislik etmeye kalkmamalı; adım adım biriktirerek ilerlemelisiniz
    • Eskiden Lena151 eğitimleriyle başlamıştım: https://github.com/kosmokato/Lena151
    • Eskiden olsa Gamedeception’a gidip ortama karış derdim ama birkaç yıl önce kapanmış gibi görünüyor
      UnknownCheats, cs.rin.ru vb. yerlere bakanlara selamlar
    • UnknownCheats bu tür materyaller için en iyi yerlerden biri
      Ben de orada aktifim; özellikle Linux kullanıcı alanı anti-cheat’leriyle, bunların içinde de VAC’nin nasıl çalıştığıyla daha çok ilgileniyorum
    • https://pwn.college harika bir eğitim kaynağı

  • Popüler bir Horde/Alliance tabanlı MMO üzerinde biraz tersine mühendislik yaptım; neredeyse aynı adımları izliyordu ve FNV32 export hash’i de vardı
    Çok benzer hileler kullandığını görünce neredeyse aynı yöntem gibi görünüyor
    Aynı koruma teknolojisiyle paketlenmiş olup olmadığını merak ediyorum

    • Source 2 motoru da şemaları, yani entity özelliklerini hash’lemek için fnv kullanıyor
    • Birleşmeden sonra Activision fikrî mülkiyetinde Warden’ı yeniden kullandılarsa mantıklı olur

  • İmza taraması gerçekten çok güçlü
    Tersine mühendislikte benim için en bağımlılık yapan kısımlardan biri de bu
    Bir imza listesi oluşturmak ve bu fonksiyon işaretçilerini çağırabilmek için betik dili binding’leri yazmak keyifli
    Pek çok üçüncü taraf mod platformunun temelinde de bu var; çünkü mod geliştiricilerine, birinci taraf geliştiricinin açmadığı anlamlı API’ler sunmaları gerekiyor

    • İmza taramasının ne olduğunu bilmiyorum ama merak edenler için bir kaynak buldum: https://www.unknowncheats.me/forum/general-programming-and-r...
    • Evet
      Bildiğim kadarıyla bazı Source motoru eklentileri de gerektiğinde bu yöntemi kullanıyor
      Ancak çoğu sanal fonksiyon tablosu işaretçisinin offset’ini kullanıyor gibi görünüyor

  • Oyun durumunu periyodik olarak dijital olarak imzalamanın ya da hileyi engellemek için bir tür iş ispatı eklemenin mümkün veya anlamlı olup olmayacağını düşünüyorum
    Hileyi engellemenin çok zor bir problem olduğunu düşünmeye başladım
    Küçük ve düşük maliyetli bir çevrimiçi FPS geliştiriyorum; anti-cheat yazılımı koymaktansa kullanıcıların birbirine güvenmesini ve hilecileri kendilerinin bulmasını ya da Valve gibi yapay zeka kullanmayı düşünüyorum
    Oyuncuların sunucuları kendilerinin yönetip işletmesine izin vereceğim gibi görünüyor
    Telefon numarası bağlama, diğer oyuncuların verdiği itibar puanı, kimlik ya da başka güçlü doğrulama araçları, dating uygulamalarındaki gibi fotoğrafla manuel doğrulama, rekabetçi maçlardan önce 10 saat oynama gibi şartlar koyulabilir
    Hardcore oyuncuların hilecileri azaltmak için bu tür süreçleri gönüllü olarak yapacağını düşünüyorum

    • Biraz çevrimiçi oyun oynadıysanız, oyuncuların çok az kanıtla bile hile şüphesini durmadan dile getirdiğini bilirsiniz
      Sevmedikleri oyuncuyu raporlayıp engelletmeye yönelik sosyal istismar da var
      Böyle bir sistemde yanlış pozitifler herhangi bir anti-cheat’ten çok daha fazla olur
    • Üst düzeyde bakınca, hilesiz bir oyunu simüle edip onu imzalamak ve hileleri ayrı ele almak yeterli