vSro Paylaşım Silkroad Online Protokol Referansı: Düzeltilmiş 288 Opcode Haritası ve İstek-Yanıt Eşleşme Matrisi

Silkroad Online Protokol Referansı: Düzeltilmiş 288 Opcode Haritası ve İstek-Yanıt Eşleşme Matrisi

Silkroad Online ağ protokolü üzerinde çalışan bot, filtre, proxy ve emülatör geliştiricilerinin yıllardır karşılaştığı en büyük sorun; istemci ikilisinden (`sro_client.exe`) türetilen paket ve opcode isimlerinin **ciddi oranda yanıltıcı ve hatalı** olmasıdır. İstemci kodunda yalnızca arayüz veya dahili olay numaralandırması için kullanılan etiketler, geliştiriciler tarafından asıl paket adı sanılmış ve onlarca yanlış dokümantasyona yol açmıştır.

Bu teknik monografta; GameServer ikilisinin (`SR_GameServer_Andreas.exe`) tersine mühendislik verileriyle çapraz doğrulanmış **288 adet işlem kodunun (Opcode) düzeltilmiş gerçek isimleri**, bilinmeyen (`unk`) bayt alanlarının gerçek anlamları, **$\text{Response} = \text{Request} + \text{0x4000}$ istek-yanıt matematiksel eşleme matrisi** ve bellek içi mesaj inşa (`CMsgStreamBuffer`) rutinleri akademik bir kesinlikle sunulmaktadır.

---

### 1. İstemci Yanılsaması vs Sunucu Doğrulaması

İstemcideki bazı işleyici isimleri paketin gerçek işlevini tamamen ters göstermektedir:
- İstemci analizinde `0x3015` işlem koduna *"SERVER_CHARACTER_DELETE_RESPONSE"* adı verilmişti. Oysa sunucu çekirdeği incelendiğinde bu paketin oyunun en kritik paketi olan **`SERVER_ENTITY_SPAWN`** (Dünyada yeni bir oyuncu, canavar, NPC, pet, binek, teleport kapısı veya düşen eşya belirten spawn paketi) olduğu kesinleşmiştir.
- Benzer şekilde `0x3016` paketi *"SERVER_CHARACTER_RESTORE"* değil, varlığın görüş alanından çıktığını veya öldüğünü bildiren **`SERVER_ENTITY_DESPAWN`** paketidir.
- `0x3013` paketi karakter oluşturma yanıtı değil, oyuna girişte tüm karakter profilini yükleyen **`SERVER_CHARACTER_DATA`** paketidir.

---

### 2. Sunucu Çekirdeği ile Düzeltilmiş Kritik Opcode Listesi



---

### 3. Bilinmeyen ("unk") Alanların Çözümlenmesi

İstemci ayrıştırmalarında daha önce `unkByte` veya `unkUInt` olarak bırakılan kritik alanlar, GameServer debug sembolleriyle adlandırılmıştır:



---

### 4. İstek ↔ Yanıt Matematiksel Eşleme Kuralı (Request ↔ Response)

Silkroad Online protokolünde istemciden sunucuya gönderilen bir istek (Request) paketi ile sunucudan dönen yanıt (Response) paketi arasında katı bir matematiksel bağıntı vardır:

$$\mathbf{Response\_Opcode} = \mathbf{Request\_Opcode} + \mathbf{0x4000}$$

İstemci istekleri kural olarak **`0x7000 – 0x7FFF`** aralığında yer alırken; sunucunun aynı işleme verdiği yanıt **`0xB000 – 0xBFFF`** aralığında döner.



---

### 5. Değişken Uzunluklu Mesajlar ve Ayrıştırma Desenleri

Belgelenen 288 paketin **181 tanesi değişken uzunluklu (Variable-Length)** yapılardan oluşur. Bu paketler 3 temel desenle inşa edilir:

1. **Sonuç Kodu Dallanması (Result-Based Branching):**
Paketin ilk baytı `result_code` taşır.
- `result == 1` (Başarılı): Arkasından ek veri alanları ve ID blokları akar.
- `result == 2` (Başarısız): Paket doğrudan sonlanır veya 2 baytlık hata kodu (`error_code`) eklenir.
2. **Tip Tabanlı Dallanma (Type-Based Branching):**
`0x3015` (Spawn) paketinde olduğu gibi, varlık türü (`TypeID`) okunur; eğer oyuncu ise ekipman ve lonca bayrakları, eğer mob ise canavar ID ve hedef indeksi, eğer yerdeki eşya ise `ItemID` ve sahip ID okunur.
3. **Sayı Tabanlı Döngüler (Count-Based Loops):**
Önce eleman adedi (`uint8_t count`) okunur, ardından döngü kurularak o sayıda alt-struct bellekten çekilir (Parti üyeleri, envanter slotları, lonca üyeleri).

---

### 6. Bellek İçi Mesaj İnşa Mekanizması (`CMsgStreamBuffer`)

İstemci dışarıya paket gönderirken `CMsgStreamBuffer` sınıfını şu sıralı fonksiyon zinciriyle koşturur:



---

### 7. Geliştiriciler İçin Protokol İlkeleri

1. **Doğru Opcode İsimlendirmesi:** Projelerinizde eski istemci isimleri yerine doğrulanmış sunucu isimlerini (`SERVER_ENTITY_SPAWN`, `SERVER_CHARACTER_DATA`) kullanın; bu sayede mantıksal karmaşanın önüne geçmiş olursunuz.
2. **+0x4000 Kuralı:** Yeni bir istemci eylemi dinlenirken veya taklit edilirken, istek koduna `0x4000` eklenerek sunucu yanıt kodunun anında tespit edilebileceğini unutmayın.
3. **Değişken Boyut Güvenliği:** Paket ayrıştırma kodlarında sabit boyut varsayımı (`sizeof(struct)`) yapmayın; mutlaka `result_code` ve döngü sayaçlarını kontrol ederek dinamik okuma yapın.

---

Silkroad Geliştirici Camiasına Teşekkür ve Saygı

Bu kapsamlı teknik dokümantasyon, tersine mühendislik mimarisi ve protokol analizlerinin gün ışığına çıkmasında Silkroad ekosistemine yıllardır karşılıksız devasa emekler veren ve bu mirası ileriye taşımaya devam eden öncü geliştiricilerimize en içten teşekkürlerimizi sunarız:

DaxterSoul — Paket filtreleme, proxy mimarileri ve sunucu güvenliğindeki temel çalışmaları ve topluluğa kazandırdığı standartlar için,
florian0 — İstemci (Client) ve GameServer ikili (binary) tersine mühendisliği, hook ve assembly düzeyindeki rehber niteliğindeki araştırmaları için,
JellyBitz — Açık kaynak Silkroad araçları, paket analiz kütüphaneleri ve geliştirici ekosistemine sunduğu paha biçilmez açık kaynak yazılımlar için,
ferdoran — İstemci-sunucu protokol analizlerinin, opcode referanslarının ve teknik dokümantasyonun derlenip topluluğa kazandırılmasındaki büyük gayretleri için.

Silkroad geliştirici topluluğuna kattığınız değer, paylaştığınız bilgi birikimi ve sunduğunuz vizyon için sonsuz teşekkürler. İyi ki varsınız!

Genişletmek için tıkla ...