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

## क्यों

हाँ, एक और फज़र और वह भी जो वर्तमान रुझानों और परंपराओं के साथ अच्छी तरह से मेल नहीं खाता। कुछ आवश्यकताओं को पूरा करने के लिए समझौते किए गए। ये आवश्यकताएँ एक ऐसा फज़र हैं जो डिफ़ॉल्ट रूप से कई प्लेटफार्मों पर काम करता है, स्थानीय और नेटवर्क दोनों लक्ष्यों को फ़ज़ करता है और उपयोग करने में बहुत आसान है। किसी को कुछ भी समझाने की कोशिश नहीं कर रहे हैं, लेकिन कुछ संदर्भ प्रदान करते हैं। कुछ लक्ष्यों को AFL जैसे फ़ज़र्स को बिल्ड चेन में एकीकृत करने के लिए बहुत प्रयास की आवश्यकता होती है। यह कोई समस्या नहीं है क्योंकि यह फज़र इंस्ट्रूमेंटेशन की आवश्यकता नहीं रखता, आसानी और पोर्टेबिलिटी के लिए इंस्ट्रूमेंटेशन द्वारा प्राप्त सटीक कवरेज का त्याग करता है। AFL भी बॉक्स के बाहर नेटवर्क फज़िंग का समर्थन नहीं करता, और जबकि इस पर आधारित प्रोजेक्ट मौजूद हैं जो करते हैं, वे उपयोग करने में सरल नहीं हैं और आमतौर पर काम करने के लिए अधिक कोड संशोधन और हार्नेस की आवश्यकता होती है ([Libfuzzer](https://llvm.org/docs/LibFuzzer.html) के साथ भी ऐसी ही कहानी)।

यह समानांतर फज़िंग नहीं करता, न ही [persistent mode](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html) जैसी तेज़ गति सुधारों का समर्थन करता है, इसलिए यह ऐसी क्षमताओं वाले फ़ज़र्स के करीब भी स्केल नहीं कर सकता। फिर से, यह कोई अत्याधुनिक फ़ज़र नहीं है। लेकिन इसे स्रोत कोड, ठीक से सेटअप बिल्ड या विशिष्ट OS सुविधाओं की आवश्यकता नहीं है। यह कुछ नेटवर्क क्लाइंट GUI और इंटरैक्टिव ऐप्स को भी फ़ज़ कर सकता है। यह कई मायनों में अपने संसाधनों का उपयोग करता है और म्यूटेटर और न्यूनीकरण जैसी कई सुविधाएँ शुरू से लिखी गई थीं।

इसे "बस काम करने" के लिए डिज़ाइन किया गया था और इसके लिए आवश्यक कुछ निर्भरताओं के लिए सेटअप और स्थापना को स्वचालित करने में प्रयास किया गया है। यह फ़ज़र एक उद्देश्य की पूर्ति के लिए लिखा गया था, विभिन्न लक्ष्य परिदृश्यों और वातावरणों में मूल्य प्रदान करने के लिए और सबसे महत्वपूर्ण रूप से जिसके लिए सभी फ़ज़र्स का अंततः मूल्यांकन किया जाना चाहिए: बग खोजने की क्षमता। और यह **बग खोजता है** ([trophies](https://github.com/sec-tools/beta/blob/main/README.md#trophies))। यह यह नहीं मानता कि लक्ष्य स्रोत कोड उपलब्ध है, इसलिए यह बंद स्रोत सॉफ़्टवेयर को काफी अच्छी तरह से कवर कर सकता है। यह थोड़े से संशोधन के साथ स्वचालन के भाग के रूप में चल सकता है, लेकिन भेद्यता शोधकर्ताओं के लिए उपयोग करने में मज़ेदार होने पर केंद्रित है। हालाँकि, इसे पूरी तरह से विकसित उत्पाद के बजाय एक R&D परियोजना के रूप में सोचना अधिक सहायक है। साथ ही, कोई जटिल सेटअप नहीं है जहाँ यह बॉक्स के बाहर थोड़ा टूटा हुआ हो या आधुनिक ऑपरेटिंग सिस्टम पर चलाने के लिए और काम की आवश्यकता हो।

इसे Ubuntu Linux, Mac और Windows पर काम करते हुए परीक्षण किया गया है और यह पूरी तरह से कार्यात्मक स्क्रिप्ट्स के साथ आता है जो आपके लिए लगभग सब कुछ करती हैं ताकि फ़ज़िंग के लिए तैयार वातावरण सेटअप किया जा सके।

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

## यह कैसे काम करता है

**Litefuzz तीन अलग-अलग मोड का समर्थन करता है: स्थानीय, क्लाइंट और सर्वर।**

स्थानीय का अर्थ है स्थानीय बाइनरी को लक्षित करना, जो Linux/Mac पर क्रमशः GDB और LLDB ट्राइएज समर्थन के साथ सबप्रोसेस के माध्यम से लॉन्च की जाती हैं और Windows पर [WinAppDbg](https://github.com/MarioVilas/winappdbg) के माध्यम से। क्रैश को स्थानीय क्रैश निर्देशिका में लिखा जाता है और फ़ॉल्ट प्रकार, जैसे रीड/राइट AV या SIGABRT/SIGSEGV, फ़ाइल हैश के साथ क्रमबद्ध किया जाता है। सभी अद्वितीय क्रैश को फ़ज़िंग के दौरान ट्राइएज किया जाता है और यह डेटा लक्ष्य आउटपुट (जैसा उपलब्ध हो) के साथ-साथ उसी निर्देशिका में आर्टिफैक्ट के रूप में कैप्चर और रखा जाता है। `--replay` और क्रैशिंग फ़ाइल प्रदान करके क्रैश को फिर से चलाना भी संभव है। `local` क्लाइंट मोड में, इनपुट निर्देशिका में सर्वर ग्रीटिंग, प्रतिक्रिया या अन्य डेटा होना चाहिए जो क्लाइंट को सर्वर से कनेक्ट करते समय अपेक्षित हो।

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

शुरू से लिखे गए कुछ म्यूटेशन फ़ंक्शन हैं जो ज्यादातर `-i` फ़्लैग द्वारा निर्दिष्ट इनपुट के यादृच्छिक चयन के साथ यादृच्छिक म्यूटेशन करते हैं। फ़ाइल फ़ज़िंग के लिए, बस स्थानीय मोड चुनें और FUZZ के साथ लक्ष्य कमांड लाइन पास करें जहाँ ऐप पार्स करने के लिए फ़ाइल नाम की अपेक्षा करता है, जैसे `tcpdump -r FUZZ` और म्यूटेट करने के लिए "अच्छी फ़ाइलों" की एक इनपुट निर्देशिका। नेटवर्क क्लाइंट फ़ज़िंग के लिए, यह स्थानीय फ़ज़िंग के समान है, लेकिन `-a` के माध्यम से कनेक्शन विशिष्टताएँ भी प्रदान करें। और यदि आप सर्वर को फ़ज़ करना चाहते हैं, तो सर्वर मोड करें और क्लाइंट की तरह ही `protocol://address:port` प्रदान करें।

यह उतनी तेज़ी से फ़ज़ करता है जितनी तेज़ी से लक्ष्य डेटा का उपभोग कर सकता है और बाहर निकल सकता है, जैसे कि अधिकांश CLI अनुप्रयोगों के मामले में, या जब तक आपने यह निर्धारित किया है कि स्थानीय निष्पादन या नेटवर्क कनेक्शन टाइमआउट से पहले इसकी आवश्यकता है, जो बहुत धीमा हो सकता है। यहाँ कोई फैंसी exec या कर्नेल ट्रिक नहीं हैं। लेकिन निश्चित रूप से यदि आप एक हार्नेस लिखते हैं जो इनपुट को पार्स करता है और जल्दी से बाहर निकलता है, लक्ष्य के एक विशिष्ट भाग को कवर करते हुए, तो यह भी मदद करता है। लेकिन उस बिंदु पर, यदि आप लक्ष्य के इतने करीब पहुँच सकते हैं, तो आप शायद [persistant mode](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html) या अन्य फ़ज़र्स द्वारा प्रदान की जा सकने वाली समान सुविधाओं का उपयोग करने में बेहतर होंगे।

संक्षेप में...

### यह क्या करता है
- linux, windows और mac पर चलता है और py2/py3 का समर्थन करता है
- CLI/GUI बाइनरी को फ़ज़ करता है जो फ़ाइलों/stdin से पढ़ती हैं
- नेटवर्क क्लाइंट और सर्वर, ओपन सोर्स या मालिकाना, स्थानीय रूप से डीबग करने योग्य या रिमोट को फ़ज़ करता है
- क्रैश का डिफ़िंग, न्यूनीकरण, रीप्ले, सॉर्टिंग और ऑटो-ट्राइएजिंग
- Misc सामान जैसे TLS समर्थन, golang बाइनरी फ़ज़िंग और Mac के लिए कुछ अतिरिक्त
- विभिन्न अंतर्निहित म्यूटेटर + pyradamsa (Linux) के साथ इनपुट को म्यूटेट करता है

### यह क्या नहीं करता
- मूल इंस्ट्रूमेंटेशन
- समवर्ती कार्यों के साथ स्केल करना
- जटिल सत्र फ़ज़िंग
- रिमोट क्लाइंट और सर्वर मॉनिटरिंग (केवल बुनियादी जाँच जैसे कनेक्ट)

## समर्थन

मुख्य रूप से **Ubuntu Linux 20.04** (22.04 और 21.04 हल्का परीक्षण), **Windows 10** और **Mac OS 11** (12 हल्का परीक्षण) पर परीक्षण किया गया। फ़ज़र और सेटअप स्क्रिप्ट इन ऑपरेटिंग सिस्टमों के थोड़े पुराने या नए संस्करणों पर भी काम कर सकते हैं, लेकिन अधिकांश शोध, परीक्षण और विकास इन वातावरणों में हुआ। Python3 समर्थित है और कोड को Python2 के साथ भी संगत बनाने का प्रयास किया गया क्योंकि [WinAppDbg](https://github.com/MarioVilas/winappdbg) के माध्यम से Windows पर फ़ज़िंग के लिए यह आवश्यक है।

प्लेटफ़ॉर्म परीक्षण मुख्य रूप से Intel-आधारित हार्डवेयर पर हुआ, लेकिन चीज़ें Apple के M1 प्लेटफ़ॉर्म पर भी ज्यादातर काम करती दिखती हैं (उल्लेखनीय अपवाद: Linux पर GDB के लिए exploitable प्लगइन शायद समर्थित नहीं है, न ही Pyradamsa)। setup/ में सेटअप स्क्रिप्ट भी हैं जो अधिकांश या सभी कार्यों और निर्भरता स्थापना को स्वचालित करती हैं। यह आम तौर पर प्रत्येक प्लेटफ़ॉर्म पर मूल बाइनरी को फ़ज़ कर सकता है, जो अक्सर C/C++ में संकलित होती हैं, लेकिन यह Golang बाइनरी के क्रैश को भी पकड़ता है (प्रयोगात्मक)।

### python संस्करण

Linux और Mac के लिए Python3 समर्थित है जबकि Windows के लिए Python2 आवश्यक है।

Linux और Mac के लिए Py3 क्यों? Pyautogui, Pyradamsa (केवल Linux), Mac पर बेहतर सॉकेट समर्थन।

Windows के लिए Py2 क्यों? Winappdbg को Py2 की आवश्यकता है।

### linux

डीबगिंग के लिए GDB और क्रैश ट्राइएज के लिए [exploitable](https://github.com/jfoote/exploitable)। यदि यह OSS है, तो आप [sanitizers](https://fuzzing-project.org/tutorial2.html) और इस तरह के साथ लक्ष्य बना और इंस्ट्रूमेंट कर सकते हैं, अन्यथा कुछ [मेमोरी डीबगर्स](https://en.wikibooks.org/wiki/Linux_Applications_Debugging_Techniques/Heap_corruption) हैं जिन्हें हम रनटाइम पर लोड कर सकते हैं।

यह स्थापना python निर्भरताओं और अन्य सहायक सामान के साथ [setup/linux.sh](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/linux.sh) के साथ स्वचालित की गई है। अनुशंसित OS Ubuntu 20.04 है क्योंकि यह वहीं है जहाँ अधिकांश परीक्षण हुआ।

### mac

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

एक चीज़ जो आपको मैन्युअल रूप से करने की आवश्यकता होगी वह है SIP को बंद करना (रिकवरी में, cmd+R के माध्यम से या vmware फ्यूजन हैक्स का उपयोग करें)। अन्यथा, टिम एप्पल के OS पर फ़ज़िंग करते समय ऑटो-ट्राइएज विफल हो जाएगा।

लगभग सभी सेटअप [setup/mac.sh](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/mac.sh) स्क्रिप्ट के साथ स्वचालित किया गया है, इसलिए त्वरित शुरुआत के लिए आप इसे चला सकते हैं।

### windows

Windows पर डीबगिंग के लिए [WinAppDbg](https://github.com/MarioVilas/winappdbg) का उपयोग किया जाता है, इस मामूली कमी के साथ कि stdin फ़ज़िंग समर्थित नहीं है।

अन्य ऑपरेटिंग सिस्टमों के लिए स्वचालित सेटअप की तरह, chocolatey windows पर पैकेज स्थापना को स्वचालित करने में मदद करता है। litefuzz रूट निर्देशिका में व्यवस्थापक के रूप में [setup/windows.bat](https://github.com/sec-tools/litefuzz/blob/HEAD/setup/windows.bat) चलाएँ ताकि स्थापनाओं को स्वचालित किया जा सके। यह डीबगिंग टूल्स और अन्य निर्भरताएँ स्थापित करेगा ताकि चीज़ें सुचारू रूप से चलें।

### लक्ष्य

यह उन लक्ष्यों के प्रकारों की सूची है जिनका परीक्षण किया गया है और आम तौर पर समर्थित हैं।

* स्थानीय CLI/GUI ऐप्स जो फ़ाइल प्रारूप या stdin पार्स करते हैं
  - डीबग समर्थन
 
* स्थानीय CLI/GUI नेटवर्क क्लाइंट जो सर्वर प्रतिक्रियाओं को पार्स करता है
  - CLI के लिए डीबग समर्थन
  - GUI के लिए सीमित डीबग समर्थन
 
* स्थानीय CLI नेटवर्क सर्वर जो क्लाइंट अनुरोधों को पार्स करता है
  - डीबग समर्थन (चेतावनी: इसे एक स्टैंडअलोन निष्पादन योग्य के रूप में चलाने में सक्षम होना चाहिए, अन्यथा इसे *रिमोट* माना जा सकता है)

* स्थानीय GUI नेटवर्क सर्वर जो क्लाइंट अनुरोधों को पार्स करता है
  - सैद्धांतिक रूप से समर्थित, अपरीक्षित

* रिमोट CLI/GUI नेटवर्क क्लाइंट जो सर्वर प्रतिक्रियाओं को पार्स करता है
  - कोई डीबग समर्थन नहीं

* रिमोट CLI/GUI नेटवर्क सर्वर जो क्लाइंट अनुरोधों को पार्स करता है
  - कोई डीबग समर्थन नहीं
  - अपवाद: Mac पर `attach` या `reportcrash` सुविधाओं का उपयोग करना

फिर से, फ़ज़र Linux, Mac और Windows पर स्थानीय ऐप्स, क्लाइंट और सर्वर पर चल सकता है और समर्थन कर सकता है और निश्चित रूप से लक्ष्य प्लेटफ़ॉर्म से स्वतंत्र रूप से रिमोट सामान को फ़ज़ कर सकता है।

### ट्राइएज

* स्थानीय CLI/GUI ऐप्स जो फ़ाइल प्रारूप या stdin पार्स करते हैं
  - ऐप चलाएँ, सिग्नल पकड़ें, क्रैशर के साथ इसे डीबगर के अंदर फिर से चलाकर पुन: प्रस्तुत करें
 
* स्थानीय CLI/GUI नेटवर्क क्लाइंट जो सर्वर प्रतिक्रियाओं को पार्स करता है
  - ऐप चलाएँ, सिग्नल पकड़ें, क्रैशर के साथ इसे डीबगर के अंदर फिर से चलाकर पुन: प्रस्तुत करें

* स्थानीय GUI/CLI नेटवर्क सर्वर जो क्लाइंट अनुरोधों को पार्स करता है
  - डीबगर में ऐप चलाएँ, सिग्नल पकड़ें, क्रैशर के साथ इसे डीबगर के अंदर फिर से चलाकर पुन: प्रस्तुत करें

* रिमोट CLI/GUI नेटवर्क क्लाइंट जो सर्वर प्रतिक्रियाओं को पार्स करता है
  - कोई दृश्यता नहीं, रिमोट साइड से क्रैश इकट्ठा करें
  - ट्राइएज में सहायता के लिए मैन्युअल रूप से सहायक स्क्रिप्ट लिख सकते हैं

* रिमोट CLI/GUI नेटवर्क सर्वर जो क्लाइंट अनुरोधों को पार्स करता है
  - कोई दृश्यता नहीं, रिमोट साइड से क्रैश इकट्ठा करें
  - ट्राइएज में सहायता के लिए मैन्युअल रूप से सहायक स्क्रिप्ट लिख सकते हैं
  - Mac पर अपवाद `attach` और `reportcrash` विकल्प हैं, जिनका उपयोग कुछ ट्राइएज क्षमताओं को सक्षम करने के लिए किया जा सकता है

## शुरुआत करना

अधिकांश प्लेटफ़ॉर्म पर सेटअप [setup](https://github.com/sec-tools/litefuzz/blob/main/README.md#setup) निर्देशिका में स्क्रिप्ट के साथ स्वचालित किया गया है।

बस उन्हें litefuzz रूट से चलाएँ और यह आपको बहुत समय बचाएगा और स्वचालित परिनियोजन के लिए आवश्यक कुछ चीज़ों को सक्षम करने में मदद करेगा। एक VM का उपयोग करना उपयोगी है ताकि एक साफ OS और फ़ज़िंग वातावरण सेटअप किया जा सके क्योंकि अन्य चीज़ों के अलावा इसकी स्नैपशॉट क्षमताएँ काम आती हैं।

विवरण के लिए [INSTALL.md](https://github.com/sec-tools/litefuzz/blob/main/INSTALL.md) देखें।

**स्थापना के बाद, त्वरित रन के लिए प्रारंभिक अनुभाग में latex2rtf के उदाहरण फ़ज़िंग का संदर्भ लें या इस README पर विस्तृत सभी कमांड लाइन विकल्पों और आगे के उदाहरणों में गोता लगाएँ।**

### docker

आप स्थानीय रूप से निर्भरताएँ स्थापित किए बिना `Dockerfile` का उपयोग करके Docker के साथ litefuzz चला सकते हैं। यह विशेष रूप से त्वरित परीक्षण के लिए या यदि आप अपने सिस्टम पर निर्भरताएँ स्थापित करने से बचना चाहते हैं तो उपयोगी है।

Dockerfile दोनों तरह से काम करता है:
- **रिपॉजिटरी के अंदर से** - स्थानीय फ़ाइलों का उपयोग करता है (तेज़, स्थानीय परिवर्तन शामिल हैं)
- **स्टैंडअलोन** - किसी भी निर्देशिका से बनाया जा सकता है (GitHub से क्लोन करता है)```bash
# Build the Docker image (from any directory with Dockerfile)
docker build -t litefuzz:latest .

# Run litefuzz
docker run --rm litefuzz:latest python3 litefuzz.py --help

यह निम्न कार्य करेगा:
- latex2rtf को 1000 पुनरावृत्तियों (iterations) के साथ फ़ज़ (Fuzz) करेगा
- हीप डिबगिंग (`-z` फ़्लैग) का उपयोग करेगा
- क्रैश को आपके होस्ट पर `./crashes` निर्देशिका में सहेजेगा
- रीपो से `/litefuzz/input/tex` पर बिल्ट-इन इनपुट फ़ाइलों का उपयोग करेगा

यदि आप होस्ट से अपनी स्वयं की इनपुट फ़ाइलों का उपयोग करना चाहते हैं:```bash
# Create input directory with your test files
mkdir -p input/tex crashes
# Add your test files to input/tex/
cp your-test.tex input/tex/

# Run fuzzing with your input files
docker run --rm \
  -v $(pwd)/input:/litefuzz/input \
  -v $(pwd)/crashes:/tmp/crashes \
  litefuzz:latest \
  python3 litefuzz.py -l -c "latex2rtf FUZZ" -i /litefuzz/input/tex -o /tmp/crashes -n 1000 -z

यह मुख्य निर्देशिका में `test_litefuzz.py` के लिए pytest चलाएगा और परीक्षण रन समाप्त होने पर PASS/FAIL परिणाम प्रदान करेगा।

#### एप क्रैश परीक्षण
विभिन्न प्लेटफार्मों पर क्रैश और ट्राइएज क्षमताओं का परीक्षण करने के लिए बगी ऐप्स के कुछ उदाहरण `test` फ़ोल्डर में पाए जा सकते हैं।

- (a) null pointer dereference
- (b) divide-by-zero
- (c) heap overflow
- (d-gui) format string bug in a GUI
- (e) buffer overflow in client
- (f) buffer overflow in server

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

**यदि विंडोज कमांड लाइन पर चला रहे हैं, तो क्रैश देखने के लिए `Event Viewer -> Windows Logs -> Application` जांचें।**

## विकल्प
विभिन्न लक्ष्य परिदृश्यों का लाभ उठाने के लिए बहुत सारे विभिन्न विकल्प और सुविधाएं हैं। निम्नलिखित एक संक्षिप्त व्याख्या और उनका उपयोग कैसे करें यह समझने में मदद करने के लिए कुछ उदाहरण हैं।

### क्रैश निर्देशिका
`-o` आपको डिफ़ॉल्ट के अलावा एक क्रैश निर्देशिका निर्दिष्ट करने देता है, जो स्थानीय पथ में crashes/ है। कोई इसका उपयोग एक ही समय में विभिन्न ऐप्स के लिए कई समवर्ती फ़ज़िंग रन के लिए क्रैश फ़ोल्डर प्रबंधित करने के लिए कर सकता है।

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

`litefuzz -lk -c "/snap/postman/140/usr/share/Postman/_Postman" -i input/http_responses -a tcp://localhost:8080 -u -n 100000 -z`

इंसुलेट मोड + रिफ्रेश का उपयोग इंटरएक्टिव क्लाइंट के लिए किया जा सकता है, जैसे कि डीबगर में FileZilla चलाएं, लेकिन प्रत्येक नए पुनरावृत्ति के लिए सर्वर से पुन: कनेक्ट करने हेतु F5 दबाते रहें। साथ ही, स्थानीय CLI/GUI सर्वर को फ़ज़ करना केवल एक बार डीबगर के अंदर शुरू और चलाया जाता है ताकि प्रक्रिया थोड़ी अधिक कुशल हो।

`--key` आपको इंटरएक्टिव लक्ष्यों को फ़ज़ करते समय कुंजियाँ भेजने की अनुमति भी देता है, जैसे कि F5 के साथ "refresh connection" भेजकर FileZilla के FTP सर्वर प्रतिक्रियाओं के पार्सिंग को फ़ज़ करना।

`litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp/filezilla -u -pp --key "F5" -n 100 -z glibc`

नोट: इंसुलेट मोड केवल लिनक्स पर काम करने का परीक्षण किया गया है और विंडोज पर समर्थित नहीं है।

### टाइमआउट
`-x secs` आपको एक टाइमआउट निर्दिष्ट करने देता है। व्यवहार में, यह CLI लक्ष्यों के लिए "पुनरावृत्तियों के बीच लगभग कितना समय" जैसा है और GUI के लिए एक वास्तविक टाइमआउट है।

### म्यूटेटर
`--mutator N` निर्दिष्ट करता है कि फ़ज़िंग के लिए किस म्यूटेटर का उपयोग किया जाए। यदि विकल्प प्रदान नहीं किया गया है, तो प्रत्येक फ़ज़िंग पुनरावृत्ति के लिए उपलब्ध म्यूटेटर की सूची से एक यादृच्छिक विकल्प चुना जाता है।

ये म्यूटेटर शुरू से लिखे गए थे (निश्चित रूप से Radamsa को छोड़कर)। और जबकि उनका व्यापक रूप से परीक्षण किया गया है और लाखों पुनरावृत्तियों के दौरान काफी अच्छा प्रदर्शन किया है, उनमें समय-समय पर सूक्ष्म बग हो सकते हैं, लेकिन आमतौर पर इससे कार्यक्षमता प्रभावित नहीं होनी चाहिए।```
FLIP_MUTATOR = 1
HIGHLOW_MUTATOR = 2
INSERT_MUTATOR = 3
REMOVE_MUTATOR = 4
CARVE_MUTATOR = 5
OVERWRITE_MUTATOR = 6
RADAMSA_MUTATOR = 7

### pause
फ़ज़िंग प्रक्रिया को रोकने के लिए ctrl+c दबाएँ। यदि आप फिर से शुरू करना चाहते हैं, तो रुकने के लिए `y` या `n` चुनें। यह सुविधा अधिकांश प्लेटफार्मों पर ठीक काम करती है, लेकिन GUI ऐप्स को फ़ज़ करते समय कम विश्वसनीय हो सकती है।

### reusing crashes for variant finding
`-e` पुन: उपयोग मोड को सक्षम करता है। इसका मतलब है कि यदि फ़ज़िंग रन के दौरान कोई क्रैश पाए गए, तो उन्हें फ़ज़िंग के दूसरे दौर के लिए इनपुट के रूप में उपयोग किया जाएगा, जो और भी अधिक बग्स को निकालने में मदद कर सकता है। अधिक बग्स के लिए `-z` के साथ `-ez` संयोजित करें! Da-duph.

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

`litefuzz -l -c "antiword FUZZ" -i docs -n 100000 -ez`

(या कोई मैन्युअल रूप से क्रैश को एक इनपुट निर्देशिका में कॉपी कर सकता है ताकि पुन: उपयोग रन के लिए पुनरावृत्तियों को सीधे नियंत्रित किया जा सके)

`litefuzz -l -c "antiword FUZZ" -i docs-crashes -n 500000 -z`

नोट: यह मोड केवल स्थानीय ऐप्स के लिए समर्थित है।

### memory debugging helpers
`-z` लिनक्स पर Electric Fence (या फ़ॉलबैक के रूप में glib malloc डीबगिंग), मैक पर Guard Malloc और विंडोज़ पर PageHeap को सक्षम करता है। साथ ही, किसी एप्लिकेशन के लिए इसे सक्षम करने के बाद PageHeap को अक्षम करने के लिए `-zz` का उपयोग किया जा सकता है। यदि आप फ़ज़र शुरू किए बिना इसे चालू/बंद करना चाहते हैं, तो केवल `-i` फ़्लैग को छोड़ दें। विंडोज़ सेटअप के दौरान, [gsudo](https://github.com/gerardog/gsudo) स्थापित होता है और इसका उपयोग कमांड लाइन पर उन्नत कमांड चलाने के लिए किया जा सकता है, जैसे कि लक्ष्यों के लिए PageHeap चालू करना।

`sudo litefuzz -l -c "notepad FUZZ" -i texts/files -z`

`sudo litefuzz -l -c "notepad FUZZ" -zz`

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

`litefuzz -l -c "geany FUZZ" -i texts/codes -z glibc`

डिफ़ॉल्ट Electric Fence malloc डीबगर बढ़िया है, लेकिन यह सभी लक्ष्यों के साथ काम नहीं करता। आप EF के साथ लक्ष्य का परीक्षण कर सकते हैं और यदि यह क्रैश होता है, तो इसके बजाय glibc सहायक चुनें।

### checking live target output
यदि लिनक्स या मैक पर स्थानीय ऐप्स को फ़ज़ किया जा रहा है, तो आप `cat /tmp/litefuzz/RUN_ID/fuzz.out` का उपयोग करके लक्ष्य से नवीनतम stdout की जाँच कर सकते हैं। फ़ज़िंग शुरू होने पर `RUN_ID` STATS जानकारी क्षेत्र में दिखाया जाता है। यदि कोई क्रैश होता है, तो stdout को क्रैश निर्देशिका में `.out` फ़ाइल के रूप में भी कैप्चर किया जाता है। वैश्विक stdout/stderr डीबगिंग उद्देश्यों के लिए `/tmp/litefuzz/out` पर भी जाता है, सभी फ़ज़िंग लक्ष्यों के लिए, अलग-थलग या स्थानीय सर्वर मोड को छोड़कर, जिनका डीबगर आउटपुट `/tmp/litefuzz/RUN_ID/out` पर जाता है।

Winappdbg मूल रूप से लक्ष्यों के stdout को कैप्चर करने का समर्थन नहीं करता (AFAIK), इसलिए यह आर्टिफैक्ट विंडोज़ पर उपलब्ध नहीं है।

### client and server modes
यदि सर्वर को केवल बाइनरी निष्पादित करके स्थानीय रूप से चलाया जा सकता है (कुछ फ़्लैग और कॉन्फ़िगरेशन के साथ या बिना), तो आप इसकी कमांड लाइन `-c` के साथ पास कर सकते हैं और यह हर पुनरावृत्ति पर एक नए निष्पादन के साथ शुरू, फ़ज़ और मारा जाएगा। यहाँ विचार गति को उन कष्टप्रद बग्स से बचने की क्षमता के लिए व्यापार करना है जो केवल लक्ष्य की मेमोरी एक "निश्चित स्थिति" में होने पर ट्रिगर होते हैं, जो झूठी सकारात्मकता का कारण बन सकते हैं। नेटवर्क क्लाइंट को स्थानीय रूप से फ़ज़ करने के साथ भी यही बात है। यह TLS कनेक्शन का भी समर्थन करता है, आपके लिए मौके पर प्रमाणपत्र उत्पन्न करता है (उपयोगकर्ता को क्लाइंट प्रमाणपत्र प्रदान करने की अनुमति देता है जब किसी सर्वर को फ़ज़ किया जा रहा है जिसे इसकी आवश्यकता है और प्रमाणपत्र फ़ज़िंग स्वयं यहाँ अन्य विचार हैं)।

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

### local network examples

`litefuzz -lk -c "wget http://localhost:8080" -a tcp://localhost:8080 -i input/http -z`

`litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -z`

`litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -o crashes/curl --tls -n 100000 -z`

(Wireshark खोलें और एक d से प्रतिक्रिया कैप्चर करें, Simple Network Management Protocol पर राइट क्लिक करें -> Export Packet Bytes -> resp.bin)

`litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3`

`litefuzz -ls -c "./sc_serv shoutcast.conf" -a localhost:8000 -i input/shouts -z`

`litefuzz -ls -c "snmpd" -i input/snmp -a udp://localhost:161 -z`

**quick notes**
- UDP सॉकेट Mac + Py2 पर थोड़ा अजीब व्यवहार कर सकते हैं, इसलिए केवल Mac + Py3 का परीक्षण और समर्थन किया गया है
- विंडोज़ पर स्थानीय नेटवर्क क्लाइंट फ़ज़िंग बगी हो सकती है और इस समय इसे प्रयोगात्मक माना जाना चाहिए

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

UDP इसे और जटिल बनाता है। यह देखने के लिए एक परीक्षण पैकेट भेजना भी कि क्या UDP पोर्ट पर कोई सुनने वाली सेवा है, प्रतिक्रिया की गारंटी नहीं देता। इसलिए नेटवर्क क्लाइंट और सर्वर को रिमोटली फ़ज़ करना संभव है, लेकिन दृश्यता पर एक समझौता होता है।

#### client

`while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done`

`litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -pp -n 100`

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

#### server

सर्वर को स्थानीय या रिमोट रूप से फ़ज़ करने के फायदे और नुकसान आपको यह निर्णय लेने में मदद कर सकते हैं कि जब दोनों विकल्प उपलब्ध हों तो किसी लक्ष्य तक कैसे पहुँचा जाए।

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

**Shoutcast**

`./sc_serv ...`

`litefuzz -s -a localhost:8000 -i input/shouts -n 10000`

**SSHesame**

`sshesame`

`litefuzz -s -a tcp://target:2022 -i input/ssh-server -p -n 1000000 -x 0.05`

**FTP**

`litefuzz -s -a tcp://target:21 -i input/ftp/req.txt -pp -n 1000`

**DNS**

`coredns -dns.port 10000`

`litefuzz -ls -c "coredns -dns.port 10000" -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000`

या

`litefuzz -s -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000`

##### TLS

`litefuzz -s -a tcp://hostname:8080 -i input/http --tls -n 10000````
...
@ 48/10000 (1 crashes, 0 duplicates, ~7:13:18 remaining)

[!] check target, sleeping for 60 seconds before attempting to continue fuzzing...

प्रत्येक पैकेट को एक ऐरे में लिया जाता है, एक यादृच्छिक इंडेक्स को उत्परिवर्तित किया जाता है और लक्ष्य को फ़ज़ करने के लिए पुनः चलाया जाता है।

`litefuzz -lk -c "ssh -T test@localhost -p 2222" -a tcp://localhost:2222 -i input/ssh -o crashes/ssh -p -n 250000 -z glibc`

और आप नवीनतम पुनरावृत्ति के लिए लक्ष्य के आउटपुट की जांच कर सकते हैं।```
cat /tmp/litefuzz/out
kex_input_kexinit: discard proposal: string is too large
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: string is too large

... and others like

ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: unknown or unsupported key type

ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory
Host key verification failed.

Bad packet length 1869636974.
ssh_dispatch_run_fatal: Connection to 127.0.0.1 port 2222: message authentication code incorrect

फ़ज़र प्रत्येक पंक्ति को अपने स्वयं के FTP प्रतिक्रिया में तोड़ता है ताकि क्लाइंट के सत्र के प्रबंधन को फ़ज़ करने का प्रयास किया जा सके। हालांकि, इसकी कोई गारंटी नहीं है कि कोई क्लाइंट ऐसा "व्यवहार" करेगा या ऐसे तरीकों से कार्य करेगा जो सत्र को ठीक से पूरा नहीं होने देंगे, इसलिए Wireshark चलाते समय सत्र परीक्षण मामलों के लिए कुछ परीक्षण और त्रुटि + फाइन ट्यूनिंग लक्ष्यों के बीच बातचीत के अंतर को समझने में सहायक हो सकती है।

`litefuzz -lk -c "ftp localhost 2121" -a tcp://localhost:2121 -i input/ftp -o crashes/ftp -n 100000 -pp -z`

इसे *-u* के साथ FileZilla जैसे GUI नेटवर्क लक्ष्यों को अलग करने के लिए भी जोड़ा जा सकता है।

`litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp.resp -n 100000 -u -pp -z glibc`

### किसी प्रक्रिया से जुड़ना
यदि लक्ष्य कनेक्शन पर एक नई प्रक्रिया उत्पन्न करता है, तो सर्वर से कनेक्शन स्थापित होने के बाद संलग्न होने के लिए एक प्रक्रिया का नाम (या pid) निर्दिष्ट किया जा सकता है। यह उन मामलों में उपयोगी है जहाँ जैसे launchd एक पोर्ट पर सुन रहा है और क्लाइंट के कनेक्ट होने के बाद ही हैंडलिंग प्रक्रिया लॉन्च करता है। यह एक ऐसी सुविधा है जो स्थानीय और दूरस्थ फ़ज़िंग के बीच की रेखा को धुंधला कर देती है, क्योंकि तकनीकी रूप से फ़ज़र दूरस्थ मोड में है, फिर भी हम लक्ष्य पता localhost के रूप में निर्दिष्ट करते हैं और इसे एक प्रक्रिया से जुड़ने के लिए कहते हैं।

`./litefuzz.py -s -a tcp://localhost:8080 -i input/shareserv -p --attach ShareServ -x 1 -n 100000`

नोट: वर्तमान में यह सुविधा केवल Mac (LLDB) और नेटवर्क फ़ज़िंग के लिए समर्थित है, हालाँकि यदि इसे लागू किया जाता है तो यह Linux (GDB) पर भी ठीक काम करेगी।

### क्रैश आर्टिफैक्ट
जब फ़ज़िंग के दौरान कोई क्रैश आता है, तो इसे डीबगर में फिर से चलाया जाता है ताकि डीबग आर्टिफैक्ट और बकेटिंग जानकारी उत्पन्न की जा सके। जानकारी प्लेटफॉर्म से प्लेटफॉर्म में भिन्न होती है, लेकिन सामान्यतः एक टेक्स्ट फ़ाइल बैकट्रेस, रजिस्टर जानकारी, `!exploitable` प्रकार की सामग्री (जहाँ उपलब्ध हो) और अन्य बुनियादी जानकारी के साथ उत्पन्न होती है।

**मेमोरी डंप** को Windows पर `--memdump` पास करके सक्षम किया जा सकता है या `--nomemdump` से अक्षम किया जा सकता है, ठीक उसी प्रकार जैसे malloc डीबगर्स को क्रमशः `-z` और `-zz` के माध्यम से नियंत्रित किया जाता है। यदि सक्षम किया जाता है, तो डंप को कंसोल डीबगर (cdbg) में भी लोड किया जाएगा और `!analyze -v` क्रैश विश्लेषण आउटपुट एक अतिरिक्त मेमोरी डंप क्रैश विश्लेषण लॉग में कैप्चर किया जाता है। Winappdbg में पहले से ही !exploitable प्रकार का विश्लेषण है जो हमें प्रारंभिक क्रैश विश्लेषण में मिलता है, इसलिए हम यहाँ केवल !analyze करते हैं।

`litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --memdump`

या किसी एप्लिकेशन के लिए मेमोरी डंप अक्षम करने के लिए

`litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --nomemdump`

ऑटो-क्रैश ट्राइएज के अलावा, बाइनरी/स्ट्रिंग डिफ (जैसा उपयुक्त हो) और लक्ष्य stdout (प्लेटफॉर्म/लक्ष्य पर निर्भर) भी उत्पन्न होते हैं और निश्चित रूप से repro फ़ाइलें भी।

स्थानीय फ़ज़िंग के लिए, आर्टिफैक्ट में सामान्यतः डिफ, stdout (केवल linux/mac), repro फ़ाइल और क्रैश लॉग तथा सूचना फ़ाइल शामिल होती है।```
$ ls crashes/latex
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diff
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diffs
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.out
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.tex
PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.txt

दूरस्थ फ़ज़िंग के लिए, चुने गए विकल्पों के आधार पर आर्टिफैक्ट्स भिन्न हो सकते हैं, लेकिन इनमें अक्सर diffs, repro file और/या repro file directory (यदि इनपुट एकाधिक पैकेट वाला सत्र है), पिछले फ़ज़िंग पुनरावृत्ति का repro file (बग को खोने से रोकना यदि वह वास्तव में क्रैश करने वाला है क्योंकि दूरस्थ फ़ज़िंग की अपनी चुनौतियाँ हैं) और crash log या संक्षिप्त जानकारी फ़ाइल शामिल होती है।```
ls crashes/serverd
REMOTE_SERVER_testbox.1_NNNN_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
REMOTE_SERVER_testbox.1_NNNN_PREV_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.diff
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.diffs
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.txt
UNKNOWN_XXXX2040YYYY_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY.zz

ls crashes/serverd/REMOTE_SERVER_localhost_NNNN_XXXX9c3f3660aaa76f70515f120298f581adfa9caa8dcaba0f25a2bc0b78YYYY
REMOTE_SERVER_testbox.1_NNNN_1.zz	REMOTE_SERVER_localhost_NNNN_2.zz
REMOTE_SERVER_testbox.1_NNNN_3.zz	REMOTE_SERVER_localhost_NNNN_4.zz

इसके संक्षिप्त संस्करण पर एक नज़र डालें।```
GET /admin.cgi?mode=debug&option=a
Authorization:s YWRtaW46Y2hhbmdlbWU
Referer:admin.cgi

**न्यूनीकरण उदाहरण**

`litefuzz -l -c "latex2rtf FUZZ" -m test.tex -z`

`litefuzz -ls -c "./sc_serv shoutcast.conf" -a "tcp://localhost:8000" -m repro.http`

**सुपरमिन उदाहरण**```
litefuzz -l -c "latex2rtf FUZZ" -mm crashes/latex2rtf/test.tex -z
...
[+] starting minimization

@ 582/582 (1 new crashes, 1145 -> 582 bytes, ~0:00:00 remaining)  

[+] reduced crash @ pc=55555556c141 -> pc=55555557c57d to 582 bytes

[+] supermin activated, continuing...

@ 299/299 (1 new crashes, 582 -> 300 bytes, ~0:00:00 remaining)

[+] reduced crash @ pc=55555557c57d to 300 bytes
...
[+] reduced crash @ pc=555555562170 to 17 bytes

@ 17/17 (2 new crashes, 17 -> 17 bytes, ~0:00:00 remaining)

[+] achieved maximum minimization @ 17 bytes (test.min.tex)

[RESULTS]
completed (17) iterations with 2 new crashes found

#### उबंटू पर फ़ाइल हैंडलर्स की गणना```
$ cat /usr/share/applications/defaults.list
[Default Applications]
application/csv=libreoffice-calc.desktop
application/excel=libreoffice-calc.desktop
application/msexcel=libreoffice-calc.desktop
application/msword=libreoffice-writer.desktop
application/ogg=rhythmbox.desktop
application/oxps=org.gnome.Evince.desktop
application/postscript=org.gnome.Evince.desktop
....

**stdin के माध्यम से gpg डिक्रिप्शन को हीप एरर चेकिंग के साथ फज करें** (Mac)

`litefuzz -l -c "gpg --decrypt" -i test-gpg -o crashes-gpg -z`

**Books ऐप को फज करें** (Mac GUI)

`litefuzz -l -c "/System/Applications/Books.app/Contents/MacOS/Books FUZZ" -i test-epub -t "/Users/test/Library/Containers/com.apple.iBooksX/Data" -x 8 -n 100000 -z`

नोट: `-z` यहाँ [Guard Malloc](https://www.manpagez.com/man/3/libgmalloc/) हीप एरर चेकिंग को सक्षम करता है ताकि सूक्ष्म हीप भ्रष्टाचार बग्स का पता लगाया जा सके।

**Mac नोट**

कुछ GUI लक्ष्य प्रत्येक पुनरावृत्ति के टाइमआउट के बाद मारे जाने में विफल हो सकते हैं और अनुत्तरदायी हो सकते हैं। इसे कम करने के लिए, आप एक स्क्रिप्ट चला सकते हैं जो दूसरे टर्मिनल में इस तरह दिखती है ताकि मैन्युअल प्रयास और निगरानी को कम करने के लिए उन्हें समय-समय पर बैच में मारा जा सके, अन्यथा फजिंग प्रक्रिया प्रभावित हो सकती है।```
#!/bin/bash
ps -Af | grep -ie "$1" | awk '{print $2}' | xargs kill -9

*/Users/test* (अस्थायी फ़ाइलों को स्थानीय GUI ऐप में भेजने के लिए पथ के पहले भाग का उदाहरण, निष्पादन के दौरान FUZZ एक पथ बन जाता है) को इसलिए चुना गया क्योंकि आपको प्रक्रियाओं को समाप्त करने के लिए एक अद्वितीय स्ट्रिंग की आवश्यकता होती है, और यदि आप केवल Process Name का उपयोग करते हैं, तो यह फ़ज़िंग प्रक्रिया को भी समाप्त कर देगा क्योंकि इसमें Process Name भी शामिल है।

**विंडोज़ पर फ़ाइल हैंडलर की गणना**

[AssocQueryString](https://github.com/sec-tools/WindowsFileHandlerEnumeration/) स्क्रिप्ट का उपयोग करके *assoc* कमांड के साथ फ़ाइल एक्सटेंशन को डिफ़ॉल्ट अनुप्रयोगों से मैप किया जा सकता है।```
C:\> .\AssocQueryString.ps1
...
.hlp :: C:\Windows\winhlp32.exe
.hta :: C:\Windows\SysWOW64\mshta.exe
.htm :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
.html :: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
.icc :: C:\Windows\system32\colorcpl.exe
.icm :: C:\Windows\system32\colorcpl.exe
.imesx :: C:\Windows\system32\IME\SHARED\imesearch.exe
.img :: C:\Windows\Explorer.exe
.inf :: C:\Windows\system32\NOTEPAD.EXE
.ini :: C:\Windows\system32\NOTEPAD.EXE
.iso :: C:\Windows\Explorer.exe

#### स्थानीय क्लाइंट

**localhost (Linux) पर SNMP क्लाइंट को फ़ज़ करें**

`litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3`

#### रिमोट क्लाइंट

**एक रिमोट FTP क्लाइंट को फ़ज़ करें (Linux)**

`while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done`

`litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -n 100`

नोट: लक्ष्य के आधार पर, क्लाइंट फ़ज़िंग के लिए एक विशेषाधिकार प्राप्त पोर्ट (1-1024) पर सुनने की आवश्यकता हो सकती है। इस स्थिति में, Linux पर आप या तो python इंटरप्रेटर पर `setcap cap_net_bind_service=+ep` सेट कर सकते हैं या फ़ज़र चलाते समय sudo का उपयोग कर सकते हैं, Mac पर बस sudo का उपयोग करें और Windows पर आप फ़ज़र को Administrator के रूप में चला सकते हैं ताकि Permission Denied त्रुटियों से बचा जा सके।

### सर्वर

#### त्वरित दृष्टि```
litefuzz -ls -c "./sc_serv shoutcast.conf" -a tcp://localhost:8000 -i input/shoutcast -o crashes/shoutcast -n 1000 -z
--========================--
--======| litefuzz |======--
--========================--

[STATS]
run id:     4001
cmdline:    ./sc_serv shoutcast.conf
address:    tcp://localhost:8000
crash dir:  crashes/shoutcast
input dir:  input/shoutcast
inputs:     3
iterations: 1000
mutator:    random(mutators)

@ 1000/1000 (1 crashes, 7 duplicates, ~0:00:00 remaining)

[RESULTS]
> completed (1000) iterations with (1) unique crashes and 7 dups
>> check crashes/shoutcast for more details

# ट्रॉफियां

Litefuzz ने विभिन्न सॉफ़्टवेयर पैकेजों से क्रैश को फ़ज़ किया है जैसे...

* antiword
* AppleScript (OS X)
* ArangoDB VelocyPack
* Avast authenticode-parser
* Avast RetDec
* BBC Audio Waveform
* ColorSync (OS X)
* Dynamsoft BarcodeReader
* eot2ttf
* evernote2md
* faad2
* Facebook's Origami Studio
* FontForge
* ForestDB
* Gifsicle
* GPUJPEG
* GPAC Multimedia Framework
* Google Draco
* Google Quipper
* GoPro GPR
* GtkRadiant
* IIPImage Server
* John The Ripper
* Kyoto Cabinet
* latex2rtf
* libMeshb
* libembroidery
* libsndfile
* Lion Vector Graphics (lvg)
* L-SMASH
* mp3-decoder
* MindNode
* minimp4
* MiniWeb Server
* MLpack
* Nvidia Data Center GPU Manager
* Numbers (OS X)
* OpenJPEG
* OpenOrienteering Mapper
* OSM Express
* Pages (OS X)
* PBRT-Parser
* Pixar USD
* Remote Apple Events (OS X)
* Samsung rlottie
* Samsung ThorVG
* Shoutcast Server
* Silo
* syslog (OS X)
* Tencent NCNN
* TinyXML2
* UEFITool
* Ulfius Web Framework
* zlib

# सामान्य प्रश्न

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

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

## आप कैसे जानते हैं कि फ़ज़र अच्छी तरह काम कर रहा है और क्या आपने इसकी तुलना दूसरों से की?
Litefuzz का उद्देश्य प्लेटफ़ॉर्म पर बग ढूँढना है। और यह करता भी है। इसलिए, ईमानदारी से कहें तो इसे फ़ज़रX या फ़ज़रY के विरुद्ध मापने की क्षमता को शामिल नहीं किया गया। कुछ व्यापार-बंद किए गए और शुरुआत में ही स्वीकार किए गए, अधिक जानकारी के लिए [#intro](https://github.com/sec-tools/litefuzz/blob/HEAD/README.md#intro) देखें।

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

## litefuzz कितना स्थिर है?
कमांड लाइन, GUI, नेटवर्क फ़ज़िंग (ज़्यादातर Linux और Mac पर), न्यूनीकरण आदि का काफी अच्छी तरह से परीक्षण किया गया है और कुल मिलाकर यह काफी ठोस होना चाहिए। कुछ अधिक विशिष्ट सुविधाएँ जैसे इंसुलेटेड नेटवर्क GUI फ़ज़िंग, Mac के लिए ReportCrash समर्थन और कुछ अन्य निचली सुविधाएँ प्रायोगिक मानी जानी चाहिए।

## क्या litefuzz के लिए असमर्थित परिदृश्य हैं?
हाँ, कुछ हैं। लेकिन अधिकांश या तो असामान्य परिदृश्य हैं जो बगी हैं, उन्हें "सही ढंग से काम करने" के लिए अधिक समय और शोध की आवश्यकता है, या प्लेटफ़ॉर्म से संबंधित कारणों से काम नहीं करते। उनमें से कई जब आप ऐसे विकल्पों के साथ चलाने का प्रयास करते हैं तो स्पष्ट रूप से "असमर्थित" संदेश के साथ बाहर निकलते हैं, और कुछ चेतावनियाँ ऊपर के अनुभागों में विभिन्न सुविधाओं का वर्णन करते समय बताई गई हैं। कुछ अधिक सूक्ष्म उदाहरणों में *इंसुलेटेड* ऐप्स पर रिप्रो मोड समर्थित नहीं है, और Mac ऐप्स पर इंसुलेट सुविधा का उपयोग करके सीमित परीक्षण किया गया है, Pyautogui Linux और Windows पर ठीक काम करता है लेकिन Mac पर यह बहुत विश्वसनीय साबित नहीं हुआ, इसलिए इसे कार्यात्मक रूप से असमर्थित मानें, और Windows पर क्लाइंट फ़ज़िंग अन्य प्लेटफ़ॉर्मों के अन्य मोड की तुलना में थोड़ा कम विश्वसनीय हो सकता है।

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

बेझिझक इस फ़ज़र को फ़ोर्क करें और ऐसे सुधार करें, वर्तमान में असमर्थित का समर्थन करें, आदि या छोटी लेकिन उपयोगी चीज़ों के लिए PRs करें।

## इस प्रोजेक्ट या इसके कोड के लिए क्या गारंटी दी जाती है?
बिल्कुल कोई नहीं। लेकिन इससे फ़ज़ करना और इसे आपको बग सौंपते देखना काफी मज़ेदार है।

## लेखक / संदर्भ
- [Jeremy Brown](https://github.com/sec-tools/litefuzz/blob/HEAD/jbrown3264%5BNOSPAM%5Dgmail)
- [macOS फ़ज़िंग के लिए स्लाइड डेक](https://www.slideshare.net/JeremyBrown37/summer-of-fuzz-macos)