เครื่องมือสำหรับตรวจจับการเปลี่ยนแปลงสัญญาอัจฉริยะ

ข้อสันนิษฐานด้านความปลอดภัย Ethereum ที่สำคัญคือรหัสสัญญาอัจฉริยะนั้นไม่สามารถเปลี่ยนแปลงได้ ดังนั้นจึงไม่สามารถเปลี่ยนแปลงได้เมื่อใช้งานบนบล็อคเชน ในทางปฏิบัติ บางสัญญาที่ชาญฉลาด สามารถ เปลี่ยนแปลง – แม้หลังจากที่ได้ปรับใช้แล้ว ด้วยกลอุบายอันชาญฉลาดสองสามข้อ คุณสามารถสร้างสัญญาอัจฉริยะที่เปลี่ยนแปลงได้ซึ่ง “การเปลี่ยนแปลง” เป็นอย่างอื่น – และด้วยการทำความเข้าใจว่าอะไรทำให้เป็นไปได้ คุณจะสามารถตรวจจับพวกมันได้

Metamorphic smart contracts สามารถเปลี่ยนแปลงได้ หมายความว่านักพัฒนาสามารถเปลี่ยนรหัสภายในได้ สัญญาอัจฉริยะเหล่านี้ก่อให้เกิดความเสี่ยงร้ายแรงต่อผู้ใช้ web3 ที่เชื่อมั่นในโค้ดที่พวกเขาคาดหวังว่าจะทำงานด้วยความสอดคล้องอย่างยิ่ง โดยเฉพาะอย่างยิ่งเมื่อผู้ไม่หวังดีสามารถใช้ประโยชน์จากความสามารถในการเปลี่ยนรูปร่างนี้ได้ ลองนึกภาพผู้โจมตีใช้เทคนิคนี้เพื่อ "ปูพรม" ให้กับผู้ที่กำลังเดิมพันโทเค็นในสัญญาอัจฉริยะที่พวกเขาไม่ทราบว่าเป็นการเปลี่ยนแปลง การโจมตีโดยอิงจากสิ่งนี้และสถานที่ที่คล้ายคลึงกันสามารถจัดเตรียมผู้หลอกลวงเพื่อเหยื่อผู้คนและโดยทั่วไปบ่อนทำลายความไว้วางใจในระบบกระจายอำนาจ

เพื่อวิเคราะห์ว่าสัญญาอัจฉริยะมีคุณสมบัติการเปลี่ยนแปลงหรือไม่ ฉันสร้างความเรียบง่าย เครื่องตรวจจับสัญญาแปรสภาพ (ได้แรงบันดาลใจจากและต่อยอดจากงานต้นฉบับของ เจสัน คาร์เวอร์, อายุ 0 ปีและ คนอื่น ๆ). ทุกคนสามารถใช้เครื่องมือนี้เพื่อตรวจสอบว่าสัญญาที่ระบุมีธงสีแดงที่อาจบ่งบอกถึงศักยภาพในการเปลี่ยนแปลงหรือไม่ วิธีการนี้ไม่สามารถพิสูจน์ได้: เพียงเพราะสัญญาอัจฉริยะแสดงแฟล็ก ไม่ได้หมายความว่าจำเป็นต้องเปลี่ยนแปลง และเพียงเพราะไม่ ไม่ได้หมายความว่าปลอดภัย ผู้ตรวจสอบเพียงเสนอการประเมินเบื้องต้นอย่างรวดเร็วว่าสัญญา อาจ แปรสภาพตามตัวบ่งชี้ที่เป็นไปได้ 

ผู้ใช้ Web3 ควรทำความคุ้นเคยกับภัยคุกคามที่เกิดจากสัญญาแปรสภาพ เพื่อให้สามารถระวังและหลีกเลี่ยงการโจมตีที่อาจเกิดขึ้นได้ ตัวทำดัชนีกระเป๋าเงินและบล็อคเชนสามารถช่วยได้โดยการเตือนผู้ใช้ก่อนที่จะโต้ตอบกับสัญญาอัจฉริยะที่อาจมีคุณสมบัติการแปรสภาพ เครื่องมือนี้มีจุดมุ่งหมายเพื่อช่วยทั้งในการให้ความรู้แก่ผู้คนเกี่ยวกับภัยคุกคามที่อาจเกิดขึ้นนี้... และการป้องกันภัยคุกคาม

การตรวจจับสัญญาอัจฉริยะที่แปรเปลี่ยน

พื้นที่ เครื่องตรวจจับสัญญาแปรสภาพ ฉันสร้างการวิเคราะห์คุณสมบัติหกประการที่อาจบ่งบอกว่าสัญญาอัจฉริยะมีการเปลี่ยนแปลงหรือไม่

1. 1. รหัส metamorphic ที่รู้จักใช้ในการปรับใช้สัญญาหรือไม่ หากรู้จัก metamorphic bytecode ซึ่งเป็นโค้ดระดับล่างที่เครื่องเสมือนสามารถอ่านได้ ซึ่ง Ethereum smart contract ซึ่งปกติจะเขียนด้วย Solidity จะกลายเป็นหลังจากคอมไพล์แล้ว จะแสดงขึ้นในธุรกรรมสำหรับการปรับใช้สัญญาอัจฉริยะที่กำหนด นั่นเป็นธงสีแดงที่สำคัญ ในส่วนที่ตามมา เราจะพูดถึงตัวอย่างหนึ่งของ metamorphic bytecode ที่พัฒนาโดย 0age ข้อแม้ที่สำคัญ: ไบต์โค้ดที่แปรผันอาจมีรูปแบบนับไม่ถ้วน ซึ่งทำให้การตรวจจับทุกรูปแบบทำได้ยาก โดยการสแกนหาอินสแตนซ์ที่รู้จักกันดี ตัวตรวจจับจะกำจัดผลไม้ที่แขวนอยู่ต่ำสำหรับผู้โจมตีที่เพียงแค่คัดลอกและวางตัวอย่างที่มีอยู่
   2. รหัสสัญญาอัจฉริยะสามารถทำลายตัวเองได้หรือไม่? ในการแทนที่โค้ดในสัญญา ซึ่งเป็นขั้นตอนสำคัญในการสร้างสัญญาแปลงร่าง ผู้พัฒนาต้องลบโค้ดที่มีอยู่ก่อน วิธีเดียวที่จะทำได้คือการใช้ รหัสตัวเองคำสั่งที่ทำงานได้ตรงตามที่คิด โดยจะลบโค้ดและที่เก็บข้อมูลทั้งหมดตามที่อยู่ของสัญญาที่กำหนด การมีอยู่ของรหัสทำลายตนเองในสัญญาไม่ได้พิสูจน์ว่าเป็นการเปลี่ยนแปลง แต่มีข้อบ่งชี้ว่าสัญญา อาจ แปรสภาพและมันก็คุ้มค่าที่จะรู้ว่าสัญญาที่คุณพึ่งพิงสามารถทำลายตัวเองได้หรือไม่
   3. สัญญาอัจฉริยะเรียกรหัสจากที่อื่นหรือไม่? หากสัญญาอัจฉริยะที่เป็นปัญหาไม่สามารถทำลายตัวเองได้โดยตรง สัญญาอัจฉริยะนั้นยังสามารถลบตัวเองได้โดยใช้ปุ่ม DELEGATALL opcode. opcode นี้ช่วยให้สัญญาอัจฉริยะสามารถโหลดและรันโค้ดที่อยู่ในสัญญาอัจฉริยะอื่นได้แบบไดนามิก แม้ว่าสัญญาอัจฉริยะจะไม่มี opcode ของ SELFDESTRUCT แต่ก็สามารถใช้ DELEGATECALL เพื่อโหลดโค้ดที่ทำลายตัวเองจากที่อื่นได้ ในขณะที่ฟังก์ชัน DELEGATECALL ไม่ได้ระบุโดยตรงว่าสัญญาอัจฉริยะมีการเปลี่ยนแปลงหรือไม่ แต่ก็เป็นเบาะแสที่เป็นไปได้และปัญหาด้านความปลอดภัยที่อาจเกิดขึ้นซึ่งเป็นสิ่งที่ควรค่าแก่การสังเกต ถูกเตือนว่าตัวบ่งชี้นี้มีศักยภาพที่จะทำให้เกิดผลบวกที่ผิดพลาดมากมาย 
   4. สัญญาอื่นปรับใช้สัญญานี้หรือไม่ สามารถปรับใช้สัญญาแปรสภาพได้ เพียง โดยสัญญาอัจฉริยะอื่น ๆ นี่เป็นเพราะว่าสัญญาแปรสภาพถูกเปิดใช้งานโดย opcode อื่น ซึ่งใช้งานได้โดยสัญญาอัจฉริยะอื่น ๆ ที่เรียกว่า CREATE2 เท่านั้น (เราจะพูดถึง CREATE2 – วิธีการทำงานและเหตุใดจึงสำคัญ – เพิ่มเติมในหัวข้อต่อๆ ไป) ลักษณะนี้เป็นหนึ่งในตัวชี้วัดที่เห็นได้ชัดเจนน้อยที่สุดของการเปลี่ยนแปลงที่เป็นไปได้ มันเป็นเงื่อนไขเบื้องต้นที่จำเป็นแต่ไม่เพียงพอ การสแกนหาลักษณะนี้มีแนวโน้มที่จะทำให้เกิดผลบวกที่ผิดพลาดมากมาย – แต่เป็นข้อมูลที่มีค่าที่ควรทราบ เนื่องจากอาจก่อให้เกิดความสงสัยและให้เหตุผลในการตรวจสอบสัญญาเพิ่มเติม โดยเฉพาะอย่างยิ่งหากสัญญาอัจฉริยะมี opcode ที่อธิบายไว้ถัดไป
   5. สัญญาตัวปรับใช้มี opcode CREATE2 หรือไม่ ดังที่กล่าวไว้ข้างต้น การปรับใช้ผ่าน CREATE2 เป็นเงื่อนไขเบื้องต้นที่จำเป็นสำหรับการเปลี่ยนแปลง หากสัญญาปรับใช้มี opcode CREATE2 ซึ่งอาจบ่งชี้ว่าใช้ CREATE2 เพื่อปรับใช้สัญญาที่เป็นปัญหา หากผู้ปรับใช้ใช้ CREATE2 เพื่อปรับใช้สัญญาดังกล่าวจริง ๆ แม้ว่านั่นไม่ได้หมายความว่าสัญญาจำเป็นต้องเปลี่ยนแปลง แต่ก็หมายความว่า อาจ เปลี่ยนแปลงได้และควรดำเนินการด้วยความระมัดระวังและตรวจสอบเพิ่มเติม อีกครั้ง ระวังผลบวกที่ผิดพลาด: สร้าง2 มีมากมาย การใช้งานที่ถูกต้องตามกฎหมายรวมถึงการหนุน โซลูชันการปรับขนาด "เลเยอร์ 2" และทำให้ง่ายต่อการสร้าง smart contract wallet ที่สามารถปรับปรุง web3 การเริ่มต้นใช้งานของผู้ใช้ และตัวเลือกการกู้คืนคีย์
   6. รหัสเปลี่ยนไปหรือไม่? นี่เป็นการบอกที่ชัดเจนที่สุด แต่มันจะปรากฏขึ้นหลังจากที่สัญญาแปรสภาพได้เปลี่ยนแปลงไปเรียบร้อยแล้ว หากรหัสแฮชของสัญญาอัจฉริยะ – ตัวระบุการเข้ารหัสที่ไม่ซ้ำกัน – แตกต่างจากเมื่อเริ่มใช้งานสัญญาในตอนแรก ก็มีแนวโน้มว่ารหัสจะถูกลบ แทนที่ หรือเปลี่ยนแปลง หากแฮชไม่ตรงกันแล้ว อาจมีบางสิ่งเกี่ยวกับโค้ดที่เปลี่ยนไปและสัญญาอาจมีการเปลี่ยนแปลง แฟล็กนี้เป็นตัวบ่งชี้ที่แน่นอนที่สุดของการเปลี่ยนแปลง แต่จะไม่ช่วยทำนายหรือยึดการเปลี่ยนรูปแบบ เนื่องจากจะตรวจสอบว่าได้เกิดขึ้นแล้วเท่านั้น

นอกเหนือจากการสร้างเครื่องมือบรรทัดคำสั่งอย่างง่ายสำหรับ Metamorphic Contract Detector ฉันยังได้สร้างตัวอย่างสัญญาอัจฉริยะที่แสดงสถานการณ์สมมติการลักพาตัวสัญญาแปลงร่างที่หลอกลวง ซึ่งฉันจะอธิบายในส่วนถัดไป รหัสทั้งหมดมีอยู่ในนี้ พื้นที่เก็บข้อมูล GitHub. 

นักแสดงที่ประสงค์ร้ายสามารถใช้สัญญาแปรสภาพเพื่อขโมยเงินของผู้คนได้อย่างไร

นี่คือวิธีที่บางคนอาจใช้ metamorphic smart contract ซึ่งเป็นส่วนหนึ่งของกลโกง 

ขั้นแรกคือขั้นตอนการตั้งค่า ผู้โจมตีปรับใช้สัญญาอัจฉริยะตามที่อยู่เฉพาะบนบล็อคเชนโดยใช้เครื่องมือสองอย่าง: metamorphic bytecode และ opcode CREATE2 (เราจะขยายความในทั้งสองแนวคิดนี้ในภายหลัง) จากนั้นโค้ดไบต์ที่เปลี่ยนแปลงจะทำตามชื่อของมันและ "morphs" ที่นี่มันเปลี่ยนเป็น a สัญญาเดิมพันs ที่ผู้ใช้สามารถเดิมพันโทเค็น ERC-20 (เราจะพูดถึงรายละเอียดของกลวิธีแปลงร่างนี้ในภายหลัง สัญญา!)

ถัดมาเป็นเหยื่อและสวิตช์ ผู้ใช้ที่ไม่สงสัยจะเดิมพันโทเค็นของพวกเขาในสัญญานี้ โดยถูกล่อลวงโดยความเป็นไปได้ที่จะได้รับผลตอบแทนหรือสิทธิพิเศษอื่นๆ ผู้โจมตีจะลบรหัสการปักหลักและ "สถานะ" ทั้งหมด - ที่เก็บข้อมูลบล็อกเชนหรือหน่วยความจำ - ตามที่อยู่สัญญาอัจฉริยะนี้โดยใช้ รหัสตัวเอง กล่าวถึงในส่วนที่แล้ว. (ควรสังเกตว่าโทเค็น - ซึ่งเป็นส่วนหนึ่งของสัญญา ERC-20 ที่แยกจากกัน - ยังคงมีอยู่โดยไม่ได้รับผลกระทบจากสัญญาที่ทำลายตัวเอง)

ในที่สุดพรมดึง ผู้โจมตีใช้ metamorphic bytecode เดียวกันกับที่ใช้ในขั้นตอนการตั้งค่าเพื่อ "ปรับใช้" สัญญาใหม่ สัญญาใหม่นี้ปรับใช้กับที่อยู่เดิมซึ่งเพิ่งถูกปล่อยออกจากสัญญาที่ทำลายตัวเอง อย่างไรก็ตาม ในครั้งนี้ bytecode “morphs” (เราจะอธิบายอีกครั้งในภายหลัง) ในสัญญาที่เป็นอันตรายซึ่งสามารถขโมยโทเค็นทั้งหมดที่เดิมพันตามที่อยู่ของสัญญาได้ หลอกลวงเสร็จสมบูรณ์ 

ความเสี่ยงที่สัญญาอัจฉริยะแบบแปรสภาพเกิดขึ้นนั้นชัดเจนอยู่แล้ว แต่คุณอาจยังคงสงสัยว่าเคล็ดลับการเปลี่ยนแปลงนี้ทำงานอย่างไร เพื่อให้เข้าใจว่า คุณต้องตรวจสอบให้ลึกถึงระดับไบต์โค้ด 

CREATE2 เปิดรับความเป็นไปได้ของการเปลี่ยนแปลงอย่างไร 

สร้าง2 เป็นการอัปเกรด opcode แนะนำให้รู้จักกับ Ethereum ในเดือนกุมภาพันธ์ 2019 ซึ่งเป็นวิธีใหม่ในการปรับใช้สัญญาอัจฉริยะ 

CREATE2 ช่วยให้นักพัฒนาควบคุมการปรับใช้สัญญาอัจฉริยะของตนได้มากกว่าที่เคย opcode CREATE ดั้งเดิมทำให้นักพัฒนาควบคุมที่อยู่ปลายทางสำหรับสัญญาอัจฉริยะที่จะปรับใช้ได้ยาก ด้วย CREATE2 ผู้คนสามารถควบคุมและทราบที่อยู่ของสัญญาอัจฉริยะเฉพาะล่วงหน้า ก่อนที่จะปรับใช้กับบล็อคเชน ความรู้ล่วงหน้านี้ – บวกกับลูกเล่นที่ชาญฉลาด – คือสิ่งที่ช่วยให้ผู้คนสร้างสัญญาอัจฉริยะที่เปลี่ยนแปลงได้ 

CREATE2 สามารถทำนายอนาคตได้อย่างไร? การคำนวณของ opcode นั้นกำหนดได้: ตราบใดที่อินพุตไม่เปลี่ยนแปลง ที่อยู่ที่กำหนดโดย CREATE2 จะไม่เปลี่ยนแปลง (แม้แต่การเปลี่ยนแปลงเพียงเล็กน้อยก็จะทำให้การปรับใช้เกิดขึ้นที่อื่นได้)

ให้ละเอียดยิ่งขึ้น CREATE2 เป็นฟังก์ชันที่รวมและแฮชองค์ประกอบสองสามอย่างเข้าด้วยกัน ขั้นแรก รวมที่อยู่ของผู้ปรับใช้ (หรือผู้ส่ง): สัญญาอัจฉริยะเริ่มต้นที่ทำหน้าที่เป็นผู้ปกครองของสัญญาที่จะสร้าง ถัดไป จะเพิ่มหมายเลขโดยพลการที่ผู้ส่งให้มา (หรือ "เกลือ") ซึ่งช่วยให้นักพัฒนาปรับใช้รหัสเดียวกันไปยังที่อยู่อื่น (โดยการเปลี่ยนเกลือ) และป้องกันการเขียนทับสัญญาที่มีอยู่เดิมที่เหมือนกัน ในที่สุด มันใช้แฮช keccak256 ของ bytecode การเริ่มต้นสัญญาอัจฉริยะ (“init”) ซึ่งเป็นเมล็ดพันธุ์ที่เปลี่ยนเป็นสัญญาอัจฉริยะใหม่ ชุดค่าผสมที่แฮชร่วมกันนี้จะกำหนดที่อยู่ Ethereum แล้วปรับใช้ bytecode ที่กำหนดไปยังที่อยู่นั้น ตราบเท่าที bytecode ยังคงเหมือนเดิมทุกประการ CREATE2 จะปรับใช้ bytecode ที่กำหนดไปยังที่อยู่เดียวกันบน blockchain เสมอ

นี่คือลักษณะของสูตร CREATE2 (หมายเหตุ: คุณจะสังเกตเห็นองค์ประกอบอื่น "0xFF" ในตัวอย่างด้านล่าง นี่เป็นเพียงค่าคงที่ CREATE2 ใช้to ป้องกันการชนกัน ด้วยรหัส CREATE ก่อนหน้า)

ตอนนี้เรามีวิธีการปรับใช้โค้ดกับที่อยู่ที่กำหนดแล้ว เป็นไปได้อย่างไรที่จะ เปลี่ยนแปลง รหัสที่อยู่เดียวกันนั้นหรือไม่ ในตอนแรกอาจดูเหมือนเป็นไปไม่ได้ หากคุณต้องการปรับใช้โค้ดใหม่โดยใช้ CREATE2 ไบต์โค้ดจะต้องเปลี่ยน ดังนั้น CREATE2 จะปรับใช้กับที่อยู่อื่น แต่ถ้านักพัฒนาสร้าง bytecode ในลักษณะที่สามารถ "แปลง" เป็นรหัสอื่นเมื่อ CREATE2 ปรับใช้สัญญาอัจฉริยะ

สัญญาแปรสภาพทำงานอย่างไร

สูตรสำหรับการเปลี่ยนสัญญาอัจฉริยะให้กลายเป็นสัญญาแปรสภาพต้องใช้สัญญาอัจฉริยะทั้งหมดสามสัญญา โดยแต่ละสัญญามีบทบาทที่แตกต่างกัน

หนึ่งในองค์ประกอบที่จำเป็นเหล่านี้คือ Metamorphic Contract Factory ซึ่งเป็นสมองของการดำเนินการ “โรงงาน” นี้มีหน้าที่รับผิดชอบในการปรับใช้สัญญาแปรสภาพเช่นเดียวกับสัญญาอัจฉริยะอื่นที่เรียกว่าสัญญาการนำไปปฏิบัติ ซึ่งได้รับการตั้งชื่อเพราะในที่สุดโค้ดของมันก็จะถูกนำไปใช้ในสัญญาแปรสภาพ การออกแบบท่าเต้นที่ละเอียดอ่อนระหว่างสัญญาทั้งสามนี้ส่งผลให้เกิดการเปลี่ยนแปลงดังแสดงในแผนภาพด้านล่าง

มาหารือกันในแต่ละขั้นตอน 1-7 โดยละเอียดเพื่อให้กระจ่างการดำเนินงานในที่ทำงาน

ขั้นตอนที่ 1: นักพัฒนาตั้งค่าทุกอย่างให้เคลื่อนไหว

ผู้เข้ารหัสออกแบบรหัสสัญญาอัจฉริยะบางอย่าง – ไบต์โค้ดของสัญญาการนำไปใช้ – ซึ่งจะไปสิ้นสุดในสัญญาแปรสภาพในที่สุด ผู้พัฒนาส่งรหัสนี้ไปที่ Metamorphic Contract Factory ซึ่งเป็นสัญญาอัจฉริยะที่มีจุดประสงค์หลักในการปรับใช้สัญญาอัจฉริยะอื่นๆ การดำเนินการนี้ทำให้กระบวนการสร้างสัญญาเปลี่ยนรูปทั้งหมดเคลื่อนไหว

ทุกสิ่งที่ตามมาเป็นผลมาจากขั้นตอนเริ่มต้นนี้ อย่างแท้จริง, ขั้นตอนที่ 1 ถึง 6 เกิดขึ้นในธุรกรรมปรมาณูเดียวบนบล็อคเชน ซึ่งหมายถึงเกือบทั้งหมดในคราวเดียว ขั้นตอนเหล่านี้สามารถทำซ้ำได้ครั้งแล้วครั้งเล่า เพื่อแทนที่โค้ดภายใน Metamorphic Contract และคงไว้ซึ่งการเปลี่ยนแปลงอย่างต่อเนื่อง

ขั้นตอนที่ 2: โรงงานปรับใช้สัญญาการดำเนินการ

สัญญาแรกที่โรงงานปรับใช้คือสัญญาการนำไปปฏิบัติ ซึ่งมีรหัสการนำไปปฏิบัติ (อย่างสร้างสรรค์ เรารู้) ลองนึกถึง Implementation Contract ว่าเป็นแท่นโหลดหรือจุดอ้างอิงซึ่งมีรหัสบางอย่างก่อนที่จะส่งไปยังปลายทางสุดท้าย ซึ่งในกรณีนี้ จะอยู่ภายในสัญญาแปรสภาพ 

ขั้นตอนที่ 3: ร้านค้าโรงงาน การดำเนินการตามสัญญา ที่อยู่

หลังจากการปรับใช้กับบล็อคเชนแล้ว สัญญาการดำเนินการจะต้องมีอยู่ที่ที่อยู่บล็อกเชนบางแห่ง โรงงานจะเก็บที่อยู่ของสัญญานี้ไว้ในหน่วยความจำของตนเอง (เพื่อใช้ในภายหลัง ในขั้นตอนที่ 5) 

ขั้นตอนที่ 4: โรงงานปรับใช้สัญญาแปรสภาพ

โรงงานปรับใช้ Metamorphic Contract โดยใช้ CREATE2 และ metamorphic bytecode คุณสามารถค้นหาคำแนะนำทางเทคนิคเชิงลึกเกี่ยวกับวิธีการทำงานของ metamorphic bytecode โปรดคลิกที่นี่เพื่ออ่านรายละเอียดเพิ่มเติมแต่พอจะพูดได้ว่าเมื่อ metamorphic bytecode ทำงาน มันจะคัดลอกโค้ดจากตำแหน่งบนเครือข่ายอื่น - ในกรณีนี้ จาก Implementation Contract - ไปยัง Metamorphic Contract ดังที่เราได้กล่าวไปแล้วในหัวข้อที่แล้ว เนื่องจาก CREATE2 ถูกกำหนดไว้แล้ว ตราบใดที่ผู้ส่ง เกลือ และไบต์โค้ดคนเดียวกันถูกใช้อยู่ ที่อยู่ของสัญญาเปลี่ยนรูปจะคงเดิมไม่ว่าจะทำซ้ำกี่ครั้งก็ตาม

ด้านล่างนี้คือตัวอย่างลักษณะของ metamorphic bytecode จาก repo การเปลี่ยนแปลง โดย 0age นี่เป็นเพียงตัวอย่างหนึ่งของ metamorphic bytecode - อาจมีรูปแบบต่างๆ นับไม่ถ้วน ซึ่งทำให้การตรวจจับสัญญา metamorphic ซับซ้อนอย่างมาก

ขั้นตอนที่ 5: Metamorphic bytecode ทำการสอบถามโรงงานสำหรับที่อยู่ตามสัญญาการดำเนินการ

ไบต์โค้ดที่แปรสภาพจะขอที่อยู่ของสัญญาการนำไปปฏิบัติจากโรงงาน (ตามที่จัดเก็บไว้ในขั้นตอนที่ 3) ไม่สำคัญว่าที่อยู่ของสัญญาดำเนินการจะเปลี่ยนแปลงตราบใดที่ไบท์โค้ดแปรสภาพที่ขอที่อยู่ยังคงเหมือนเดิม อันที่จริง หากผู้พัฒนาปรับใช้สัญญา Implementation Contract ใหม่ในภายหลัง เช่น สัญญาที่เป็นอันตรายที่ออกแบบมาเพื่อขโมยโทเค็น ก็จำเป็นต้องปรับใช้ที่ที่อยู่บล็อกเชนอื่น ต่อขั้นตอนที่ 2 สิ่งนี้ไม่มีผลกระทบต่อการสร้างสัญญาแปรสภาพ

ขั้นตอนที่ 6: รหัสสัญญาการดำเนินการจะถูกคัดลอกไปยัง Metamorphic Contract

การใช้ที่อยู่ blockchain ที่เรียนรู้ในขั้นตอนที่ 5 ไบต์โค้ด metamorphic จะระบุตำแหน่งของโค้ดใน Implementation Contract และคัดลอกโค้ดนั้นไปยังที่เก็บข้อมูลในเครื่องของ Metamorphic Contract นี่คือลักษณะที่สัญญาแปรสภาพเปลี่ยนรูปร่าง: โดยการคัดลอกโค้ดจากสัญญาดำเนินการ 

ขั้นตอนที่ 7: ล้างและทำซ้ำ

นักพัฒนาสามารถทำซ้ำขั้นตอนที่ 1 ถึง 6 ซ้ำแล้วซ้ำอีก และแทนที่รหัสในสัญญาแปรสภาพด้วยสิ่งที่พวกเขาชอบโดยใช้สัญญาดำเนินการใหม่ ทั้งหมดที่จำเป็นคือการใช้ opcode ของ SELFDESTRUCT หรือที่แย่กว่านั้นคือ opcodes ของ DELEGATECALL ที่ส่งผลให้เกิด SELFDESTRUCT ในท้ายที่สุด เพื่อลบโค้ดที่มีอยู่ก่อนใน Metamorphic Contract โดยการทำซ้ำวงจรด้วยไบต์โค้ด Implementation Contract ใหม่ Metamorphic Contract จะเหมือนกับเวทมนตร์ แปลงร่าง!

การใช้เทคนิคนี้ในการสร้างสัญญาแปรสภาพ นักพัฒนาที่ชาญฉลาดสามารถปรับเปลี่ยนพื้นเพได้อย่างต่อเนื่องภายใต้เท้าของผู้ใช้ web3 พิจารณาตัวอย่างเช่นสถานการณ์หลอกลวงอีกครั้ง นักพัฒนาซอฟต์แวร์อาจปรับใช้ Implementation Contract ก่อนด้วยรหัสการปักหลักโทเค็น ซึ่งผ่านเส้นทางที่วนเวียนอยู่ในกราฟิกและอธิบายอย่างละเอียดในขั้นตอนข้างต้น จะจบลงในสัญญาแปรสภาพ นักต้มตุ๋นสามารถทำลายรหัสนี้เองได้ในภายหลังและแทนที่ด้วยการใช้สัญญา Implementation ใหม่ที่มีโทเค็น-การขโมย รหัส. 

อะไรก็ตามที่ถูกปรับใช้ในสัญญา Implementation จะจบลงใน Metamorphic Contract ในที่สุด นั่นคือสาระสำคัญของเคล็ดลับ 

***

Metamorphic smart contracts ทำลายสัญญาโซเชียลของ web3 โดยปริยาย ที่คุณเห็นคือสิ่งที่คุณได้รับ คล้ายกับวิธีที่เกมเปลือกใช้ถ้วยเคลื่อนที่สามถ้วยเพื่อซ่อนลูกบอล การทำงานร่วมกันของสัญญาทั้งสามในการสร้างสัญญาแปรสภาพทำให้ยากต่อการปฏิบัติตามหน้าที่ที่แท้จริงของสัญญา เกมเชลล์เป็นการเปรียบเทียบที่เหมาะเจาะเป็นพิเศษเพราะว่านักเล่นกลที่มีความมั่นใจมักจะใช้มือว่องไวและชี้ทางผิดเพื่อให้แน่ใจว่าพวกเขาจะชนะ ในเวอร์ชัน web3 ผู้เขียนสัญญาแปลงร่างสามารถสร้าง "บอล" - รหัสการใช้งานซึ่งก็คือ - หายไป (อ่าน: ทำลายตัวเอง) และสามารถแทนที่ด้วยสิ่งที่พวกเขาชอบ

การมีอยู่ของสัญญาแปรสภาพหมายความว่าเป็นไปได้ที่ผู้ใช้ web3 จะเข้าสู่สัญญาที่สามารถเปลี่ยนแปลงได้ตามต้องการ – นั่นคือสาเหตุที่ภัยคุกคามนี้มีความสำคัญอย่างยิ่งต่อการทำความเข้าใจและป้องกัน ตัวตรวจจับสัญญาแปรสภาพของฉัน เสนอเพียงขั้นตอนแรกในการระบุสัญญาแปรสภาพด้วยมือที่ว่องไว มีหลายวิธีที่สามารถปรับปรุงเครื่องตรวจจับได้ในอนาคต ตัวอย่างเช่น โดยการตรวจสอบโรงงาน (หรือสัญญาผู้ปรับใช้) ที่สร้างสัญญาแปรสภาพซ้ำๆ เราสามารถเห็นได้ว่าโรงงานนั้นเปลี่ยนแปลงตัวเองหรือไม่ คุณลักษณะนี้จะเป็นส่วนเสริมที่เป็นประโยชน์สำหรับเครื่องตรวจจับเวอร์ชัน 2 ที่อัปเกรดแล้ว

คุ้มค่าที่จะย้ำอีกครั้ง: เครื่องมือตรวจจับนี้ไม่น่าเชื่อถือ ธงที่จับได้ไม่ใช่สัญญาณบ่งชี้ถึงศักยภาพในการเปลี่ยนแปลงทั้งหมด แต่พวกมันมีเบาะแส การระบุแฟล็กเหล่านี้เป็นเพียงจุดเริ่มต้นสำหรับการสอบถามที่ละเอียดยิ่งขึ้น นั่นเป็นเหตุผลที่เราขยายเครื่องตรวจจับเพื่อค้นหาแฟล็กที่สามารถสร้างผลบวกปลอมได้อย่างง่ายดาย เช่น การมีอยู่ของออปโค้ด CREATE2 หรือ DELEGATECALL หากคุณมีข้อเสนอแนะในการปรับปรุงเครื่องมือหรือต้องการต่อยอดหรือเพิ่มในงานเบื้องต้นนี้ โปรดติดต่อฉันที่ .

วิเคราะห์สัญญาอัจฉริยะสำหรับลักษณะการเปลี่ยนแปลง โดยใช้เครื่องมือตรวจจับ และเยี่ยมชม repo GitHub สำหรับข้อมูลเพิ่มเติม

บรรณาธิการ: Robert Hackett @rhhackett

***

กิตติกรรมประกาศ: ฉันต้องการส่งเสียงชื่นชมอย่างมากและขอขอบคุณ Robert Hackett, Eddy Lazzarin, Sam Ragsdale, Riyaz Faizullabhoy, Noah Citron, Mason Hall และ Daejun Park สำหรับความคิดเห็นอันมีค่าและคำแนะนำในการทำให้โพสต์และเครื่องมือนี้มีชีวิตขึ้นมา 

***

ความคิดเห็นที่แสดงในที่นี้เป็นความคิดเห็นของบุคลากร AH Capital Management, LLC (“a16z”) ที่ยกมาและไม่ใช่ความคิดเห็นของ a16z หรือบริษัทในเครือ ข้อมูลบางอย่างในที่นี้ได้รับมาจากแหล่งบุคคลที่สาม รวมถึงจากบริษัทพอร์ตโฟลิโอของกองทุนที่จัดการโดย a16z ในขณะที่นำมาจากแหล่งที่เชื่อว่าเชื่อถือได้ a16z ไม่ได้ตรวจสอบข้อมูลดังกล่าวอย่างอิสระและไม่รับรองความถูกต้องของข้อมูลหรือความเหมาะสมสำหรับสถานการณ์ที่กำหนด นอกจากนี้ เนื้อหานี้อาจรวมถึงโฆษณาของบุคคลที่สาม a16z ไม่ได้ตรวจทานโฆษณาดังกล่าวและไม่ได้รับรองเนื้อหาโฆษณาใด ๆ ที่อยู่ในนั้น

เนื้อหานี้จัดทำขึ้นเพื่อวัตถุประสงค์ในการให้ข้อมูลเท่านั้น และไม่ควรใช้เป็นคำแนะนำทางกฎหมาย ธุรกิจ การลงทุน หรือภาษี คุณควรปรึกษาที่ปรึกษาของคุณเองในเรื่องเหล่านั้น การอ้างอิงถึงหลักทรัพย์หรือสินทรัพย์ดิจิทัลใดๆ มีวัตถุประสงค์เพื่อเป็นตัวอย่างเท่านั้น และไม่ถือเป็นการแนะนำการลงทุนหรือข้อเสนอเพื่อให้บริการที่ปรึกษาการลงทุน นอกจากนี้ เนื้อหานี้ไม่ได้มุ่งไปที่หรือมีไว้สำหรับการใช้งานโดยนักลงทุนหรือนักลงทุนที่คาดหวัง และไม่อาจเชื่อถือได้ไม่ว่าในกรณีใดๆ เมื่อตัดสินใจลงทุนในกองทุนใดๆ ที่จัดการโดย a16z (การเสนอให้ลงทุนในกองทุน a16z จะกระทำโดยบันทึกเฉพาะบุคคล ข้อตกลงจองซื้อ และเอกสารที่เกี่ยวข้องอื่นๆ ของกองทุนดังกล่าว และควรอ่านให้ครบถ้วน) การลงทุนหรือบริษัทพอร์ตการลงทุนใดๆ ที่กล่าวถึง อ้างถึง หรือ ที่อธิบายไว้ไม่ได้เป็นตัวแทนของการลงทุนทั้งหมดในยานพาหนะที่จัดการโดย a16z และไม่สามารถรับประกันได้ว่าการลงทุนนั้นจะให้ผลกำไรหรือการลงทุนอื่น ๆ ในอนาคตจะมีลักษณะหรือผลลัพธ์ที่คล้ายคลึงกัน รายการการลงทุนที่ทำโดยกองทุนที่จัดการโดย Andreessen Horowitz (ไม่รวมการลงทุนที่ผู้ออกไม่อนุญาตให้ a16z เปิดเผยต่อสาธารณะและการลงทุนที่ไม่ได้ประกาศในสินทรัพย์ดิจิทัลที่ซื้อขายในตลาดหลักทรัพย์) มีอยู่ที่ https://a16z.com/investments /.

แผนภูมิและกราฟที่ให้ไว้ภายในมีวัตถุประสงค์เพื่อให้ข้อมูลเท่านั้น และไม่ควรใช้ในการตัดสินใจลงทุนใดๆ ผลการดำเนินงานในอดีตไม่ได้บ่งบอกถึงผลลัพธ์ในอนาคต เนื้อหาพูดตามวันที่ระบุเท่านั้น การคาดการณ์ การประมาณการ การคาดการณ์ เป้าหมาย โอกาส และ/หรือความคิดเห็นใดๆ ที่แสดงในเอกสารเหล่านี้อาจเปลี่ยนแปลงได้โดยไม่ต้องแจ้งให้ทราบและอาจแตกต่างหรือขัดแย้งกับความคิดเห็นที่แสดงโดยผู้อื่น โปรดดู https://a16z.com/disclosures สำหรับข้อมูลสำคัญเพิ่มเติม