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

مقدمة

لا توجد أسرار على سلسلة الكتل (blockchain)، فكل ما يحدث متسق وقابل للتحقق ومتاح للعامة. من الناحية المثالية، يجب نشر شفرة المصدر الخاصة بالعقود والتحقق منها على إيثرسكان (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).

إعداد الشفرة القابلة للتنفيذ

يمكنك الحصول على أكواد التشغيل بالانتقال إلى إيثرسكان للعقد، والنقر على علامة التبويب العقد (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) خاصة لأنها تحتاج إلى بايتات إضافية للقيمة التي يتم دفعها. إذا كان كود التشغيل هو PUSH، فإننا نستخرج عدد البايتات ونضيفه.

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

1=dec2hex(hex2dec(A1)+B1)

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

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

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

تقوم هذه الشفرة بأمرين:

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

المعالِج عند 0x5E (لبيانات الاستدعاء غير التابعة لواجهة التطبيق الثنائية ABI)

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

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

إذا نظرنا في تلك المعاملة ونقرنا على انقر لرؤية المزيد، نرى أن بيانات الاستدعاء، التي تسمى بيانات الإدخال، فارغة بالفعل (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 تعمل على مستوى البت، لذلك فهي تعكس قيمة كل بت في قيمة الاستدعاء.

نحن نقفز إذا كانت Value* أصغر من 2^256-CALLVALUE-1 أو تساويها. يبدو هذا منطقًا لمنع التجاوز. وبالفعل، نرى أنه بعد بضع عمليات لا معنى لها (على سبيل المثال، الكتابة في الذاكرة على وشك الحذف)، عند الإزاحة 0x01DE، يتم إرجاع العقد إذا تم اكتشاف التجاوز، وهو سلوك طبيعي.

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

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

يؤدي تقسيم اختبارات مطابقة توقيع الطريقة إلى قسمين مثل هذا إلى توفير نصف الاختبارات في المتوسط. تتبع الشفرة التي تلي ذلك مباشرة والشفرة الموجودة في 0x43 نفس النمط: DUP1 أول 32 بت من بيانات الاستدعاء، PUSH4 (((توقيع الطريقة))، وتشغيل 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) يمكننا أيضًا رؤية المعاملة التي أنشأته.

إذا نقرنا على تلك المعاملة، ثم على علامة التبويب الحالة (State)، يمكننا رؤية القيم الأولية للمعلمات. على وجه التحديد، يمكننا أن نرى أن 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

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

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, 'لا يمكن المطالبة بنافذة مستقبلية'
نسخ

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

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

1  ...
2  if stor5[_claimWindow][addr(_claimFor)]:
3      revert with 0, 'الحساب طالب بالفعل بالنافذة المحددة'
نسخ

لذا نعلم الآن أن Storage[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
نسخ

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

لذا يبدو أن العقود تحاول إرسال ETH إلى _param2. إذا كان بإمكانه فعل ذلك، فهذا رائع. إذا لم يكن كذلك، فإنه يحاول إرسال WETH (opens 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
إظهار الكل
نسخ

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

الخلاصة

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

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

آخر تحديث للصفحة: 22 أغسطس 2025

q (opens in a new tab)

b (opens in a new tab)

n (opens in a new tab)

+7

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