एक बग का इतिहास या मैं कैसे पासवर्ड को ज़िप करता हूं

यह व्यक्तिगत अनुभव की कहानी है, किसी और, पुराने, असमर्थित कोड में बग ढूंढने का अनुभव।

यह सब हमेशा की तरह शुरू हो गया, मेरे सामने पहली नज़र में एक सरल काम था: सी फ़ोल्डर / क्यूटी में एक विशिष्ट पासवर्ड के साथ एक ज़िप संग्रह में वर्तमान फ़ोल्डर में फ़ाइलों को पैक करने के लिए, ऐसा लगेगा कि यह आसान हो सकता है?

स्वाभाविक रूप से, पहला सहायक Google है , और उन्होंने सुझाव दिया कि ज़िप अभिलेखागार के साथ काम करने के लिए दो क्यूटी पुस्तकालय हैं:

QuaZIP और OSDab ZIP , अन्य बातों के अलावा, Qt स्वयं पैकेजिंग के लिए qCompress और qDecompress विधियों का समर्थन करता है।

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

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





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



आरंभ करने के लिए, मैंने कोड, कोड पर टिप्पणियों और लेखक के बारे में जानकारी का अध्ययन किया। मुझे पता चला कि QuaZIP क्लासेस अपने आप में शुद्ध C. में लिखी गई MiniZip लाइब्रेरी के ऊपर एक Qt आवरण है। जल्दी से यह सुनिश्चित करना कि QuaZIP रैपर अप्रासंगिक है, मैंने MiniZip कोड का अध्ययन करना शुरू कर दिया। पहली नज़र में, सब कुछ पूरी तरह से काम करता था। और इसलिए मैंने Google पर सवाल पूछने का फैसला किया, साथ ही इस बहुत ही पुस्तकालय के डेवलपर की वेबसाइट पर भी। वहाँ मुझे एक ही सवाल के साथ दो अप्राप्य बग रिपोर्ट मिलीं जो 2007 से उठीं।



को दबाकर।



इसके अलावा, मैंने समस्या का अध्ययन करने के बारे में निर्धारित किया है। पहली फ़ाइल जिस पर संदेह गिर गया था, निश्चित रूप से, एक crypt.h फ़ाइल थी, जिसमें एन्क्रिप्शन एल्गोरिथम को ही लागू किया गया था।

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



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

तस्वीर बहुत दिलचस्प निकली, यहाँ यह है:





एन्क्रिप्टेड ज़िप फ़ाइल में एक काफी सरल संरचना है:

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

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

फाइल सेक्शन इस तरह से बनाया गया है:

[स्थानीय फ़ाइल शीर्ष लेख 1]

[12 बाइट्स एन्क्रिप्ट हेडर 1]

[फ़ाइल डेटा 1]

[डेटा विवरणक 1]

।

।

।

[स्थानीय फ़ाइल हेडर n]

[12 बाइट्स एनक्रिप्ट हेडर n]

[फ़ाइल डेटा एन]

[डेटा विवरणक n]

स्थानीय फ़ाइल शीर्षक को देखना दिलचस्प है:

स्थानीय फ़ाइल हेडर हस्ताक्षर 4 बाइट्स (0x04034b50)

2 बाइट्स निकालने के लिए आवश्यक संस्करण

सामान्य प्रयोजन बिट फ्लैग 2 बाइट्स

संपीड़न विधि 2 बाइट्स

अंतिम मॉड फ़ाइल समय 2 बाइट्स

अंतिम मॉड फ़ाइल दिनांक 2 बाइट्स

crc-32 4 बाइट्स

संकुचित आकार 4 बाइट्स

असम्पीडित आकार 4 बाइट्स

फ़ाइल का नाम लंबाई 2 बाइट्स

अतिरिक्त फ़ील्ड की लंबाई 2 बाइट्स

फ़ाइल नाम (चर आकार)

अतिरिक्त क्षेत्र (चर आकार)

यह भी ध्यान दिया जाना चाहिए कि कोई भी हेडर ब्लॉक 4 "मैजिक" बाइट्स "पीके .." से शुरू होता है, जहां अंतिम दो बाइट्स बदलते हैं जिसके आधार पर ब्लॉक शुरू हुआ।



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



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



परिणामस्वरूप, हेडर फ़ील्ड्स और अन्य सहायक सूचनाओं के संबंध में फाइलें हर चीज में बिल्कुल समान हो गई हैं।



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



स्ट्रिंग की जगह

c = (rand() >> 7) & 0xff;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

crypt.h फ़ाइल में और दोनों कार्यक्रमों में, मुझे एक ही तरह से बनाए गए दो नए अभिलेख प्राप्त हुए और ओकटेटा में उनकी जांच करना शुरू किया







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

हम crypt.h की सामग्री को देखते हैं और देखते हैं कि अंतिम दो बाइट्स एक विशेष crcForCrypting कुंजी का उपयोग करके विशेष तरीके से उत्पन्न होते हैं।

  buf[n++] = zencode(pkeys, pcrc_32_tab, (int)(crcForCrypting >> 16) & 0xff, t); buf[n++] = zencode(pkeys, pcrc_32_tab, (int)(crcForCrypting >> 24) & 0xff, t);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ठीक है, दोनों कार्यक्रमों में हार्डकोडेड ccForCrypting को प्रतिस्थापित करते हुए, मैंने देखा कि फाइलें एक ही थीं (!) , अर्थात, वे बिल्कुल वैसी ही थीं, जैसे कि वह एक ही फाइल हो।

यह महसूस करने के बाद कि सच्चाई कहीं आस-पास है, मैंने अध्ययन करने का फैसला किया कि crcForCrypting चर का मूल्य कैसे प्राप्त किया जाता है ? और मुझे पता चला कि Info-ZIP में यह वेरिएबल फ़ाइल क्रिएशन टाइम की 16-बिट लेफ्ट शिफ्ट द्वारा प्राप्त किया गया है, जबकि MiniZIP में यह वेरिएबल हमेशा शून्य निकला।



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



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

फिलहाल, कोई QuaZIP अपडेट नहीं है, मैं वर्तमान संस्करण के लिए पैच के साथ लेख में अंतर लागू करता हूं।