रिवर्स इंजीनियरिंग शानदार चक्कर

शानदार Dizzy 1991 में Codemasters द्वारा बनाई गई एक पहेली platformer खेल है। वह डिज़ी सीरीज़ का हिस्सा हैं। इस तथ्य के बावजूद कि डिज़ी श्रृंखला अभी भी लोकप्रिय है, और यह शौकिया गेम ( डिज़ी आयु ) बनाता है, ऐसा लगता है कि कोई भी मूल गेम के रिवर्स विकास में शामिल नहीं था।


मैंने मूल गेम के संसाधनों को निकालने, देखने और पैकेज करने के लिए कुछ सरल उपकरण लिखे। उपकरण GitHub पर पोस्ट किया गया।

पैकिंग खोलना

बाइनरी फ़ाइल PCDIZZY.EXE को Microsoft EXEPack प्रारूप में पैक किया गया है। हालांकि कई लिनक्स उपकरण हैं जो इस तरह के निष्पादनयोग्य को विघटित कर सकते हैं, उनमें से कोई भी शानदार डेज़ी के लिए उपयोग किए जाने वाले संस्करण का समर्थन नहीं करता है। इसलिए, निष्पादन योग्य फ़ाइल को अनपैक करने के लिए, मैंने यूएनपी के डॉस संस्करण का उपयोग किया। निष्पादन योग्य फ़ाइल को अनपैक करने के बाद, इसे आईडीए में डाउनलोड किया जा सकता है। आसानी से, बाइनरी फ़ाइल का अनपैक्ड संस्करण अभी भी अच्छी तरह से काम करता है, इसलिए इसे डॉसबॉक्स डीबगर का उपयोग करके डीबग किया जा सकता है।

डेटा फ़ाइलें

खेल में दो डेटा फाइलें हैं: DIZZY.NDX और DIZZY.RES। एक्सटेंशन, साथ ही फ़ाइल आकार, हमें एक संकेत देते हैं कि उनमें क्या हो सकता है। NDX फ़ाइल लगभग 8 KB है, और RES फ़ाइल लगभग 800 KB है। चूंकि खेल सी में लिखा गया है, इसलिए हम आईडीए में फोपेन कॉल की खोज कर सकते हैं कि डेटा फाइलें कहां खुलती हैं। असेंबलर में लिखे गए डॉस गेम्स में, इसके लिए आपको निर्देश 21h देखने की जरूरत है (फ़ाइल आह = डी 3 डी खोलने के लिए)। डिज़ी बाइनरी में फ़ोपेन के चारों ओर एक आवरण फ़ंक्शन होता है जो आपको मुख्य नाम और फ़ाइल एक्सटेंशन को निर्दिष्ट करने की अनुमति देता है। यह हमें कोड के निम्नलिखित ब्लॉक में ले जाता है:


यह DIZZY.RES और DIZZY.NDX फ़ाइलों को लोड करता है, और वैश्विक चर में फ़ाइल पॉइंटर्स को भी बचाता है। जब रिवर्स इंजीनियरिंग डॉस बायनेरिज़, एक कष्टप्रद समस्या उत्पन्न होती है: उनमें रजिस्टरों 16-बिट होते हैं, लेकिन कुछ मामलों में संकेत 32-बिट हो सकते हैं। यहाँ FILE * पॉइंटर्स आकार में 32 बिट्स हैं और do_open_file से ax: dx पर लौटे हैं। ध्यान दें कि स्ट्रिंग्स भी 32-बिट पॉइंटर्स हैं, और चक्कर पर कॉलिंग फ़ंक्शन (और यह भ्रमित आईडीए ऑटोएनालिसिस - यह fopen के लिए एक मोड तर्क माना जाता था) के लिए पारित किया जाता है।

Xrefs में g_dizzy_res / ndx की घटनाओं को देखकर, आप पा सकते हैं कि फ़ाइलें कहाँ पढ़ी जाती हैं। डॉसबॉक्स डिबगर इस बिंदु पर उपयोगी है, क्योंकि कई यादृच्छिक फ़ाइल रीड ऑपरेशंस की उच्च संभावना है, और रीड ऑफ़सेट निर्धारित करने के लिए आईडीए का उपयोग करना एक बहुत नीरस प्रक्रिया होगी। DOSBox डिबगर के निर्माण और उपयोग पर अच्छा मार्गदर्शन यहां पाया जा सकता है ।

IDA और DOSBox डीबगर को एक साथ उपयोग करते समय, यह स्पष्ट हो जाता है कि NDX फ़ाइल का उपयोग RES फ़ाइल के लिए एक इंडेक्स के रूप में किया जाता है। NDX फ़ाइल में प्रत्येक प्रविष्टि 16 बाइट्स लेती है; यह आरईएस फ़ाइल में खंड पहचानकर्ता, उसके आकार और ऑफसेट को संग्रहीत करता है। आरईएस डेटा को कैसे पढ़ा जाता है, इसे देखते हुए, आप देख सकते हैं कि फ्लैग बाइट को पहले एनडीएक्स फ़ाइल में चेक किया गया है। यदि बिट 0x80 सेट नहीं है, तो डेटा को सीधे RES फ़ाइल से पढ़ा जाता है, अन्यथा एक अधिक जटिल कोड पथ निष्पादित होता है। झंडे को अधिकांश टुकड़ों के लिए सेट किया गया है, इसलिए उच्च संभावना के साथ हम यह मान सकते हैं कि यह इन टुकड़ों के लिए उपयोग किए जाने वाले कुछ प्रकार के संपीड़न को दर्शाता है।

दबाव

कंपास पथ आरईएस टुकड़े के आधार से पढ़कर शुरू होता है दो 32-बिट शब्द प्रारंभिक और अंतिम आकारों का संकेत देते हैं, और फिर विघटन फ़ंक्शन को कहा जाता है। 1991 में, सरल रन लंबाई एन्कोडिंग (RLE) और शब्दकोश संपीड़न लोकप्रिय थे, जैसे कि विभिन्न Liv-Zempel एल्गोरिदम। अनपैकिंग चक्र की शुरुआत इस तरह होती है:


अनपैकिंग के लिए टोकन get_next_token फ़ंक्शन का उपयोग करके प्राप्त किए जाते हैं, जो कि स्रोत डेटा के अगले भाग को कुल्हाड़ी में पढ़ता है: dx by a shift by cl। सीएल रजिस्टर का उपयोग बिट शिफ्ट की स्थिति के रूप में किया जाता है, आठ तक पहुंचने के बाद शून्य पर लौटा। चक्र की शुरुआत में, टोकन पढ़ा जाता है और निचले बिट की जांच की जाती है। यदि ध्वज सेट है, तो कोड सरल है:


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

संपीड़न एल्गोरिथ्म कई कारणों से दिलचस्प है। सबसे पहले, यह चर बिट लंबाई एन्कोडिंग का उपयोग करता है। निरपेक्ष मान 1 ध्वज और 8-बिट डेटा मान के रूप में एन्कोड किया गया है। उत्सुकता से, बिटस्ट्रीम को छोटे एंडियन के रूप में एन्कोड किया गया है। यह एक हेक्स संपादक में RES फ़ाइल का अवलोकन करके अपघटन के विश्लेषण को थोड़ा जटिल करता है। उदाहरण के लिए, यदि टुकड़े के पहले तीन बाइट्स को पूर्ण मान के रूप में एन्कोड किया जाता है, तो डेटा निम्नानुसार व्यवस्थित किया जाता है:

 : AAAAAAAA BBBBBBBB CCCCCCCC DDDDDDDD  1: 6543210F 7  2: 543210F 76  3: 43210F 765 

इसके अलावा, अनपैक पढ़ने पर बाइट को छोड़ सकता है, यदि काउंटर टोकन अगले टोकन की प्राप्ति पर शून्य पर लौटता है। मुझे नहीं पता कि यह अनुकूलन है, या बग, या गेम डेवलपर द्वारा बनाई गई कोई हैक मेरे उपकरणों के साथ समस्या को ठीक करने के लिए है।

यदि ध्वज को साफ़ किया जाता है, तो अनपैकर अनपैक किए गए डेटा के प्रारंभिक भाग से प्रतिलिपि बनाता है। इस स्थिति में, निम्नलिखित बिट्स लंबाई और ऑफसेट को कॉपी करने के लिए एन्कोड करते हैं। ऑफसेट 10 या 13 बिट्स में एन्कोडेड है, और वांछित विकल्प ध्वज को इंगित करता है। यह एक बहुत ही अजीब पसंद की तरह लगता है, क्योंकि यह कोड को थोड़ा जटिल करता है, और सबसे अच्छा केवल 2 बिट्स बचाता है।

श्रृंखला की लंबाई एन्कोडिंग थोड़ा अजीब लगता है। अनपैकर बिट्स को तब तक पढ़ता है जब तक वह शून्य बिट तक नहीं पहुंच जाता। फिर लंबाई को एनकोड करने के लिए उपयोग किए जाने वाले बिट्स की संख्या दो से अधिक है और गैर-शून्य बिट्स की संख्या है। उदाहरण के लिए, जब 58 (0x3a) की लंबाई एन्कोडिंग होती है, तो बिटस्ट्रीम इस तरह दिखता है:

 11110 111010 

एन्कोडिंग के लिए 11 बिट्स की आवश्यकता होती है। छोटी लंबाई बेहतर एन्कोडेड होती है क्योंकि न्यूनतम बिट लंबाई 2 होती है। 3 तक की लंबाई को कॉपी करने के लिए केवल 3 बिट्स को एन्कोड करना होता है, 7 तक 5 बिट्स की आवश्यकता होती है, और इसी तरह। मुझे इस बात की जानकारी नहीं है कि इस प्रकार की कोडिंग एक सामान्य तकनीक है या नहीं।

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

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

स्तरों

विलक्षण चक्कर एक खुली दुनिया के साथ एक खेल है। स्तर ऊर्ध्वाधर या क्षैतिज स्क्रॉलिंग वाले क्षेत्र हैं। खिलाड़ी स्तरों के बीच चलता है, स्तर के अंत तक पहुंचता है या इमारतों में प्रवेश करता है और छोड़ता है। हालाँकि RES फ़ाइल में अंशों का संदर्भ 16-बिट आइडेंटीफायर (ID) के माध्यम से बनाया जाता है, लेकिन गेम की बाइनरी फाइल में वास्तव में टुकड़े पहचानकर्ताओं के साथ मिलान स्तर के नामों की एक तालिका होती है। प्रत्येक स्तर में कई टुकड़े होते हैं: एक शीर्षक, एक या अधिक परतें, एक टाइलसेट और एक पैलेट। यहां थोड़ा अतिरेक है, क्योंकि कुछ स्तर समान पैलेट और टाइलसेट का उपयोग करते हैं, लेकिन समान टुकड़ों का पुन: उपयोग नहीं करते हैं, इसलिए RES फ़ाइल में कई डुप्लिकेट संसाधन हैं।

परतें एक स्तर के लिए टाइल्स को एनकोड करती हैं। दुनिया के विभिन्न हिस्सों के लिए या पृष्ठभूमि परतों के लिए, आप अतिरिक्त परतों का उपयोग कर सकते हैं। उदाहरण के लिए, Tree1.stg के स्तर पर, पेड़ों के शीर्ष के विभिन्न भागों के लिए आठ परतें होती हैं और एक सामान्य पृष्ठभूमि परत होती है। हालाँकि, पानी के नीचे के स्तर को sea1.stg और sea2.stg में विभाजित किया गया है, जिनमें से प्रत्येक में एक अग्रभूमि परत और एक पृष्ठभूमि परत है।

स्क्रॉलिंग के बिना पृष्ठभूमि की परतें निश्चित-चौड़ाई की पृष्ठभूमि हैं, उदाहरण के लिए, पेड़ के शीर्ष के साथ खेल के एक हिस्से में एक जंगल। अग्रभूमि और पृष्ठभूमि टाइलें, जो चरित्र के सामने और पीछे स्थित हैं, उसी परत में एन्कोडेड हैं जिस टाइल पर आप चल सकते हैं। उदाहरण के लिए, स्क्रीनशॉट खेल की शुरुआत से पेड़ों की चोटी से स्तर दिखाता है:


ट्रीटॉप स्तर

यह पेड़ की सातवीं परत है ।1g:


सातवीं परत का स्तर पेड़1.stg

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

खेल में स्तर के रूप में, cutscenes, चरित्र चित्र और एक सूची नियंत्रण स्क्रीन भी संग्रहीत हैं। ऐसा लगता है कि यह तकनीक डॉस गेम्स के लिए मानक है, शायद इसलिए यह आवश्यक कोड की मात्रा को कम करता है।


इन्वेंट्री प्रबंधन का "स्तर"

स्प्राइट

स्प्राइट प्रारूप विशेष रूप से दिलचस्प नहीं है। प्रत्येक स्प्राइट एक बिटमैप प्रति पिक्सेल एक बाइट के साथ होता है, लेकिन प्रति स्प्राइट केवल 16 रंगों के साथ। रंगों की सीमित संख्या का उपयोग करना 256-रंग वीजीए के युग में एक सामान्य तकनीक थी, क्योंकि स्प्राइट के लिए पैलेट शिफ्ट प्रदर्शन करना आसान था या अन्य पैलेट के साथ स्तरों में उनका उपयोग करना; इसके अलावा, इसने स्प्राइट्स के लिए आवंटित स्थान को बचा लिया।

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


खिलाड़ी चरित्र स्प्राइट

और क्या बचा है?

यह कुछ और चीजों के लिए इंजीनियर को उलट कर रख देता है। अधिकतर मुझे डेटा फ़ाइल स्वरूपों में दिलचस्पी है, लेकिन कुछ ऐसे पहलू हैं जिन्हें मैं नहीं समझता:

• वस्तुओं के स्थान (कुंजियाँ, फल आदि) कहाँ हैं। ऐसा लगता है कि उन्हें स्तरीय टुकड़ों में नहीं लिखा गया है। शायद वे खेल की द्विआधारी फ़ाइल में संग्रहीत होते हैं, क्योंकि खिलाड़ी एक स्तर पर एक वस्तु उठा सकता है और इसे दूसरे पर फेंक सकता है।
• कैसे टकराव काम करते हैं। एक खिलाड़ी कुछ टाइलों के सामने या पीछे चल सकता है, और फर्श सपाट या ढलान वाला हो सकता है।
• स्तर कैसे जुड़े हैं। यह जानकारी गेम के बाइनरी में संग्रहीत की जा सकती है।
• स्तरों पर टाइल्स के लिए पैलेट की शिफ्ट पूरी तरह से सही नहीं है। कुछ टाइलें गलत रंग दिखाती हैं।
• प्रत्येक स्प्राइट सेट में तीन टुकड़े होते हैं: हेडर, टेबल और डेटा। एक तालिका और डेटा के साथ टुकड़े मेरे लिए स्पष्ट हैं, लेकिन स्प्राइट्स के बारे में कुछ जानकारी हेडर में शामिल हैं, उदाहरण के लिए, एक्स और वाई द्वारा ऑफसेट। मुझे इसका प्रारूप पूरी तरह से समझ में नहीं आया।