Crypto Drainer et Rug Pull : Comment les détecter à temps

1. Comparatif express : Honeypot vs. Rug Pull vs. Wallet Drainer

2. La Checklist Sécu Étape par Étape Avant d'Acheter le Moindre Token

Étape 1 : Scan Automatisé du Contrat

Passez l'adresse du token à la moulinette sur Token Sniffer, l'API GoPlus Security et DEXScreener. Si DEXScreener affiche 800 transactions d'achat et littéralement zéro vente sur une fenêtre de 4 heures, on arrête tout. C'est un honeypot. Point barre.

Étape 2 : Durée de Verrouillage de la Liquidité (Liquidity Lock)

Une équipe legit verrouille ses tokens de pool de liquidité (LP) via des protocoles comme Uncx Network ou PinkSale.

• Red Flag : La liquidité est déverrouillée, détenue par un EOA (Externally Owned Account), ou bloquée pour moins de 6 mois.
• Green Flag : Les tokens LP sont burn (envoyés vers 0x000000000000000000000000000000000000dead) ou bloqués dans un contrat vérifiable pour au moins un an.

Étape 3 : Vérif de la Distribution & de l'Ownership

Checkez l'onglet Holders sur Etherscan ou BscScan.

Si une poignée de wallets (hors exchanges et adresses de burn) contrôlent plus de 5 à 10 % de la supply totale, félicitations, c'est vous la liquidité de sortie (exit liquidity). Vérifiez aussi si l'ownership (propriété) du contrat a bien été renoncée. Si ce n'est pas le cas, le owner peut modifier arbitrairement les taxes, blacklister votre adresse ou mettre les transferts en pause quand ça lui chante.

Étape 4 : Audit des Transactions & Signatures

Ne signez jamais de transactions à l'aveugle (blind-sign). Aujourd'hui, les wallet drainers demandent rarement des transferts ETH classiques — ils abusent des signatures off-chain comme l'EIP-712, Permit2 ou les signatures EIP-2612 pour contourner les alertes de sécurité standards de votre wallet. Utilisez des extensions de simulation dynamique de transaction pour inspecter les changements d'état (state changes) avant de broadcast.

3. Plongée Technique : Analyse de Sécu & Mécanique du Code

Parlons un peu technique. Pourquoi les analyseurs statiques traditionnels passent à côté des scams sophistiqués ? Parce que les scammers écrivent de la logique contextuelle (context-aware).

Attendez... pourquoi les gens pensent encore que la vérification du code sur Etherscan garantit quoi que ce soit en termes de sécu ? Je me pose la question à chaque fois que quelqu'un pleure d'avoir perdu de l'argent sur un projet "vérifié". La vérification du code source prouve juste que le bytecode EVM déployé correspond bien aux fichiers Solidity soumis. Ça ne dit absolument RIEN sur la nature éthique ou malveillante de la logique à l'intérieur de ces fichiers !

L'Astuce du Honeypot : Gas-Griefing & Taxes Dynamiques

Une technique classique de honeypot consiste à configurer des frais standards de 2 % au déploiement, puis à pumper la taxe à 99 % dans la fonction _transfer() une fois qu'il y a assez de liquidité dans la pool.

Pire encore, les honeypots basés sur du gas-griefing dynamique :

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
/*
 * Ma petite réplique reverse-engineerée d'une logique de honeypot trouvée dans la nature.
 * NE DÉPLOYEZ PAS ÇA. C'est purement pour l'analyse éducative.
 */
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 c'est un ordre de vente (transfert vers l'adresse de la paire) et que l'expéditeur n'est pas whitelisted
        if (!_isWhitelisted[from] && !_isWhitelisted[to]) {
            // Astuce : Brûler des tonnes de gas avec une boucle infinie ou une grosse allocation mémoire
            // ce qui fait crasher la transaction de l'acheteur avec une erreur "Out of Gas" !
            assembly {
                let m := mload(0x40)
                mstore(m, 0xdeadbeef)
                // Brûler le gas artificiellement lors des tentatives de vente
                invalid()
            }
        }
        _balances[from] -= amount;
        _balances[to] += amount;
    }
}

Vous captez l'entourloupe ? Quand vous achetez, tout passe crème. Mais à la seconde où vous routez un call swapExactTokensForETH sur Uniswap, le contrat checke si votre wallet est whitelisted. Si ce n'est pas le cas, il balance un opcode invalid() ou part dans une boucle infinie, siphonnant tout le gas alloué et faisant un revert de la transaction avec une erreur cryptique. La plupart des petits investisseurs se disent "Ah, le slippage est trop faible" et laissent tomber, pendant que le dev vide tranquillement la pool.

4. Comment les Wallet Drainers Contournent les Défenses du Web3

Parlons des exploits par signature off-chain — en particulier les abus liés à Permit2 et l'EIP-712.

Les allowances (autorisations) traditionnelles vous obligent à envoyer une transaction on-chain en appelant approve(spender, amount). Ça coûte du gas et ça déclenche une pop-up UI claire sur votre wallet pour vous alerter sur l'allowance.

Les scripts de drainers contournent ça en exploitant le standard Permit2 d'Uniswap ou les approvals EIP-2612. La dApp malveillante vous demande de signer une chaîne de données apparemment inoffensive en utilisant la signature de votre wallet (eth_signTypedData_v4). En coulisses, cette signature numérique donne au smart contract de l'attaquant l'autorisation explicite de vider vos tokens ERC-20 ou vos NFTs de votre compte sans exiger la moindre confirmation on-chain supplémentaire de votre part !

// Exemple de payload malveillant généré par des scripts de drainer
const domain = {
    name: 'Permit2',
    chainId: 1, // Mainnet
    verifyingContract: '0x000000000022D473030F116dDEE9F6B43aC78BA3' // Adresse officielle Permit2 d'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' }
    ]
};
// L'utilisateur pense se connecter à un site, mais autorise en fait l'accès au max de ses tokens :
const value = {
    details: {
        token: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", // USDC
        amount: "1461501637330902918203684832716283019655932542975", // valeur max d'un uint160
        expiration: 2000000000,
        nonce: 0
    },
    spender: "0xMaliciousAttackerContractAddressHere...",
    sigDeadline: 2000000000
};

Si vous signez ce payload, l'attaquant récupère cette signature off-chain, la soumet lui-même au contrat Permit2, paie les frais de gas, et vous siphonne vos USDC instantanément.

5. Reverse Engineering du Bytecode EVM : Repérer les Scams Sans Code Source

Qu'est-ce qui se passe quand un nouveau token n'est pas encore vérifié sur Etherscan ou BscScan ? La plupart des gens se taillent en courant. Mais en tant que CTO (et ex-auditeur sécu), le bytecode non vérifié, c'est là que le vrai fun commence. T'as pas vraiment besoin du code source Solidity d'origine pour piger si un smart contract essaie de te dépouiller.

Quand les devs compilent du code Solidity en bytecode EVM, les noms de fonctions se transforment en identifiants de 4 octets appelés Function Selectors (les 4 premiers octets du hash Keccak-256 de la signature de la fonction).

Par exemple, transfer(address,uint256) donnera toujours le hash 0xa9059cbb.

Si tu colles le bytecode d'un contrat non vérifié dans un outil comme Dedaub Bytecode Decompiler ou ethervm.io, jette un œil directement au selector dispatcher ou cherche ces hashs de fonctions suspectes dans le bytecode brut :

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

Attends... pourquoi tu devrais t'en soucier de ces signatures précisément ? Parce que si un contrat de token non vérifié contient 0x40c10f19 (mint) avec un owner non-renoncé, le dev peut imprimer en douce 10 milliards de tokens de nulle part directement sur son wallet perso, les dumper sur Uniswap, et vider chaque dollar de liquidité en deux secondes chrono.

Voici un petit snippet Python utilisant web3.py que j'utilise en interne pour scanner le bytecode des contrats non vérifiés à la recherche de fonctions admin dangereuses avant d'interagir avec le moindre token :

# Snippet d'outil de sécurité interne pour détecter les signatures de fonctions à haut risque dans le bytecode EVM non vérifié.
# Écrit pour des vérifications automatiques rapides lors de l'investigation de smart contracts.
from web3 import Web3
# Connexion à un nœud RPC public
w3 = Web3(Web3.HTTPProvider('https://eth.llamarpc.com'))
# Selectors de fonctions 4-byte à haut risque connus (hashs Keccak-256)
DANGEROUS_SELECTORS = {
    "0x40c10f19": "mint(address,uint256)",
    "0xe47d6060": "setBlacklist(address,bool)",
    "0x8a8c523c": "preventSell(address)",
    "0x70480932": "pauseTrading()"
}
def analyze_bytecode(contract_address: str):
    # Récupération du bytecode brut depuis la chain
    code = w3.eth.get_code(Web3.to_checksum_address(contract_address)).hex()
    
    if code == '0x' or len(code) <= 2:
        print("[-] L'adresse n'a aucun code de contrat déployé (EOA).")
        return
    print(f"[+] Analyse du bytecode EVM pour : {contract_address}")
    
    found_flags = []
    for selector, func_name in DANGEROUS_SELECTORS.items():
        # Suppression du préfixe '0x' pour le matching dans la chaîne hex brute
        clean_selector = selector[2:]
        if clean_selector in code:
            found_flags.append(func_name)
    if found_flags:
        print("[!] ALERTE RED FLAG ! Fonctions dangereuses détectées dans le bytecode :")
        for flag in found_flags:
            print(f"    - {flag}")
    else:
        print("[+] Aucun selector d'admin caché de base détecté lors du scan standard.")
# Exemple d'utilisation avec une adresse arbitraire
# analyze_bytecode("0x...")

6. Tactiques Avancées de Drainers : Approvals Empoisonnés & Address Poisoning

Les scammers ne comptent plus seulement sur les pools de liquidité des DEX ; ils ciblent directement le solde de ton wallet en exploitant des failles d'expérience utilisateur (UX) et des ficelles psychologiques.

Attaques par Address Poisoning

T'as déjà maté l'historique de ton wallet pour y trouver un transfert de 0 ETH ou 0.0001 Token venant d'une adresse qui ressemble comme deux gouttes d'eau à la tienne ?

C'est ça, l'Address Poisoning.

Des scripts d'attaque surveillent le mempool à la recherche de transactions de wallets à gros volume. Ils génèrent une vanity address via un générateur GPU (style Profanity) qui partage exactement les 4-5 premiers et 4-5 derniers caractères de ton wallet (ou d'une adresse à laquelle t'envoies souvent des fonds).

Ensuite, ils balancent une transaction à zéro euro vers ton wallet en utilisant transferFrom().

Le but de la manœuvre ? Ils veulent que leur fausse adresse apparaisse dans l'historique de tes transactions récentes. La prochaine fois que t'ouvres ton wallet pour envoyer des sous, au lieu de taper ton adresse ou de vérifier chaque caractère un par un, tu copier-colles l'adresse tout en haut de ton historique... et tu balances accidentellement tes ETH direct au scammer.

Règle d'or : Ne copie JAMAIS une adresse de wallet depuis ton historique de transactions ! Copie toujours tes adresses depuis un carnet de contacts en favori, un domaine ENS, ou alors vérifie chaque caractère de l'adresse sans exception.

7. Le Checklist Ultime de Hardening pour la Défense On-Chain

Pour garder tes assets en sécurité dans le Web3 d'aujourd'hui, mets en place ce setup de sécurité opérationnelle (OpSec) :

• Utilise des Hardwallets Séparés pour Interagir vs. Stocker : Garde un hardware wallet de "cold storage" dédié (Ledger, Trezor, Keystone) qui ne se connecte jamais aux dApps, ne signe aucun message et ne claim aucun airdrop. À côté, contiens un "burn-wallet" séparé avec un minimum de fonds pour tes swaps de tous les jours et tes expérimentations sur des protocoles DeFi.
• Refuse le Blind Signing de Messages Off-Chain : Désactive le "blind signing" sur ton hardware wallet dès que c'est possible. Si une dApp web exige un eth_sign ou un payload hex opaque que tu ne peux pas lire, refuse immédiatement.
• Définis des Limites de Dépense Personnalisées : Quand tu approuves un ceiling de dépense ERC-20 sur Uniswap ou 1inch, ne choisis jamais "Illimité". Règle manuellement l'allowance au montant exact que tu prévois de trader. De cette façon, même si le protocole se fait exploiter plus tard, tes tokens restants ne seront pas touchés.
• Hygiène de Révocation Régulière : Programme-toi un rappel le 1er de chaque mois pour faire un tour sur Revoke.cash ou sur le Token Approval Checker d'Etherscan afin de révoquer les permissions périmées ou inutilisées sur tous tes réseaux (Ethereum, Arbitrum, Solana, Base, BSC).