Rétro-ingénierie d'un contrat

Introduction

Il n'y a pas de secrets sur la chaîne de blocs, tout ce qui s'y passe est cohérent, vérifiable et accessible publiquement. Idéalement, les contrats devraient avoir leur code source publié et vérifié sur Etherscan (opens in a new tab). Cependant, ce n'est pas toujours le cas (opens in a new tab). Dans cet article, vous apprendrez comment faire la rétro-ingénierie de contrats en examinant un contrat sans code source, 0x2510c039cc3b061d79e564b38836da87e31b342f (opens in a new tab).

Il existe des décompilateurs, mais ils ne produisent pas toujours des résultats exploitables (opens in a new tab). Dans cet article, vous apprendrez comment faire manuellement la rétro-ingénierie et comprendre un contrat à partir des codes d'opération (opens in a new tab), ainsi que comment interpréter les résultats d'un décompilateur.

Pour pouvoir comprendre cet article, vous devez déjà connaître les bases de l'EVM et être au moins un peu familier avec l'assembleur EVM. Vous pouvez en apprendre davantage sur ces sujets ici (opens in a new tab).

Préparer le code exécutable

Vous pouvez obtenir les codes d'opération en allant sur Etherscan pour le contrat, en cliquant sur l'onglet Contract puis sur Switch to Opcodes View. Vous obtenez une vue avec un code d'opération par ligne.

Cependant, pour pouvoir comprendre les sauts, vous devez savoir où se trouve chaque code d'opération dans le code. Pour ce faire, une méthode consiste à ouvrir une feuille de calcul Google (Google Spreadsheet) et à coller les codes d'opération dans la colonne C. Vous pouvez ignorer les étapes suivantes en faisant une copie de cette feuille de calcul déjà préparée (opens in a new tab).

L'étape suivante consiste à obtenir les emplacements corrects du code afin de pouvoir comprendre les sauts. Nous allons placer la taille du code d'opération dans la colonne B, et l'emplacement (en hexadécimal) dans la colonne A. Tapez cette fonction dans la cellule B1 puis copiez-la et collez-la pour le reste de la colonne B, jusqu'à la fin du code. Après avoir fait cela, vous pouvez masquer la colonne B.

=1+IF(REGEXMATCH(C1,"PUSH"),REGEXEXTRACT(C1,"PUSH(\d+)"),0)

Tout d'abord, cette fonction ajoute un octet pour le code d'opération lui-même, puis recherche PUSH. Les codes d'opération PUSH sont spéciaux car ils nécessitent des octets supplémentaires pour la valeur empilée. Si le code d'opération est un PUSH, nous extrayons le nombre d'octets et l'ajoutons.

Dans A1, mettez le premier décalage, zéro. Ensuite, dans A2, mettez cette fonction et copiez-collez-la à nouveau pour le reste de la colonne A :

=dec2hex(hex2dec(A1)+B1)

Nous avons besoin que cette fonction nous donne la valeur hexadécimale car les valeurs qui sont empilées avant les sauts (JUMP et JUMPI) nous sont données en hexadécimal.

Le point d'entrée (0x00)

Les contrats sont toujours exécutés à partir du premier octet. Voici la partie initiale du code :

Ce code fait deux choses :

1. Écrire 0x80 comme une valeur de 32 octets aux emplacements mémoire 0x40-0x5F (0x80 est stocké dans 0x5F, et 0x40-0x5E sont tous des zéros).
2. Lire la taille des données d'appel. Normalement, les données d'appel pour un contrat Ethereum suivent l'ABI (interface binaire-programme) (opens in a new tab), qui nécessite au minimum quatre octets pour le sélecteur de fonction. Si la taille des données d'appel est inférieure à quatre, sauter à 0x5E.

Le gestionnaire à 0x5E (pour les données d'appel non-ABI)

Cet extrait commence par un JUMPDEST. Les programmes de l'EVM (machine virtuelle Ethereum) lèvent une exception si vous sautez vers un code d'opération qui n'est pas JUMPDEST. Ensuite, il examine la CALLDATASIZE, et si elle est « vraie » (c'est-à-dire non nulle), il saute à 0x7C. Nous y reviendrons plus bas.

Donc, lorsqu'il n'y a pas de données d'appel, nous lisons la valeur de Storage[6]. Nous ne savons pas encore ce qu'est cette valeur, mais nous pouvons chercher des transactions que le contrat a reçues sans données d'appel. Les transactions qui transfèrent simplement de l'ETH sans aucune donnée d'appel (et donc sans méthode) ont dans Etherscan la méthode Transfer. En fait, la toute première transaction que le contrat a reçue (opens in a new tab) est un transfert.

Si nous regardons dans cette transaction et cliquons sur Click to see More (Cliquer pour voir plus), nous voyons que les données d'appel, appelées données d'entrée (input data), sont en effet vides (0x). Remarquez également que la valeur est de 1,559 ETH, ce qui sera pertinent plus tard.

Ensuite, cliquez sur l'onglet State (État) et développez le contrat que nous sommes en train de rétro-ingénierer (0x2510...). Vous pouvez voir que Storage[6] a bien changé pendant la transaction, et si vous changez Hex en Number (Nombre), vous voyez qu'il est devenu 1 559 000 000 000 000 000, la valeur transférée en wei (j'ai ajouté les espaces pour plus de clarté), correspondant à la valeur suivante du contrat.

Si nous regardons les changements d'état causés par d'autres transactions Transfer de la même période (opens in a new tab), nous voyons que Storage[6] a suivi la valeur du contrat pendant un certain temps. Pour l'instant, nous l'appellerons Value*. L'astérisque (*) nous rappelle que nous ne savons pas encore ce que fait cette variable, mais elle ne peut pas servir uniquement à suivre la valeur du contrat car il n'est pas nécessaire d'utiliser le stockage, qui est très coûteux, quand vous pouvez obtenir le solde de vos comptes en utilisant ADDRESS BALANCE. Le premier code d'opération pousse la propre adresse du contrat. Le second lit l'adresse au sommet de la pile et la remplace par le solde de cette adresse.

Nous allons continuer à tracer ce code à la destination du saut.

Le NOT est au niveau du bit (bitwise), il inverse donc la valeur de chaque bit dans la valeur d'appel.

Nous sautons si Value* est inférieur ou égal à 2^256-CALLVALUE-1. Cela ressemble à une logique pour empêcher un dépassement de capacité (overflow). Et en effet, nous voyons qu'après quelques opérations dénuées de sens (l'écriture en mémoire est sur le point d'être supprimée, par exemple) au décalage 0x01DE, le contrat s'annule si le dépassement est détecté, ce qui est un comportement normal.

Notez qu'un tel dépassement est extrêmement improbable, car il nécessiterait que la valeur d'appel plus Value* soit comparable à 2^256 wei, soit environ 10^59 ETH. L'offre totale d'ETH, au moment de la rédaction, est inférieure à deux cents millions (opens in a new tab).

Si nous sommes arrivés ici, obtenez Value* + CALLVALUE et sautez au décalage 0x75.

Si nous arrivons ici (ce qui nécessite que les données d'appel soient vides), nous ajoutons à Value* la valeur d'appel. Cela est cohérent avec ce que nous disons que les transactions Transfer font.

Enfin, videz la pile (ce qui n'est pas nécessaire) et signalez la fin réussie de la transaction.

Pour résumer, voici un organigramme pour le code initial.

Le gestionnaire à 0x7C

Je n'ai volontairement pas indiqué dans le titre ce que fait ce gestionnaire. Le but n'est pas de vous apprendre comment fonctionne ce contrat spécifique, mais comment faire de la rétro-ingénierie de contrats. Vous apprendrez ce qu'il fait de la même manière que moi, en suivant le code.

Nous arrivons ici depuis plusieurs endroits :

• S'il y a des données d'appel de 1, 2 ou 3 octets (à partir du décalage 0x63)
• Si la signature de la méthode est inconnue (à partir des décalages 0x42 et 0x5D)

Il s'agit d'une autre cellule de stockage, que je n'ai pu trouver dans aucune transaction, il est donc plus difficile de savoir ce qu'elle signifie. Le code ci-dessous rendra les choses plus claires.

Ces codes d'opération tronquent la valeur que nous lisons dans Storage[3] à 160 bits, la longueur d'une adresse Ethereum.

Ce saut est superflu, puisque nous passons au code d'opération suivant. Ce code est loin d'être aussi efficace en gaz qu'il pourrait l'être.

Tout au début du code, nous avons défini Mem[0x40] à 0x80. Si nous cherchons 0x40 plus tard, nous voyons que nous ne le modifions pas - nous pouvons donc supposer qu'il vaut 0x80.

Copie toutes les données d'appel en mémoire, en commençant à 0x80.

Maintenant, les choses sont beaucoup plus claires. Ce contrat peut agir comme un contrat proxy (opens in a new tab), appelant l'adresse dans Storage[3] pour faire le vrai travail. DELEGATE_CALL appelle un contrat distinct, mais reste dans le même stockage. Cela signifie que le contrat délégué, celui pour lequel nous sommes un proxy, accède au même espace de stockage. Les paramètres de l'appel sont :

• Gaz : Tout le gaz restant
• Adresse appelée : Storage[3]-en-adresse
• Données d'appel : Les octets CALLDATASIZE commençant à 0x80, là où nous avons placé les données d'appel d'origine
• Données de retour : Aucune (0x00 - 0x00) Nous obtiendrons les données de retour par d'autres moyens (voir ci-dessous)

Ici, nous copions toutes les données de retour dans le tampon mémoire commençant à 0x80.

Donc, après l'appel, nous copions les données de retour dans le tampon 0x80 - 0x80+RETURNDATASIZE, et si l'appel réussit, nous exécutons alors RETURN avec exactement ce tampon.

Échec de DELEGATECALL

Si nous arrivons ici, à 0xC0, cela signifie que le contrat que nous avons appelé a été annulé. Comme nous ne sommes qu'un proxy pour ce contrat, nous voulons renvoyer les mêmes données et également annuler.

Nous exécutons donc REVERT avec le même tampon que celui utilisé pour RETURN plus tôt : 0x80 - 0x80+RETURNDATASIZE

Appels ABI

Si la taille des données d'appel est de quatre octets ou plus, il peut s'agir d'un appel ABI valide.

Etherscan nous indique que 1C est un code d'opération inconnu, car il a été ajouté après qu'Etherscan a écrit cette fonctionnalité (opens in a new tab) et ils ne l'ont pas mise à jour. Un tableau des codes d'opération à jour (opens in a new tab) nous montre qu'il s'agit d'un décalage vers la droite

Diviser ainsi en deux les tests de correspondance de la signature de méthode permet d'économiser la moitié des tests en moyenne. Le code qui suit immédiatement ceci et le code en 0x43 suivent le même modèle : DUP1 les 32 premiers bits des données d'appel, PUSH4 (((method signature>, exécutent EQ pour vérifier l'égalité, puis JUMPI si la signature de méthode correspond. Voici les signatures de méthode, leurs adresses et, si elle est connue, la définition de méthode correspondante (opens in a new tab) :

Si aucune correspondance n'est trouvée, le code saute vers le gestionnaire de proxy à 0x7C, dans l'espoir que le contrat pour lequel nous sommes un proxy ait une correspondance.

splitter()

La première chose que fait cette fonction est de vérifier que l'appel n'a pas envoyé d'ETH. Cette fonction n'est pas payable (opens in a new tab). Si quelqu'un nous a envoyé de l'ETH, cela doit être une erreur et nous voulons REVERT pour éviter que cet ETH ne se retrouve là où il ne peut pas être récupéré.

Et 0x80 contient maintenant l'adresse du proxy

Le code E4

C'est la première fois que nous voyons ces lignes, mais elles sont partagées avec d'autres méthodes (voir ci-dessous). Nous appellerons donc la valeur dans la pile X, et rappelez-vous simplement que dans splitter(), la valeur de ce X est 0xA0.

Ce code reçoit donc un pointeur de mémoire dans la pile (X), et amène le contrat à RETURN avec un tampon qui est 0x80 - X.

Dans le cas de splitter(), cela renvoie l'adresse pour laquelle nous sommes un proxy. RETURN renvoie le tampon dans 0x80-0x9F, qui est l'endroit où nous avons écrit ces données (décalage 0x130 ci-dessus).

currentWindow()

Le code aux décalages 0x158-0x163 est identique à ce que nous avons vu en 0x103-0x10E dans splitter() (à l'exception de la destination JUMPI), nous savons donc que currentWindow() n'est pas non plus payable.

Le code DA

Ce code est également partagé avec d'autres méthodes. Nous appellerons donc la valeur dans la pile Y, et rappelez-vous simplement que dans currentWindow(), la valeur de ce Y est Storage[1].

Écrire Y dans 0x80-0x9F.

Et le reste est déjà expliqué ci-dessus. Ainsi, les sauts vers 0xDA écrivent le sommet de la pile (Y) dans 0x80-0x9F, et renvoient cette valeur. Dans le cas de currentWindow(), cela renvoie Storage[1].

merkleRoot()

Le code aux offsets 0xED-0xF8 est identique à ce que nous avons vu en 0x103-0x10E dans splitter() (à l'exception de la destination JUMPI), nous savons donc que merkleRoot() n'est pas non plus payable.

Ce qui se passe après le saut, nous l'avons déjà compris. Donc merkleRoot() renvoie Storage[0].

0x81e580d3

Le code aux décalages 0x138-0x143 est identique à ce que nous avons vu en 0x103-0x10E dans splitter() (à l'exception de la destination JUMPI), nous savons donc que cette fonction n'est pas non plus payable.

Il semble que cette fonction prenne au moins 32 octets (un mot) de données d'appel.

Si elle ne reçoit pas les données d'appel, la transaction est annulée sans aucune donnée de retour.

Voyons ce qui se passe si la fonction reçoit effectivement les données d'appel dont elle a besoin.

calldataload(4) est le premier mot des données d'appel après la signature de la méthode

Si le premier mot n'est pas inférieur à Storage[4], la fonction échoue. Elle est annulée sans aucune valeur de retour :

Si le calldataload(4) est inférieur à Storage[4], nous obtenons ce code :

Et les emplacements mémoire 0x00-0x1F contiennent maintenant la donnée 0x04 (0x00-0x1E sont tous des zéros, 0x1F vaut quatre)

Il y a donc une table de correspondance dans le stockage, qui commence au SHA3 de 0x000...0004 et possède une entrée pour chaque valeur légitime de données d'appel (valeur inférieure à Storage[4]).

Nous savons déjà ce que fait le code au décalage 0xDA, il renvoie la valeur au sommet de la pile à l'appelant. Cette fonction renvoie donc la valeur de la table de correspondance à l'appelant.

0x1f135823

Le code aux décalages 0xC4-0xCF est identique à ce que nous avons vu en 0x103-0x10E dans splitter() (à l'exception de la destination JUMPI), nous savons donc que cette fonction n'est pas non plus payable.

Nous savons déjà ce que fait le code au décalage 0xDA, il renvoie la valeur au sommet de la pile à l'appelant. Cette fonction renvoie donc Value*.

Résumé des méthodes

Avez-vous l'impression de comprendre le contrat à ce stade ? Pas moi. Jusqu'à présent, nous avons ces méthodes :

Mais nous savons que toute autre fonctionnalité est fournie par le contrat dans Storage[3]. Peut-être que si nous savions ce qu'est ce contrat, cela nous donnerait un indice. Heureusement, c'est la chaîne de blocs et tout est connu, du moins en théorie. Nous n'avons vu aucune méthode qui définit Storage[3], il a donc dû être défini par le constructeur.

Le constructeur

Lorsque nous regardons un contrat (opens in a new tab), nous pouvons également voir la transaction qui l'a créé.

Si nous cliquons sur cette transaction, puis sur l'onglet État, nous pouvons voir les valeurs initiales des paramètres. Plus précisément, nous pouvons voir que Storage[3] contient 0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761 (opens in a new tab). Ce contrat doit contenir la fonctionnalité manquante. Nous pouvons le comprendre en utilisant les mêmes outils que ceux utilisés pour le contrat que nous examinons.

Le contrat proxy

En utilisant les mêmes techniques que celles utilisées pour le contrat original ci-dessus, nous pouvons voir que le contrat s'annule si :

• Il y a de l'ETH attaché à l'appel (0x05-0x0F)
• La taille des données d'appel est inférieure à quatre (0x10-0x19 et 0xBE-0xC2)

Et que les méthodes qu'il prend en charge sont :

Nous pouvons ignorer les quatre méthodes du bas car nous ne les atteindrons jamais. Leurs signatures sont telles que notre contrat original s'en charge lui-même (vous pouvez cliquer sur les signatures pour voir les détails ci-dessus), ce doivent donc être des méthodes qui sont remplacées (opens in a new tab).

L'une des méthodes restantes est claim(<params>), et une autre est isClaimed(<params>), il semble donc s'agir d'un contrat d'airdrop. Au lieu de parcourir le reste code d'opération par code d'opération, nous pouvons essayer le décompilateur (opens in a new tab), qui produit des résultats utilisables pour trois fonctions de ce contrat. La rétro-ingénierie des autres est laissée comme exercice au lecteur.

scaleAmountByPercentage

Voici ce que le décompilateur nous donne pour cette fonction :

def unknown8ffb5c97(uint256 _param1, uint256 _param2) payable:
  require calldata.size - 4 >=′ 64
  if _param1 and _param2 > -1 / _param1:
      revert with 0, 17
  return (_param1 * _param2 / 100 * 10^6)

Le premier require teste que les données d'appel ont, en plus des quatre octets de la signature de la fonction, au moins 64 octets, ce qui est suffisant pour les deux paramètres. Si ce n'est pas le cas, il y a manifestement un problème.

L'instruction if semble vérifier que _param1 n'est pas zéro, et que _param1 * _param2 n'est pas négatif. C'est probablement pour éviter les cas de dépassement de capacité.

Enfin, la fonction renvoie une valeur mise à l'échelle.

claim

Le code créé par le décompilateur est complexe, et tout n'est pas pertinent pour nous. Je vais en ignorer une partie pour me concentrer sur les lignes qui, selon moi, fournissent des informations utiles.

def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable:
  ...
  require _param2 == addr(_param2)
  ...
  if currentWindow <= _param1:
      revert with 0, 'cannot claim for a future window'

Nous voyons ici deux choses importantes :

• _param2, bien qu'il soit déclaré comme un uint256, est en fait une adresse
• _param1 est la fenêtre réclamée, qui doit être currentWindow ou antérieure.

  ...
  if stor5[_claimWindow][addr(_claimFor)]:
      revert with 0, 'Account already claimed the given window'

Nous savons donc maintenant que Storage[5] est un tableau de fenêtres et d'adresses, et indique si l'adresse a réclamé la récompense pour cette fenêtre.

  ...
  idx = 0
  s = 0
  while idx < _param4.length:
  ...
      if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]:
          mem[mem[64] + 32] = mem[(32 * idx) + 296]
          ...
          s = sha3(mem[_62 + 32 len mem[_62]])
          continue
      ...
      s = sha3(mem[_66 + 32 len mem[_66]])
      continue
  if unknown2eb4a7ab != s:
      revert with 0, 'Invalid proof'

Nous savons que unknown2eb4a7ab est en fait la fonction merkleRoot(), donc ce code semble vérifier une preuve de Merkle (opens in a new tab). Cela signifie que _param4 est une preuve de Merkle.

  call addr(_param2) with:
     value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
       gas 30000 wei

C'est ainsi qu'un contrat transfère son propre ETH à une autre adresse (contrat ou détenue en externe). Il l'appelle avec une valeur qui est le montant à transférer. Il semble donc qu'il s'agisse d'un airdrop d'ETH.

  if not return_data.size:
      if not ext_call.success:
          require ext_code.size(stor2)
          call stor2.deposit() with:
             value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei

Les deux dernières lignes nous indiquent que Storage[2] est également un contrat que nous appelons. Si nous regardons la transaction du constructeur (opens in a new tab), nous voyons que ce contrat est 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 (opens in a new tab), un contrat d'ether enveloppé (WETH) dont le code source a été téléchargé sur Etherscan (opens in a new tab).

Il semble donc que le contrat tente d'envoyer de l'ETH à _param2. S'il y parvient, tant mieux. Sinon, il tente d'envoyer du WETH (opens in a new tab). Si _param2 est un compte détenu en externe (EOA), il peut toujours recevoir de l'ETH, mais les contrats peuvent refuser de recevoir de l'ETH. Cependant, le WETH est un ERC-20 et les contrats ne peuvent pas refuser de l'accepter.

  ...
  log 0xdbd5389f: addr(_param2), unknown81e580d3[_param1] * _param3 / 100 * 10^6, bool(ext_call.success)

À la fin de la fonction, nous voyons qu'une entrée de journal est générée. Regardez les entrées de journal générées (opens in a new tab) et filtrez sur le sujet qui commence par 0xdbd5.... Si nous cliquons sur l'une des transactions qui a généré une telle entrée (opens in a new tab), nous voyons qu'il s'agit bien d'une réclamation : le compte a envoyé un message au contrat que nous rétro-ingénierons, et a reçu de l'ETH en retour.

1e7df9d3

Cette fonction est très similaire à claim ci-dessus. Elle vérifie également une preuve de Merkle, tente de transférer de l'ETH au premier, et produit le même type d'entrée de journal.

def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
  ...
  idx = 0
  s = 0
  while idx < _param3.length:
      if idx >= mem[96]:
          revert with 0, 50
      _55 = mem[(32 * idx) + 128]
      if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]:
          ...
          s = sha3(mem[_58 + 32 len mem[_58]])
          continue
      mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]])
  ...
  if unknown2eb4a7ab != s:
      revert with 0, 'Invalid proof'
  ...
  call addr(_param1) with:
     value s wei
       gas 30000 wei
  if not return_data.size:
      if not ext_call.success:
          require ext_code.size(stor2)
          call stor2.deposit() with:
             value s wei
               gas gas_remaining wei
  ...
  log 0xdbd5389f: addr(_param1), s, bool(ext_call.success)

La principale différence est que le premier paramètre, la fenêtre à retirer, n'est pas là. Au lieu de cela, il y a une boucle sur toutes les fenêtres qui pourraient être réclamées.

  idx = 0
  s = 0
  while idx < currentWindow:
      ...
      if stor5[mem[0]]:
          if idx == -1:
              revert with 0, 17
          idx = idx + 1
          s = s
          continue
      ...
      stor5[idx][addr(_param1)] = 1
      if idx >= unknown81e580d3.length:
          revert with 0, 50
      mem[0] = 4
      if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]:
          revert with 0, 17
      if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6):
          revert with 0, 17
      if idx == -1:
          revert with 0, 17
      idx = idx + 1
      s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6)
      continue

Il semble donc s'agir d'une variante de claim qui réclame toutes les fenêtres.

Conclusion

À présent, vous devriez savoir comment comprendre les contrats dont le code source n'est pas disponible, en utilisant soit les codes d'opération, soit (quand cela fonctionne) le décompilateur. Comme le montre la longueur de cet article, la rétro-ingénierie d'un contrat n'est pas triviale, mais dans un système où la sécurité est essentielle, c'est une compétence importante de pouvoir vérifier que les contrats fonctionnent comme promis.

Découvrez d'autres de mes travaux ici (opens in a new tab).