GameCube के लिए खेल में NES एमुलेटर की रिवर्स इंजीनियरिंग

पशु क्रॉसिंग में छोड़े गए डेवलपर के मेनू को सक्रिय करने के तरीकों की खोज करते हुए, एनईएस एमुलेटर के लिए खेल चयन मेनू सहित, मुझे एक दिलचस्प विशेषता मिली जो मूल खेल में मौजूद है और लगातार सक्रिय थी, लेकिन निन्टेंडो द्वारा कभी भी इसका उपयोग नहीं किया गया था।

इन-गेम NES / Famicom गेम के अलावा, आप मेमोरी कार्ड से नए NES गेम डाउनलोड कर सकते हैं।

मैंने अपने कोड और डेटा को गेम में पैच करने के लिए इस ROM बूटलोडर का उपयोग करने का एक तरीका खोजने में कामयाब रहा, जो आपको मेमोरी कार्ड के माध्यम से कोड निष्पादित करने की अनुमति देता है।

परिचय - एनईएस कंसोल ऑब्जेक्ट्स

साधारण एनईएस खेल, जो पशु क्रॉसिंग से प्राप्त किए जा सकते हैं, एनईएस कंसोल के रूप में फर्नीचर के अलग-अलग टुकड़े होते हैं, जिस पर कारतूस होता है।

इस ऑब्जेक्ट को अपने घर में स्थित करने और इसके साथ बातचीत करने के बाद, आप इसे केवल गेम चला सकते हैं। नीचे दी गई छवि Excitebike और Golf को दर्शाती है।


एक सामान्य एनईएस कंसोल ऑब्जेक्ट भी है जिसमें कोई अंतर्निहित गेम नहीं हैं। यह Redd से खरीदा जा सकता है, और कभी-कभी यादृच्छिक घटनाओं के माध्यम से प्राप्त किया जाता है, उदाहरण के लिए, शहर के नोटिस बोर्ड पर पढ़कर कि कंसोल शहर में एक यादृच्छिक बिंदु पर दफन है।


यह ऑब्जेक्ट एक NES कंसोल की तरह दिखता है, जिस पर कोई कारतूस नहीं हैं।


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


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

इन विशेषताओं का प्रदर्शन करने से पहले, मैं उन्हें रिवर्स इंजीनियरिंग की प्रक्रिया समझाऊंगा।

मेमोरी कार्ड पर ROM बूटलोडर खोजें

हम एक डेवलपर मेनू की तलाश कर रहे हैं

प्रारंभ में, मैं एक कोड ढूंढना चाहता था जो विभिन्न डेवलपर मेनू को सक्रिय करता है, जैसे कि मानचित्र चयन मेनू या एनआईए एमुलेटर के लिए गेम चयन मेनू। फ़ॉरेस्ट मैप सेलेक्ट मेनू, जिसकी बदौलत आप आसानी से गेम के विभिन्न स्थानों को आसानी से लोड कर सकते हैं, यह पता लगाने के लिए काफी सरल था - मैंने सिर्फ स्क्रीन के शीर्ष पर दिखाई देने वाली फॉरेस्ट मैप सेलेक्ट लाइन की तलाश की थी (इसे इंटरनेट पर विभिन्न वीडियो और स्क्रीनशॉट में देखा जा सकता है )।

"फॉरेस्ट मैप select_print_wait " में, डेटा का क्रॉस-रेफरेंस select_print_wait फ़ंक्शन के लिए होता है, जो अन्य कार्यों का एक समूह होता है, जिसमें select_init फ़ंक्शन सहित select_* उपसर्ग भी select_init है। वे ऐसे कार्य करते हैं जो मानचित्र चयन मेनू को नियंत्रित करते हैं।

select_init फ़ंक्शन एक अन्य दिलचस्प फ़ंक्शन की ओर जाता है जिसे game_get_next_game_dlftbl कहा जाता है। यह फ़ंक्शन सभी अन्य मेनू और "दृश्यों" को एक साथ जोड़ता है जो आप चला सकते हैं: निनटेंडो लोगो के साथ एक स्क्रीन, मुख्य स्क्रीन, कार्ड चयन मेनू, एनईएस एमुलेटर मेनू (फेमीकोम), और इसी तरह। यह मुख्य गेम प्रक्रिया की शुरुआत में शुरू होता है, यह पता चलता है कि इसे किस दृश्य आरंभीकरण फ़ंक्शन को चलाना चाहिए, और टेबल डेटा संरचना में इसके प्रवेश का पता लगाता है जिसे game_dlftbls कहा जाता है। इस तालिका में विभिन्न दृश्यों के प्रसंस्करण कार्यों के लिंक हैं, साथ ही साथ कुछ अन्य डेटा भी हैं।


फ़ंक्शन के पहले ब्लॉक का सावधानीपूर्वक अध्ययन से पता चला है कि यह फ़ंक्शन को "अगले गेम इनिट" को लोड करता है, और फिर इसकी तुलना अच्छी तरह से ज्ञात इनिट फ़ंक्शन की एक श्रृंखला के साथ करना शुरू करता है:

• first_game_init
• select_init
• play_init
• second_game_init
• trademark_init
• player_select_init
• save_menu_init
• famicom_emu_init
• prenmi_init

फंक्शन पॉइंटर्स में से एक जिसे वह ढूंढ रहा है वह है famicom_emu_init , जो NES / Famicom famicom_emu_init को चलाने के लिए जिम्मेदार है। game_get_next_game_init परिणाम के लिए game_get_next_game_init famicom_emu_init या select_init डिबगर में select_init , मैं विशेष मेनू प्रदर्शित करने में सक्षम था। अगला कदम यह निर्धारित करना है कि कार्यक्रम के निष्पादन के दौरान ये संकेत सामान्य तरीके से कैसे सेट किए जाते हैं। केवल एक ही चीज़ game_get_next_game_init फ़ंक्शन game_get_next_game_init है 0xC पहले तर्क के 0xC में ऑफ़सेट पर लोड game_get_next_game_init है।

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

• जब खेल सामान्य तरीके से शुरू होता है, तो यह क्रियाओं का निम्नलिखित क्रम करता है:
  
  • first_game_init
  • second_game_init
  • trademark_init
  • play_init
• player_select_init अगली init को player_select_init सेट करता है। इस स्क्रीन से आपको कार्ड चुनने के तुरंत बाद एक खिलाड़ी का चयन करने की अनुमति मिल सकती है, लेकिन ऐसा लगता है कि यह सही तरीके से काम नहीं करता है।

मुझे एक नाममात्र फ़ंक्शन भी मिला, जो एमुलेटर के इनिट फ़ंक्शन को परिभाषित करता है, लेकिन मुझे ऐसा कुछ भी नहीं मिला जो खिलाड़ी या मैप विकल्प के इनिट फ़ंक्शन को इनिट फ़ंक्शन सेट करता हो।

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

Game_play_fbdemo_wipe_proc स्क्रीन Game_play_fbdemo_wipe_proc और ब्लैकआउट जैसे दृश्यों के बीच संक्रमण को संभालता है।

कुछ शर्तों के तहत, स्क्रीन संक्रमण सामान्य गेमप्ले से एमुलेटर के प्रदर्शन के लिए किया गया था। यह वह था जिसने एमुलेटर इनिट फ़ंक्शन सेट किया था।

सांत्वना वस्तुओं को संभालना

दरअसल, एनईएस कंसोल के लिए फर्नीचर ऑब्जेक्ट्स के हैंडलर एमुलेटर पर स्क्रीन ट्रांस्फ़ॉर्म हैंडलर स्विच करते हैं। जब कोई खिलाड़ी किसी एक कंसोल से इंटरैक्ट करता है, aMR_FamicomEmuCommonMove ।

फ़ंक्शन को कॉल करते समय, r6 में NES गेम फ़ाइलों के नाम में संख्‍याओं के अनुरूप अनुक्रमणिका मान होता है जो famicom.arc :

• 01_nes_cluclu3.bin.szs
• 02_usa_balloon.nes.szs
• 03_nes_donkey1_3.bin.szs
• 04_usa_jr_math.nes.szs
• 05_pinball_1.nes.szs
• 06_nes_tennis3.bin.szs
• 07_usa_golf.nes.szs
• 08_punch_wh.nes.szs
• 09_usa_baseball_1.nes.szs
• 10_cluclu_1.qd.szs
• 11_usa_donkey3.nes.szs
• 12_donkeyjr_1.nes.szs
• 13_soccer.nes.szs
• 14_exbike.nes.szs
• 15_usa_wario.nes.szs
• 16_usa_icecl.nes.szs
• 17_nes_mario1_2.bin.szs
• 18_smario_0.nes.szs
• 19_usa_zelda1_1.nes.szs

( .arc एक मालिकाना फ़ाइल संग्रह प्रारूप है।)

जब r6 शून्य के बराबर नहीं होता है, तो इसे aMR_RequestStartEmu कॉल में पास किया aMR_RequestStartEmu । इस स्थिति में, एमुलेटर पर संक्रमण शुरू हो जाता है।


हालाँकि, यदि r6 शून्य है, तो aMR_RequestStartEmu_MemoryC फ़ंक्शन को aMR_RequestStartEmu_MemoryC कहा aMR_RequestStartEmu_MemoryC । डिबगर में मान को 0 पर सेट करने पर, मुझे संदेश मिला "मेरे पास कोई सॉफ़्टवेयर नहीं है।" मुझे तुरंत याद नहीं आया कि मुझे यह सुनिश्चित करने के लिए NES कंसोल ऑब्जेक्ट की जांच करने की आवश्यकता है कि यह r6 मान को रीसेट करता है, लेकिन यह पता चला है कि शून्य इंडेक्स का उपयोग बिना कारतूस के कंसोल ऑब्जेक्ट के लिए किया जाता है।

हालांकि aMR_RequestStartEmu किसी तरह की डेटा संरचना में इंडेक्स वैल्यू को स्टोर करता है, aMR_RequestStartEmu_MemoryC अधिक जटिल ऑपरेशन करता है ...


कोड का यह तीसरा ब्लॉक aMR_GetCardFamicomCount कहता है और एक गैर-शून्य परिणाम के लिए जांच करता है, अन्यथा यह फ़ंक्शन ग्राफ के बाईं ओर अधिकांश दिलचस्प चीजों को छोड़ देता है।

aMR_GetCardFamicomCount कॉल famicom_get_disksystem_titles , जो तब memcard_game_list कॉल memcard_game_list , और यहां सब कुछ बहुत दिलचस्प हो जाता है।

memcard_game_list मेमोरी कार्ड को memcard_game_list और फ़ाइल वैल्यू साइकिल में घूमना शुरू करता है, कुछ मूल्यों में जाँच करता है। डिबगर में फ़ंक्शन को ट्रैक करके, मैं यह समझने में सक्षम था कि यह मेमोरी कार्ड पर मेरी प्रत्येक फ़ाइल के साथ मूल्यों की तुलना कर रहा था।


फ़ंक्शन यह तय करता है कि फ़ाइल को डाउनलोड करना है या नहीं, कई लाइनों की जाँच के परिणामों के आधार पर। सबसे पहले, यह "जीएएफई" और "01" लाइनों की उपस्थिति की जांच करता है, जो गेम और कंपनी के पहचानकर्ता हैं। निन्टेंडो के लिए 01 स्टैंड, जीएएफई का मतलब एनिमल क्रॉसिंग है। मुझे लगता है कि यह GameCube पशु वन अंग्रेजी के लिए खड़ा है।

वह फिर "DobutsunomoriP_F_" और "SAVE" लाइनों की जाँच करती है। इस मामले में, पहली पंक्ति का मिलान होना चाहिए, लेकिन दूसरा नहीं। यह पता चला कि "डोबटसूनोमोरीपी_एफ_एसएवी" उस फ़ाइल का नाम है जो एनईएस के लिए एम्बेडेड गेम का डेटा संग्रहीत करता है। इसलिए, इसके अलावा सभी फाइलें उपसर्ग "DobutsunomoriP_F_" के साथ लोड की जाएंगी।

डॉल्फिन डिबगर का उपयोग करके "तुलना" के साथ स्ट्रिंग तुलना को छोड़ना और गेम ट्रिक को विश्वास करना कि मेरी "सेव" फ़ाइल को सुरक्षित रूप से डाउनलोड किया जा सकता है, मुझे यह मेनू एनईएस कंसोल का उपयोग करने के बाद मिला:


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


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

पहली चीज जो मैंने करने की कोशिश की, वह यह खोजने की कोशिश की गई कि मेमोरी कार्ड फ़ाइल से गेम का नाम कहां पढ़ा जाता है। संदेश में मौजूद "FEFSC" लाइन की खोज करना "क्या आप <name> खेलना चाहेंगे?", मुझे वह ऑफसेट मिला जिस पर वह फ़ाइल से पढ़ा गया था: 0x642 । मैंने सहेजें फ़ाइल की प्रतिलिपि बनाई, फ़ाइल का नाम "DobutsunomoriP_F_TEST" में बदल दिया, बाइट्स को ऑफसेट 0x642 पर "परीक्षण" में बदल दिया और परिवर्तित सहेजे गए को आयात किया, जिसके बाद मुझे जो नाम चाहिए वह मेनू में दिखाई दिया।

इस प्रारूप में कुछ और फाइलें जोड़ने के बाद, मेनू में कुछ और विकल्प दिखाई दिए:

ROM डाउनलोड करें

यदि aMR_GetCardFamicomCount लौटाया aMR_GetCardFamicomCount , तो मेमोरी को ढेर पर आवंटित किया जाता है, famicom_get_disksystem_titles को सीधे famicom_get_disksystem_titles कॉल किया जाता है, जिसके बाद डेटा संरचना में यादृच्छिक famicom_get_disksystem_titles का एक गुच्छा निर्दिष्ट किया जाता है। जहां इन मूल्यों को पढ़ा जाएगा, वहां व्याख्या करने के बजाय, मैंने famicom कार्यों की सूची का अध्ययन करना शुरू किया।

यह पता चला कि मुझे famicom_rom_load आवश्यकता है। यह या तो मेमोरी कार्ड से, या खेल के आंतरिक संसाधनों से रोम के लोडिंग को नियंत्रित करता है।


इस "मेमोरी कार्ड से बूट" ब्लॉक में सबसे महत्वपूर्ण बात यह है कि यह कॉल करता है
memcard_game_load । वह मेमोरी कार्ड पर फ़ाइल को फिर से माउंट करता है, इसे पढ़ता है और पार्स करता है। यह वह जगह है जहाँ सबसे महत्वपूर्ण फ़ाइल स्वरूप विकल्प स्पष्ट हो जाते हैं।

चेकसम मान

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

यदि सत्यापन विफल हो जाता है, तो आपको मेमोरी कार्ड को सही ढंग से पढ़ने की असंभवता के बारे में एक संदेश प्राप्त होता है, और कुछ भी नहीं होता है। डिबगिंग के दौरान, मुझे सिर्फ इतना करना है कि इस चेक को छोड़ दें।

ROM को कॉपी करें

memcard_game_load के अंत के memcard_game_load , एक और दिलचस्प बात होती है। इसके और चेकसम के बीच कोड के कई और दिलचस्प ब्लॉक हैं, लेकिन उनमें से कोई भी ब्रांचिंग के लिए नेतृत्व नहीं करता है जो इस व्यवहार के निष्पादन को रोक देता है।


यदि मेमोरी कार्ड से पढ़ा गया एक निश्चित 16-बिट पूर्णांक मान शून्य के बराबर नहीं है, तो एक फ़ंक्शन कहा जाता है जो बफर में संपीड़न हेडर की जांच करता है। यह Yay0 या Yaz0 बफर की शुरुआत को देखकर मालिकाना निंटेंडो कंप्रेशन फॉर्मेट की जाँच करता है। यदि इनमें से एक रेखा पाई जाती है, तो अनपैक फ़ंक्शन को कहा जाता है। अन्यथा, एक साधारण कॉपी कॉपी फ़ंक्शन किया जाता है। किसी भी स्थिति में, उसके बाद, nesinfo_data_size नामक एक चर nesinfo_data_size जाता nesinfo_data_size ।

यहां एक और संकेत दिया गया है कि एम्बेडेड NES गेम्स के लिए ROM फाइलें Yaz0 कम्प्रेशन का उपयोग करती हैं, और यह लाइन उनकी फाइलों के हेडर में मौजूद होती है।

शून्य के लिए चेक किया गया मान देखने के बाद, और बफ़र कंप्रेशन चेक फ़ंक्शंस में गया, मुझे जल्दी से पता चला कि मेमोरी कार्ड में फ़ाइल में गेम कहां से पढ़ा जा रहा है। फ़ाइल में ऑफसेट 0x640 से कॉपी किए गए 32-बाइट बफर के भाग के लिए शून्य चेकिंग की जाती है, जो कि ROM हैडर की सबसे अधिक संभावना है। यह फ़ंक्शन फ़ाइल के अन्य हिस्सों की भी जांच करता है, और यह उनमें है कि गेम का नाम स्थित है (हेडर के तीसरे बाइट के साथ शुरू)।

कोड निष्पादन पथ में मैंने पाया, ROM बफर इस 32-बाइट हेडर बफर के तुरंत बाद स्थित है।


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

टेस्ट रन के लिए, मैंने पिनबॉल गेम रोम का उपयोग किया, जो पहले से ही गेम में है, और 32-बाइट हेडर के बाद इसकी सामग्री सम्मिलित की गई है। चेकसम मान की गणना करने के बजाय, मैंने ब्रेकप्वाइंट सेट किया ताकि मैं बस calcSum छोड़ calcSum और अन्य जांच के परिणामों का भी निरीक्षण कर calcSum जिससे एक शाखा हो सकती है जो ROM बूट प्रक्रिया को छोड़ देती है।

अंत में, मैंने डॉल्फिन मेमोरी कार्ड मैनेजर के माध्यम से नई फ़ाइल आयात की, खेल को फिर से शुरू किया, और कंसोल को लॉन्च करने का प्रयास किया।



यह काम किया! डॉल्फिन मापदंडों से संबंधित कुछ छोटे ग्राफिक कीड़े थे, जो एनईएस एमुलेटर द्वारा उपयोग किए जाने वाले ग्राफिक्स मोड को प्रभावित करते थे, लेकिन सामान्य तौर पर खेल ने ठीक प्रदर्शन किया। (डॉल्फिन के नए बिल्ड में, इसे डिफ़ॉल्ट रूप से काम करना चाहिए।)

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


डिबगर्स के हस्तक्षेप के बिना लोड की जा सकने वाली नई ROM फ़ाइलों को कैसे बनाया जाए, यह जानने के लिए, मुझे कोड लिखना और बेहतर फ़ाइल स्वरूप पार्स करना शुरू करना पड़ा।

बाहरी ROM फ़ाइल स्वरूप

पार्सिंग फ़ाइलों का सबसे महत्वपूर्ण हिस्सा memcard_game_load पर होता है। इस फ़ंक्शन में कोड पार्सिंग ब्लॉक के छह मुख्य खंड हैं:

• जांच योग
• फ़ाइल नाम सहेजें
• ROM फ़ाइल हैडर
• अज्ञात बफर को बिना किसी प्रोसेसिंग के कॉपी किया गया
• पाठ टिप्पणी, आइकन और बैनर लोडर (एक नई सेव फ़ाइल बनाने के लिए)
• रोम बूटलोडर

जांच योग

सेव फ़ाइल में सभी बाइट मानों के योग के निचले आठ बिट्स शून्य होने चाहिए। यहाँ साधारण पायथन कोड है जो आवश्यक चेकसम बाइट उत्पन्न करता है:

 checksum = 0 for byte_val in new_data_tmp: checksum += byte_val checksum = checksum % (2**32) # keep it 32 bit checkbyte = 256 - (checksum % 256) new_data_tmp[-1] = checkbyte 

चेकसम बाइट को स्टोर करने के लिए संभवतः एक विशेष स्थान है, लेकिन सेव फ़ाइल के बहुत अंत में इसे खाली जगह में जोड़ना काफी अच्छी तरह से काम करता है।

फ़ाइल का नाम

फिर से, फ़ाइल नाम को "DobutsunomoriP_F_" से शुरू करना चाहिए और कुछ के साथ समाप्त होना चाहिए जिसमें "बचाओ" नहीं है। इस फ़ाइल का नाम एक दो बार कॉपी किया जाता है, और एक मामले में "F" अक्षर "S" से बदल दिया जाता है। यह NES गेम ("DobutsunomoriP_S_NAME") के लिए फ़ाइलों को सहेजने का नाम होगा।

ROM हैडर

32-बाइट हेडर की एक सीधी कॉपी मेमोरी में लोड की जाती है। इस शीर्ष लेख के कुछ मानों का उपयोग यह निर्धारित करने के लिए किया जाता है कि बाद के अनुभागों को कैसे संभालना है। मूल रूप से, ये कुछ 16-बिट आकार के मान और पैक्ड पैरामीटर बिट्स हैं।

यदि आप फ़ंक्शन के प्रारंभ में हैडर द्वारा कॉपी किए गए पॉइंटर को ट्रेस करते हैं और उसके तर्क की स्थिति का पता लगाते हैं, तो नीचे दिए गए फ़ंक्शन के हस्ताक्षर से पता चलेगा कि इसमें वास्तव में MemcardGameHeader_t* टाइप है।

 memcard_game_load(unsigned char *, int, unsigned char **, char *, char *, MemcardGameHeader_t *, unsigned char *, unsigned long, unsigned char *, unsigned long) 

अज्ञात बफर

शीर्ष लेख से 16-बिट आकार मान की जाँच करता है। यदि यह शून्य के बराबर नहीं है, तो बाइट्स की संबंधित संख्या सीधे फ़ाइल बफर से आवंटित मेमोरी के एक नए ब्लॉक में कॉपी की जाती है। यह फ़ाइल पॉइंटर में डेटा पॉइंटर को ले जाता है ताकि आगे की कॉपी अगले सेक्शन से जारी रह सके।

बैनर, आइकन और टिप्पणी

हेडर में एक और आकार का मूल्य जांचा जाता है, और यदि यह शून्य के बराबर नहीं है, तो फ़ाइल संपीड़न चेक फ़ंक्शन कहा जाता है। यदि आवश्यक हो, तो SetupExternCommentImage एल्गोरिथ्म लॉन्च किया जाएगा, जिसके बाद SetupExternCommentImage ।

यह फ़ंक्शन तीन चीजें करता है: "कमेंटरी", बैनर छवि और आइकन। उनमें से प्रत्येक के लिए, ROM हेडर में एक कोड है, जिसमें दिखाया गया है कि उन्हें कैसे संभालना है। निम्नलिखित विकल्प हैं:

1. डिफ़ॉल्ट मान का उपयोग करें
2. ROM फ़ाइल में बैनर / आइकन / टिप्पणी अनुभाग से कॉपी करें
3. वैकल्पिक बफर से कॉपी करें

कोड के डिफ़ॉल्ट मान आइकन या बैनर को डिस्क पर संसाधन से लोड किए जाने का कारण बनते हैं, और सहेजें फ़ाइल और टिप्पणी (फ़ाइल का पाठ विवरण) का नाम "पशु क्रॉसिंग" और "एनईएस कैसेट सेव डेटा" मान निर्दिष्ट किए जाते हैं। यहाँ यह कैसा दिखता है:


कोड का दूसरा मूल्य बस ROM फ़ाइल ("पशु क्रॉसिंग" के लिए एक विकल्प) से गेम के नाम की प्रतिलिपि बनाता है, और फिर फ़ाइल टिप्पणी में स्ट्रिंग "] ROM" को खोजने और इसे "SAVE" के साथ बदलने की कोशिश करता है। जाहिर है, जो फाइलें निन्टेंडो जारी करना चाहती थीं, वे "गेम नेम [एनईएस] रोम" या कुछ इसी नाम के प्रारूप में होनी चाहिए थीं।

आइकन और बैनर के लिए, कोड छवि प्रारूप को निर्धारित करने की कोशिश करता है, इस प्रारूप के अनुरूप एक निश्चित आकार मान प्राप्त करें और फिर छवि की प्रतिलिपि बनाएँ।

अंतिम कोड मान पर, फ़ाइल का नाम और विवरण बफर से बदलाव के बिना कॉपी किया जाता है, और आइकन और बैनर भी वैकल्पिक बफर से लोड किए जाते हैं।

रोम

यदि आप ध्यान से memcard_game_load कॉपी रॉम के स्क्रीनशॉट को देखते हैं, तो आप देख सकते हैं कि शून्य के लिए समानता के लिए चेक किया गया 16-बिट मान 4 बिट्स (16 से गुणा) के बाईं ओर स्थानांतरित कर दिया गया है, और फिर इसका उपयोग memcpy फंक्शन के आकार के रूप में किया जाता है यदि संपीड़न का पता नहीं चला है। यह शीर्ष लेख में मौजूद एक और आकार का मान है।

यदि आकार शून्य के बराबर नहीं है, तो ROM डेटा को संपीड़न के लिए जांचा जाता है, और फिर कॉपी किया जाता है।

अज्ञात बफर और बग खोज

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

मुझे फाइलों को बचाने के आधार पर खेल का फायदा उठाने की संभावना में बहुत दिलचस्पी थी, और ऐसा लगता था कि यह सबसे अच्छा विकल्प था।

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

लेकिन मैं अभी भी जानना चाहता था कि इस बफर का क्या होता है, जिसे बिना किसी प्रोसेसिंग के कॉपी किया जाता है।

एनईएस सूचना लेबल हैंडलर

मैं famicom_rom_load लौटा famicom_rom_load । मेमोरी कार्ड या डिस्क से रोम लोड करने के बाद, कई कार्य कहे जाते हैं:

• nesinfo_tag_process1
• nesinfo_tag_process2
• nesinfo_tag_process3

उस स्थान को ट्रैक करने के बाद, जहां अज्ञात बफ़र की प्रतिलिपि बनाई गई है, मैंने सुनिश्चित किया कि यह कार्य इन कार्यों द्वारा किया जाता है। वे nesinfo_next_tag लिए एक कॉल के साथ शुरू करते हैं, जो एक सरल एल्गोरिथ्म करता है:

• यह निर्दिष्ट करता है कि निर्दिष्ट पॉइंटर nesinfo_tags_end में पॉइंटर से nesinfo_tags_end है nesinfo_tags_end । यदि यह nesinfo_tags_end या nesinfo_tags_end शून्य से कम है, तो यह सूचक के शीर्षलेख में स्ट्रिंग "END" की उपस्थिति की जांच करता है।
  
  
  • यदि "END" पहुंच गया है, या सूचक nesinfo_tags_end ऊपर या ऊपर nesinfo_tags_end , तो फ़ंक्शन वापस लौट आता है।
  • अन्यथा, सूचक के ऑफसेट 0x3 पर बाइट को 4 और वर्तमान पॉइंटर में जोड़ा जाता है, जिसके बाद मान लौटाया जाता है।

यह हमें बताता है कि तीन-अक्षर नाम, डेटा आकार मान और स्वयं डेटा से किसी प्रकार का लेबल प्रारूप है। परिणाम अगले लेबल के लिए एक संकेतक है, क्योंकि वर्तमान लेबल छोड़ दिया गया है ( cur_ptr + 4 तीन अक्षर के नाम और एक बाइट को छोड़ देता है, और size_byte डेटा को छोड़ देता है)।

यदि परिणाम शून्य नहीं है, तो लेबल प्रोसेसिंग फ़ंक्शन यह पता लगाने के लिए स्ट्रिंग तुलनाओं की एक श्रृंखला करता है कि किस लेबल को संसाधित करने की आवश्यकता है। nesinfo_tag_process1 में लेबल किए गए कुछ नाम इस nesinfo_tag_process1 : VEQ, VNE, GID, GNO, BBR और QDS।


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

सौभाग्य से, कई विस्तृत डीबगिंग संदेश हैं जो टैग का पता चलने पर प्रदर्शित होते हैं।वे सभी जापानी में हैं, इसलिए उन्हें पहले Shift-JIS से डिकोड किया जाना चाहिए और अनुवादित किया जाना चाहिए। उदाहरण के लिए, QDS के लिए एक संदेश "डिस्क लोड हो रहा है क्षेत्र लोड हो रहा है" या "चूंकि यह पहला रन है, एक डिस्क सहेजें क्षेत्र बनाएँ" पढ़ सकता है। BBR के लिए संदेश "बैटरी का बैकअप लोड करना" या "चूंकि यह पहली शुरुआत है, हम सफाई करते हैं" पढ़ते हैं।

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

डिबग संदेश के साथ एक "एचएससी" टैग भी है जो कहता है कि यह रिकॉर्ड्स को संसाधित कर रहा है। उसे अपने टैग डेटा के साथ-साथ मूल स्कोर रिकॉर्ड मूल्य से ROM में एक ऑफसेट मिलता है। इन निशानों का उपयोग एनईएस गेम की मेमोरी में एक जगह को इंगित करने के लिए किया जा सकता है, जो संभवतः भविष्य में सहेजने और उन्हें पुनर्स्थापित करने के लिए हाईस्कॉर स्टोर करने के लिए है।

ये टैग एक काफी जटिल ROM मेटाडेटा डाउनलोड सिस्टम बनाते हैं। इसके अलावा, उनमें से कई memcpyलेबल डेटा में संचरित मूल्यों के आधार पर कॉल का नेतृत्व करते हैं ।

बग का शिकार

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

हालांकि, ऐसे कई मामले हैं जहां प्रेषित आकार के आकार के मूल्य memcpyअधिक हो सकते हैं 0xFFFF।

QDs

QDS अपने टैग डेटा के साथ-साथ 16-बिट आकार के मूल्य से 24-बिट ऑफसेट लोड करता है।

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

24-बिट मान का एक अधिकतम मूल्य है 0xFFFFFF, जो लोड किए गए ROM डेटा के बाहर लिखने के लिए आवश्यक से बहुत अधिक है। हालांकि, कुछ समस्याएं हैं ...

पहला यह है कि यद्यपि अधिकतम आकार का मूल्य बराबर है 0xFFFF, यह शुरू में मेमोरी विभाजन को रीसेट करने के लिए उपयोग किया जाता है। यदि आकार मान बहुत अधिक है (बहुत बड़ा नहीं है 0x1000), तो यह गेम कोड में "QDS" चिह्न को रीसेट कर देगा।

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

छोटे आकार का मान सेट करके इससे बचा जा सकता है। एक और समस्या यह है कि ऑफ़सेट वैल्यू केवल मेमोरी में आगे बढ़ सकती है, और रोम एनईएस डेटा उपलब्ध मेमोरी के अंत के काफी करीब में स्थित है।

उनके बाद केवल कुछ ढेर हैं, और उनमें से एक में कुछ विशेष रूप से उपयोगी नहीं है, जैसे कि स्पष्ट फ़ंक्शन पॉइंटर्स।

सामान्य मामले में, आप इसका उपयोग ढेर ओवरफ्लो का दोहन करने के लिए कर सकते हैं, लेकिन mallocइस ढेर के लिए उपयोग किए जाने वाले कार्यान्वयन में, ब्लॉकों में स्वास्थ्य जांच के कुछ बाइट्स जोड़े गए हैं malloc। हम बाद के ढेर ब्लॉकों में सूचक मूल्यों पर लिख सकते हैं। स्वास्थ्य जांच के बिना, यह एक मनमाने ढंग से स्मृति क्षेत्र में लिखने के लिए इस्तेमाल किया जा सकता है जब freeएक शामिल ढेर ब्लॉक के लिए कहा जाता है ।

हालाँकि, अगले और पिछले ब्लॉकों की शुरुआत में mallocएक विशिष्ट बाइट पैटर्न ( 0x7373) के लिए यहाँ उपयोग किए जाने वाले चेक की जाँच की जाती है कि इसे कब बुलाया जाएगाfree। अगर उसे ये बाइट्स नहीं मिलते हैं, तो वह कॉल करती है OSPanicऔर गेम फ्रीज कर देती है।


कुछ लक्ष्य स्थान पर इन बाइट्स की उपस्थिति को प्रभावित करने में असमर्थ, यहां लिखना संभव नहीं है। दूसरे शब्दों में, इस जगह के पास कुछ रिकॉर्ड करने में सक्षम होने के बिना किसी अनियंत्रित जगह पर कुछ रिकॉर्ड करना असंभव है। 0x73730000रिटर्न एड्रेस के सामने सीधे स्टैक पर स्टोर किए गए मूल्य को बनाने का कोई तरीका हो सकता है और वह स्थान जो उस मूल्य को संदर्भित करता है, जिसे हम डेस्टिनेशन एड्रेस पर लिखना चाहते हैं (यह भी चेक किया जाएगा जैसे कि यह एक हीप ब्लॉक का पॉइंटर था), लेकिन यह इसे किसी शोषण में प्राप्त करना और उसका उपयोग करना कठिन है।

nesinfo_update_highscore

क्यूडीएस, बीबीआर और एचएससी टैग के संबंध में एक अन्य कार्य यह है nesinfo_update_highscore। क्यूडीएस, बीबीआर, और ओएफएस अंक (ऑफसेट) के आकार का उपयोग ऑफ़सेट की गणना करने के लिए किया जाता है जिस पर रिकॉर्ड करना है, और एचएससी चिह्न में उस स्थान पर रिकॉर्डिंग शामिल है। यह फ़ंक्शन NES एमुलेटर द्वारा संसाधित प्रत्येक फ़्रेम के लिए किया जाता है।

इस मामले में, QDS के लिए भी प्रत्येक लेबल के लिए अधिकतम ऑफ़सेट मूल्य बराबर है 0xFFFF। हालांकि, लेबल प्रोसेसिंग चक्र के दौरान, BBR और QDS लेबल से आयाम मान वास्तव में जमा होते हैं । इसका मतलब है कि कई अंकों का उपयोग लगभग किसी भी ऑफसेट मूल्य की गणना करने के लिए किया जा सकता है। सीमा एक लेबल की संख्या है जो एक मेमोरी कार्ड पर फ़ाइल में ROM लेबल के डेटा अनुभाग में फिट हो सकती है, और इसका अधिकतम आकार भी है 0xFFFF।

जिस आधार पते पर ऑफसेट जोड़ा गया है वह 0x800C3180डेटा बफ़र है। यह पता ROM डेटा से बहुत कम है, जो हमें रिकॉर्डिंग स्थान चुनने में अधिक स्वतंत्रता देता है। उदाहरण के लिए, स्टैक से पते में वापसी पते को फिर से लिखना काफी सरल होगा 0x812F95DC।

दुर्भाग्य से, यह भी काम नहीं किया। यह पता चला है कि यह nesinfo_tag_process1इन लेबल से ऑफसेट के संचित आकार की भी जांच करता है, और इस आकार का उपयोग अंतरिक्ष को आरंभीकृत करने के लिए करता है:

 bzero(nintendo_hi_0, ((offset_sum + 0xB) * 4) + 0x40) 

ऑफसेट मूल्य के साथ जो मैं गणना करने की कोशिश कर रहा था, इससे यह तथ्य 0x48D91ECसामने आया कि (76,386,796) मेमोरी के बाइट्स को मंजूरी दे दी गई , यही वजह है कि खेल शानदार रूप से दुर्घटनाग्रस्त हो गया।

पैट का निशान

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

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

हालांकि, एक लेबल है जो तब भी काम कर सकता है जब गैर-शून्य nesinfo_rom_start: पीएटी। किसी फ़ंक्शन में यह सबसे कठिन लेबल है nesinfo_tag_process2।


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

प्रत्येक PAT मार्क डेटा बफर में 8-बिट प्रकार कोड, 8-बिट पैच आकार और 16-बिट ऑफ़सेट मान होता है, उसके बाद पैच डेटा होता है।

• यदि कोड 2 है, तो ऑफसेट मूल्य को ऑफसेट के वर्तमान योग में जोड़ा जाता है।
• यदि कोड 9 है, तो ऑफसेट को 4 बिट्स द्वारा स्थानांतरित कर दिया जाता है और ऑफसेट के वर्तमान योग में जोड़ा जाता है।
• यदि कोड 3 है, तो ऑफ़सेट का योग 0 पर रीसेट हो जाता है।

एनईएस सूचना लेबल का अधिकतम आकार 255 है, यानी सबसे बड़ा पैट पैच आकार 251 बाइट्स है। हालांकि, कई पीएटी अंकों का उपयोग किया जा सकता है, अर्थात, आप 251 बाइट्स से अधिक पैच कर सकते हैं, साथ ही साथ गैर-आकस्मिक रिक्त स्थान भी।

जब तक हमारे पास कोड 2 या कोड 9 के साथ PAT तलवों की एक श्रृंखला है, तब तक गंतव्य पॉइंटर की ऑफसेट जमा होती रहती है। पैच डेटा कॉपी करते समय, यह शून्य पर रीसेट हो जाता है, लेकिन यदि आप शून्य पैच आकार का उपयोग करते हैं, तो इससे बचा जा सकता है। यह स्पष्ट है कि इसका nesinfo_rom_startउपयोग कई पीएटी अंकों का उपयोग करके एक अशक्त सूचक के साथ कुछ मनमाना ऑफसेट की गणना करने के लिए किया जा सकता है ।

हालाँकि, कोड मान के दो और चेक हैं ...

• यदि कोड 0x80और के बीच है 0xFF, तो इसे जोड़ा जाता है 0x7F80, और फिर 16 बिट्स को स्थानांतरित कर दिया जाता है। फिर इसे 16-बिट ऑफसेट मूल्य में जोड़ा जाता है और पैच के लिए अंतिम पते के रूप में उपयोग किया जाता है।

यह हम से एक श्रेणी में पैच के लिए एक गंतव्य पता निर्दिष्ट कर सकते हैं 0x80000000अप करने के लिए 0x807FFFFF! यह वह जगह है जहाँ पशु क्रॉसिंग कोड का बड़ा हिस्सा मेमोरी में रहता है। इसका मतलब यह है कि हम मेमोरी कार्ड पर एक फ़ाइल से ROM मेटाडेटा लेबल का उपयोग करके पशु क्रॉसिंग कोड को स्वयं पैच कर सकते हैं।

एक छोटे पैच लोडर की मदद से, आप मेमोरी कार्ड से बड़े पैच को आसानी से किसी भी पते पर डाउनलोड कर सकते हैं।

एक त्वरित जांच के रूप में, मैंने अपने पिछले लेख में वर्णित "ज़ुरु मोड 2" (गेम डेवलपर मोड) को शामिल करने वाला एक पैच बनाया) जब कोई उपयोगकर्ता गेम मैप से ROM लोड करता है। यह पता चला कि चाबियों से धोखा देने वाला कॉम्बो केवल "ज़ुरू मोड 1" मोड को सक्रिय करता है, जिसमें फ़ंक्शंस की पहुंच 2 मोड तक नहीं है। इस पैच के साथ, मेमोरी कार्ड के लिए धन्यवाद, हम वास्तविक हार्डवेयर के लिए डेवलपर मोड तक पूरी पहुंच प्राप्त कर सकते हैं।


ROM के बूट होने पर पैच के निशान को संसाधित किया जाएगा।


ROM को लोड करने के बाद, आपको परिणाम देखने के लिए NES एमुलेटर से बाहर निकलना होगा।


यह काम करता है!

पैच जानकारी लेबल प्रारूप

इस पैच को चलाने वाली सहेजें फ़ाइल में सूचना चिह्न इस तरह दिखाई देते हैं:

000000 5a 5a 5a 00 50 41 54 08 a0 04 6f 9c 00 00 00 7d >ZZZ.PAT...o....}<
000010 45 4e 44 00 >END.<

• ZZZ \x00: प्रारंभ चिह्न को अनदेखा कर दिया। 0x00क्या इसके डेटा बफर का आकार: शून्य है।
• PAT \x08 \xA0 \x04 \x6F\x9C \x00\x00\x00\x7D: पैच 0x80206F9Cमें 0x0000007D।
  
  • 0x08 लेबल बफर का आकार है।
  • 0xA0जब जोड़ा 0x7F80जाता है 0x8020, यानी गंतव्य पते के ऊपरी 16 बिट्स।
  • 0x04पैच डेटा का आकार ( 0x0000007D) है।
  • 0x6F9C गंतव्य पते के निचले 16 बिट्स हैं।
  • 0x0000007D पैच डेटा है।
• END \x00 : मार्कर चिह्न समाप्त करें।

यदि आप अपने आप को एक पैचर या रोम सेव फाइल्स के निर्माण के साथ प्रयोग करना चाहते हैं, तो https://github.com/jamchamb/ac-nesrom-save-generator पर मैंने फ़ाइलों को जनरेट करने के लिए एक बहुत ही सरल कोड पोस्ट किया है। ऊपर दिखाए गए जैसे एक पैच को निम्न कमांड के साथ उत्पन्न किया जा सकता है:

$ ./patcher.py Patcher /dev/null zuru_mode_2.gci -p 80206F9c 0000007D

मनमाना कोड निष्पादन

इस टैग के लिए धन्यवाद, आप एनिमल क्रॉसिंग में मनमाना कोड निष्पादन प्राप्त कर सकते हैं।

लेकिन यहां आखिरी बाधा आती है: डेटा के लिए पैच का उपयोग करना अच्छी तरह से काम करता है, लेकिन कोड निर्देश को पैच करते समय समस्याएं उत्पन्न होती हैं।

जब पैच रिकॉर्ड किए जाते हैं, तो खेल पुराने निर्देशों का पालन करना जारी रखता है जो इसके स्थान पर थे। यह एक कैशिंग मुद्दे की तरह लगता है, और वास्तव में यह है। GameCube CPU में निर्देश कैश हैं, जैसा कि विनिर्देशों में वर्णित है ।

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

हालाँकि, मूल कोड को चलाने की क्षमता के बिना, हम अभी भी कॉल नहीं कर सकते हैं ICInvalidateRange। सफल कोड निष्पादन के लिए, हमें एक और चाल की आवश्यकता है। हीप ओवरफ्लो के साथ एक शोषण का उपयोग करने की संभावना के लिए

कार्यान्वयन का अध्ययन malloc, मैंने सीखा कि कार्यान्वयन कार्यों mallocको गतिशील रूप से डेटा संरचना का उपयोग करके अक्षम किया जा सकता है my_malloc। my_mallocवर्तमान कार्यान्वयन के लिए mallocया freeमेमोरी में स्थिर स्थान से एक पॉइंटर लोड करता है , और फिर इस फ़ंक्शन को कॉल करता है, जो सभी तर्कों को पारित करता है my_malloc।

एनईएस एमुलेटर सक्रिय रूप से उपयोग करता हैmy_mallocरोम से संबंधित एनईएस डेटा के लिए स्मृति और मुफ्त मेमोरी आवंटित करने के लिए, इसलिए मुझे यकीन था कि इसे पीएटी के निशान के रूप में लगभग उसी समय लॉन्च किया जाएगा।

चूंकि यह my_mallocमेमोरी से एक पॉइंटर को लोड करता है और इसे एक संक्रमण बनाता है, इसलिए मैं केवल पॉइंटर को अधिलेखित करके प्रोग्राम निष्पादन प्रक्रिया को बदल सकता हूं ताकि यह वर्तमान फ़ंक्शन को इंगित करे mallocया free। टूल कैशिंग ऐसा होने से नहीं रोकेगा, क्योंकि किसी भी निर्देश को बदलने की आवश्यकता नहीं है my_malloc।

Dsubutsu no Mori e + fan project के डेवलपर, Cuyler, ने PowerPC असेंबलर में ऐसा लोडर लिखा और इस वीडियो में नए कोड को इंजेक्ट करने के लिए इसके उपयोग का प्रदर्शन किया: https://www.youtube.com/watch?v=Bdxn7gP6WIc। (D lastbutsu no Mori e + GameCube पर अंतिम पशु क्रॉसिंग पुनरावृति था, जिसमें सबसे अधिक अपडेट थे। केवल जापान में जारी किया गया था।) पैच कुछ कोड डाउनलोड करता है जो खिलाड़ी को आईडी द्वारा पत्र में प्रवेश करके और जेड बटन दबाकर किसी भी ऑब्जेक्ट को बनाने की अनुमति देता है।


इसके लिए धन्यवाद, आप
एक असली गेम क्यूब पर पशु क्रॉसिंग की नियमित प्रतिलिपि में मॉड, धोखा और होमब्रे को डाउनलोड कर सकते हैं ।