الهندسة العكسية لعقد

المقدمة

لا توجد أسرار على سلسلة الكتل، كل ما يحدث يكون متسقًا، وقابلاً للتحقق، ومتاحًا للجمهور. في الوضع المثالي، يجب أن تكون العقود قد نُشر كود المصدر الخاص بها وتم التحقق منه على Etherscan (opens in a new tab). ومع ذلك، ليس هذا هو الحال دائمًا (opens in a new tab). في هذه المقالة ستتعلم كيفية إجراء الهندسة العكسية للعقود من خلال النظر إلى عقد بدون كود المصدر، 0x2510c039cc3b061d79e564b38836da87e31b342f (opens 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+IF(REGEXMATCH(C1,"PUSH"),REGEXEXTRACT(C1,"PUSH(\d+)"),0)

أولاً، تضيف هذه الدالة بايتًا واحدًا لرمز التشغيل نفسه، ثم تبحث عن PUSH. تعتبر رموز التشغيل PUSH خاصة لأنها تحتاج إلى بايتات إضافية للقيمة التي يتم دفعها. إذا كان رمز التشغيل هو PUSH، فإننا نستخرج عدد البايتات ونضيفه.

في A1 ضع الإزاحة الأولى، صفر. ثم، في A2، ضع هذه الدالة وانسخها والصقها مرة أخرى لبقية العمود A:

=dec2hex(hex2dec(A1)+B1)

نحتاج إلى هذه الدالة لتعطينا القيمة السداسية العشرية لأن القيم التي يتم دفعها قبل القفزات (JUMP و JUMPI) تُعطى لنا بالنظام السداسي عشري.

نقطة الدخول (0x00)

يتم تنفيذ العقود دائمًا من البايت الأول. هذا هو الجزء الأولي من الكود:

يقوم هذا الكود بشيئين:

1. كتابة 0x80 كقيمة بحجم 32 byte في مواقع الذاكرة 0x40-0x5F (يتم تخزين 0x80 في 0x5F، وتكون المواقع 0x40-0x5E كلها أصفارًا).
2. قراءة حجم بيانات الاستدعاء. عادةً ما تتبع بيانات الاستدعاء لعقد إيثريوم واجهة التطبيق الثنائية (ABI) (opens in a new tab)، والتي تتطلب كحد أدنى أربعة بايتات لمُحدد الدالة. إذا كان حجم بيانات الاستدعاء أقل من أربعة، انتقل إلى 0x5E.

المعالج عند 0x5E (لبيانات الاستدعاء غير التابعة لـ ABI)

تبدأ هذه المقتطفة بـ JUMPDEST. تُلقي برامج آلة إيثريوم الافتراضية (EVM) استثناءً إذا انتقلت إلى رمز تشغيل ليس JUMPDEST. ثم تنظر إلى CALLDATASIZE، وإذا كانت "صحيحة" (أي ليست صفرًا) تنتقل إلى 0x7C. سنصل إلى ذلك أدناه.

لذا عندما لا توجد بيانات استدعاء، نقرأ قيمة Storage[6]. لا نعرف ما هي هذه القيمة بعد، ولكن يمكننا البحث عن المعاملات التي تلقاها العقد بدون بيانات استدعاء. المعاملات التي تقوم فقط بتحويل ETH بدون أي بيانات استدعاء (وبالتالي بدون طريقة) تظهر في Etherscan بالطريقة Transfer. في الواقع، أول معاملة تلقاها العقد على الإطلاق (opens in a new tab) هي تحويل.

إذا نظرنا في تلك المعاملة ونقرنا على Click to see More (انقر لرؤية المزيد)، نرى أن بيانات الاستدعاء، والتي تسمى بيانات الإدخال، فارغة بالفعل (0x). لاحظ أيضًا أن القيمة هي 1.559 ETH، وسيكون ذلك ذا صلة لاحقًا.

بعد ذلك، انقر فوق علامة التبويب State (الحالة) وقم بتوسيع العقد الذي نقوم بهندسته العكسية (0x2510...). يمكنك أن ترى أن Storage[6] قد تغيرت بالفعل أثناء المعاملة، وإذا قمت بتغيير Hex (النظام السداسي عشري) إلى Number (رقم)، فسترى أنها أصبحت 1,559,000,000,000,000,000، وهي القيمة المحولة بوحدة wei (أضفت الفواصل للتوضيح)، والتي تتوافق مع قيمة العقد التالية.

إذا نظرنا في تغييرات الحالة الناتجة عن معاملات Transfer أخرى من نفس الفترة (opens in a new tab)، نرى أن Storage[6] تتبعت قيمة العقد لفترة من الوقت. في الوقت الحالي سنسميها Value*. تذكرنا العلامة النجمية (*) بأننا لا نعرف ما يفعله هذا المتغير بعد، ولكن لا يمكن أن يكون مجرد تتبع لقيمة العقد لأنه لا توجد حاجة لاستخدام التخزين، وهو مكلف للغاية، عندما يمكنك الحصول على رصيد حساباتك باستخدام ADDRESS BALANCE. يدفع رمز التشغيل الأول عنوان العقد نفسه. ويقرأ الثاني العنوان الموجود في أعلى المكدس ويستبدله برصيد ذلك العنوان.

سنستمر في تتبع هذا الكود عند وجهة الانتقال.

العملية NOT هي عملية على مستوى البت (bitwise)، لذا فهي تعكس قيمة كل بت في قيمة الاستدعاء.

ننتقل إذا كانت Value* أصغر من 2^256-CALLVALUE-1 أو تساويها. يبدو هذا كمنطق لمنع تجاوز السعة (overflow). وبالفعل، نرى أنه بعد بضع عمليات غير منطقية (الكتابة في الذاكرة على وشك أن تُحذف، على سبيل المثال) عند الإزاحة 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)

هذه خلية تخزين أخرى، لم أتمكن من العثور عليها في أي معاملات، لذا من الصعب معرفة ما تعنيه. الكود أدناه سيوضح ذلك.

تقوم رموز التشغيل هذه باقتطاع القيمة التي قرأناها من Storage[3] إلى 160 بت، وهو طول عنوان إيثريوم.

هذه القفزة زائدة عن الحاجة، لأننا سننتقل إلى رمز التشغيل التالي. هذا الكود ليس فعالاً من حيث استهلاك الغاز كما ينبغي أن يكون.

في بداية الكود تمامًا، قمنا بتعيين Mem[0x40] إلى 0x80. إذا بحثنا عن 0x40 لاحقًا، فسنرى أننا لم نقم بتغييره - لذا يمكننا افتراض أنه 0x80.

انسخ جميع بيانات الاستدعاء إلى الذاكرة، بدءًا من 0x80.

الآن أصبحت الأمور أكثر وضوحًا. يمكن أن يعمل هذا العقد كـ وكيل (opens in a new tab)، حيث يستدعي العنوان الموجود في Storage[3] للقيام بالعمل الحقيقي. يستدعي DELEGATE_CALL عقدًا منفصلاً، ولكنه يبقى في نفس مساحة التخزين. هذا يعني أن العقد المفوض، الذي نعمل كوكيل له، يصل إلى نفس مساحة التخزين. معلمات الاستدعاء هي:

• الغاز: كل الغاز المتبقي
• العنوان المستدعى: Storage[3]-as-address
• بيانات الاستدعاء: بايتات CALLDATASIZE بدءًا من 0x80، وهو المكان الذي وضعنا فيه بيانات الاستدعاء الأصلية
• بيانات الإرجاع: لا شيء (0x00 - 0x00) سنحصل على بيانات الإرجاع بوسائل أخرى (انظر أدناه)

هنا نقوم بنسخ جميع بيانات الإرجاع إلى المخزن المؤقت للذاكرة بدءًا من 0x80.

لذا بعد الاستدعاء، نقوم بنسخ بيانات الإرجاع إلى المخزن المؤقت 0x80 - 0x80+RETURNDATASIZE، وإذا كان الاستدعاء ناجحًا، فإننا نقوم بـ RETURN باستخدام هذا المخزن المؤقت بالضبط.

فشل DELEGATECALL

إذا وصلنا إلى هنا، إلى 0xC0، فهذا يعني أن العقد الذي استدعيناه قد تراجع. وبما أننا مجرد وكيل لهذا العقد، فإننا نريد إرجاع نفس البيانات والتراجع أيضًا.

لذا نقوم بـ REVERT بنفس المخزن المؤقت الذي استخدمناه لـ RETURN سابقًا: 0x80 - 0x80+RETURNDATASIZE

استدعاءات ABI

إذا كان حجم بيانات الاستدعاء أربعة بايتات أو أكثر، فقد يكون هذا استدعاء ABI صالحًا.

يخبرنا Etherscan أن 1C هو رمز تشغيل غير معروف، لأنه تمت إضافته بعد أن برمج Etherscan هذه الميزة (opens in a new tab) ولم يقوموا بتحديثها. يوضح لنا جدول رموز التشغيل المُحدَّث (opens in a new tab) أن هذا يعني إزاحة لليمين.

من خلال تقسيم اختبارات مطابقة توقيع الطريقة إلى قسمين بهذا الشكل، يتم توفير نصف الاختبارات في المتوسط. يتبع الكود الذي يلي هذا مباشرة والكود الموجود في 0x43 نفس النمط: DUP1 أول 32 بت من بيانات الاستدعاء، PUSH4 (((method signature>، ثم تشغيل EQ للتحقق من التطابق، وبعد ذلك JUMPI إذا كان توقيع الطريقة متطابقًا. إليك تواقيع الطرق، وعناوينها، وتعريف الطريقة المقابل (opens in a new tab) إذا كان معروفًا:

إذا لم يتم العثور على تطابق، ينتقل الكود إلى معالج الوكيل عند 0x7C، على أمل أن يكون لدى العقد الذي نعمل كوكيل له تطابق.

splitter()

أول شيء تفعله هذه الدالة هو التحقق من أن الاستدعاء لم يرسل أي ETH. هذه الدالة ليست payable (opens in a new tab). إذا أرسل لنا شخص ما ETH، فلا بد أن يكون ذلك خطأ ونريد التراجع (REVERT) لتجنب بقاء ETH في مكان لا يمكنهم استرداده منه.

ويحتوي 0x80 الآن على عنوان الوكيل

كود E4

هذه هي المرة الأولى التي نرى فيها هذه الأسطر، لكنها مشتركة مع طرق أخرى (انظر أدناه). لذلك سنطلق على القيمة في المكدس اسم X، وتذكر فقط أنه في splitter() تكون قيمة X هذه هي 0xA0.

إذن، يتلقى هذا الكود مؤشر ذاكرة في المكدس (X)، ويجعل العقد ينفذ RETURN مع مخزن مؤقت بحجم 0x80 - X.

في حالة splitter()، يُرجع هذا العنوان الذي نعتبر عقد وكيل له. يُرجع RETURN المخزن المؤقت في النطاق 0x80-0x9F، وهو المكان الذي كتبنا فيه هذه البيانات (الإزاحة 0x130 أعلاه).

currentWindow()

الكود في الإزاحات 0x158-0x163 مطابق لما رأيناه في 0x103-0x10E في splitter() (باستثناء وجهة JUMPI)، لذلك نعلم أن currentWindow() ليس أيضًا payable.

كود DA

هذا الكود مشترك أيضًا مع دوال أخرى. لذلك سنسمي القيمة في المكدس Y، ونتذكر فقط أنه في currentWindow() قيمة Y هذه هي Storage[1].

اكتب Y في 0x80-0x9F.

والباقي مشروح بالفعل أعلاه. لذا فإن القفزات إلى 0xDA تكتب أعلى المكدس (Y) في 0x80-0x9F، وتُرجع تلك القيمة. في حالة currentWindow()، فإنها تُرجع Storage[1].

merkleRoot()

الكود في الإزاحات 0xED-0xF8 مطابق لما رأيناه في 0x103-0x10E في splitter() (باستثناء وجهة JUMPI)، لذا نعلم أن merkleRoot() ليس أيضًا payable.

ما يحدث بعد القفزة اكتشفناه بالفعل. لذا يُرجع merkleRoot() القيمة Storage[0].

0x81e580d3

الرمز في الإزاحات 0x138-0x143 مطابق لما رأيناه في 0x103-0x10E في splitter() (باستثناء الوجهة JUMPI)، لذلك نعلم أن هذه الدالة ليست payable أيضًا.

يبدو أن هذه الدالة تأخذ 32 بايت (كلمة واحدة) على الأقل من بيانات الاستدعاء.

إذا لم تحصل على بيانات الاستدعاء، تتراجع المعاملة دون أي بيانات إرجاع.

دعونا نرى ما يحدث إذا حصلت الدالة بالفعل على بيانات الاستدعاء التي تحتاجها.

calldataload(4) هي الكلمة الأولى من بيانات الاستدعاء بعد توقيع الطريقة

إذا لم تكن الكلمة الأولى أقل من Storage[4]، تفشل الدالة. وتتراجع دون أي قيمة مُرجعة:

إذا كانت calldataload(4) أقل من Storage[4]، نحصل على هذا الرمز:

وتحتوي مواقع الذاكرة 0x00-0x1F الآن على البيانات 0x04 (جميع 0x00-0x1E أصفار، و 0x1F هي أربعة)

لذا يوجد جدول بحث في التخزين، والذي يبدأ عند SHA3 لـ 0x000...0004 ويحتوي على إدخال لكل قيمة بيانات استدعاء مشروعة (القيمة أقل من Storage[4]).

نحن نعلم بالفعل ما يفعله الرمز عند الإزاحة 0xDA، فهو يُرجع القيمة العليا للمكدس إلى المستدعي. لذا تُرجع هذه الدالة القيمة من جدول البحث إلى المستدعي.

0x1f135823

الكود في الإزاحات 0xC4-0xCF مطابق لما رأيناه في 0x103-0x10E في splitter() (باستثناء الوجهة JUMPI)، لذلك نعلم أن هذه الدالة ليست payable أيضًا.

نحن نعلم بالفعل ما يفعله الكود عند الإزاحة 0xDA، فهو يُرجع القيمة العليا في المكدس إلى المستدعي. لذلك تُرجع هذه الدالة Value*.

ملخص الطرق

هل تشعر أنك تفهم العقد في هذه المرحلة؟ أنا لا أشعر بذلك. حتى الآن لدينا هذه الطرق:

لكننا نعلم أن أي وظيفة أخرى يتم توفيرها بواسطة العقد في Storage[3]. ربما إذا عرفنا ما هو هذا العقد، فسيعطينا ذلك دليلًا. لحسن الحظ، هذه هي سلسلة الكتل وكل شيء معروف، على الأقل نظريًا. لم نر أي طرق تقوم بتعيين Storage[3]، لذلك لابد أنه تم تعيينه بواسطة المُنشئ.

المُنشئ

عندما ننظر إلى عقد (opens in a new tab)، يمكننا أيضًا رؤية المعاملة التي أنشأته.

إذا نقرنا على تلك المعاملة، ثم على علامة التبويب الحالة، يمكننا رؤية القيم الأولية للمعلمات. على وجه التحديد، يمكننا أن نرى أن Storage[3] يحتوي على 0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761 (opens 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

هذا ما تقدمه لنا أداة فك التجميع لهذه الدالة:

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

يختبر require الأول أن بيانات الاستدعاء تحتوي، بالإضافة إلى البايتات الأربعة لتوقيع الدالة، على 64 بايت على الأقل، وهو ما يكفي للمعلمتين. إذا لم يكن الأمر كذلك، فمن الواضح أن هناك خطأ ما.

يبدو أن عبارة if تتحقق من أن _param1 ليس صفرًا، وأن _param1 * _param2 ليس سالبًا. من المحتمل أن يكون هذا لمنع حالات الالتفاف (wrap around).

أخيرًا، تُرجع الدالة قيمة متناسبة.

claim

الكود الذي تنشئه أداة فك التجميع معقد، وليس كله ذا صلة بنا. سأتخطى بعضًا منه للتركيز على الأسطر التي أعتقد أنها توفر معلومات مفيدة

def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable:
  ...
  require _param2 == addr(_param2)
  ...
  if currentWindow <= _param1:
      revert with 0, 'cannot claim for a future window'

نرى هنا شيئين مهمين:

• _param2، على الرغم من الإعلان عنه كـ uint256، هو في الواقع عنوان
• _param1 هي النافذة التي تتم المطالبة بها، والتي يجب أن تكون currentWindow أو أقدم.

  ...
  if stor5[_claimWindow][addr(_claimFor)]:
      revert with 0, 'Account already claimed the given window'

لذا نعلم الآن أن Storage[5] عبارة عن مصفوفة من النوافذ والعناوين، وما إذا كان العنوان قد طالب بالمكافأة لتلك النافذة.

  ...
  idx = 0
  s = 0
  while idx < _param4.length:
  ...
      if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]:
          mem[mem[64] + 32] = mem[(32 * idx) + 296]
          ...
          s = sha3(mem[_62 + 32 len mem[_62]])
          continue
      ...
      s = sha3(mem[_66 + 32 len mem[_66]])
      continue
  if unknown2eb4a7ab != s:
      revert with 0, 'Invalid proof'

نعلم أن unknown2eb4a7ab هي في الواقع الدالة merkleRoot()، لذا يبدو أن هذا الكود يتحقق من إثبات ميركل (opens in a new tab). هذا يعني أن _param4 هو إثبات ميركل.

  call addr(_param2) with:
     value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
       gas 30000 wei

هذه هي الطريقة التي يقوم بها العقد بتحويل ETH الخاص به إلى عنوان آخر (عقد أو مملوك خارجيًا). يقوم باستدعائه بقيمة تمثل المبلغ المراد تحويله. لذا يبدو أن هذا إسقاط جوي لـ ETH.

  if not return_data.size:
      if not ext_call.success:
          require ext_code.size(stor2)
          call stor2.deposit() with:
             value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei

يخبرنا السطران السفليان أن Storage[2] هو أيضًا عقد نقوم باستدعائه. إذا نظرنا إلى معاملة المُنشئ (opens in a new tab) نرى أن هذا العقد هو 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 (opens in a new tab)، وهو عقد إيثر مغلف (WETH) تم رفع كود المصدر الخاص به إلى Etherscan (opens in a new tab).

لذا يبدو أن العقد يحاول إرسال ETH إلى _param2. إذا تمكن من ذلك، فهذا رائع. وإذا لم يتمكن، فإنه يحاول إرسال WETH (opens in a new tab). إذا كان _param2 حسابًا مملوكًا خارجيًا (EOA) فيمكنه دائمًا تلقي ETH، لكن العقود يمكنها رفض تلقي ETH. ومع ذلك، فإن WETH هو ERC-20 ولا يمكن للعقود رفض قبوله.

  ...
  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 إلى الأول، وتنتج نفس النوع من إدخال السجل.

def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
  ...
  idx = 0
  s = 0
  while idx < _param3.length:
      if idx >= mem[96]:
          revert with 0, 50
      _55 = mem[(32 * idx) + 128]
      if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]:
          ...
          s = sha3(mem[_58 + 32 len mem[_58]])
          continue
      mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]])
  ...
  if unknown2eb4a7ab != s:
      revert with 0, 'Invalid proof'
  ...
  call addr(_param1) with:
     value s wei
       gas 30000 wei
  if not return_data.size:
      if not ext_call.success:
          require ext_code.size(stor2)
          call stor2.deposit() with:
             value s wei
               gas gas_remaining wei
  ...
  log 0xdbd5389f: addr(_param1), s, bool(ext_call.success)

الفرق الرئيسي هو أن المعلمة الأولى، وهي النافذة المراد سحبها، غير موجودة. بدلاً من ذلك، هناك حلقة تكرار عبر جميع النوافذ التي يمكن المطالبة بها.

  idx = 0
  s = 0
  while idx < currentWindow:
      ...
      if stor5[mem[0]]:
          if idx == -1:
              revert with 0, 17
          idx = idx + 1
          s = s
          continue
      ...
      stor5[idx][addr(_param1)] = 1
      if idx >= unknown81e580d3.length:
          revert with 0, 50
      mem[0] = 4
      if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]:
          revert with 0, 17
      if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6):
          revert with 0, 17
      if idx == -1:
          revert with 0, 17
      idx = idx + 1
      s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6)
      continue

لذا يبدو أنه متغير من claim يطالب بجميع النوافذ.

الخاتمة

بحلول الآن، يجب أن تكون قد عرفت كيفية فهم العقود التي لا يتوفر كودها المصدري، باستخدام إما رموز التشغيل أو (عندما تنجح) أداة فك التجميع. وكما هو واضح من طول هذا المقال، فإن الهندسة العكسية لعقد ليست أمراً بسيطاً، ولكن في نظام يكون فيه الأمان أمراً بالغ الأهمية، فإن القدرة على التحقق من أن العقود تعمل كما هو موعود تعد مهارة مهمة.

انظر هنا للمزيد من أعمالي (opens in a new tab).

آخر تحديث للصفحة: 3 أبريل 2026

q (opens in a new tab)

b (opens in a new tab)

n (opens in a new tab)

+7

عرض المساهمين