Appuyez sur ESC pour fermer

Faux réseau GIWA : 766 ETH volés via un faux bridge L2 crypto

Analyse d'une escroquerie sophistiquée impliquant un faux mainnet GIWA, qui a coûté 766 ETH aux utilisateurs le 27/09/2026, et a compromis l'exchange décentralisé DYORSWAP suite à l'intégration d'un faux RPC.

Une tromperie de haut vol : comment falsifier une blockchain

Je faisais défiler mon fil de veille en matière de sécurité et... j'ai failli lâcher mon café. Sept cent soixante-six ethers. Disparus dans la nature. Et encore, s'il s'était agi d'un phishing classique via une fausse bibliothèque ou d'un exploit de contrat à base de flash loans, j'en aurais vu d'autres. Mais là, le montage est bien plus élégant. Les escrocs ont déployé un faux mainnet GIWA, l'ont branché sur le DEX d'un tiers et ont vidé les poches des utilisateurs pour quelques millions de dollars.

Décortiquons cet incident en détail, car d'un point de vue architectural, il y a de quoi satisfaire notre curiosité d'ingénieur. En tant que spécialiste de la cybersécurité et CTO en activité, je ne peux qu'admirer l'audace de l'exécution, même s'il ne faut évidemment pas envier l'équipe de DYORSWAP.

Attendez, comment peut-on seulement "truquer" une blockchain de niveau 2 ? Cela peut sembler délirant pour un néophyte, mais dans l'écosystème EVM, un réseau n'a rien de magique : c'est un ensemble de conventions et d'endpoints RPC.

Les attaquants ont pris une stack open source (probablement en forkant un truc du genre OP Stack) et ont déployé un nœud. Mais lancer un serveur ne suffit pas, il faut aussi persuader les wallets et les applications qu'il s'agit du produit officiel de l'exchange sud-coréen Upbit, dont le mainnet GIWA n'avait même pas encore officiellement démarré.

Ils ont hardcodé dans la configuration du nœud le Chain ID officiel — le chiffre 9134, que l'équipe de GIWA avait enregistré en amont pour sa future blockchain. Et c'est précisément là que réside la faille majeure de tout cet écosystème : les portefeuilles comme MetaMask vérifient un réseau sur la base de lignes de configuration et d'ID, et non grâce à des racines de confiance cryptographiques rattachées aux créateurs légitimes.

C'est à ce moment précis que le DEX DYORSWAP s'est fait piéger. Ils ont ajouté ce faux RPC à leur propre infrastructure, désireux d'être les premiers à surfer sur le Hype du nouveau réseau.

Vous savez, à l'époque où je faisais encore des audits de smart contracts à la petite semaine, on se disait toujours : bon, d'accord, le front-end peut être spoofé, le RPC peut être remplacé, mais le smart contract du bridge, c'est sacré, le code s'exécute directement sur la blockchain Ethereum ! Et c'est là que se cache le piège le plus redoutable de cette attaque.

Pourquoi les utilisateurs n'ont-ils rien vu venir ?

Les utilisateurs n'ont rien soupçonné parce que le bridge présentait l'interface native idéale pour transférer des fonds d'Ethereum vers le réseau L2 GIWA. Les gens signaient des transactions sur MetaMask, envoyant leurs précieux ETH vers un smart contract de dépôt sur le mainnet.

Techniquement, ce contrat avait été codé par les malfaiteurs de manière à imiter le comportement d'un validateur de dépôt standard. Dès que la transaction passait la validation sur le réseau principal, les escrocs prenaient le contrôle des fonds. En échange, l'utilisateur recevait de faux jetons sans la moindre valeur sur le solde de son faux L2. Les chiffres augmentaient à l'écran, créant l'illusion d'un bridge réussi, tandis que les ETH s'envolaient déjà vers les adresses des organisateurs pour se volatiliser dans des mixers. Au final, 1 335 adresses uniques ont été piégées, laissant environ 767,7 ETH sur le carreau. Ils ont réussi à blanchir proprement près de 766,3 ETH, en optimisant les frais de gaz au minimum.

L'équipe de DYORSWAP a assuré en déboursant plus de 200 ETH de sa poche pour indemniser les victimes. Je respecte cette approche vis-à-vis de la réputation de l'entreprise, même s'il va falloir colmater d'urgence cette brèche architecturale dans la validation des connexions RPC externes.

Passons maintenant à la partie pratique. Comment éviter de financer les prochains arnaqueurs si vous aimez tester les nouvelles blockchains en avant-première ? Je vous ai préparé un petit script Python de vérification pour auditer les nœuds RPC avant même d'envisager la moindre interaction avec votre wallet.

#!/usr/bin/env python3
import requests
def rpc_call(rpc_url, method, params=None):
    if params is None:
        params = []
    payload = {
        "jsonrpc": "2.0",
        "method": method,
        "params": params,
        "id": 1
    }
    response = requests.post(rpc_url, json=payload, timeout=10)
    response.raise_for_status()
    data = response.json()
    if "error" in data:
        raise RuntimeError(f"{method}: {data['error']}")
    return data.get("result")
def verify_evm_node(rpc_url, expected_chain_id):
    try:
        chain_id_hex = rpc_call(rpc_url, "eth_chainId")
        chain_id = int(chain_id_hex, 16)
        net_version = rpc_call(rpc_url, "net_version")
        client_version = rpc_call(rpc_url, "web3_clientVersion")
        block_number_hex = rpc_call(rpc_url, "eth_blockNumber")
        block_number = int(block_number_hex, 16)
        latest_block = rpc_call(
            rpc_url,
            "eth_getBlockByNumber",
            ["latest", False]
        )
        print("=" * 60)
        print(f"RPC URL         : {rpc_url}")
        print(f"Chain ID        : {chain_id}")
        print(f"Expected ChainID : {expected_chain_id}")
        print(f"Net Version     : {net_version}")
        print(f"Client Version   : {client_version}")
        print(f"Block Number     : {block_number}")
        if latest_block:
            print(f"Latest Block Hash: {latest_block.get('hash')}")
            print(f"Latest Block Num : {int(latest_block['number'], 16)}")
            print(f"Parent Hash      : {latest_block.get('parentHash')}")
            print(f"Timestamp        : {int(latest_block['timestamp'], 16)}")
        print("=" * 60)
        checks = []
        checks.append(chain_id == expected_chain_id)
        try:
            checks.append(int(net_version) == expected_chain_id)
        except Exception:
            checks.append(False)
        checks.append(block_number > 0)
        checks.append(
            latest_block is not None
            and latest_block.get("hash")
            and latest_block.get("parentHash")
            and latest_block.get("number")
        )
        if all(checks):
            print("VERIFICATION PASSED")
            return True
        print("VERIFICATION FAILED")
        return False
    except Exception as e:
        print(f"ERROR: {e}")
        return False
if __name__ == "__main__":
    verify_evm_node(
        "https://your-rpc-endpoint",
        9134
    )

Retenez la règle d'or : ne faites jamais confiance aux listes de réseaux partagées par des comptes Twitter louches ou des DEX non vérifiés, tant que le projet officiel n'a pas publié les endpoints exacts par le biais de ses canaux officiels (pas sur les réseaux sociaux, mais dans sa documentation ou sur son site web sécurisé par un certificat SSL valide). L'exchange Upbit a clairement affirmé que leur mainnet n'était pas encore en ligne et que tous les RPC actuels ne sont que pure spéculation et arnaque avérée.

Résumer cet article de blog avec :

FAQ

Les cybercriminels ont déployé un nœud Layer 2 compatible EVM usurpant l'identifiant Chain ID officiel 9134 de GIWA, connecté un contrat de dépôt frauduleux et piégé 1 335 portefeuilles en leur soutirant des ETH réels contre des soldes L2 fictifs.

La plateforme décentralisée a validé la légitimité du réseau uniquement sur la base de la correspondance du Chain ID 9134, omis de procéder à une vérification de la racine cryptographique et négligé la confirmation auprès des canaux officiels d'Upbit.

Les développeurs et utilisateurs doivent croiser les réponses RPC via des méthodes natives comme net_version, vérifier la continuité des en-têtes de bloc avec eth_getBlockByNumber et s'appuyer exclusivement sur de la documentation vérifiée cryptographiquement.
Oleg Filatov

As the Chief Technology Officer at EXMON Exchange, I focus on building secure, scalable crypto infrastructure and developing systems that protect user assets and privacy.

With over 15 years in cybersecurity, blockchain, and DevOps, I specialize in smart contract analysis, threat modeling, and secure system architecture.

At EXMON Academy, I share practical insights from real-world...

...

Partager votre avis

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués *