कॉन्ट्रॅक्टचे रिव्हर्स इंजिनिअरिंग

प्रस्तावना

ब्लॉकचेनवर कोणतीही गुपिते नाहीत, जे काही घडते ते सुसंगत, पडताळणीयोग्य आणि सार्वजनिकरित्या उपलब्ध असते. आदर्शपणे, कॉन्ट्रॅक्ट्सचा सोर्स कोड इथरस्कॅनवर प्रकाशित आणि सत्यापित केला गेला पाहिजेopens in a new tab. तथापि, ते नेहमीच असे नसतेopens in a new tab. या लेखात आपण सोर्स कोडशिवाय कॉन्ट्रॅक्टचे रिव्हर्स इंजिनिअर कसे करायचे हे शिकाल, 0x2510c039cc3b061d79e564b38836da87e31b342fopens in a new tab या कॉन्ट्रॅक्टवर नजर टाकून.

रिव्हर्स कंपाइलर्स आहेत, परंतु ते नेहमीच वापरण्यायोग्य परिणामopens in a new tab देत नाहीत. या लेखात आपण ऑपकोड्सopens in a new tab वरून कॉन्ट्रॅक्टचे मॅन्युअली रिव्हर्स इंजिनिअरिंग करून ते कसे समजून घ्यावे, तसेच डीकंपाइलरच्या परिणामांचा अर्थ कसा लावावा हे शिकाल.

हा लेख समजून घेण्यासाठी तुम्हाला EVM च्या मूलभूत गोष्टी आधीच माहित असल्या पाहिजेत आणि EVM असेंबलरशी किमान काही प्रमाणात परिचित असले पाहिजे. तुम्ही या विषयांबद्दल येथे वाचू शकताopens in a new tab.

एक्झिक्यूटेबल कोड तयार करा

कॉन्ट्रॅक्टसाठी Etherscan वर जाऊन, Contract टॅबवर क्लिक करून आणि नंतर Switch to Opcodes View वर क्लिक करून तुम्ही ऑपकोड्स मिळवू शकता. तुम्हाला एक व्ह्यू मिळेल जो प्रति ओळ एक ऑपकोड असेल.

तथापि, जंप्स समजून घेण्यासाठी, प्रत्येक ऑपकोड कोडमध्ये कुठे आहे हे तुम्हाला माहित असणे आवश्यक आहे. ते करण्यासाठी, एक मार्ग म्हणजे Google स्प्रेडशीट उघडून स्तंभ C मध्ये ऑपकोड पेस्ट करणे. तुम्ही या आधीच तयार केलेल्या स्प्रेडशीटची प्रत बनवून पुढील पायऱ्या वगळू शकताopens in a new tab.

पुढील पायरी म्हणजे योग्य कोड लोकेशन्स मिळवणे जेणेकरून आपण जंप्स समजून घेऊ शकू. आपण स्तंभ B मध्ये ऑपकोडचा आकार आणि स्तंभ A मध्ये स्थान (हेक्साडेसिमलमध्ये) ठेवू. B1 सेलमध्ये हे फंक्शन टाइप करा आणि नंतर ते कोडच्या शेवटपर्यंत स्तंभ B च्या उर्वरित भागासाठी कॉपी आणि पेस्ट करा. हे केल्यानंतर तुम्ही स्तंभ B लपवू शकता.

1=1+IF(REGEXMATCH(C1,"PUSH"),REGEXEXTRACT(C1,"PUSH(\d+)"),0)

प्रथम हे फंक्शन स्वतः ऑपकोडसाठी एक बाइट जोडते, आणि नंतर PUSH शोधते. पुश ऑपकोड्स विशेष आहेत कारण त्यांना पुश केल्या जाणाऱ्या व्हॅल्यूसाठी अतिरिक्त बाइट्सची आवश्यकता असते. जर ऑपकोड PUSH असेल, तर आपण बाइट्सची संख्या काढतो आणि ती जोडतो.

A1 मध्ये पहिला ऑफसेट, शून्य टाका. नंतर, A2 मध्ये, हे फंक्शन टाका आणि पुन्हा स्तंभ A च्या उर्वरित भागासाठी कॉपी आणि पेस्ट करा:

1=dec2hex(hex2dec(A1)+B1)

आम्हाला हेक्साडेसिमल व्हॅल्यू मिळवण्यासाठी या फंक्शनची आवश्यकता आहे कारण जंप्स (JUMP आणि JUMPI) पूर्वी पुश केलेल्या व्हॅल्यूज आम्हाला हेक्साडेसिमलमध्ये दिल्या जातात.

एंट्री पॉइंट (0x00)

कॉन्ट्रॅक्ट्स नेहमी पहिल्या बाइटपासून एक्झिक्यूट केले जातात. हा कोडचा प्रारंभिक भाग आहे:

हा कोड दोन गोष्टी करतो:

1. मेमरी लोकेशन्स 0x40-0x5F मध्ये 32 बाइट व्हॅल्यू म्हणून 0x80 लिहा (0x80 हे 0x5F मध्ये साठवले जाते, आणि 0x40-0x5E सर्व शून्य आहेत).
2. कॉलडेटाचा आकार वाचा. सामान्यतः इथेरियम कॉन्ट्रॅक्टसाठी कॉल डेटा ABI (ॲप्लिकेशन बायनरी इंटरफेस)opens in a new tab चे पालन करतो, ज्यासाठी फंक्शन सिलेक्टरसाठी किमान चार बाइट्सची आवश्यकता असते. जर कॉल डेटाचा आकार चार पेक्षा कमी असेल, तर 0x5E वर जंप करा.

0x5E वरील हँडलर (नॉन-ABI कॉल डेटासाठी)

हा स्निपेट JUMPDEST ने सुरू होतो. EVM (इथेरियम व्हर्च्युअल मशीन) प्रोग्राम्स JUMPDEST नसलेल्या ऑपकोडवर जंप केल्यास अपवाद टाकतात. मग ते CALLDATASIZE पाहते, आणि जर ते "true" असेल (म्हणजे शून्य नसेल) तर 0x7C वर जंप करते. आपण खाली त्यावर येऊ.

म्हणून जेव्हा कोणताही कॉल डेटा नसतो तेव्हा आपण स्टोरेज[6] चे व्हॅल्यू वाचतो. हे व्हॅल्यू काय आहे हे आम्हाला अद्याप माहित नाही, परंतु आम्ही कॉन्ट्रॅक्टला कोणताही कॉल डेटा नसताना मिळालेल्या व्यवहारांसाठी पाहू शकतो. ज्या व्यवहारांमध्ये फक्त ETH हस्तांतरित केले जाते आणि कोणताही कॉल डेटा नसतो (आणि म्हणून कोणतीही पद्धत नाही) त्यामध्ये Etherscan मध्ये Transfer ही पद्धत असते. खरं तर, कॉन्ट्रॅक्टला मिळालेला पहिला व्यवहारopens in a new tab एक हस्तांतरण आहे.

जर आपण त्या व्यवहारात पाहिले आणि अधिक पाहण्यासाठी क्लिक करा वर क्लिक केले, तर आपल्याला दिसेल की कॉल डेटा, ज्याला इनपुट डेटा म्हणतात, खरोखरच रिकामा आहे (0x). हे देखील लक्षात घ्या की व्हॅल्यू 1.559 ETH आहे, जे नंतर संबंधित असेल.

पुढे, स्टेट टॅबवर क्लिक करा आणि आपण रिव्हर्स इंजिनिअरिंग करत असलेल्या कॉन्ट्रॅक्टचा विस्तार करा (0x2510...). तुम्ही पाहू शकता की व्यवहारादरम्यान स्टोरेज[6] बदलले आहे, आणि जर तुम्ही हेक्स (Hex) बदलून नंबर (Number) केले, तर तुम्हाला दिसेल की ते 1,559,000,000,000,000,000 झाले आहे, जे wei मध्ये हस्तांतरित केलेले मूल्य आहे (मी स्पष्टतेसाठी स्वल्पविराम जोडले आहेत), जे पुढील कॉन्ट्रॅक्ट मूल्याशी संबंधित आहे.

जर आपण त्याच कालावधीतील इतर Transfer व्यवहारांमुळेopens in a new tab झालेल्या स्टेट बदलांकडे पाहिले तर आपल्याला दिसेल की स्टोरेज[6] ने काही काळासाठी कॉन्ट्रॅक्टच्या मूल्याचा मागोवा घेतला. आतासाठी आपण त्याला Value* म्हणू. तारका चिन्ह (*) आपल्याला आठवण करून देते की हे व्हेरिएबल काय करते हे आपल्याला अद्याप माहीत नाही, परंतु ते फक्त कॉन्ट्रॅक्ट व्हॅल्यूचा मागोवा घेण्यासाठी असू शकत नाही कारण स्टोरेज वापरण्याची गरज नाही, जे खूप महाग आहे, जेव्हा तुम्ही ADDRESS BALANCE वापरून तुमच्या खात्यातील शिल्लक मिळवू शकता. पहिला ऑपकोड कॉन्ट्रॅक्टचा स्वतःचा पत्ता पुश करतो. दुसरा एक स्टॅकच्या शीर्षस्थानी असलेला पत्ता वाचतो आणि त्या पत्त्याच्या शिलकेसह बदलतो.

आपण जंप डेस्टिनेशनवर या कोडचा मागोवा घेणे सुरू ठेवू.

NOT बिटवाईज आहे, म्हणून ते कॉल व्हॅल्यूमधील प्रत्येक बिटची व्हॅल्यू उलटते.

जर Value* 2^256-CALLVALUE-1 पेक्षा लहान असेल किंवा त्याच्या समान असेल तर आपण जंप करतो. हे ओव्हरफ्लो टाळण्यासाठी तर्कशास्त्र असल्यासारखे दिसते. आणि खरंच, आपण पाहतो की काही निरर्थक ऑपरेशन्सनंतर (उदाहरणार्थ, मेमरीमध्ये लिहिणे हटवले जाणार आहे) ऑफसेट 0x01DE वर ओव्हरफ्लो आढळल्यास कॉन्ट्रॅक्ट परत येतो, जे सामान्य वर्तन आहे.

लक्षात घ्या की असा ओव्हरफ्लो अत्यंत अशक्य आहे, कारण त्यासाठी कॉल व्हॅल्यू आणि Value* ची बेरीज 2^256 wei, म्हणजे सुमारे 10^59 ETH च्या तुलनेने असावी लागेल. एकूण ETH पुरवठा, लिहिण्याच्या वेळी, दोनशे दशलक्षांपेक्षा कमी आहेopens in a new tab.

जर आपण येथे आलो, तर Value* + CALLVALUE मिळवा आणि ऑफसेट 0x75 वर जंप करा.

जर आपण येथे आलो (ज्यासाठी कॉल डेटा रिकामा असणे आवश्यक आहे) तर आपण Value* मध्ये कॉल व्हॅल्यू जोडतो. हे आपण Transfer व्यवहार काय करतात याच्याशी सुसंगत आहे.

शेवटी, स्टॅक साफ करा (जे आवश्यक नाही) आणि व्यवहाराचा यशस्वी शेवट सूचित करा.

थोडक्यात सांगायचे तर, सुरुवातीच्या कोडसाठी येथे एक फ्लोचार्ट आहे.

0x7C वरील हँडलर

मी मुद्दाम हेडिंगमध्ये हे हँडलर काय करते हे टाकले नाही. मुद्दा हा विशिष्ट कॉन्ट्रॅक्ट कसा काम करतो हे शिकवण्याचा नाही, तर कॉन्ट्रॅक्ट्सचे रिव्हर्स इंजिनिअरिंग कसे करावे हे शिकवण्याचा आहे. तुम्ही ते काय करते हे त्याच प्रकारे शिकाल जसे मी शिकलो, कोडचे अनुसरण करून.

आपण येथे अनेक ठिकाणांहून येतो:

• जर 1, 2, किंवा 3 बाइट्सचा कॉल डेटा असेल (ऑफसेट 0x63 पासून)
• जर मेथड सिग्नेचर अज्ञात असेल (ऑफसेट 0x42 आणि 0x5D पासून)

हा आणखी एक स्टोरेज सेल आहे, जो मला कोणत्याही व्यवहारात सापडला नाही, त्यामुळे त्याचा अर्थ काय आहे हे जाणून घेणे अधिक कठीण आहे. खालील कोड ते अधिक स्पष्ट करेल.

हे ऑपकोड्स आम्ही स्टोरेज[3] मधून वाचलेले व्हॅल्यू 160 बिट्सपर्यंत कमी करतात, जे इथेरियम पत्त्याची लांबी आहे.

ही जंप अनावश्यक आहे, कारण आपण पुढील ऑपकोडवर जात आहोत. हा कोड गॅस-कार्यक्षमतेच्या बाबतीत जितका असू शकला असता तितका नाही.

कोडच्या अगदी सुरुवातीला आम्ही Mem[0x40] हे 0x80 वर सेट केले. जर आपण नंतर 0x40 शोधले, तर आपल्याला दिसेल की आपण ते बदलत नाही - म्हणून आपण ते 0x80 आहे असे गृहीत धरू शकतो.

सर्व कॉल डेटा मेमरीमध्ये कॉपी करा, 0x80 पासून सुरू करून.

आता गोष्टी अधिक स्पष्ट झाल्या आहेत. हा कॉन्ट्रॅक्ट प्रॉक्सीopens in a new tab म्हणून काम करू शकतो, खरे काम करण्यासाठी स्टोरेज[3] मधील पत्त्यावर कॉल करून. DELEGATE_CALL एका वेगळ्या कॉन्ट्रॅक्टला कॉल करतो, परंतु त्याच स्टोरेजमध्ये राहतो. याचा अर्थ असा की डेलीगेटेड कॉन्ट्रॅक्ट, ज्यासाठी आम्ही प्रॉक्सी आहोत, त्याच स्टोरेज स्पेसमध्ये प्रवेश करतो. कॉलसाठी पॅरामीटर्स आहेत:

• Gas: उर्वरित सर्व गॅस
• कॉल केलेला पत्ता: स्टोरेज[3]-as-address
• कॉल डेटा: 0x80 पासून सुरू होणारे CALLDATASIZE बाइट्स, जिथे आम्ही मूळ कॉल डेटा ठेवला
• रिटर्न डेटा: काहीही नाही (0x00 - 0x00) आम्ही इतर मार्गांनी रिटर्न डेटा मिळवू (खाली पहा)

येथे आम्ही सर्व रिटर्न डेटा 0x80 पासून सुरू होणाऱ्या मेमरी बफरमध्ये कॉपी करतो.

म्हणून कॉल नंतर आम्ही रिटर्न डेटा 0x80 - 0x80+RETURNDATASIZE बफरमध्ये कॉपी करतो, आणि जर कॉल यशस्वी झाला तर आम्ही त्याच बफरसह RETURN करतो.

DELEGATECALL अयशस्वी

जर आपण येथे, 0xC0 वर आलो, तर याचा अर्थ असा की आम्ही कॉल केलेला कॉन्ट्रॅक्ट रिव्हर्ट झाला. आम्ही त्या कॉन्ट्रॅक्टसाठी फक्त एक प्रॉक्सी असल्याने, आम्हाला समान डेटा परत करायचा आहे आणि रिव्हर्ट देखील करायचा आहे.

म्हणून आम्ही पूर्वी RETURN साठी वापरलेल्या त्याच बफरसह REVERT करतो: 0x80 - 0x80+RETURNDATASIZE

ABI कॉल्स

जर कॉल डेटाचा आकार चार बाइट्स किंवा अधिक असेल तर हा एक वैध ABI कॉल असू शकतो.

Etherscan आम्हाला सांगतो की 1C एक अज्ञात ऑपकोड आहे, कारण हे Etherscan ने हे फिचर लिहिल्यानंतर जोडले होतेopens in a new tab आणि त्यांनी ते अपडेट केलेले नाही. एक अद्ययावत ऑपकोड टेबलopens in a new tab आम्हाला दर्शविते की हे उजवीकडे शिफ्ट आहे

मेथड सिग्नेचर मॅचिंग टेस्ट्स अशा प्रकारे दोन भागात विभागल्याने सरासरी अर्ध्या टेस्ट्स वाचतात. या नंतरचा कोड आणि 0x43 मधील कोड समान पॅटर्नचे अनुसरण करतो: कॉल डेटाचे पहिले 32 बिट्स DUP1 करा, PUSH4 (((मेथड सिग्नेचर>, समानतेची तपासणी करण्यासाठी EQ चालवा, आणि नंतर मेथड सिग्नेचर जुळल्यास JUMPI करा. येथे मेथड सिग्नेचर्स, त्यांचे पत्ते आणि शक्य असल्यास संबंधित मेथड डेफिनेशनopens in a new tab दिले आहेत:

जर जुळणारे काही सापडले नाही, तर कोड 0x7C येथील प्रॉक्सी हँडलर वर जंप करतो, या आशेने की ज्या कॉन्ट्रॅक्टसाठी आपण प्रॉक्सी आहोत त्याच्याकडे जुळणारे काहीतरी असेल.

splitter()

हे फंक्शन प्रथम तपासते की कॉलने कोणताही ETH पाठवला नाही. हे फंक्शन payableopens in a new tab नाही. जर कोणी आम्हाला ETH पाठवले असेल तर ती चूक असावी आणि आम्ही REVERT करू इच्छितो जेणेकरून ते ETH अशा ठिकाणी राहणार नाही जिथे ते परत मिळवू शकत नाहीत.

आणि 0x80 मध्ये आता प्रॉक्सी पत्ता आहे

E4 कोड

ही ओळी आपण पहिल्यांदाच पाहत आहोत, परंतु त्या इतर मेथड्ससह शेअर केल्या आहेत (खाली पहा). म्हणून आम्ही स्टॅकमधील व्हॅल्यूला X म्हणू, आणि फक्त लक्षात ठेवा की splitter() मध्ये या X चे व्हॅल्यू 0xA0 आहे.

म्हणून हा कोड स्टॅकमध्ये एक मेमरी पॉइंटर (X) प्राप्त करतो, आणि कॉन्ट्रॅक्टला 0x80 - X असलेल्या बफरसह RETURN करण्यास कारणीभूत ठरतो.

splitter() च्या बाबतीत, हे तो पत्ता परत करते ज्यासाठी आपण प्रॉक्सी आहोत. RETURN 0x80-0x9F मधील बफर परत करते, जिथे आपण हा डेटा लिहिला होता (वरील ऑफसेट 0x130).

currentWindow()

0x158-0x163 ऑफसेटमधील कोड splitter() मध्ये 0x103-0x10E मध्ये पाहिलेल्या कोडसारखाच आहे (JUMPI डेस्टिनेशन वगळता), म्हणून आम्हाला माहित आहे की currentWindow() देखील payable नाही.

DA कोड

हा कोड इतर मेथड्ससह देखील शेअर केला जातो. म्हणून आपण स्टॅकमधील व्हॅल्यूला Y म्हणू, आणि फक्त लक्षात ठेवा की currentWindow() मध्ये या Y चे व्हॅल्यू Storage[1] आहे.

Y ला 0x80-0x9F मध्ये लिहा.

आणि बाकीचे आधीच वर स्पष्ट केले आहे. म्हणून 0xDA वर जंप केल्याने स्टॅक टॉप (Y) 0x80-0x9F मध्ये लिहिला जातो आणि ते व्हॅल्यू परत केले जाते. currentWindow() च्या बाबतीत, ते स्टोरेज[1] परत करते.

merkleRoot()

0xED-0xF8 ऑफसेटमधील कोड splitter() मध्ये 0x103-0x10E मध्ये पाहिलेल्या कोडसारखाच आहे (JUMPI डेस्टिनेशन वगळता), म्हणून आम्हाला माहित आहे की merkleRoot() देखील payable नाही.

जंप नंतर काय होते ते आपण आधीच शोधले आहे. म्हणून merkleRoot() स्टोरेज[0] परत करते.

0x81e580d3

0x138-0x143 ऑफसेटमधील कोड splitter() मध्ये 0x103-0x10E मध्ये पाहिलेल्या कोडसारखाच आहे (JUMPI डेस्टिनेशन वगळता), म्हणून आम्हाला माहित आहे की हे फंक्शन देखील payable नाही.

असे दिसते की हे फंक्शन किमान 32 बाइट्स (एक शब्द) कॉल डेटा घेते.

जर त्याला कॉल डेटा मिळाला नाही तर व्यवहार कोणत्याही रिटर्न डेटाशिवाय रिव्हर्ट होतो.

चला पाहूया की जर फंक्शनला आवश्यक असलेला कॉल डेटा मिळाला तर काय होते.

calldataload(4) हा मेथड सिग्नेचर_नंतरचा_ कॉल डेटाचा पहिला शब्द आहे

जर पहिला शब्द स्टोरेज[4] पेक्षा कमी नसेल, तर फंक्शन अयशस्वी होते. ते कोणत्याही परत केलेल्या व्हॅल्यूशिवाय रिव्हर्ट होते:

जर calldataload(4) स्टोरेज[4] पेक्षा कमी असेल, तर आम्हाला हा कोड मिळतो:

आणि मेमरी लोकेशन्स 0x00-0x1F मध्ये आता डेटा 0x04 आहे (0x00-0x1E सर्व शून्य आहेत, 0x1F चार आहे)

म्हणून स्टोरेजमध्ये एक लुकअप टेबल आहे, जे 0x000...0004 च्या SHA3 पासून सुरू होते आणि प्रत्येक वैध कॉल डेटा व्हॅल्यूसाठी (स्टोरेज[4] पेक्षा कमी व्हॅल्यू) एक एंट्री आहे.

आपल्याला आधीच माहित आहे की ऑफसेट 0xDA येथील कोड काय करतो, ते स्टॅक टॉप व्हॅल्यू कॉलरला परत करते. म्हणून हे फंक्शन लुकअप टेबलमधून व्हॅल्यू कॉलरला परत करते.

0x1f135823

0xC4-0xCF ऑफसेटमधील कोड splitter() मध्ये 0x103-0x10E मध्ये पाहिलेल्या कोडसारखाच आहे (JUMPI डेस्टिनेशन वगळता), म्हणून आम्हाला माहित आहे की हे फंक्शन देखील payable नाही.

आपल्याला आधीच माहित आहे की ऑफसेट 0xDA येथील कोड काय करतो, ते स्टॅक टॉप व्हॅल्यू कॉलरला परत करते. म्हणून हे फंक्शन Value* परत करते.

मेथड सारांश

तुम्हाला असे वाटते का की तुम्हाला या क्षणी कॉन्ट्रॅक्ट समजला आहे? मला नाही. आतापर्यंत आमच्याकडे या मेथड्स आहेत:

परंतु आम्हाला माहित आहे की इतर कोणतीही कार्यक्षमता स्टोरेज[3] मधील कॉन्ट्रॅक्टद्वारे प्रदान केली जाते. कदाचित जर आम्हाला माहित असेल की तो कॉन्ट्रॅक्ट काय आहे तर आम्हाला काहीतरी सुगावा लागेल. सुदैवाने, हे ब्लॉकचेन आहे आणि सर्व काही ज्ञात आहे, किमान सिद्धांतानुसार. आम्ही स्टोरेज[3] सेट करणाऱ्या कोणत्याही मेथड्स पाहिल्या नाहीत, म्हणून ते कन्स्ट्रक्टरद्वारे सेट केले गेले असावे.

कन्स्ट्रक्टर

जेव्हा आपण एका कॉन्ट्रॅक्टकडे पाहतोopens in a new tab तेव्हा आपण तो तयार करणारा व्यवहार देखील पाहू शकतो.

जर आपण त्या व्यवहारावर क्लिक केले, आणि नंतर स्टेट टॅबवर, तर आपण पॅरामीटर्सची प्रारंभिक व्हॅल्यू पाहू शकतो. विशेषतः, आपण पाहू शकतो की स्टोरेज[3] मध्ये 0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761opens in a new tab आहे. त्या कॉन्ट्रॅक्टमध्ये गहाळ कार्यक्षमता असली पाहिजे. आपण ज्या कॉन्ट्रॅक्टची तपासणी करत आहोत त्यासाठी वापरलेल्या त्याच साधनांचा वापर करून आपण ते समजू शकतो.

प्रॉक्सी कॉन्ट्रॅक्ट

वर दिलेल्या मूळ कॉन्ट्रॅक्टसाठी वापरलेल्या त्याच तंत्रांचा वापर करून आपण पाहू शकतो की कॉन्ट्रॅक्ट परत येतो जर:

• कॉलसोबत कोणताही ETH जोडलेला असेल (0x05-0x0F)
• कॉल डेटाचा आकार चार पेक्षा कमी असेल (0x10-0x19 आणि 0xBE-0xC2)

आणि ते समर्थन देत असलेल्या मेथड्स आहेत:

आपण खालील चार मेथड्स दुर्लक्षित करू शकतो कारण आपण त्यांच्यापर्यंत कधीच पोहोचणार नाही. त्यांचे सिग्नेचर्स असे आहेत की आपला मूळ कॉन्ट्रॅक्ट स्वतः त्यांची काळजी घेतो (तुम्ही वरील तपशील पाहण्यासाठी सिग्नेचर्सवर क्लिक करू शकता), म्हणून त्या ओव्हरराइड केलेल्या मेथड्सopens in a new tab असाव्यात.

उर्वरित मेथड्सपैकी एक claim(<params>) आहे आणि दुसरी isClaimed(<params>) आहे, म्हणून तो एअरड्रॉप कॉन्ट्रॅक्टसारखा दिसतो. बाकीचे ऑपकोड बाय ऑपकोड तपासण्याऐवजी, आपण डीकंपाइलरचा प्रयत्न करू शकतोopens in a new tab, जो या कॉन्ट्रॅक्टमधून तीन फंक्शन्ससाठी वापरण्यायोग्य परिणाम देतो. इतरांचे रिव्हर्स इंजिनिअरिंग वाचकांसाठी अभ्यास म्हणून सोडले आहे.

scaleAmountByPercentage

या फंक्शनसाठी डीकंपाइलर आपल्याला हे देतो:

1def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable:
2  require calldata.size - 4 >=′ 64
3  if _param1 and _param2 > -1 / _param1:
4      revert with 0, 17
5  return (_param1 * _param2 / 100 * 10^6)
कॉपी

पहिले require तपासते की कॉल डेटामध्ये, फंक्शन सिग्नेचरच्या चार बाइट्स व्यतिरिक्त, किमान 64 बाइट्स आहेत, जे दोन पॅरामीटर्ससाठी पुरेसे आहेत. जर नसेल तर अर्थातच काहीतरी चूक आहे.

if स्टेटमेंट असे दिसते की _param1 शून्य नाही आणि _param1 * _param2 ऋण नाही हे तपासते. हे कदाचित रॅप अराउंडचे प्रकार टाळण्यासाठी आहे.

शेवटी, फंक्शन एक स्केल्ड व्हॅल्यू परत करते.

claim

डीकंपाइलर तयार करत असलेला कोड गुंतागुंतीचा आहे आणि त्यापैकी सर्वच आपल्यासाठी संबंधित नाहीत. मी उपयुक्त माहिती पुरवतात असे मला वाटणाऱ्या ओळींवर लक्ष केंद्रित करण्यासाठी त्यापैकी काही वगळणार आहे

1def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable:
2  ...
3  require _param2 == addr(_param2)
4  ...
5  if currentWindow <= _param1:
6      revert with 0, 'cannot claim for a future window'
कॉपी

येथे आपण दोन महत्त्वाच्या गोष्टी पाहतो:

• _param2, जरी ते uint256 म्हणून घोषित केले असले तरी, प्रत्यक्षात एक पत्ता आहे
• _param1 ही दावा केलेली विंडो आहे, जी currentWindow किंवा त्यापूर्वीची असावी.

1  ...
2  if stor5[_claimWindow][addr(_claimFor)]:
3      revert with 0, 'Account already claimed the given window'
कॉपी

तर आता आपल्याला माहित आहे की स्टोरेज[5] हे विंडोज आणि पत्त्यांचे अॅरे आहे आणि पत्त्याने त्या विंडोसाठी बक्षीस दावा केला आहे की नाही हे दर्शवते.

1  ...
2  idx = 0
3  s = 0
4  while idx < _param4.length:
5  ...
6      if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]:
7          mem[mem[64] + 32] = mem[(32 * idx) + 296]
8          ...
9          s = sha3(mem[_62 + 32 len mem[_62]])
10          continue
11      ...
12      s = sha3(mem[_66 + 32 len mem[_66]])
13      continue
14  if unknown2eb4a7ab != s:
15      revert with 0, 'Invalid proof'
सर्व दाखवा
कॉपी

आम्हाला माहित आहे की unknown2eb4a7ab प्रत्यक्षात merkleRoot() फंक्शन आहे, म्हणून हा कोड मर्कल प्रूफopens in a new tab पडताळणी करत असल्यासारखा दिसतो. याचा अर्थ _param4 हा एक मर्कल प्रूफ आहे.

1  call addr(_param2) with:
2     value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
3       gas 30000 wei
कॉपी

एक कॉन्ट्रॅक्ट स्वतःचा ETH दुसऱ्या पत्त्यावर (कॉन्ट्रॅक्ट किंवा बाह्य मालकीचा) कसा हस्तांतरित करतो हे असे आहे. ते हस्तांतरित करायच्या रकमेच्या व्हॅल्यूने त्याला कॉल करते. तर असे दिसते की हा ETH चा एअरड्रॉप आहे.

1  if not return_data.size:
2      if not ext_call.success:
3          require ext_code.size(stor2)
4          call stor2.deposit() with:
5             value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
कॉपी

खालील दोन ओळी आपल्याला सांगतात की स्टोरेज[2] हा देखील एक कॉन्ट्रॅक्ट आहे ज्याला आपण कॉल करतो. जर आपण कन्स्ट्रक्टर व्यवहाराकडे पाहिलेopens in a new tab तर आपल्याला दिसेल की हा कॉन्ट्रॅक्ट 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2opens in a new tab आहे, एक रॅप्ड इथर कॉन्ट्रॅक्ट ज्याचा सोर्स कोड Etherscan वर अपलोड केला गेला आहेopens in a new tab.

तर असे दिसते की कॉन्ट्रॅक्ट्स _param2 ला ETH पाठवण्याचा प्रयत्न करतात. जर ते करू शकले, तर छान. जर नाही, तर ते WETHopens in a new tab पाठवण्याचा प्रयत्न करते. जर _param2 एक बाह्य मालकीचे खाते (EOA) असेल तर ते नेहमी ETH प्राप्त करू शकते, परंतु कॉन्ट्रॅक्ट्स ETH प्राप्त करण्यास नकार देऊ शकतात. तथापि, WETH हे ERC-20 आहे आणि कॉन्ट्रॅक्ट्स ते स्वीकारण्यास नकार देऊ शकत नाहीत.

1  ...
2  log 0xdbd5389f: addr(_param2), unknown81e580d3[_param1] * _param3 / 100 * 10^6, bool(ext_call.success)
कॉपी

फंक्शनच्या शेवटी आपण एक लॉग एंट्री तयार होताना पाहतो. तयार झालेल्या लॉग एंट्रीज पहाopens in a new tab आणि 0xdbd5... ने सुरू होणाऱ्या टॉपिकवर फिल्टर करा. जर आपण अशी एंट्री तयार करणाऱ्या व्यवहारांपैकी एकावर क्लिक केलेopens in a new tab तर आपल्याला दिसेल की खरोखरच तो एक दावा असल्यासारखा दिसतो - खात्याने आपण रिव्हर्स इंजिनिअरिंग करत असलेल्या कॉन्ट्रॅक्टला एक संदेश पाठवला, आणि बदल्यात त्याला ETH मिळाले.

1e7df9d3

हे फंक्शन वरील claim सारखेच आहे. ते देखील मर्कल प्रूफ तपासते, पहिल्याला ETH हस्तांतरित करण्याचा प्रयत्न करते, आणि त्याच प्रकारची लॉग एंट्री तयार करते.

1def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
2  ...
3  idx = 0
4  s = 0
5  while idx < _param3.length:
6      if idx >= mem[96]:
7          revert with 0, 50
8      _55 = mem[(32 * idx) + 128]
9      if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]:
10          ...
11          s = sha3(mem[_58 + 32 len mem[_58]])
12          continue
13      mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]])
14  ...
15  if unknown2eb4a7ab != s:
16      revert with 0, 'Invalid proof'
17  ...
18  call addr(_param1) with:
19     value s wei
20       gas 30000 wei
21  if not return_data.size:
22      if not ext_call.success:
23          require ext_code.size(stor2)
24          call stor2.deposit() with:
25             value s wei
26               gas gas_remaining wei
27  ...
28  log 0xdbd5389f: addr(_param1), s, bool(ext_call.success)
सर्व दाखवा
कॉपी

मुख्य फरक असा आहे की पहिला पॅरामीटर, काढण्यासाठीची विंडो, तेथे नाही. त्याऐवजी, दावा करता येणाऱ्या सर्व विंडोजवर एक लूप आहे.

1  idx = 0
2  s = 0
3  while idx < currentWindow:
4      ...
5      if stor5[mem[0]]:
6          if idx == -1:
7              revert with 0, 17
8          idx = idx + 1
9          s = s
10          continue
11      ...
12      stor5[idx][addr(_param1)] = 1
13      if idx >= unknown81e580d3.length:
14          revert with 0, 50
15      mem[0] = 4
16      if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]:
17          revert with 0, 17
18      if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6):
19          revert with 0, 17
20      if idx == -1:
21          revert with 0, 17
22      idx = idx + 1
23      s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6)
24      continue
सर्व दाखवा
कॉपी

तर ते claim चे एक प्रकार वाटते जे सर्व विंडोजचा दावा करते.

निष्कर्ष

आतापर्यंत तुम्हाला माहित झाले असेल की ज्या कॉन्ट्रॅक्ट्सचा सोर्स कोड उपलब्ध नाही ते कसे समजून घ्यायचे, एकतर ऑपकोड्स वापरून किंवा (जेव्हा ते काम करते) डीकंपाइलर वापरून. या लेखाच्या लांबीवरून हे स्पष्ट होते की कॉन्ट्रॅक्टचे रिव्हर्स इंजिनिअरिंग करणे सोपे नाही, परंतु ज्या सिस्टीममध्ये सुरक्षितता आवश्यक आहे तेथे कॉन्ट्रॅक्ट्स वचन दिल्याप्रमाणे काम करतात याची पडताळणी करण्याची क्षमता असणे हे एक महत्त्वाचे कौशल्य आहे.

माझ्या कामाबद्दल अधिक माहितीसाठी येथे पहाopens in a new tab.

पृष्ठ अखेरचे अद्यतन: २२ ऑगस्ट, २०२५

qopens in a new tab

bopens in a new tab

popens in a new tab

+7

योगदानकर्ता पहा