मेरी कमांड के अंत में यह 'और' कैसे बना, स्क्रिप्ट को जल्दी बना दिया?

Question

कुछ CTF चुनौतियों को ऑनलाइन हल करते समय, मैं एक ऐसी स्थिति में आया था जहाँ मुझे एक सर्वर को bruteforce करने की आवश्यकता थी। यह मेरे द्वारा लिखा गया कोड है:

#!/bin/bash

for i in {0..9}{0..9}{0..9}{0..9} 
    do
    echo "Now trying code.."
    echo $i
    echo "a fixed string" $i | nc localhost *port here* >> /tmp/me/dump.txt
    done

यह अविश्वसनीय रूप से, दर्दनाक रूप से धीमा था । मुझे 1000 से 9999 तक संयोजनों की कोशिश करने की आवश्यकता थी और प्रत्येक 10 कोशिशों के लिए यह लगभग 5 सेकंड था। फिर, एक सलाह के बाद, मैंने इस पंक्ति के अंत में एक 'और' डाला:

   echo "a fixed string" $i | nc localhost *port here* >> /tmp/me/dump.txt &

और, इसने सेकंड के भीतर 100 के संयोजन की कोशिश की। मैं बहुत ही आश्चर्यचकित था। क्या कोई मुझे तर्क समझा सकता है? '& ’ने क्या किया?

Comments

मेरा सुझाव है कि आप अपना शेल मैनुअल पढ़ें। &पृष्ठभूमि में कमांड चलाता है, बस इतना ही। यह तेज या कुछ भी नहीं बना। जो भी शेल का उपयोग कर रहे हैं उसे पढ़ें (मैं मान लेता हूं) मैनुअल।

— पोलीमोन

इसने इसे पृष्ठभूमि में चलाया, आपको यह देखना चाहिए कि यह वास्तव में समाप्त हो गया है।

— डिस्प्लेनाम

आप 1000 के नीचे परीक्षण नहीं करना चाहते हैं? कृपया उपयोग करेंfor i in {1000..9999}

— वाल्टर ए

यह संभव है कि इसने स्क्रिप्ट को तेजी से चलाया क्योंकि बंदरगाह अब समानांतर रूप से समय पर चल रहे हैं। आपको waitअंत में शामिल करना चाहिए , हालांकि।

— ब्राचली

क्या आपने देखा nc -z localhost 1000-2000?

— वाल्टर ए

Answer 1

&एक पृष्ठभूमि प्रक्रिया को जोड़ना ।

यदि आप लिखते हैं a; b, तो यह कमांड चलाएगा a, इसके समाप्त होने की प्रतीक्षा करेगा , फिर bक्रम से चलाएगा ।

यदि आप लिखते हैं a & b, तो यह aएक पृष्ठभूमि प्रक्रिया के रूप में दिखाई देगी । यह खत्म होने का इंतजार नहीं करेगा, और यह bतुरंत चलना शुरू कर देगा । यह दोनों एक ही बार में चलेगा।

आप देख सकते हैं कि यह शेल में प्रयोग करके क्या करता है। यदि आपने Xइंस्टॉल किया है, तो xtermयह देखने का एक अच्छा तरीका है कि क्या होता है: टाइप करना

$ xterm

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

$ xterm &

तब यह इसे पृष्ठभूमि में चलाएगा, और आपको अपना शेल तुरंत वापस मिल जाएगा, जबकि xtermखिड़की भी खुली रहेगी।

तो अगर आप लिखेंगे

echo "a fixed string" $i | nc localhost *port here* >> /tmp/me/dump.txt

यह कनेक्शन बनाता है, स्ट्रिंग भेजता है, फ़ाइल में जो भी आता है उसे स्टोर करता है, और उसके बाद ही अगले अगले पर जाता है।

&इसे जोड़ने से इंतजार नहीं होता। यह अंत में उनमें से सभी दस हजार को एक साथ कम या ज्यादा चलाना होगा।

आपकी स्क्रिप्ट अधिक तेज़ी से "अंत" लगती है, क्योंकि यह संभवतः उस समय में समाप्त नहीं हुई थी। इसने सिर्फ दस हजार पृष्ठभूमि वाली नौकरियां बनाईं, और फिर अग्रभूमि को समाप्त कर दिया।

इसका मतलब यह भी है कि, आपके मामले में, यह एक साथ कम या ज्यादा दस हजार कनेक्शन खोलने की कोशिश करेगा । दूसरे छोर को क्या संभाल सकता है, इसके आधार पर, उनमें से कुछ अच्छी तरह से विफल हो सकते हैं। इतना ही नहीं, लेकिन इस बात की कोई गारंटी नहीं है कि वे क्रम में चलेंगे, वास्तव में वे लगभग निश्चित रूप से नहीं करेंगे, इसलिए वास्तव में क्या खत्म होगा /tmp/me/dump.txtकिसी का अनुमान है।

क्या आपने चेक किया कि क्या आउटपुट सही था?

Comments

हां, मैंने चुनौती को हल कर दिया। यदि सही कोड प्रदान किया गया था, तो सर्वर को पासवर्ड के साथ जवाब देना था। मैंने 'डंप.टेक्स्ट' की जाँच करने के लिए इस कमांड को निष्पादित किया: $ cat dump.txt | sort | uniq -u .. और सही पासवर्ड वाली लाइन मेरे सामने आ गई।

— शिक्षार्थी

@intellikid: मेरा मतलब असभ्य होना नहीं है, लेकिन यह सरासर किस्मत का काम करता है। इतना ही नहीं आदेश भी मायने नहीं रखता था, सर्वर की प्रतिक्रियाएं ncबफर लिखना से छोटी थीं । अगर ऐसा नहीं होता, तो सर्वर की प्रतिक्रियाएं बहुत कम होतीं। Ie, यदि आपके पास 1 बाइट का लिखित बफ़र था, और प्रतिक्रियाएं थीं 1111और 2222, आपने संभवतः 11221212बड़े करीने से अलग होने के बजाय कुछ देखा होगा 1111 2222।

— मारिनस

हाँ, मुझे एहसास हुआ कि यही कारण है कि मैं ये युद्ध खेल खेल रहा हूं। मैं प्रत्येक स्तर पर सीखता हूं। उस सीख के लिए धन्यवाद।

— शिक्षार्थी

Answer 2

Nc (netcat) कमांड महंगा, समय के हिसाब से है। इसे दूरस्थ सर्वर से कनेक्ट करने, डेटा भेजने, प्रतिक्रिया की प्रतीक्षा करने और उसे वापस करने की आवश्यकता है।

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

तो मूल रूप से, आपका स्पीडअप इन सभी रिमोट कनेक्शन को समानांतर में बनाने के कारण होता है, अन्यथा उन्हें पिछले एक के पूरा होने तक इंतजार करना होगा।

Btw, आपके टर्मिनल पर निर्भर करता है, इको कमांड भी आपके लूप को धीमा कर सकता है (उन्हें कभी-कभी लिखने के बफर में जगह होने तक इंतजार करने की आवश्यकता होती है)।