مركز التحليلات
Cryptoverse
Trading Arena
منصة كريبتوبيديا
هديّة
منصة أنظمة البلوكتشين
The $ASP Buildkey Pre-TGE Trading is live on Aspecta platfrom
discoveryBanners
المواضيع الرائجة
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /
‏13 يوليو، 03:22·
لذلك اكتشفت أنه مربي أكثر. لقد لاحظت أن التوجيه الأمامي tx (من قبل المهاجمين) يستدعي "تهيئة" وأن البروتوكولات تستدعي أيضا _successly_ "تهيئة" بعد ذلك (وبالتالي يعتقدون أن كل شيء طبيعي). لكن انتظر ، كيف يكون هذا ممكنا؟ اضطررت إلى النظر بعمق في تغييرات فتحة التخزين وتخمين ما وجدته: لقد قاموا بإعادة تعيين قيمة فتحة التخزين "_initialized" في نهاية الإرسال الأمامي (بعد أن تم تبديلهم إلى عقد التنفيذ الضار). هذا يعني أن تخزين الوكيل يبدو الآن كما لم يتم تهيئته أبدا. فتحة التخزين ذات الصلة التي يجب النظر إليها هي "keccak256 (abi.encode(uint256 (keccak256 (" - 1)) & ~ bytes32 (uint256 (0xff))" = '0xf0c57e16840df040f15088dc2f81fe391c3923bec73e23a9662efc9c229c6a00' هذا هو الشر من المستوى التالي.
sudo rm -rf --no-preserve-root /
sudo rm -rf --no-preserve-root /‏10 يوليو، 22:13
يصبح الأمر أكثر خيالية: الطريقة التي تم خداع بها Etherscan تظهر عقد التنفيذ الخاطئ تعتمد على تعيين فتحتين مختلفتين للوكيل في نفس البث الأمامي. لذلك يستخدم Etherscan إرشادا معينا يتضمن فتحات تخزين مختلفة لاسترداد عقد التنفيذ. هناك وكيل قديم بواسطة OpenZeppelin استخدم الفتحة التالية: 'keccak256 ("org.zeppelinos.proxy.implementation")' = '0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3' لدينا الآن أيضا فتحة EIP-1967 القياسية 'bytes32 (uint256 (keccak256 ('eip1967.proxy.implementation')) - 1)' = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc' إذن ما حدث هو أن فتحة وكيل OpenZeppelin القديمة تمت كتابتها مع عنوان التنفيذ الحميد _ و _ تمت كتابة فتحة EIP-1967 القياسية أيضا مع عنوان التنفيذ الضار. نظرا لأن Etherscan يستفسر أولا عن فتحة البروكسي القديمة ، فقد استرد المظهر الحميد أولا وبالتالي يعرضه.
‏‎21.52‏K