2026-01-04 21:20:37

Récemment, un schéma préoccupant a été identifié. Par comparaison de données anormales, il est suspecté qu'il s'agit d'une variante d'attaque de "première frappe" (首次铸造攻击).

Voici d'abord le phénomène observé : après avoir investi 0.001 BNB pour acheter, on reçoit 1000 jetons (équivalent à 0,3$), mais lors du retrait, on obtient en fait 15 millions de jetons (valeur de 450$). Ce gain de 1500 fois dépasse largement toute erreur de glissement ou erreur mathématique normale, il y a forcément quelque chose derrière.

La méthode d'attaque la plus probable consiste à appeler directement la fonction mint. Certains contrats de jetons de mauvaise qualité ne vérifient pas du tout les permissions lors de la conception, permettant à n'importe qui d'appeler directement la fonction de mint :

function mint(address to, uint amount) public {
_mint(to, amount);
}

Dans ce cas, l'attaquant n'a qu'à acheter un peu de jetons (en laissant une trace d'adresse), puis à appeler directement mint pour créer des jetons pour lui-même, et enfin utiliser ces jetons qui apparaissent de nulle part pour ajouter ou retirer de la liquidité. Tout cela ressemble à une opération normale.

Une autre possibilité est une faille liée à la taxe de transfert. Certains jetons appliquent une taxe de transfert très élevée (par exemple 20%), ce qui signifie qu'en transférant 100 jetons de A à B, B reçoit 80, et 20 sont brûlés. Mais si l'attaquant devient fournisseur de liquidité, le pool pourrait, à cause d'un bug dans le calcul de la taxe, générer des jetons supplémentaires lors du transfert.

Il faut aussi se méfier des attaques de synchronisation de solde (balance sync attack). Après avoir ajouté de la liquidité, l'attaquant pourrait discrètement augmenter son solde de jetons ailleurs, puis retirer la liquidité pour empocher plus de valeur.

Tous ces schémas exploitent la logique même du contrat pour faire du mal. La clé pour se protéger réside dans la qualité de l'audit du contrat de jetons et dans la vérification que les contrôles d'autorisation sont bien en place.

BNB-0,17%

Voir l'original

Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.

7 J'aime

Récompense
7
6
Reposter
Partager

Commentaire

0/400

GhostChainLoyalist

· Il y a 7h

Encore cette même manœuvre, il est vraiment absurde que la fonction mint n'ait pas de vérification des permissions... Elle aurait dû être auditées depuis longtemps.

Voir l'originalRépondre0

BlockImposter

· 01-04 21:48

1500x ? Putain, ces chiffres sont délirants, c'est sûrement une faille de mint ou un bug fiscal qui fait des siennes ---- Encore un contrat pourri avec une vérification des permissions mal faite, il aurait fallu que ces développeurs apprennent à coder sur la blockchain depuis longtemps ---- Cette stratégie est trop vicieuse, créer des tokens puis retirer la liquidité en un clin d'œil, les gens ordinaires ne peuvent pas le voir ---- Il y a tellement de failles dans la taxe de transfert ? On dirait que la plupart des projets n'ont même pas pensé à ça ---- En fin de compte, c'est encore l'audit qui est crucial, dommage que la plupart des nouveaux tokens soient directement apés ---- Je n'avais pas pensé à l'attaque de synchronisation de solde, no wonder que certains gagnent de l'argent sans raison apparente ---- Le code du contrat est mis en public comme ça ? Vraiment, des gens osent écrire ça ou je suis juste naïf ---- Souviens-toi de ces stratégies, la prochaine fois que tu regardes un projet, vérifie d'abord le contrôle des permissions avant d'investir ---- Putain, donc ceux qui montent de 10x dès leur lancement ont peut-être été piratés ? Ou je suis trop nul pour voir ça

Voir l'originalRépondre0

FalseProfitProphet

· 01-04 21:47

Oh non, encore une vulnérabilité dans la fonction mint, j'ai vu cette astuce trop de fois, c'est la norme pour un marché en déclin Une différence de prix de 1500 fois ? Mint directement des pièces, on peut même se passer de l'audit du contrat

Voir l'originalRépondre0

WagmiWarrior

· 01-04 21:45

Oh là là, 1500x ? Quel contrat aussi pourri faut-il pour en arriver là, la vérification des permissions n’est qu’une façade --- La fonction mint ouverte en appel public, c’est vraiment incroyable, c’est aberrant --- Donc, les audits des petits contrats de tokens sont tous de la simple formalité, ils auraient dû être retirés depuis longtemps --- Je n’avais jamais entendu parler du bug de la taxe de transfert, il faut vraiment un développeur complètement fou pour penser à ce genre de détail --- Avec autant de vulnérabilités dans les contrats, le yield farming n’est vraiment qu’un jeu de hasard, je rigole quand on parle de revenus stables --- Pas étonnant qu’il y ait autant de révélations sur les shitcoins récemment, ils jouent tous ces petits jeux --- Ne pas avoir contrôlé correctement les permissions avant de lancer, c’est sérieux ce développement ? --- 1500 millions de tokens apparaissent de nulle part, ce n’est pas une machine à imprimer de l’argent ça, c’est tellement ironique --- Donc, pour les nouveaux tokens, il faut vraiment regarder le rapport d’audit, sinon c’est jouer avec le feu --- La combinaison de la taxe de transfert et des vulnérabilités de permission, ça va piéger combien de petits investisseurs ?

Voir l'originalRépondre0

MEVHunterNoLoss

· 01-04 21:37

Putain, 1500x ? Quel contrat aussi nul, ils ne font même pas de vérification des permissions ?

Voir l'originalRépondre0

RunWhenCut

· 01-04 21:22

艹，又是这套？mint没权限检查真的绝了，一看就是某个印度小哥random生成的垃圾合约 --- 1500倍？老哥这不是漏洞，这是在明着抢钱啊 --- Transfert de taxe encore plus absurde, dès qu’un bug dans le pool apparaît, il devient directement une imprimante à billets, on dirait qu’il y a de nouvelles astuces chaque semaine --- Audit ? Pour quoi faire, la plupart des projets ne veulent même pas dépenser d’argent, hein --- C’est pour ça que je n’achète maintenant que des tokens ayant été audités plus de deux fois, je ne touche pas aux autres même avec un APY élevé

Voir l'originalRépondre0