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

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

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

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

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

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
krackattacks-scripts — संशोधित hostapd और मॉनिटर-मोड फ्रेम रीप्ले का उपयोग करके KRACK कुंजी पुनर्स्थापना भेद्यताओं के लिए WPA2 क्लाइंट्स और APs को सत्यापित करने वाली स्क्रिप्ट्स। | Kitploit
उपकरण/GitHubGitHub/vanhoefm/krackattacks-scripts
वाई-फाई ऑडिटिंगभेद्यता विश्लेषणवायरलेस सुरक्षापेनिट्रेशन टेस्टिंग
GitHubvanhoefm/krackattacks-scripts

krackattacks-scripts

संशोधित hostapd और मॉनिटर-मोड फ्रेम रीप्ले का उपयोग करके KRACK कुंजी पुनर्स्थापना भेद्यताओं के लिए WPA2 क्लाइंट्स और APs को सत्यापित करने वाली स्क्रिप्ट्स।

रिपॉजिटरी देखें
3.5k7671 साल पहलेKitploit द्वारा समीक्षित

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

सभी देखें →

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

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

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

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

यह प्रोजेक्ट स्क्रिप्ट्स प्रदान करता है जो यह जाँचने के लिए हैं कि क्या क्लाइंट या एक्सेस पॉइंट्स (APs) WPA2 के विरुद्ध KRACK हमले से प्रभावित हैं। इस हमले के पीछे के विवरण के लिए हमारी वेबसाइट देखें और शोध पत्र।

याद रखें कि हमारी स्क्रिप्ट्स हमले वाली स्क्रिप्ट्स नहीं हैं! यह जाँचने के लिए कि क्या कोई एक्सेस पॉइंट या क्लाइंट KRACK हमले से प्रभावित है, आपको उपयुक्त नेटवर्क क्रेडेंशियल्स की आवश्यकता होगी।

दिसंबर 2024: 7वें टेस्ट ./krack-test-client.py --gtkinit में एक बग ठीक किया गया है। इस बगफिक्स से पहले, यह उल्लेख किया गया था कि यह टेस्ट (इसका आउटपुट) अविश्वसनीय था, लेकिन अब नए निर्देशों का पालन करने पर आउटपुट भरोसेमंद होना चाहिए। अर्थात, जब यह टेस्ट अब संकेत देता है कि डिवाइस संवेदनशील है, तो वह वास्तव में संभावतः संवेदनशील है।

जनवरी 2021: स्क्रिप्ट्स को Python3 के साथ संगत बनाया गया है और नए Linux वितरणों को बेहतर समर्थन देने के लिए अद्यतन किया गया है। यदि आप पुराने संस्करण पर वापस जाना चाहते हैं, तो रिपॉजिटरी को क्लोन करने के बाद git fetch --tags && git checkout v1 निष्पादित करें (और git checkout research का उपयोग करके नवीनतम संस्करण पर वापस जाएँ)।

पूर्वापेक्षाएँ

हमारी स्क्रिप्ट्स का परीक्षण Kali Linux पर किया गया था। Kali पर आवश्यक निर्भरताएँ स्थापित करने के लिए, निष्पादित करें:

root@kitploit:~
sudo apt update
sudo apt install libnl-3-dev libnl-genl-3-dev pkg-config libssl-dev net-tools git sysfsutils python3-venv iw

अब हमारे संशोधित hostapd इंस्टेंस को कंपाइल करें और एक python वर्चुअल वातावरण बनाएँ। यह सुनिश्चित करता है कि आप संगत python लाइब्रेरीज़ (जो krackattack/requirements.txt में सूचीबद्ध हैं) का उपयोग कर रहे हैं:

root@kitploit:~
git clone https://github.com/vanhoefm/krackattacks-scripts.git
cd krackattacks-scripts/krackattack
./build.sh
./pysetup.sh

फिर बेहतर परिणामों के लिए हार्डवेयर एन्क्रिप्शन अक्षम करें:

root@kitploit:~
cd krackattack
sudo ./disable-hwcrypto.sh

ध्यान दें कि यदि आवश्यक हो तो आप बाद में sudo ./reenable-hwcrypto.sh स्क्रिप्ट का उपयोग करके हार्डवेयर एन्क्रिप्शन को पुनः सक्षम कर सकते हैं। हार्डवेयर एन्क्रिप्शन अक्षम करने के बाद रिबूट करने की अनुशंसा की जाती है। हमने अपनी स्क्रिप्ट्स का परीक्षण Kali Linux पर Intel Dual Band Wireless-AC 7260 और TP-Link TL-WN722N v1 के साथ किया।

हर उपयोग से पहले

हर बार स्क्रिप्ट्स का उपयोग करने से पहले आपको अपने नेटवर्क मैनेजर में Wi-Fi अक्षम करना होगा। फिर निष्पादित करें:

root@kitploit:~
sudo rfkill unblock wifi
cd krackattack
sudo su
source venv/bin/activate

ऐसा करने के बाद आप स्क्रिप्ट्स को कई बार निष्पादित कर सकते हैं, जब तक आप टर्मिनल को बंद नहीं करते।

यदि आप disable-hwcrypto.sh के प्रभावों को पूर्ववत करना चाहते हैं, तो फ़ाइल /etc/modprobe.d/nohwcrypt.conf को हटा दें।

क्लाइंट्स का परीक्षण

पहले hostapd/hostapd.conf को संशोधित करें और टेस्ट निष्पादित करने के लिए उपयोग किए जाने वाले Wi-Fi इंटरफ़ेस को निर्दिष्ट करने हेतु interface= लाइन को संपादित करें। ध्यान दें कि सभी टेस्टों के लिए, एक बार स्क्रिप्ट चलने के बाद, आपको परीक्षण किए जा रहे डिवाइस को पासवर्ड abcdefgh का उपयोग करके SSID testnetwork से कनेक्ट करने देना होगा। आप hostapd/hostapd.conf को संशोधित करके AP की सेटिंग्स बदल सकते हैं। सभी टेस्टों में क्लाइंट को Wi-Fi नेटवर्क से कनेक्ट होने के बाद IP प्राप्त करने के लिए DHCP का उपयोग करना चाहिए। ऐसा इसलिए है क्योंकि कुछ टेस्ट केवल क्लाइंट द्वारा DHCP का उपयोग करके IP का अनुरोध करने के बाद ही शुरू होते हैं!

अब आपको krackattacks/ निर्देशिका में स्थित निम्नलिखित टेस्ट चलाने चाहिए:

  1. ./krack-test-client.py --replay-broadcast। यह जाँचता है कि क्या क्लाइंट रीप्ले किए गए ब्रॉडकास्ट फ्रेम्स को स्वीकार करता है। यदि क्लाइंट रीप्ले किए गए ब्रॉडकास्ट फ्रेम्स को स्वीकार करता है, तो इसे पहले पैच किया जाना चाहिए। यदि आप क्लाइंट को पैच नहीं करते हैं, तो हमारी स्क्रिप्ट यह निर्धारित नहीं कर पाएगी कि ग्रुप की पुनः स्थापित हो रही है या नहीं (क्योंकि तब स्क्रिप्ट हमेशा कहेगी कि ग्रुप की पुनः स्थापित हो रही है)।

  2. ./krack-test-client.py --group --gtkinit। यह जाँचता है कि क्या क्लाइंट दिए गए रिसीव सीक्वेंस काउंटर (RSC) के साथ ग्रुप की हैंडशेक में ग्रुप की स्थापित करता है। इस संवेदनशीलता के पीछे के विवरण के लिए हमारे अनुवर्ती शोध पत्र का खंड 6.4 देखें।

  3. ./krack-test-client.py --group। यह जाँचता है कि क्या क्लाइंट ग्रुप की हैंडशेक में ग्रुप की को पुनः स्थापित करता है। दूसरे शब्दों में, यह जाँचता है कि क्या क्लाइंट CVE-2017-13080 के प्रति संवेदनशील है। स्क्रिप्ट पहले से उपयोग किए गए (रीप्ले किए गए) पैकेट नंबर (यहाँ पैकेट नंबर = nonce = IV) का उपयोग करके क्लाइंट को ब्रॉडकास्ट ARP अनुरोध भेजकर ग्रुप की की पुनः स्थापनाओं का परीक्षण करती है। ध्यान दें कि यदि क्लाइंट हमेशा रीप्ले किए गए ब्रॉडकास्ट फ्रेम्स को स्वीकार करता है (देखें --replay-broadcast), तो यह टेस्ट गलत निष्कर्ष निकाल सकता है कि ग्रुप की पुनः स्थापित हो रही है।

  4. ./krack-test-client.py। यह क्लाइंट को बार-बार एन्क्रिप्टेड मैसेज 3 भेजकर 4-way हैंडशेक में की पुनः स्थापनाओं का परीक्षण करता है। दूसरे शब्दों में, यह CVE-2017-13077 (सबसे अधिक प्रभाव वाली संवेदनशीलता) और CVE-2017-13078 के लिए परीक्षण करता है। स्क्रिप्ट यह देखने के लिए क्लाइंट द्वारा भेजे गए ट्रैफिक की निगरानी करती है कि क्या पेयरवाइज़ की पुनः स्थापित हो रही है। ध्यान दें कि यह प्रभावी रूप से दो परीक्षण करता है: क्या पेयरवाइज़ की पुनः स्थापित होती है, और क्या ग्रुप की पुनः स्थापित होती है। ग्रुप की पुनः स्थापना परीक्षण शुरू करने के लिए सुनिश्चित करें कि क्लाइंट DHCP का उपयोग करके IP का अनुरोध करता है। यह सुनिश्चित करने के लिए कि क्लाइंट पर्याप्त यूनिकास्ट फ्रेम्स भेज रहा है, आप वैकल्पिक रूप से AP को पिंग कर सकते हैं: ।

कुछ अतिरिक्त टिप्पणियाँ:

  • सबसे महत्वपूर्ण टेस्ट ./krack-test-client है, जो 4-way हैंडशेक में सामान्य की पुनः स्थापनाओं का परीक्षण करता है।

  • इन टेस्टों को कम हस्तक्षेप वाले कमरे में करें। अधिक मात्रा में पैकेट लॉस इस स्क्रिप्ट को कम विश्वसनीय बना देगा!

  • वैकल्पिक रूप से आप स्क्रिप्ट के आउटपुट की पुष्टि करने के लिए नेटवर्क ट्रैफिक की मैन्युअल रूप से जाँच कर सकते हैं (कुछ Wi-Fi NICs हमारी स्क्रिप्ट्स में हस्तक्षेप कर सकते हैं):

    • यह पुष्टि करने के लिए कि हमारी स्क्रिप्ट (AP) उचित पैकेट नंबरों (IVs) का उपयोग करके फ्रेम्स भेजती है, मॉनिटर मोड में एक अतिरिक्त Wi-Fi NIC का उपयोग करें। विशेष रूप से, जाँचें कि क्या रीप्ले किए गए ब्रॉडकास्ट फ्रेम्स वास्तव में पहले से उपयोग किए गए पैकेट नंबर (IV) के साथ भेजे जाते हैं।

    • क्लाइंट द्वारा भेजे गए फ्रेम्स के IVs की निगरानी करके पेयरवाइज़ की पुनः स्थापनाओं की जाँच करने के लिए मॉनिटर मोड में एक अतिरिक्त Wi-Fi NIC का उपयोग करें।

    • यह देखने के लिए कि रीप्ले किए गए ब्रॉडकास्ट ARP अनुरोध स्वीकार किए जाते हैं या नहीं, क्लाइंट पर ट्रैफिक कैप्चर करें।

  • यदि क्लाइंट कई Wi-Fi रेडियो/NICs का उपयोग कर सकता है, तो कई Wi-Fi NICs का उपयोग करके परीक्षण करें।

  • अधिक डीबगिंग आउटपुट के लिए आप --debug पैरामीटर जोड़ सकते हैं।

  • सभी अपरिचित पैरामीटर hostapd को पास कर दिए जाते हैं, इसलिए आप hostapd को सभी डीबग जानकारी आउटपुट करने के लिए -dd -K जैसा कुछ शामिल कर सकते हैं।

Wi-Fi Alliance परीक्षणों से संगति

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

  • 4.1.1 (EAPOL मैसेज 3 का प्लेनटेक्स्ट पुनः प्रेषण)। हम वर्तमान में इस टेस्ट का समर्थन नहीं करते हैं। यह टेस्ट वैसे भी आवश्यक नहीं है। सुनिश्चित करें कि परीक्षण किया जा रहा डिवाइस टेस्ट 4.1.3 पास करता है, और फिर यह इस टेस्ट को भी पास कर लेगा।

  • 4.1.2 (EAPOL M3 का प्लेनटेक्स्ट में तत्काल पुनः प्रेषण)। हम वर्तमान में इस टेस्ट का समर्थन नहीं करते हैं। फिर से, सुनिश्चित करें कि परीक्षण किया जा रहा डिवाइस टेस्ट 4.1.3 पास करता है, और फिर यह इस टेस्ट को भी पास कर लेगा।

  • 4.1.3 (पेयरवाइज़ रीकी हैंडशेक के दौरान एन्क्रिप्टेड EAPOL M3 का तत्काल पुनः प्रेषण)। यह ./krack-test-client.py से मेल खाता है, सिवाय इसके कि एन्क्रिप्टेड EAPOL M3 तत्काल के बजाय आवधिक रूप से भेजे जाते हैं।

  • 4.1.5 (4-way हैंडशेक में PTK पुनः स्थापना जब STA टेम्पोरल PTK निर्माण का उपयोग करता है, समान ANonce)। इस टेस्ट को ./krack-test-client.py --tptk का उपयोग करके निष्पादित करें।

  • 4.1.6 (4-way हैंडशेक में PTK पुनः स्थापना जब STA टेम्पोरल PTK निर्माण का उपयोग करता है, यादृच्छिक ANonce)। इस टेस्ट को ./krack-test-client.py --tptk-rand का उपयोग करके निष्पादित करें।

  • 4.2.1 (STA पर ग्रुप की हैंडशेक संवेदनशीलता परीक्षण)। इस टेस्ट को ./krack-test-client.py --group का उपयोग करके निष्पादित करें।

  • 4.3.1 (WNM स्लीप मोड का समर्थन करने वाले STA पर GTK और IGTK की पुनः स्थापना)। हम वर्तमान में इस टेस्ट का समर्थन नहीं करते हैं (और वास्तव में Wi-Fi Alliance भी नहीं करता है!)।

एक्सेस पॉइंट्स का परीक्षण: एक संवेदनशील FT हैंडशेक (802.11r) का पता लगाना

  1. नेटवर्क से कनेक्ट करने के लिए उपयोग किया जा सकने वाला wpa_supplicant कॉन्फ़िगरेशन फ़ाइल बनाएँ। एक बुनियादी उदाहरण है:

    root@kitploit:~
     ctrl_interface=/var/run/wpa_supplicant
     network={
       ssid="testnet"
       key_mgmt=FT-PSK
       psk="password"
     }
    

    "FT-PSK" के उपयोग पर ध्यान दें। इसे network.conf या समान नाम से सहेजें। अधिक जानकारी के लिए wpa_supplicant.conf देखें।

  2. अपने प्लेटफ़ॉर्म के wpa_supplicant का उपयोग करके नेटवर्क से कनेक्ट करने का प्रयास करें। इसके लिए संभवतः ऐसे कमांड की आवश्यकता होगी:

    root@kitploit:~
     sudo wpa_supplicant -D nl80211 -i wlan0 -c network.conf
    

    यदि यह विफल होता है, तो या तो AP FT का समर्थन नहीं करता है, या आपने चरण 1 में गलत नेटवर्क कॉन्फ़िगरेशन विकल्प प्रदान किए हैं। ध्यान दें कि यदि AP FT का समर्थन नहीं करता है, तो यह इस संवेदनशीलता से प्रभावित नहीं होता है।

  3. इस स्क्रिप्ट का उपयोग पिछले wpa_supplicant कमांड के रैपर के रूप में करें:

    root@kitploit:~
     sudo su
     source venv/bin/activate
     ./krack-ft-test.py wpa_supplicant -D nl80211 -i wlan0 -c network.conf
    

    यह प्रदान किए गए पैरामीटरों का उपयोग करके wpa_supplicant कमांड को निष्पादित करेगा, और एक वर्चुअल मॉनिटर इंटरफ़ेस जोड़ेगा जो हमले के परीक्षण करेगा। पहले रूट बनना और फिर python वर्चुअल वातावरण लोड करना महत्वपूर्ण है (यह वर्चुअल वातावरण कैसे बनाएँ, ऊपर देखें)।

  4. उसी नेटवर्क के किसी भिन्न AP पर रोम करने के लिए wpa_cli का उपयोग करें। उदाहरण के लिए:

    root@kitploit:~
     wpa_cli -i wlan0
     > status
     bssid=c4:e9:84:db:fb:7b
     ssid=testnet
     ...
     > scan_results 
     bssid / frequency / signal level / flags / ssid
     c4:e9:84:db:fb:7b	2412  -21  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
     c4:e9:84:1d:a5:bc	2412  -31  [WPA2-PSK+FT/PSK-CCMP][ESS] testnet
     ...
     > roam c4:e9:84:1d:a5:bc
     ...
    

अतिरिक्त: हार्डवेयर डिक्रिप्शन

यह पुष्टि करने के लिए कि हार्डवेयर डिक्रिप्शन अक्षम है, अपने Wi-Fi NIC को प्लग इन करने के बाद systool -vm ath9k_htc या समान निष्पादित करें ताकि पुष्टि हो सके कि nohwcript/swcrypto/hwcrypto पैरामीटर सेट किया गया है। ध्यान दें कि आपको ath9k_htc को अपने वायरलेस नेटवर्क कार्ड के कर्नेल मॉड्यूल से बदलना होगा।

अतिरिक्त: 5 GHz समर्थित नहीं है

5 GHz बैंड में डिवाइसों के परीक्षण के लिए कोई आधिकारिक समर्थन नहीं है।

यदि आप फिर भी 5 GHz चैनलों पर उपकरण का उपयोग करना चाहते हैं, तो उपयोग किए जा रहे नेटवर्क कार्ड को 5 GHz चैनल में फ्रेम्स के इंजेक्शन की अनुमति देनी होगी। दुर्भाग्यवश, नियामक बाधाओं के कारण यह हमेशा संभव नहीं होता है। यह देखने के लिए कि आप किन चैनलों पर फ्रेम्स इंजेक्ट कर सकते हैं, आप iw list निष्पादित कर सकते हैं और Frequencies के अंतर्गत उन चैनलों को देखें जो disabled, no IR, या radar detection के रूप में चिह्नित नहीं हैं। ध्यान दें कि ये स्थितियाँ आपके नेटवर्क कार्ड, वर्तमान कॉन्फ़िगर किए गए देश, और जिस AP से आप कनेक्टेड हैं, पर निर्भर हो सकती हैं। अधिक जानकारी के लिए, उदाहरण के लिए, Arch Linux दस्तावेज़ीकरण देखें।

ध्यान दें कि Linux कर्नेल फ्रेम्स के इंजेक्शन की अनुमति नहीं दे सकता है, भले ही सामान्य फ्रेम्स भेजने की अनुमति हो। ऐसा इसलिए है क्योंकि फ़ंक्शन ieee80211_monitor_start_xmit में कर्नेल फ्रेम्स इंजेक्ट करने से इनकार कर देता है जब cfg80211_reg_can_beacon false लौटाता है। परिणामस्वरूप, Linux फ्रेम्स इंजेक्ट करने से इनकार कर सकता है, भले ही यह वास्तव में अनुमत हो। सही (या सभी) परिस्थितियों में cfg80211_reg_can_beacon को true लौटाना इस बग को रोकता है। इसलिए आपको Linux ड्राइवरों को पैच करना होगा ताकि cfg80211_reg_can_beacon हमेशा true लौटाए, उदाहरण के लिए, backport ड्राइवर कोड को मैन्युअल रूप से पैच करके।

अतिरिक्त: मैन्युअल परीक्षण

hostap git रिपॉजिटरी को क्लोन करके (अधिक विस्तृत) परीक्षण मैन्युअल रूप से करना भी संभव है:

root@kitploit:~
git clone git://w1.fi/srv/git/hostap.git

और tests/cipher-and-key-mgmt-testing.txt में दिए गए निर्देशों का पालन करें।

टूल डाउनलोड करें
ping 192.168.100.254
  • ./krack-test-client.py --tptk। टेस्ट 4 के समान, सिवाय इसके कि एन्क्रिप्टेड मैसेज 3 भेजने से पहले एक जाली मैसेज 1 इंजेक्ट किया जाता है। टेस्ट का यह प्रकार महत्वपूर्ण है क्योंकि कुछ क्लाइंट (जैसे wpa_supplicant v2.6) केवल तब 4-way हैंडशेक में पेयरवाइज़ की पुनः स्थापनाओं के प्रति संवेदनशील होते हैं जब पुनः प्रेषित मैसेज 3 भेजने से पहले एक जाली मैसेज 1 इंजेक्ट किया जाता है।

  • ./krack-test-client.py --tptk-rand। उपरोक्त टेस्ट के समान, सिवाय इसके कि जाली मैसेज 1 में एक यादृच्छिक ANonce होता है।

  • ./krack-test-client.py --gtkinit। यह जाँचता है कि क्या क्लाइंट दिए गए रिसीव सीक्वेंस काउंटर (RSC) के साथ 4-way हैंडशेक में ग्रुप की स्थापित करता है। यह 4-way हैंडशेक के Msg3/4 को हर बार एक नई ग्रुप की और बहुत उच्च रीप्ले काउंटर के साथ पुनः प्रेषित करके किया जाता है। हम जानते हैं कि यह संवेदनशील है यदि परीक्षण के तहत क्लाइंट बाद में कम रीप्ले काउंटर वाले ब्रॉडकास्ट फ्रेम्स को स्वीकार करता है। दुर्भाग्यवश, कुछ क्लाइंट पुनः प्रेषित Msg3/4 को बिल्कुल स्वीकार नहीं करते हैं, जिसका अर्थ है कि ऐसे क्लाइंट्स का इस कमांड से परीक्षण नहीं किया जा सकता है। जो क्लाइंट पुनः प्रेषित Msg3/4 को स्वीकार करते हैं, और इसलिए इस कमांड से परीक्षण किए जा सकते हैं, वे Msg4/4 के साथ उत्तर देंगे जिसे निम्नलिखित आउटपुट के आधार पर पहचाना जा सकता है:

    root@kitploit:~
    [09:24:11] 02:20:2a:22:a8:30: received a new message 4
    

    हम यह भी अनुशंसा करते हैं कि इस टेस्ट को कम पृष्ठभूमि शोर वाले वातावरण में निष्पादित करें और इसे कई बार निष्पादित करें।

  • इस उदाहरण में हम testnet के AP c4:e9:84:db:fb:7b से कनेक्टेड थे (status कमांड देखें)। scan_results कमांड दिखाता है कि इस नेटवर्क में MAC c4:e9:84:1d:a5:bc वाला एक दूसरा AP भी है। फिर हम इस दूसरे AP पर रोम करते हैं।

  • AP और क्लाइंट के बीच ट्रैफिक उत्पन्न करें। उदाहरण के लिए:

    root@kitploit:~
     arping -I wlan0 192.168.1.10
    
  • अब यह देखने के लिए ./krack-ft-test.py का आउटपुट देखें कि क्या AP संवेदनशील है।

    1. पहले इसे "Detected FT reassociation frame" कहना चाहिए। फिर यह हमले का प्रयास करने के लिए इस फ्रेम को रीप्ले करना शुरू करेगा।
    2. स्क्रिप्ट दिखाती है कि डेटा फ्रेम्स भेजते समय AP किन IVs (= पैकेट नंबरों) का उपयोग कर रहा है।
    3. संदेश IV reuse detected (IV=X, seq=Y). AP is vulnerable! का अर्थ है कि हमने पुष्टि कर ली है कि यह संवेदनशील है।

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

    संवेदनशील AP का उदाहरण आउटपुट:

    root@kitploit:~
     [15:59:24] Replaying Reassociation Request
     [15:59:25] AP transmitted data using IV=1 (seq=0)
     [15:59:25] Replaying Reassociation Request
     [15:59:26] AP transmitted data using IV=1 (seq=0)
     [15:59:26] IV reuse detected (IV=1, seq=0). AP is vulnerable!
    

    पैच किए गए AP का उदाहरण आउटपुट (ध्यान दें कि IVs कभी पुनः उपयोग नहीं होते):

    root@kitploit:~
     [16:00:49] Replaying Reassociation Request
     [16:00:49] AP transmitted data using IV=1 (seq=0)
     [16:00:50] AP transmitted data using IV=2 (seq=1)
     [16:00:50] Replaying Reassociation Request
     [16:00:51] AP transmitted data using IV=3 (seq=2)
     [16:00:51] Replaying Reassociation Request
     [16:00:52] AP transmitted data using IV=4 (seq=3)