स्मार्ट अनुबंधों के स्वचालित ऑडिट के लिए गाइड। भाग 3: मिथक

चेतावनी

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

लेख का उद्देश्य पाठक को यह समझने की समझ देना है कि विभिन्न विश्लेषणकर्ताओं में कोड विश्लेषण के तरीके और उन्हें सही तरीके से उपयोग करने की क्षमता के बजाय "एक विकल्प बनाएं"। एक उचित विकल्प एक बार में कई उपकरणों का उपयोग करना है, जो विश्लेषण किए गए अनुबंध के लिए सबसे उपयुक्त है।

लॉन्च के लिए सेटअप और तैयारी

Mythril एक साथ कई प्रकार के विश्लेषण का उपयोग करता है, यहां इसके बारे में कुछ अच्छे लेख हैं: सबसे महत्वपूर्ण , यह या यह । जारी रखने से पहले, यह उन्हें पढ़ने के लिए समझ में आता है।

सबसे पहले, हम मिथाइलर की अपनी डॉकटर छवि बनाते हैं (इससे कोई फर्क नहीं पड़ता कि हम उसमें क्या बदलाव करना चाहते हैं?):

git clone https://github.com/ConsenSys/mythril-classic.git cd mythril-classic docker build -t myth . 

अब इसे हमारे contracts/flattened.sol पर चलाने की कोशिश करें contracts/flattened.sol (मैं उसी अनुबंध का उपयोग करता हूं जिस पर चर्चा की गई थी ), जिसमें दो मुख्य अनुबंध हैं, Ownable से योग्य और हमारी Booking । कंपाइलर संस्करण के साथ हमें अभी भी एक समस्या है, मैंने इसे पिछले लेख की तरह ही ठीक किया, डॉकरीफाइल में लाइनें जोड़ते हुए जो कंपाइलर संस्करण को बदल देगा:

 COPY --from=ethereum/solc:0.4.20 /usr/bin/solc /usr/bin 

छवि के पुनर्निर्माण के बाद, आप अनुबंध विश्लेषण चलाने की कोशिश कर सकते हैं। सभी चेतावनियों को देखने के लिए तुरंत -v4 और --verbose-report झंडे का उपयोग करें। आइए जाने:

 docker run -v $(pwd):/tmp \ -w /tmp myth:latest \ -v4 \ --verbose-report \ -x contracts/flattened.sol 

यहां हम निर्भरता के बिना एक चपटा अनुबंध के साथ काम करते हैं। एक अलग Booking.sol अनुबंध का विश्लेषण करने और Mythril को सभी निर्भरताओं को लेने के लिए, आप कुछ इस तरह का उपयोग कर सकते हैं:

 docker run -v $(pwd):/tmp \ -w /tmp myth:latest \ --solc-args="--allow-paths /tmp/node_modules/zeppelin-solidity/ zeppelin-solidity=/tmp/node_modules/zeppelin-solidity" \ -v4 \ --verbose-report \ -x contracts/Booking.sol 

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

 docker run -v $(pwd):/tmp -w /tmp myth:latest -x contracts/flattened.sol:Booking -v4 --verbose-report 

स्टार्ट और डिप्लॉय कॉन्ट्रैक्ट

हम उपरोक्त लाइन के साथ विश्लेषक शुरू करते हैं, आउटपुट को देखते हैं, और हम अन्य चीजों के साथ इस लाइन को प्राप्त करते हैं:

 mythril.laser.ethereum.svm [WARNING]: No contract was created during the execution of contract creation Increase the resources for creation execution (--max-depth or --create-timeout) The analysis was completed successfully. No issues were detected. 

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

इसलिए, हम मिथाइल के बारे में पढ़ रहे हैं: It uses concolic analysis, taint analysis and control flow checking to detect a variety of security vulnerabilities । यदि आप इन शर्तों से बहुत परिचित नहीं हैं, तो मैं यहां विकीर्ण परीक्षण के बारे में विकी को सलाह देता हूं, लेकिन यहां x86 के लिए टेंट चेकिंग के बारे में एक अच्छी प्रस्तुति दी गई है। संक्षेप में: Mythril एक अनुबंध के निष्पादन का अनुकरण करता है, उन शाखाओं को ठीक करता है जिनके साथ निष्पादन हो सकता है और अनुबंध के "टूटे हुए" राज्य को प्राप्त करने की कोशिश कर सकता है, मापदंडों के विभिन्न संयोजनों के माध्यम से छंटनी कर सकता है और सभी संभावित रास्तों को प्राप्त करने की कोशिश कर रहा है। यहाँ ऊपर लेख से एक नमूना कार्रवाई आरेख है:

 1.      .   symbolic-,        . 2.      ,     ,   trace .    ,      ,    . 3.     . 4.       trace-. 5.  symbolic execution   trace,   symbolic ,    ,     ,     . 6.     ,          .    , . 7.   :   ,   ,   input-,     ,      .   input-   ,   .6    . 8.   .4 

यदि आप इसे बहुत सरल करते हैं, तो Mythril कोड में एक शाखा का सामना कर रहा है, यह समझ सकता है कि किस चर के सेट में एक और दूसरी शाखा में प्रवेश करना संभव है। प्रत्येक शाखा में, Mythril जानता है कि क्या यह मुखर, transfer , आत्म-अविनाशी और अन्य सुरक्षा-प्रासंगिक opcodes की ओर जाता है। इसलिए, माइथ्रिल विश्लेषण करता है कि कौन से मापदंडों और लेनदेन का सेट सुरक्षा भंग हो सकता है। और जिस तरह से माइथ्रिल उन शाखाओं को काट देता है जिन्हें कभी नियंत्रण नहीं मिलता है और नियंत्रण प्रवाह का विश्लेषण इसकी मुख्य चाल है। Mythril आंतों और शाखा चलने के बारे में अधिक विवरण यहां लिखे गए हैं ।

स्मार्ट अनुबंध निष्पादन की निर्धारक प्रकृति के कारण, निर्देशों का एक ही क्रम हमेशा मंच, वास्तुकला या पर्यावरण की परवाह किए बिना, राज्य में बदलाव के एक सेट के लिए सख्ती से आगे बढ़ता है। इसके अलावा, स्मार्ट कॉन्ट्रैक्ट में कार्य कम होते हैं, और संसाधन बेहद सीमित होते हैं, इसलिए माइथ्रिल, प्रतीकात्मक और देशी निष्पादन के संयोजन जैसे विश्लेषक स्मार्ट कॉन्ट्रैक्ट के लिए बेहद कुशलता से काम कर सकते हैं।

इस प्रक्रिया में, माइथ्रिल "राज्य" की अवधारणा का उपयोग करता है - यह अनुबंध का कोड, इसका वातावरण, वर्तमान कमांड का एक संकेतक, अनुबंध का भंडारण और स्टैक की स्थिति है। यहाँ प्रलेखन है:

 The machine state μ is defined as the tuple (g, pc, m, i, s) which are the gas available, the program counter pc ∈ P256, the memory contents, the active number of words in memory (counting continuously from position 0), and the stack contents. The memory contents μm are a series of zeroes of size 256. 

राज्यों के बीच संक्रमण का ग्राफ अध्ययन का मुख्य उद्देश्य है। विश्लेषण के सफल प्रक्षेपण के मामले में, इस ग्राफ के बारे में जानकारी विश्लेषण लॉग में प्रदर्शित की जाती है। इसके अलावा, माइथ्रिल - ग्राफ विकल्प का उपयोग करके इस ग्राफ को मानव-पठनीय रूप में --graph ।

अब कमोबेश यह समझने में कि माइथ्रिल क्या करेगा, हम यह समझना जारी रखेंगे कि कॉन्ट्रैक्ट को पार्स क्यों नहीं किया गया और यह कहां से आया है [WARNING]: No contract was created during the execution of contract creation । शुरू करने के लिए, मैंने --create-timeout और --max-depth (जैसा कि अनुशंसित है) और परिणाम प्राप्त नहीं किया, मैंने सोचा कि निर्माता को दोष देना था - इसमें कुछ काम नहीं किया था। यहाँ उसका कोड है:

 function Booking( string _description, string _fileUrl, bytes32 _fileHash, uint256 _price, uint256 _cancellationFee, uint256 _rentDateStart, uint256 _rentDateEnd, uint256 _noCancelPeriod, uint256 _acceptObjectPeriod ) public payable { require(_price > 0); require(_price > _cancellationFee); require(_rentDateStart > getCurrentTime()); require(_rentDateEnd > _rentDateStart); require(_rentDateStart+_acceptObjectPeriod < _rentDateEnd); require(_rentDateStart > _noCancelPeriod); m_description = _description; m_fileUrl = _fileUrl; m_fileHash = _fileHash; m_price = _price; m_cancellationFee = _cancellationFee; m_rentDateStart = _rentDateStart; m_rentDateEnd = _rentDateEnd; m_noCancelPeriod = _noCancelPeriod; m_acceptObjectPeriod = _acceptObjectPeriod; } 

Mythril के एक्शन एल्गोरिदम को याद करें। ट्रेस चलाने के लिए, आपको कॉन्ट्रैक्ट कंस्ट्रक्टर को कॉल करने की आवश्यकता है, क्योंकि बाद के सभी निष्पादन इस बात पर निर्भर करेंगे कि कंस्ट्रक्टर को किन मापदंडों के साथ बुलाया गया था। उदाहरण के लिए, यदि आप कंस्ट्रक्टर को _price == 0 साथ _price == 0 , तो कंस्ट्रक्टर require(_price > 0) पर अपवाद छोड़ देगा require(_price > 0) । यहां तक ​​कि अगर Mythril कई _price मानों से _price करता है, तो भी निर्माता टूट जाएगा यदि, उदाहरण के लिए, _price <= _cancellationFee । इस अनुबंध में, सख्त प्रतिबंधों से जुड़े एक दर्जन पैरामीटर हैं, और Mythril, निश्चित रूप से, मापदंडों के मान्य संयोजनों का अनुमान नहीं लगा सकता है। वह निष्पादन की अगली शाखा में जाने की कोशिश करता है, कंस्ट्रक्टर के मापदंडों के माध्यम से छंटनी करता है, लेकिन उसके पास व्यावहारिक रूप से अनुमान लगाने का कोई मौका नहीं है - मापदंडों के बहुत सारे संयोजन हैं। इसलिए, अनुबंध की गणना काम नहीं करती है - सभी तरीके किसी तरह की require(...) पर आराम करते हैं, और हमें उपरोक्त समस्या मिलती है।

अब हमारे पास दो तरीके हैं: पहला यह है कि कंस्ट्रक्टर में सभी require को अक्षम करके उन्हें टिप्पणी कर दें। तब Mythril किसी भी सेट पैरामीटर के साथ कंस्ट्रक्टर को कॉल करने में सक्षम होगा और सब कुछ काम करेगा। लेकिन इसका मतलब यह है कि इस तरह के मापदंडों के साथ एक अनुबंध की जांच करने से, माइथ्रिल को त्रुटियां मिलेंगी जो कि कंस्ट्रक्टर को दिए गए गलत मूल्यों के साथ संभव हैं। सीधे शब्दों में कहा जाए, तो अगर कॉन्ट्रैक्ट निर्माता _cancellationFee के किराए की कीमत का एक अरब गुना _mprice , तो _mprice एक बग _mprice , तो ऐसे बग में कोई फायदा नहीं है - ऐसा कॉन्ट्रैक्ट कभी ब्लॉक नहीं होगा और त्रुटियों को खोजने में संसाधन खर्च होंगे। हम मानते हैं कि अनुबंध अभी भी अधिक या कम सुसंगत मापदंडों के साथ अटका हुआ है, इसलिए आगे के विश्लेषण के लिए यह अधिक यथार्थवादी निर्माण मापदंडों को निर्दिष्ट करने के लिए समझ में आता है, ताकि मिथिलर उन त्रुटियों की तलाश न करें जो अनुबंध ठीक से बंद होने पर कभी नहीं होंगे।

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

  function Booking( ) public payable { m_description = "My very long booking text about hotel and beautiful sea view!"; m_fileUrl = "https://ether-airbnb.bam/some-url/"; m_fileHash = 0x1628f3170cc16d40aad2e8fa1ab084f542fcb12e75ce1add62891dd75ba1ffd7; m_price = 1000000000000000000; // 1 ETH m_cancellationFee = 100000000000000000; // 0.1 ETH m_rentDateStart = 1550664800 + 3600 * 24; // current time + 1 day m_rentDateEnd = 1550664800 + 3600 * 24 * 4; // current time + 4 days m_acceptObjectPeriod = 3600 * 8; // 8 hours m_noCancelPeriod = 3600 * 24; // 1 day require(m_price > 0); require(m_price > m_cancellationFee); require(m_rentDateStart > 1550664800); require(m_rentDateEnd > m_rentDateStart); require((m_rentDateStart + m_acceptObjectPeriod) < m_rentDateEnd); require(m_rentDateStart > m_noCancelPeriod); } 

प्लस, सब कुछ शुरू करने के लिए, आपको max-depth पैरामीटर भी सेट करना होगा। इसने इस --max-depth=34 साथ मेरे लिए काम किया --max-depth=34 AAX t2.medium उदाहरण पर --max-depth=34 । उसी समय, मेरे लैपटॉप पर, जो अधिक शक्तिशाली है, सब कुछ बिना किसी max-depth शुरू होता है। इस पैरामीटर के उपयोग को देखते हुए, विश्लेषण के लिए शाखाओं का निर्माण करना आवश्यक है, और इसका डिफ़ॉल्ट मान अनंत ( कोड ) है। इसलिए, इस पैरामीटर को घुमाएं, लेकिन सुनिश्चित करें कि वांछित अनुबंध का विश्लेषण किया गया है। आप इसे संदेशों द्वारा समझ सकते हैं जैसे:

 mythril.laser.ethereum.svm [INFO]: 248 nodes, 247 edges, 2510 total states mythril.laser.ethereum.svm [INFO]: Achieved 59.86% coverage for code: ............. 

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

त्रुटियों की खोज करें

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

सबसे पहले, आइए देखें कि लंबे समय से पीड़ित Booking अनुबंध के लिए Mythril ने क्या जारी किया है। पहली चेतावनी:

 ==== Dependence on predictable environment variable ==== SWC ID: 116 Severity: Low Contract: Booking Function name: fallback PC address: 566 Estimated Gas Usage: 17908 - 61696 Sending of Ether depends on a predictable variable. The contract sends Ether depending on the values of the following variables: - block.timestamp Note that the values of variables like coinbase, gaslimit, block number and timestamp are predictable and/or can be manipulated by a malicious miner. Don't use them for random number generation or to make critical decisions. -------------------- In file: contracts/flattened.sol:142 msg.sender.transfer(msg.value-m_price) 

और यह उठता है क्योंकि

 require(m_rentDateStart > getCurrentTime()); 

फॉलबैक फंक्शन में।

ध्यान दें कि Mythril ने महसूस किया कि getCurrentTime() में छुपा हुआ है। इस तथ्य के बावजूद कि अनुबंध का अर्थ एक गलती नहीं है, इस तथ्य को कि Mythril प्रसारण के साथ block.timestamp को block.timestamp है! इस मामले में, प्रोग्रामर को यह समझना चाहिए कि निर्णय उस मूल्य के आधार पर किया गया है जो कि खान में नियंत्रण कर सकता है। और, यदि भविष्य में किसी सेवा के लिए नीलामी या अन्य नीलामी अनुबंध के इस स्थान पर उत्पन्न होती है, तो किसी को सामने चल रहे हमलों की संभावना को ध्यान में रखना चाहिए।

आइए देखें कि अगर हम इस तरह से नेस्टेड कॉल में वैरिएबल को छिपाते हैं तो Mythril ब्लॉकचिम पर एक निर्भरता देखता है:

 function getCurrentTime() public view returns (uint256) { - return now; + return getCurrentTimeInner(); } + function getCurrentTimeInner() internal returns (uint256) { + return now; + } 

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

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

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

 function collectTaxes() external onlyState(State.PAID) { msg.sender.transfer(address(this).balance / 5); } 

मिथाइल समस्या पाया गया:

 ==== Unprotected Ether Withdrawal ==== SWC ID: 105 Severity: High Contract: Booking Function name: collectTaxes() PC address: 2492 Estimated Gas Usage: 2135 - 2746 Anyone can withdraw ETH from the contract account. Arbitrary senders other than the contract creator can withdraw ETH from the contract account without previously having sent a equivalent amount of ETH to it. This is likely to be a vulnerability. -------------------- In file: contracts/flattened.sol:149 msg.sender.transfer(address(this).balance / 5) -------------------- -------------------- Transaction Sequence: { "2": { "calldata": "0x", "call_value": "0xde0b6b3a7640000", "caller": "0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef" }, "3": { "calldata": "0x01b613a5", "call_value": "0x0", "caller": "0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef" } } 

महान, अर्थात्। Mythril ने दो लेनदेन भी किए, जो इस तथ्य को जन्म देते हैं कि आप अनुबंध से ईथर ले सकते हैं। अब State.PAID आवश्यकता को State.RENT बदलें। इस तरह,:

 - function collectTaxes() external onlyState(State.PAID){ + function collectTaxes() external onlyState(State.RENT) { 

अब collectTaxes() केवल तभी कहा जा सकता है जब अनुबंध स्थिति में हो। State.RENT स्थिति में, और इस समय शेष राशि पर कुछ भी नहीं है, क्योंकि अनुबंध ने पहले ही मालिक को पूरा प्रसारण भेज दिया है। और यहाँ महत्वपूर्ण बात यह है कि Mythril इस बार त्रुटि का उत्पादन नहीं करता है ==== Unprotected Ether Withdrawal ==== ! केवल कंडिशन onlyState(State.RENT) की शर्त के तहत, एनालाइजर को उस कोड ब्रांच में नहीं मिला जो नॉन-जीरो बैलेंस के साथ कॉन्ट्रैक्ट से ईथर भेजती है। Mythril मापदंडों के लिए विभिन्न विकल्पों के माध्यम से चला गया, लेकिन आप सभी प्रसारण को पट्टेदार को भेजकर केवल State.RENT में State.RENT कर सकते हैं। इसलिए, गैर-शून्य शेष के साथ कोड की इस शाखा में पहुंचना असंभव है, और Mythril बिल्कुल ऑडिटर को परेशान नहीं करता है!

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

इसके अलावा, यह मत भूलो कि Mythril का एक हिस्सा प्रतीकात्मक निष्पादन है, और यह दृष्टिकोण, स्वयं, निष्पादन का अनुकरण किए बिना, कई कमजोरियों को निर्धारित कर सकता है। उदाहरण के लिए, "+", "-" और अन्य अंकगणितीय संचालकों के किसी भी उपयोग को "पूर्णांक अतिप्रवाह" की भेद्यता माना जा सकता है यदि किसी एक ऑपरेंड को हमलावर द्वारा नियंत्रित किया जाता है। लेकिन मैं फिर से दोहराता हूं, मायथ्रिल की सबसे शक्तिशाली विशेषता प्रतीकात्मक और देशी निष्पादन का संयोजन है और पैरामीटर मूल्यों का निर्धारण तर्क शाखा में अग्रणी है।

निष्कर्ष

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

माइथ्रिल अभी भी एक काफी युवा सॉफ्टवेयर है, यह आईडीए प्रो नहीं है, और कुछ लेखों को छोड़कर बहुत कम दस्तावेज हैं। कई मापदंडों का मूल्य केवल Mythril कोड में पढ़ा जा सकता है, जो कि cli.py से शुरू होता है । मुझे उम्मीद है कि प्रलेखन में प्रत्येक पैरामीटर के संचालन का एक पूर्ण और गहन विवरण प्रकट होता है।

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

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

संक्षेप में, Mythril का उपयोग करने के लिए सिफारिशें हैं:

1. जितना संभव हो अध्ययन के तहत अनुबंध की प्रारंभिक शर्तों को संकीर्ण करें। यदि, विश्लेषण के दौरान, माइथ्रिल शाखाओं पर बहुत सारे संसाधन खर्च करेगा जो कभी भी अभ्यास में लागू नहीं किया जाएगा, तो यह वास्तव में महत्वपूर्ण कीड़े खोजने की क्षमता खो देगा, इसलिए आपको हमेशा संभावित शाखाओं के क्षेत्र को कम करने की कोशिश करनी चाहिए।
2. सुनिश्चित करें कि अनुबंध विश्लेषण शुरू हो गया है, mythril.laser.ethereum.svm [WARNING]: No contract was created during the execution of contract creation Increase the resources for creation execution (--max-depth or --create-timeout) जैसे संदेशों को याद न करें mythril.laser.ethereum.svm [WARNING]: No contract was created during the execution of contract creation Increase the resources for creation execution (--max-depth or --create-timeout) , अन्यथा आप गलती से विचार कर सकते हैं कि कोई बग नहीं है।
3. आप कॉन्ट्रैक्ट कोड में शाखाओं को मनमाने ढंग से अक्षम कर सकते हैं, जिससे शाखाओं को चुनने और संसाधनों को बचाने में Mythril को कम विविधता मिल सकती है। max-depth पर प्रतिबंध के बिना करने की कोशिश करें, ताकि विश्लेषण को "काट" न करें, लेकिन त्रुटि को मुखौटा न करने के लिए सावधान रहें।
4. प्रत्येक चेतावनी पर ध्यान दें, यहां तक ​​कि हल्की टिप्पणियां भी कभी-कभी अनुबंध कोड में कम से कम एक टिप्पणी जोड़ने के लिए इसके लायक होती हैं, जिससे अन्य डेवलपर्स के लिए यह आसान हो जाता है।

अगले लेख में, हम मोनिकोर विश्लेषक से निपटेंगे, लेकिन यहां उन लेखों के लिए सामग्री की तालिका है जो लिखने के लिए तैयार हैं या नीचे हैं:

भाग 1. परिचय। संकलन, चपटा, एकरूपता के संस्करण
भाग 2. खिसकना
3. Mythril ( )
4. Manticore ( )
5. Echidna ( )