Como Identificar Crypto Drainer e Rug Pull a Tempo

1. Comparativo Rápido: Honeypot vs. Rug Pull vs. Wallet Drainer

2. Checklist de Segurança Passo a Passo Antes de Comprar Qualquer Token

Passo 1: Scan Automatizado do Contrato

Rode o endereço do token no Token Sniffer, na API do GoPlus Security e no DEXScreener. Se o DEXScreener mostrar 800 transações de compra e literalmente zero vendas numa janela de 4 horas, para tudo. É honeypot. Ponto final.

Passo 2: Tempo de Trava da Liquidez

Uma equipe séria trava os tokens do Pool de Liquidez (LP) por meio de protocolos como Uncx Network ou PinkSale.

• Red Flag: Liquidez destravada, mantida em uma EOA (Externally Owned Account) ou travada por menos de 6 meses.
• Green Flag: Tokens de LP queimados (enviados para 0x000000000000000000000000000000000000dead) ou travados em um contrato verificável por pelo menos um ano.

Passo 3: Checagem de Distribuição e Propriedade (Ownership)

Inspecione a aba Holders no Etherscan ou BscScan.

Se um punhado de carteiras (que não sejam exchanges ou endereços de queima) controlar mais de 5% a 10% do supply total, parabéns: você é a liquidez de saída dos caras. Além disso, veja se a propriedade do contrato foi renunciada (renounced). Se não foi, o dono pode alterar as taxas do nada, colocar seu endereço na blacklist ou pausar as transferências quando bem entender.

Passo 4: Auditoria de Transações e Assinaturas

Nunca assine transações às cegas. Os wallet drainers modernos raramente pedem transferências diretas de ETH hoje em dia — eles abusam de assinaturas off-chain como EIP-712, Permit2 ou EIP-2612 para burlar os alertas padrão das carteiras. Use extensões de simulação dinâmica de transação para verificar as mudanças de estado antes de transmitir qualquer coisa para a rede.

3. Análise Profunda de Segurança e Mecânica de Código

Bora falar de mecânica técnica de verdade. Por que os analisadores estáticos tradicionais deixam passar scams mais sofisticados? Porque os golpistas escrevem lógicas conscientes do contexto.

Pera aí... por que a galera ainda acha que código verificado no Etherscan é garantia de segurança? Eu me pergunto isso toda vez que vejo alguém reclamando que perdeu grana num projeto "verificado". A verificação do código-fonte só prova que o bytecode EVM implantado bate com os arquivos Solidity enviados. Isso não diz ABSOLUTAMENTE NADA sobre a lógica interna ser idônea ou maliciosa!

O Truque do Honeypot: Gas-Griefing e Taxas Dinâmicas

Uma técnica bem comum de honeypot é configurar taxas padrão de 2% no deploy inicial e, depois que entra liquidez suficiente, socar a taxa em 99% dentro da função _transfer().

Pior ainda são os honeypots dinâmicos com gas-griefing:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
/*
 * Minha réplica rápida de engenharia reversa de uma lógica de honeypot que peguei no radar.
 * NÃO faça deploy disso. É puramente para fins educacionais.
 */
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");
        // Se for uma ordem de venda (transferindo para o endereço do par) e o remetente não estiver na whitelist
        if (!_isWhitelisted[from] && !_isWhitelisted[to]) {
            // Truque: Queima quantidades brutais de gas usando um loop infinito ou alocação pesada de memória
            // fazendo a transação do comprador falhar com erro de "Out of Gas"!
            assembly {
                let m := mload(0x40)
                mstore(m, 0xdeadbeef)
                // Queima gas de propósito nas tentativas de venda
                invalid()
            }
        }
        _balances[from] -= amount;
        _balances[to] += amount;
    }
}

Sacou o que acontece aqui? Quando você compra, roda tudo lindo. Mas no segundo em que você chama um swapExactTokensForETH na Uniswap, o contrato checa se a sua carteira tá na whitelist. Se não estiver, ele executa um opcode invalid() ou entra num loop infinito, devorando todo o gas alocado e revertendo a transação com um erro criptografado. A maioria dos usuários de varejo acha que "o slippage tá baixo demais" e desiste, enquanto o dev vai drenando o pool aos poucos.

4. Como os Wallet Drainers Burlam as Defesas Web3

Bora analisar os exploits de assinatura off-chain — especificamente o abuso de Permit2 e EIP-712.

Aprovações (allowances) tradicionais exigem que você envie uma transação on-chain chamando approve(spender, amount). Isso gasta gas e dispara um pop-up claro na UI da carteira te avisando sobre a permissão.

Os scripts de drainer passam por cima disso usando o padrão Permit2 da Uniswap ou aprovações EIP-2612. O dApp malicioso te pede para assinar uma string de dados aparentemente inofensiva usando a assinatura da sua carteira (eth_signTypedData_v4). Nos bastidores, essa assinatura digital dá ao contrato inteligente do atacante autorização expressa para transferir seus tokens ERC-20 ou NFTs da sua conta sem precisar de mais nenhuma confirmação on-chain!

// Exemplo de payload malicioso construído por scripts de drainer
const domain = {
    name: 'Permit2',
    chainId: 1, // Mainnet
    verifyingContract: '0x000000000022D473030F116dDEE9F6B43aC78BA3' // Endereço oficial do Permit2 da Uniswap
};
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' }
    ]
};
// O usuário acha que está fazendo login num site, mas na verdade está liberando o saldo máximo dos tokens:
const value = {
    details: {
        token: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", // USDC
        amount: "1461501637330902918203684832716283019655932542975", // valor máximo uint160
        expiration: 2000000000,
        nonce: 0
    },
    spender: "0xMaliciousAttackerContractAddressHere...",
    sigDeadline: 2000000000
};

Se você assinar esse payload, o atacante pega essa assinatura off-chain, envia ele mesmo para o contrato do Permit2, paga a taxa de gas e rouba seus USDCs num piscar de olhos.

5. Engenharia Reversa em Bytecode da EVM: Identificando Scams Sem Código-Fonte

O que acontece quando um token novo ainda não foi verificado no Etherscan ou BscScan? A maioria da galera sai correndo. Mas como CTO (e ex-auditor de segurança), bytecode não verificado é onde a diversão de verdade começa. Você não precisa do código-fonte original em Solidity para descobrir se um contrato está tentando te passar a perna.

Quando os devs compilam o código Solidity para bytecode da EVM, os nomes das funções viram identificadores de 4 bytes chamados Function Selectors (os primeiros 4 bytes do hash Keccak-256 da assinatura da função).

Por exemplo, transfer(address,uint256) sempre resulta no hash 0xa9059cbb.

Se você jogar o bytecode de um contrato não verificado em uma ferramenta como o Dedaub Bytecode Decompiler ou no ethervm.io, olhe direto para o dispatcher de selectors ou busque por esses hashes de função suspeitos no bytecode bruto:

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

Peraí... por que você deveria se importar com essas assinaturas específicas? Porque se um contrato de token não verificado contiver a 0x40c10f19 (mint) junto com um dono que não renunciou ao contrato (un-renounced owner), o dev pode simplesmente imprimir 10 bilhões de tokens do nada direto na carteira privada dele, despejar tudo na Uniswap e drenar até o último centavo de liquidez em segundos.

Aqui está um snippet simples em Python usando web3.py que eu uso internamente para escanear bytecode não verificado em busca de funções de admin perigosas antes de interagir com qualquer token:

# Snippet de ferramenta interna de segurança para detectar assinaturas de função de alto risco em bytecode EVM não verificado.
# Criado para checagens automáticas rápidas durante investigações de smart contracts.
from web3 import Web3
# Conecta a um nó RPC público
w3 = Web3(Web3.HTTPProvider('https://eth.llamarpc.com'))
# Selectors de função de 4 bytes de alto risco conhecidos (hashes Keccak-256)
DANGEROUS_SELECTORS = {
    "0x40c10f19": "mint(address,uint256)",
    "0xe47d6060": "setBlacklist(address,bool)",
    "0x8a8c523c": "preventSell(address)",
    "0x70480932": "pauseTrading()"
}
def analyze_bytecode(contract_address: str):
    # Busca o bytecode bruto direto da chain
    code = w3.eth.get_code(Web3.to_checksum_address(contract_address)).hex()
    
    if code == '0x' or len(code) <= 2:
        print("[-] Endereço não possui código de contrato implantado (EOA).")
        return
    print(f"[+] Analisando EVM Bytecode para: {contract_address}")
    
    found_flags = []
    for selector, func_name in DANGEROUS_SELECTORS.items():
        # Remove o prefixo '0x' para fazer matching na string hex bruta
        clean_selector = selector[2:]
        if clean_selector in code:
            found_flags.append(func_name)
    if found_flags:
        print("[!] ALERTA DE RED FLAG! Funções perigosas detectadas no bytecode:")
        for flag in found_flags:
            print(f"    - {flag}")
    else:
        print("[+] Nenhum selector de admin oculto básico foi detectado no scan padrão.")
# Exemplo de uso com um endereço arbitrário
# analyze_bytecode("0x...")

6. Táticas Avançadas de Drainers: Approvals Envenenados & Address Poisoning

Os golpistas não dependem mais apenas de pools de liquidez em DEXs; agora eles miram direto no saldo da sua carteira usando falhas de experiência do usuário (UX) e truques psicológicos.

Ataques de Address Poisoning

Você já olhou o histórico da sua carteira e viu uma transferência de 0 ETH ou 0.0001 Token vinda de um endereço quase idêntico ao seu?

Isso é Address Poisoning (Envenenamento de Endereço).

Scripts de ataque monitoram a mempool em busca de transações de carteiras de alto valor. Eles geram um endereço customizado (vanity address) usando geradores via GPU (como o profanity) que compartilha exatamente os mesmos 4-5 primeiros e 4-5 últimos dígitos da sua carteira (ou de um endereço para o qual você envia fundos com frequência).

Depois, eles enviam uma transação de valor zero para a sua carteira usando transferFrom().

O objetivo? Eles querem que o endereço falso apareça no seu histórico recente de transações. Na próxima vez que você abrir a carteira para enviar fundos, em vez de digitar o endereço ou checar cada caractere, você copia e cola o endereço do topo do seu histórico... e, sem querer, manda seu ETH direto pro golpista.

Regra de Ouro: Nunca copie endereços de carteira direto do seu histórico de transações! Sempre copie de uma lista de contatos nos favoritos, de um domínio ENS, ou verifique absolutamente todos os caracteres do endereço.

7. O Checklist Definitivo de Hardening para Defesa On-Chain

Para manter seus ativos em segurança no Web3 atual, implemente este setup de segurança operacional (OpSec):

• Use Hardware Wallets Separadas para Interagir vs. Armazenar: Mantenha uma hardware wallet dedicada exclusivamente para "cold storage" (Ledger, Trezor, Keystone) que nunca se conecta a dApps, não assina mensagens e nem resgata airdrops. Tenha uma "burn-wallet" (carteira descartável) separada, com fundos mínimos, para swaps do dia a dia e para interagir com protocolos DeFi experimentais.
• Recuse Assinaturas Cegas (Blind Signing) Off-Chain: Desative o "blind signing" no seu dispositivo hardware sempre que possível. Se uma dApp web exigir eth_sign ou um payload em hex opaco que você não consegue ler, recuse imediatamente.
• Defina Limites de Gastos Personalizados (Custom Spend Limits): Ao aprovar um limite de gasto de ERC-20 na Uniswap ou 1inch, nunca selecione "Ilimitado". Ajuste manualmente a allowance para o valor exato que planeja negociar. Assim, mesmo que o protocolo seja explorado no futuro, o restante dos seus tokens continuará a salvo.
• Higiene Periódica de Revogação: Coloque um lembrete no calendário para todo dia 1º do mês acessar o Revoke.cash ou o Token Approval Checker do Etherscan para revogar permissões antigas ou não utilizadas em todas as redes (Ethereum, Arbitrum, Solana, Base, BSC).

Bom, acho que isso cobre todas as mecânicas principais! Se você esbarrou em algum contrato suspeito, ficou com dúvida nos snippets de código ou precisa de uma força para desvendar um hash de transação esquisito — manda bala nos comentários aqui embaixo. Vou fazer o possível para colar lá e te responder!