Oyun Güncellendiğinde Trainer Neden Bozuluyor?

Bir oyuna güncelleme geldiğinde trainer tarafında en sık karşılaştığımız durumlardan biri şu:

Dün çalışan özellik bugün çalışmıyor.

Bazen 50 özellikli bir trainerin tamamı bozuluyor.

Bazen sadece 2-3 özellik gidiyor.

Bazen trainer açılıyor ama belirli bir butona bastığınız anda oyun çöküyor.

Bazen de hiçbir hata vermiyor, sadece özellik artık hiçbir şey yapmıyor.

Bunun sebebi trainerlerin çoğu zaman doğrudan oyunun çalışma yapısına bağlı olması.

Oyun değiştiğinde bizim kullandığımız adresler, fonksiyonlar, sınıflar veya scriptler de değişebiliyor.

🎮 Trainer Oyun Dosyasına Değil, Oyunun Çalışan Yapısına Bağlı

Önce önemli bir ayrım yapalım.

Trainer çoğu zaman oyunun klasörüne birkaç dosya kopyalayıp bırakmaz.

Oyun çalışırken:

• bellekteki değerleri,

• fonksiyonları,

• nesneleri,

• sınıfları,

• runtime sistemlerini

bulup bunlarla iletişim kurar.

Mesela bir özellik:

Can azaltan fonksiyonu

buluyor olabilir.

Bir diğeri:

Player nesnesindeki stamina field’ını

değiştiriyor olabilir.

Başka biri:

CryEngine CVar

kullanıyor olabilir.

Oyun geliştiricisi güncellemede bunlardan herhangi birini değiştirirse trainerin ilgili özelliği de etkilenebilir.

🔎 AOB Signature Değişebilir

Daha önce AOB Signature konusunu anlatmıştım.

Trainer oyundaki belirli bir kodu bulmak için şöyle bir byte deseni arıyor olabilir:

48 8B ?? ?? ?? ?? 48 85 C0 74 ??

Oyun güncellendiğinde geliştirici ilgili fonksiyonu değiştirebilir.

Compiler yeni sürümde farklı instruction üretebilir.

Eski imza artık:

0 eşleşme

döndürür.

Sonuç olarak trainer patch uygulayacağı veya pointer yakalayacağı kodu bulamaz.

Bu durumda ilgili özellik çalışmaz.

Yeni sürümde fonksiyonu tekrar bulup signature’ı güncellemek gerekir.

👉 Pointer ve Offsetler Değişebilir

Bir özellik şöyle çalışıyor olabilir:

Player → Stats → Health

Ama yeni güncellemede geliştirici PlayerStats yapısına yeni bir field ekledi.

Eskiden:

Health = +0x120

iken artık:

Health = +0x128

olabilir.

Trainer hâlâ +0x120 kullanıyorsa artık can yerine başka bir değere bakıyor olabilir.

En iyi ihtimalle özellik çalışmaz.

En kötü ihtimalle yanlış belleğe yazdığı için oyun çöker.

Pointer chain’in herhangi bir halkasının değişmesi de aynı problemi oluşturabilir.

🕳️ Code Cave Bozulabilir

Code Cave kullanan özellikler güncellemelerden daha fazla etkilenebilir.

Çünkü oyunun çalışan makine koduna kontrollü şekilde hook atıyoruz.

Eski sürümde hook kurduğumuz yerde:

mov eax,[rcx+120]

olabilir.

Yeni sürümde geliştirici kodu değiştirmiştir:

mov eax,[rbx+128]

Artık:

• kullanılan register değişmiş,

• offset değişmiş,

• instruction uzunluğu değişmiş,

• kod akışı değişmiş

olabilir.

Eski cave’i yeni sürüme kör şekilde uygularsak oyun crash bile olabilir.

Bu yüzden yalnızca AOB’yi yenilemek bazen yeterli olmaz.

Hook’un kendisini de yeniden analiz etmek gerekir.

🧠 Runtime Pointer Capture Değişebilir

Bazı trainerlerde player pointer’ını çalışan fonksiyonun içinden yakalıyorum.

Mesela eski sürümde:

rcx = Player

olduğunu tespit etmiş olabiliriz.

Güncellemeden sonra compiler aynı fonksiyonda artık oyuncu nesnesini:

rbx

üzerinde tutuyor olabilir.

AOB hâlâ kodu bulsa bile biz yanlış register’ı kaydediyorsak artık gerçek oyuncu nesnesini alamayız.

Bu da güzel bir örnek:

Trainer bozulması her zaman adres değişmesi değildir.

Bazen aynı fonksiyon hâlâ vardır ama çalışma şekli değişmiştir.

🟦 Unity Mono Trainerler de Bozulabilir

Mono kullanan Unity oyunlarında durum biraz farklı.

Burada doğrudan:

PlayerStats.health

gibi class ve field yapılarını çözebiliyoruz.

Bu bazı güncellemelerde avantaj sağlar.

Örneğin field’ın fiziksel offset’i değişse bile runtime’dan tekrar çözülebiliyorsa trainer çalışmaya devam edebilir.

Ama geliştirici:

PlayerStats

sınıfını:

CharacterStats

olarak değiştirirse?

Ya da:

health

field’ını kaldırıp property sistemine geçirirse?

Bu durumda trainerin aradığı yapı artık yoktur.

Dolayısıyla Mono kullanmak güncellemeleri tamamen ortadan kaldırmıyor.

Sadece bazı kırılma türlerini azaltabiliyor.

🟪 Unreal Engine Reflection da Değişebilir

Subnautica 2 tarafında kullandığım Unreal Engine reflection sistemi de benzer.

Trainer bir property’yi runtime sırasında adıyla çözebiliyor olabilir.

Mesela:

Health

Property’nin offset’i güncellemede değişti ama adı aynı kaldıysa trainer bunu tekrar çözebilir.

Bu güzel.

Ama geliştirici:

Health

yerine:

CurrentHealth

kullanmaya başladıysa veya sistemi farklı bir component’e taşıdıysa artık trainerin mantığını da güncellemek gerekir.

Yani reflection:

Hardcoded offset bağımlılığını azaltabilir ama oyun mimarisindeki değişiklikleri engelleyemez.

🏹 CryEngine Komutları da Değişebilir

Kingdom Come trainerlerinde CryEngine’in:

• Console

• CVar

• komut sistemleri

üzerinden birçok işlem yapabiliyorum.

Bu yöntem native memory patch’e göre bazı özelliklerde oldukça rahat.

Ama oyun güncellemesinde geliştirici:

• CVar adını değiştirebilir,

• komutu kaldırabilir,

• davranışını değiştirebilir,

• belirli bir komutu artık farklı şekilde işletebilir.

Bu durumda memory address değişmemiş olsa bile ilgili trainer özelliği yine bozulabilir.

🐍 Script Sistemleri de Güncellemelerden Etkileniyor

The Sims 4 tarafında Python runtime kullanıyorum.

Game Dev Tycoon tarafında companion sistemi var.

Kingdom Come tarafında Lua gibi oyun içi script sistemlerinden faydalanılabiliyor.

Bunlar klasik pointer trainer olmadığı için bazen şöyle düşünülüyor:

Memory kullanmıyorsa güncellemede bozulmaz.

Ama bu da doğru değil.

Oyun geliştiricisi:

• Python API’sini,

• class adlarını,

• methodları,

• event’leri,

• script arayüzlerini

değiştirebilir.

Bizim çağırdığımız method artık yoksa özellik çalışmaz.

Yani hangi yöntemi kullanırsanız kullanın oyunun mimarisine bir noktada bağlısınız.

🗄️ Veritabanı Yapısı Değişebilir

Hogwarts Legacy trainerinde bazı işlemlerde oyunun kendi SQLite yapısından yararlanıyorum.

Bu tarafta da:

• tablo adı,

• kolon adı,

• veri yapısı,

• sorgu davranışı

değişebilir.

Eski sorgu yeni sürümde geçersiz kalabilir.

Dolayısıyla trainer güncellemesi sadece memory tarafını kontrol etmekten ibaret değil.

Kullandığımız bütün yöntemleri ayrı ayrı değerlendirmek gerekiyor.

🤔 Peki Neden Bazen Sadece 2 Özellik Bozuluyor?

Çünkü 50 özellikli trainerin 50 özelliği aynı sistemi kullanmak zorunda değil.

Mesela trainerde:

• 20 özellik Mono field kullanıyor,

• 10 özellik AOB + Code Cave,

• 5 özellik pointer,

• 10 özellik oyun konsolu,

• 5 özellik script sistemi

kullanıyor olabilir.

Oyun güncellemesinde yalnızca bir native fonksiyon değiştirilmişse sadece o fonksiyona bağlı özellikler bozulur.

Diğerleri çalışmaya devam eder.

Bu yüzden:

Trainer çalışıyor mu?

sorusu bazen yeterli değil.

Doğru soru:

Trainerdeki hangi özellikler hâlâ çalışıyor?

oluyor.

🔗 Aynı Sisteme Bağlı Birden Fazla Özellik Birlikte Bozulabilir

Bazen bir tane temel pointer onlarca özellik tarafından kullanılır.

Örneğin:

Player Object

bir kez yakalanıyor.

Sonrasında:

• Health

• Stamina

• Hunger

• Thirst

• Speed

aynı nesne üzerinden yönetiliyor.

Eğer player pointer yakalama sistemi bozulursa bir anda 5 özellik de gider.

Bu durumda aslında 5 ayrı problem yoktur.

Tek bir temel dependency bozulmuştur.

Bu yüzden trainer güncellemesinde önce ortak altyapılara bakmak önemli.

💥 Neden Bazen Oyun Direkt Crash Oluyor?

Bir özellik sadece değer yazıyorsa yanlış adres yüzünden hiçbir şey olmama ihtimali var.

Ama trainer:

• code cave,

• memory patch,

• function hook

kullanıyorsa yanlış yere müdahale etmek daha tehlikeli.

Trainer eski sürümdeki instruction’ın hâlâ orada olduğunu varsayıp patch uygularsa yeni sürümde tamamen farklı bir kodun üzerine yazabilir.

CPU biraz sonra oraya geldiğinde geçersiz instruction çalıştırır ve oyun kapanır.

Bu nedenle oyun güncellendiğinde özellikle hook tabanlı özelliklerde daha dikkatli olmak gerekiyor.

🧱 Compiler Değişiklikleri Bile Etkileyebilir

Bazen geliştirici ilgili özelliğe dokunmamış olabilir.

Ama oyunu farklı compiler ayarlarıyla yeniden derlemiştir.

Sonuçta:

• instruction sırası değişebilir,

• register seçimi değişebilir,

• fonksiyon inline edilebilir,

• optimizasyon davranışı değişebilir.

Oyuncu açısından ilgili mekanik tamamen aynı görünür.

Ama trainer açısından makine kodu farklıdır.

Bu nedenle:

Bu güncellemede sadece grafik bug’ı düzeltildi, trainer neden bozuldu?

gibi durumlar teorik olarak yaşanabilir.

Patch notlarında yazmayan derleme değişiklikleri de traineri etkileyebilir.

📦 Oyun Motoru Güncellenirse Daha Büyük Değişiklik Olabilir

Geliştirici Unity veya Unreal Engine sürümünü yükselttiğinde daha geniş değişiklikler oluşabilir.

Runtime yapısı değişebilir.

Metadata düzeni farklılaşabilir.

Methodlar yeniden derlenebilir.

Serialization sistemi değişebilir.

Böyle durumlarda tek tek birkaç signature güncellemek yerine trainer engine tarafında bile değişiklik yapmak gerekebilir.

Her güncelleme böyle büyük olmaz ama büyük engine geçişleri trainer geliştirme açısından daha dikkatli incelenmesi gereken değişiklikler.

🔄 Trainer Güncellemesine Nasıl Başlıyorum?

Bir oyun güncellendiğinde ilk yaptığım şey genelde bütün traineri sıfırdan yazmak değil.

Önce mevcut özellikleri test ediyorum.

Örneğin:

74 özellik

varsa hangileri çalışıyor, hangileri çalışmıyor bakıyorum.

Sonra bozuk özellikleri kullandıkları yönteme göre ayırıyorum.

Mesela:

• AOB bulunmuyor

• Pointer yanlış

• Class bulunmuyor

• Field değişmiş

• Command çalışmıyor

• Script methodu yok

• Code Cave crash oluşturuyor

gibi.

Bu bize oyunun güncellemede neyi değiştirdiği konusunda da ipucu veriyor.

🔎 AOB Bozulduysa

İlgili fonksiyonu yeni sürümde tekrar buluyorum.

Sonra yeni bir signature oluşturuyorum.

Ama sadece:

Yeni byte’ları yazdım, tamam.

demiyorum.

Çünkü instruction yapısı değişmiş olabilir.

Hook veya patch mantığını da tekrar kontrol etmek gerekiyor.

👉 Pointer Bozulduysa

Yeni pointer yolu veya yeni field offset’i bulunuyor.

Sonrasında:

• oyunu yeniden başlatma,

• save değiştirme,

• bölge değiştirme

gibi testlerle gerçekten stabil olup olmadığı tekrar kontrol ediliyor.

🧩 Runtime Sistemi Bozulduysa

Mono, Unreal, CryEngine veya script tarafında problem varsa önce yeni yapıyı anlamaya çalışıyorum.

Bazen sadece:

health → currentHealth

gibi küçük isim değişikliği vardır.

Bazen ise geliştirici bütün sistemi başka sınıfa taşımıştır.

Bu durumda özellik daha geniş şekilde yeniden hazırlanabilir.

🧪 Güncelledikten Sonra Yine Test Başlıyor

Traineri yeni sürüme uyarladıktan sonra:

Hata vermedi, yayınlayalım.

demek istemiyorum.

Tekrar:

• aç/kapat,

• save yükleme,

• respawn,

• harita değişimi,

• özellik kombinasyonları,

• Hub üzerinden kullanım

gibi testlere dönmek gerekiyor.

Çünkü problemi düzeltirken başka bir şeyi bozmuş olabilirsiniz.

⚠️ Yeni Oyun Sürümü Gelince Kullanıcı Ne Yapmalı?

Yeni güncelleme geldiği anda özellikle büyük trainerlerde biraz beklemenizi öneriyorum.

Trainer açılıyor diye bütün özelliklerin uyumlu olduğunu varsaymayın.

Mümkünse ORGA tarafında ilgili oyunun uyumluluk durumunu kontrol edin.

Eğer henüz test edilmediyse özellikle:

• save üzerinde kalıcı işlem yapan,

• inventory değiştiren,

• teleport kullanan,

• code patch uygulayan

özelliklerde biraz daha dikkatli olmak mantıklı.

🚫 “Eski Traineri Zorla Çalıştırmak” İyi Fikir Değil

Bazen kullanıcı:

Sürüm kontrolünü kapatsak eski trainer çalışmaz mı?

diye düşünebilir.

Belki çalışır.

Ama mesele sadece sürüm numarası değil.

Trainer eski adreslere veya eski kod yapısına müdahale ediyorsa sürüm kontrolünü atlamak problemi çözmez.

Tam tersine yanlış belleğe müdahale edilmesine neden olabilir.

Bu yüzden uyumluluk kontrolünü engel olarak değil güvenlik katmanı olarak görmek daha doğru.

🎮 ORGA Hub’da Neden Farklı Trainer Yöntemleri Var?

Bu konu aslında bunun nedenlerinden birini de gösteriyor.

Her şeyi tek yöntemle yaparsam bütün trainerler aynı tür değişikliklere bağımlı hale gelir.

Bunun yerine oyun ne sunuyorsa onu kullanmaya çalışıyorum.

Unity Mono ise Mono.

Unreal ise reflection.

CryEngine ise console/CVar.

Python kullanıyorsa Python.

Bunlar yoksa AOB, pointer, capture, code cave gibi native yöntemler.

Bu trainerleri güncellemelere karşı kusursuz yapmıyor ama mümkün olduğunca oyunun gerçek yapısına yakın çalışmamızı sağlıyor.

❤️ Kısaca Özetlersek

Oyun güncellendiğinde trainer şu nedenlerden biri veya birkaçı yüzünden bozulabilir:

• AOB signature değişir

• Pointer chain kırılır

• Offset değişir

• Function yeniden yazılır

• Register kullanımı değişir

• Code Cave artık doğru yere bağlanmaz

• Class veya field adı değişir

• Unreal property yapısı değişir

• CryEngine komutu değişir

• Python/Lua API değişir

• Veritabanı yapısı değişir

• Oyun motoru veya compiler değişir

Bu yüzden trainer güncellemek her zaman:

Yeni adresi bul ve kaydet

kadar basit değil.

Bazı oyunlarda 5 dakika sürer.

Bazılarında tek bir özellik saatlerce yeniden analiz gerektirebilir.

Trainer geliştirmede işin büyük kısmı aslında yalnızca özellik eklemek değil, oyun değiştikçe o özellikleri yaşamaya devam ettirmek.

ORGA Hub’daki trainerleri de oyun güncellemeleri geldikçe mümkün olduğunca test edip uyumlu hale getirmeye devam ediyorum.