Ingeniería inversa de un contrato

Introducción

No hay secretos en la cadena de bloques, todo lo que sucede es consistente, verificable y está disponible públicamente. Idealmente, los contratos deberían tener su código fuente publicado y verificado en Etherscan (opens in a new tab). Sin embargo, ese no es siempre el caso (opens in a new tab). En este artículo aprenderás cómo aplicar ingeniería inversa a los contratos analizando un contrato sin código fuente, 0x2510c039cc3b061d79e564b38836da87e31b342f (opens in a new tab).

Existen descompiladores inversos, pero no siempre producen resultados utilizables (opens in a new tab). En este artículo aprenderás cómo aplicar ingeniería inversa manualmente y entender un contrato a partir de los códigos de operación (opens in a new tab), así como a interpretar los resultados de un descompilador.

Para poder entender este artículo, ya deberías conocer los conceptos básicos de la EVM y estar al menos algo familiarizado con el ensamblador de la EVM. Puedes leer sobre estos temas aquí (opens in a new tab).

Preparar el código ejecutable

Puede obtener los códigos de operación yendo a Etherscan para el contrato, haciendo clic en la pestaña Contract y luego en Switch to Opcodes View. Obtendrá una vista que muestra un código de operación por línea.

Sin embargo, para poder entender los saltos, necesita saber en qué parte del código se encuentra cada código de operación. Para hacerlo, una forma es abrir una hoja de cálculo de Google y pegar los códigos de operación en la columna C. Puede omitir los siguientes pasos haciendo una copia de esta hoja de cálculo ya preparada (opens in a new tab).

El siguiente paso es obtener las ubicaciones correctas del código para que podamos entender los saltos. Pondremos el tamaño del código de operación en la columna B y la ubicación (en hexadecimal) en la columna A. Escriba esta función en la celda B1 y luego cópiela y péguela en el resto de la columna B, hasta el final del código. Después de hacer esto, puede ocultar la columna B.

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

Primero, esta función añade un byte para el propio código de operación y luego busca PUSH. Los códigos de operación PUSH son especiales porque necesitan tener bytes adicionales para el valor que se está insertando. Si el código de operación es un PUSH, extraemos el número de bytes y lo sumamos.

En A1 ponga el primer desplazamiento, cero. Luego, en A2, ponga esta función y vuelva a copiarla y pegarla para el resto de la columna A:

=dec2hex(hex2dec(A1)+B1)

Necesitamos que esta función nos dé el valor hexadecimal porque los valores que se insertan antes de los saltos (JUMP y JUMPI) se nos dan en hexadecimal.

El punto de entrada (0x00)

Los contratos siempre se ejecutan desde el primer byte. Esta es la parte inicial del código:

Este código hace dos cosas:

1. Escribe 0x80 como un valor de 32 bytes en las ubicaciones de memoria 0x40-0x5F (0x80 se almacena en 0x5F, y de 0x40 a 0x5E son todo ceros).
2. Lee el tamaño de los datos de llamada. Normalmente, los datos de llamada para un contrato de Ethereum siguen la ABI (interfaz binaria de aplicación) (opens in a new tab), que como mínimo requiere cuatro bytes para el selector de función. Si el tamaño de los datos de llamada es menor a cuatro, salta a 0x5E.

El manejador en 0x5E (para datos de llamada que no son de la ABI)

Este fragmento comienza con un JUMPDEST. Los programas de la EVM (máquina virtual de Ethereum) lanzan una excepción si se salta a un código de operación que no sea JUMPDEST. Luego, observa el CALLDATASIZE, y si es "verdadero" (es decir, no es cero) salta a 0x7C. Llegaremos a eso más adelante.

Por lo tanto, cuando no hay datos de llamada, leemos el valor de Storage[6]. Aún no sabemos cuál es este valor, pero podemos buscar transacciones que el contrato haya recibido sin datos de llamada. Las transacciones que simplemente transfieren ETH sin ningún dato de llamada (y, por lo tanto, sin método) tienen en Etherscan el método Transfer. De hecho, la primera transacción que recibió el contrato (opens in a new tab) es una transferencia.

Si observamos esa transacción y hacemos clic en Click to see More (Hacer clic para ver más), vemos que los datos de llamada, denominados datos de entrada (input data), están efectivamente vacíos (0x). Observe también que el valor es 1.559 ETH, lo cual será relevante más adelante.

A continuación, haga clic en la pestaña State (Estado) y expanda el contrato al que le estamos aplicando ingeniería inversa (0x2510...). Puede ver que Storage[6] sí cambió durante la transacción, y si cambia Hex a Number (Número), verá que se convirtió en 1,559,000,000,000,000,000, el valor transferido en wei (agregué las comas para mayor claridad), correspondiente al siguiente valor del contrato.

Si observamos los cambios de estado causados por otras transacciones Transfer del mismo período (opens in a new tab), vemos que Storage[6] rastreó el valor del contrato durante un tiempo. Por ahora lo llamaremos Value*. El asterisco (*) nos recuerda que aún no sabemos qué hace esta variable, pero no puede ser solo para rastrear el valor del contrato porque no hay necesidad de usar el almacenamiento, que es muy costoso, cuando puede obtener el saldo de sus cuentas usando ADDRESS BALANCE. El primer código de operación introduce en la pila la propia dirección del contrato. El segundo lee la dirección en la parte superior de la pila y la reemplaza con el saldo de esa dirección.

Continuaremos rastreando este código en el destino del salto.

El NOT es a nivel de bits, por lo que invierte el valor de cada bit en el valor de la llamada.

Saltamos si Value* es menor que 2^256-CALLVALUE-1 o igual a este. Esto parece lógica para prevenir el desbordamiento. Y, de hecho, vemos que después de algunas operaciones sin sentido (escribir en la memoria está a punto de eliminarse, por ejemplo) en el offset 0x01DE, el contrato se revierte si se detecta el desbordamiento, lo cual es un comportamiento normal.

Tenga en cuenta que tal desbordamiento es extremadamente improbable, porque requeriría que el valor de la llamada más Value* fuera comparable a 2^256 wei, aproximadamente 10^59 ETH. El suministro total de ETH, al momento de escribir este artículo, es de menos de doscientos millones (opens in a new tab).

Si llegamos aquí, obtenemos Value* + CALLVALUE y saltamos al offset 0x75.

Si llegamos aquí (lo que requiere que los datos de llamada estén vacíos) sumamos a Value* el valor de la llamada. Esto es consistente con lo que decimos que hacen las transacciones Transfer.

Finalmente, limpiamos la pila (lo cual no es necesario) y señalamos el final exitoso de la transacción.

Para resumir todo, aquí hay un diagrama de flujo para el código inicial.

El manejador en 0x7C

A propósito, no puse en el encabezado lo que hace este manejador. El objetivo no es enseñarte cómo funciona este contrato específico, sino cómo aplicar ingeniería inversa a los contratos. Aprenderás lo que hace de la misma manera que yo, siguiendo el código.

Llegamos aquí desde varios lugares:

• Si hay datos de llamada de 1, 2 o 3 bytes (desde el desplazamiento 0x63)
• Si la firma del método es desconocida (desde los desplazamientos 0x42 y 0x5D)

Esta es otra celda de almacenamiento, una que no pude encontrar en ninguna transacción, por lo que es más difícil saber qué significa. El código a continuación lo aclarará.

Estos códigos de operación truncan el valor que leemos de Storage[3] a 160 bits, la longitud de una dirección de Ethereum.

Este salto es superfluo, ya que vamos al siguiente código de operación. Este código no es tan eficiente en gas como podría ser.

Al principio del código establecemos Mem[0x40] en 0x80. Si buscamos 0x40 más adelante, vemos que no lo cambiamos, por lo que podemos asumir que es 0x80.

Copia todos los datos de llamada a la memoria, comenzando en 0x80.

Ahora las cosas están mucho más claras. Este contrato puede actuar como un proxy (opens in a new tab), llamando a la dirección en Storage[3] para hacer el trabajo real. DELEGATE_CALL llama a un contrato separado, pero permanece en el mismo almacenamiento. Esto significa que el contrato delegado, para el cual somos un proxy, accede al mismo espacio de almacenamiento. Los parámetros para la llamada son:

• Gas: Todo el gas restante
• Dirección llamada: Storage[3]-como-dirección
• Datos de llamada: Los bytes de CALLDATASIZE que comienzan en 0x80, que es donde pusimos los datos de llamada originales
• Datos de retorno: Ninguno (0x00 - 0x00) Obtendremos los datos de retorno por otros medios (ver a continuación)

Aquí copiamos todos los datos de retorno al búfer de memoria que comienza en 0x80.

Así que después de la llamada copiamos los datos de retorno al búfer 0x80 - 0x80+RETURNDATASIZE, y si la llamada es exitosa, entonces hacemos RETURN exactamente con ese búfer.

DELEGATECALL falló

Si llegamos aquí, a 0xC0, significa que el contrato al que llamamos se revirtió. Como solo somos un proxy para ese contrato, queremos devolver los mismos datos y también revertir.

Así que hacemos REVERT con el mismo búfer que usamos para RETURN anteriormente: 0x80 - 0x80+RETURNDATASIZE

Llamadas a la ABI

Si el tamaño de los datos de llamada es de cuatro bytes o más, esto podría ser una llamada a la ABI válida.

Etherscan nos dice que 1C es un código de operación desconocido, porque se añadió después de que Etherscan escribiera esta función (opens in a new tab) y no la han actualizado. Una tabla de códigos de operación actualizada (opens in a new tab) nos muestra que esto es un desplazamiento a la derecha (shift right)

Al dividir las pruebas de coincidencia de firmas de métodos en dos de esta manera, se ahorra la mitad de las pruebas en promedio. El código que sigue inmediatamente a esto y el código en 0x43 siguen el mismo patrón: DUP1 los primeros 32 bits de los datos de llamada, PUSH4 (((method signature>, ejecuta EQ para comprobar la igualdad, y luego JUMPI si la firma del método coincide. Aquí están las firmas de los métodos, sus direcciones y, si se conoce, la definición del método correspondiente (opens in a new tab):

Si no se encuentra ninguna coincidencia, el código salta a el manejador del proxy en 0x7C, con la esperanza de que el contrato del cual somos un proxy tenga una coincidencia.

splitter()

Lo primero que hace esta función es comprobar que la llamada no haya enviado ningún ETH. Esta función no es payable (opens in a new tab). Si alguien nos envió ETH, debe ser un error y queremos REVERT para evitar tener ese ETH donde no puedan recuperarlo.

Y 0x80 ahora contiene la dirección del proxy

El código E4

Esta es la primera vez que vemos estas líneas, pero se comparten con otros métodos (ver más abajo). Así que llamaremos X al valor en la pila, y solo recuerda que en splitter() el valor de esta X es 0xA0.

Por lo tanto, este código recibe un puntero de memoria en la pila (X) y hace que el contrato ejecute RETURN con un búfer que es 0x80 - X.

En el caso de splitter(), esto devuelve la dirección para la cual somos un proxy. RETURN devuelve el búfer en 0x80-0x9F, que es donde escribimos estos datos (desplazamiento 0x130 arriba).

currentWindow()

El código en los offsets 0x158-0x163 es idéntico a lo que vimos en 0x103-0x10E en splitter() (aparte del destino JUMPI), por lo que sabemos que currentWindow() tampoco es payable.

El código DA

Este código también se comparte con otros métodos. Así que llamaremos Y al valor en la pila, y solo recordaremos que en currentWindow() el valor de esta Y es Storage[1].

Escribe Y en 0x80-0x9F.

Y el resto ya se explicó anteriormente. Por lo tanto, los saltos a 0xDA escriben la parte superior de la pila (Y) en 0x80-0x9F y devuelven ese valor. En el caso de currentWindow(), devuelve Storage[1].

merkleRoot()

El código en los offsets 0xED-0xF8 es idéntico a lo que vimos en 0x103-0x10E en splitter() (aparte del destino de JUMPI), por lo que sabemos que merkleRoot() tampoco es payable.

Lo que sucede después del salto ya lo hemos averiguado. Así que merkleRoot() devuelve Storage[0].

0x81e580d3

El código en los desplazamientos 0x138-0x143 es idéntico a lo que vimos en 0x103-0x10E en splitter() (aparte del destino JUMPI), por lo que sabemos que esta función tampoco es payable.

Parece que esta función toma al menos 32 bytes (una palabra) de datos de llamada.

Si no obtiene los datos de llamada, la transacción se revierte sin ningún dato de retorno.

Veamos qué sucede si la función sí obtiene los datos de llamada que necesita.

calldataload(4) es la primera palabra de los datos de llamada después de la firma del método

Si la primera palabra no es menor que Storage[4], la función falla. Se revierte sin ningún valor devuelto:

Si calldataload(4) es menor que Storage[4], obtenemos este código:

Y las ubicaciones de memoria 0x00-0x1F ahora contienen los datos 0x04 (0x00-0x1E son todos ceros, 0x1F es cuatro)

Por lo tanto, hay una tabla de búsqueda en el almacenamiento, que comienza en el SHA3 de 0x000...0004 y tiene una entrada para cada valor legítimo de datos de llamada (valor por debajo de Storage[4]).

Ya sabemos lo que hace el código en el desplazamiento 0xDA, devuelve el valor superior de la pila al llamador. Así que esta función devuelve el valor de la tabla de búsqueda al llamador.

0x1f135823

El código en los desplazamientos 0xC4-0xCF es idéntico a lo que vimos en 0x103-0x10E en splitter() (aparte del destino JUMPI), por lo que sabemos que esta función tampoco es payable.

Ya sabemos lo que hace el código en el desplazamiento 0xDA, devuelve el valor superior de la pila al llamador. Así que esta función devuelve Value*.

Resumen de métodos

¿Sientes que entiendes el contrato en este punto? Yo no. Hasta ahora tenemos estos métodos:

Pero sabemos que cualquier otra funcionalidad es proporcionada por el contrato en Storage[3]. Tal vez si supiéramos qué es ese contrato nos daría una pista. Afortunadamente, esto es la cadena de bloques y todo se sabe, al menos en teoría. No vimos ningún método que establezca Storage[3], por lo que debe haber sido establecido por el constructor.

El constructor

Cuando observamos un contrato (opens in a new tab) también podemos ver la transacción que lo creó.

Si hacemos clic en esa transacción, y luego en la pestaña Estado, podemos ver los valores iniciales de los parámetros. Específicamente, podemos ver que Storage[3] contiene 0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761 (opens in a new tab). Ese contrato debe contener la funcionalidad que falta. Podemos entenderlo usando las mismas herramientas que usamos para el contrato que estamos investigando.

El contrato proxy

Usando las mismas técnicas que utilizamos para el contrato original anterior, podemos ver que el contrato se revierte si:

• Hay algún ETH adjunto a la llamada (0x05-0x0F)
• El tamaño de los datos de llamada es menor a cuatro (0x10-0x19 y 0xBE-0xC2)

Y que los métodos que admite son:

Podemos ignorar los cuatro métodos inferiores porque nunca llegaremos a ellos. Sus firmas son tales que nuestro contrato original se encarga de ellos por sí mismo (puede hacer clic en las firmas para ver los detalles anteriores), por lo que deben ser métodos que se anulan (opens in a new tab).

Uno de los métodos restantes es claim(<params>) y otro es isClaimed(<params>), por lo que parece un contrato de airdrop. En lugar de revisar el resto código de operación por código de operación, podemos probar el descompilador (opens in a new tab), que produce resultados utilizables para tres funciones de este contrato. La ingeniería inversa de las demás se deja como ejercicio para el lector.

scaleAmountByPercentage

Esto es lo que nos da el descompilador para esta función:

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)

El primer require comprueba que los datos de llamada tienen, además de los cuatro bytes de la firma de la función, al menos 64 bytes, suficientes para los dos parámetros. Si no es así, obviamente hay algo mal.

La declaración if parece comprobar que _param1 no es cero y que _param1 * _param2 no es negativo. Probablemente sea para evitar casos de desbordamiento.

Finalmente, la función devuelve un valor escalado.

claim

El código que crea el descompilador es complejo y no todo es relevante para nosotros. Voy a omitir parte de él para centrarme en las líneas que creo que proporcionan información útil.

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'

Aquí vemos dos cosas importantes:

• _param2, aunque se declara como un uint256, en realidad es una dirección
• _param1 es la ventana que se está reclamando, que tiene que ser currentWindow o anterior.

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

Así que ahora sabemos que Storage[5] es una matriz de ventanas y direcciones, y si la dirección reclamó la recompensa para esa ventana.

  ...
  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'

Sabemos que unknown2eb4a7ab es en realidad la función merkleRoot(), por lo que este código parece estar verificando una prueba de Merkle (opens in a new tab). Esto significa que _param4 es una prueba de Merkle.

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

Así es como un contrato transfiere su propio ETH a otra dirección (contrato o de propiedad externa). La llama con un valor que es la cantidad a transferir. Por lo tanto, parece que se trata de un airdrop de 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

Las dos últimas líneas nos dicen que Storage[2] también es un contrato al que llamamos. Si miramos la transacción del constructor (opens in a new tab) vemos que este contrato es 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 (opens in a new tab), un contrato de ether envuelto (WETH) cuyo código fuente se ha subido a Etherscan (opens in a new tab).

Por lo tanto, parece que el contrato intenta enviar ETH a _param2. Si puede hacerlo, genial. Si no, intenta enviar WETH (opens in a new tab). Si _param2 es una cuenta de propiedad externa (EOA) entonces siempre puede recibir ETH, pero los contratos pueden negarse a recibir ETH. Sin embargo, WETH es ERC-20 y los contratos no pueden negarse a aceptarlo.

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

Al final de la función vemos que se genera una entrada de registro. Mire las entradas de registro generadas (opens in a new tab) y filtre por el tema que comienza con 0xdbd5.... Si hacemos clic en una de las transacciones que generó dicha entrada (opens in a new tab) vemos que, de hecho, parece un reclamo: la cuenta envió un mensaje al contrato al que le estamos haciendo ingeniería inversa y, a cambio, obtuvo ETH.

1e7df9d3

Esta función es muy similar a claim anterior. También comprueba una prueba de Merkle, intenta transferir ETH a la primera y produce el mismo tipo de entrada de registro.

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 principal diferencia es que el primer parámetro, la ventana a retirar, no está ahí. En su lugar, hay un bucle sobre todas las ventanas que podrían ser reclamadas.

  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

Así que parece una variante de claim que reclama todas las ventanas.

Conclusión

A estas alturas ya deberías saber cómo entender contratos cuyo código fuente no está disponible, usando ya sea los códigos de operación o (cuando funciona) el descompilador. Como es evidente por la longitud de este artículo, aplicar ingeniería inversa a un contrato no es trivial, pero en un sistema donde la seguridad es esencial, es una habilidad importante poder verificar que los contratos funcionen como se promete.

Consulta aquí más de mi trabajo (opens in a new tab).