Bir Trainer Nasıl Geliştiriliyor? ORGA Hub’da Kullandığım Yöntemler

Trainer geliştirme konusunda dışarıdan en çok görünen şey genelde şu oluyor:

“Canı 999 yap, parayı değiştir, sınırsız mermi ekle.”

Ama o değeri güvenilir şekilde bulmak, oyun yeniden açıldığında tekrar yakalayabilmek ve oyun güncellendiğinde mümkün olduğunca az bozulmasını sağlamak işin asıl zor tarafı.

ORGA Hub’daki trainerleri geliştirirken de her oyun için aynı yöntemi kullanmıyorum.

Oyunun motoruna, veriyi nasıl tuttuğuna ve bize hangi sistemleri sunduğuna göre yöntem tamamen değişebiliyor.

Bu konuda ORGA Hub tarafında bir trainer geliştirirken genel olarak nasıl düşündüğümü ve kullandığım yöntemleri anlatmak istiyorum. 🎮

🔍 İlk İş Oyunu Tanımak

Bir trainer geliştirmeye başlamadan önce doğrudan bellekte değer aramaya geçmek bana göre doğru yöntem değil.

Önce oyunun ne olduğunu anlamaya çalışıyorum.

Mesela:

Unity mi?

Unreal Engine mi?

CryEngine mi?

Kendi özel motoru mu var?

Mono mu kullanıyor?

Native kod mu?

Oyunun içinde Python, Lua veya başka bir script sistemi var mı?

Kendi konsolu veya geliştirici komutları bulunuyor mu?

Bunları bilmek hangi yöntemin daha mantıklı olduğunu ciddi şekilde değiştiriyor.

Çünkü bazen bellekte saatlerce pointer aramak yerine oyunun zaten bize sunduğu bir sistemi kullanmak çok daha sağlam sonuç verebiliyor.

🧠 En Basit Örnek: Bellekteki Değeri Bulmak

Diyelim oyunda 100 canımız var.

Bellekte 100 değerini arayıp hasar aldıktan sonra 75 olan sonuçları filtreleyerek gerçek can değerini bulabiliriz.

Bu trainer geliştirmeye girişte kullanılan en temel yöntemlerden biri.

Değeri bulduktan sonra örneğin sürekli:

999

olarak yazarsak teorik olarak sınırsız can elde etmiş oluruz.

Ama iş burada bitmiyor.

Çünkü bulunan adres büyük ihtimalle oyun yeniden başlatıldığında değişecek.

Asıl mesele:

Bu değeri sonraki açılışta tekrar nasıl bulacağız?

👉 Pointer Nedir?

Oyundaki bir değer her açılışta farklı adrese taşınabiliyor.

Ancak o değere ulaşan bir adres zinciri daha stabil olabilir.

Burada pointer sistemi devreye giriyor.

Basitleştirirsek:

Oyun modülü → oyuncu nesnesi → karakter istatistikleri → can

gibi bir yol düşünün.

Trainer her açılışta bu yolu takip ederek o anki can adresini bulabilir.

ORGA Hub’da da bazı trainer özelliklerinde pointer ve pointer chain yöntemleri kullanıyorum.

Ama pointer bulmak tek başına her zaman yeterli değil.

Oyun güncellemesi geldiğinde offsetlerden biri değişirse zincir kırılabilir.

Bu yüzden farklı yöntemlere de ihtiyaç oluyor.

🔎 AOB Signature Nedir?

Trainer geliştirmede en sık kullandığım yöntemlerden biri AOB taraması.

AOB, kabaca oyunun makine kodu içerisinde belirli bir byte desenini aramak anlamına geliyor.

Örneğin oyunun bir fonksiyonunda:

48 8B ?? ?? 89 83 ?? ?? ?? ??

gibi ayırt edici bir yapı olabilir.

Trainer oyunu açtığında bellekte bu deseni arayıp ilgili kodu tekrar bulabilir.

Buradaki ?? bölümleri değişebilecek byte’ları temsil eder.

İyi hazırlanmış bir AOB imzası küçük oyun güncellemelerinde düz adrese göre çok daha dayanıklı olabilir.

Ama bunun da garantisi yok.

Geliştirici ilgili fonksiyonu ciddi şekilde değiştirirse imza yine bozulabilir.

🕳️ Code Cave Nedir?

Bazı özelliklerde sadece mevcut değeri değiştirmek yeterli olmuyor.

Oyunun bir fonksiyonunun davranışını değiştirmek gerekebiliyor.

Burada code cave yöntemi kullanılabiliyor.

Mantık kabaca şöyle:

Oyunun çalıştırdığı kodun belirli bir bölümünü yakalıyoruz.

Oradan kendi ayırdığımız kod alanına yönlendiriyoruz.

İstediğimiz işlemleri gerçekleştiriyoruz.

Sonra tekrar oyunun normal kod akışına dönüyoruz.

Böylece örneğin:

• hasarı engellemek,

• alınan değeri değiştirmek,

• çalışan fonksiyondan oyuncu adresini yakalamak,

• özel bir koşul eklemek

gibi daha gelişmiş işlemler yapılabiliyor.

ORGA Hub’daki birçok native trainerde bu yöntemi kullanıyorum.

🎯 Runtime Pointer Capture

Bazen sağlam bir pointer zinciri bulmak yerine oyunun çalışan kodundan gerçek nesne adresini yakalamak daha mantıklı oluyor.

Örneğin oyun her karede oyuncunun canını güncelleyen bir fonksiyon çalıştırıyor olabilir.

O fonksiyonun içerisinden geçtiğinde CPU register’larından biri:

şu anki oyuncu nesnesini

tutuyor olabilir.

Trainer bu adresi çalışma sırasında yakalayıp saklayabilir.

Daha sonra:

• can,

• stamina,

• açlık,

• para

gibi aynı nesneye bağlı değerlerde kullanabilir.

ORGA Hub’daki bazı trainerlerde bu nedenle runtime capture yöntemleri bulunuyor.

Bunun avantajı statik bir pointer bulmaya çalışmak yerine oyunun bize gerçek nesneyi kendisinin göstermesi.

🧊 Freeze Mantığı

Bazı özellikler aslında oldukça basit bir mantıkla çalışıyor.

Bir değeri bulduktan sonra sürekli istenen değeri yazıyoruz.

Örneğin enerji:

100

olarak tutuluyorsa trainer belirli aralıklarla değeri tekrar 100 yapabilir.

Oyun:

99 → 98 → 97

diye düşürmeye çalışırken trainer tekrar:

100

yazar.

Kullanıcı açısından sonuç:

Sınırsız enerji.

Ama bu yöntem her değer için doğru değil.

Bazı değerlerin sürekli yazılması oyunun kendi sistemleriyle çakışabiliyor.

Bu yüzden bazen değeri freeze etmek yerine onu azaltan fonksiyonu değiştirmek daha doğru oluyor.

🧩 Her Oyun İçin Bellek Taramıyorum

ORGA Hub trainer altyapısında özellikle önem verdiğim şeylerden biri bu.

Bir oyun bize daha düzgün bir yol sunuyorsa sırf trainer olduğu için illa memory patch kullanmak istemiyorum.

Örneğin bazı Unity oyunlarında Mono runtime üzerinden sınıfları ve field’ları doğrudan çözebiliyoruz.

Bu durumda:

Player + 0x148

gibi kör bir offset yerine:

Player sınıfındaki health field’ı

gibi daha anlamlı bir yapı üzerinden ilerlemek mümkün olabiliyor.

🟦 Unity ve Mono

Unity’nin Mono kullandığı oyunlarda ORGA Hub’ın Mono tarafında ayrı bir altyapısı bulunuyor.

Burada runtime üzerinden:

• sınıflar,

• field’lar,

• methodlar,

• JIT edilmiş method adresleri

çözülebiliyor.

Örneğin Rain World, Raft, Stranded Deep ve Streamer Life Simulator gibi oyunlarda Mono tabanlı yöntemlerden yararlanıyorum.

Bu sistem sayesinde bazı değerlerde hardcoded offset kullanımını azaltabiliyoruz.

Tabii oyunun yapısına göre yine patch veya code cave gerektiği yerler olabiliyor.

🎮 Unreal Engine Reflection

Unreal Engine tarafında da benzer bir yaklaşım mümkün.

Özellikle yeni Unreal Engine oyunlarında nesnelerin ve property’lerin runtime yapısından faydalanılabiliyor.

ORGA Hub’da Subnautica 2 tarafında Unreal Engine reflection kullanan ayrı bir sistem geliştirdim.

Bazı özelliklerde doğrudan:

şu sınıftaki şu property

mantığıyla ilerleyebiliyoruz.

Bu da her şeyi sabit adres ve offsetlerle çözmekten daha temiz bir yöntem olabiliyor.

🔴 REDengine ve Cyberpunk 2077

Cyberpunk 2077 tarafında da oyuna özel bir sistem kullanıyorum.

Burada REDengine yapısından faydalanan ayrı bir katman bulunuyor.

Cyberpunk trainerindeki özelliklerin büyük kısmı oyuna özel bu sistem üzerinden çalışıyor.

Bunun yanında ihtiyaç olan yerlerde yine:

• pointer,

• patch,

• code cave

gibi native yöntemler de kullanılabiliyor.

Yani bir trainerin içinde bile birden fazla teknik birlikte bulunabiliyor.

🏹 CryEngine ve Kingdom Come

Kingdom Come tarafı bunun güzel örneklerinden biri.

Kingdom Come: Deliverance ve Kingdom Come: Deliverance 2 için sadece bellekte değer arayıp değiştirmiyorum.

CryEngine’in kendi:

• Console

• CVar

• komut sistemleri

üzerinden de birçok özelliği kontrol edebiliyoruz.

ORGA Hub’da bunun için ayrı bir CryEngine köprüsü bulunuyor.

Bazı özelliklerde oyunun zaten sahip olduğu sistemi kullanmak, bellekte aynı şeyi zorla değiştirmekten çok daha mantıklı.

Kingdom Come trainerlerinin bu kadar fazla özelliğe sahip olabilmesinin nedenlerinden biri de bu.

🐍 The Sims 4 ve Python

The Sims 4 ise tamamen farklı.

Oyunun içinde Python tabanlı büyük bir script sistemi bulunuyor.

Bu yüzden ORGA Hub’daki Sims 4 trainerinde klasik memory freeze yerine oyunun Python runtime’ı ile iletişim kuran bir sistem kullanıyorum.

Hub oyunun içindeki Python tarafında gerekli işlemleri çalıştırabiliyor.

Yani mantık:

ORGA Hub → oyunun Python sistemi → oyun

şeklinde ilerliyor.

Bence trainer geliştirmenin güzel tarafı da bu.

İki oyunda aynı özelliği yapıyor olabilirsiniz ama kullandığınız yöntem tamamen farklı olabilir.

🗄️ Hogwarts Legacy ve SQLite

Hogwarts Legacy tarafında daha da ilginç bir yapı var.

Bazı özelliklerde memory patch ve code cave kullanılırken bazı işlemler oyunun kendi SQLite veritabanı üzerinden gerçekleştiriliyor.

ORGA Hub tarafında uygun işlemlerde oyunun kendi SQLite sistemini kullanarak sorgu çalıştırabilecek bir yapı bulunuyor.

Yani örneğin oyun bir bilgiyi zaten kendi veritabanında tutuyorsa bellekte geçici bir kopyasını değiştirmek yerine bazen doğrudan gerçek kaynağa müdahale etmek daha doğru olabiliyor.

🟨 Game Dev Tycoon ve Companion Sistem

Game Dev Tycoon traineri de klasik trainerlerden farklı.

Burada ayrı bir companion sistemi kullanıyorum.

Hub ve oyun içindeki companion tarafı birlikte çalışıyor.

Bu nedenle Game Dev Tycoon’daki özelliklerin tamamına yakını doğrudan klasik memory patch mantığına dayanmıyor.

Teknik olarak biraz:

mod + trainer + Hub kontrolü

karışımı bir yapı diyebiliriz.

💾 PlayerPrefs Gibi Sistemler

Bazı Unity oyunları belirli değerleri doğrudan PlayerPrefs içinde tutabiliyor.

Streamer Life Simulator gibi oyunlarda bazı özelliklerde bunu kullanmak mümkün.

Eğer gerçek değer burada tutuluyorsa bellekte gördüğümüz geçici kopyasını değiştirmek yerine PlayerPrefs üzerindeki esas değeri değiştirmek daha mantıklı olabiliyor.

Yani kullandığım yöntem her zaman:

“RAM’de değer bul ve değiştir.”

değil.

Önce oyunun o veriyi gerçekten nerede tuttuğunu anlamaya çalışıyorum.

🧪 Bir Özellik Bulduktan Sonra Test Başlıyor

Bir özelliği bir kez çalıştırmak trainerin hazır olduğu anlamına gelmiyor.

Örneğin sınırsız can yaptım ve çalıştı.

Sonra şunları kontrol etmek gerekiyor:

Trainer kapatıldığında ne oluyor?

Yeni kayıt açınca çalışıyor mu?

Save yükleyince çalışıyor mu?

Karakter ölünce pointer değişiyor mu?

Bölüm değiştirince adres değişiyor mu?

Menüye dönünce ne oluyor?

Oyunu kapatıp tekrar açınca bulunabiliyor mu?

Başka bir özellik açıkken çakışıyor mu?

Bazen ilk testte mükemmel çalışan bir özellik bölüm değiştirdiğiniz anda bozulabiliyor.

Asıl test süreci burada başlıyor.

🔄 Oyun Güncellemesi Gelince Ne Oluyor?

Trainer geliştirmede en can sıkıcı taraflardan biri bu. 😄

Oyun güncellendiğinde:

• AOB imzaları,

• fonksiyonlar,

• offsetler,

• field yapıları,

• sınıflar,

• JIT methodları,

• scriptler

değişebiliyor.

Bu yüzden trainerin tamamı değil, belirli özellikleri de bozulabilir.

Örneğin 50 özellikli bir trainerde 47 özellik çalışırken sadece 3 özellik güncellemeden etkilenmiş olabilir.

Bu nedenle oyun güncellemelerinden sonra trainerleri yeniden test etmek gerekiyor.

📦 ORGA Hub Trainerleri Nasıl Dağıtıyor?

ORGA Hub tarafında trainer tanımlarını kullanıcıya açık JSON dosyaları halinde bırakmıyorum.

Geliştirme tarafındaki trainer tanımları paketleme aşamasında işlenerek şifreli ve imzalı .bin paketlerine dönüştürülüyor.

Hub paketi kullanmadan önce imzasını doğruluyor.

Ardından gerekli trainer tanımı çalışma sırasında çözülerek trainer engine tarafından kullanılıyor.

Yani dağıtım mantığı kabaca:

Trainer tanımı → şifreleme ve imzalama → BIN paket → ORGA Hub → Trainer Engine → oyun

şeklinde.

Böylece trainer altyapısını tek bir Hub içerisinde tutarken her oyun için ayrı bir trainer uygulaması dağıtmak zorunda kalmıyorum.

🎮 Şu Anda ORGA Hub’da Birçok Farklı Yöntem Birlikte Kullanılıyor

Şu anki trainerlere baktığımızda aslında tek bir “ORGA trainer yöntemi” yok.

Kullandığım sistemler arasında:

• AOB tarama

• Pointer ve pointer chain

• Memory patch

• Code cave

• Runtime pointer capture

• Value freeze

• Unity Mono

• Unreal Engine reflection

• REDengine

• CryEngine Console/CVar

• Python runtime

• SQLite

• PlayerPrefs

• Companion/script sistemleri

bulunuyor.

Hangisinin kullanılacağı tamamen oyuna bağlı.

❤️ Benim İçin En Önemli Kısım

Trainer geliştirirken amacım sadece özelliği bir şekilde çalıştırmak değil.

Mümkün olduğunca oyunun yapısına uygun yöntemi bulmak.

Eğer oyun bize sağlam bir runtime API sunuyorsa onu kullanmak daha mantıklı olabilir.

Reflection kullanılabiliyorsa sabit offset yazmaya gerek olmayabilir.

Oyunun kendi konsolu varsa bellekte aynı işlemi tekrar üretmeye çalışmak gereksiz olabilir.

Bazı oyunlarda ise bunların hiçbiri yoktur ve AOB + code cave en doğru çözüm olur.

Bu yüzden trainer geliştirmek bana göre biraz da oyunla iletişim kurmanın en doğru yolunu bulmak.

Forumda ilerleyen konularda bu yöntemleri tek tek daha detaylı anlatacağım.

Özellikle AOB Signature, Pointer, Code Cave, Mono ve Unreal Engine reflection taraflarını ayrı başlıklarda ele almak istiyorum. 🎮