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

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

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

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

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

रिफैक्टरिंग

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

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

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

नया संस्करण तेज, अधिक कॉम्पैक्ट, क्लीनर और आसान है। यह INI इनपुट के संबंध में अधिक लचीला है, इसलिए इसका उपयोग करना आसान है। लेकिन क्या यह वास्तव में सही है?

fuzzing

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

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

यह मानते हुए कि आपके पास आवश्यक उपकरण स्थापित हैं (मेक, जीसीसी, एफएल), यहां बताया गया है कि बिनिट्यूल्स फ़ज़िंग कैसे शुरू होता है:

 $ make CC=afl-gcc $ mkdir in out $ echo '[x]' > in/empty $ afl-fuzz -i in -o out -- ./bini 

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



इस उदाहरण में, मैंने डिफ़ॉल्ट कंपाइलर को afl ( CC=afl-gcc ) के लिए GCC शेल में बदल दिया। यहाँ afl पृष्ठभूमि में GCC कहता है, लेकिन यह बाइनरी में अपना टूलकिट जोड़ता है। जब फ़ज़िंग, afl-fuzz इस टूलकिट का उपयोग किसी प्रोग्राम के निष्पादन पथ की निगरानी के लिए करता है। एफएल प्रलेखन तकनीकी विवरण की व्याख्या करता है।

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

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

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

एक परीक्षण सूट बनाएँ

जैसे ही मैंने फ़ज़र द्वारा पता की गई सभी त्रुटियों को ठीक किया और सभी सीमा स्थितियों में पार्सर को समायोजित किया, मैंने फ़ज़र डेटा पैकेज से परीक्षणों का एक सेट बनाया - हालांकि सीधे नहीं।

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

दूसरे, इन इनपुटों में से कई अपने अद्वितीय निष्पादन पथ को लागू करने की आवश्यकता से अधिक लंबे थे। afl-tmin , एक परीक्षण मामले का न्यूनतम, afl-tmin परीक्षण के मामले को कम कर दिया, afl-tmin मदद की।

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

• वैध इनपुट
  
• अमान्य इनपुट

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

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