Как распознать Crypto Drainer и Rug Pull до потери денег

1. Быстрое сравнение: Ханипот vs. Рэг-пул vs. Драйнер кошельков

2. Чек-лист безопасности перед покупкой любого токена

Шаг 1: Автоматический скан контракта

Прогоняй адрес токена через Token Sniffer, API GoPlus Security и DEXScreener. Если DEXScreener показывает 800 покупок и буквально ноль продаж за последние 4 часа, тормози. Это наверняка ханипот. Без вариантов.

Шаг 2: Длительность лока ликвидности

Адекватная команда всегда лочит токены пула ликвидности (LP) через такие протоколы, как Uncx Network или PinkSale.

• Красный флаг: Ликвидность не залочена, висит на EOA-кошельке (обычном внешнем аккаунте) или залочена меньше чем на полгода.
• Зеленый флаг: LP-токены сожжены (отправлены на адрес 0x000000000000000000000000000000000000dead) или залочены в проверяемом контракте минимум на год.

Шаг 3: Проверка распределения и владения

Чекни вкладку Holders (держатели) в Etherscan или BscScan.

Если горстка кошельков (не биржевых и не адресов сжигания) контролирует больше 5–10% от общего саплая, то ты - та самая ликвидность на выход. Плюс проверь, отказался ли создатель от прав на контракт. Если нет, админ в любой момент может поменять налоги, забанить твой адрес или вообще поставить переводы на паузу.

Шаг 4: Аудит транзакций и подписей

Никогда не подписывай транзакции вслепую. Современные драйнеры уже почти не клянчат классические переводы в ETH — они юзают офчейн-подписи типа EIP-712, Permit2 или EIP-2612, чтобы обходить стандартные предупреждения кошельков. Юзай расширения для симуляции транзакций на лету, чтобы оценивать изменения стейта до подтверждения в сети.

3. Глубокий разбор безопасности и механики кода

Давайте поговорим о реальной технической кухне. Почему старые статические анализаторы пропускают сложные скамы? Да потому что скамеры пишут адаптивную логику под конкретный контекст.

Погодите... почему люди до сих пор верят, что верификация кода на Etherscan дает 100% защиты? Я задаюсь этим вопросом каждый раз, когда кто-то жалуется на слив бабла в «верифицированном» проекте. Верификация исходников просто доказывает, что развернутый байткод EVM совпадает с поданными Solidity-файлами. Это вообще ни разу не говорит о том, честная там заложена логика или вредоносная!

Фишка с ханипотом: Газ-грифинг и динамические налоги

Классический прием в ханипотах - выставить стандартную комиссию в 2% на старте, а потом задрать ее до 99% прямо внутри функции _transfer(), как только наберется приличная ликвидность.

Еще хуже работают ханипоты с динамическим газ-грифингом:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
/*
 * Моя быстрая реверс-инжиниринговая копия логики ханипота, которую я поймал в дикой природе.
 * НЕ ДЕПЛОЙТЕ ЭТО. Код исключительно для образовательного разбора.
 */
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");
        // Если это ордер на продажу (перевод на адрес пула) и отправитель не в вайтлисте
        if (!_isWhitelisted[from] && !_isWhitelisted[to]) {
            // Трюк: сжигаем кучу газа через бесконечный цикл или тяжелое выделение памяти,
            // чтобы транзакция покупателя вылетела с ошибкой "Out of Gas"!
            assembly {
                let m := mload(0x40)
                mstore(m, 0xdeadbeef)
                // Искусственно палим газ на попытках продажи
                invalid()
            }
        }
        _balances[from] -= amount;
        _balances[to] += amount;
    }
}

Заметили, что тут происходит? При покупке все проходит как по маслу. Но стоит вам запустить свап через swapExactTokensForETH на Uniswap, как контракт проверяет, есть ли ваш кошелек в вайтлисте. Если нет, он пускает в ход опкод invalid() или бесконечный цикл, сжигает весь выделенный газ и откатывает транзакцию с загадочной ошибкой. Большинство обычных юзеров думают: «Типа проскользание (slippage) слишком низкое» и забивают, пока разраб тихонько вычищает пул.

4. Как драйнеры обходят защиты в Web3

Давайте обсудим эксплойты с офчейн-подписями, а именно, злоупотребление стандартами Permit2 и EIP-712.

Обычные разрешения требуют отправки ончейн-транзакции с вызовом approve(spender, amount). Это стоит газа и вызывает понятное предупреждение в интерфейсе кошелька касательно лимитов.

Скрипты драйнеров обходят это за счет стандарта Permit2 от Uniswap или аппрувов EIP-2612. Злодейская децентрализованная аппка просит вас подписать якобы безобидную строчку данных с помощью цифровой подписи кошелька (eth_signTypedData_v4). Под капотом эта подпись дает смарт-контракту хакера явное добро на вывод ваших токенов ERC-20 или NFT вообще без каких-либо дополнительных ончейн-подтверждений с вашей стороны!

// Образец вредоносного пейлоада, собранного скриптами дринеров
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
};

Если подписать этот пейлоад, хакер забирает офчейн-подпись, сам пушит ее в контракт Permit2, платит за газ и мгновенно уводит ваши USDC.

5. Реверс-инжиниринг EVM-байкода: вычисляем скам без исходного кода

Что происходит, когда новый токен еще не верифицирован на Etherscan или BscScan? Большинство тут же сливается. Но для меня, как СТО (и бывшего аудитора безопасности), неверифицированный байткод - это как раз то, где начинается самое интересное. Чтобы понять, пытается ли контракт вас обокрасть, исходник на Solidity вообще не нужен.

Когда разработчики компилируют Solidity-код в EVM-байткод, названия функций превращаются в 4-байтовые идентификаторы - селекторы функций (Function Selectors, то есть первые 4 байта хэша Keccak-256 от сигнатуры функции).

Например, transfer(address,uint256) всегда хэшируется в 0xa9059cbb.

Если вставить байткод неверифицированного контракта в декомпилятор вроде Dedaub Bytecode Decompiler или ethervm.io, смотрите напрямую на диспетчер селекторов или ищите эти подозрительные хэши функций прямо в сыром байткоде:

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

Стоп... а почему вас вообще должны волновать эти сигнатуры? Да потому что если в неверифицированном смарт-контракте есть 0x40c10f19 (mint), а владение (owner) не отказано (un-renounced), дев может втихую напечатать 10 миллиардов токенов из воздуха прямо себе на кошелек, дампить их на Uniswap и за секунды выгрести всю ликвидность до копейки.

Вот простой Python-скрипт на web3.py, который я использую для внутренних проверок: он сканирует байткод неверифицированных контрактов на опасные админские функции перед тем, как вообще взаимодействовать с токеном:

# Внутренний скрипт безопасности для детекта высокорисковых сигнатур функций в неверифицированном 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...")

6. Продвинутые тактики дрaйнеров: отравленные аппрувы & Address Poisoning

Скамеры больше не надеются только на пулы ликвидности на DEX; теперь они метят прямо в баланс вашего кошелька, используя баги UX и психологические уловки.

Атаки типа Address Poisoning

Открывали когда-нибудь историю транзакций в кошельке с удивлением, видя перевод на 0 ETH или 0.0001 токена с адреса, который выглядит почти один в один как ваш?

Это и есть Address Poisoning (отравление адресов).

Вредоносные скрипты мониторят мемпул в поисках транзакций с «жирных» кошельков. Они генерируют красивый vanity-адрес с помощью GPU-генераторов (вроде profanity), у которого первые 4–5 и последние 4–5 символов совпадают с вашим адресом (или адресом, куда вы часто переводите крипту).

Затем они отправляют нулевую транзакцию на ваш кошелек через transferFrom().

Цель? Сделать так, чтобы поддельный адрес замаячил у вас в истории недавних транзакций. В следующий раз, когда вы зайдёте отправить средства, вместо ввода адреса вручную или сверки каждого символа, вы просто скопируете верхний адрес из истории... и отправляете свои ETH прямо мошеннику.

Золотое правило: Никогда не копируйте адреса кошельков из истории транзакций! Всегда берите адреса из закладок, ENS-доменов или сверяйте адрес буквально посимвольно.

7. Чек-лист по харднингу: абсолютная защита в ончейне

Чтобы не потерять активы в современном Web3, внедрите этот базовый сетап операционной безопасности (OpSec):

• Разделите аппаратники для хранения и повседневных задач: Держите отдельный «холодный» хардверный кошелек (Ledger, Trezor, Keystone), который никогда не подключается к dApps, не подписывает сообщения и не клеймит аирдропы. А для ежедневных свапов и тестов экспериментальных DeFi-протоколов используйте отдельный «бернер-кошелек» с минимальным балансом.
• Отклоняйте слепое подписание (Blind Signing) оффчейн-сообщений: Отключите «blind signing» на аппаратном устройстве везде, где возможно. Если dApp требует подпись eth_sign или непонятный hex-пейлоад, который вы не можете прочитать, сразу отклоняйте.
• Задавайте кастомные лимиты расходов (Spend Limits): Подтверждая лимит на расходы ERC-20 токенов на Uniswap или 1inch, никогда не выбирайте «Unlimited». Вручную ставьте allowance ровно на ту сумму, которую собираетесь обменять. Так даже при взломе протокола ваши оставшиеся токены останутся нетронутыми.
• Регулярная гигиена ревоков: Поставьте напоминание на 1-е число каждого месяца: заходить на Revoke.cash или Token Approval Checker от Etherscan и сбрасывать старые или неиспользуемые разрешения во всех сетях (Ethereum, Arbitrum, Solana, Base, BSC).

Что ж, думаю, на этом с основными механиками разобрались! Если вам попался подозрительный контракт, есть вопросы или нужна помощь с тем, чтобы разобрать какой-нибудь странный хэш транзакции — пишите в комментариях. Постараюсь на всё ответить!