تحليل معمق لعملية احتيال متطورة باستخدام شبكة رئيسية مزيفة لـ GIWA، والتي أدت في 27/09/2026 إلى خسارة المستخدمين لـ 766 إيثريوم، وتعرض منصة التداول اللامركزية (DEX) DYORSWAP للاختراق بسبب دمج نقطة اتصال RPC وهمية.
احتيال بمستوى متقدم: كيف تقوم بتزیيف بلوكتشين؟
كنت أتصفح تدفق مراقبة الأمان و... كدت أسقط كوب القهوة من يدي. 766 إيثريوم طارت في الهواء ببساطة. لو كانت هجمة تصيد احتيالي تقليدية لمكتبة برمجية أو استغلال عقد ذكي عبر القروض السريعة (Flash Loans)، لكنت قلت "حسناً، أمور عادية وقد رأينا الكثير منها". لكن هذا السيناريو مصمم بطريقة أكثر أناقة ودهاء بكثير. لقد قام المحتالون بإطلاق شبكة GIWA رئيسية مزيفة، وربطوها بمنصة تداول لامركزية تابعة لشخص آخر، واستنزفوا ملايين الدولارات من المستخدمين.
دعونا نحلل هذا الحادث بدقة متناهية، لأنه من الناحية المعمارية يستحق حقاً دراسته من منظور هندسي. وبصفتي متخصصاً في أمنข้อมูล (InfoSec) ومدير تكنولوجيا معلومات (CTO) نشطاً، كادت تعجبني جراءة التنفيذ، رغم أننا بالطبع لا نتمنى أبداً ما حدث لفريق DYORSWAP.
انتظر لحظة، هل يمكن حقاً "تزیيف" شبكة بلوكتشين من الطبقة الثانية (L2)؟ يبدو الأمر جنونياً لمن ينظر من الخارج، لكن في عالم آلة إيثريوم الافتراضية (EVM)، لا توجد شبكة سحرية؛ فهي مجرد مجموعة من القواعد (Conventions) ون نقاط اتصال RPC.
قام الجهات الخبيثة بأخذ حزمة برمجية مفتوحة المصدر (على الأرجح فرع أو Fork من شيء يشبه OP Stack) ونشروا عقدهم الخاص. لكن مجرد تشغيل الخادم لا يكفي؛ كان عليهم إقناع المحافظ والتطبيقات بأن هذا هو المنتج الرسمي لبورصة Upbit الكورية الجنوبية، التي لم تطلق شبكة GIWA الخاصة بها رسمياً بعد في الأساس.
لقد قاموا بترميز (Hardcode) معرف الشبكة الرسمي (Chain ID) بقوة داخل إعدادات العقد — وهو الرقم 9134 الذي سجله فريق GIWA مسبقاً لشبكتهم المستقبلية. وهنا تكمن الثغرة الحقيقية للنظام البيئي بأكمله: المحافظ مثل MetaMask تتحقق من الشبكة استناداً إلى سطور الإعدادات والمعرفات، وليس بناءً على جذور الثقة المشفرة للمبتكرين الحقيقيين.
وهنا بالضبط النقطة التي وقعت فيها منصة DYORSWAP في الفخ، حيث أضافوا نقطة اتصال RPC الوهمية هذه إلى بنيتهم التحتية رغبةً منهم في القفز على موجة الضجة الإعلامية للشبكة الجديدة قبل أي شخص آخر.
أتدرون، عندما كنت أجري عمليات تدقيق العقود الذكية بنفسي سابقاً، اعتقدنا دائماً: حسناً، يمكن تزييف الواجهة الأمامية، ويمكن تبديل RPC، لكن العقد الذكي للجسر (Bridge) هو أمر مقدس، فالكود يعمل مباشرة على شبكة إيثريوم! وهنا تكمن الفخ الأكثر دهاءً في هذا الهجوم.
لماذا لم يشك المستخدمون في أي شيء؟
لم يشك المستخدمون في أي شيء لأن الجسر بدا وكأنه الواجهة الأصلية تماماً لنقل الأموال من إيثريوم إلى شبكة الطبقة الثانية GIWA. كان الناس يوقعون المعاملات عبر MetaMask مرسلين إيثريومهم الثمين إلى العقد الذكي للإيداع على الشبكة الرئيسية.
من الناحية التقنية، تمت كتابة هذا العقد من قبل المحتالين بطريقة تحاكي تشغيل محدد إيداع قياسي. وبمجرد التحقق من صحة المعاملة على الشبكة الرئيسية، كان المخادعون يحصلون على السيطرة الكاملة على الأموال. وفي المقابل، كان المستخدم يتلقى رموزاً (Tokens) وهمية ليس لها أي رصيد حقيقي في رصيد الطبقة الثانية المزيف. كانت الأرقام ترتفع على الشاشة لتخلق وهم نجاح عملية الجسر، بينما كان الإيثريوم الحقيقي قد طار بالفعل إلى محافظ منظمي العملية ليتبخر عبر خدمات الخلط (Mixers). ونتيجة لذلك، تضررت 1335 عنواناً فريداً، وبقي حوالي 767.7 إيثريوم محاصراً في الفخ. والأكثر من ذلك، تمكنوا من سحب ما يقارب 766.3 إيثريوم نظيفة بأقل تكاليف ممكنة للرسوم (Gas).
لقد تصرف فريق DYORSWAP بشكل رائع حقاً من خلال تخصيص أكثر من 200 إيثريوم من جيوبهم الخاصة للتعويضات. أنا أقدر هذا النهج تجاه السمعة، رغم أن الثغرة المعمارية في التحقق من اتصالات RPC الخارجية ستتطلب سداً فورياً وبأي ثمن.
والآن دعونا ننتقل إلى الجزء العملي. كيف تتجنب أن تصبح ممولاً للمحتالين الجدد إذا كنت تحب أن تكون أول من يختبر شبكات البلوكتشين الجديدة؟ لقد أعددت لك نصاً برمجياً للتحقق بلغة بايثون (Python) للتحقق من عقد RPC قبل حتى التفكير في التفاعل معها من خلال محفظتك.
#!/usr/bin/env python3
import requests
def rpc_call(rpc_url, method, params=None):
if params is None:
params = []
payload = {
"jsonrpc": "2.0",
"method": method,
"params": params,
"id": 1
}
response = requests.post(rpc_url, json=payload, timeout=10)
response.raise_for_status()
data = response.json()
if "error" in data:
raise RuntimeError(f"{method}: {data['error']}")
return data.get("result")
def verify_evm_node(rpc_url, expected_chain_id):
try:
chain_id_hex = rpc_call(rpc_url, "eth_chainId")
chain_id = int(chain_id_hex, 16)
net_version = rpc_call(rpc_url, "net_version")
client_version = rpc_call(rpc_url, "web3_clientVersion")
block_number_hex = rpc_call(rpc_url, "eth_blockNumber")
block_number = int(block_number_hex, 16)
latest_block = rpc_call(
rpc_url,
"eth_getBlockByNumber",
["latest", False]
)
print("=" * 60)
print(f"RPC URL : {rpc_url}")
print(f"Chain ID : {chain_id}")
print(f"Expected ChainID : {expected_chain_id}")
print(f"Net Version : {net_version}")
print(f"Client Version : {client_version}")
print(f"Block Number : {block_number}")
if latest_block:
print(f"Latest Block Hash: {latest_block.get('hash')}")
print(f"Latest Block Num : {int(latest_block['number'], 16)}")
print(f"Parent Hash : {latest_block.get('parentHash')}")
print(f"Timestamp : {int(latest_block['timestamp'], 16)}")
print("=" * 60)
checks = []
checks.append(chain_id == expected_chain_id)
try:
checks.append(int(net_version) == expected_chain_id)
except Exception:
checks.append(False)
checks.append(block_number > 0)
checks.append(
latest_block is not None
and latest_block.get("hash")
and latest_block.get("parentHash")
and latest_block.get("number")
)
if all(checks):
print("VERIFICATION PASSED")
return True
print("VERIFICATION FAILED")
return False
except Exception as e:
print(f"ERROR: {e}")
return False
if __name__ == "__main__":
verify_evm_node(
"https://your-rpc-endpoint",
9134
)لا تنسَ القاعدة الذهبية: لا تثق أبداً بقوائم الشبكات الواردة من حسابات تويتر المشبوهة أو منصات التداول اللامركزية غير التحقق منها، إلى أن ينشر المشروع الرسمي النقاط النهائية (Endpoints) بدقة عبر قنواته المؤكدة (ليس وسائل التواصل الاجتماعي، بل التوثيق الرسمي أو الموقع الإلكتروني الرسمي الذي يحمل شهادات SSL). لقد صرحت بورصة Upbit بوضوح تام أن شبكتهم الرئيسية لم يتم إطلاقها بعد، وأن جميع نقاط RPC الحالية ليست سوى طلقات في الهواء وعملية نصب صريحة.
