كيف نحكم على ما إذا كان ما يسمى بـ "HACK" الذي حدث لمشروع Crypto أو Blockchain شرعيًا أم أنه مجرد آلية لإخفاء RUG؟

من الواضح ، بعد ما حدث مع MtGox أو QuadrigaCX أو حالات مماثلة حيث ادعى المؤسسون أنهم فقدوا المفاتيح الخاصة التي تحتفظ بمعظم الأصول الرقمية لبورصاتهم أثناء اختفائهم أو العثور عليهم ميتة في وقت لاحق ، فإن الأشخاص في مجال العملات المشفرة يشككون بشكل متزايد عندما يسمعون عن الاختراق في مشروع ، والفكرة الأولى التي تتبادر إلى الذهن هي أن المؤسسين قد أفرغوا الصندوق بشكل أساسي وأفرغوا معه ، وهذا ما يسمى عادةً بـ RUG.

ربما كان هذا هو الحال في العديد من المشاريع ، ولكن ليس بالضرورة في جميعها ، لذلك نحن نبحث اليوم في حالة نعتقد أنها اختراق حقيقي بسبب طبيعة الموقف.

نعتقد أنها حالة مثيرة للاهتمام لتحليلها لأنها ستساعد على فهم أهمية الأمان والتدقيق بشكل أفضل في العقود الذكية أو المشاريع المرتبطة بـ blockchain بشكل عام.

سنحلل بشكل موضوعي الدراما التي حدثت لمشروع RING Financial ، وهو رمز تم إطلاقه على BSC (Binance Blockchain).

قبل الوصول إلى الاختراق ، سنلخص أولاً المشروع وحالته قبله:

RING Financial قبل الاختراق

كانت RING المالية عبارة عن مشروع DeFi بهدف جعل DeFi أكثر سهولة في الوصول إلى مجتمع DeFi والعملات المشفرة. مشروع طموح أراد إنشاء بروتوكول عائد للعقد يحكمه حاملو العقد ويخصص السيولة في أكثر من 300 بروتوكول في وقت واحد. كان الهدف هو الوصول إلى جميع البروتوكولات من خلال عقدة RING واحدة ومن خلال RING Dapp.

تم التحقق من هذه البروتوكولات من قبل الفريق ومن ثم يقوم المجتمع بالتصويت عليها حيث يتم تخصيصها. نفس مفهوم التصويت كما هو الحال في DAO مما جعل RING جذابة للغاية.

كما قامت RING Financial بتبسيط قدر كبير من عملية البحث وعملية النشر لحامل عقدة واحد. One Dapp للوصول إلى جميع Dapps الأخرى ، لذلك لن تحتاج إلا إلى واجهة واحدة بدلاً من 300 واجهة مختلفة مع وصولهم وعقدهم الخاصة.

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

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

إذن ما الذي حدث بالفعل مع RING Financial؟ ولماذا تم اختراقها؟ بفضل blockchain ، لدينا جميع الأدلة الجنائية اللازمة للتعمق في هذا ومعرفة مكان نقاط الضعف ولماذا لم تكن RING Financial عملية احتيال.

حدث RING Financial HACK في الخامس من كانون الأول (ديسمبر) 5 بين الساعة 2021:2 ظهرًا والساعة 01:2 مساءً بالتوقيت العالمي المنسق.

نعم ، حدث كل شيء في 5 دقائق فقط! بفضل ماسح blockchain للحصول على هذه التفاصيل ، بالمناسبة ، نقدم لك أسفل روابط المعاملات المتعلقة بـ HACK بالإضافة إلى عنوان العقد لأولئك الذين يرغبون في البحث بمزيد من التفاصيل.

إليك ملخص يوضح الخلل الذي استغله المهاجم:

عليك أن تفهم أن العقد الذكي لـ RING Financial يتكون من عدة أجزاء ، جزء للرمز المميز وجميع البيانات المتعلقة به والآخر لكل ما يتعلق بحساب العقد والمكافآت. يحتوي جزء الرمز المميز على أمان بحيث لا يمكن إلا لمسؤول العقد تعديل البيانات المهمة لهذا الرمز ، لتظهر لك بعض التعليمات البرمجية ، إليك رأس وظيفة العقد المحمية عبر السمة "onlyOwner" التي تنص على أنه لا يمكن تنفيذ الوظيفة إلا من قبل المسؤول:

وظيفة لا تحتوي على ملف المالك فقط السمة (أو السمة المكافئة لحماية وصول الوظيفة) يمكن تنفيذها بواسطة أي شخص صغير.

الآن ، خمن ماذا؟ لا تحتوي الوظائف الموجودة في جزء العقد والمكافآت على هذه السمة ، كما ترى من خلال النظر إلى أسماء الوظائف أدناه ( المالك فقط السمة مفقودة):

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

الآن ربما تسأل نفسك سؤالين:

كيف يمكن للمطورين ترك مثل هذه الثغرة؟

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

كيف تعرف أنه ليس المطور نفسه هو الذي ترك هذا الخلل عن قصد ولم يكن عملية احتيال؟

اعتراض جيد جدًا ومن السهل افتراض عملية احتيال عندما لا تكون متأكدًا من كيفية القيام بذلك العقود الذكية العمل ولكن من السهل جدًا افتراض براءة المطور ، لأنه نشر والتحقق من الرمز الكامل للعقد الذكي علنًا على BSCSCAN.COM (الماسح الضوئي الأكثر شعبية في Binance Blockchain) ، في 19 نوفمبر 2021 ، هو القول ، أكثر من أسبوعين قبل حدوث RING Financial HACK. وكما أوضحنا من قبل ، فقد تمت كتابة الخلل في BLACK ON WHITE في العقد ، وكان أي مطور متمرس سيلاحظه ويتفاعل معه ، ولكن لسوء الحظ ، كان أول من لم يرحم على الإطلاق. لذلك من الواضح أن المطور لم يكن على علم بهذا الخلل لأنه لم يكن ليخاطر للسماح لأي شخص بقتل مشروع RING Financial في أي وقت.

للعودة إلى استمرار RING Financial HACK ، أدرك المطور خطأه وقام ببساطة بتجميد العقد لإيقاف أي توزيع للمكافآت حتى لا يفرغ المهاجم المجموعة بالكامل. ثم أعاد نشر عقد Node ، هذه المرة بسمة الأمان "onlyOwner". كان عقد Node الجديد هذا قادرًا على التعامل مع توزيع المكافآت الجديد بشكل صحيح ، إلا أنه فات الأوان ، لأنه نتيجة لـ HACK فقد كل الثقة في المشروع والفريق ، وتسبب ضغط البيع في القضاء على الرمز المميز و المشروع.

في الختام ، اخترنا هذه القصة لأنها تُظهر شيئين مهمين حول العقود الذكية ومشاريع التشفير ، ولا تقم أبدًا بتشفير عقد على عجل واتصل دائمًا بشركات التدقيق ، لأنه بمجرد حدوث الاختراق ، يكون قد فات الأوان لإنقاذ القارب ، و يُعد مشروع RING Financial مثالاً جيدًا ، علاوة على ذلك ، وفقًا لاتصالاتهم ، اتصلوا بشركات تدقيق لعقد Node الثاني هذا ولم ينشروه علنًا على BSCSCAN حتى تأكدوا من أمانه. ولكن كما قيل من قبل ، فقد فات الأوان على RING Financial ، وكان الضرر غير قابل للإصلاح.

إليك جميع روابط الماسح الضوئي وعناوين العقد:

تنفيذ معاملة المحفظة لاستغلال الاختراق: 0xfe58c9e2ecb95757be6f4bca33162cfa346cc34f

 Ring smart-contract address: 0x521ef54063148e5f15f18b9631426175cee23de2

Ring reward pool address: 0xa46cc87eca075c5ae387b86867aa3ee4cb397372

 استغلال اختراق المعاملات:

 TRX 1 تحديث

    link: https://bscscan.com/tx/0x596d38494ea5ae640b2a556a7029692928f15713d22b5948477c4eb4a92cf68e

TRX 2 تحديث

    link: https://bscscan.com/tx/0xfc890c855709bb6aeb5177ee31e08751561344402a88af13e7dfd02b9a2f6003

TRX 3 تحديث

    link: https://bscscan.com/tx/0x35c2f1ed9c5ce13a714af6c0dcbbce8fe720f7d6212232b6dd3657d8799a10f1

• محتوى مدعوم من تحسين محركات البحث وتوزيع العلاقات العامة. تضخيم اليوم.
• بلاتوبلوكشين. Web3 Metaverse Intelligence. تضخيم المعرفة. الوصول هنا.
• المصدر https://www.fintechnews.org/how-to-judge-if-a-so-called-hack-that-happened-to-a-crypto-or-blockchain-project-is-legit-or-if-its-just-a-mechanism-to-hide-a-rug/