Avertissement de sécurité Web3丨Un nouveau jeu au sein de la chaîne, décryptage à grande échelle de la méthode Rug Pull

Récemment, l'équipe d'experts en sécurité CertiK a fréquemment détecté plusieurs « escroqueries à la sortie » utilisant la même tactique, communément appelée Rug Pull.

Après avoir mené des recherches approfondies, nous avons constaté que plusieurs incidents utilisant les mêmes tactiques pointaient vers le même gang et étaient finalement liés à plus de 200 escroqueries au retrait de jetons. Cela indique que nous avons peut-être découvert une équipe de piratage automatisé à grande échelle qui récupère des actifs via des « escroqueries à la sortie ».

Dans ces escroqueries à la sortie, l'attaquant créera un nouveau jeton ERC20 et créera un pool de liquidité Uniswap V2 avec le jeton pré-miné au moment de la création plus un certain montant de WETH.

Lorsque le nouveau robot de la chaîne ou l'utilisateur achète de nouveaux jetons dans le pool de liquidité un certain nombre de fois, l'attaquant utilisera les jetons générés à partir de rien pour épuiser tous les WETH du pool de liquidité.

Étant donné que les jetons obtenus par l'attaquant à partir de rien ne sont pas reflétés dans l'offre totale (totalSupply) et ne déclenchent pas l'événement de transfert, ils ne peuvent pas être vus dans Etherscan, ce qui rend leur perception difficile par le monde extérieur.

Les attaquants ont non seulement envisagé la dissimulation, mais ont également conçu un jeu dans le jeu pour paralyser les utilisateurs possédant des compétences techniques de base et capables de lire l'Etherscan, et utilisent un petit problème pour dissimuler leur véritable objectif...

Arnaque plus profonde

Prenons l’un de ces cas comme exemple pour expliquer les détails de cette arnaque à la sortie.

Ce que nous avons détecté était en fait une transaction dans laquelle l'attaquant a utilisé une énorme quantité de jetons (créés secrètement) pour drainer le pool de liquidités et réaliser un profit. Dans cette transaction, la partie au projet a utilisé un total de 416 483 104 164 831 (environ 416 000 milliards) MUMI pour échange Environ 9,736 WETH ont été libérés, drainant la liquidité du pool.

Cependant, cette transaction n’est que le dernier maillon de toute l’arnaque. Pour comprendre l’ensemble de l’arnaque, nous devons continuer à remonter jusqu’au bout.

Déployer des jetons

À 7h52 le 6 mars (heure UTC, la même ci-dessous), l'adresse de l'attaquant (0x8AF8) Rug Pull a déployé un jeton ERC20 (adresse 0x4894) nommé MUMI (nom complet MultiMixer AI) et l'a pré-miné 420 690 000 (environ 420 millions) de jetons ont été attribués et tous ont été attribués à des déployeurs sous contrat.

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

Ajouter des liquidités

À 8 heures précises (8 minutes après la création du token), l'adresse de l'attaquant (0x8AF8) a commencé à ajouter des liquidités.

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é-extraits 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) de jetons initialement utilisés pour ajouter de la liquidité, environ 63 103 500 (environ 63 millions) de jetons ont été renvoyés au contrat de jetons (adresse 0x4894). a constaté que le contrat de jeton facturera certains frais de traitement pour chaque transfert et que l'adresse de collecte des frais de traitement est le contrat de jeton lui-même (spécifiquement implémenté dans la "fonction _transfer").

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

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

Verrouiller les liquidités

À 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é.

Une fois le LP verrouillé, théoriquement tous les tokens 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 possibilité de la supprimer. grâce à la capacité de liquidité à effectuer Rug Pull.

Afin de permettre aux utilisateurs d'acheter en toute confiance les jetons nouvellement lancés, de nombreuses parties au projet verrouillent LP, ce qui signifie que la partie du projet dit : « Je ne m'enfuirai pas, tout le monde peut acheter en toute confiance ! », mais est-ce vraiment le cas ? ? Evidemment non, c’est le cas, poursuivons l’analyse.

Tirer le tapis

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

Il y a trois points qui méritent d’être mentionnés ici :

1. L'adresse où l'adresse fiscale est déployée n'est pas la même que l'adresse où les jetons sont déployés, ce qui peut indiquer que la partie au projet réduit intentionnellement la corrélation entre chaque opération et l'adresse, ce qui rend plus difficile le traçage 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 que vous ne souhaitez pas exposer.

3. Le contrat fiscal est déployé plus tard que le contrat symbolique et l'adresse fiscale dans le contrat symbolique a été codée en dur, ce qui signifie que la partie au projet peut prédire l'adresse du contrat fiscal. Puisque l'instruction CREATE détermine l'adresse du créateur et une fois, il est déployé. L’adresse du contrat est déterminée, l’équipe du projet a donc simulé l’adresse du contrat à l’avance en utilisant l’adresse du créateur.

**En fait, de nombreuses escroqueries à la sortie sont menées via des adresses fiscales, et les caractéristiques du mode de déploiement des adresses fiscales sont conformes aux points 1 et 2 ci-dessus. **

A 11 heures du matin (3 heures après la création du jeton), l'adresse de l'attaquant ② (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 000 milliards) de jetons MUMI à l'adresse fiscale contre environ 9 736 ETH et a épuisé les liquidités du pool.

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

Après avoir vérifié le code décompilé de la méthode "swapExactETHForTokens" du contrat fiscal (0x77fb), nous avons constaté que la fonction principale de cette fonction est de transférer le contrat fiscal (0x77fb) avec le numéro "xt" (spécifié par l'appelant) via Routeur uniswapV2. Les tokens MUMI sont échangés contre des ETH et envoyés à l'adresse "_manualSwap" déclarée dans l'adresse fiscale.

L'adresse de stockage de l'adresse _manualSwap est 0x0. Après interrogation avec la commande getStorageAt de json-rpc, on constate que l'adresse correspondant à _manualSwap est 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 000 milliards) de jetons MUMI (la décimale des jetons MUMI est 9).

En d’autres termes, au final, le projet a utilisé 420 690 000 000 000 (environ 420 000 milliards) de MUMI pour drainer le WETH dans le pool de liquidités et achever l’intégralité de l’arnaque de sortie.

Cependant, il y a ici une question cruciale : d’où vient le contrat fiscal (0x77fb) à partir de tant de jetons MUMI ?

D'après le contenu précédent, nous savons que l'offre totale de jetons MUMI au moment du déploiement du contrat de jetons était de 420 690 000 (environ 420 millions), et après la fin de l'arnaque à la sortie, l'offre totale que nous avons interrogée dans le contrat de jetons MUMI Le montant est toujours de 420 690 000 (indiqué par 420 690 000 000 000 000 dans la figure ci-dessous, vous devez soustraire 0 du chiffre décimal correspondant, qui est 9). Les jetons du contrat fiscal (0x77fb) dépassent de loin l'offre totale (420 690 000 000 000, environ 420 000 milliards) C'est comme si elle était apparue de nulle part. Il faut savoir que, comme mentionné ci-dessus, 0x77fb, comme adresse fiscale, n'a même pas été utilisée pour recevoir les frais de traitement générés lors du processus de transfert de token MUMI. La taxe a été perçue par le contrat symbolique.

Technique révélée

• D'où vient le contrat fiscal

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

Il a été constaté que parmi les 6 événements de transfert liés à 0x77fb, il n'y avait que des transferts du contrat fiscal (0x7ffb), et il n'y avait aucun transfert de jetons MUMI. À première vue, les jetons du contrat fiscal (0x7ffb) sont vraiment apparus De nulle part.

Par conséquent, les énormes jetons MUMI qui sont apparus de nulle part dans l’adresse du contrat fiscal (0x7ffb) ont deux caractéristiques :

1. Pas d'impact sur l'approvisionnement total du contrat MUMI

2. L'augmentation des jetons ne déclenche pas l'événement Transfert

Ensuite l'idée est très claire, c'est à dire qu'il doit y avoir une porte dérobée dans le contrat de token MUMI. Cette porte dérobée modifie directement la variable balance, et lors de la modification de balabce, elle ne modifie pas totalSupply et ne déclenche pas l'événement Transfer.

En d'autres termes, il s'agit d'une implémentation de jeton ERC20 non standard ou malveillante. Les utilisateurs ne peuvent pas détecter que le côté du projet crée secrètement des jetons à partir de changements dans l'offre totale et d'événements. **

L'étape suivante consiste à vérifier l'idée ci-dessus.Nous recherchons directement le mot-clé « solde » dans le code source du contrat de token MUMI.

En conséquence, nous avons constaté qu'il existe une fonction de type privé "swapTokensForEth" dans le contrat et que le paramètre d'entrée est tokenAmount de type uint256. Dans la 5ème ligne de la fonction, la partie au projet modifie directement _taxWallet, qui est le MUMI. le solde du contrat fiscal (0x7ffb). est tokenAmount * 10**_decimals, soit 1 000 000 000 (environ 1 milliard) de fois le tokenAmount, puis convertissez le montant tokenAmount de MUMI en ETH à partir du pool de liquidité et stockez-le dans le contrat de jeton (0x4894).

Recherchez ensuite le mot-clé « swapTokenForEth ».

La fonction "swapTokenForEth" est appelée dans la fonction "_transfer". Si vous regardez attentivement les conditions d'appel, vous trouverez :

1. Lorsque l'adresse de réception du transfert est le pool de liquidité MUMI-WETH.

2. La fonction "swapTokenForEth" ne sera appelée que lorsque d'autres adresses achèteront des jetons MUMI dans le pool de liquidité pour plus de _preventSwapBefore (5 fois)

3. Le tokenAmount entrant est la plus petite valeur entre le solde du jeton MUMI appartenant à l'adresse du jeton et _maxTaxSwap

C'est-à-dire que lorsque le contrat détecte que l'utilisateur a échangé plus de 5 fois des WETH contre des jetons MUMI dans le pool, il frappera secrètement une énorme quantité de jetons pour l'adresse fiscale, convertira une partie des jetons en ETH et stockera. eux dans le contrat symbolique.

** D'une part, la partie au projet collecte ostensiblement des taxes et les échange automatiquement régulièrement contre une petite quantité d'ETH et les insère dans le contrat de jetons. Ceci est montré aux utilisateurs et fait penser à tout le monde que c'est la source des revenus de la partie au projet. bénéfices. **

** D'un autre côté, ce que fait réellement l'équipe du projet, c'est modifier directement le solde du compte et drainer tout le pool de liquidités une fois que le nombre de transactions de l'utilisateur atteint 5 fois. **

• Comment faire du profit

Après avoir exécuté la fonction « swapTokenForEth », la fonction « _transfer » exécutera également sendETHToFee pour envoyer l'ETH obtenu grâce à la collecte des taxes dans l'adresse du jeton au contrat fiscal (0x77fb).

L'ETH du contrat fiscal (0x77fb) peut être retiré par la fonction « sauvetage » mise en place dans son contrat.

Revenons maintenant au record de rachat de la dernière transaction rentable de toute l’arnaque à la sortie.

Au total, deux échanges ont été effectués dans le cadre de la transaction rentable : la première fois, 4 164 831 (environ 4,16 millions) de jetons MUMI pour 0,349 ETH, et la deuxième fois, 416 483 100 000 000 (environ 416 000 milliards) 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 000 milliards) de jetons représentés par les paramètres d'entrée est que certains des jetons sont utilisés. comme taxe Envoyé au contrat de jeton (0x4894), comme le montre la figure ci-dessous :

Le premier échange correspond au deuxième processus d'échange. Lorsque le token est envoyé du contrat fiscal (0x7ffb) au contrat du routeur, la condition de déclenchement de la fonction backdoor dans le contrat de token est remplie, provoquant le déclenchement de « swapTokensForEth ». par la fonction n'est pas une opération critique.

• La faux derrière

Comme le montre ce qui précède, l'ensemble du cycle d'escroquerie à la sortie, depuis le déploiement jusqu'à la création du pool de liquidités, en passant par Rug Pull des jetons MUMI, ne prend qu'environ 3 heures, mais à un coût inférieur à environ 6,5 ETH (3 ETH sont utilisés pour Pour ajouter de la liquidité, 3 ETH ont été utilisés pour échanger des MUMI du pool de liquidité contre des incitations, et moins de 0,5 ETH ont été utilisés pour déployer des contrats et lancer des transactions) et ont obtenu 9,7 ETH, avec un profit maximum de plus de 50 %. **

Il y a eu 5 transactions dans lesquelles l'attaquant a échangé ETH contre MUMI, qui n'ont pas été mentionnées dans l'article précédent. Les informations sur la transaction sont les suivantes :

En analysant les adresses EOA opérant en liquidité, nous avons constaté qu'une partie considérable des adresses sont des "nouveaux robots" sur la chaîne. Combiné avec les caractéristiques de l'ensemble de l'arnaque, qui est rapide dans et hors,** nous avons des raisons de croire que cible toute cette arnaque. Les cibles sont toutes sortes de nouveaux robots et de nouveaux scripts très actifs sur la chaîne. **

Par conséquent, qu'il s'agisse de la conception du contrat, du déploiement du contrat et du processus de verrouillage de la liquidité du jeton, apparemment inutiles mais compliqués, ou du comportement suspect de l'adresse associée de l'attaquant échangeant activement de l'ETH contre des jetons MUMI, on peut comprendre que l'attaquant essaie de Un déguisement conçu pour tenter de tromper les programmes anti-fraude de divers nouveaux robots de la chaîne. **

En suivant le flux de capitaux, nous avons constaté que tous les produits de l'attaque étaient finalement envoyés à l'adresse de règlement des fonds ** (0xDF1a)** par l'adresse d'attaque ② (0x9dF4).

En fait, la source initiale des fonds et la destination finale des fonds pour de nombreuses escroqueries à la sortie que nous avons récemment détectées pointent vers cette adresse. Nous avons donc effectué une analyse approximative et des statistiques sur les transactions à cette adresse.

Il a finalement été découvert que l'adresse était devenue active il y a environ 2 mois et avait initié plus de 7 000 transactions à ce jour et que l'adresse avait interagi avec plus de 200 jetons.

Nous avons analysé environ 40 enregistrements de transactions de jetons et avons constaté que dans les pools de liquidité correspondant à presque tous les jetons que nous avons examinés, il y aurait éventuellement une transaction d'échange avec un montant d'entrée bien supérieur à l'offre totale du jeton. L’ETH entrant est épuisé et la période entière d’arnaque à la sortie est plus courte.

Les transactions de déploiement de certains jetons (Mingyan Chine) sont les suivantes :

Par conséquent, nous pouvons conclure que cette adresse est en fait une récolteuse automatisée à grande échelle « d'escroquerie à la sortie », et que la cible de la récolte est le nouveau robot sur la chaîne.

**Cette adresse est toujours active. **

Écrivez à la fin

Si un jeton ne modifie pas le totalSupply lors de la frappe et ne déclenche pas l'événement de transfert, il nous sera alors difficile de détecter si le côté du projet frappe secrètement des jetons. Cela exacerbera également le problème de savoir si le jeton est sûr ou non. Cela ne dépend pas entièrement du côté du projet. "Statu quo conscient ou non".

**Par conséquent, nous devrons peut-être envisager d'améliorer le mécanisme de jetons existant ou d'introduire une solution efficace de détection du montant total des jetons pour garantir l'ouverture et la transparence des changements de montant des jetons. **Il ne suffit pas de capturer les changements de statut des jetons avec les événements maintenant.

Et ce à quoi nous devons être attentifs, c'est que même si la sensibilisation de chacun à la lutte contre la fraude s'améliore, les méthodes anti-fraude des attaquants s'améliorent également. C'est un jeu sans fin. Nous devons continuer à apprendre et à réfléchir pour y parvenir. .Protégez-vous dans le jeu.