मॉडर ने GBA क्रैश साउंड से गेम ROM बहाल किया

 (arstechnica.com)
1 पॉइंट द्वारा GN⁺ 2024-01-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • TheZZAZZGlitch ने Game Boy Advance क्रैश साउंड रिकॉर्ड करके कार्ट्रिज के अंदर मौजूद गेम डेटा की पहचान की, और अंततः उसी ROM को फिर से बहाल किया जा सकता है, यह दिखाया
  • मुख्य विचार यह है कि क्रैश के बाद निकलने वाले ऑडियो को ROM डेटा के रूप में समझा जाए, लेकिन अलग-अलग सोर्स फ़ॉर्मैट के हिसाब से काफी एडजस्टमेंट चाहिए, इसलिए इसे सामान्य डम्प टूल की तरह इस्तेमाल करना मुश्किल है
  • 4 घंटे से ज़्यादा की रिकॉर्डिंग में लगभग 1 घंटा 50 मिनट के आसपास एक विशिष्ट waveform दिखाई दिया, और उसके बाद गेम के instrument sounds और audio samples क्रम से सुनाई दिए
  • Python script और alignment correction की मदद से 99.76% accuracy तक पहुँचा गया, लेकिन बूटिंग विफल रही; फिर 3 रिकॉर्डिंग को majority-vote algorithm से मिलाने पर यह 99.979% तक सुधर गया
  • 7 रिकॉर्डिंग को मिलाने और खाली हिस्सों को फ़िल्टर करने के बाद 100% match हासिल हुआ, जिससे सिर्फ क्रैश साउंड के आधार पर GBA ROM बहाल करने की प्रायोगिक संभावना की पुष्टि हुई

क्रैश साउंड से ROM डेटा पढ़ने का प्रयोग

  • TheZZAZZGlitch ने दिखाया कि software crash के बाद GBA जो आवाज़ निकालता है, उसमें गेम डेटा शामिल हो सकता है
  • क्रैश हुआ GBA कार्ट्रिज के अंदर मौजूद डेटा के आधार पर आवाज़ निकालता रह सकता है, और विशेष hardware तथा code से इस audio का विश्लेषण करके यह पहचाना जा सकता है कि वह कौन-सा गेम है
  • हालांकि, यह तरीका कार्ट्रिज डेटा को आसानी से dump करने का साधन नहीं है, और तुरंत इस्तेमाल करने लायक समाधान भी नहीं है
    • अलग-अलग source format के मुताबिक काफी tuning की ज़रूरत पड़ती है

लंबी रिकॉर्डिंग में उभरा waveform

  • GBA को क्रैश कराने के बाद 4 घंटे से अधिक रिकॉर्डिंग करने पर लगभग 1 घंटा 50 मिनट के आसपास एक खास waveform दिखाई दिया
  • इसके बाद के हिस्से में गेम में शामिल असली instrument sounds और audio samples क्रम से सुनाई दिए
  • बाकी डेटा 13,100Hz के 8-bit data जैसा सुनाई देता है, और कुछ हिस्से बेहद अजीब लगते हैं

Python script और पहली बहाली की कोशिश

  • TheZZAZZGlitch ने “2 दिन तक bugs ठीक करने के बाद” साफ़ GBA crash dump recording को पढ़ने वाली Python script तैयार की
  • ROM डेटा में 0-byte वाले बड़े हिस्से मौजूद थे, और ये भाग मौन जैसे दिखाई देते हैं, इसलिए audio से इन्हें parse करना कठिन था
  • मूल ROM में उनकी स्थिति के आधार पर sections को फिर से arrange करने वाली अलग script चलाने के बाद, बहाल किया गया ROM 99.76% accuracy तक पहुँचा
  • यह ROM फिर भी बूट नहीं हुआ, और क्योंकि इसमें ज्ञात ROM डेटा का उपयोग करके अज्ञात डेटा को उजागर किया गया था, तकनीकी रूप से इसे “cheating” माना गया
    • पूरी तरह blind तरीके से करने पर भी कुछ धारणाएँ और अनुमान लागू किए जा सकते हैं

कई रिकॉर्डिंग मिलाकर accuracy बढ़ाना

  • अगले चरण में recording quality सुधारने पर ध्यान दिया गया
  • 3 बार रिकॉर्ड किए गए नतीजों को “majority vote” algorithm से मिलाने पर accuracy 99.979% तक पहुँच गई
  • यह output ROM बूट तो हो गया, लेकिन text गड़बड़ा गया और title screen पर crash हो गया
  • इसके बाद 7 रिकॉर्डिंग को जोड़कर और खाली हिस्सों को फ़िल्टर करके 100% match हासिल किया गया

फ़िजिकल हार्डवेयर और अतिरिक्त प्रयोग

  • वीडियो के बाद के हिस्से में यह भी देखा गया कि यह तरीका physical hardware पर कैसे काम करता है
  • दूसरे गेम्स पर भी प्रयोग किए गए, और clone cartridge के अंदर मौजूद ARM code से जुड़ी एक रहस्यमय बात का भी पीछा किया गया
  • बेहतर रिकॉर्डिंग पाने के तरीकों को भी आज़माया गया
    • उनमें से एक था एक चैनल में rough mixdown करने वाला “cursed adapter” इस्तेमाल करना

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-01-23
Hacker News की रायें

  • 0x00 के लंबे क्रम की समस्या clock recovery से जुड़ी है
    कुछ digital data streams, खासकर disk drive magnetic head का raw data या Ethernet जैसी high-speed serial communication, अलग clock signal के बिना भेजी जाती हैं
    receiver एक मोटे frequency reference के आधार पर clock बनाता है, और phase-locked loop (PLL) से data stream के transitions के साथ clock phase को मिलाता है
    इस तरीके के काम करने के लिए data transitions इतने बार-बार आने चाहिए कि PLL oscillator के drift को ठीक किया जा सके, और बिना transition के कितनी देर तक टिक सकता है, इसे maximum consecutive identical digits (CID) specification कहा जाता है
    https://en.wikipedia.org/wiki/Clock_recovery

    • पहले 8b/10b जैसे छोटे bit intervals को सावधानी से संभालने वाले चतुर codebook approach से clock recovery की संभावना सुनिश्चित की जाती थी और line capacitance की समस्या से बचा जाता था, यह अच्छी बात थी
      बाद में 64/66b जैसे बड़े bit blocks में छोटा header जोड़कर clock transitions सुनिश्चित करने और पूरे data को pseudorandom scrambler से गुजारने वाले तरीके पर शिफ्ट हुआ
    • दूसरी चिंता यह है कि waveform में कहीं AC coupling हो, जिससे DC pass न हो सके
      clock पूरी तरह synchronized हो तब भी, लंबे intervals में लगभग पूरी तरह 1 वाला signal और लगभग पूरी तरह 0 वाला signal आखिरकार एक जैसे हो जाते हैं
    • इस मामले में यह ज्यादा relevant नहीं लगता
      audio analog है, और bitstream के रूप में decode करने के लिए DAC चाहिए; यह किसी खास synchronization के बिना 44.1kHz या 48kHz जैसी fixed frequency पर transmit होता है
    • इस page पर Wireless Set Number 10 नाम का एक बहुत दिलचस्प लेख मिला
      https://en.wikipedia.org/wiki/Wireless_Set_Number_10

  • लगभग 20 साल पहले 4th-generation iPod firmware को piezo speaker से dump करने वाला original iPodLinux hack याद आ गया
    https://web.archive.org/web/20140810083116/http://www.newscientist.com/article/dn7085
    संयोग से उसी की वजह से iPod पर GBA games भी चला सकते थे, लेकिन click wheel से Doom खेलना और black-and-white video देखना ही काफी satisfying था

    • अच्छी यादें हैं
      मेरे पास अभी भी iPod Classic है, और battery upgrade करने के बाद उसमें 256GB MicroSD card की 4 cards लगाए हैं
      हाल ही में Bluetooth जोड़ने वाला mod भी देखा, लेकिन उसके लिए back case बदलना पड़ता है, इसलिए शायद मैं वहाँ तक नहीं जाऊँगा
      इसके design में भी, और अपनी music files की copies खुद own करने की बात में भी समय के साथ फीका न पड़ने वाला एहसास है

  • इसे यहाँ और attention मिलते देखकर अच्छा लगा
    कुछ दिन पहले भी post हुआ था, लेकिन दब गया: https://news.ycombinator.com/item?id=39037104
    original video में इस छोटे write-up में न होने वाली बहुत सारी बातें हैं, और इसमें DS से ठीक audio quality पाने के लिए hacker का खुद काट-छांट कर बनाया गया custom adapter भी शामिल है

  • Zzazz हर साल April Fools' Day contest/event आयोजित करता है, और आम तौर पर उसमें कुछ न कुछ retro hacking या reverse engineering शामिल होती है
    हिस्सा लेने की सलाह दूँगा
    पिछले contests GitHub पर हैं

  • Nintendo का audio architecture हमेशा दिलचस्प रहा है
    मूल NES में arbitrary waveforms बनाने वाला sample generator था और उसे दो तरीकों से drive किया जा सकता था
    एक तरीका यह था कि memory address देने पर वह bits पढ़ता और उन्हें बहुत simple waveform की तरह process करता; 1 का मतलब “value को एक बढ़ाओ”, 0 का मतलब “value को एक घटाओ”, इसलिए flat waveform बनाने के लिए 10101010 जैसा repeat करना पड़ता था
    दूसरा तरीका था CPU से “initial value” लगातार सीधे डालकर chip को direct drive करना, जो असल में audio driver द्वारा RAM से bits पढ़ने से तेज था
    समस्या यह थी कि यह तरीका सारे CPU cycles खा जाता था, इसलिए इसे तभी इस्तेमाल किया जा सकता था जब कोई और काम न हो
    Battletoads जैसे games ने इसका फायदा उठाकर action रुकने के दौरान higher-quality drum hits बजाए, और इसे title screen, दुश्मन को आखिरी hit देने पर पल भर के लिए सारी action रुकने वाले “crunchy” effect, और यादगार pause music में इस्तेमाल किया
    यहाँ एक demo है जिसमें game direct drive mode और chip द्वारा samples पढ़ने वाले mode के बीच switch करता है। Retro Game Audio ने emulator से modified video upload किया है, जिसमें direct drive subroutine में प्रवेश करने का क्षण दिखता है: https://www.youtube.com/watch?v=JGT0FM3yh-w

  • सबसे पहले तो यही जिज्ञासा है कि ऐसा होता ही क्यों है
    क्या ऐसे games का अपनी state को audio के रूप में dump करना आम बात है? क्या यह game developers के लिए जानबूझकर बनाया गया debugging tool है?

    • लेखक का पिछला video[1] इस behavior की technical details समझाता है
      मूल रूप से GBA sound, RAM के buffer से audio stream करता है, और interrupt को hardware को बताना होता है कि buffer की शुरुआत से दोबारा पढ़े
      लेकिन अगर interrupt नहीं आता, जैसे game crash होने पर, तो audio stream buffer से आगे निकलकर memory के दूसरे हिस्से पढ़ने लगता है
      [1] https://www.youtube.com/watch?v=wSWNkpqjtQY&t=361s
    • यह काफी दुर्लभ है, और जानबूझकर बनाया गया debugging tool भी नहीं है
      सिद्धांत रूप में GBA, game crash होने पर architecture को “halt” कर सकता था, या नियमित रूप से चलने वाली state update को non-maskable interrupt से जोड़कर ऐसी watchdog व्यवस्था रख सकता था कि update रुकने पर reboot हो जाए
      लेकिन ऐसी सुविधा महंगी पड़ती, इसलिए GBA में यह नहीं है
      Nintendo ने पुराने game cartridge निर्माताओं वाला पारंपरिक तरीका अपनाया: “अगर हमारे game में bugs नहीं हैं, तो undefined hardware state में behavior की चिंता करने की जरूरत भी नहीं”
      इसलिए जब कोई GBA game ऐसी crash state में फंसता है, जैसे interrupts disabled वाला infinite loop, तो audio chip को पता ही नहीं चलता कि system crash हो गया है और वह RAM के लगातार bits पढ़कर उन्हें sound में बदलने का अपना साधारण काम जारी रखता है
      सामान्य operation में read operations को manage करने वाला cleanup routine गायब हो जाता है, इसलिए पढ़ना जारी रहता है और आखिरकार cartridge ROM के values दर्शाने वाले bits तक पहुंच जाता है

  • सच में अविश्वसनीय रूप से impressive है
    यहां इस्तेमाल हुई majority-vote algorithm जैसी techniques शायद कई industries में पर्याप्त रूप से इस्तेमाल नहीं हो रही हैं

    • अगर रुचि हो, तो sophisticated noisy signal recovery techniques अब लगभग 100 साल से जमा होती आ रही हैं
      magnetic storage media मूल रूप से इसी hack जैसे सिद्धांत पर काम करता है
      https://en.wikipedia.org/wiki/Partial-response_maximum-likelihood
      यही विचार यहां भी लागू किया जा सकता है, क्योंकि GBA ROM content में मजबूत bias होगा
      majority vote बहुत सारी जानकारी बर्बाद कर देता है
    • जो value सबसे ज्यादा बार आई हो उसे चुनने, या ज्यादा सामान्य रूप से median चुनने का एक दिलचस्प use-case यह है कि एक ही समय पर ली गई कई photos से noise या लोगों को हटाया जा सकता है
      सारी photos को overlap कर दें और हर pixel के लिए सिर्फ median value छोड़ दें[1]
      [1]: https://patdavid.net/2013/05/noise-removal-in-photos-with-median_6/
    • data recovery में यह काफी common है
      disk image को बार-बार पढ़ते रहना, quorum decision चलाना, और जब checksum pass करने वाला result मिले तो देखना कि वह सही से काम करता है या नहीं
      file signature जैसे higher-level checksum हों तो extra verification के लिए और बेहतर है
      कुछ aerospace applications में भी इस्तेमाल होता है
    • मैंने सोचा था कि यह film scans में, खासकर 4K77 जैसे fan projects में, इस्तेमाल हो सकता है
      चूंकि वे pristine master नहीं बल्कि damaged हो सकने वाले theatrical prints से काम करते हैं, अगर कई copies का इस्तेमाल करके scratches आदि हटाए जा सकें, तो बाद की manual correction में लगने वाला समय बहुत कम हो सकता है

  • 0xFF का 0x00 में बदलना DC blocking capacitor या high-pass filtering की वजह से हो सकता है
    audio circuits inaudible content के लिए खास उपयुक्त नहीं होते
    अगर किस्मत अच्छी हो, तो chip के audio output से digital oscilloscope सीधे जोड़ने पर capture accuracy बेहतर हो सकती है, फिर भी bootable image निकाल लेना काफी impressive है

    • YouTube video comments में पढ़ा था कि मकसद जितना हो सके basic equipment से करना था
      इसलिए proper data-logging oscilloscope के बजाय कई बार repeat capture करके errors को average करने में कई घंटे लगाए गए
    • सही है, बिना DC bias वाला signal बनाना होगा
      Manchester encoding जैसा simple तरीका भी काफी मदद करेगा
      अगर उससे पर्याप्त न हो, तो NRZ या यहां तक कि convolutional encoding भी संभव है
      साथ ही sine wave भेजनी चाहिए, या अगर ऐसा न हो सके तो कम से कम square wave frequency इतनी ऊंची रखनी चाहिए कि AC coupling capacitor उसे निगल न जाए

  • इस पूरी चीज में मेरे लिए सबसे impressive हिस्सा यह है कि pirates ने ROM+volatile storage memory के बजाय writable flash से game चलाने के लिए code में जो बदलाव किए

    • pirated Game Boy और Game Boy Advance games में battery की लागत के कुछ cents बचाने के लिए यह बहुत common technique है
      असल में ऐसे patches बनाना इतना मुश्किल भी नहीं है
      pirates game code जहां save करता है उसे थोड़ा reverse-engineer करके, हर game के लिए patch लिखते हैं ताकि save content writable flash में flush हो जाए
      हालांकि official GBA games save करने के लिए हमेशा Nintendo SDK के functions इस्तेमाल करते हैं, इसलिए उन functions को hook करने पर battery-less clone cartridges पर किसी भी GBA game को save करवा पाने वाला generic patch काफी simple हो जाता है
      मैंने यह करने वाला patcher लिखा था, जो यहां देखा जा सकता है
      https://github.com/metroid-maniac/gba-auto-batteryless-patcher

  • क्या किसी को पता है कि TheZZAZZGlitch का emulator जब report करता है कि game गलत address पर jump करने की कोशिश कर रहा है, तो अंदर क्या हो रहा होता है?
    मैं GameBoy Advance में इस्तेमाल हुए ARM7 processor से परिचित नहीं हूं, लेकिन समझ नहीं पा रहा कि गलत value पर jump call कैसे बन सकती है
    और यह भी उत्सुकता है कि TheZZAZZGlitch के गलत तरीके से restore किए गए ROM में से किसी एक को असली GameBoy पर चलाने से क्या होगा

    • bx instruction का इस्तेमाल करके register में stored arbitrary address पर jump किया जा सकता है
      और गलत restore किए गए ROM को असली GameBoy पर चलाने से crash होगा, और आखिरकार वह ROM को speaker पर बजाना शुरू कर देगा
      video का मूल point यही है :)
    • संभव है कि emulator GBA memory map के केवल valid areas की access को emulate करता हो, और invalid area access होने पर वही error throw करता हो
      असली hardware पर क्या होगा… कौन जाने :)