Crypto Drainer & Rug Pull erkennen: Wallet schützen

1. Schneller Vergleich: Honeypot vs. Rug Pull vs. Wallet Drainer

2. Step-by-Step-Checkliste für die Sicherheit vor jedem Token-Kauf

Schritt 1: Automatisierter Contract-Scan

Jage die Token-Adresse durch Token Sniffer, die GoPlus Security API und DEXScreener. Wenn DEXScreener dir in einem 4-Stunden-Fenster 800 Buy-Transaktionen und absolut null Verkäufe anzeigt: Stop! Das ist ein Honeypot. Punkt.

Schritt 2: Liquidity Lock-Dauer

Ein seriöses Team lockt seine Liquidity Pool (LP)-Tokens über Protokolle wie Uncx Network oder PinkSale.

• Red Flag: Die Liquidity ist nicht gelockt, liegt auf einem EOA (Externally Owned Account) oder ist für weniger als 6 Monate gesperrt.
• Green Flag: LP-Tokens sind geburnt (an 0x000000000000000000000000000000000000dead gesendet) oder für mindestens ein Jahr in einem verifizierbaren Contract gelockt.

Schritt 3: Verteilungs- & Ownership-Check

Check den Holders-Tab auf Etherscan oder BscScan.

Wenn eine Handvoll Wallets (die keine Exchanges oder Burn-Adressen sind) mehr als 5–10 % des Gesamt-Supplys halten, bist du die Exit-Liquidity. Check außerdem, ob die Contract-Ownership "renounced" (aufgegeben) wurde. Wenn nicht, kann der Dev nach Belieben Steuern anpassen, deine Adresse auf die Blacklist setzen oder Transaktionen pausieren, wann immer er lustig ist.

Schritt 4: Transaktions- & Signatur-Audit

Signiere niemals blind Transaktionen. Moderne Wallet Drainer fragen heute selten nach einfachen ETH-Transfers – sie missbrauchen Off-Chain-Signaturen wie EIP-712, Permit2 oder EIP-2612, um die Standard-Warnfenster der Wallet zu umgehen. Nutze Extensions für dynamische Transaktionssimulationen, um Statusänderungen genau zu prüfen, bevor du etwas an das Netzwerk broadcastest.

3. Deep-Dive: Sicherheitsanalyse & Code-Mechaniken

Reden wir über echte technische Mechaniken. Warum übersehen klassische statische Analysetools ausgefeilte Scams? Weil Scammer kontextbezogene Logik schreiben.

Moment mal... Warum glauben Leute eigentlich immer noch, dass ein verifizierter Code auf Etherscan Sicherheit garantiert? Ich frage mich das jedes Mal, wenn jemand rumheult, weil er bei einem "verifizierten" Projekt Kohle verloren hat. Source-Code-Verifizierung beweist lediglich, dass der deployed EVM-Bytecode mit den eingereichten Solidity-Dateien übereinstimmt. Sie sagt absolut gar nichts darüber aus, ob die Logik in diesen Dateien sauber oder bösartig ist!

Der Honeypot-Trick: Gas-Griefing & dynamische Steuern

Ein beliebter Honeypot-Trick besteht darin, beim initialen Deployment normale 2 % Gebühren einzustellen und die Fee in der _transfer()-Funktion auf 99 % hochzudrehen, sobald genug Liquidity im Pool ist.

Noch fieser sind dynamische Gas-Griefing-Honeypots:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
/*
 * Mein kurzes Reverse-Engineering-Replikat einer Honeypot-Logik, die ich in freier Wildbahn erwischt habe.
 * NICHT deployen. Das dient rein der bildenden Analyse.
 */
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");
        // Wenn es ein Verkauf ist (Transfer an Pair-Adresse) und der Sender nicht ge-whitelisted ist
        if (!_isWhitelisted[from] && !_isWhitelisted[to]) {
            // Trick: Verbrenne Unmengen an Gas durch eine Endlosschleife oder schwere Speicherallokation,
            // sodass die Transaktion des Käufers mit einem "Out of Gas"-Fehler fehlschlägt!
            assembly {
                let m := mload(0x40)
                mstore(m, 0xdeadbeef)
                // Künstlicher Gas-Burn bei Verkaufsversuchen
                invalid()
            }
        }
        _balances[from] -= amount;
        _balances[to] += amount;
    }
}

Siehst du, was hier passiert? Wenn du kaufst, geht alles glatt. Aber in dem Moment, in dem du einen swapExactTokensForETH-Call auf Uniswap absetzt, prüft der Contract, ob deine Wallet ge-whitelisted ist. Wenn nicht, führt er einen invalid()-Opcode oder eine Endlosschleife aus, frisst dein gesamtes zugewiesenes Gas auf und revertet die Transaktion mit einem kryptischen Fehler. Die meisten Retail-Nutzer denken dann: "Slippage war wohl zu niedrig" und geben auf – während der Dev den Pool langsam leersaugt.

4. Wie Wallet Drainer Web3-Schutzmechanismen umgehen

Sprechen wir über Off-Chain-Signatur-Exploits – speziell den Missbrauch von Permit2 und EIP-712.

Klassische Allowances erfordern das Senden einer On-Chain-Transaktion mit dem Aufruf approve(spender, amount). Das kostet Gas und löst im Wallet-UI ein klares Pop-up aus, das dich vor der Freigabe warnt.

Drainer-Skripte umgehen das, indem sie Uniswaps Permit2-Standard oder EIP-2612-Approvals nutzen. Die bösartige dApp fordert dich auf, eine scheinbar harmlose Zeichenkette mit deiner Wallet-Signatur (eth_signTypedData_v4) zu unterschreiben. Hinter den Kulissen gibt diese digitale Signatur dem Smart Contract des Angreifers die explizite Erlaubnis, deine ERC-20-Tokens oder NFTs direkt aus deinem Account abzuziehen – ohne dass du noch einmal eine On-Chain-Bestätigung abnicken musst!

// Beispiel für eine bösartige Payload, die von Drainer-Skripten generiert wird
const domain = {
    name: 'Permit2',
    chainId: 1, // Mainnet
    verifyingContract: '0x000000000022D473030F116dDEE9F6B43aC78BA3' // Offizielle Uniswap Permit2-Adresse
};
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' }
    ]
};
// Der Nutzer glaubt, er loggt sich auf einer Website ein, signiert aber in Wahrheit seine maximalen Token-Bestände weg:
const value = {
    details: {
        token: "0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48", // USDC
        amount: "1461501637330902918203684832716283019655932542975", // Maximum-Wert für uint160
        expiration: 2000000000,
        nonce: 0
    },
    spender: "0xMaliciousAttackerContractAddressHere...",
    sigDeadline: 2000000000
};

Wenn du diese Payload signierst, schnappt sich der Angreifer diese Off-Chain-Signatur, reicht sie selbst beim Permit2-Contract ein, zahlt die Gas-Fee und zieht deine USDC augenblicklich ab.

5. Reverse Engineering von EVM-Bytecode: Scams auch ohne Quellcode entlarven

Was passiert, wenn ein neuer Token auf Etherscan oder BscScan noch nicht verifiziert ist? Die meisten kriegen Panik und rennen weg. Aber als CTO (und ehemaliger Security Auditor) fängt der Spaß bei unverifiziertem Bytecode erst richtig an. Du brauchst nicht einmal den originalen Solidity-Quellcode, um zu checken, ob dich ein Contract abziehen will.

Wenn Entwickler Solidity-Code in EVM-Bytecode kompilieren, werden Funktionsnamen zu 4-Byte-Bezeichnern, den sogenannten Function Selectors (die ersten 4 Bytes des Keccak-256-Hashes der Funktionssignatur).

Zum Beispiel ergibt der Hash von transfer(address,uint256) immer 0xa9059cbb.

Wenn du den Bytecode eines unverifizierten Contracts in ein Tool wie den Dedaub Bytecode Decompiler oder ethervm.io wirfst, schau direkt auf den Selector-Dispatcher oder suche im Raw-Bytecode nach diesen verdächtigen Funktions-Hashes:

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

Halt... warum sollten dich genau diese Signaturen interessieren? Weil: Wenn ein unverifizierter Token-Contract 0x40c10f19 (mint) in Kombination mit nicht aufgegebenen Owner-Rechten enthält, kann der Dev klammheimlich 10 Milliarden Token aus dem Nichts direkt in seine private Wallet drucken, sie auf Uniswap dumpen und die komplette Liquidität in Sekunden leersaugen.

Hier ist ein einfaches Python-Snippet mit web3.py, das ich intern nutze, um unverifizierten Contract-Bytecode auf gefährliche Admin-Rechte zu scannen, bevor ich überhaupt mit einem Token interagiere:

# Internes Security-Tool-Snippet zum Erkennen von High-Risk-Funktionssignaturen in unverifiziertem EVM-Bytecode.
# Entwickelt für schnelle, automatisierte Checks bei Smart-Contract-Analysen.
from web3 import Web3
# Verbindung zu einem öffentlichen RPC-Node herstellen
w3 = Web3(Web3.HTTPProvider('https://eth.llamarpc.com'))
# Bekannte Risiko-Function-Selectors (4 Bytes / Keccak-256-Hashes)
DANGEROUS_SELECTORS = {
    "0x40c10f19": "mint(address,uint256)",
    "0xe47d6060": "setBlacklist(address,bool)",
    "0x8a8c523c": "preventSell(address)",
    "0x70480932": "pauseTrading()"
}
def analyze_bytecode(contract_address: str):
    # Raw-Bytecode direkt von der Chain abrufen
    code = w3.eth.get_code(Web3.to_checksum_address(contract_address)).hex()
    
    if code == '0x' or len(code) <= 2:
        print("[-] Adresse hat keinen deployed Contract-Code (EOA).")
        return
    print(f"[+] Analysiere EVM-Bytecode für: {contract_address}")
    
    found_flags = []
    for selector, func_name in DANGEROUS_SELECTORS.items():
        # '0x'-Präfix entfernen für Matching im Raw-Hex-String
        clean_selector = selector[2:]
        if clean_selector in code:
            found_flags.append(func_name)
    if found_flags:
        print("[!] RED-FLAG-WARNUNG! Gefährliche Funktionen im Bytecode entdeckt:")
        for flag in found_flags:
            print(f"    - {flag}")
    else:
        print("[+] Keine offensichtlichen, versteckten Admin-Selectors im Standard-Scan gefunden.")
# Beispielaufruf mit einer beliebigen Adresse
# analyze_bytecode("0x...")

6. Fortgeschrittene Drainer-Taktiken: Poisoned Approvals & Address Poisoning

Scammer verlassen sich schon lange nicht mehr nur auf DEX-Liquidity-Pools; sie nehmen dein bestehendes Wallet-Guthaben direkt ins Visier – mit UX-Schlupflöchern und psychologischen Tricks.

Address-Poisoning-Attacken

Hast du schon mal in deine Wallet-Historie geschaut und einen Transfer von 0 ETH oder 0,0001 Token von einer Adresse gesehen, die deiner eigenen zum Verwechseln ähnlich sieht?

Genau das ist Address Poisoning.

Angreifer-Skripte überwachen den Mempool nach Transaktionen von High-Value-Wallets. Sie generieren per GPU-Generator (wie profanity) eine Vanity-Adresse, die exakt dieselben ersten 4–5 und letzten 4–5 Zeichen hat wie deine Wallet (oder eine Adresse, an die du oft Kohle schickst).

Dann schicken sie dir per transferFrom() eine Zero-Value-Transaktion auf deine Wallet.

Das Ziel? Die Fake-Adresse soll in deiner Historie ganz oben auftauchen. Wenn du das nächste Mal deine Wallet öffnest, um Crypto zu verschicken, tippst du die Adresse nicht manuell ein oder prüfst jedes Zeichen, sondern kopierst einfach die oberste Adresse aus dem Verlauf... und zack: Deine ETH gehen direkt an den Scammer.

Faustregel: Kopiere NIEMALS Wallet-Adressen aus deiner Transaktionshistorie! Nutze immer Lesezeichen, ein Kontaktbuch, ENS-Domains oder überprüfe wirklich jedes einzelne Zeichen der Adresse.

7. Die ultimative Hardening-Checkliste für deine On-Chain-Defensive

Um deine Assets im modernen Web3 effektiv zu schützen, solltest du dieses OpSec-Setup (Operational Security) am Start haben:

• Trenne Interaktion und Storage strikt auf Hardware-Wallets: Nutze eine dedizierte "Cold Storage"-Hardware-Wallet (Ledger, Trezor, Keystone), die NIEMALS mit dApps verbunden wird, Nachrichten signiert oder Airdrops claimt. Für tägliche Swaps und DeFi-Experimente nutzt du eine separate "Burner-Wallet" mit minimalem Guthaben.
• Lehne Blind Signing bei Off-Chain-Nachrichten ab: Deaktiviere "Blind Signing" auf deinem Hardware-Wallet, wo immer es geht. Wenn eine dApp eth_sign oder einen undurchsichtigen Hex-Payload verlangt, den du nicht lesen kannst: sofort abbrechen.
• Setze individuelle Spending-Limits: Wenn du auf Uniswap oder 1inch ein ERC-20-Limit genehmigst, wähle NIEMALS "Unbegrenzt". Setze die Allowance manuell genau auf den Betrag, den du traden willst. Selbst wenn das Protokoll später gehackt wird, bleiben deine restlichen Token unangetastet.
• Regelmäßige Revoke-Routine: Setze dir am 1. jedes Monats einen Kalendereintrag, um auf Revoke.cash oder Etherscans Token Approval Checker alle veralteten oder ungenutzten Berechtigungen über alle Netzwerke (Ethereum, Arbitrum, Solana, Base, BSC) hinweg zu widerrufen.

So, damit sollten wir die wichtigsten Core-Mechaniken abgedeckt haben! Wenn ihr über einen verdächtigen Smart Contract gestolpert seid, Fragen zu den Code-Snippets habt oder Hilfe beim Zerlegen von einem merkwürdigen Transaktions-Hash braucht – haut es mir einfach unten in die Kommentare. Ich gebe mein Bestes, reinzuschauen und euch weiterzuhelfen!