Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

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

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
dtls-fuzzer — dtls-fuzzer DTLS सर्वर कार्यान्वयन के लिए एक प्रोटोकॉल-स्टेट-फज़र है। | Kitploit
उपकरण/GitLabGitLab/pfg666/dtls-fuzzer
फज़िंगनेटवर्क सुरक्षा
GitLabpfg666/dtls-fuzzer

dtls-fuzzer

dtls-fuzzer DTLS सर्वर कार्यान्वयन के लिए एक प्रोटोकॉल-स्टेट-फज़र है।

रिपॉजिटरी देखें
495 साल पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

dtls-fuzzer एक Java उपकरण है जो DTLS सर्वरों का प्रोटोकॉल स्थिति फज़िंग करता है। अधिक ठोस रूप से, यह निम्नलिखित कार्यक्षमता का समर्थन करता है:

  1. एक वर्णमाला (alphabet) दिए जाने पर, यह स्वचालित रूप से एक स्थानीय DTLS सर्वर कार्यान्वयन का एक मॉडल उत्पन्न कर सकता है;
  2. एक परीक्षण (इनपुट का अनुक्रम) और एक वर्णमाला दिए जाने पर, यह DTLS सर्वर कार्यान्वयन पर परीक्षण निष्पादित कर सकता है;
  3. यह एक बैच लर्निंग कार्य चला सकता है, जिसमें कई लर्निंग रन शामिल हैं।

dtls-fuzzer DTLS संदेशों को उत्पन्न/पार्स करने और स्थिति बनाए रखने के लिए TLS-Attacker का उपयोग करता है। इसके लिए, TLS-Attacker को DTLS के लिए समर्थन के साथ विस्तारित किया गया है। dtls-fuzzer TLS-Attacker के संस्करण 3.0b पर निर्भर करता है, जो DTLS संवर्धन को लागू करने वाला एक संस्करण है।

आर्टिफैक्ट सामग्री

आर्टिफैक्ट में शामिल है:

  1. dtls-fuzzer की फ़ाइल संरचना का विवरण, जिसमें स्रोत कोड और पेपर में प्रदर्शित के अनुरूप प्रायोगिक डेटा शामिल है;
  2. चुने गए SUT (सिस्टम अंडर टेस्ट)/ DTLS सर्वर कार्यान्वयन पर dtls-fuzzer का मूल्यांकन करने के लिए एक वॉकथ्रू।

dtls-fuzzer फ़ाइल संरचना

dtls-fuzzer की रूट निर्देशिका में सबसे महत्वपूर्ण फ़ोल्डर हैं:

  1. 'src', dtls-fuzzer का Java स्रोत कोड वाली निर्देशिका;
  2. 'examples', वर्णमालाओं, परीक्षणों, विनिर्देशों (अर्थात मॉडल), और तर्क फ़ाइलों के उदाहरणों वाली निर्देशिका, जिन्हें लर्निंग प्रयोग शुरू करने के लिए dtls-fuzzer को आपूर्ति की जा सकती है। इस निर्देशिका में फ़ाइलों का उपयोग लर्निंग प्रयोगों के इनपुट के रूप में किया जाता है;
  3. 'experiments', प्रयोगों से संबंधित डेटा वाली निर्देशिका। इस डेटा का कुछ भाग लर्निंग प्रयोगों के इनपुट के रूप में भी काम करता है। सबसे उल्लेखनीय फ़ोल्डर हैं:
    1. 'suts', Java SUTs के लिए बाइनरी के साथ। ये SUTs कस्टम-निर्मित DTLS सर्वर प्रोग्राम हैं जिनका स्रोत कोड सार्वजनिक रूप से उपलब्ध है;
    2. 'patches', वे पैच जो स्रोत कोड संकलित होने से पहले कुछ SUTs (विशेष रूप से उपयोगिताओं) पर लागू किए गए थे। इन पैच का प्राथमिक उद्देश्य लर्निंग के दौरान समय-प्रेरित व्यवहार को रोकना, SUT में कार्यक्षमता को सक्षम/अक्षम करना, और पूर्व-साझा कुंजी जैसे मापदंडों को कॉन्फ़िगर करना था;
    3. 'keystore', लर्निंग के दौरान उपयोग की जाने वाली कुंजी सामग्री (जैसे सार्वजनिक-निजी कुंजी जोड़े, Java कीस्टोर);
    4. 'results', प्रायोगिक परिणाम।

प्रायोगिक परिणाम

'experiments/results' में प्रायोगिक परिणाम शामिल हैं, जो कार्य का मुख्य आउटपुट हैं। विशेष रूप से

  • 'all_ciphers' में सभी चलाए गए प्रयोगों के लिए आउटपुट फ़ोल्डर शामिल हैं;
    • 'mapper' में प्रायोगिक परिणाम शामिल हैं जो किए गए कुछ मैपर निर्णयों को उचित ठहराने में मदद करते हैं (धारा 5.2 देखें)
  • 'included' में अभिसारी प्रयोगों के लिए आउटपुट फ़ोल्डर शामिल हैं (अभिसारी का अर्थ है कि लर्निंग सफलतापूर्वक एक मॉडल उत्पन्न करता है)।
    • ध्यान दें कि 'all_ciphers' में सभी प्रयोग सफल नहीं हुए/अंतिम मॉडल के साथ समाप्त नहीं हुए (हम ऐसे मामलों में कहते हैं कि लर्निंग अभिसारी नहीं हुई)

आउटपुट फ़ोल्डर

आउटपुट फ़ोल्डरों का नाम प्रयोग कॉन्फ़िगरेशन के आधार पर रखा गया है, अर्थात:

  • परीक्षण किया गया SUT/कार्यान्वयन;
  • उपयोग की गई वर्णमाला, कवर किए गए कुंजी विनिमय एल्गोरिदम के संदर्भ में, जहाँ 'all' इंगित करता है कि सभी 4 कुंजी विनिमय एल्गोरिदम का उपयोग किया गया था;
  • जहाँ लागू हो, क्या क्लाइंट प्रमाणन आवश्यक था (req), वैकल्पिक (nreq) या अक्षम (none);
  • परीक्षण एल्गोरिदम: रैंडम वॉक (rwalk) या इसका एक अनुकूलन (stests);
    • अनुकूलन का उपयोग करने वाले प्रयोगों को पेपर में शामिल नहीं किया गया है
  • वैकल्पिक रूप से, क्या पुनर्प्रेषण (retransmissions) को आउटपुट में शामिल/बाहर किया गया था (incl या excl)।
    • पुनर्प्रेषण डिफ़ॉल्ट रूप से शामिल थे

एक उदाहरण के रूप में, फ़ोल्डर का नाम 'jsse-12_rsa_cert_none_rwalk_incl' DTLS के JSSE 12 कार्यान्वयन पर एक प्रयोग को इंगित करता है, जिसमें RSA हैंडशेक करने के लिए इनपुट शामिल वर्णमाला का उपयोग किया गया है, क्लाइंट प्रमाणपत्र प्रमाणीकरण अक्षम है, परीक्षण एल्गोरिदम रैंडम वॉक है और पुनर्प्रेषण शामिल हैं।

एक आउटपुट फ़ोल्डर में शामिल है:

  • 'alphabet.xml', इनपुट वर्णमाला;
  • 'command.args', उपयोग की गई तर्क फ़ाइल जिसमें विभिन्न प्रयोग पैरामीटर हैं, विशेष रूप से:
    • queries, रैंडम वॉक परीक्षणों की संख्या की सीमा जो एक परिकल्पना को अंतिम माने जाने के लिए पास होनी चाहिए
    • equivalenceAlgorithms, नियोजित मॉडल-आधारित परीक्षण एल्गोरिदम
    • runWait और timeout, क्रमशः प्रारंभ और प्रतिक्रिया टाइमआउट (हम उन पर बाद में स्पर्श करते हैं)
  • 'sul.config', TLS-Attacker के लिए SUT-निर्भर कॉन्फ़िगरेशन, उसी कॉन्फ़िगरेशन का उपयोग TLS-Attacker का उपयोग करके अकेले SUT पर वर्कफ़्लो ट्रेस निष्पादित करने के लिए किया जा सकता है;
  • 'hyp[0-9]+.dot', मध्यवर्ती परिकल्पनाएँ;
  • 'statistics.txt', प्रयोग आँकड़े जैसे परीक्षणों की कुल संख्या, लर्निंग समय;
    • तालिका 4 यह डेटा प्रदर्शित करती है
  • 'nondet.log', सामना किए गए गैर-नियतात्मक व्यवहार के लॉग;
  • 'learnedModel.dot', लर्निंग अभिसारी होने की स्थिति में, सीखा गया मॉडल (अर्थात अंतिम परिकल्पना);
  • 'error.msg', एक त्रुटि संदेश जो प्रयोग विफल होने/लर्निंग रुक जाने की स्थिति में उत्पन्न होता है, और इसलिए, एक अंतिम मॉडल में अभिसारी नहीं होता है।
    • मुख्य दोषी समय-संबंधित गैर-नियतत्ववाद है (समान इनपुट विभिन्न परिणाम देते हैं)।

मूल्यांकनकर्ता जाँच सकता है (उदाहरण के लिए) कि 'included' में प्रायोगिक परिणाम तालिका 4 में प्रदर्शित के अनुरूप हैं, या तालिका 2 में परीक्षण किए गए कॉन्फ़िगरेशन भी 'all_ciphers' में दिखाई देते हैं। ध्यान दें कि पेपर में दिखाई देने वाले मॉडल महत्वपूर्ण छंटाई/ट्रिमिंग का परिणाम थे, जबकि आउटपुट फ़ोल्डरों में दिखाई देने वाले मॉडल अपरिवर्तित हैं।

dtls-fuzzer मूल्यांकन चरण

dtls-fuzzer का मूल्यांकन करने के उद्देश्य के लिए निम्नलिखित चरणों का पालन करना आवश्यक है:

  1. सुनिश्चित करें कि पूर्वापेक्षाएँ पूरी हों
  2. dtls-fuzzer स्थापित करें
  3. SUT सेटअप करें
  4. SUT के लिए मॉडल उत्पन्न करने के लिए dtls-fuzzer का उपयोग करें
  5. परिणामों का विश्लेषण करें

इस मूल्यांकन अनुभाग के बाद dtls-fuzzer का उपयोग करने पर एक मार्गदर्शिका दी गई है जो इसके मुख्य उपयोग मामलों का परिचय देती है।

पूर्वापेक्षाएँ सुनिश्चित करना

dtls-fuzzer का परीक्षण Ubuntu 18.04 और Debian 9 Linux वितरणों पर किया गया है। यह किसी भी हाल के Linux वितरण पर काम करना चाहिए। अन्य प्लेटफार्मों के लिए समर्थन का परीक्षण नहीं किया गया है। यह मार्गदर्शिका एक Debian-आधारित वितरण (जिसमें 'apt-get' है) का उपयोग करने की मानती है।

एक Java 8 JDK (जावा डेवलपमेंट किट) वर्चुअल मशीन (VM) की आवश्यकता है। प्रयोग चलाने के लिए उपयोग किया गया संस्करण 1.8.0_222 है, हालाँकि बाद के Java 8 संस्करणों को भी काम करना चाहिए। ध्यान दें कि उपकरण Java 9 या बाद के संस्करणों पर नहीं बनता है। हम निर्भरता प्रबंधन/तैनाती के लिए maven ('mvn' उपयोगिता) पर भी निर्भर हैं।

हम पर्याप्त रूप से शक्तिशाली मशीन का उपयोग करने की सलाह देते हैं, अन्यथा संवेदनशील समय पैरामीटर जैसे प्रतिक्रिया प्रतीक्षा समय, बहुत कम हो सकते हैं, जिससे पेपर में प्राप्त से भिन्न आउटपुट प्राप्त हो सकते हैं। इससे भी बदतर, वे लर्निंग प्रयोगों को विफल कर सकते हैं। मूल प्रयोग एक मल्टी-कोर सर्वर पर चलाए गए थे, हालाँकि, हम उम्मीद करते हैं (हालाँकि पूरी तरह से परीक्षण नहीं किया गया है) कि i7 प्रोसेसर वाले डेस्कटॉप पर लर्निंग संभव होनी चाहिए। समय मापदंडों को तदनुसार ट्यून करने पर कमजोर सिस्टम पर भी लर्निंग संभव है। अंत में, .dot मॉडल को .pdf में निर्यात करके विज़ुअलाइज़ करने के लिए graphviz लाइब्रेरी स्थापित करने की आवश्यकता है। यह माना जाता है कि graphviz द्वारा प्रदान की गई 'dot' उपयोगिता सिस्टम PATH में स्थित है।

संक्षेप में, सलाह दी गई पूर्वापेक्षाएँ हैं:

  • हालिया Linux वितरण, अधिमानतः Debian-आधारित
  • प्रयोग पुनरुत्पादन/विश्वसनीय लर्निंग के लिए डेस्कटॉप/सर्वर मशीन
  • (>=) 4 GB RAM
  • Java 8 JDK
  • maven
  • graphviz

वातावरण स्थापित करना

Java 8 JDK

dtls-fuzzer को Java 8 JDK (जावा डेवलपमेंट किट) की आवश्यकता है। यदि Java स्थापित नहीं है, तो हम OpenJDK कार्यान्वयन स्थापित करते हैं (Ubuntu पर 'apt-get' के माध्यम से), और इस उपधारा के शेष भाग को छोड़ सकते हैं।

root@kitploit:~
> sudo apt-get install openjdk-8-jdk

यदि java का कोई संस्करण स्थापित है, तो हम चला कर जाँच सकते हैं कि यह कौन सा संस्करण है:

root@kitploit:~
> java -version

संस्करण कोड 1.8 से शुरू होना चाहिए (जैसे 1.8.0_242), और वर्चुअल मशीन "Server VM" होनी चाहिए (यह दर्शाता है कि केवल रनटाइम वातावरण के बजाय पूर्ण JDK स्थापित है)। यदि ऐसा है, तो हम Java के साथ समाप्त हैं। यदि ऐसा नहीं है, तो हम जाँच सकते हैं कि Java 8 JDK हमारे प्लेटफ़ॉर्म पर स्थापित है लेकिन वर्तमान में चयनित नहीं है, चलाकर:

root@kitploit:~
> update-java-alternatives --list

यदि Java 8 JDK दिखाई देता है, तो हम उसी कमांड का उपयोग करके Java 8 JDK को डिफ़ॉल्ट Java कार्यान्वयन के रूप में कॉन्फ़िगर कर सकते हैं।

root@kitploit:~
> sudo update-java-alternatives --set java-1.8.0-openjdk-amd64

अन्यथा, हमें शुरुआत में दिखाए अनुसार पूर्ण स्थापना करने की आवश्यकता है। दुर्भाग्य से, 'update-java-alternatives' कभी-कभी सफल नहीं होता है, जैसा कि "error" संदेशों द्वारा इंगित किया गया है। यदि ऐसा मामला उत्पन्न होता है, तो हम यह अंतःक्रियात्मक रूप से कॉन्फ़िगर करने के लिए 'update-alternatives' का उपयोग कर सकते हैं कि 'java' (इंटरप्रेटर) और 'javac' (कंपाइलर) द्वारा कौन सी Java VM चुनी गई है।

root@kitploit:~
> sudo update-alternatives --config java
> sudo update-alternatives --config javac

अन्य

Java 8 सेट होने पर, हम अन्य निर्भरताओं, maven, graphviz और कुछ सामान्य SUT निर्भरताओं को स्थापित करने के लिए आगे बढ़ते हैं। फिर हम dtls-fuzzer के रिपॉजिटरी को पसंद के एक फ़ोल्डर में क्लोन करते हैं, आर्टिफैक्ट शाखा की जाँच करते हैं। समाप्त करने के लिए, हम उस फ़ोल्डर को अपनी वर्तमान निर्देशिका बनाते हैं।

root@kitploit:~
> sudo apt-get install maven graphviz autotools-dev automake libtool
> git clone  -b usenix20-artifact https://github.com/assist-project/dtls-fuzzer.git ~/dtls-fuzzer
> cd ~/dtls-fuzzer

dtls-fuzzer स्थापित करना

हम पहले 'prepare.sh' स्क्रिप्ट चलाते हैं जो dtls-fuzzer पर निर्भर लाइब्रेरीज़ स्थापित करती है, अर्थात् दो स्थानीय .jars और TLS-Attacker 3.0b। फिर हम उपकरण स्वयं स्थापित करते हैं। POSIX सिस्टम पर परिणामी कमांड होंगे:

root@kitploit:~
> bash prepare.sh
> mvn clean install

इन चरणों का पालन करने पर, 'target' नामक एक निर्देशिका बनाई जानी चाहिए जिसमें 'dtls-fuzzer.jar' हो। यह हमारी निष्पादन योग्य लाइब्रेरी है। इस बिंदु से आगे यह माना जाता है कि कमांड dtls-fuzzer की रूट निर्देशिका से चलाए जाते हैं।

त्वरित रन

मान लीजिए कि हम केवल PSK (पूर्व-साझा कुंजी) का उपयोग करके OpenSSL 1.1.1b के लिए एक मॉडल उत्पन्न करना चाहते हैं। dtls-fuzzer का एक त्वरित रन इस प्रकार है।

पहले हम SUT सेट करते हैं, जो एक 'setup_sut.sh' स्क्रिप्ट द्वारा स्वचालित रूप से किया जाता है।

root@kitploit:~
> bash setup_sut.sh openssl-1.1.1b

फिर हम 'args/openssl-1.1.1b' फ़ोल्डर से एक तर्क फ़ाइल चुनते हैं। हम देखते हैं कि चुनने के लिए कई तर्क फ़ाइलें हैं, अर्थात्:

root@kitploit:~
learn_openssl-1.1.1b_all_cert_none_rwalk_incl  
learn_openssl-1.1.1b_all_cert_nreq_rwalk_incl  
learn_openssl-1.1.1b_all_cert_req_rwalk_incl  
learn_openssl-1.1.1b_psk_rwalk_incl

रुचि की तर्क फ़ाइल 'learn_openssl-1.1.1b_psk_rwalk_incl' है, क्योंकि इसका फ़ाइल नाम PSK इंगित करता है। इस प्रकार हम इसे चुनते हैं, और उस पर फ़ज़र चलाते हैं। हम अतिरिक्त रूप से लर्निंग समय को छोटा करने के लिए परीक्षणों की संख्या 200 तक सीमित करते हैं। अंत में, OpenSSL के लिए, LD_LIBRARY_PATH को कार्यान्वयन की निर्देशिका ('suts/openssl-1.1.1b/') पर सेट करना होगा। लर्निंग चलाने से पहले, हम यह जाँचने के लिए एक सरल परीक्षण निष्पादित करना चाह सकते हैं कि हमारा सेटअप कार्य कर रहा है। एक अच्छा परीक्षण सिर्फ एक हैंडशेक पूरा करना है। हम तर्क फ़ाइल, और 'examples/tests' से संबंधित परीक्षण को पैरामीटर के रूप में प्रदान करते हैं। हमें मिलता है:

root@kitploit:~
>  LD_LIBRARY_PATH=suts/openssl-1.1.1b/ java -jar target/dtls-fuzzer.jar @args/openssl-1.1.1b/learn_openssl-1.1.1b_psk_rwalk_incl -test examples/tests/psk

यदि सब कुछ ठीक रहा, तो सर्वर ने "This is a hello message" प्रिंट किया होगा, जो हैंडशेक पूरा करने के बाद हम भेजते हैं। अपने सेटअप को कार्यशील जानते हुए, हम अब लर्निंग शुरू कर सकते हैं चलाकर:

root@kitploit:~
> LD_LIBRARY_PATH=suts/openssl-1.1.1b/ java -jar target/dtls-fuzzer.jar @args/openssl-1.1.1b/learn_openssl-1.1.1b_psk_rwalk_incl -queries 200

हम देखते हैं कि प्रयोग के लिए एक आउटपुट निर्देशिका, 'output/openssl-1.1.1b_psk_rwalk_incl/' बनाई गई है। हम प्रयोग की वर्तमान स्थिति (उत्पन्न परिकल्पनाओं की संख्या...) की जाँच करने के लिए इस निर्देशिका को 'ls' कर सकते हैं।

root@kitploit:~
> ls output/openssl-1.1.1b_psk_rwalk_incl/

जब चीजें सही होती हैं

यदि सब कुछ ठीक रहता है, तो 20-30 मिनट के बाद, आउटपुट निर्देशिका में एक 'learnedModel.dot' फ़ाइल होनी चाहिए। हम graphviz 'dot' उपयोगिता का उपयोग करके .pdf में निर्यात करके और अपने पसंदीदा .pdf व्यूअर के साथ .pdf खोलकर फ़ाइल को विज़ुअलाइज़ कर सकते हैं।

root@kitploit:~
> dot -Tpdf output/openssl-1.1.1b_psk_rwalk_incl/learnedModel.dot > output/openssl-1.1.1b_psk_rwalk_incl/learnedModel.pdf
> evince output/openssl-1.1.1b_psk_rwalk_incl/learnedModel.pdf

अंत में, हम मॉडल का एक बेहतर/ट्रिम किया गया संस्करण उत्पन्न करने के लिए 'trim_model.sh' का उपयोग कर सकते हैं। यह इस प्रकार किया जा सकता है:

root@kitploit:~
> bash trim_model.sh --output output/openssl-1.1.1b_psk_rwalk_incl/nicerLearnedModel.dot output/openssl-1.1.1b_psk_rwalk_incl/learnedModel.dot 
> dot -Tpdf output/openssl-1.1.1b_psk_rwalk_incl/nicerLearnedModel.dot > output/openssl-1.1.1b_psk_rwalk_incl/nicerLearnedModel.pdf
> evince output/openssl-1.1.1b_psk_rwalk_incl/nicerLearnedModel.pdf

अब हम विनिर्देश के विरुद्ध मॉडल की जाँच करके सिस्टम की अनुरूपता निर्धारित कर सकते हैं...

जब चीजें गलत होती हैं

आउटपुट निर्देशिका को 'ls' करते समय हमें 'error.msg' मिल सकता है। यह एक संकेत है कि प्रयोग विफल हो गया और लर्निंग अचानक समाप्त हो गई। ऐसे मामलों में सामग्री प्रदर्शित करने से विफलता के पीछे का कारण पता चलता है

root@kitploit:~
> cat output/openssl-1.1.1b_psk_rwalk_incl/error.msg

ध्यान दें कि अनुरूपता की जाँच अभी भी अंतिम उत्पन्न परिकल्पना पर की जा सकती है, जब तक कि संभावित निष्कर्षों को सिस्टम के विरुद्ध मान्य किया जाता है (जैसा कि उन्हें वैसे भी करना चाहिए)।

SUT सेटअप करना

हम SUT सेट करने के लिए एक स्क्रिप्ट प्रदान करते हैं। यह स्क्रिप्ट स्रोत फ़ाइलें डाउनलोड करती है, कुछ निर्भरताएँ (jvm) स्थापित करती है और SUT बनाती है। जिन SUTs के लिए स्वचालित सेटअप प्रदान किया गया है, उन्हें देखने के लिए चलाएँ:

root@kitploit:~
> bash setup_sut.sh

सेट अप करने के लिए, उदाहरण के लिए, Contiki-NG के tinydtls कार्यान्वयन को चलाएँ:

root@kitploit:~
> bash setup_sut.sh ctinydtls

स्क्रिप्ट dtls-fuzzer की रूट निर्देशिका में दो फ़ोल्डर उत्पन्न करेगी।

  • 'suts', जहाँ SUT बाइनरी तैनात की जाती हैं
  • 'modules', जहाँ कोई भी निर्भरता तैनात की जाती है

दुर्भाग्य से, SUT सेटअप को स्वचालित करना एक जटिल प्रक्रिया है, इसलिए हम निम्नलिखित शॉर्टकट लेते हैं। Java SUTs (JSSE, Scandium) के लिए हम कार्यान्वयन नहीं बनाते हैं, इसके बजाय हम 'experiments/suts' निर्देशिका से संकलित .jars का उपयोग करते हैं। ध्यान दें कि इन Java SUTs (सर्वर अनुप्रयोगों) का स्रोत कोड सार्वजनिक रूप से ऑनलाइन उपलब्ध है, Scandium और JSSE देखें, जो PionDTLS के लिए भी मामला है। स्वचालित रूप से निर्भरताएँ स्थापित करने से 'sudo' पहुंच का संकेत मिल सकता है। यह GnuTLS के लिए होता है जो बाहरी लाइब्रेरीज़ जैसे nettle पर निर्भर करता है, और Eclipse के TinyDTLS के लिए, जो autoconf पर निर्भर करता है। अंत में, हम NSS और PionDTLS के लिए स्वचालित सेटअप/तर्क फ़ाइलें प्रदान नहीं करते हैं क्योंकि इन प्रणालियों के लिए सेटअप कितना जटिल है।

समस्या निवारण

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

हम यहाँ विभिन्न SUTs की निर्भरताओं का एक अपूर्ण वृक्ष देते हैं। इटैलिक में वे निर्भरताएँ हैं जिन्हें 'setup_sut.sh' 'sudo' पहुंच का उपयोग करके स्थापित करने का प्रयास करता है।

  • GnuTLS:
    • m4
    • pkg-config
    • nettle
  • Eclipse का TinyDTLS
    • m4
    • autoconf
  • WolfSSL
    • m4
    • autoconf
    • libtool
  • nettle
    • m4
    • pkg-config
  • autoconf
    • aclocal
      • automake
      • autotools-dev

एक SUT कॉन्फ़िगरेशन सीखना

अब हम एक SUT कॉन्फ़िगरेशन सीखने के लिए तैयार हैं। विभिन्न SUT कॉन्फ़िगरेशन के लिए तर्क फ़ाइलें dtls-fuzzer की होम निर्देशिका में स्थित 'args' निर्देशिका में प्रदान की गई हैं। प्रत्येक तर्क फ़ाइल का नाम प्रयोग सेटअप (SUT, वर्णमाला, प्रमाणीकरण) का वर्णन करता है जैसा कि 'experiments/results/' में आउटपुट फ़ोल्डर नामों द्वारा वर्णित है। एक तर्क फ़ाइल का उपयोग करके SUT के लिए लर्निंग शुरू करने के लिए, चलाएँ:

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file

आउटपुट फ़ोल्डर एक उत्पन्न 'output' निर्देशिका में संग्रहीत किया जाएगा।

पैरामीटर अनुकूलन

परीक्षण सीमा

पेपर में प्रयोगों की तुलना में, हमने कम शक्तिशाली हार्डवेयर के अनुकूलन के रूप में कई SUTs के लिए प्रतिक्रिया टाइमआउट बढ़ा दिया। लर्निंग समय को छोटा करने के लिए, हम रैंडम वॉक एल्गोरिदम की परीक्षण सीमा को 20000 से घटाकर 5000 करने का सुझाव देते हैं। यह इस प्रकार किया जा सकता है:

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file -queries 5000

यह तर्क फ़ाइल में सीमा सेटिंग को अधिलेखित कर देगा। GnuTLS, PionDTLS और JSSE के अलावा, हम उम्मीद करते हैं कि इस कम सीमा के लिए लर्निंग समान मॉडल उत्पन्न करेगी।

समय पैरामीटर

समय एक समस्या बन सकता है, जिससे गैर-नियतत्ववाद हो सकता है, इसके बाद एक सूचनात्मक 'error.msg' फ़ाइल के साथ अचानक समाप्ति हो सकती है। ऐसे मामलों में, दो समायोजन हैं जिन्हें ट्वीक किया जा सकता है:

  1. प्रतिक्रिया टाइमआउट (सर्वर के मौन होने का निष्कर्ष निकालने से पहले प्रत्येक प्रतिक्रिया की प्रतीक्षा का समय);
  2. प्रारंभ टाइमआउट (सर्वर के शुरू होने की प्रतीक्षा का समय)।

इन पैरामीटरों को तर्क फ़ाइल में संबंधित सेटिंग्स को अधिलेखित करके समायोजित किया जा सकता है (संभवतः उच्च मान के साथ):

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file -timeout new_response_timeout -runWait new_start_timeout

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

लर्निंग समय

हम एक निश्चित अवधि के बाद प्रयोगों को स्वचालित रूप से समाप्त करना चाह सकते हैं, विशेष रूप से उन प्रयोगों को जिनके कभी समाप्त होने की उम्मीद नहीं है। इस अवधि को समय सीमा पैरामीटर के माध्यम से सेट करना संभव है, जिसे प्रयोग को चलाने की अधिकतम अवधि सौंपी गई है। यह अवधि ISO 8601 प्रारूप में प्रदान की गई है। एक प्रयोग के निष्पादन समय को 60 मिनट तक सीमित करने के लिए, हम चलाएंगे:

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @args/sut_name/arg_file -timeLimit "PT60M"

समवर्ती प्रयोग और पोर्ट टकराव

एक समय में कई प्रयोग चलाना संभव है, बशर्ते कि सर्वर विभिन्न पोर्ट पर सुनने के लिए कॉन्फ़िगर किए गए हों। हम प्रत्येक प्रयोग को एक अलग टर्मिनल में लॉन्च करना चुन सकते हैं। वैकल्पिक रूप से, हम 'disown' उपयोगिता का उपयोग करके एक ही टर्मिनल में प्रयोग लॉन्च कर सकते हैं:

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @args/ctinydtls/learn_ctinydtls_psk_rwalk 1>/dev/null 2>&1 & disown

हालाँकि, कुछ (>2) से अधिक चलाने से मशीन पर अतिरिक्त बोझ पड़ता है। यह आकस्मिक पोर्ट टकराव के कारण लर्निंग विफलता की संभावना भी बढ़ाता है। अधिकांश कॉन्फ़िगरेशन में, सर्वर लोकलहोस्ट पर कुछ हार्ड-कोडेड पोर्ट पर सुनने के लिए कॉन्फ़िगर किए गए हैं, 'args' में प्रदान किए गए कॉन्फ़िगरेशन विशिष्ट हार्ड-कोडेड पोर्ट का उपयोग करते हैं। JSSE और Scandium कॉन्फ़िगरेशन के लिए, सेटअप अलग है। प्रत्येक परीक्षण पर, SUT एक गतिशील रूप से चुने गए पोर्ट पर सुनने वाला एक सर्वर लॉन्च करता है और dtls-fuzzer को TCP सॉकेट पर पोर्ट संचारित करता है। इसका लाभ यह है कि dtls-fuzzer को सूचित करना कि सर्वर पैकेट प्राप्त करने के लिए कब तैयार है (इसके अभाव में, dtls-fuzzer को सर्वर के शुरू होने के लिए आँख बंद करके एक मनमाना समय प्रतीक्षा करनी होगी)। नकारात्मक पक्ष यह है कि आवंटित पोर्ट किसी भिन्न प्रयोग के किसी हार्ड-कोडेड पोर्ट के समान हो सकता है, जहाँ एक सर्वर थ्रेड को हाल ही में रोका गया है और एक नया थ्रेड अभी तक शुरू नहीं किया गया है (जिसका अर्थ है कि हार्ड-कोडेड पोर्ट का उपयोग गतिशील आवंटन में किया जा सकता है)। इस प्रकार के टकराव से बचने के लिए, हम Scandium और JSSE प्रयोगों को अन्य सभी से अलग चलाने की सलाह देते हैं।

सुझाए गए कॉन्फ़िगरेशन

हम निम्नलिखित कॉन्फ़िगरेशन सुझाते हैं जिनके लिए स्वचालित निर्माण विश्वसनीय है, लर्निंग तेज़ है या दिलचस्प बग पाए गए हैं। कमांड चलाने से पहले सुनिश्चित करें कि आपने SUT सेट किया है। आप देखेंगे कि हम जहाँ संभव हो PSK कॉन्फ़िगरेशन पर ध्यान केंद्रित करते हैं। ऐसा इसलिए है क्योंकि छोटे पासवर्ड वाले PSK को किसी भी अन्य एन्क्रिप्शन तंत्र की तुलना में काफी कम प्रसंस्करण समय की आवश्यकता होती है।### OpenSSL 1.1.1b कोई भी openssl-1.1.1b कॉन्फ़िगरेशन (उदाहरण के लिए 'args/openssl-1.1.1b/learn_openssl-1.1.1b_all_cert_req_rwalk_incl') आज़माया जा सकता है। प्रयोग जल्दी समाप्त होते हैं (एक दिन से कम), सभी कुंजी विनिमय एल्गोरिदम का अभ्यास करते हुए। सभी (PSK, RSA, ECDH, DH) कुंजी विनिमय एल्गोरिदम का उपयोग करते हुए क्लाइंट प्रमाणपत्र आवश्यक कॉन्फ़िगरेशन के लिए कमांड:

root@kitploit:~
> LD_LIBRARY_PATH=suts/openssl-1.1.1b/ java -jar target/dtls-fuzzer.jar @args/openssl-1.1.1b/learn_openssl-1.1.1b_all_cert_req_rwalk_incl -queries 5000

ध्यान दें, OpenSSL सीखते समय LD_LIBRARY_PATH वेरिएबल को इंस्टॉलेशन निर्देशिका की ओर इंगित करना आवश्यक है।

MbedTLS 2.16.1

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

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @args/mbedtls-2.16.1/learn_mbedtls_all_cert_none_rwalk_incl -queries 5000

Contiki-NG TinyDTLS PSK का उपयोग करते हुए

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

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @args/ctinydtls/learn_ctinydtls_psk_rwalk -queries 2000

WolfSSL 4.0.0 PSK का उपयोग करते हुए

WolfSSL के लिए हम एक PSK कॉन्फ़िगरेशन प्रदान करते हैं जिसके लिए सीखना अपेक्षाकृत जल्दी समाप्त होना चाहिए।

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @args/wolfssl-4.0.0/learn_wolfssl-4.0.0_psk_rwalk -queries 2000

GnuTLS 3.6.7 क्लाइंट प्रमाणीकरण अक्षम के साथ

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

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @args/gnutls-3.6.7/learn_gnutls-3.6.7_all_cert_none_rwalk_incl -queries 2000

Scandium PSK (बग फिक्स से पहले)

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

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @args/scandium-2.0.0/learn_scandium-2.0.0_psk_rwalk -queries 2000

JSSE 12.0.2 प्रमाणीकरण आवश्यक के साथ

इस कॉन्फ़िगरेशन के लिए प्राप्त मॉडल का एक संशोधित संस्करण पेपर में दिखाई देता है। मॉडल महत्वपूर्ण बगों को उजागर करता है। प्रयोग को Scandium या JSSE से संबंधित प्रयोगों के समानांतर नहीं चलाया जाना चाहिए। ध्यान दें कि JSSE के लिए सीखना समाप्त/अभिसरित नहीं होता, अधिक से अधिक अवस्थाओं वाली परिकल्पनाएँ बनाता है। इसलिए हमने JSSE प्रयोगों को एक दिन के बाद स्वचालित रूप से समाप्त करने के लिए कॉन्फ़िगर किया (पेपर में दो दिन)। RSA कुंजी विनिमय के लिए कमांड:

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @args/jsse-12/learn_jsse-12_rsa_cert_req_rwalk_incl 

कठिन सीखने के बजाय, हम केवल यह परीक्षण करना चाह सकते हैं कि क्या इस सेटिंग में बिना कोई प्रमाणपत्र संदेश भेजे हैंडशेक पूरा किया जा सकता है। यह चलाकर किया जा सकता है:

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @args/jsse-12/learn_jsse-12_rsa_cert_req_rwalk_incl -test examples/tests/rsa

परिणामों का विश्लेषण

सीखना पूरा होने के बाद, आउटपुट निर्देशिका में विश्लेषण करने योग्य चीज़ें हैं:

  • 'statistics.txt', प्रयोग आँकड़े जैसे परीक्षणों की कुल संख्या, सीखने का समय;
  • 'nondet.log', सामने आए गैर-नियतात्मक व्यवहार के लॉग, यदि सब कुछ ठीक रहा तो यह खाली होना चाहिए;
  • 'learnedModel.dot', सीखा गया मॉडल (या अंतिम परिकल्पना) जो सफल समाप्ति पर उत्पन्न होता है;
  • 'hyp[0-9]+.dot', मध्यवर्ती परिकल्पनाएँ;
  • 'error.msg', यदि कुछ बुरा हुआ जिसने सीखना रोक दिया। यदि सीखने का प्रयोग समय समाप्त हो जाता है तो भी उत्पन्न होता है।

मॉडल का विज़ुअलाइज़ेशन

.dot सीखे गए मॉडल को graphviz लाइब्रेरी का उपयोग करके, .pdf में रूपांतरण द्वारा विज़ुअलाइज़ किया जा सकता है:

root@kitploit:~
> dot -Tpdf learnedModel.dot  > learnedModel.pdf

दुर्भाग्य से, जैसे-जैसे मॉडल आकार में बढ़ते हैं, इस विधि से उत्पन्न .pdf पढ़ने में कठिन होते जाते हैं। इसलिए हमने प्रूनिंग स्क्रिप्ट विकसित/उपयोग/आयात की हैं जिन्हें 'trim_model.sh' द्वारा एक्सेस किया जाता है। स्क्रिप्ट चलाकर उपयोग की जानकारी प्रदान करती है:

root@kitploit:~
> bash trim_model.sh

हम स्क्रिप्ट को उसके सबसे बुनियादी रूप में उपयोग करने की सलाह देते हैं, जो है:

root@kitploit:~
> bash trim_model.sh learnedModel.dot 

स्क्रिप्ट:

  1. अवस्थाओं और इनपुट/आउटपुट लेबल को संक्षिप्त करती है
  2. हैंडशेक पूर्णता की ओर ले जाने वाले पथों को रंग देती है
    • उपयोगकर्ता को यह निर्धारित करना चाहिए कि क्या हैंडशेक कॉन्फ़िगरेशन को देखते हुए कानूनी हैं
  3. समान अवस्थाओं को जोड़ने वाले, समान आउटपुट लेकिन भिन्न इनपुट वाले 3 या अधिक संक्रमणों के समूहों को 'Other' इनपुट के अंतर्गत मर्ज करती है
  4. (वैकल्पिक) उन अवस्थाओं को प्रून करती है जहाँ से हैंडशेक अब पूरा नहीं किया जा सकता (विशेष रूप से JSSE के लिए उपयोगी)
  5. (वैकल्पिक) समान अवस्थाओं को जोड़ने वाले संक्रमणों को एक ही किनारे पर रखती है

(5) के लिए 'experiments\scripts' में पाई जाने वाली कस्टम mypydot Python 3 लाइब्रेरी स्थापित करना आवश्यक है। अन्य सभी चरण सादे 'sed' और dot-trimmer Java लाइब्रेरी का उपयोग करते हैं। इस लाइब्रेरी का .jar 'experiments\scripts' में शामिल है।

सामान्य dtls-fuzzer वॉकथ्रू

सहायता पृष्ठ प्रदर्शित करना

चलाएँ:

root@kitploit:~
> java -jar target/dtls-fuzzer.jar -help

DTLS कार्यान्वयन सीखना

विकल्पों की संख्या भारी हो सकती है। DTLS सर्वर कार्यान्वयन सीखने के लिए, केवल कुछ विकल्प निर्दिष्ट करने की आवश्यकता है, अर्थात्: "-connect ip_address:port" जो चल रहे DTLS सर्वर का पता है। अन्य सभी विकल्प डिफ़ॉल्ट मानों पर सेट हैं, जिसमें वर्णमाला भी शामिल है।

एकल सीखने का रन

किसी मौजूदा स्थानीय सर्वर कार्यान्वयन के लिए जो पोर्ट 20000 पर सुन रहा है, सीखने का रन लॉन्च करने के लिए चलाएँ:

root@kitploit:~
> java -jar target/dtls-fuzzer.jar -connect localhost:20000

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

root@kitploit:~
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -cmd "openssl s_server -accept 20000 -dtls1_2"

इतने सारे पैरामीटरों के साथ, कमांड बहुत लंबी हो सकती हैं। dtls-fuzzer तर्कों को पार्स करने के लिए JCommander का उपयोग करता है, जो एक फ़ाइल से पैरामीटर भी पढ़ सकता है। तर्कों के उदाहरणों के लिए 'experiments/args' पर जाएँ। dtls-fuzzer को तर्क फ़ाइल प्रदान करने के लिए इसे पैरामीटर के रूप में "@" से पहले प्रदान करें। आप कमांड में अन्य स्पष्ट तर्क भी जोड़ सकते हैं (जो तर्क फ़ाइल में उन्हें अधिलेखित कर देंगे)

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @arg_file ...overwriting params...

बैच सीखना

सीखने के रनों का एक बैच लॉन्च करने के लिए, 'experiments/scripts' में 'launcher.py' स्क्रिप्ट का उपयोग किया जा सकता है। तर्क फ़ाइलों वाली एक निर्देशिका प्रदान करने पर, उपकरण प्रत्येक तर्क फ़ाइल के लिए एक सीखने की प्रक्रिया लॉन्च करेगा।

root@kitploit:~
> python3 experiments/scripts/launcher.py --jar target/dtls-fuzzer.jar --args args_folder

परीक्षण सूट चलाना

सीखने के प्रयोग चलाने से पहले, यह जाँचने में मदद मिलती है कि तर्क सही ढंग से सेट हैं, विशेष रूप से समय पैरामीटर। इसके लिए, dtls-fuzzerr SUT पर एक कस्टम परीक्षण सूट (परीक्षणों का संग्रह) निष्पादित कर सकता है, और आउटपुट का सारांश प्रदान कर सकता है। इस कार्यक्षमता का उपयोग असफल सीखने के प्रयोगों का निदान करते समय भी किया जा सकता है, अर्थात यह पता लगाना कि क्या गलत हुआ।

डिफ़ॉल्ट वर्णमाला का उपयोग करके सर्वर पर परीक्षण सूट चलाने के लिए, आप चला सकते हैं:

root@kitploit:~
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file

परीक्षण फ़ाइलों के उदाहरणों के लिए, 'examples/tests' पर जाएँ। एक परीक्षण फ़ाइल में न्यूलाइन-पृथक इनपुट की सूची होती है। परीक्षण खाली नई पंक्तियों द्वारा अलग किए जाते हैं। प्रत्येक परीक्षण का अंत या तो फ़ाइल का अंत है, या एक खाली नई पंक्ति है। एक पंक्ति को टिप्पणी करने के लिए "#" का उपयोग किया जाता है।

यदि आपके पास एक मॉडल/विनिर्देश है, तो आप परीक्षण सूट भी चला सकते हैं और आउटपुट की तुलना विनिर्देश में दिए गए आउटपुट से कर सकते हैं।

root@kitploit:~
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file -specification model

परीक्षणों के चलने की संख्या '-times' पैरामीटर द्वारा कॉन्फ़िगर करने योग्य है, जो डिफ़ॉल्ट रूप से 1 है। इसे उच्च संख्या पर सेट करने से प्रत्येक परीक्षण के आउटपुट की तुलना करके सीखने के कॉन्फ़िगरेशन में गैर-नियतत्ववाद का पता लगाने में मदद मिलती है।

root@kitploit:~
> java -jar target/dtls-fuzzer.jar -connect localhost:20000 -test test_file -times 10

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

root@kitploit:~
> java -jar target/dtls-fuzzer.jar @learning_arg_file -test test_file
टूल डाउनलोड करें