🉐 ✍🏼 ✋ मोबाइल MMORPG नेटवर्क प्रोटोकॉल को पार्स कैसे करें 🎒 🌴 👲🏽

एक मोबाइल MMORPG खेलने के वर्षों में, मैंने इसके रिवर्स इंजीनियरिंग में कुछ अनुभव प्राप्त किया है, जिसे मैं लेखों की एक श्रृंखला में साझा करना चाहूंगा। नमूना विषय:

सर्वर और क्लाइंट के बीच पार्स संदेश स्वरूप।
गेम ट्रैफ़िक को सुविधाजनक तरीके से देखने के लिए एक सुनने का अनुप्रयोग लिखना।
गैर-HTTP प्रॉक्सी सर्वर का उपयोग करके ट्रैफ़िक अवरोधन और इसका संशोधन।
अपने खुद के ("पायरेटेड") सर्वर के लिए पहला कदम।

इस लेख में, मैं सर्वर और क्लाइंट के बीच संदेश प्रारूप को पार्स करने पर चर्चा करूंगा। रुचि, मैं बिल्ली के लिए पूछना।

आवश्यक उपकरण

नीचे वर्णित चरणों को दोहराने में सक्षम होने के लिए, आपको निम्न की आवश्यकता होगी:

पीसी (मैंने विंडोज 7/10 पर किया था, लेकिन मैकओएस बहुत काम कर सकता है अगर नीचे की वस्तुएं उपलब्ध हों);
पैकेट विश्लेषण के लिए विरेचक;
टेम्पलेट द्वारा पैकेट पार्स करने के लिए 010Editor (वैकल्पिक, लेकिन आपको संदेश प्रारूप को जल्दी और आसानी से वर्णन करने की अनुमति देता है);
खेल के साथ ही मोबाइल डिवाइस।

इसके अलावा, हाथ में खेल से पढ़ने योग्य डेटा, जैसे कि उनके पहचानकर्ताओं के साथ वस्तुओं, प्राणियों आदि की सूची होना बहुत ही वांछनीय है। यह संकुल में प्रमुख बिंदुओं की खोज को बहुत सरल करता है, और कभी-कभी यह आपको डेटा के निरंतर प्रवाह में वांछित संदेश को फ़िल्टर करने की अनुमति देता है।

पदच्छेद सर्वर और क्लाइंट के बीच संदेश प्रारूप

आरंभ करने के लिए, हमें मोबाइल डिवाइस का ट्रैफ़िक देखना होगा। ऐसा करना काफी सरल है (हालांकि मैं बहुत लंबे समय के लिए इस स्पष्ट निर्णय पर पहुंच गया): हमारे पीसी पर हम एक वाई-फाई एक्सेस प्वाइंट बनाते हैं, इसे मोबाइल डिवाइस से कनेक्ट करते हैं, विंडसर में वांछित इंटरफेस का चयन करते हैं - और हमारी आंखों के सामने सभी मोबाइल हैं।

खेल में प्रवेश करने और कुछ समय के लिए प्रतीक्षा करने के बाद ताकि खेल सर्वर से संबंधित अनुरोधों को खुद ही रोक न दिया जाए, आप निम्नलिखित चित्र देख सकते हैं:

इस स्तर पर, हम पहले से ही गेम और सर्वर के बीच केवल पैकेट देखने के लिए विंडसर फिल्टर का उपयोग कर सकते हैं, साथ ही केवल पेलोड के साथ:

tcp && tcp.payload && tcp.port == 44325

यदि आप अन्य खिलाड़ियों और एनपीसी से दूर एक शांत जगह पर खड़े होते हैं, और कुछ भी नहीं करते हैं, तो आप सर्वर और क्लाइंट से लगातार संदेश दोहराते हुए देख सकते हैं (आकार 76 और 84 बाइट्स, क्रमशः)। मेरे मामले में, चरित्र चयन स्क्रीन पर विभिन्न पैकेजों की न्यूनतम संख्या भेजी गई थी।

क्लाइंट से अनुरोध की आवृत्ति पिंग के समान है। सत्यापन के लिए कुछ संदेश दें (3 समूह, ऊपर एक ग्राहक से एक अनुरोध है, नीचे यह एक सर्वर की प्रतिक्रिया है):

आपकी आंख को पकड़ने वाली पहली चीज संकुल की पहचान है। दशमलव प्रणाली में परिवर्तित होने पर प्रतिक्रिया में 8 अतिरिक्त बाइट्स सेकंड में टाइमस्टैम्प के समान हैं: 5CD008F8 ₁₆ = 1557137656 ₁₀ (पहली जोड़ी से)। हम घड़ी की जांच करते हैं - हां, यह है। पिछले 4 बाइट्स अनुरोध में अंतिम 4 बाइट्स से मेल खाते हैं। अनुवाद करते समय, हम प्राप्त करते हैं: A4BB ₁₆ = 42171 ₁₀ , जो समय के समान है, लेकिन मिलीसेकंड में भी। यह खेल के लॉन्च के समय से लगभग पूरी तरह से मेल खाता है, और सबसे अधिक संभावना है।

यह अनुरोध और प्रतिक्रिया के पहले 6 बाइट्स पर विचार करने के लिए बनी हुई है। संदेश के पहले चार बाइट्स के मान की निर्भरता पर ध्यान देना आसान है (आइए इस पैरामीटर L कॉल करें) संदेश के आकार पर: सर्वर से प्रतिक्रिया 8 बाइट्स से अधिक है, L के मूल्य में भी 8 से वृद्धि हुई है, हालांकि, पैकेट का आकार दोनों मामलों में L के मूल्य के 6 बाइट्स से अधिक है। आप यह भी देख सकते हैं कि L बाद के दो बाइट्स क्लाइंट और सर्वर से अनुरोधों में अपना मूल्य बनाए रखते हैं, और यह देखते हुए कि उनका मूल्य एक से भिन्न है, हम विश्वास के साथ कह सकते हैं कि यह संदेश कोड C (संबंधित संदेश कोड सबसे अधिक संभावना निर्धारित किया जाएगा। क्रमिक रूप से)। सामान्य संरचना 010Editor के लिए न्यूनतम टेम्पलेट लिखने के लिए पर्याप्त स्पष्ट है:

पहले 4 बाइट्स - L - संदेश पेलोड आकार;
अगले 2 बाइट्स - C - संदेश कोड;
पेलोड ही।

 struct Event { uint payload_length <bgcolor=0xFFFF00, name="Payload Length">; ushort event_code <bgcolor=0xFF9988, name="Event Code">; byte payload[payload_length] <name="Event Payload">; };

इसलिए, क्लाइंट पिंग संदेश का प्रारूप: स्थानीय पिंग समय भेजें; सर्वर प्रतिक्रिया प्रारूप: सेकंड में प्रतिक्रिया भेजने का एक ही समय और समय भेजें। यह मुश्किल नहीं लगता है, है ना?

आइए एक उदाहरण को और अधिक जटिल बनाने का प्रयास करें। एक शांत जगह पर खड़े होकर पिंग पैकेट छिपाकर, आप संदेश टेलीपोर्ट पा सकते हैं और आइटम (शिल्प) बना सकते हैं। पहले एक के साथ शुरू करते हैं। गेम डेटा को देखते हुए, मुझे पता था कि टेलीपोर्ट पॉइंट का क्या मूल्य है। परीक्षणों के लिए, मैंने 0x2B , 0x67 , 0x6B और 0x1AF मूल्यों के साथ बिंदुओं का उपयोग किया। संदेशों में मूल्यों की तुलना करें: 0x2B , 0x67 , 0x6B और 0x3AF :

गड़बड़। दो समस्याएं दिखाई देती हैं:

मान 4 बाइट्स नहीं हैं, लेकिन विभिन्न आकारों के हैं;
सभी मान फ़ाइलों से डेटा से मेल नहीं खाते हैं, और इस मामले में अंतर 128 है।

इसके अतिरिक्त, जब पिंग प्रारूप के साथ तुलना की जाती है, तो आप कुछ अंतर देख सकते हैं:

अपेक्षित मान से पहले 0x08 ;
4-बाइट मान, L से 4 कम (चलो इसे D कहते हैं D यह फ़ील्ड सभी संदेशों में प्रकट नहीं होती है, जो थोड़ा अजीब है, लेकिन यह कहाँ है, निर्भरता L - 4 = D संरक्षित है। एक तरफ, संदेशों के लिए। एक साधारण संरचना (पिंग की तरह) इसकी आवश्यकता नहीं है, लेकिन दूसरे पर - यह बेकार दिखता है)।

आप में से कुछ, मुझे लगता है, पहले से ही अपेक्षित मूल्यों के बेमेल होने का कारण अनुमान लगा सकता था, लेकिन मैं जारी रखूंगा। आइए देखें कि शिल्प में क्या हो रहा है:

14183 और 14285 के अनुमानित मूल्य भी वास्तविक 28391 और 28621 के अनुरूप नहीं हैं, लेकिन यहां अंतर पहले से ही 128 से अधिक है। कई परीक्षणों (अन्य प्रकार के संदेशों सहित) के बाद यह पता चला कि अपेक्षित संख्या जितनी बड़ी होगी, पैकेट में मूल्य के बीच का अंतर उतना ही अधिक होगा। क्या अजीब बात थी कि १२ was तक के मूल्य अपने आप बने रहे। समझ गया, क्या हाल है? स्पष्ट स्थिति उन लोगों के लिए है जो पहले से ही इसका सामना कर चुके हैं, और अनजाने में, मुझे इस "सिफर" को दो दिनों के लिए अलग करना पड़ा (अंत में, बाइनरी फॉर्म में मूल्यों के विश्लेषण ने "हैकिंग" में मदद की)। ऊपर वर्णित व्यवहार को परिवर्तनीय लंबाई की मात्रा कहा जाता है - एक संख्या का प्रतिनिधित्व करता है जो अनिश्चित संख्या के बाइट्स का उपयोग करता है, जहां एक बाइट की आठवीं बिट (निरंतरता बिट) अगले बाइट की उपस्थिति निर्धारित करती है। विवरण से, यह स्पष्ट है कि वीएलक्यू पढ़ना केवल लिटिल-एंडियन क्रम में संभव है। संयोग से, पैकेट में सभी मूल्य उसी क्रम में हैं।

अब जब हम जानते हैं कि प्रारंभिक मूल्य कैसे प्राप्त किया जाए, तो हम टाइप के लिए एक टेम्प्लेट लिख सकते हैं:

 struct VLQ { local char size = 1; while(true) { byte obf_byte; if ((obf_byte & 0x80) == 0x80) { size++; } else { break; } } FSeek(FTell() - size); byte bytes[size]; local uint64 _ = FromVLQ(bytes, size); };

और बाइट्स के एक सरणी को पूर्णांक मान में बदलने का कार्य:

 uint64 FromVLQ(byte bytes[], char size) { local uint64 source = 0; local int i = 0; local byte x; for (i = 0; i < size; i++) { x = bytes[i]; source |= (x & 0x7F) * Pow(2, i * 7); //   <<   , ..     ,  uint32,        uint64 if ((x & 0x80) != 0x80) { break; } } return source; };

लेकिन वापस विषय के निर्माण के लिए। फिर से D दिखाई देता है और फिर से बदलते मूल्य के सामने 0x08 । 0x10 0x01 संदेश के अंतिम दो बाइट्स संदिग्ध रूप से क्राफ्टिंग आइटम की संख्या के समान हैं, जहां 0x10 की भूमिका 0x08 समान है लेकिन फिर भी समझ से बाहर है। लेकिन अब आप इस ईवेंट के लिए एक टेम्प्लेट लिख सकते हैं:

 struct CraftEvent { uint data_length <bgcolor=0x00FF00, name="Data Length">; byte marker1; VLQ craft_id <bgcolor=0x00FF00, name="Craft ID">; byte marker2; VLQ quantity <bgcolor=0x00FF00, name="Craft Quantity">; };

जो इस तरह दिखेगा:

और फिर भी, ये सरल उदाहरण थे। चरित्र के आंदोलन की घटना को पार्स करना अधिक कठिन होगा। हम क्या जानकारी देखने की उम्मीद करते हैं? कम से कम, चरित्र के निर्देशांक जहां वह देख रहा है, गति और स्थिति (खड़े, दौड़, कूद, आदि)। चूंकि संदेश में कोई रेखाएं दिखाई नहीं देती हैं, इसलिए सबसे अधिक संभावना है कि राज्य का वर्णन enum माध्यम से किया जाए। विकल्पों की गणना करके, गेम फ़ाइलों से डेटा के साथ उनकी तुलना करने के साथ-साथ कई परीक्षणों के माध्यम से, आप इस बोझिल टेम्पलेट का उपयोग करके तीन XYZ वैक्टर पा सकते हैं:

 struct MoveEvent { uint data_length <bgcolor=0x00FF00, name="Data Length">; byte marker; VLQ move_time <bgcolor=0x00FFFF>; FSkip(2); byte marker; float position_x <bgcolor=0x00FF00>; byte marker; float position_y <bgcolor=0x00FF00>; byte marker; float position_z <bgcolor=0x00FF00>; FSkip(2); byte marker; float direction_x <bgcolor=0x00FFFF>; byte marker; float direction_y <bgcolor=0x00FFFF>; byte marker; float direction_z <bgcolor=0x00FFFF>; FSkip(2); byte marker; float speed_x <bgcolor=0x00FFFF>; byte marker; float speed_y <bgcolor=0x00FFFF>; byte marker; float speed_z <bgcolor=0x00FFFF>; byte marker; VLQ character_state <bgcolor=0x00FF00>; };

दृश्य परिणाम:

हरे रंग के तीन स्थान के निर्देशांक के रूप में निकला, पीला तीन, सबसे अधिक संभावना है, जहां चरित्र दिख रहा है और उसकी गति का वेक्टर है, और अंतिम एक चरित्र की स्थिति है। आप समन्वय मूल्यों ( X मान से पहले 0x0D , Y से पहले 0x1D और Z से पहले 0x1D ) और राज्य से पहले ( 0x30 ) के बीच निरंतर बाइट्स (मार्कर) देख सकते हैं, जो कि 0x08 और 0x10 अर्थ में संदिग्ध रूप से समान हैं। अन्य घटनाओं के कई मार्करों का विश्लेषण करने के बाद, यह पता चला है कि यह इसके बाद के मूल्य (पहले तीन बिट्स) और अर्थ अर्थ का प्रकार निर्धारित करता है, अर्थात। ऊपर दिए गए उदाहरण में, यदि आप अपने मार्करों (निर्देशांक, आदि के सामने 0x120F को बनाए रखते हुए वैक्टर स्वैप करते हैं, तो खेल (सैद्धांतिक रूप से) को सामान्य रूप से संदेश को पार्स करना चाहिए। इस जानकारी के आधार पर, आप कुछ नए प्रकार जोड़ सकते हैं:

 struct Packed { VLQ marker <bgcolor=0xFFBB00>; //    VLQ! local uint size = marker.size; //       ( , )          switch (marker._ & 0x7) { case 1: double v; size += 8; break; //     case 5: float v; size += 4; break; default: VLQ v; size += v.size; break; } }; struct PackedVector3 { Packed marker <name="Marker">; Packed x <name="X">; Packed y <name="Y">; Packed z <name="Z">; };

अब हमारा गति संदेश टेम्प्लेट काफी कम हो गया है:

 struct MoveEvent { uint data_length <bgcolor=0x00FF00, name="Data Length">; Packed move_time <bgcolor=0x00FFFF>; PackedVector3 position <bgcolor=0x00FF00>; PackedVector3 direction <bgcolor=0x00FF00>; PackedVector3 speed <bgcolor=0x00FF00>; Packed state <bgcolor=0x00FF00>; };

एक अन्य प्रकार जिसे हमें अगले लेख में आवश्यकता हो सकती है वह रेखाएं हैं जो उनके आकार के Packed मूल्य से पहले हैं:

 struct PackedString { Packed length; char str[length.v._]; };

अब, नमूना संदेश प्रारूप को जानते हुए, आप संदेशों को फ़िल्टर करने और उनका विश्लेषण करने की सुविधा के लिए अपना सुनने का आवेदन लिख सकते हैं, लेकिन यह अगले लेख के लिए विषय है।

अपडेट: संकेत के लिए धन्यवाद कि ऊपर वर्णित संदेश संरचना प्रोटोकॉल बफ़र है , और उपयोगी लेख के लिंक के लिए टाटीकोमा भी है।

मोबाइल MMORPG नेटवर्क प्रोटोकॉल को पार्स कैसे करें

आवश्यक उपकरण

पदच्छेद सर्वर और क्लाइंट के बीच संदेश प्रारूप

More articles: