Pointer ile AOB Arasındaki Fark Nedir? Trainer Geliştirmede Hangisi Ne Zaman Kullanılır?

Trainer geliştirmeye yeni başlayanların en çok karıştırdığı konulardan biri Pointer ile AOB Signature arasındaki fark.

İkisi de sonunda bizi oyundaki bir değere veya koda ulaştırabiliyor ama aslında tamamen farklı şeyler yapıyorlar.

En basit haliyle:

Pointer bize bir veriye giden yolu gösterir.

AOB ise bellekte belirli bir kod veya byte desenini arayıp bulur.

İkisini rakip yöntemler gibi düşünmemek lazım. Hatta birçok trainerde ikisini birlikte kullanıyorum.

👉 Pointer Nedir?

Pointer, bellekte başka bir adresi gösteren değerdir.

Basit bir örnek verelim.

Oyuncunun canı bellekte şu adreste olsun:

0x1A35F840

Ama oyunu kapatıp tekrar açtığınızda can artık:

0x2C781910

adresinde olabilir.

Bu durumda doğrudan ilk adresi trainer içine yazarsak oyun yeniden açıldığında çalışmaz.

Burada pointer devreye girebilir.

Örneğin elimizde şöyle bir yol olduğunu düşünelim:

Game.exe + 0x123456

↓

Player

↓

Stats

↓

Health

Trainer her açılışta bu zinciri takip ederek o anki gerçek can adresine ulaşır.

Yani pointer bize:

Can şu adreste.

demekten çok:

Cana ulaşmak için şu yolu takip et.

der.

🔗 Pointer Chain Nedir?

Bir değere ulaşmak için bazen tek pointer yeterli olmaz.

Birden fazla adresi sırayla takip etmek gerekir.

Mesela:

Game.exe + 0x123456

→ +0x30

→ +0x18

→ +0xA0

Bu yapıya pointer chain diyebiliriz.

Trainer önce modül adresini bulur.

Sonra ilk offset'i takip eder.

Oradan çıkan adresin üzerine diğer offset'i uygular.

Bu şekilde sonunda gerçek değere ulaşır.

Pointer zinciri stabil olduğu sürece oyun her açıldığında adres değişse bile trainer çalışmaya devam edebilir.

🔎 AOB Signature Ne Yapıyor?

AOB ise başka bir yaklaşım kullanıyor.

Burada:

Değerin adresi nerede?

diye sormuyoruz.

Onun yerine:

Aradığım kod bellekte nasıl görünüyor?

diyoruz.

Mesela oyunda canı azaltan instruction çevresinde şöyle bir byte dizisi olabilir:

F3 0F 11 83 ?? ?? ?? ?? 48 8B 5C 24 ??

Trainer oyun açıldığında bu deseni bellekte arar.

Eğer imza benzersizse ilgili kodun nerede olduğunu tekrar bulabilir.

Yani AOB'nin yaptığı iş:

Adres ezberlemek yerine kodun parmak izini aramak.

🧠 Temel Fark Burada

Pointer çoğunlukla veriye ulaşmaya odaklanır.

Örneğin:

• Can

• Para

• Stamina

• Açlık

• Mermi

• Oyuncu pozisyonu

gibi değerlerin bulunduğu nesnelere ulaşmak için kullanılabilir.

AOB ise çoğunlukla kod veya fonksiyon bulmak için kullanılır.

Örneğin:

• Hasar veren kod

• Mermiyi azaltan kod

• Stamina tüketen fonksiyon

• Player nesnesine erişen instruction

• Hareket hızını hesaplayan bölüm

gibi.

Ama tabii bu kesin bir kural değil. Kullanım alanları zaman zaman birbirine yaklaşabiliyor.

🎮 Basit Bir Can Örneği

Oyuncunun canını sınırsız yapmak istediğimizi düşünelim.

Bunu birkaç farklı şekilde yapabiliriz.

Pointer Yöntemi

Can değerine giden sağlam bir pointer chain buluruz.

Trainer:

Player → Stats → Health

yolunu takip eder ve canı sürekli:

100

olarak yazar.

Bu durumda freeze mantığı kullanmış oluruz.

AOB Yöntemi

Canı azaltan fonksiyonu buluruz.

Örneğin:

Health = Health - Damage

işlemini yapan kodu AOB signature ile yakalarız.

Sonra ilgili instruction'ı patchleyebilir veya code cave ile:

God Mode açıksa hasarı uygulama.

diyebiliriz.

İki yöntemin kullanıcı açısından sonucu aynı olabilir:

Sınırsız can.

Ama arka tarafta tamamen farklı şekilde çalışırlar.

🤔 Hangisi Daha İyi?

Bunun tek bir cevabı yok.

Oyuna göre değişiyor.

Bazı oyunlarda çok sağlam pointer zincirleri bulunabiliyor.

Böyle bir durumda basit bir değer için code cave hazırlamak gereksiz olabilir.

Bazı oyunlarda ise pointer zinciri sürekli kırılıyor ama ilgili fonksiyonun kod yapısı oldukça stabil kalıyor.

O zaman AOB daha mantıklı olabilir.

Bazen de ikisini birlikte kullanmak en iyi çözüm oluyor.

🔥 AOB + Pointer Birlikte Nasıl Kullanılıyor?

Bence en güzel örneklerden biri runtime pointer capture.

Diyelim oyuncu nesnesine giden düzgün bir pointer chain bulamadım.

Ama oyunun bir fonksiyonunda şöyle bir kod var:

mov [rcx+120], eax

Ve testler sonucunda anlıyorum ki o anda:

rcx = Player Object

Trainer önce bu instruction'ı AOB ile bulabilir.

Ardından code cave veya capture sistemiyle rcx değerini yakalayabilir.

Artık elimizde gerçek player pointer var.

Sonra bu pointer üzerinden:

Player + HealthOffset

Player + StaminaOffset

Player + HungerOffset

gibi alanlara erişebiliriz.

Yani:

AOB → Player nesnesini buluyor

Pointer/offset → Nesnenin içindeki değerleri buluyor

Bu yöntem ORGA Hub tarafında da kullandığım yaklaşımlardan biri.

🔄 Oyun Güncellemesinde Pointer Ne Olur?

Pointer chain'ler güncellemelerden etkilenebilir.

Örneğin geliştirici oyuncu sınıfına yeni bir field ekledi.

Eski yapı:

Health = +0x120

iken yeni sürümde:

Health = +0x128

olabilir.

Artık eski offset yanlış yere bakar.

Aynı şekilde pointer zincirindeki bir nesnenin yapısı değişirse tüm chain kırılabilir.

Bu yüzden:

Pointer buldum, artık sonsuza kadar çalışır.

diye bir şey yok. 😄

🔄 Oyun Güncellemesinde AOB Ne Olur?

AOB de kırılabilir.

Geliştirici ilgili fonksiyonu yeniden derlediğinde:

• instruction'lar değişebilir,

• register'lar değişebilir,

• compiler farklı kod üretebilir,

• fonksiyon tamamen değişebilir.

Bu durumda eski imza artık:

0 sonuç

döndürebilir.

Ya da daha kötü şekilde birden fazla yerde eşleşebilir.

O zaman signature'ı yeniden hazırlamak gerekir.

🛡️ Hangisi Güncellemelere Daha Dayanıklı?

Bu tamamen oyuna bağlı.

İyi hazırlanmış bir AOB küçük güncellemelerde oldukça sağlam olabilir.

Ama aynı şekilde düzgün bir root object üzerinden oluşturulmuş pointer yapısı da uzun süre değişmeden kalabilir.

Ben mümkün olduğunca:

en stabil olan yöntemi

seçmeye çalışıyorum.

Bir yöntemin teknik olarak daha havalı görünmesi benim için çok önemli değil.

Basit pointer gerçekten sağlamsa pointer kullanmak daha mantıklı.

Oyunun kendi runtime sistemi varsa pointer veya AOB kullanmak bile gerekmeyebilir.

🟦 Unity Oyunlarında Durum Biraz Değişiyor

Unity Mono kullanan oyunlarda pointer ile AOB arasında seçim yapmadan önce başka bir seçeneğimiz daha olabilir.

Mono metadata üzerinden:

• sınıfı,

• field'ı,

• methodu

doğrudan bulabiliriz.

Mesela:

PlayerStats.health

alanını runtime üzerinden çözebiliyorsak manuel pointer chain hazırlamaya gerek kalmayabilir.

ORGA Hub'da Rain World, Raft, Stranded Deep ve Streamer Life Simulator gibi oyunlarda Mono sisteminden faydalanmamın nedenlerinden biri bu.

🟪 Unreal Engine'de de Benzer Mantık Var

Unreal Engine oyunlarında da reflection kullanılabiliyorsa property'leri isim üzerinden çözmek mümkün olabilir.

Subnautica 2 tarafında buna benzer bir sistem kullanıyorum.

Bu durumda:

Player + 0x3A8

gibi sabit bir offset'e bağımlı kalmak yerine ilgili property runtime yapısından bulunabiliyor.

Yani trainer geliştirme aslında sadece:

Pointer mı AOB mi?

sorusundan ibaret değil.

Önce oyunun bize daha iyi bir yöntem sunup sunmadığına bakmak gerekiyor.

🧩 Pointer Hangi Durumlarda Mantıklı?

Ben genellikle şu tarz durumlarda pointer yaklaşımını değerlendirebilirim:

• Değerin kendisini sürekli okumam gerekiyorsa

• Oyuncu nesnesi stabil şekilde bulunabiliyorsa

• Aynı nesne içinde birden fazla değer varsa

• Sağlam bir root pointer varsa

• Değer freeze edilecekse

• Bir butonla belirli bir değer yazılacaksa

Örneğin aynı player nesnesinde:

• Health

• Stamina

• Hunger

• Thirst

bulunuyorsa bir kez player pointer'ı bulup bütün özellikleri bunun üzerinden yönetmek mantıklı olabilir.

🔎 AOB Hangi Durumlarda Mantıklı?

AOB ise daha çok:

• oyun fonksiyonunu bulmak,

• code cave yerleştirmek,

• patch uygulanacak kodu bulmak,

• runtime pointer yakalamak,

• sabit RVA'dan kurtulmak

istediğim durumlarda işime yarıyor.

Özellikle native oyunlarda oldukça önemli bir araç.

❌ Kötü Pointer Nasıl Olur?

Pointer scan yaptığınızda bazen milyonlarca sonuç çıkabilir.

Bir tanesini seçip:

Çalışıyor.

demek yeterli değil.

O zincir:

• sadece mevcut save'de,

• sadece mevcut karakterde,

• sadece mevcut oturumda

çalışıyor olabilir.

Oyunu yeniden açınca kırılıyorsa trainer için pek işe yaramaz.

Pointer bulduktan sonra farklı oturumlarda tekrar test etmek önemli.

❌ Kötü AOB Nasıl Olur?

AOB tarafında da benzer durum var.

İmza:

48 8B ?? ??

gibi fazla genel olursa oyunda yüzlerce sonuç bulabilir.

Aşırı spesifik yaparsak da küçücük güncellemede bozulabilir.

İyi signature hazırlarken amaç:

Benzersizlik ile esneklik arasında denge kurmak.

🧪 Ben Genelde Nasıl Karar Veriyorum?

Bir özellik geliştirirken kabaca şu sırayla düşünüyorum:

Oyunun kendi sistemi bunu yapabiliyor mu?

Evetse mümkünse onu kullanırım.

Örneğin CryEngine CVar, Mono, Unreal reflection veya Python gibi.

Olmuyorsa:

Değere stabil şekilde ulaşabiliyor muyum?

Evetse pointer veya runtime field çözümü kullanabilirim.

Olmuyorsa:

İlgili kodu stabil şekilde bulabiliyor muyum?

Burada AOB devreye girebilir.

Daha karmaşık bir işlem gerekiyorsa:

AOB + Code Cave + Runtime Capture

gibi yöntemleri birlikte kullanabilirim.

🎮 ORGA Hub'da İkisi de Kullanılıyor

ORGA Hub trainer sisteminde tek bir yönteme bağlı kalmıyorum.

Bazı özelliklerde:

• Pointer

• Pointer freeze

• Pointer button

kullanılırken bazı özelliklerde:

• AOB

• Patch

• Code cave

• Runtime capture

kullanılıyor.

Bazı trainerlerde ise ikisi aynı özelliğin farklı aşamalarında birlikte çalışıyor.

Örneğin AOB ile oyuncu nesnesini yakalayıp daha sonra pointer offsetleri üzerinden değerleri değiştirmek mümkün.

❤️ Kısaca Özetleyelim

En basit ayrım şu:

Pointer

Veriye giden yolu takip eder.

AOB Signature

Bellekte belirli bir byte/kod desenini arar.

Birisi diğerinin yerine tamamen geçmez.

Trainer geliştirirken bazen pointer daha mantıklı olur, bazen AOB, bazen de ikisinin birlikte kullanılması gerekir.

Benim için en iyi yöntem:

oyunun yapısına en uygun ve mümkün olduğunca stabil olan yöntem.

Bu yüzden ORGA Hub'daki trainerlerde tek bir teknik yerine oyunlara göre farklı sistemler kullanıyorum.

Bir sonraki teknik konuda da trainerlerde sık kullandığım başka bir yönteme geçip Code Cave nedir, nasıl çalışır ve neden kullanılır? kısmını anlatacağım.