Analyse technique : Arnaque dans l'arnaque du lancement sur chaîne, décryptage d'une méthode de rug pull à grande échelle
TechFlow SélectionTechFlow Sélection
Analyse technique : Arnaque dans l'arnaque du lancement sur chaîne, décryptage d'une méthode de rug pull à grande échelle
Cet article détaille les éléments de cette escroquerie à la sortie en prenant l'un des cas comme exemple.
Dédié à des analyses Web3 approfondiesRédaction : CertiK
Récemment, l'équipe d'experts en sécurité de CertiK a détecté à plusieurs reprises des escroqueries identiques connues sous le nom de « rug pull ».
Après une analyse approfondie, nous avons découvert que ces multiples incidents utilisant la même méthode remontaient tous à un seul et même groupe, lié à plus de 200 cas de rug pull sur des jetons. Cela suggère que nous avons peut-être découvert une équipe de hackers automatisée à grande échelle, spoliant des actifs via des escroqueries de type « rug pull ».
Dans ces escroqueries, les attaquants créent un nouveau jeton ERC20, puis forment un pool de liquidités sur Uniswap V2 en combinant les jetons pré-minés au moment de la création avec une certaine quantité de WETH.
Lorsque des robots spécialisés dans les nouveaux jetons (« farming bots ») ou des utilisateurs achètent un certain nombre de fois ce nouveau jeton dans le pool de liquidités, les attaquants utilisent alors des jetons générés ex nihilo pour vider complètement le WETH présent dans le pool.
Étant donné que les jetons ainsi créés arbitrairement ne sont pas reflétés dans l'offre totale (totalSupply), ni ne déclenchent d'événement Transfer, ils restent invisibles sur Etherscan, rendant cette activité très difficile à détecter.
Les attaquants ont non seulement pensé à la discrétion, mais ont également mis en place un piège subtil destiné à tromper les utilisateurs disposant de compétences techniques basiques, capables de consulter Etherscan, en masquant leur véritable objectif derrière un problème mineur…
Analyse approfondie de l’escroquerie
Prenons un exemple parmi ceux que nous avons détectés afin d’en examiner les détails précis.
Ce que nous avons réellement observé est la transaction finale dans laquelle l’attaquant utilise une quantité massive de jetons (frappés clandestinement) pour vider le pool de liquidités et réaliser un profit. Dans cette transaction, l’équipe du projet a échangé environ 416 483 104 164 831 (environ 416 billions) de jetons MUMI contre environ 9,736 WETH, vidant complètement le pool.
Toutefois, cette transaction ne représente que la dernière étape de tout le stratagème. Pour comprendre pleinement l’escroquerie, il faut remonter plus loin.
Déploiement du jeton
Le 6 mars à 7h52 UTC (heure indiquée ci-après), l’adresse de l’attaquant (0x8AF8) a déployé un jeton ERC20 nommé MUMI (pour MultiMixer AI, adresse 0x4894), avec une pré-mine de 420 690 000 (environ 420 millions) de jetons, tous attribués au déployeur du contrat.
La quantité de jetons pré-minés correspond bien au code source du contrat.
Ajout de liquidités
À 8h00 (soit 8 minutes après la création du jeton), l’adresse de l’attaquant (0x8AF8) commence à ajouter des liquidités.
L’adresse (0x8AF8) appelle la fonction openTrading du contrat de jeton, crée un pool de liquidités MUMI-WETH via le factory Uniswap V2, y dépose tous les jetons pré-minés ainsi que 3 ETH, et obtient environ 1,036 jetons LP.
D’après les détails de la transaction, parmi les 420 690 000 jetons (environ 420 millions) initialement destinés aux liquidités, 63 103 500 (environ 63 millions) ont été renvoyés au contrat du jeton (adresse 0x4894). En examinant le code source, on constate que le contrat de jeton prélève des frais sur chaque transfert, et que l’adresse bénéficiaire de ces frais est le propre contrat du jeton (implémentation située dans la fonction _transfer).
Curieusement, bien qu’une adresse de taxation (tax address) soit définie dans le contrat (0x7ffb), les frais finissent par être envoyés au contrat du jeton lui-même.
Ainsi, la quantité réelle de jetons MUMI ajoutés au pool de liquidités est de 357 586 500 (environ 357 millions), après déduction des frais, et non de 420 690 000 (environ 420 millions).
Verrouillage des liquidités
À 8h01 (une minute après la création du pool), l’adresse de l’attaquant (0x8AF8) verrouille entièrement les 1,036 jetons LP obtenus lors de l’ajout de liquidités.
Une fois les LP verrouillés, théoriquement, tous les jetons MUMI détenus par l’adresse de l’attaquant (0x8AF8) sont bloqués dans le pool (à l’exception de ceux perçus comme frais). L’attaquant ne pourrait donc plus retirer les liquidités pour effectuer un rug pull.
De nombreux projets verrouillent leurs LP pour rassurer les investisseurs, en disant implicitement : « Je ne fuirai pas, achetez en toute confiance ». Mais est-ce vraiment le cas ? Manifestement non, comme le montre cet exemple. Analysons davantage.
Le Rug Pull
À 8h10, une nouvelle adresse attaquante② (0x9DF4) apparaît : elle déploie l’adresse de taxation (0x7ffb) déclarée dans le contrat du jeton.
Trois points méritent d’être soulignés :
1. L’adresse ayant déployé l’adresse de taxation est différente de celle ayant déployé le jeton, ce qui suggère une volonté délibérée de dissocier les opérations et de rendre le traçage plus difficile.
2. Le contrat de taxation n’est pas publié, ce qui signifie qu’il pourrait contenir des opérations cachées.
3. Le contrat de taxation est déployé après le contrat du jeton, bien que son adresse soit déjà codée en dur dans ce dernier. Cela signifie que les attaquants pouvaient prédire l’adresse du contrat de taxation. Étant donné que l’instruction CREATE produit une adresse déterministe selon l’adresse du créateur et son nonce, ils ont pu simuler à l’avance le calcul de cette adresse.
En réalité, de nombreuses escroqueries de type rug pull utilisent l’adresse de taxation, et le mode de déploiement de cette adresse correspond souvent aux points 1 et 2 ci-dessus.
À 11h00 (trois heures après la création du jeton), l’adresse attaquante② (0x9DF4) lance le rug pull. Elle appelle la méthode « swapExactETHForTokens » du contrat de taxation (0x77fb), échangeant 416 483 104 164 831 (environ 416 billions) de jetons MUMI présents dans ce contrat contre environ 9,736 ETH, vidant ainsi le pool de liquidités.
Comme le contrat de taxation (0x77fb) n’est pas publié, nous avons procédé à sa décompilation. Voici le résultat obtenu :
https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c
Après examen du code décompilé de la méthode « swapExactETHForTokens » du contrat de taxation (0x77fb), nous constatons que cette fonction permet essentiellement, via le routeur UniswapV2, d’échanger une quantité spécifiée (« xt ») de jetons MUMI détenus par le contrat de taxation (0x77fb) contre de l’ETH, puis d’envoyer cet ETH à l’adresse « _manualSwap » définie dans le contrat de taxation.
L’adresse « _manualSwap » se trouve au stockage 0x0. Une requête via la commande JSON-RPC getStorageAt révèle que cette adresse correspond bien au déployeur du contrat de taxation (0x77fb) : l’attaquant② (0x9DF4).
Le paramètre d’entrée « xt » de cette transaction rug pull est de 420 690 000 000 000 000 000 000, ce qui correspond à 420 690 000 000 000 (environ 420 billions) de jetons MUMI (le jeton MUMI ayant 9 décimales).
Au final, l’équipe du projet a utilisé 420 690 000 000 000 (environ 420 billions) de jetons MUMI pour vider entièrement le WETH du pool, accomplissant ainsi l’escroquerie complète.
Mais une question cruciale demeure : d’où proviennent tous ces jetons MUMI détenus par le contrat de taxation (0x77fb) ?
Nous savons que l’offre totale du jeton MUMI au déploiement était de 420 690 000 (environ 420 millions). Après l’escroquerie, l’offre totale affichée par le contrat reste inchangée (420 690 000 000 000 000 sur Etherscan, à ajuster de 9 décimales). Les jetons détenus par le contrat de taxation (420 690 000 000 000, soit environ 420 billions) semblent donc apparus de nulle part. Rappelons que 0x77fb, bien que désignée comme adresse de taxation, n’a jamais reçu les frais de transfert — ceux-ci étant en réalité versés au contrat du jeton lui-même.
Révélation de la méthode
Origine des jetons dans le contrat de taxation
Pour déterminer l’origine des jetons dans le contrat de taxation (0x7ffb), nous avons consulté son historique d’événements ERC20 de transfert.
Parmi les 6 événements liés à 0x77fb, seuls des transferts sortants apparaissent — aucun événement d’entrée de jetons MUMI. À première vue, les jetons semblent donc avoir été créés ex nihilo.
Ces jetons massifs apparaissant dans l’adresse du contrat de taxation (0x7ffb) présentent deux caractéristiques claires :
1. Aucun impact sur l’offre totale (totalSupply) du jeton MUMI.
2. Aucun déclenchement d’événement Transfer lors de leur apparition.
La conclusion est donc évidente : le contrat du jeton MUMI contient nécessairement une porte dérobée modifiant directement la variable de solde (balance), sans ajuster totalSupply ni déclencher d’événement Transfer.
Il s’agit donc d’une implémentation ERC20 non standard, voire malveillante, empêchant les utilisateurs de détecter que l’équipe du projet frappe clandestinement des jetons.
Pour vérifier cette hypothèse, nous recherchons simplement le mot-clé « balance » dans le code source du contrat MUMI.
Nous découvrons alors une fonction privée « swapTokensForEth », prenant en paramètre un montant tokenAmount. À la ligne 5 de cette fonction, l’équipe du projet attribue directement au portefeuille de taxation (_taxWallet), c’est-à-dire au contrat de taxation (0x7ffb), un solde égal à tokenAmount * 10**_decimals (soit 1 milliard de fois tokenAmount), puis échange tokenAmount jetons MUMI depuis le pool contre de l’ETH, gardé dans le contrat du jeton (0x4894).
Ensuite, cherchons « swapTokenForEth ».
La fonction « swapTokenForEth » est appelée dans la fonction « _transfer ». En analysant les conditions d’appel, on observe :
1. Si l’adresse destinataire (to) est le pool de liquidités MUMI-WETH.
2. Si d’autres adresses ont acheté des jetons MUMI dans le pool plus de _preventSwapBefore fois (5 fois), alors « swapTokenForEth » est déclenchée.
3. Le montant transmis (tokenAmount) est le minimum entre le solde du contrat en jetons MUMI et _maxTaxSwap.
Ainsi, dès que le contrat détecte plus de 5 achats de jetons MUMI dans le pool, il frappe massivement des jetons pour le compte de l’adresse de taxation, et en échange une partie contre de l’ETH qu’il conserve.
D’un côté, l’équipe du projet affiche publiquement des frais automatiquement convertis en petites quantités d’ETH — une mise en scène destinée à faire croire que c’est là leur source de revenus.
De l’autre, leur véritable objectif est d’exploiter ces transactions pour modifier directement les soldes et vider intégralement le pool de liquidités.
Mécanisme de profit
Après l’exécution de « swapTokenForEth », la fonction « _transfer » appelle aussi sendETHToFee pour envoyer l’ETH accumulé (provenant des taxes) du contrat du jeton vers le contrat de taxation (0x77fb).
L’ETH dans le contrat de taxation (0x77fb) peut ensuite être retiré via la fonction « rescue » implémentée dans ce contrat.
Revenons maintenant à la transaction finale de profit et analysons les échanges effectués.
Cette transaction comporte deux échanges : Premier échange : 4 164 831 (environ 4,16 millions) de MUMI contre 0,349 ETH. Second échange : 416 483 100 000 000 (environ 416 billions) de MUMI contre 9,368 ETH. Le second échange correspond à l’appel de « swapExactETHForTokens » depuis le contrat de taxation (0x7ffb). La différence avec le paramètre d’entrée (420 690 000 000 000) s’explique par le fait que certains jetons ont été prélevés comme taxe et envoyés au contrat du jeton (0x4894), comme montré ci-dessous :
Le premier échange correspond à une conversion automatique déclenchée par la fonction porte dérobée lors de l’envoi des jetons du contrat de taxation (0x7ffb) vers le routeur — une opération non essentielle.
Le grand faucheur derrière tout cela
Comme vu précédemment, le cycle complet du rug pull — du déploiement du jeton à la création du pool puis à l’escroquerie — n’a duré que 3 heures environ. Pour un coût total inférieur à 6,5 ETH (3 ETH pour les liquidités, 3 ETH pour acheter des MUMI afin d’attirer les acheteurs, moins de 0,5 ETH pour les déploiements et transactions), le gain atteint 9,7 ETH, soit un profit supérieur à 50 %.
L’attaquant a effectué 5 transactions d’achat de MUMI avec de l’ETH, non mentionnées auparavant. Voici les liens :
-
https://etherscan.io/tx/0x62a59ba219e9b2b6ac14a1c35cb99a5683538379235a68b3a607182d7c814817
-
https://etherscan.io/tx/0x0c9af78f983aba6fef85bf2ecccd6cd68a5a5d4e5ef3a4b1e94fb10898fa597e
-
https://etherscan.io/tx/0xc0a048e993409d0d68450db6ff3fdc1f13474314c49b734bac3f1b3e0ef39525
-
https://etherscan.io/tx/0x9874c19cedafec351939a570ef392140c46a7f7da89b8d125cabc14dc54e7306
-
https://etherscan.io/tx/0x9ee3928dc782e54eb99f907fcdddc9fe6232b969a080bc79caa53ca143736f75
L’analyse des adresses EOA intervenant dans les pools révèle qu’une grande partie sont des « bots de lancement » (farming bots). Compte tenu du caractère rapide de cette escroquerie (entrer-sortir rapidement), il est raisonnable de penser que la cible principale était précisément ces bots et scripts de trading automatisés actifs sur la chaîne.
Ainsi, la conception apparemment inutilement complexe du contrat, les étapes de déploiement et de verrouillage, ou encore les achats suspects d’ETH par les adresses liées aux attaquants, peuvent tous être interprétés comme des tentatives de tromper les systèmes antifraude des bots de trading.
En suivant le flux de fonds, nous avons constaté que tous les profits ont été envoyés par l’attaquant② (0x9dF4) vers une adresse de capitalisation (0xDF1a).
En réalité, plusieurs autres rug pulls récemment détectés ont tous pour origine ou destination finale cette même adresse. Nous avons donc analysé ses transactions.
Nous avons découvert que cette adresse est active depuis environ 2 mois, a réalisé plus de 7 000 transactions, et interagi avec plus de 200 jetons différents.
Après analyse d’environ 40 de ces jetons, nous avons constaté que dans presque tous les cas, le pool de liquidités subissait une transaction d’échange avec un volume dépassant largement l’offre totale du jeton, vidant totalement les liquidités ETH, et ce dans un délai très court.
Exemples de transactions de déploiement pour certains jetons (comme « Mingyan Zhonghua ») :
https://etherscan.io/tx/0x324d7c133f079a2318c892ee49a2bcf1cbe9b20a2f5a1f36948641a902a83e17
https://etherscan.io/tx/0x0ca861513dc68eaef3017e7118e7538d999f9b4a53e1b477f1f1ce07d982dc3f
Nous pouvons donc conclure que cette adresse est en réalité une machine automatisée à grande échelle de type « rug pull », ciblant spécifiquement les bots de lancement sur la blockchain.
Cette adresse est toujours active.
Conclusion
Si un jeton peut frapper de nouvelles unités sans modifier l’offre totale ni déclencher d’événement Transfer, il devient extrêmement difficile de détecter ces frappes clandestines. Cela renforce la situation actuelle où la sécurité d’un jeton repose entièrement sur la bonne foi de son équipe.
Nous devrions donc envisager d’améliorer les mécanismes existants ou d’introduire un système fiable de vérification de l’offre totale, garantissant la transparence des modifications de quantité. Se fier uniquement aux événements (events) pour surveiller l’état des jetons n’est plus suffisant.
Et surtout, rappelons-nous que même si la vigilance collective progresse, les techniques antifraude des attaquants progressent aussi. Ce combat est une lutte incessante. Seule une veille constante et une réflexion continue nous permettront de nous protéger dans ce jeu sans fin.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
CertiK
