Le chercheur en sécurité Florent a confirmé à The Block, le 31 mai, qu’il avait aidé à récupérer environ 1 003 ETH (environ 2 millions de dollars) qui étaient bloqués dans un contrat de l’ICO HongCoin de 2016 pendant près de 9 ans. Au moment de la publication, 2 investisseurs avaient déjà retiré au total 96,5 ETH, et avaient, de leur propre initiative, versé à Florent une récompense de type « white hat ».
Raison technique de la confirmation de la vulnérabilité de dépassement d’entiers et solutions
Florent a confirmé à The Block que le contrat HongCoin a été déployé à l’aide d’une version plus ancienne de Solidity, sans mécanismes de protection contre les dépassements d’entiers (qui ont ensuite été corrigés via la bibliothèque SafeMath). La fonction de remboursement refuse les titulaires dont le solde de jetons dépasse le compteur global. Au fil des années, une partie des remboursements a fait baisser le compteur à 356, ce qui a limité le plafond de remboursement à seulement 3,56 ETH (environ 7 000 dollars), alors que les soldes de la majorité des détenteurs étaient bien supérieurs à ce montant.
La solution confirmée par Florent consiste à utiliser la fonction de gestion de l’équipe HongCoin — initialement prévue pour frapper des tokens de récompense. Lorsque cette fonction est appelée avec des valeurs d’entrée spécifiques, en l’absence de protection contre les dépassements, le solde du détenteur est réinitialisé à 1, la vérification du remboursement passe ensuite, et les ETH bloqués sont ainsi libérés.
Pas une attaque unilatérale : l’équipe HongCoin signe elle-même la transaction de déblocage
Florent a confirmé que ce n’est pas un acte de piratage unilatéral. Il a d’abord envoyé un e-mail à l’équipe HongCoin, a vérifié la séquence des opérations sur une bifurcation du réseau principal Foundry, puis c’est l’équipe HongCoin qui a signé elle-même la transaction de déblocage. Du moment d’envoi du premier e-mail à la finalisation de l’ensemble du processus, il s’est écoulé environ une semaine. 41 détenteurs devaient réinitialiser leur solde, ce qui correspond à environ 1 000 ETH réellement gelés ; les 7 autres peuvent être remboursés directement. L’équipe a signé au total 41 transactions.
Florent a confirmé que la raison pour laquelle le pirate n’avait pas agi auparavant est que « le contrat ne contient aucune faille d’autorisation permettant au pirate de voler des fonds ; le seul résultat possible de toute attaque est que l’ETH soit renvoyé aux investisseurs initiaux » — il n’y a donc, pour le pirate, aucune possibilité de profit.
Méthodologie de confirmation : scanner et limites connues de Claude Code
Florent a confirmé qu’il avait mis en place un nœud Ethereum auto-hébergé et fait tourner un scanner pour repérer les contrats détenant plus de 100 ETH, puis les a filtrés un par un. Il a confirmé avoir utilisé Claude Code pour accélérer le tri et le regroupement des contrats, mais que l’IA présente des limites pour analyser des failles précises de contrats intelligents : « l’IA est souvent influencée par le fait que le contrat n’a pas encore été compromis ; elle en déduit alors très souvent par défaut que “ce n’est pas cassable”, ce qui est fréquemment faux. »
Florent a confirmé, le 24 mai, qu’il avait également récupéré auparavant 19,329 ETH (environ 40 590 dollars) depuis deux anciens contrats, dont un contrat d’ICO échouée en 2018 et des fonds d’utilisateurs après la fermeture de l’application par Liquality en 2024.
FAQ
Comment la vulnérabilité de dépassement d’entiers du contrat HongCoin a-t-elle entraîné un blocage des fonds pendant 9 ans ?
D’après la confirmation de Florent, la fonction de remboursement exige que le solde de tokens du détenteur ne dépasse pas le compteur global. Au fil des années, des remboursements partiels ont réduit le compteur à 356, et le montant maximal remboursable a été ramené à 3,56 ETH, tandis que la majorité des détenteurs détenaient un solde bien supérieur à cette valeur. La raison technique fondamentale est que la version antérieure de Solidity ne disposait pas de protection contre les dépassements d’entiers ; la bibliothèque SafeMath a ensuite corrigé ce problème.
Pourquoi le pirate n’avait-il pas attaqué auparavant ce contrat détenant une grande quantité d’ETH ?
D’après la confirmation de Florent, le contrat ne contient aucune faille d’autorisation permettant à un attaquant de voler des fonds ; quel que soit le type d’attaque, le seul résultat est que l’ETH est renvoyé aux investisseurs initiaux. Il n’existe donc aucun espace de profit pour le pirate, ce qui explique l’absence de motivation à attaquer.
Comment Claude Code a-t-il été utilisé lors de cette action de type white hat, et quelles limites l’IA présente-t-elle ?
Florent a confirmé avoir utilisé Claude Code pour accélérer le tri et le regroupement des contrats, mais il a confirmé que l’IA présente des limites lors de l’analyse de failles de contrats intelligents. Elle est souvent influencée par le fait que « le contrat n’a pas encore été compromis » et par défaut considère que la faille ne peut pas être exploitée ; il a indiqué que cette conclusion est souvent erronée.
