फज़िंग

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

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

इतिहास
फ़ज़ शब्द की उत्पत्ति 1988 के पतन वर्ग की परियोजना से हुई थी स्नातक उन्नत ऑपरेटिंग सिस्टम वर्ग (CS736) में, विस्कॉन्सिन विश्वविद्यालय में प्रोफेसर बार्टन मिलर द्वारा पढ़ाया गया था, जिसके परिणाम बाद में 1990 में प्रकाशित हुए थे। यूटिलिटी के लिए स्वचालित रूप से यादृच्छिक इनपुट और कमांड-लाइन पैरामीटर उत्पन्न करने के लिए एक यूनिक्स उपयोगिता का परीक्षण करने के लिए होता है। प्रोजेक्ट को यूनिक्स कमांड लाइन कार्यक्रमों की विश्वसनीयता का परीक्षण करने के लिए डिज़ाइन किया गया था जब तक कि वे दुर्घटनाग्रस्त होने तक त्वरित उत्तराधिकार में बड़ी संख्या में यादृच्छिक इनपुट निष्पादित कर सकते है। मिलर की टीम 25 से 33 प्रतिशत उपयोगिताओं को क्रैश करने में सक्षम थी, जिनका उन्होंने परीक्षण किया था। फिर उन्होंने कारण निर्धारित करने के लिए प्रत्येक क्रैश को डिबग किया था और प्रत्येक ज्ञात विफलता को वर्गीकृत किया था। अन्य शोधकर्ताओं को अन्य सॉफ्टवेयर के साथ समान प्रयोग करने की अनुमति देने के लिए, उपकरणों के स्रोत कोड, परीक्षण प्रक्रियाओं और कच्चे परिणाम डेटा को सार्वजनिक रूप से उपलब्ध कराया गया था। इस प्रारंभिक फ़ज़िंग को अब ब्लैक बॉक्स, जेनरेशनल, अनस्ट्रक्चर्ड (डंब) फ़ज़िंग कहा जाता है।

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

मूल फज़ परियोजना ने 1995, 2000, 2006 और हाल ही में 2020 में योगदान दिया:
 * 1995: फ़ज़ रिविज़िटेड पेपर में चार भाग होते है।
 * यूनिक्स सिस्टम की व्यापक विविधता और अधिक उपयोगिताओं सहित मूल कमांड लाइन अध्ययन को पुन: प्रस्तुत किया। अध्ययन से पता चला कि, अगर कुछ भी, विश्वसनीयता खराब हो गई थी। यह पहला अध्ययन था जिसमें ओपन सोर्स जीएनयू और लिनक्स उपयोगिताओं को शामिल किया गया था, जो दिलचस्प रूप से वाणिज्यिक यूनिक्स सिस्टम की तुलना में काफी अधिक विश्वसनीय थे।
 * एक्स-विंडोज़ के तहत जीयूआई (विंडो आधारित) अनुप्रयोगों के फ़ज़ परीक्षण का परिचय दिया। इस अध्ययन में असंरचित और संरचित (माउस और कीबोर्ड घटनाओं के मान्य अनुक्रम) इनपुट डेटा दोनों का उपयोग किया गया। वे X-Windows अनुप्रयोगों के 25% को क्रैश करने में सक्षम थे। इसके अलावा, उन्होंने एक्स-विंडोज सर्वर का परीक्षण किया और दिखाया कि यह क्रैश के लिए लचीला था।
 * संरचित परीक्षण इनपुट के आधार पर फिर से नेटवर्क सेवाओं की फ़ज़ परीक्षण की शुरुआत की। इनमें से कोई भी सेवा दुर्घटनाग्रस्त नहीं हुई थी।
 * सिस्टम लाइब्रेरी कॉल रिटर्न वैल्यू के यादृच्छिक परीक्षण का परिचय दिया, विशेष रूप से फ़ंक्शन के मॉलोक परिवार से यादृच्छिक रूप से शून्य लौटा रहा है। लगभग आधे मानक यूनिक्स प्रोग्राम ऐसे वापसी मूल्यों की ठीक से जाँच करने में विफल रहे।
 * 2000: हाल ही में जारी किए गए विंडोज एनटी ऑपरेटिंग सिस्टम के लिए एप्लाइड फज़ परीक्षण, Win32 विंडो सिस्टम के तहत चलने वाले अनुप्रयोगों का परीक्षण। वे 21% अनुप्रयोगों को क्रैश करने में सक्षम थे और परीक्षण किए गए अतिरिक्त 24% को लटका दिया। फिर से, अनुप्रयोग असंरचित और संरचित (वैध कीबोर्ड और माउस ईवेंट) इनपुट दोनों के साथ परीक्षण कर रहे थे, उन अनुप्रयोगों में से लगभग आधे को क्रैश कर दिया, जिनका उन्होंने परीक्षण किया था। उन्होंने विफलताओं के कारणों की पहचान की और उन्हें पिछले अध्ययनों के समान पाया।
 * 2001: दो लोकप्रिय यूनिक्स वेरिएंट्स, एक GNU/Linux प्लेटफॉर्म और एक सोलारिस प्लेटफॉर्म के तहत 87 यूनिक्स उपयोगिताओं के लिए फ़ज़ परीक्षण लागू किया गया, जो SunOS 1990 पर 29% दुर्घटनाग्रस्त हो गया, लेकिन परीक्षण किए गए रेड हैट 6.2 पर केवल 4%। सबसे आम विफलता मोड पॉइंटर अंकगणितीय था, इसके बाद रिटर्न कोड की जांच नहीं की गई और पुराने (खतरनाक) इनपुट फ़ंक्शंस का उपयोग किया गया।
 * 2006: कमांड लाइन और विंडो आधारित अनुप्रयोगों दोनों के लिए Mac OS X पर एप्लाइड फ़ज़ परीक्षण। उन्होंने 135 कमांड लाइन उपयोगिता कार्यक्रमों का परीक्षण किया, जिनमें से 7% परीक्षण किए गए। इसके अलावा, उन्होंने MacOS Aqua (उपयोगकर्ता इंटरफ़ेस) विंडो सिस्टम के अंतर्गत चलने वाले 30 अनुप्रयोगों का परीक्षण किया, जिनमें से 73% परीक्षण किए गए।
 * 2020: हाल ही में, उन्होंने यह देखने के लिए कि क्या मूल तकनीकें अभी भी प्रासंगिक थीं और क्या वर्तमान उपयोगिता कार्यक्रम इस प्रकार के परीक्षण के लिए प्रतिरोधी थे, क्लासिक जेनरेशनल, ब्लैक बॉक्स, वर्तमान यूनिक्स सिस्टम, विशेष रूप से Linux, FreeBSD और MacOS पर असंरचित परीक्षण लागू किया। उन्होंने प्रत्येक प्लेटफॉर्म पर लगभग 75 उपयोगिताओं का परीक्षण किया, लिनक्स पर 12% की विफलता दर, मैकओएस पर 16% और फ्रीबीएसडी पर 19%। (ध्यान दें कि ये विफलता दर समान प्रणालियों के पिछले परीक्षण के परिणामों से भी बदतर थे।) जब उन्होंने प्रत्येक विफलता का विश्लेषण किया और उन्हें वर्गीकृत किया, तो उन्होंने पाया कि विफलताओं की क्लासिक श्रेणियां, जैसे सूचक और सरणी त्रुटियां और रिटर्न कोड की जांच नहीं करना, नए परिणामों में मोटे तौर पर अभी भी मौजूद थे। इसके अलावा, नई विफलता जटिल प्रोग्राम स्थिति और एल्गोरिदम से उत्पन्न होती है जो इनपुट आकार या जटिलता के साथ स्केल नहीं करती थी। उन्होंने हाल ही में रस्ट में लिखी गई यूनिक्स उपयोगिताओं का भी परीक्षण किया और पाया कि वे C में लिखी गई समान विश्वसनीयता की थीं, हालांकि (उम्मीद के मुताबिक) स्मृति त्रुटियों की संभावना कम थी।

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

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

अप्रैल 2015 में, हन्नो बॉक ने दिखाया कि कैसे फजर एएफएल 2014 हार्टब्लीड भेद्यता को ढूंढ सकता था। (अप्रैल 2014 में हार्दिक भेद्यता का खुलासा किया गया था। यह एक गंभीर भेद्यता है जो विरोधियों को अन्यथा एन्क्रिप्टेड संचार को समझने की अनुमति देती है। भेद्यता को गलती से ओपनएसएसएल में पेश किया गया था जो परिवहन परत सुरक्षा को लागू करता है और इंटरनेट पर अधिकांश सर्वरों द्वारा उपयोग किया जाता है। शोडान (वेबसाइट) ने अप्रैल 2016 में 238,000 मशीनों के अभी भी असुरक्षित होने की सूचना दी; जनवरी 2017 में 200,000। )

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

सितंबर 2016 में, Microsoft ने प्रोजेक्ट स्प्रिंगफील्ड की घोषणा की, जो सॉफ्टवेयर में सुरक्षा संबंधी महत्वपूर्ण बग खोजने के लिए क्लाउड-आधारित फ़ज़ परीक्षण सेवा है।

दिसंबर 2016 में, Google ने OSS-Fuzz की घोषणा की जो कई सुरक्षा-महत्वपूर्ण ओपन-सोर्स परियोजनाओं की निरंतर फ़ज़िंग की अनुमति देता है।

ब्लैक हैट 2018 में, क्रिस्टोफर डोमस ने एक प्रोसेसर में एक छिपे हुए कम किए गए निर्देश सेट कंप्यूटर कोर के अस्तित्व को उजागर करने के लिए फ़ज़िंग के उपयोग का प्रदर्शन किया। यह कोर रिंग 3 से सुरक्षा रिंग कमांड को निष्पादित करने के लिए मौजूदा सुरक्षा जांच को बायपास करने में सक्षम था।

सितंबर 2020 में, माइक्रोसॉफ्ट ने वनफज जारी किया, जो एक सेल्फ-होस्टिंग (वेब ​​सर्विसेज) | सेल्फ-होस्टेड फ़ज़िंग-एज़-ए-सर्विस प्लेटफ़ॉर्म है जो सॉफ्टवेयर बग का पता लगाने को स्वचालित करता है। यह खिड़कियाँ और लिनक्स को सपोर्ट करता है।

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

रैंडम इनपुट के निष्पादन को यादृच्छिक परीक्षण या बंदर परीक्षण भी कहा जाता है।

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

1983 में, Apple में स्टीव कैप्स ने द मंकी को विकसित किया, एक उपकरण जो मैकपेंट जैसे क्लासिक मैक ओएस अनुप्रयोगों के लिए यादृच्छिक इनपुट उत्पन्न करेगा। आलंकारिक बंदर अनंत बंदर प्रमेय को संदर्भित करता है जिसमें कहा गया है कि एक बंदर एक टाइपराइटर कीबोर्ड पर यादृच्छिक रूप से असीमित समय के लिए चाबियों को मारता है, अंततः शेक्सपियर के पूरे कार्यों को टाइप करेगा। परीक्षण के मामले में, बंदर इनपुट के विशेष अनुक्रम को लिखेंगे जो दुर्घटना को ट्रिगर करेगा।

1991 में, क्रैशमे टूल जारी किया गया था, जिसका उद्देश्य बेतरतीब ढंग से चुने गए मापदंडों के साथ सिस्टम कॉल को बेतरतीब ढंग से निष्पादित करके यूनिक्स और यूनिक्स जैसी ऑपरेटिंग सिस्टम की मजबूती का परीक्षण करना था।

प्रकार
एक फजर को कई तरह से वर्गीकृत किया जा सकता है: # एक फ़ज़र जनरेशन-आधारित या म्यूटेशन-आधारित हो सकता है, जो इस बात पर निर्भर करता है कि इनपुट स्क्रैच से उत्पन्न हुए है या मौजूदा इनपुट को संशोधित करके।
 * 1) एक फजर गूंगा (असंरचित) या स्मार्ट (संरचित) हो सकता है, यह इस बात पर निर्भर करता है कि वह इनपुट संरचना से अवगत है या नहीं।
 * 2) एक फ़ज़र सफ़ेद-, ग्रे- या ब्लैक-बॉक्स हो सकता है, यह इस बात पर निर्भर करता है कि वह प्रोग्राम संरचना से अवगत है या नहीं।

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

कुछ फ़ज़र्स में स्क्रैच से इनपुट उत्पन्न करने और मौजूदा बीजों के उत्परिवर्तन द्वारा इनपुट उत्पन्न करने के लिए दोनों करने की क्षमता होती है।

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

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

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

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

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

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

एक ग्रे-बॉक्स परीक्षण|ग्रे-बॉक्स फ़ज़र कार्यक्रम के बारे में जानकारी इकट्ठा करने के लिए प्रोग्राम विश्लेषण के बजाय इंस्ट्रूमेंटेशन (कंप्यूटर प्रोग्रामिंग) का लाभ उठाता है। उदाहरण के लिए, AFL और libFuzzer एक इनपुट द्वारा प्रयोग किए जाने वाले बुनियादी ब्लॉक संक्रमणों का पता लगाने के लिए हल्के इंस्ट्रूमेंटेशन का उपयोग करते है। यह एक उचित प्रदर्शन ओवरहेड की ओर जाता है, लेकिन फ़ज़िंग के दौरान कोड कवरेज में वृद्धि के बारे में फ़ज़र को सूचित करता है, जो ग्रे-बॉक्स फ़ज़र्स को बेहद कुशल भेद्यता का पता लगाने वाला उपकरण बनाता है।

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

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

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

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

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

ब्राउज़र सुरक्षा
आधुनिक वेब ब्राउज़र व्यापक फ़ज़िंग से गुजरते है। Google Chrome का क्रोमियम (वेब ​​​​ब्राउज़र) कोड क्रोम सुरक्षा टीम द्वारा 15,000 कोर के साथ लगातार फ़ज़ किया जाता है। Microsoft Edge और Internet Explorer के लिए, Microsoft ने उत्पाद विकास के दौरान 670 मशीन-वर्षों के साथ फ़ज़्ड परीक्षण किया, जिससे 1 बिलियन HTML फ़ाइलों से 400 बिलियन से अधिक DOM मैनिपुलेशन उत्पन्न हुए।

टूलचैन
एक फ़ज़र अपेक्षाकृत कम समय में बड़ी संख्या में इनपुट उत्पन्न करता है। उदाहरण के लिए, 2016 में Google OSS-fuzz प्रोजेक्ट ने एक सप्ताह में लगभग 4 ट्रिलियन (छोटा पैमाना) इनपुट का उत्पादन किया। इसलिए, कई फ़ज़र्स एक toolchain प्रदान करते है जो अन्यथा मैन्युअल और थकाऊ कार्यों को स्वचालित करता है जो विफलता-उत्प्रेरण इनपुट की स्वचालित पीढ़ी का पालन करते है।

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

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

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

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

यह भी देखें

 * अमेरिकन फ़ज़ी लोप (फ़ज़र)
 * शंक्वाकार परीक्षण
 * [[गड़बड़]]
 * गड़बड़
 * बंदर परीक्षण
 * यादृच्छिक परीक्षण
 * जिम्मेदार प्रकटीकरण
 * रनटाइम त्रुटि का पता लगाना
 * सुरक्षा परीक्षण
 * धुआँ परीक्षण (सॉफ्टवेयर)
 * प्रतीकात्मक निष्पादन
 * सिस्टम परीक्षण
 * परीक्षण स्वचालन

अग्रिम पठन

 * A free, online, introductory textbook on fuzzing.
 * Ari Takanen, Jared D. DeMott, Charles Miller, Fuzzing for Software Security Testing and Quality Assurance, 2008, ISBN 978-1-59693-214-2
 * Michael Sutton, Adam Greene, and Pedram Amini. Fuzzing: Brute Force Vulnerability Discovery, 2007, ISBN 0-321-44611-9.
 * H. Pohl, Cost-Effective Identification of Zero-Day Vulnerabilities with the Aid of Threat Modeling and Fuzzing, 2011
 * Fabien Duchene, Detection of Web Vulnerabilities via Model Inference assisted Evolutionary Fuzzing, 2014, PhD Thesis
 * Bratus, S., Darley, T., Locasto, M., Patterson, M.L., Shapiro, R.B., Shubina, A., Beyond Planted Bugs in "Trusting Trust": The Input-Processing Frontier, IEEE Security & Privacy Vol 12, Issue 1, (Jan-Feb 2014), pp. 83–87—Basically highlights why fuzzing works so well: because the input is the controlling program of the interpreter.

बाहरी संबंध

 * Fuzzing Project, includes tutorials, a list of security-critical open-source projects, and other resources.
 * University of Wisconsin Fuzz Testing (the original fuzz project) Source of papers and fuzz software.
 * Designing Inputs That Make Software Fail, conference video including fuzzy testing
 * Building 'Protocol Aware' Fuzzing Frameworks