Learn
Analyse approfondie des techniques de Rug Pull à grande échelle

Analyse approfondie des techniques de Rug Pull à grande échelle

Intermédiaire
BlockchainTutorielTendances macroTechnologie
3/26/2024, 4:10:49 AM
La situation actuelle où la sécurité des jetons dépend entièrement de la prise de conscience du projet. Pour remédier à cela, nous devons peut-être améliorer les mécanismes des jetons ou introduire des schémas de surveillance efficaces de l'offre de jetons pour garantir la transparence dans les changements de quantité de jetons. Nous devons être vigilants, car si la prise de conscience de la fraude augmente, les techniques anti-fraude des attaquants évoluent également constamment. Il s'agit d'un jeu en cours, et nous devons continuer à apprendre et à réfléchir pour protéger nos intérêts.

Exploration technique du titre original | Décryptage de la technique de Rug Pull à grande échelle dans le jeu de la chaîne

Récemment, les experts en sécurité de CertiK ont fréquemment détecté de multiples cas de la même méthode d'escroquerie à la sortie, communément appelée Rug Pull. Après enquête approfondie, nous avons découvert que plusieurs cas de la même méthode pointent vers le même groupe, finalement lié à plus de 200 escroqueries à la sortie de tokens. Cela suggère que nous pourrions avoir découvert un groupe de pirates informatiques automatisé à grande échelle qui récolte des actifs grâce à des escroqueries à la sortie. Dans ces escroqueries à la sortie, les attaquants créent un nouveau jeton ERC20 et utilisent des jetons pré-minés ainsi qu'une certaine quantité de WETH pour créer un pool de liquidité Uniswap V2. Après que des robots ou des utilisateurs sur la chaîne aient effectué un certain nombre d'achats du nouveau token à partir du pool de liquidité, l'attaquant épuisera tout le WETH dans le pool avec des tokens générés à partir de rien. Comme les tokens obtenus par l'attaquant à partir de rien ne sont pas reflétés dans l'offre totale et ne déclenchent pas d'événements de transfert, ils ne sont pas visibles sur etherscan, ce qui rend difficile pour les étrangers de les détecter. Les attaquants ne considèrent pas seulement la dissimulation, mais conçoivent aussi une subterfuge pour tromper les utilisateurs ayant des compétences techniques de base qui vérifient etherscan, en utilisant un problème mineur pour cacher leurs véritables intentions...

Plongez dans l'arnaque

Escroquerie approfondie

En utilisant l'un des cas comme exemple, plongeons dans les détails de cette arnaque à la sortie. Ce que nous avons détecté, c'est une transaction où l'attaquant a utilisé une quantité massive de jetons (discrètement créés) pour épuiser le pool de liquidité et réaliser des bénéfices. Dans cette transaction, l'équipe du projet a échangé environ 416 483 104 164 831 (environ 416 quadrillions) de jetons MUMI contre environ 9,736 WETH, épuisant la liquidité du pool. Cependant, cette transaction n'est que la partie finale de toute l'arnaque. Pour comprendre toute l'arnaque, nous devons continuer à remonter le fil.

Déployer des jetons

Le 6 mars à 7h52 (heure UTC, identique pour la suite), l'adresse de l'attaquant (0x8AF8) a déployé un jeton ERC20 nommé MUMI (nom complet MultiMixer AI) à l'adresse 0x4894 et pré-miné 420 690 000 (environ 420 millions) jetons, tous alloués au déploiement du contrat.

Le nombre de jetons pré-minés correspond au code source du contrat.

Ajouter de la liquidité

À 8 heures pile (8 minutes après la création du jeton), l'adresse de l'attaquant (0x8AF8) a commencé à ajouter de la liquidité. L'adresse de l'attaquant (0x8AF8) appelle la fonction openTrading dans le contrat de jeton, crée un pool de liquidité MUMI-WETH via l'usine Uniswap v2, ajoute tous les jetons pré-minés et 3 ETH au pool de liquidité, et obtient finalement environ 1,036 jeton LP.


Il ressort des détails de la transaction que sur les 420 690 000 (environ 420 millions) jetons initialement utilisés pour ajouter de la liquidité, environ 63 103 500 (environ 63 millions) jetons ont été renvoyés au contrat de jeton (adresse 0x4894). En consultant le code source du contrat, on découvre que le contrat de jeton prélèvera des frais de traitement pour chaque transfert, et l'adresse de collecte des frais de traitement est le contrat de jeton lui-même (implémenté spécifiquement dans la fonction "_transfer").

Ce qui est étrange, c'est que l'adresse fiscale 0x7ffb (l'adresse pour la collecte des frais de transfert) a été définie dans le contrat, mais les frais finaux ont été envoyés au contrat de jeton lui-même.

Par conséquent, le nombre final de jetons MUMI ajoutés au pool de liquidité est de 357 586 500 (environ 350 millions) après impôts, et non pas 420 690 000 (environ 430 millions).

Verrouiller la liquidité

À 8h01 (1 minute après la création du pool de liquidité), l'adresse de l'attaquant (0x8AF8) a verrouillé les 1,036 jetons LP obtenus en ajoutant de la liquidité.

Après que le LP est verrouillé, théoriquement, tous les jetons MUMI détenus par l'adresse de l'attaquant (0x8AF8) sont verrouillés dans le pool de liquidité (à l'exception de la partie utilisée comme frais de traitement), donc l'adresse de l'attaquant (0x8AF8) n'a pas la capacité de le retirer grâce à la capacité de liquidité pour effectuer un Rug Pull. Afin de permettre aux utilisateurs d'acheter des jetons nouvellement lancés en toute confiance, de nombreuses parties prenantes du projet verrouillent LP, ce qui signifie que la partie prenante du projet déclare : "Je ne m'enfuirai pas, tout le monde peut acheter en toute confiance !", mais est-ce vraiment le cas ? Évidemment non, c'est le cas, poursuivons l'analyse.

Rug Pull

À 8:10, une nouvelle adresse d'attaquant ② (0x9DF4) est apparue, et il a déployé l'adresse fiscale 0x7ffb déclarée dans le contrat de jeton.

Il y a trois points qui méritent d’être mentionnés ici : 1. L’adresse où l’adresse fiscale est déployée et l’adresse où les jetons sont déployés ne sont pas les mêmes. Cela peut indiquer que la partie du projet réduit intentionnellement la corrélation entre chaque opération et l’adresse, ce qui rend plus difficile le suivi du comportement. 2. Le contrat de l’adresse fiscale n’est pas open source, ce qui signifie qu’il peut y avoir des opérations cachées dans l’adresse fiscale qui ne veulent pas être exposées. 3. Le contrat fiscal est déployé plus tard que le contrat de jeton et l’adresse fiscale dans le contrat de jeton a été codée en dur, ce qui signifie que l’adresse du contrat fiscal peut être prédite à l’avance par l’équipe de projet. Étant donné que l’instruction CREATE détermine l’adresse du créateur et nonce, l’adresse du contrat de déploiement est déterminée. Par conséquent, l’équipe de projet a utilisé l’adresse du créateur pour simuler et calculer à l’avance l’adresse du contrat. En fait, de nombreuses escroqueries de sortie sont menées par le biais d’adresses fiscales, et les caractéristiques du mode de déploiement des adresses fiscales sont conformes aux points 1 et 2 ci-dessus. À 11 heures (3 heures après la création du jeton), l’adresse de l’attaquant (2) (0x9DF4) a effectué un Rug Pull. En appelant la méthode « swapExactETHForTokens » du contrat fiscal (0x77fb), il a échangé 416 483 104 164 831 (environ 416 trillions) de jetons MUMI à l’adresse fiscale contre environ 9,736 ETH, et a épuisé la liquidité du pool.

Étant donné que le contrat fiscal (0x77fb) n'est pas open source, nous avons décompilé son bytecode et les résultats de la décompilation sont les suivants :

https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c

Après avoir décompilé la méthode "swapExactETHForTokens" du contrat de collecte de taxes (0x77fb), nous avons découvert que la fonctionnalité principale implémentée par cette fonction est d'échanger le montant spécifié "xt" (spécifié par l'appelant) de jetons MUMI détenus par le contrat de collecte de taxes (0x77fb) en ETH en utilisant le routeur UniswapV2, puis de l'envoyer à l'adresse déclarée comme "_manualSwap" dans l'adresse de taxe.


L'adresse de stockage de l'adresse _manualSwap est 0x0. Après avoir interrogé avec la commande getStorageAt de json-rpc, nous avons constaté que l'adresse correspondant à _manualSwap est exactement le déployeur du contrat fiscal (0x77fb) : attaquant ② (0x9DF4).

Le paramètre d'entrée xt de cette transaction Rug Pull est de 420 690 000 000 000 000 000 000, correspondant à 420 690 000 000 000 (environ 420 billions) jetons MUMI (la décimale des jetons MUMI est de 9).

En d'autres termes, en fin de compte, le projet a utilisé 420 690 000 000 000 (environ 420 billions) de MUMI pour vider le WETH dans le pool de liquidité et mener à bien l'ensemble de l'arnaque à la sortie. Cependant, il y a ici une question cruciale : d'où le contrat de collecte de taxes (0x77fb) a-t-il obtenu autant de jetons MUMI ? D'après le contenu précédent, nous avons appris que l'offre totale de jetons MUMI au moment du déploiement était de 420 690 000 (environ 420 millions). Cependant, après la fin du schéma de rug pull, lorsque nous avons interrogé l'offre totale de jetons dans le contrat de jetons MUMI, elle est restée à 420 690 000 (comme le montre la figure ci-dessous, affichée comme 420 690 000 000 000 000, ce qui nécessite de soustraire les zéros terminaux correspondant à la décimale, où la décimale est 9). Les jetons dans le contrat de collecte de taxes (0x77fb), dépassant largement l'offre totale (420 690 000 000 000, environ 420 billions), semblent être apparus de nulle part. Il est à noter que, comme mentionné précédemment, l'adresse 0x77fb, agissant en tant qu'adresse fiscale, n'a même pas été utilisée pour recevoir les frais de transaction générés lors du processus de transfert de jetons MUMI ; la taxe a été reçue par le contrat de jetons lui-même.

Révéler la technique

  • D'où vient le contrat fiscal ?

Afin d'explorer la source du jeton du contrat fiscal (0x7ffb), nous avons examiné son historique d'événements de transfert ERC20.

Les résultats ont révélé que sur les 6 événements de transfert impliquant 0x77fb, seuls des événements ont été observés où des jetons étaient transférés depuis le contrat de collecte de taxes (0x7ffb), sans aucun événement de transfert de jetons MUMI entrant. À première vue, il semble en effet que les jetons du contrat de collecte de taxes (0x7ffb) sont apparus de nulle part. Par conséquent, la quantité importante de jetons MUMI semblant apparaître de nulle part dans le contrat de collecte de taxes (0x7ffb) présente deux caractéristiques : 1. Cela n'a pas affecté le totalSupply du contrat MUMI. 2. L'augmentation des jetons n'a pas déclenché d'événement de transfert. Avec cela à l'esprit, il devient évident qu'il doit y avoir une porte dérobée dans le contrat de jetons MUMI, modifiant directement la variable de solde sans changements correspondants dans le totalSupply ou déclenchement d'événements de transfert. En d'autres termes, il s'agit d'une implémentation non standard ou malveillante d'un jeton ERC20, où les utilisateurs ne peuvent pas percevoir la création furtive de jetons par l'équipe du projet à partir de changements dans l'offre totale ou les événements. La prochaine étape consiste à vérifier cette idée en recherchant directement le mot-clé "balance" dans le code source du contrat de jetons MUMI.

Par conséquent, nous avons constaté qu'il existe une fonction de type privée « swapTokensForEth » dans le contrat, et le paramètre d'entrée est tokenAmount de type uint256. À la 5ème ligne de la fonction, la partie projet modifie directement _taxWallet, qui est le solde MUMI du contrat fiscal (0x7ffb) pourtokenAmount 10*_décimales, qui est 1 000 000 000 (environ 1 milliard) fois le tokenAmount, puis convertir le montant de tokenAmount de MUMI en ETH à partir du pool de liquidité et le stocker dans le contrat de jeton (0x4894). Ensuite, recherchez le mot-clé "swapTokenForEth".

La fonction "swapTokenForEth" est appelée dans la fonction "_transfer". Après un examen plus approfondi des conditions d'appel, on observe que : 1. Lorsque l'adresse du destinataire (adresse de destination) du transfert est le pool de liquidité MUMI-WETH. 2. La fonction "swapTokenForEth" est appelée uniquement lorsque la quantité de jetons MUMI achetés par d'autres adresses dans le pool de liquidité dépasse "_preventSwapBefore" (5 fois). 3. Le paramètre "tokenAmount" passé à la fonction est la valeur minimale entre le solde de jetons MUMI possédé par l'adresse du jeton et "_maxTaxSwap".



Cela signifie que lorsque le contrat détecte que l'utilisateur a échangé des WETH contre des jetons MUMI dans le pool plus de 5 fois, il créera secrètement une énorme quantité de jetons pour l'adresse fiscale, convertira une partie des jetons en ETH et les stockera dans le contrat de jetons. D'une part, la partie du projet collecte ostensiblement des impôts et les échange automatiquement contre une petite quantité d'ETH régulièrement et les place dans le contrat de jetons. Cela est montré aux utilisateurs et fait croire à tout le monde que c'est la source des bénéfices de la partie du projet. D'autre part, ce que fait vraiment l'équipe du projet est de modifier directement le solde du compte et de vider tout le pool de liquidités après que le nombre de transactions de l'utilisateur atteint 5 fois.

  • Comment faire du profit

Après l'exécution de la fonction 'swapTokenForEth', la fonction '_transfer' exécutera également sendETHToFee pour envoyer l'ETH obtenu de la collecte de taxes à l'adresse du jeton vers le contrat fiscal (0x77fb).

L'ETH dans le contrat fiscal (0x77fb) peut être retiré par la fonction "sauvetage" mise en œuvre dans son contrat.

Maintenant, revenons sur l'historique de rachat de la dernière transaction rentable dans l'ensemble de l'arnaque à la sortie.

Un total de deux échanges ont été effectués dans la transaction rentable. La première fois, il y avait 4 164 831 (environ 4,16 millions) de jetons MUMI pour 0,349 ETH, et la deuxième fois, il y avait 416 483 100 000 000 (environ 416 billions) de jetons MUMI pour 9,368 ETH. Le deuxième échange est l'échange initié dans la fonction "swapExactETHForTokens" dans le contrat fiscal (0x7ffb). La raison pour laquelle le nombre ne correspond pas aux 420 690 000 000 000 (environ 420 billions) de jetons représentés par les paramètres d'entrée est que certains des jetons sont utilisés comme taxe envoyée au contrat de jetons (0x4894), comme le montre la figure ci-dessous:

Le premier échange correspond au processus du second échange. Lorsque le jeton est envoyé du contrat fiscal (0x7ffb) au contrat de routeur, la condition de déclenchement de la fonction de porte dérobée dans le contrat de jeton est remplie, ce qui provoque le déclenchement de "swapTokensForEth". L'échange initié par la fonction n'est pas une opération critique.

  • Récolteur Derrière l'Escroquerie

Comme on peut le voir dans le contenu précédent, tout le cycle du jeton MUMI, du déploiement à la création du pool de liquidité, puis au Rug Pull, n'a pris que environ 3 heures. Cependant, il a réussi à réaliser plus de 50% de profit avec un coût de moins de 6,5 ETH environ (3 ETH pour l'ajout de liquidité, 3 ETH pour l'échange de MUMI à partir du pool de liquidité comme appât et moins de 0,5 ETH pour le déploiement du contrat et l'initiation des transactions), ce qui représente 9,7 ETH. L'attaquant a effectué cinq transactions d'échange d'ETH contre MUMI, qui n'avaient pas été mentionnées précédemment. Les détails des transactions sont les suivants :

En analysant les EOAs (comptes possédés à l'extérieur) opérant au sein de la liquidité, il a été découvert qu'une partie significative des adresses appartenait à des opérations "bot" on-chain. Compte tenu de la nature rapide de l'ensemble de l'escroquerie, il est raisonnable de supposer que la cible de cette escroquerie était les divers "bots" actifs et scripts sur la chaîne. Par conséquent, qu'il s'agisse de la conception de contrat apparemment inutile mais complexe, du déploiement de contrat, du processus de verrouillage de liquidité, ou du comportement suspect des attaquants échangeant activement de l'ETH contre des jetons MUMI en cours de route, tout cela peut être compris comme des tentatives des attaquants de tromper les mécanismes anti-fraude de divers bots on-chain. En suivant le flux de fonds, il a été constaté que tous les profits obtenus lors de l'attaque ont finalement été envoyés par l'adresse attaquante ② (0x9dF4) à l'adresse 0xDF1a.

En fait, à la fois les sources de financement initiales et les destinations finales de plusieurs escroqueries à la sortie récentes ont pointé vers cette adresse. Par conséquent, une analyse approximative et des statistiques des transactions de cette adresse ont été effectuées. Il a été constaté que l'adresse est devenue active il y a environ 2 mois et a initié plus de 7 000 transactions à ce jour, interagissant avec plus de 200 jetons. Parmi environ 40 enregistrements de transactions de jetons analysés, il a été constaté que presque tous les jetons, lorsqu'ils sont consultés dans leurs pools de liquidité correspondants, auraient une seule grande transaction d'échange qui épuise tout l'ETH dans le pool de liquidité, et tout le cycle d'escroquerie à la sortie est court. Voici les transactions de déploiement de certains jetons (par exemple, la cigarette chinoise):

https://etherscan.io/tx/0x324d7c133f079a2318c892ee49a2bcf1cbe9b20a2f5a1f36948641a902a83e17

https://etherscan.io/tx/0x0ca861513dc68eaef3017e7118e7538d999f9b4a53e1b477f1f1ce07d982dc3f

Par conséquent, on peut en conclure que cette adresse est en fait un collecteur de "arnaque à la sortie" automatisée à grande échelle, ciblant les opérations de bot on-chain. Cette adresse est toujours active.

En conclusion, si le processus de création de jetons ne correspond pas à la modification du totalSupply ou au déclenchement d'événements de transfert, il est difficile pour nous de percevoir si l'équipe du projet crée secrètement des jetons. Cela aggrave la situation actuelle où la sécurité des jetons dépend entièrement de la conscience de l'équipe du projet. Par conséquent, il peut être nécessaire de envisager d'améliorer les mécanismes de jetons existants ou d'introduire un schéma efficace de surveillance du total de l'offre de jetons pour garantir la transparence des changements de quantité de jetons. Se fier uniquement aux événements pour capturer les modifications d'état des jetons ne suffit pas. De plus, nous devons être conscients que bien que la sensibilisation à la prévention de la fraude augmente, les méthodes des attaquants pour contrer la fraude évoluent également. Il s'agit d'un jeu sans fin, et nous devons continuer à apprendre et à réfléchir pour nous protéger.

  • Outils utilisés dans cet article

Afficher les informations de base sur la transaction : https://etherscan.io/

Décompilation du contrat : app.dedaub.com/decompilejson-rpc :https://www.quicknode.com/docs/ethereum/eth_getStorageAt

Avertissement：

  1. Cet article est repris de [ CertiK], Transmettre le titre original '技术详解 | 链上打新局中局，大规模Rug Pull手法解密'. Tous les droits d'auteur appartiennent à l'auteur original [.CertiK]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
  2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
  3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.

Bagikan

Konten

Déployer des jetons

Ajouter de la liquidité

Verrouiller la liquidité

Rug Pull

Analyse approfondie des techniques de Rug Pull à grande échelle

Intermédiaire3/26/2024, 4:10:49 AM
La situation actuelle où la sécurité des jetons dépend entièrement de la prise de conscience du projet. Pour remédier à cela, nous devons peut-être améliorer les mécanismes des jetons ou introduire des schémas de surveillance efficaces de l'offre de jetons pour garantir la transparence dans les changements de quantité de jetons. Nous devons être vigilants, car si la prise de conscience de la fraude augmente, les techniques anti-fraude des attaquants évoluent également constamment. Il s'agit d'un jeu en cours, et nous devons continuer à apprendre et à réfléchir pour protéger nos intérêts.
BlockchainTutorielTendances macroTechnologie

Déployer des jetons

Ajouter de la liquidité

Verrouiller la liquidité

Rug Pull

Exploration technique du titre original | Décryptage de la technique de Rug Pull à grande échelle dans le jeu de la chaîne

Récemment, les experts en sécurité de CertiK ont fréquemment détecté de multiples cas de la même méthode d'escroquerie à la sortie, communément appelée Rug Pull. Après enquête approfondie, nous avons découvert que plusieurs cas de la même méthode pointent vers le même groupe, finalement lié à plus de 200 escroqueries à la sortie de tokens. Cela suggère que nous pourrions avoir découvert un groupe de pirates informatiques automatisé à grande échelle qui récolte des actifs grâce à des escroqueries à la sortie. Dans ces escroqueries à la sortie, les attaquants créent un nouveau jeton ERC20 et utilisent des jetons pré-minés ainsi qu'une certaine quantité de WETH pour créer un pool de liquidité Uniswap V2. Après que des robots ou des utilisateurs sur la chaîne aient effectué un certain nombre d'achats du nouveau token à partir du pool de liquidité, l'attaquant épuisera tout le WETH dans le pool avec des tokens générés à partir de rien. Comme les tokens obtenus par l'attaquant à partir de rien ne sont pas reflétés dans l'offre totale et ne déclenchent pas d'événements de transfert, ils ne sont pas visibles sur etherscan, ce qui rend difficile pour les étrangers de les détecter. Les attaquants ne considèrent pas seulement la dissimulation, mais conçoivent aussi une subterfuge pour tromper les utilisateurs ayant des compétences techniques de base qui vérifient etherscan, en utilisant un problème mineur pour cacher leurs véritables intentions...

Plongez dans l'arnaque

Escroquerie approfondie

En utilisant l'un des cas comme exemple, plongeons dans les détails de cette arnaque à la sortie. Ce que nous avons détecté, c'est une transaction où l'attaquant a utilisé une quantité massive de jetons (discrètement créés) pour épuiser le pool de liquidité et réaliser des bénéfices. Dans cette transaction, l'équipe du projet a échangé environ 416 483 104 164 831 (environ 416 quadrillions) de jetons MUMI contre environ 9,736 WETH, épuisant la liquidité du pool. Cependant, cette transaction n'est que la partie finale de toute l'arnaque. Pour comprendre toute l'arnaque, nous devons continuer à remonter le fil.

Déployer des jetons

Le 6 mars à 7h52 (heure UTC, identique pour la suite), l'adresse de l'attaquant (0x8AF8) a déployé un jeton ERC20 nommé MUMI (nom complet MultiMixer AI) à l'adresse 0x4894 et pré-miné 420 690 000 (environ 420 millions) jetons, tous alloués au déploiement du contrat.

Le nombre de jetons pré-minés correspond au code source du contrat.

Ajouter de la liquidité

À 8 heures pile (8 minutes après la création du jeton), l'adresse de l'attaquant (0x8AF8) a commencé à ajouter de la liquidité. L'adresse de l'attaquant (0x8AF8) appelle la fonction openTrading dans le contrat de jeton, crée un pool de liquidité MUMI-WETH via l'usine Uniswap v2, ajoute tous les jetons pré-minés et 3 ETH au pool de liquidité, et obtient finalement environ 1,036 jeton LP.


Il ressort des détails de la transaction que sur les 420 690 000 (environ 420 millions) jetons initialement utilisés pour ajouter de la liquidité, environ 63 103 500 (environ 63 millions) jetons ont été renvoyés au contrat de jeton (adresse 0x4894). En consultant le code source du contrat, on découvre que le contrat de jeton prélèvera des frais de traitement pour chaque transfert, et l'adresse de collecte des frais de traitement est le contrat de jeton lui-même (implémenté spécifiquement dans la fonction "_transfer").

Ce qui est étrange, c'est que l'adresse fiscale 0x7ffb (l'adresse pour la collecte des frais de transfert) a été définie dans le contrat, mais les frais finaux ont été envoyés au contrat de jeton lui-même.

Par conséquent, le nombre final de jetons MUMI ajoutés au pool de liquidité est de 357 586 500 (environ 350 millions) après impôts, et non pas 420 690 000 (environ 430 millions).

Verrouiller la liquidité

À 8h01 (1 minute après la création du pool de liquidité), l'adresse de l'attaquant (0x8AF8) a verrouillé les 1,036 jetons LP obtenus en ajoutant de la liquidité.

Après que le LP est verrouillé, théoriquement, tous les jetons MUMI détenus par l'adresse de l'attaquant (0x8AF8) sont verrouillés dans le pool de liquidité (à l'exception de la partie utilisée comme frais de traitement), donc l'adresse de l'attaquant (0x8AF8) n'a pas la capacité de le retirer grâce à la capacité de liquidité pour effectuer un Rug Pull. Afin de permettre aux utilisateurs d'acheter des jetons nouvellement lancés en toute confiance, de nombreuses parties prenantes du projet verrouillent LP, ce qui signifie que la partie prenante du projet déclare : "Je ne m'enfuirai pas, tout le monde peut acheter en toute confiance !", mais est-ce vraiment le cas ? Évidemment non, c'est le cas, poursuivons l'analyse.

Rug Pull

À 8:10, une nouvelle adresse d'attaquant ② (0x9DF4) est apparue, et il a déployé l'adresse fiscale 0x7ffb déclarée dans le contrat de jeton.

Il y a trois points qui méritent d’être mentionnés ici : 1. L’adresse où l’adresse fiscale est déployée et l’adresse où les jetons sont déployés ne sont pas les mêmes. Cela peut indiquer que la partie du projet réduit intentionnellement la corrélation entre chaque opération et l’adresse, ce qui rend plus difficile le suivi du comportement. 2. Le contrat de l’adresse fiscale n’est pas open source, ce qui signifie qu’il peut y avoir des opérations cachées dans l’adresse fiscale qui ne veulent pas être exposées. 3. Le contrat fiscal est déployé plus tard que le contrat de jeton et l’adresse fiscale dans le contrat de jeton a été codée en dur, ce qui signifie que l’adresse du contrat fiscal peut être prédite à l’avance par l’équipe de projet. Étant donné que l’instruction CREATE détermine l’adresse du créateur et nonce, l’adresse du contrat de déploiement est déterminée. Par conséquent, l’équipe de projet a utilisé l’adresse du créateur pour simuler et calculer à l’avance l’adresse du contrat. En fait, de nombreuses escroqueries de sortie sont menées par le biais d’adresses fiscales, et les caractéristiques du mode de déploiement des adresses fiscales sont conformes aux points 1 et 2 ci-dessus. À 11 heures (3 heures après la création du jeton), l’adresse de l’attaquant (2) (0x9DF4) a effectué un Rug Pull. En appelant la méthode « swapExactETHForTokens » du contrat fiscal (0x77fb), il a échangé 416 483 104 164 831 (environ 416 trillions) de jetons MUMI à l’adresse fiscale contre environ 9,736 ETH, et a épuisé la liquidité du pool.

Étant donné que le contrat fiscal (0x77fb) n'est pas open source, nous avons décompilé son bytecode et les résultats de la décompilation sont les suivants :

https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c

Après avoir décompilé la méthode "swapExactETHForTokens" du contrat de collecte de taxes (0x77fb), nous avons découvert que la fonctionnalité principale implémentée par cette fonction est d'échanger le montant spécifié "xt" (spécifié par l'appelant) de jetons MUMI détenus par le contrat de collecte de taxes (0x77fb) en ETH en utilisant le routeur UniswapV2, puis de l'envoyer à l'adresse déclarée comme "_manualSwap" dans l'adresse de taxe.


L'adresse de stockage de l'adresse _manualSwap est 0x0. Après avoir interrogé avec la commande getStorageAt de json-rpc, nous avons constaté que l'adresse correspondant à _manualSwap est exactement le déployeur du contrat fiscal (0x77fb) : attaquant ② (0x9DF4).

Le paramètre d'entrée xt de cette transaction Rug Pull est de 420 690 000 000 000 000 000 000, correspondant à 420 690 000 000 000 (environ 420 billions) jetons MUMI (la décimale des jetons MUMI est de 9).

En d'autres termes, en fin de compte, le projet a utilisé 420 690 000 000 000 (environ 420 billions) de MUMI pour vider le WETH dans le pool de liquidité et mener à bien l'ensemble de l'arnaque à la sortie. Cependant, il y a ici une question cruciale : d'où le contrat de collecte de taxes (0x77fb) a-t-il obtenu autant de jetons MUMI ? D'après le contenu précédent, nous avons appris que l'offre totale de jetons MUMI au moment du déploiement était de 420 690 000 (environ 420 millions). Cependant, après la fin du schéma de rug pull, lorsque nous avons interrogé l'offre totale de jetons dans le contrat de jetons MUMI, elle est restée à 420 690 000 (comme le montre la figure ci-dessous, affichée comme 420 690 000 000 000 000, ce qui nécessite de soustraire les zéros terminaux correspondant à la décimale, où la décimale est 9). Les jetons dans le contrat de collecte de taxes (0x77fb), dépassant largement l'offre totale (420 690 000 000 000, environ 420 billions), semblent être apparus de nulle part. Il est à noter que, comme mentionné précédemment, l'adresse 0x77fb, agissant en tant qu'adresse fiscale, n'a même pas été utilisée pour recevoir les frais de transaction générés lors du processus de transfert de jetons MUMI ; la taxe a été reçue par le contrat de jetons lui-même.

Révéler la technique

  • D'où vient le contrat fiscal ?

Afin d'explorer la source du jeton du contrat fiscal (0x7ffb), nous avons examiné son historique d'événements de transfert ERC20.

Les résultats ont révélé que sur les 6 événements de transfert impliquant 0x77fb, seuls des événements ont été observés où des jetons étaient transférés depuis le contrat de collecte de taxes (0x7ffb), sans aucun événement de transfert de jetons MUMI entrant. À première vue, il semble en effet que les jetons du contrat de collecte de taxes (0x7ffb) sont apparus de nulle part. Par conséquent, la quantité importante de jetons MUMI semblant apparaître de nulle part dans le contrat de collecte de taxes (0x7ffb) présente deux caractéristiques : 1. Cela n'a pas affecté le totalSupply du contrat MUMI. 2. L'augmentation des jetons n'a pas déclenché d'événement de transfert. Avec cela à l'esprit, il devient évident qu'il doit y avoir une porte dérobée dans le contrat de jetons MUMI, modifiant directement la variable de solde sans changements correspondants dans le totalSupply ou déclenchement d'événements de transfert. En d'autres termes, il s'agit d'une implémentation non standard ou malveillante d'un jeton ERC20, où les utilisateurs ne peuvent pas percevoir la création furtive de jetons par l'équipe du projet à partir de changements dans l'offre totale ou les événements. La prochaine étape consiste à vérifier cette idée en recherchant directement le mot-clé "balance" dans le code source du contrat de jetons MUMI.

Par conséquent, nous avons constaté qu'il existe une fonction de type privée « swapTokensForEth » dans le contrat, et le paramètre d'entrée est tokenAmount de type uint256. À la 5ème ligne de la fonction, la partie projet modifie directement _taxWallet, qui est le solde MUMI du contrat fiscal (0x7ffb) pourtokenAmount 10*_décimales, qui est 1 000 000 000 (environ 1 milliard) fois le tokenAmount, puis convertir le montant de tokenAmount de MUMI en ETH à partir du pool de liquidité et le stocker dans le contrat de jeton (0x4894). Ensuite, recherchez le mot-clé "swapTokenForEth".

La fonction "swapTokenForEth" est appelée dans la fonction "_transfer". Après un examen plus approfondi des conditions d'appel, on observe que : 1. Lorsque l'adresse du destinataire (adresse de destination) du transfert est le pool de liquidité MUMI-WETH. 2. La fonction "swapTokenForEth" est appelée uniquement lorsque la quantité de jetons MUMI achetés par d'autres adresses dans le pool de liquidité dépasse "_preventSwapBefore" (5 fois). 3. Le paramètre "tokenAmount" passé à la fonction est la valeur minimale entre le solde de jetons MUMI possédé par l'adresse du jeton et "_maxTaxSwap".



Cela signifie que lorsque le contrat détecte que l'utilisateur a échangé des WETH contre des jetons MUMI dans le pool plus de 5 fois, il créera secrètement une énorme quantité de jetons pour l'adresse fiscale, convertira une partie des jetons en ETH et les stockera dans le contrat de jetons. D'une part, la partie du projet collecte ostensiblement des impôts et les échange automatiquement contre une petite quantité d'ETH régulièrement et les place dans le contrat de jetons. Cela est montré aux utilisateurs et fait croire à tout le monde que c'est la source des bénéfices de la partie du projet. D'autre part, ce que fait vraiment l'équipe du projet est de modifier directement le solde du compte et de vider tout le pool de liquidités après que le nombre de transactions de l'utilisateur atteint 5 fois.

  • Comment faire du profit

Après l'exécution de la fonction 'swapTokenForEth', la fonction '_transfer' exécutera également sendETHToFee pour envoyer l'ETH obtenu de la collecte de taxes à l'adresse du jeton vers le contrat fiscal (0x77fb).

L'ETH dans le contrat fiscal (0x77fb) peut être retiré par la fonction "sauvetage" mise en œuvre dans son contrat.

Maintenant, revenons sur l'historique de rachat de la dernière transaction rentable dans l'ensemble de l'arnaque à la sortie.

Un total de deux échanges ont été effectués dans la transaction rentable. La première fois, il y avait 4 164 831 (environ 4,16 millions) de jetons MUMI pour 0,349 ETH, et la deuxième fois, il y avait 416 483 100 000 000 (environ 416 billions) de jetons MUMI pour 9,368 ETH. Le deuxième échange est l'échange initié dans la fonction "swapExactETHForTokens" dans le contrat fiscal (0x7ffb). La raison pour laquelle le nombre ne correspond pas aux 420 690 000 000 000 (environ 420 billions) de jetons représentés par les paramètres d'entrée est que certains des jetons sont utilisés comme taxe envoyée au contrat de jetons (0x4894), comme le montre la figure ci-dessous:

Le premier échange correspond au processus du second échange. Lorsque le jeton est envoyé du contrat fiscal (0x7ffb) au contrat de routeur, la condition de déclenchement de la fonction de porte dérobée dans le contrat de jeton est remplie, ce qui provoque le déclenchement de "swapTokensForEth". L'échange initié par la fonction n'est pas une opération critique.

  • Récolteur Derrière l'Escroquerie

Comme on peut le voir dans le contenu précédent, tout le cycle du jeton MUMI, du déploiement à la création du pool de liquidité, puis au Rug Pull, n'a pris que environ 3 heures. Cependant, il a réussi à réaliser plus de 50% de profit avec un coût de moins de 6,5 ETH environ (3 ETH pour l'ajout de liquidité, 3 ETH pour l'échange de MUMI à partir du pool de liquidité comme appât et moins de 0,5 ETH pour le déploiement du contrat et l'initiation des transactions), ce qui représente 9,7 ETH. L'attaquant a effectué cinq transactions d'échange d'ETH contre MUMI, qui n'avaient pas été mentionnées précédemment. Les détails des transactions sont les suivants :

En analysant les EOAs (comptes possédés à l'extérieur) opérant au sein de la liquidité, il a été découvert qu'une partie significative des adresses appartenait à des opérations "bot" on-chain. Compte tenu de la nature rapide de l'ensemble de l'escroquerie, il est raisonnable de supposer que la cible de cette escroquerie était les divers "bots" actifs et scripts sur la chaîne. Par conséquent, qu'il s'agisse de la conception de contrat apparemment inutile mais complexe, du déploiement de contrat, du processus de verrouillage de liquidité, ou du comportement suspect des attaquants échangeant activement de l'ETH contre des jetons MUMI en cours de route, tout cela peut être compris comme des tentatives des attaquants de tromper les mécanismes anti-fraude de divers bots on-chain. En suivant le flux de fonds, il a été constaté que tous les profits obtenus lors de l'attaque ont finalement été envoyés par l'adresse attaquante ② (0x9dF4) à l'adresse 0xDF1a.

En fait, à la fois les sources de financement initiales et les destinations finales de plusieurs escroqueries à la sortie récentes ont pointé vers cette adresse. Par conséquent, une analyse approximative et des statistiques des transactions de cette adresse ont été effectuées. Il a été constaté que l'adresse est devenue active il y a environ 2 mois et a initié plus de 7 000 transactions à ce jour, interagissant avec plus de 200 jetons. Parmi environ 40 enregistrements de transactions de jetons analysés, il a été constaté que presque tous les jetons, lorsqu'ils sont consultés dans leurs pools de liquidité correspondants, auraient une seule grande transaction d'échange qui épuise tout l'ETH dans le pool de liquidité, et tout le cycle d'escroquerie à la sortie est court. Voici les transactions de déploiement de certains jetons (par exemple, la cigarette chinoise):

https://etherscan.io/tx/0x324d7c133f079a2318c892ee49a2bcf1cbe9b20a2f5a1f36948641a902a83e17

https://etherscan.io/tx/0x0ca861513dc68eaef3017e7118e7538d999f9b4a53e1b477f1f1ce07d982dc3f

Par conséquent, on peut en conclure que cette adresse est en fait un collecteur de "arnaque à la sortie" automatisée à grande échelle, ciblant les opérations de bot on-chain. Cette adresse est toujours active.

En conclusion, si le processus de création de jetons ne correspond pas à la modification du totalSupply ou au déclenchement d'événements de transfert, il est difficile pour nous de percevoir si l'équipe du projet crée secrètement des jetons. Cela aggrave la situation actuelle où la sécurité des jetons dépend entièrement de la conscience de l'équipe du projet. Par conséquent, il peut être nécessaire de envisager d'améliorer les mécanismes de jetons existants ou d'introduire un schéma efficace de surveillance du total de l'offre de jetons pour garantir la transparence des changements de quantité de jetons. Se fier uniquement aux événements pour capturer les modifications d'état des jetons ne suffit pas. De plus, nous devons être conscients que bien que la sensibilisation à la prévention de la fraude augmente, les méthodes des attaquants pour contrer la fraude évoluent également. Il s'agit d'un jeu sans fin, et nous devons continuer à apprendre et à réfléchir pour nous protéger.

  • Outils utilisés dans cet article

Afficher les informations de base sur la transaction : https://etherscan.io/

Décompilation du contrat : app.dedaub.com/decompilejson-rpc :https://www.quicknode.com/docs/ethereum/eth_getStorageAt

Avertissement：

  1. Cet article est repris de [ CertiK], Transmettre le titre original '技术详解 | 链上打新局中局，大规模Rug Pull手法解密'. Tous les droits d'auteur appartiennent à l'auteur original [.CertiK]. Si vous avez des objections à cette réimpression, veuillez contacter le Porte Apprendreéquipe, et ils s'en occuperont rapidement.
  2. Clause de non-responsabilité: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
  3. Les traductions de l'article dans d'autres langues sont réalisées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.
Mulai Sekarang
Daftar dan dapatkan Voucher
$100
!