रिवर्स इंजीनियरिंग का परिचय: हैकिंग गेम डेटा प्रारूप

परिचय

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

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

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

थोड़ी पृष्ठभूमि

यह सब तब शुरू हुआ जब मैंने लिनक्स पर चिप के चैलेंज को फिर से बनाने की कोशिश की।

चिप का चैलेंज मूल रूप से 1989 में अब भूल गए अटारी लिंक्स पोर्टेबल कंसोल के लिए जारी किया गया था। उस समय के लिए, अटारी लिंक्स एक प्रभावशाली कार थी, लेकिन यह निन्टेंडो गेम बॉय के रूप में एक ही समय में सामने आई, जिसने अंततः बाजार पर कब्जा कर लिया।

चिप चैलेंज एक पहेली खेल है जिसमें एक शीर्ष दृश्य और एक टाइल नक्शा है। ऐसे अधिकांश खेलों के साथ, प्रत्येक स्तर का लक्ष्य बाहर निकलना है। अधिकांश स्तरों में, आउटपुट को चिप के लिए एक कनेक्टर द्वारा संरक्षित किया जाता है, जिसे केवल एक निश्चित संख्या में कंप्यूटर चिप्स को इकट्ठा करके बाईपास किया जा सकता है।


वीडियो: एक्शन में अटारी लिंक्स , लेवल वन वॉकथ्रू ।

"लेसन 1" नाम के तहत पहले स्तर से एक नया खेल शुरू होता है। एक चिप के लिए चिप्स और एक स्लॉट के अलावा, चाबियाँ और दरवाजे उस पर दिखाई देते हैं। अन्य स्तरों पर, जाल, बम, पानी और जीव जैसी बाधाएं उत्पन्न होती हैं जो (सबसे अधिक बार) पूर्वानुमानित मार्गों के साथ चलती हैं। वस्तुओं और उपकरणों की एक विस्तृत श्रृंखला आपको कई पहेलियाँ और समय सीमाएं बनाने की अनुमति देती है। खेल को पूरा करने के लिए आपको 140 से अधिक स्तरों से गुजरना होगा।

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

और यहीं से मेरी कहानी शुरू होती है। मैंने फैसला किया कि मैं बुनियादी ओपन सोर्स गेम इंजन का एक संस्करण बनाना चाहता हूं ताकि मैं लिनक्स और विंडोज पर चिप के चैलेंज को खेल सकूं और प्रशंसकों द्वारा बनाए गए सभी स्तरों को चलाना आसान बना सकूं।

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


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

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

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

अचानक, मेरी सर्वोच्च प्राथमिकता एमएस-डॉस के लिए रिवर्स इंजीनियरिंग स्तर की फाइलें थीं।

डेटा फ़ाइलें

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

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

आवश्यक शर्तें

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

पहले देखो

यहां MS-DOS के अंतर्गत पोर्ट से डेटा फ़ाइलों वाली निर्देशिका की एक सूची दी गई है:

  $ एलएस स्तर
 all_full.pak cake_wal.pak eeny_min.pak iceberg.pak lesson_5.pak mulligan.pak playtime.pak southpol.pak को पूरी तरह से_पाक
 alphabet.pak महल_m.pak elementa.pak ice_cube.pak lesson_6.pak nice_day.pak potpourr.pak special.pak traffic_.pak
 amsterda.pak catacomb.pak fireflie.pak icedeath.pak lesson_7.pak nightmar.pak problems.pak spirals.pak trinity.pak
 इसके अलावा .pak cellbloc.pak firetrap.pak icehouse.pak lesson_8.pak now_you_.pak refracti.pak spooks.pak Trust_me.pak
 arcticfl.pak chchchip.pak floorgas.pak invincib.pak लॉबस्टर_.पाक नट_और.पाक उल्टा_पाक भाप।
 बॉल्स_ओ_पैक चिलर.पाक मजबूर_ई.पाक i.pak लॉक_blo.pak on_the_r.pak rink.pak स्ट्राइप्स। pak up_the_b.pak
 beware_o.pak chipmine.pak force_fi.pak i_slide.pak loop_aro.pak oorto_ge.pak roadign.pak suicide.pak vanishin.pak
 blink.pak citybloc.pak force_sq.pak जेलर .pak memory.pak open_que.pak sampler.pak telebloc.pak पीड़ित। pak
 blobdanc.pak colony.pak fortune_.pak jump_.pak metastab.pak oversea_.pak scavenge.pak telenet.pak vortex.pak
 blobnet.pak गलियारा.पाक चार_पुल। kablam.pak mind_blo.pak दर्द। pak scoundre.pak t_fair.pak war.pak
 block_fa.pak cypher.pak four_squ.pak knot.pak mishmesh.pak paranoia.pak see_s.pak the_last.pak राइटर_पाक
 block_ii.pak deceptio.pak glut.pak सीढ़ी। pak miss_dir.pak आंशिक_.पाक short_ci.pak the_mars.pak yorkhous.pak
 block_n_.pak deepfree.pak goldkey.pak लेमिंग्स।पक मिक्स_नु.पाक पेंटाग्रा।पैक सिक्रिटिन।पैक the_pris.pak
 block_ou.pak digdirt.pak go_with_.pak lesson_1.pak mix_up.pak perfect_.pak skelzie.pak three_do.pak
 block.pak digger.pak grail.pak lesson_2.pak Monster_.pak pier_sev.pak slide_st.pak time_lap.pak
 bounce_c.pak doublema.pak hidden_d.pak lesson_3.pak morton.pak ping_pon.pak slo_mo.pak torturec.pak
 brushfir.pak draw_an.pak Hunt.pak lesson_4.pak mugger_s.pak playhous.pak socialis.pak tossed_s.pak 

जैसा कि आप देख सकते हैं, सभी फाइलें .pak में समाप्त होती .pak । .pak एप्लिकेशन डेटा फ़ाइल के लिए मानक अनुमति है, और यह, दुर्भाग्य से, हमें इसकी आंतरिक संरचना के बारे में कोई जानकारी नहीं देता है। फ़ाइल नाम स्तर के नाम के पहले आठ वर्ण हैं, कुछ अपवादों के साथ। (उदाहरण के लिए, स्तर फ़ाइलों "ब्लॉक बस्टर" और "ब्लॉक बस्टर II" के नाम में "बस्टर" शब्द छोड़ा गया है ताकि वे मेल न खाएं।)

  $ एलएस स्तर |  WC
      17 148 1974 

निर्देशिका में 148 डेटा फाइलें हैं, और गेम में वास्तव में बिल्कुल 148 स्तर हैं, इसलिए यहां सब कुछ समान है।

अब जांच करते हैं कि ये फाइलें क्या हैं। xxd हेक्साडेसिमल डेटा (हेक्सडंप) को डंप करने के लिए एक मानक उपयोगिता है। आइए देखें कि यह LESSON 1 के अंदर कैसा दिखता है।

  $ xxd स्तर / lesson_1.pak
 00000000: 1100 cb00 0200 0004 0202 0504 0407 0505 ................
 00000010: 0807 0709 0001 0a01 010b 0808 0d0a 0a11 ................
 00000020: 0023 1509 0718 0200 2209 0d26 0911 270b। # ...... ".. और .. '।
 00000030: 0b28 0705 291e 0127 2705 020d 0122 0704. (..) ..''.......
 00000040: 0902 090a 0215 0426 0925 0111 1502 221d ....... &।% .... "।
 00000050: 0124 011d 0d01 0709 0020 001b 0400 1a00। $ ....... ......
 00000060: 2015 2609 1f00 3300 2911 1522 2302 110d। और ... 3.) .. "# ...
 00000070: 0107 2609 1f18 2911 1509 181a 0223 021b .. और ...) ...... # ।।
 00000080: 0215 2201 1c01 1c0d 0a07 0409 0201 0201 .. "............।
 00000090: 2826 0123 1505 0902 0121 1505 220a 2727 ((। # .....! ..! ')।'
 000000a0: 0b05 0400 060b 0828 0418 780b 0828 0418 ....... (.. x ..) ।।
 000000b0: 700b 0828 0418 6400 1710 1e1e 1a19 0103 p .. (.. d .........
 000000c0: 000e 1a17 1710 0e1f 010e 1314 1b29 1f1a ……………… ..
 000000d0: 0012 101f 011b 0c1e 1f01 1f13 1001 0e13 ................
 000000e0: 141b 001e 1a0e 1610 1f2d 0020 1e10 0116 .........।  ....
 000000f0: 1024 291f 1a01 1a1b 1019 000f 1a1a 1d1e। $) .............
 00000100: 2d02 

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

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

हम क्या देखने की उम्मीद करते हैं?

आइए एक कदम पीछे लें और स्थिति को स्पष्ट करें: हम इन डेटा फ़ाइलों में क्या विशिष्ट डेटा प्राप्त करने की उम्मीद करते हैं?

सबसे स्पष्ट स्तर का एक निश्चित "मानचित्र" है: दीवारों और दरवाजों की स्थिति, साथ ही साथ अन्य सभी चीजों का संकेत देने वाला डेटा, जो स्तर को अद्वितीय बनाता है।


(सौभाग्य से हमारे लिए, खेल के प्रशंसकों ने एक श्रमसाध्य काम किया और सभी 148 स्तरों के लिए पूर्ण नक्शे एकत्र किए, इसलिए हम उन्हें यह जानने के लिए उपयोग कर सकते हैं कि प्रत्येक नक्शे पर क्या होना चाहिए।)

मानचित्र के अतिरिक्त, प्रत्येक स्तर में कई अन्य विशेषताएँ होनी चाहिए। उदाहरण के लिए, आप देख सकते हैं कि प्रत्येक स्तर का एक नाम है, उदाहरण के लिए, "LESSON 1", "सही मिलान", "DRAVN और QUARTERED", और इसी तरह। विभिन्न स्तरों की अलग-अलग समय सीमाएँ भी होती हैं, इसलिए हम यह मान सकते हैं कि यह जानकारी भी डेटा में समाहित है। इसके अलावा, प्रत्येक स्तर पर इकट्ठे चिप्स की अपनी संख्या होती है। (हम मान सकते हैं कि यह संख्या बस स्तर पर चिप्स की संख्या से मेल खाती है, लेकिन यह पता चला है कि कुछ स्तरों पर चिप कनेक्टर को खोलने के लिए आवश्यकता से अधिक चिप्स हैं। कम से कम इन स्तरों के लिए, न्यूनतम संख्या को स्पष्ट रूप में इंगित किया जाना चाहिए।)

डेटा का एक और टुकड़ा जो हम स्तर के डेटा में खोजने की उम्मीद करते हैं वह संकेत पाठ है। कुछ स्तरों पर एक "संकेत बटन" है - जमीन पर एक बड़ा प्रश्न चिह्न। जब चिप उस पर उठती है, तो एक टूलटिप पाठ प्रदर्शित किया जाता है। संकेत बटन लगभग 20 स्तरों पर है।

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

तो यहाँ प्रासंगिक डेटा की हमारी सूची है:

• स्तर का नक्शा
• स्तर का नाम
• पासवर्ड का स्तर
• समय सीमा
• चिप्स की संख्या
• टूलटिप पाठ

चलो डेटा के कुल आकार का अनुमान लगाते हैं। समय सीमा और चिप्स की संख्या निर्धारित करने का सबसे आसान तरीका। इन दोनों मापदंडों में 0 से 999 तक के मान हो सकते हैं, इसलिए उन्हें 4 बाइट्स के कुल आकार के साथ पूर्णांक मान के रूप में संग्रहीत किया जाता है। पासवर्ड में हमेशा चार अक्षर होते हैं, इसलिए इसे चार और बाइट्स के रूप में संग्रहीत किया जाता है, यानी केवल 8 बाइट्स। स्तरों के नाम की लंबाई चार से उन्नीस अक्षरों में भिन्न होती है। यदि हम मानते हैं कि हमें लाइन को पूरा करने के लिए एक और बाइट की आवश्यकता है, तो यह बीस बाइट्स है, यानी, सबटोटल 28 बाइट्स है। सबसे लंबा टूलटिप पाठ आकार में 80 बाइट्स से अधिक है; यदि हम इस मान को 90 पर गोल करते हैं, तो हमें कुल 118 बाइट मिलेंगे।

स्तर योजना के बारे में क्या? अधिकांश स्तरों में 32 × 32 टाइल्स का आकार होता है। बड़े स्तर मौजूद नहीं हैं। कुछ स्तर कम हैं, लेकिन यह मानना ​​तर्कसंगत होगा कि वे केवल 32 × 32 कार्ड में एम्बेडेड हैं। यदि हम मानते हैं कि एक टाइल के लिए एक बाइट की आवश्यकता होती है, तो पूर्ण सर्किट के लिए 1024 बाइट की आवश्यकता होती है। यही है, सामान्य तौर पर, हमें 1142 बाइट्स प्रति स्तर का मोटा अनुमान है। बेशक, यह सिर्फ एक मोटा प्रारंभिक अनुमान है। यह संभव है कि इनमें से कुछ तत्व अलग-अलग संग्रहीत हैं, या स्तर की फ़ाइलों के अंदर संग्रहीत नहीं हैं। या उनके पास अन्य डेटा हो सकते हैं जिन्हें हमने नोटिस नहीं किया था या उनके बारे में नहीं जानते थे। लेकिन अभी तक हमने एक अच्छी नींव रखी है।

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

क्या है और क्या नहीं है

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

  $ तार का स्तर / * |  कम
 : @; #
 &> '' :: 4 #
 , ,,!
 -54 ";
 / & 67
 !) ६०
 <171
 * (0 *)
 82> '= /
 8> <171 &&
 9> # 2 ') (
 ,) ९
  0hX
 `@PX
 ) "" *
 २४ ** ५
 ;)) <
 B777: .. 22C1
 ई ,, एफ
 -GDED
 EGFF16G ;; H <
 IECJ
 9K444
 = MBBB >> N9 "O" 9P3? Q?
 लाइनें 1-24 / 1544 (अधिक) 

ASCII कचरे के मनमाने अंशों के अलावा यहां कुछ भी दिखाई नहीं देता है।

संभवतः, इन फ़ाइलों में कहीं-कहीं स्तर के नाम और संकेत हैं, लेकिन वे या तो ASCII में संग्रहीत नहीं हैं, या कुछ परिवर्तन से गुज़रे हैं (उदाहरण के लिए, संपीड़न के कारण)।

यह निम्नलिखित पर ध्यान देने योग्य भी है: फ़ाइल बमुश्किल 256 बाइट्स के आकार तक पहुंचती है। यह काफी छोटा है, यह देखते हुए कि शुरू में हमने इसका आकार 1140 बाइट से अधिक होने का अनुमान लगाया था।

-S विकल्प आकार के अवरोही क्रम में फ़ाइलों को सॉर्ट करता है।

  $ ls -lS स्तर |  सिर
 कुल 592
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 680 Jun 23 2015 mulligan.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 675 जून 23 2015 संकोचन.पाक
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 671 Jun 23 2015 बॉल्स_o_.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 648 जून 23 2015 cake_wal.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 647 जून 23 2015 citybloc.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 639 जून 23 2015 four_ple.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 636 Jun 23 2015 Trust_me.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 625 Jun 23 2015 block_n_.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 622 Jun 23 2015 mix_up.pak 

सबसे बड़ी फ़ाइल केवल 680 बाइट्स लेती है, और यह बहुत ज्यादा नहीं है। और सबसे छोटा क्या होगा?

-r विकल्प ls को आदेश को उलटने के लिए कहता है।

  $ ls -lSr स्तर |  सिर
 कुल 592
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 206 Jun 23 2015 kablam.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 214 जून 23 2015 भाग्य_पाक
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 219 जून 23 2015 digdirt.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 226 जून 23 2015 lesson_2.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 229 Jun 23 2015 lesson_8.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 237 Jun 23 2015 आंशिक_.पाक
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 239 जून 23 2015 knot.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 247 Jun 23 2015 cellbloc.pak
 -rw-r - r-- 1 ब्रेडबॉक्स ब्रेडबॉक्स 248 जून 23 2015 torturec.pak 

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

हमारे प्रारंभिक मूल्यांकन में, हमने माना कि कार्ड को प्रति टाइल एक बाइट की आवश्यकता होगी, और केवल 1024 बाइट्स। यदि हम इस अनुमान को आधे में काटते हैं, अर्थात्, प्रत्येक टाइल को केवल 4 बिट्स (या दो टाइल प्रति बाइट) की आवश्यकता होगी, तो कार्ड अभी भी 512 बाइट्स पर कब्जा करेगा। 512 680 से छोटा है, लेकिन अभी भी अधिकांश स्तरों से बड़ा है। और किसी भी मामले में - 4 बिट्स केवल 16 अलग-अलग मूल्य प्रदान करेंगे, और खेल में बहुत अधिक अलग-अलग ऑब्जेक्ट हैं।

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

हम सबसे बड़ी फ़ाइलों के नक्शे देख सकते हैं:


लेवल 57 मैप: स्ट्रेंथ MAZE


लेवल 98 कार्ड: SHRINKING

और फिर उनकी तुलना सबसे छोटी फाइलों के नक्शे से करें:


लेवल 106 कार्ड: KABLAM


स्तर 112 कार्ड: फोर्नेट फ़ेवर

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

यदि फाइलें वास्तव में एन्क्रिप्ट की जाती हैं, तो कार्ड डेटा को डिक्रिप्ट करने से पहले हमें सबसे पहले सम्पीडन को डिक्रिप्ट करना होगा।

हम एक ही समय में कई फ़ाइलों का अध्ययन करते हैं

पहली डेटा फ़ाइल के हमारे संक्षिप्त अध्ययन ने हमें कुछ अनुमान लगाने की अनुमति दी, लेकिन कुछ भी ठोस नहीं मिला। अगले चरण के रूप में, हम कई डेटा फ़ाइलों के पैटर्न का पता लगाना शुरू करेंगे। अभी के लिए, हम मानते हैं कि सभी 148 फाइलें डेटा को एन्कोड करने के लिए एक ही ऑर्डरिंग स्कीम का उपयोग करती हैं, इसलिए इन फ़ाइलों में डुप्लिकेट पैटर्न की तलाश हमें आरंभ करने में मदद करेगी।

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

  स्तरों में एफ के लिए $ / *;  xxd $ f |  sed -n 1p;  हो गया |  कम
 00000000: 2300 dc01 0300 0004 0101 0a03 030b 2323 # ............. ##
 00000000: 2d00 bf01 0300 0015 0101 2203 0329 2222 -... "..)"
 00000000: 2b00 a101 0301 0105 0000 0601 0207 0505 + ..............।
 00000000: 1d00 d300 0200 0003 0101 0402 0205 0102 ................
 00000000: 2d00 7a01 0300 0006 1414 0701 0109 0303 -z …………।
 00000000: 3100 0802 0200 0003 0101 0502 0206 1313 1 ..............।
 00000000: 1a00 b700 0200 0003 0100 0502 0206 0101 ................
 00000000: 1a00 0601 0300 0005 0001 0601 0107 0303 ................
 00000000: 2000 7a01 0200 0003 0202 0401 0105 0028 .z ............ (
 00000000: 3a00 a400 0200 0003 2828 0428 0205 0303: ....... (? (....)।
 00000000: 2600 da00 0300 0004 0507 0901 010a 0303 और ...............
 00000000: 2400 f000 0300 0004 0303 0504 0407 0101 $ ..............।
 00000000: 2a00 ef01 0300 0005 0101 0614 0007 0303 * ..............।
 00000000: 2c00 8c01 0300 0004 0303 0500 0107 0101, ..............।
 00000000: 2a00 0001 0300 0004 0303 0501 0107 0404 * ..............।
 00000000: 1b00 6d01 0200 0003 0101 0502 0206 0003 ..m .............
 00000000: 1e00 1701 0200 0003 0202 0401 0105 0013 ................
 00000000: 3200 ee01 0f00 0015 0101 270f 0f29 1414 2 ......... '..) ।।
 00000000: 2a00 5b01 0300 0005 0303 0601 0107 1414 *। […………।
 00000000: 2c00 8a01 0200 0003 0202 0401 0105 0303, ..............।
 00000000: 1d00 9c00 0216 1604 0000 0516 0107 0205 ................
 00000000: 2000 e100 0200 0003 0101 0402 0205 0303 ..............।
 00000000: 2000 2601 0300 0004 0303 0502 0207 0101. और ............
 00000000: 1f00 f600 0132 0403 0000 0532 3206 0404 ..... 2 ..... 22 ...
 1-24 / 148 (अधिक) 

इस डंप को देखते हुए, आप देख सकते हैं कि प्रत्येक कॉलम में कुछ समान मूल्य हैं।

पहली बाइट के साथ शुरू करते हुए, हम जल्द ही महसूस करते हैं कि इसका मूल्य बहुत सीमित श्रेणी में है, हेक्साडेसिमल 40 (या दशमलव में लगभग 20–60 ) की सीमा में। यह एक बहुत विशिष्ट विशेषता है।

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

छोटा-सा एंडियन क्या है? जब एक संख्यात्मक मूल्य जो एक से अधिक बाइट को संग्रहीत करता है, तो आपको पहले उस क्रम का चयन करना होगा जिसमें बाइट्स संग्रहीत होंगे। यदि आप पहली बार एक बाइट को संख्या के छोटे हिस्से का प्रतिनिधित्व करते हैं, तो इसे प्रत्यक्ष-क्रम ( लिटिल-एंडियन ) कहा जाता है; यदि आप पहले बाइट्स को सबसे अधिक संख्या में दर्शाते हुए स्टोर करते हैं, तो यह रिवर्स ऑर्डर ( बिग-एंडियन ) है। उदाहरण के लिए, हम दशमलव मानों को रिवर्स ऑर्डर (बिग-एंडियन) में लिखते हैं: लाइन "42" का अर्थ है "बयालीस," नहीं "चार और बीस।" लिटिल-एंडियन माइक्रोप्रोसेसरों के कई परिवारों के लिए एक प्राकृतिक आदेश है, इसलिए यह आमतौर पर अधिक लोकप्रिय है, नेटवर्क प्रोटोकॉल के अपवाद के साथ, जिसे आमतौर पर बड़े-एंडियन की आवश्यकता होती है।

यदि हम विश्लेषण जारी रखते हैं, तो हम जल्द ही देखेंगे कि फ़ाइल में तीसरा बाइट पिछले दो के समान नहीं है: इसका मान एक विस्तृत श्रृंखला पर भिन्न होता है। हालांकि, चौथा बाइट हमेशा 00 , 01 या 02 , और 01 सबसे आम है। यह भी हमें संकेत देता है कि ये दोनों बाइट्स एक और 16-बिट मान का गठन करते हैं, जो दशमलव मान 0-700 की सीमा में है। इस परिकल्पना की पुष्टि इस तथ्य से भी की जा सकती है कि तीसरी बाइट का मूल्य आमतौर पर कम है अगर चौथी बाइट का मूल्य 02 , और आमतौर पर बड़ा है अगर चौथी बाइट 00 ।

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

आइए दृश्य अन्वेषण जारी रखें, और देखें कि क्या यह पैटर्न 16-बिट पूर्णांक मानों से संरक्षित है। पांचवें बाइट में आमतौर पर बहुत कम मूल्य होते हैं: 02 और 03 सबसे अधिक बार सामना किए जाते हैं, और अधिकतम मान 05 लगता है। किसी फ़ाइल का छठा बाइट अक्सर शून्य के बराबर होता है - लेकिन कभी-कभी इसमें बहुत बड़ा मान होता है, उदाहरण के लिए 32 या 2C । इस जोड़ी में, अंतराल में वितरित मूल्यों के बारे में हमारी धारणा विशेष रूप से पुष्टि नहीं की गई है।

हम प्रारंभिक मूल्यों का ध्यानपूर्वक अध्ययन करते हैं

हम हेक्स डंप उत्पन्न करने के लिए od का उपयोग करके अपने अनुमान का परीक्षण कर सकते हैं। od यूटिलिटी xxd समान है, लेकिन आउटपुट प्रारूपों का एक बड़ा चयन प्रदान करता है। हम इसका उपयोग आउटपुट को 16-बिट दशमलव पूर्णांक के रूप में डंप करने के लिए कर सकते हैं:

-t यूटिलिटी का विकल्प आउटपुट फॉर्मेट को निर्दिष्ट करता है। इस स्थिति में, u बिना अहस्ताक्षरित दशमलव संख्या के लिए खड़ा है, और 2 प्रति रिकॉर्ड दो बाइट्स के लिए है। (आप -d विकल्प का उपयोग करके भी इस प्रारूप को निर्दिष्ट कर सकते हैं।)

  स्तरों में एफ के लिए $ / *;  do od -tu2 $ f |  sed -n 1p;  हो गया |  कम
 0000000 35 476 3 1024 257 778 2819 8995
 0000000 45 447 3 5376 257 802 10499 8738
 0000000 43 417 259 1281 0 262 1794 1285
 0000000 29 211 2 768 257 516 1282 513
 0000000 45 378 3 1536 5140 263 2305 771
 0000000 49 520 2 768 257 517 1538 4883
 0000000 26 183 2 768 1 517 1538 257
 0000000 26 262 3 1280 256 262 1793 771
 0000000 32 378 2 768 514 260 1281 10240
 0000000 58 164 2 768 10280 10244 1282 771
 0000000 38 218 3 1024 1797 265 2561 771
 0000000 36 240 3 1024 771 1029 1796 257
 0000000 42 495 3 1280 257 5126 1792 771
 0000000 44 396 3 1024 771 5 1793 257
 0000000 42 256 3 1024 771 261 1793 1028
 0000000 27 365 2 768 257 517 1538 768
 0000000 30 279 2 768 514 260 1281 4864
 0000000 50 494 15 5376 257 3879 10511 5140
 0000000 42 347 3 1280 771 262 1793 5140
 0000000 44 394 2 768 514 260 1281 771
 0000000 29 156 5634 1046 0 5637 1793 1282
 0000000 32 225 2 768 257 516 1282 771
 0000000 32 294 3 1024 771 517 1794 257
 0000000 31 246 12801 772 0 12805 1586 1028
 1-24 / 148 (अधिक) 

यह आउटपुट दिखाता है कि पहले कुछ बाइट्स के बारे में हमारा अनुमान सही था। हम देखते हैं कि पहला १६-बिट मान २०- and० की दशमलव सीमा में है, और दूसरा १६-बिट मान १००-६०० की दशमलव सीमा में है। हालाँकि, बाद के मान इतनी अच्छी तरह से व्यवहार नहीं करते हैं। कुछ पैटर्न उनमें दिखाई देते हैं (उदाहरण के लिए, चौथे स्थान पर, आश्चर्यजनक रूप से अक्सर 1024), लेकिन उनके पास फ़ाइल के पहले मूल्यों में निहित दोहराव नहीं है।

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

वास्तव में, मूल्यों का दूसरा अंतराल (100-600) फ़ाइल आकार के अंतराल के काफी करीब है, जिसे हमने पहले देखा था (208–680)। शायद यह संयोग नहीं है? आइए एक परिकल्पना को सामने रखें: फ़ाइल के तीसरे और चौथे बाइट्स में संग्रहीत 16-बिट मान कुल फ़ाइल आकार के साथ संबंधित है। अब जब हमारे पास एक परिकल्पना है, तो हम इसका परीक्षण कर सकते हैं। आइए देखें कि क्या इस जगह की बड़ी फ़ाइलों में वास्तव में हर समय बड़े मूल्य हैं, और छोटे लोगों के पास छोटे मूल्य हैं।

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

-N4 यूटिलिटी का -An ऑप्शन -N4 करता है, जो फाइल में ऑफसेट को प्रदर्शित करता है, और -N4 od फाइल के पहले 4 बाइट्स के बाद रुकने od कहता है।

  स्तरों में एफ के लिए $ / *;  do size = $ (wc -c <$ f);  data = $ (od -tuS -An -N4 $ f);  इको "$ आकार: $ डेटा";  हो गया |  कम
 585: 35 476
 586: 45 447
 550: 43,417
 302: 29,211
 517: 45 378
 671: 49 520
 265: 26 183
 344: 26,262
 478: 32,378
 342: 58 164
 336: 38 218
 352: 36,240
 625: 42 495
 532: 44,396
 386: 42,256
 450: 27 365
 373: 30 279
 648: 50 494
 477: 42 347
 530: 44,394
 247: 29 156
 325: 32,225
 394: 32,294
 343: 31,246 

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

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

हम readआउटपुट से दो संख्याओं odको अलग-अलग चर में निकालने के लिए उपयोग कर सकते हैं , और फिर उनके योग को खोजने के लिए शेल अंकगणितीय का उपयोग कर सकते हैं:

शेल कमांडreadऊर्ध्वाधर पट्टी के दाईं ओर का उपयोग नहीं किया जा सकता है, क्योंकि पाइपलाइन में स्थानांतरित आदेशों को एक चाइल्ड कमांड प्रोसेसर (सबमिशन) में निष्पादित किया जाता है, जो बाहर निकलने पर, इसके पर्यावरण चर को बिट रिसीवर में ले जाता है। इसलिए, इसके बजाय, हमें प्रक्रिया प्रतिस्थापन फ़ंक्शन का उपयोग करने bashऔर आउटपुट odको एक अस्थायी फ़ाइल पर निर्देशित करने की आवश्यकता है, जिसे तब कमांड पर पुनर्निर्देशित किया जा सकता है read।

स्तरों में एफ के लिए $ / *; do size = $ (wc -c <$ f); v1 v2 << (od -tuS -An -N4 $ f) पढ़ें; sum = $ (($ v1 + $ v2));
    इको "$ आकार: $ v1 + $ v2 = $ योग"; हो गया | कम
585: 35 + 476 = 511
586: 45 + 447 = 492
550: 43 + 417 = 460
302: 29 + 211 = 240
517: 45 + 378 = 423
671: 49 + 520 = 569
265: 26 + 183 = 209
344: 26 + 262 = 288
478: 32 + 378 = 410
342: 58 + 164 = 222
336: 38 + 218 = 256
352: 36 + 240 = 276
625: 42 + 495 = 537
532: 44 + 396 = 440
386: 42 + 256 = 298
450: 27 + 365 = 392
373: 30 + 279 = 309
648: 50 + 494 = 544
477: 42 + 347 = 389
530: 44 + 394 = 438
247: 29 + 156 = 185
325: 32 + 225 = 257
394: 32 + 294 = 326
343: 31 + 246 = 277
1-24 / 148 (अधिक) 

दो संख्याओं का योग भी लगभग फ़ाइल आकार के साथ संबंधित है, लेकिन वे अभी भी काफी मेल नहीं खाते हैं। वे कितने अलग हैं? आइए उनके अंतर को प्रदर्शित करें:

स्तरों में एफ के लिए $ / *; do size = $ (wc -c <$ f); v1 v2 << (od -tuS -An -N4 $ f) पढ़ें; diff = $ (($ आकार - $ v1 - $ v2));
    इको "$ आकार = $ v1 + $ v2 + $ भिन्न"; हो गया | कम
585 = 35 + 476 + 74
586 = 45 + 447 + 94
550 = 43 + 417 + 90
302 = 29 + 211 + 62
517 = 45 + 378 + 94
671 = 49 + 520 + 102
265 = 26 + 183 + 56
344 = 26 + 262 + 56
478 = 32 + 378 + 68
342 = 58 + 164 + 120
336 = 38 + 218 + 80
352 = 36 + 240 + 76
625 = 42 + 495 + 88
532 = 44 + 396 + 92
386 = 42 + 256 + 88
450 = 27 + 365 + 58
373 = 30 + 279 + 64
648 = 50 + 494 + 104
477 = 42 + 347 + 88
530 = 44 + 394 + 92
247 = 29 + 156 + 62
325 = 32 + 225 + 68
394 = 32 + 294 + 68
343 = 31 + 246 + 66
lines 1-24/148 (more) 

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

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

(यदि आप पर्याप्त सावधानी बरतते हैं, तो आप पहले से ही एक कनेक्शन के बारे में संकेत देते हुए कुछ देख चुके हैं जो अभी तक देखा नहीं गया है। यदि आप नहीं कर रहे हैं, तो पढ़ना जारी रखें। रहस्य जल्द ही सामने आ जाएगा।)

बड़ी क्रॉस-फ़ाइल तुलना

इस बिंदु पर, एक बार में 16 से अधिक बाइट्स को पार-तुलना करने में सक्षम होना अच्छा होगा। इसके लिए हमें एक अलग प्रकार के दृश्य की आवश्यकता होती है। एक अच्छा दृष्टिकोण एक ऐसी छवि बनाना है जिसमें प्रत्येक पिक्सेल फ़ाइलों में से एक की एक अलग बाइट को दर्शाता है, और रंग इस बाइट के मूल्य को दर्शाता है। एक छवि एक समय में सभी 148 फ़ाइलों का एक टुकड़ा दिखा सकती है यदि प्रत्येक डेटा फ़ाइल छवि पिक्सेल की एक पंक्ति द्वारा इंगित की जाती है। चूंकि सभी फाइलें अलग-अलग आकार की हैं, इसलिए हम आयताकार छवि बनाने के लिए प्रत्येक के पहले 200 बाइट लेते हैं।

सबसे आसान तरीका ग्रेस्केल में एक छवि बनाना है, जिसमें प्रत्येक बाइट का मूल्य ग्रे के विभिन्न स्तरों से मेल खाता है। हमारे डेटा के साथ PGM फ़ाइल बनाना बहुत सरल है, क्योंकि PGM हेडर में केवल ASCII टेक्स्ट होते हैं:

 $ echo P5 200 148 255 >hdr.pgm 

PGM? PGM, «portable graymap» (« ») — , : ASCII, . — PBM («portable bitmap», « »), 8 , PPM («portable pixmap», « »), 3 .

P5पीजीएम फ़ाइल प्रारूप के लिए प्रारंभिक हस्ताक्षर है। अगले दो नंबर, 200और 148, छवि की चौड़ाई और ऊँचाई निर्दिष्ट करते हैं, और अंतिम 255, प्रति पिक्सेल अधिकतम मूल्य इंगित करता है। पिक्सेल डेटा के बाद PGM हेडर एक नई लाइन के साथ समाप्त होता है। (यह ध्यान देने योग्य है कि PGM शीर्ष लेख को अक्सर पाठ की तीन अलग-अलग पंक्तियों में विभाजित किया जाता है, लेकिन PGM मानक के लिए केवल यह आवश्यक है कि तत्वों को कुछ व्हाट्सएप चरित्र द्वारा अलग किया जाए।)

हम headप्रत्येक फाइल के लिए पहले 200 बाइट्स निकालने के लिए उपयोगिता का उपयोग कर सकते हैं :

स्तरों में एफ के लिए $ / *; हेड -c200 $ f; किया> बाहर

फिर हम उन्हें एक शीर्षक के साथ संक्षिप्त कर सकते हैं और एक प्रदर्शित छवि बना सकते हैं:

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

$ cat hdr.pgm out.pgm | xview / देव / स्टडिन

यदि आपके लिए एक अंधेरे छवि में विवरण पर विचार करना मुश्किल है, तो आप एक अलग रंग योजना चुन सकते हैं। pgmtoppmपिक्सेल को रंगों की एक अलग श्रेणी में बदलने के लिए ImageMagick से उपयोगिता का उपयोग करें । यह संस्करण एक "नकारात्मक" छवि बनाएगा:

$ cat hdr.pgm out.pgm | pgmtoppm सफेद-काला | xview / देव / स्टडिन

और यह संस्करण निम्न मान को पीला और उच्च मान को नीला बनाता है:

$ cat hdr.pgm out.pgm | pgmtoppm पीला-नीला | xview / देव / स्टडिन

रंगों की दृश्यता एक बहुत ही व्यक्तिपरक प्रश्न है, इसलिए आप प्रयोग कर सकते हैं और चुन सकते हैं कि आपके लिए सबसे अच्छा कौन सा है। जैसा कि हो सकता है, 200 × 148 छवि काफी छोटी है, इसलिए इसका आकार बढ़ाकर दृश्यता बढ़ाना सबसे अच्छा है:

$ cat hdr.pgm out.pgm | xview -ज़ूम 300 / देव / स्टडिन

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

और यद्यपि तीसरे बाइट के बाहर कई उच्च मूल्य नहीं हैं, जब वे दिखाई देते हैं, तो वे अक्सर श्रृंखला से मिलकर होते हैं, जिससे छवि में छोटी उज्ज्वल धारियां बनती हैं। इन श्रृंखलाओं में से कुछ समय-समय पर बाधित होती हैं, जिससे एक धराशायी लाइन प्रभाव पैदा होता है। (शायद, सही रंग चयन के साथ, गहरे रंगों में ऐसे दृश्यों को नोटिस करना संभव होगा।)

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

धारियों में थोड़ा गहरा पिक्सेल की पृष्ठभूमि के खिलाफ थोड़ा उज्जवल पिक्सेल की पतली रेखाएँ होती हैं। इसलिए, इस ग्राफिक पैटर्न को डेटा फ़ाइलों के पैटर्न के साथ सहसंबंधित होना चाहिए, जिसमें थोड़ा बड़ा मूल्य समान रूप से थोड़ा छोटे बाइट मूल्यों के बीच बिखरे हुए हैं। ऐसा लगता है कि छवि के बीच में धारियां कम हो गई हैं। चूंकि यह फ़ाइलों के पहले 200 बाइट्स को दिखाता है, इसलिए आपको उम्मीद करनी चाहिए कि बाइट पैटर्न लगभग 100 बाइट्स के बाद समाप्त होता है।

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

स्तरों में एफ के लिए $ / *; टेल -c200 $ f; किया> out.pgm; cat hdr.pgm out.pgm | xview -ज़ूम 300 / देव / स्टडिन

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

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

और हम वास्तव में थोड़ा और प्रयास कर सकते हैं। आप छवियों PIL("तकिया") के साथ काम करने के लिए पायथन और उसकी लाइब्रेरी का उपयोग कर सकते हैं :

फ़ाइल

 import sys from PIL import Image # Retrieve the full list of data files. filenames = sys.argv[1:] # Create a grayscale image, its height equal to the number of data files. width = 750 height = len(filenames) image = Image.new('L', (width, height)) # Fill in the image, one row at a time. for y in range(height): # Retrieve the contents of one data file. data = open(filenames[y]).read() linewidth = len(data) # Turn the data into a pixel-high image, each byte becoming one pixel. line = Image.new(image.mode, (linewidth, 1)) linepixels = line.load() for x in range(linewidth): linepixels[x,0] = ord(data[x]) # Stretch the line out to fit the final image, and paste it into place. line = line.resize((width, 1)) image.paste(line, (0, y)) # Magnify the final image and display it. image = image.resize((width, 3 * height)) image.show() 

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

 $ पाइथन शोबाइट्सहोम का स्तर / * 

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

डेटा की विशेषता

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

मूल्यों को पूरी तरह से

फिर से लिखने के लिए, पायथन में कुछ पंक्तियाँ पर्याप्त हैं: जनगणना फ़ाइल:

 import sys data = sys.stdin.read() for c in range(256): print c, data.count(chr(c)) 

एक चर में सभी डेटा को जोर देने के बाद, हम प्रत्येक बाइट मान की घटना की आवृत्ति की गणना कर सकते हैं।

$ बिल्ली का स्तर / * | python ./census.py | कम
0 2458
1 2525
२ १६२६
३ १ 3६68
४ १०४२
५ १४ ९ १
6 1081
7 1445
8 ९ ५8
९ १५४१
१० १२ 10 ९
११ १२२४
12845
१३ ९ ०8
१४ 14५ ९
15 1022
१६ ६ 16 ९
17 1087
18,881
19 1116
20 1007
21 1189
२२ १०२ ९
23,733
लाइनें 1-24 / 256 (अधिक) 

हम देखते हैं कि सबसे अधिक बार बाइट मान 0 और 1 होते हैं, आवृत्ति में अगला 2 और 3 होता है, जिसके बाद संख्या घट जाती है (हालांकि कम गति के साथ)। इस डेटा को बेहतर रूप से देखने के लिए, हम आउटपुट को gnuplotइस जनगणना में बदल सकते हैं और हिस्टोग्राम में बदल सकते हैं: उपयोगिता

विकल्प काम पूरा होने के बाद ग्राफ के साथ विंडो को बंद नहीं करने का आदेश देता है ।-pgnuplotgnuplot

$ बिल्ली का स्तर / * | python ./census.py | gnuplot -p -e 'plot "-" बॉक्स के साथ'

यह बहुत ही ध्यान देने योग्य है कि पहले कुछ बाइट मूल्य अन्य सभी की तुलना में बहुत अधिक सामान्य हैं। निम्न मानों में से कई भी काफी सामान्य हैं, और फिर लगभग 50 से मूल्यों की आवृत्ति एक चिकनी संभावना वक्र के साथ घटने लगती है। हालांकि, उच्च मूल्यों का एक सबसेट है जो समान रूप से एक दूसरे से अलग हैं, जिनमें से आवृत्ति बल्कि स्थिर लगती है। मूल आउटपुट को देखकर, हम यह सुनिश्चित कर सकते हैं कि इस सबसेट में ऐसे मूल्य शामिल हैं जो आठ से विभाज्य हो सकते हैं।

ये मानों की संख्या में अंतर बताते हैं कि बाइट मानों के कई अलग-अलग "वर्ग" हैं, इसलिए यह देखना तर्कसंगत होगा कि ये कक्षाएं कैसे वितरित की जाती हैं। बाइट मानों का पहला समूह सबसे कम मान होगा: 0, 1, 2, और 3. फिर दूसरा समूह 4 से 64 तक मान हो सकता है। और तीसरा समूह 64 से ऊपर के मान होंगे, जो 8. से विभाज्य हैं। बाकी के बिना, बाकी सब, सहित 64 से अधिक 8 मूल्यों के गैर-विभाज्य चौथा और अंतिम समूह होगा।

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

Showbytes2.py फ़ाइल:

 import sys from PIL import Image # Retrieve the full list of data files. filenames = sys.argv[1:] # Create a color image, its height equal to the number of data files. width = 750 height = len(filenames) image = Image.new('RGB', (width, height)) # Fill in the image, one row at a time. for y in range(height): # Retrieve the contents of one data file. data = open(filenames[y]).read() linewidth = len(data) # Turn the data into a pixel-high image, each byte becoming one pixel. line = Image.new(image.mode, (linewidth, 1)) linepixels = line.load() # Determine which group each byte belongs to and assign it a color. for x in range(linewidth): byte = ord(data[x]) if byte < 0x04: linepixels[x,0] = (255, 0, 0) elif byte < 0x40: linepixels[x,0] = (0, 255, 0) elif byte % 8 == 0: linepixels[x,0] = (0, 0, 255) else: linepixels[x,0] = (255, 255, 255) # Paste the line of pixels into the final image, stretching to fit. line = line.resize((width, 1)) image.paste(line, (0, y)) # Magnify the final image and display it. image = image.resize((width, 3 * height)) image.show() 

हमने चार समूहों को लाल, हरा, नीला और सफेद रंग दिया। (फिर, आप अपनी प्राथमिकताओं के अनुरूप अन्य रंगों को चुनने का प्रयास कर सकते हैं।)

 $ अजगर शोबीस २-०५ स्तर / * 

इस छवि के लिए धन्यवाद, हम डेटा फ़ाइलों को पाँच भागों में अलग करने की शुद्धता की पूर्व-पुष्टि कर सकते हैं:

1. चार-बाइट हेडर जो हमें पहले मिला था।
2. , , (.. ).
3. , (. 64).
4. , .
5. , .

इन रंगों के लिए धन्यवाद, यह स्पष्ट है कि चौथे भाग में, जहां उच्च बाइट मान प्रबल होते हैं, जैसा कि ग्रेस्केल में छवि में देखा जा सकता है, उच्च बाइट मान, 8 से विभाजित, विशेष रूप से प्रबल होता है।

पिछली छवि से हम जानते हैं कि दूसरा भाग, यानी धारियों वाला भाग। लगभग पूरी तरह से लाल क्षेत्र में फैला है। वास्तव में, पहली छवियों में से एक में हमने देखा कि धारियों वाला भाग, बाएं से दाएं, धीरे-धीरे औसत पर चमकता है।

हम फिर से देखते हैं कि मुख्य तीसरे भाग से हरे रंग के पिक्सेल समय-समय पर आंतरायिक हरे और लाल पिक्सेल (या तो नीले या सफेद) से पैटर्न चित्रित करते हैं। हालांकि, यह पैटर्न विशेष रूप से नियमित नहीं है, और काल्पनिक हो सकता है।

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

संरचना खोज

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

(कुछ समय के लिए, हम मानते हैं कि स्ट्रिप पैटर्न पहले चार बाइट्स के तुरंत बाद शुरू होता है। नेत्रहीन, यह स्पष्ट नहीं है, लेकिन यह संभावना है, और बाइट मूल्यों की जांच करना हमें जल्दी से सच दिखाना चाहिए।)

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

विकल्प फ़ाइल के पहले 4 बाइट्स -s4को xxdछोड़ने का आदेश देता है ।

स्तरों में एफ के लिए $ / *; do xxd -s4 $ f | sed -n 1p; हो गया | कम
00000004: 0200 0003 0202 0401 0105 0303 0700 0108 ................
00000004: 0201 0104 0000 0504 0407 0202 0902 010a ................
00000004: 0300 0004 0303 0504 0407 0505 0801 0109 ................
00000004: 0300 0009 0202 1203 0313 0909 1401 0115 ................
00000004: 0203 0305 0000 0602 0207 0505 0901 010a ................
00000004: 0203 0304 0000 0502 0404 001 0901 010a ................
00000004: 0300 0005 022a 0602 2907 0303 0902 000a ..... * ..) .......
00000004: 0203 0305 0000 0605 0507 0101 0802 0209 ................
00000004: 0300 0007 0303 0901 010a 0707 0b09 090c ................
00000004: 0300 0004 0101 0903 030e 0404 1609 0920 ...............
00000004: 0200 0003 1313 0402 0205 0013 0701 0109 ................
00000004: 0500 0006 0505 0701 0109 0606 0e07 070f ................
00000004: 0100 0003 0101 0a03 030b 0a0a 0e32 3216 .............22.
00000004: 0300 0004 0705 0903 030a 0606 0b08 080c ................
00000004: 0200 0003 0701 0402 0209 0501 0a08 080b ................
00000004: 0200 0003 0202 0901 010a 0303 0b05 010d ................
00000004: 0200 0003 0202 0403 0305 0101 0904 040a ................
00000004: 0300 0007 0303 0f01 0115 0707 2114 1422 ............!.."
00000004: 0200 0003 0202 0403 0309 0101 0a04 040b ................
00000004: 0231 3103 0202 0500 0006 0303 0701 0109 .11.............
00000004: 0200 0003 0202 0b32 320c 0303 0e08 0811 .......22.......
00000004: 0201 0103 0000 0902 020a 0303 0b09 090c ................
00000004: 0200 0003 0202 0a01 010b 0303 0d0b 0b0f ................
00000004: 0300 0005 0303 0701 0109 0001 0b05 051b ................
lines 27-50/148 (more) 

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

इस पैटर्न की निरंतरता से स्पष्ट है कि फ़ाइल का यह हिस्सा एक सरणी या तालिका है, और सरणी में प्रत्येक रिकॉर्ड की लंबाई तीन बाइट्स है।

आप आउटपुट को ट्रिपल की एक श्रृंखला के रूप में देखना आसान बनाने के लिए हेक्स डंप प्रारूप को कॉन्फ़िगर कर सकते हैं:

विकल्प -g3दो के बजाय तीन बाइट्स द्वारा समूहीकरण सेट करता है। विकल्प-c18 16 के बजाय प्रति पंक्ति 18 बाइट्स (3 का एक बहु) सेट करता है।

स्तरों में एफ के लिए $ / *; do xxd -s4 -g3 -c18 $ f | sed -n 1p; हो गया | कम
00000004: 050000 060505 070101 090606 0e0707 0f0001 ..................
00000004: 010000 030101 0a0303 0b0a0a 0e3232 161414 .............% ...
00000004: 030000 040705 090303 0a0606 0b0808 0c0101 ..................
00000004: 020000 030701 040202 090501 0a0808 0b0101 ..................
00000004: 020000 030202 090101 0a0303 0b0501 0d0302 ..................
00000004: 020000 030202 040303 050101 090404 0a0302 ..................
00000004: 030000 070303 0f0101 150707 211414 221313 ………… ..! ”..!
00000004: 020000 030202 040303 090101 0a0404 0b0001 ..................
00000004: 023131 030202 050000 060303 070101 090505 .11 ...............
00000004: 020000 030202 0b3232 0c0303 0e0808 110b0b ....... .........
00000004: 020101 030000 090202 0a0303 0b0909 0c0a0a ..................
00000004: 020000 030202 0a0101 0b0303 0d0b0b 0f2323 ................##
00000004: 030000 050303 070101 090001 0b0505 1b0707 ..................
00000004: 022323 030000 040202 050303 030101 070505 .##...............
00000004: 031414 050000 060303 070505 080101 090707 ..................
00000004: 030000 050202 060303 070505 080101 090606 ..................
00000004: 030202 040000 050303 070404 080005 090101 ..................
00000004: 030202 040000 050303 090404 1d0101 1f0909 ..................
00000004: 020000 050303 060101 070202 0f0300 110505 ..................
00000004: 050000 070101 0c0505 0d0007 110c0c 120707 ..................
00000004: 030202 050000 060303 070505 080101 090606 ..................
00000004: 020000 030101 050202 060505 070100 080303 ..................
00000004: 020000 030202 050303 090101 0a0505 0b0302 ..................
00000004: 022c2c 030000 040202 020303 050101 060202 .,,...............
lines 38-61/148 (more) 

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

एक और ध्यान देने योग्य पैटर्न जो तुरंत ध्यान देने योग्य नहीं है: प्रत्येक ट्रिपल का पहला बाइट बाएं से दाएं बढ़ता है। यद्यपि यह पैटर्न कम ध्यान देने योग्य है, इसकी स्थिरता अधिक है; पहले बेमेल को खोजने से पहले हमें बहुत सी लाइनों को देखना होगा। और बाइट्स आमतौर पर छोटे मूल्यों से बढ़ जाते हैं, लेकिन वे किसी भी नियमित पैटर्न का प्रतिनिधित्व नहीं करते हैं।

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

चलो पूरी फाइल की जांच करने के लिए केवल पहले स्तर पर डंप पर जाएं:

 $ xxd -s4 -g3 -c18 स्तर / lesson_1.pak
00000004: 020000 040202 050404 070505 080707 090001 ..................
00000016: 0a0101 0b0808 0d0a0a 110023 150907 180200 ........... # ......
00000028: 22090d 260911 270b0b 280705 291e01 272705 ".. और .. '.. (..) ..' '।
0000003a: 020d01 220704 090209 0a0215 042609 250111 ... "......... और% ..
0000004c: 150222 1d0124 011d0d 010709 002000 1b0400 .. ".." ………।
0000005e: 1a0020 152609 1f0033 002911 152223 02110d ... और ... 3.) .. # ... ...
00000070: 010726 091f18 291115 09181a 022302 1b0215 .. और ...) ..........
00000082: 22011c 011c0d 0a0704 090201 020128 260123 "........... (& #
00000094: 150509 020121 150522 0a2727 0b0504 00060b .....! "..."।
000000a6: 082804 18780b 082804 18700b 082804 186400 .(..x..(..p..(..d.
000000b8: 17101e 1e1a19 010300 0e1a17 17100e 1f010e ..................
000000ca: 13141b 291f1a 001210 1f011b 0c1e1f 011f13 ...)..............
000000dc: 10010e 13141b 001e1a 0e1610 1f2d00 201e10 .............-. ..
000000ee: 011610 24291f 1a011a 1b1019 000f1a 1a1d1e ...$).............
00000100: 2d02 

ट्रिपल के अनुक्रम का अध्ययन करते हुए, हम अस्थायी रूप से मान सकते हैं कि इस डेटा में बैंड के साथ भाग 17 ट्रिपल के बाद समाप्त होता है, ऑफसेट द्वारा 00000036। यह सटीक नहीं है, लेकिन प्रत्येक ट्रिपलेट का पहला बाइट लगातार इसके मूल्य को बढ़ाता है, और फिर अठारहवें ट्रिपलेट से घट जाता है। एक और प्रमाण: अठारहवें त्रिकाल में, दूसरी बाइट का अर्थ पहले जैसा है। हमने अभी तक इस पर ध्यान नहीं दिया है, लेकिन अगर हम पीछे लौटकर देखेंगे, तो हम देखेंगे कि पहली बाइट कभी भी दूसरी या तीसरी बाइट के बराबर नहीं होती है।

यदि हमारा मार्कर सिद्धांत सही है, तो दो संभावनाएं हैं। सबसे पहले, यह संभव है कि स्ट्रिप भाग के बाद कुछ विशेष बाइट मान (सत्रहवें ट्रिपल के ठीक बाद) हो। दूसरे, वहाँ शायद कहीं मौजूद एक मूल्य है जो धारियों के साथ भाग के आकार के बराबर है। यह आकार 17 के बराबर हो सकता है (अर्थात, यह त्रिगुणों की संख्या को इंगित करता है), या 51 (यह एक भाग में बाइट्स की कुल संख्या को इंगित करता है), या 55 (51 प्लस 4, अर्थात्, फ़ाइल का ऑफसेट जिसमें यह भाग समाप्त होता है)।

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

दूसरे विकल्प के लिए, यह स्पष्ट रूप से पहले भाग में आकार संकेतक की तलाश करेगा। निहारना - चार-बाइट फ़ाइल हैडर में पहला 16-बिट मूल्य 17 है:

 $ od -n -tuS -N4 स्तर / lesson_1.pak
    17 203 

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

स्तरों में एफ के लिए $ / *; do size = $ (wc -c <$ f); v1 v2 << (od -tuS -An -N4 $ f) पढ़ें; diff = $ (($ आकार - 3 * $ v1 - $ v2));
    गूंज "$ आकार = 3 * $ v1 + $ v2 + $ भिन्न"; हो गया | कम
585 = 3 * 35 + 476 + 4
586 = 3 * 45 + 447 + 4
550 = 3 * 43 + 417 + 4
302 = 3 * 29 + 211 + 4
517 = 3 * 45 + 378 + 4
671 = 3 * 49 + 520 + 4
265 = 3 * 26 + 183 + 4
344 = 3 * 26 + 262 + 4
478 = 3 * 32 + 378 + 4
342 = 3 * 58 + 164 + 4
336 = 3 * 38 + 218 + 4
352 = 3 * 36 + 240 + 4
625 = 3 * 42 + 495 + 4
532 = 3 * 44 + 396 + 4
386 = 3 * 42 + 256 + 4
450 = 3 * 27 + 365 + 4
373 = 3 * 30 + 279 + 4
648 = 3 * 50 + 494 + 4
477 = 3 * 42 + 347 + 4
530 = 3 * 44 + 394 + 4
247 = 3 * 29 + 156 + 4
325 = 3 * 32 + 225 + 4
394 = 3 * 32 + 294 + 4
343 = 3 * 31 + 246 + 4
lines 1-24/148 (more) 

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

हमें एक निरंतर सूत्र मिला, जिसका अर्थ है कि अब हम पूरी तरह से समझते हैं कि पहले भाग में संख्याओं का क्या मतलब है।

(वैसे, यहां बहुत ही गुप्त पैटर्न है जो चौकस पाठकों को नोटिस कर सकता है। समीकरणों का एक सावधानीपूर्वक अध्ययन यह स्पष्ट करता है कि जब फ़ाइलों में समान पहला नंबर होता है, तो उन्हें समान अवशिष्ट अंतर मिलता है। ऐसा इसलिए होता है क्योंकि अंतर हमेशा मूल्य से दोगुना होता है। पहला नंबर। यह एक स्पष्ट पैटर्न है, लेकिन एक श्रमसाध्य या सफल पर्यवेक्षक इसे नोटिस कर सकता है।)

इसलिए, हम कह सकते हैं कि फ़ाइल के तीन मुख्य भाग हैं:

1. चार-बाइट हेडर;
2. तीन बाइट रिकॉर्ड की तालिका; और
3. फ़ाइल का शेष भाग, जिसमें माना जाता है कि अधिकांश डेटा है।

(नतीजतन, अन्य भाग जो हमने पहले निर्धारित किए हैं, उन्हें तीसरे भाग के उपखंड होना चाहिए।)

मेटाडेटा की व्याख्या करना

इस योजना को देखते हुए, यह मानना ​​तर्कसंगत होगा कि दूसरे भाग की तालिका में प्रविष्टियाँ कुछ मेटाडेटा हैं जो तीसरे भाग के डेटा की व्याख्या करने के लिए आवश्यक हैं।

लेकिन इस तालिका में किस प्रकार का मेटाडेटा शामिल है?

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

(बेशक, प्रत्येक संपीड़न प्रकार एक संग्रहीत शब्दकोष का उपयोग नहीं करता है। उदाहरण के लिए, इसमें इस्तेमाल किया गया एल्गोरिथम एल्गोरिथ्म gzipऔर zlibआपको डेटा स्ट्रीम से सीधे शब्दकोश को फिर से बनाने की अनुमति देता है। लेकिन ऐसे मामले नियम के बजाय अपवाद हैं।)

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

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

फ़ाइल decompress.py:

 import struct import sys # Read the compressed data file. data = sys.stdin.read() # Extract the two integers of the four-byte header. tablesize, datasize = struct.unpack('HH', data[0:4]) data = data[4:] # Separate the dictionary table and the compressed data. tablesize *= 3 table = data[0:tablesize] data = data[tablesize:datasize] # Apply the dictionary entries to the data section. for n in range(0, len(table), 3): key = table[n] val = table[n+1:n+3] data = data.replace(key, val) # Output the expanded result. sys.stdout.write(data) 

अब हम एक उदाहरण डेटा फ़ाइल का उपयोग करके इस स्क्रिप्ट की जाँच कर सकते हैं:

$ python ./decompress.py <levels/lesson_1.pak | xxd
00000000: 0b0b 0b0b 0404 0000 0a0a 0109 0d05 0502 ................
00000010: 0200 0100 0000 0101 0100 0009 0702 0209 ................
00000020: 1100 0125 0100 2309 0700 0009 0d1d 0124 ...%..#........$
00000030: 011d 0a0a 0105 0500 0100 2000 1b02 0200 .......... .....
00000040: 1a00 2009 0709 1100 011f 0033 001e 0100 .. ........3....
00000050: 2309 0709 0d23 0000 0023 0a0a 0105 0509 #....#...#......
00000060: 1100 011f 0200 1e01 0023 0907 0001 0200 .........#......
00000070: 1a00 0023 0000 1b00 0009 0709 0d01 1c01 ...#............
00000080: 1c0a 0a01 0105 0502 0200 0100 0001 0000 ................
00000090: 0107 0509 1101 2309 0704 0400 0100 0001 ......#.........
000000a0: 2109 0704 0409 0d01 010b 0b0b 0b08 0804 !...............
000000b0: 0402 0200 0608 0807 0707 0502 0202 0078 ...............x
000000c0: 0808 0707 0705 0202 0200 7008 0807 0707 ..........p.....
000000d0: 0502 0202 0064 0017 101e 1e1a 1901 0300 .....d..........
000000e0: 0e1a 1717 100e 1f01 0e13 141b 1e01 1f1a ................
000000f0: 0012 101f 011b 0c1e 1f01 1f13 1001 0e13 ................
00000100: 141b 001e 1a0e 1610 1f2d 0020 1e10 0116 .........-. ....
00000110: 1024 1e01 1f1a 011a 1b10 1900 0f1a 1a1d .$..............
00000120: 1e2d 0000

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

यदि हम ध्यान से परिणामी आउटपुट की जांच करते हैं, तो हम जल्द ही देखेंगे कि यह कई बार बाइट्स के साथ शुरू होता है। 0b, 04, 00, 0a- वे सभी जोड़ों में दिखाई देते। संपीड़ित मूल को देखते हुए, हम देखेंगे कि ये सभी जोड़े एक शब्दकोश प्रतिस्थापन के कारण उत्पन्न हुए हैं। लेकिन इस प्रक्रिया में, हम तुरंत ध्यान देते हैं कि ये सभी डुप्लिकेट अर्थ डिक्शनरी में प्रविष्टियों के अनुरूप हैं। यही है, अगर हम फिर से शब्दकोश लागू करते हैं, तो डेटा फिर से विस्तारित होगा। शायद हम पर्याप्त नहीं खोल रहे हैं?

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

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

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

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

तो, हम शब्दकोश को दाईं से बाईं ओर लागू करने के लिए पायथन प्रोग्राम की एक पंक्ति में बदलाव कर सकते हैं:

फ़ाइल decompress2.py:

 import struct import sys # Read the compressed data file. data = sys.stdin.read() # Extract the two integers of the four-byte header. tablesize, datasize = struct.unpack('HH', data[0:4]) data = data[4:] # Separate the dictionary table and the compressed data. tablesize *= 3 table = data[0:tablesize] data = data[tablesize:datasize] # Apply the dictionary entries to the data section in reverse order. for n in range(len(table) - 3, -3, -3): key = table[n] val = table[n+1:n+3] data = data.replace(key, val) # Output the expanded result. sys.stdout.write(data) 

यदि हम इस संस्करण की कोशिश करते हैं, तो आउटपुट बहुत बड़ा होगा:

 $ python ./decompress2.py <levels/lesson_1.pak | xxd | less
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100: 0000 0000 0000 0000 0000 0101 0101 0100 ................
00000110: 0101 0101 0100 0000 0000 0000 0000 0000 ................
00000120: 0000 0000 0000 0000 0000 0100 0000 0101 ................
00000130: 0100 0000 0100 0000 0000 0000 0000 0000 ................
00000140: 0000 0000 0000 0000 0000 0100 2300 0125 ............#..%
00000150: 0100 2300 0100 0000 0000 0000 0000 0000 ..#.............
00000160: 0000 0000 0000 0000 0101 0101 011d 0124 ...............$
00000170: 011d 0101 0101 0100 0000 0000 0000 0000 ................
1-24 / 93 (अधिक) 

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

$ python ./decompress2.py <level / lesson_1.pak | xxd -c32 | कम
00000000: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ............................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ............................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ............................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ................................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ................................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ................................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ................................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ................................
00000100: 0000 0000 0000 0000 0000 0101 0101 0100 0101 0101 0100 0000 0000 0000 0000 0000 ................................
00000120: 0000 0000 0000 0000 0000 0100 0000 0101 0100 0000 0100 0000 0000 0000 0000 0000 ................................
00000140: 0000 0000 0000 0000 0000 0100 2300 0125 0100 2300 0100 0000 0000 0000 0000 0000 ............#..%..#.............
00000160: 0000 0000 0000 0000 0101 0101 011d 0124 011d 0101 0101 0100 0000 0000 0000 0000 ...............$................
00000180: 0000 0000 0000 0000 0100 2000 1b00 0000 0000 1a00 2000 0100 0000 0000 0000 0000 .......... ......... ...........
000001a0: 0000 0000 0000 0000 0100 2300 011f 0033 001e 0100 2300 0100 0000 0000 0000 0000 ..........#....3....#...........
000001c0: 0000 0000 0000 0000 0101 0101 0123 0000 0023 0101 0101 0100 0000 0000 0000 0000 .............#...#..............
000001e0: 0000 0000 0000 0000 0100 2300 011f 0000 001e 0100 2300 0100 0000 0000 0000 0000 ..........#.........#...........
00000200: 0000 0000 0000 0000 0100 0000 1a00 0023 0000 1b00 0000 0100 0000 0000 0000 0000 ...............#................
00000220: 0000 0000 0000 0000 0101 0101 0101 1c01 1c01 0101 0101 0100 0000 0000 0000 0000 ................................
00000240: 0000 0000 0000 0000 0000 0000 0100 0001 0000 0100 0000 0000 0000 0000 0000 0000 ................................
00000260: 0000 0000 0000 0000 0000 0000 0100 2301 2300 0100 0000 0000 0000 0000 0000 0000 ..............#.#...............
00000280: 0000 0000 0000 0000 0000 0000 0100 0001 2100 0100 0000 0000 0000 0000 0000 0000 ................!...............
000002a0: 0000 0000 0000 0000 0000 0000 0101 0101 0101 0100 0000 0000 0000 0000 0000 0000 ................................
000002c0: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ................................
000002e0: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 ................................
lines 1-24/47 (more) 

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

xcdएक गैर-मानक उपकरण है, लेकिन आप इसे यहां से डाउनलोड कर सकते हैं । -rउपयोगिता विकल्प पर ध्यान दें less, जो आपको नियंत्रण दृश्यों को साफ़ करने के लिए कहता है।


इसकी तुलना एक प्रशंसक द्वारा तैयार किए गए पहले स्तर के नक्शे से करें:


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

डेटा व्याख्या

मैप छवि के साथ बाइट मानों की तुलना करके, हम यह निर्धारित कर सकते हैं कि 00एक खाली टाइल को 01एन्कोड करता है, एक दीवार को एनकोड करता है, और 23एक चिप को दर्शाता है। 1Aएक लाल दरवाजे को दर्शाता है, 1B- एक नीला दरवाजा, और इसी तरह। हम पूरे स्तर के नक्शे को बनाने वाले चिप्स, कुंजियों, दरवाजों और अन्य सभी टाइलों को सटीक मान दे सकते हैं।

अब हम अगले स्तर पर जा सकते हैं और वहां दिखाई देने वाली वस्तुओं के लिए बाइट मूल्यों को पा सकते हैं। और अगले स्तरों के साथ जारी रखें जब तक कि हमें बाइट मूल्यों और गेम ऑब्जेक्ट्स की पूरी सूची प्राप्त न हो जाए जो वे एनकोड करते हैं।

जैसा कि हमने शुरू में सुझाव दिया था, कार्ड 1024 बाइट्स (ऑफ़सेट पर 000003FF) के ठीक बाद समाप्त होता है ।

इस बार, डंप की पहली 32 लाइनों को हटाने के लिए, हम उपयोग करते हैंsed। चूंकि हमारे पास प्रति पंक्ति 32 बाइट्स हैं, हम पहले 1024 बाइट्स को छोड़ देंगे।


तुरंत बाद नक्शा डेटा 384 बाइट्स के अनुक्रम में चला जाता है (मान श्रेणी में हैं 00000400- 0000057F), लगभग सभी जिनमें से शून्य हैं, लेकिन उन दोनों के बीच वहाँ भी कुछ ग़ैर शून्य मान रहे हैं। इसके बाद एक पूरी तरह से अलग बाइट पैटर्न आता है, इसलिए यह मान लेना तर्कसंगत होगा कि यह 384-बाइट अनुक्रम एक अलग हिस्सा है।

यदि हम कुछ और स्तरों को देखते हैं, तो हम पैटर्न पर जल्दी ध्यान देते हैं। 384-बाइट वाले हिस्से में वास्तव में तीन उप-भाग होते हैं, प्रत्येक 128 बाइट्स लंबे होते हैं। प्रत्येक उपधारा शून्य के बाद कुछ गैर-शून्य बाइट्स के साथ शुरू होती है जो शेष उपधारा भरती हैं।

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

जब हमें पता चला कि इन तीनों उपखंडों के स्तर पर मॉब पर डेटा मौजूद है, तो यह पता लगाना बहुत मुश्किल नहीं होगा कि प्रत्येक उपखंड में क्या निहित है।

पहली 128-बाइट उपधारा बाइट मूल्यों की एक सूची है जो भीड़ के प्रकार को निर्धारित करती है। उदाहरण के लिए, दूसरे स्तर के बफर इस तरह दिखते हैं:

 $ python ./decompress2.py <levels/lesson_2.pak | xxd | less
00000400: 0608 1c1c 0808 0000 0000 0000 0000 0000 ................
00000410: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000420: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000430: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000440: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000450: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000460: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000470: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000480: a870 98a0 6868 0000 0000 0000 0000 0000 .p..hh..........
00000490: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000004a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000004b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000004c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000004d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000004e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000004f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000500: 6060 6060 5868 0000 0000 0000 0000 0000 ````Xh..........
00000510: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000520: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000530: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000540: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000550: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000560: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000570: 0000 0000 0000 0000 0000 0000 0000 ................
लाइनें 64-87 / 93 (अधिक) 

इसकी तुलना एक स्तरीय मानचित्र से करें:


इस स्तर पर, छह मॉब हैं: तीन बग, दो ब्लॉक और एक चिप। पहले 128-बाइट उपकुंजी में एक बाइट 06, तीन बाइट्स 08और दो बाइट्स होते हैं 1C। यह निष्कर्ष निकालना उचित होगा कि 06चिप किसके लिए खड़ा है 08- एक बग, और 1C- एक ब्लॉक।

चिप चार विभिन्न मूल्यों, अर्थात् करने के लिए भेजा जा सकता है: (कार्ड और हमारे शब्दकोश भीड़ में भरने के स्तर से डेटा फ़ाइलों की तुलना करने के जारी रखते हुए, हम जल्दी से इस सिद्धांत में एक दोष लगता है 04, 05, 06या07। नोटेशन के इस सेट में वास्तव में सभी मॉब हैं। जब हम अलग-अलग मूल्यों का ध्यानपूर्वक अध्ययन करते हैं, तो हम अंततः समझेंगे कि मान 0, 1, 2, या 3 बाइट मान में जोड़ा गया है जो कि प्रकार को दर्शाता है, जो भीड़ की प्रारंभिक दिशा को दर्शाता है: उत्तर, पूर्व, दक्षिण, या पश्चिम। उदाहरण के लिए, एक बाइट मान 06एक चिप को दक्षिण की ओर दर्शाता है।)

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

इस हिस्से से निपटने के बाद, अब हम देख सकते हैं कि कितने डेटा फ़ाइलों के बाद केवल कुछ बाइट्स बचे हैं:

नोट किxxdविकल्प के लिए एक -sहेक्साडेसिमल मान स्वीकार करता है ।

स्तरों में एफ के लिए $ / *; do python ./decompress2.py <$ f | xxd -s 0x580 | sed -n 1p; हो गया | कम
00000580: 9001 0c17 1701 1120 1717 00 ....... ...
00000580: 0000 0c17 1b13 0c0d 101f 011e 1a20 1b00 ......... ।।
00000580: f401 0c18 1e1f 101d 0f0c 1800 ............
00000580: 2c01 0c1b 0c1d 1f18 1019 1f00, ...........
00000580: 9001 0c1d 0e1f 140e 1117 1a22 00 ............ "
00000580: 2c01 0d0c 1717 1e01 1a01 1114 1d10 00, ..............
00000580: 2c01 0d10 220c 1d10 011a 1101 0d20 1200, ... "........ ।।
00000580: 5802 0d17 1419 1600 X ......।
00000580: 0000 0d17 1a0d 0f0c 190e 1000 ............
00000580: f401 0d17 1a0d 1910 1f00 ..........
00000580: f401 0d17 1a0e 1601 110c 0e1f 1a1d 2400 .............. $।
00000580: ee02 0d17 1a0e 1601 0d20 1e1f 101d 0114 ......... ......
00000580: 5802 0d17 1a0e 1601 1901 1d1a 1717 00 X..............
00000580: 5e01 0d17 1a0e 1601 1a20 1f00 ^........ ..
00000580: c201 0d17 1a0e 1601 0d20 1e1f 101d 00 ......... .....
00000580: 2c01 0d1a 2019 0e10 010e 141f 2400 ,... .......$.
00000580: 5000 0d1d 201e 1311 141d 1000 P... .......
00000580: e703 0e0c 1610 0122 0c17 1600 ......."....
00000580: 5802 0e0c 1e1f 1710 0118 1a0c 1f00 X.............
00000580: 8f01 0e0c 1f0c 0e1a 180d 1e00 ............
00000580: 0000 0e10 1717 0d17 1a0e 1610 0f00 1b1d ................
00000580: 2c01 0e13 0e13 0e13 141b 1e00 ,...........
00000580: 8f01 0e13 1417 1710 1d00 ..........
00000580: bc02 0e13 141b 1814 1910 00 ...........
lines 1-24/148 (more) 

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

कमांड odमूल ऑफसेट पर जाने के -jबजाय इसका उपयोग करता है -s। यह कमांड को ध्यान देने योग्य भी है printf: स्वरूपण प्रदान करने के अलावा, यह अंत में लटकने वाली एक नई रेखा के बिना पाठ प्रदर्शित करने का एक सुविधाजनक तरीका है।

स्तरों में एफ के लिए $ / *; प्रिंटफ "% -20s" $ f; python ./decompress2.py <$ f | od -n -j 0x580 -tuS -N2; हो गया | कम
स्तर / all_full.pak 400
स्तर / वर्णमाला। फलक ०
स्तर / amsterda.pak 500
स्तर / जोड़.पाक 300
स्तर / arcticfl.pak 400
स्तर / बॉल_ओ__पाक ३००
स्तर / beware_o.pak 300
स्तर / ब्लिंक .pak 600
स्तर / blobdanc.pak 0
स्तर / blobnet.pak 500
स्तरों / block_fa.pak 500
स्तरों / block_ii.pak 750
स्तरों / block_n_.pak 600
स्तर / block_ou.pak 350
स्तर / ब्लॉक.पाक 450
स्तर / बाउंस_इंक 300
स्तर / brushfir.pak 80
स्तर / cake_wal.pak 999
स्तर / महल_m.pak 600
स्तर / कैटाकोम्ब.पाक 399
स्तर / सेलब्लाक.पाक ०
स्तर / chchchip.pak 300
स्तर / चिलर। pak 399
स्तर / चिपमाइन .pak 700
1-24 / 148 (अधिक) 

यदि हम फिर से सूची की ओर मुड़ते हैं, तो मूल रूप से उस डेटा से बनाया जाता है जिसे हमने फ़ाइलों में खोजने की उम्मीद की थी, तो हम महसूस करेंगे कि यह संख्या स्तर को पूरा करने का समय है (यदि मूल्य शून्य है, तो स्तर पर कोई समय सीमा नहीं है)।

इन दो बाइट्स के बाद, डेटा अधिक अस्थिर हो जाता है। तथ्य यह है कि अधिकांश स्तरों के लिए फ़ाइल में लगभग दस बाइट्स शेष हैं, गंभीरता से उनकी सामग्री को सीमित करता है:

$ python ./decompress2.py <level / all_full.pak | xxd -s 0x0582
00000582: 0c17 1701 1120 1717 00 ..... ..... 

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

00	पंक्ति का अंत
01	अंतरिक्ष बार
02 - 0B	अंक 0-9
0C - 25	अक्षर AZ
26 - 30	विराम चिह्न

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

उसके बाद, हम सभी फाइलों के अंत में पहुंच गए। अब हमारे पास इन स्तरों की योजना का पूर्ण विवरण है। हमारा काम पूरा हो गया है।

अधूरा कारोबार

एक चौकस पाठक यह नोटिस कर सकता है कि शुरू में हमें इन फाइलों में दो और तत्व मिलने की उम्मीद थी जो हमें कभी नहीं मिले। हम दोनों की अनुपस्थिति की व्याख्या करेंगे:

पहला तत्व चिप्स की संख्या है, अर्थात। चिप कनेक्टर के माध्यम से पारित करने के लिए एक खिलाड़ी को कुल कितनी चिप्स एकत्रित करनी चाहिए। जैसा कि हमने शुरू में कहा था, अक्सर यह एक स्तर पर चिप्स की कुल संख्या के बराबर होता है, लेकिन ऐसा हमेशा नहीं होता है। इसलिए, यह डेटा किसी तरह प्राप्त किया जाना चाहिए। उत्तर उन स्तरों के कार्डों का अध्ययन करके पाया जा सकता है जिन पर अतिरिक्त चिप्स हैं। यह पता चलता है कि चिप्स को इंगित करने के लिए दो अलग-अलग मूल्यों का उपयोग किया जाता है। मूल्य 23हमें शुरू में मिला, लेकिन मूल्य का भी उपयोग किया जाता है।31एक चिप को इंगित करना जो चिप कनेक्टर को खोलने के लिए आवश्यक कुल राशि को प्रभावित नहीं करता है। (हालांकि, गेमप्ले के दृष्टिकोण से, दोनों प्रकार के चिप्स समान हैं। यदि 31स्तर पर एक प्रकार की चिप है, तो स्तर पर आप किसी भी संख्या में चिप्स एकत्र नहीं कर सकते हैं।)

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

अंतभाषण

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

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

एक महान उपयोगिता trडेटा फ़ाइलों के अपने चरित्र सेट को ASCII में बदलना आसान बनाती है।

$ tr '\ 001- \ 045' '0-9A-Z' <level / lesson_1.pak | XXD
00000000: 4600 cb00 3000 0032 3030 3332 3235 3333 F ... 0..200322533
00000010: 3635 3537 0020 3820 2039 3636 4238 3846 6557. 8 966B88F
00000020: 0058 4a37 354d 3000 5737 4226 3746 2739 .XJ75M0.W7B और IF'9
00000030: 3928 3533 2953 2027 2733 3042 2057 3532 9 (53) एस '' 30 बी W52
00000040: 3730 3738 304a 3226 375a 2046 4a30 5752 70780J2 और 7Z FJWRR
00000050: 2059 2052 4220 3537 0055 0050 3200 4f00 Y RB 57.U.P2.O।
00000060: 554a 2637 5400 3300 2946 4a57 5830 4642 UJ & 7T.3।) FJWX0FB
00000070: 2035 2637 544d 2946 4a37 4d4f 3058 3050 5 और 7TM) FJ7MO0X0P
00000080: 304a 5720 5120 5142 3835 3237 3020 3020 0JW Q QB8527070
00000090: 2826 2058 4a33 3730 2056 4a33 5738 2727 (& XJ370 VJ3W8''
000000a0: 3933 3200 3439 3628 324d 7839 3628 324d 932.496(2Mx96(2M
000000b0: 7039 3628 324d 6400 4c45 5353 4f4e 2031 p96(2Md.LESSON 1
000000c0: 0043 4f4c 4c45 4354 2043 4849 5029 544f .COLLECT CHIP)TO
000000d0: 0047 4554 2050 4153 5420 5448 4520 4348 .GET PAST THE CH
000000e0: 4950 0053 4f43 4b45 542d 0055 5345 204b IP.SOCKET-.USE K
000000f0: 4559 2954 4f20 4f50 454e 0044 4f4f 5253 EY)TO OPEN.DOORS
00000100: 2d30 -0 

उदाहरण के लिए, मदद पाठ में दो स्थान होते हैं जहां S और अनुक्रम का क्रम सही कोष्ठक द्वारा प्रतिस्थापित किया जाता है। इन विसंगतियों ने मुझे संपीड़न की उपस्थिति की गणना करने और इसकी प्रकृति के बारे में कुछ जानकारी प्राप्त करने के लिए पर्याप्त सबूत दिए। बाद में मैंने डेटा फ़ाइलों की शुरुआत के करीब उनकी घटनाओं के साथ असामान्य बाइट मूल्यों को जोड़ा। (उदाहरण के लिए, हेक्साडेसिमल ऑफ़सेट डंप में ऊपर दिखाया गया 00000035एक सही ब्रैकेट है, उसके बाद एक राजधानी एस और एक स्पेस है।) इसमें से, मैंने कंप्रेशन स्कीम की गणना लेख में वर्णित प्रक्रिया के समान की। बाकी सब कुछ बहुत सरल था।

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