Ingegneria inversa di un contratto

Introduzione

Non ci sono segreti sulla blockchain, tutto ciò che accade è coerente, verificabile e disponibile pubblicamente. Idealmente, i contratti dovrebbero avere il loro codice sorgente pubblicato e verificato su Etherscan (opens in a new tab). Tuttavia, non è sempre così (opens in a new tab). In questo articolo imparerai come fare ingegneria inversa sui contratti esaminando un contratto senza codice sorgente, 0x2510c039cc3b061d79e564b38836da87e31b342f (opens in a new tab).

Esistono decompilatori, ma non sempre producono risultati utilizzabili (opens in a new tab). In questo articolo imparerai come fare ingegneria inversa manualmente e comprendere un contratto a partire dai codici operativi (opcode) (opens in a new tab), oltre a come interpretare i risultati di un decompilatore.

Per poter comprendere questo articolo dovresti già conoscere le basi della EVM ed avere almeno una certa familiarità con l'assembler della EVM. Puoi leggere di questi argomenti qui (opens in a new tab).

Preparare il codice eseguibile

Puoi ottenere i codici operativi (opcode) andando su Etherscan per il contratto, cliccando sulla scheda Contract e poi su Switch to Opcodes View. Otterrai una visualizzazione con un opcode per riga.

Per poter comprendere i salti, tuttavia, devi sapere dove si trova ciascun opcode nel codice. Per farlo, un modo è aprire un foglio di calcolo Google e incollare gli opcode nella colonna C. Puoi saltare i passaggi seguenti creando una copia di questo foglio di calcolo già preparato (opens in a new tab).

Il passaggio successivo consiste nell'ottenere le posizioni corrette del codice, in modo da poter comprendere i salti. Inseriremo la dimensione dell'opcode nella colonna B e la posizione (in esadecimale) nella colonna A. Digita questa funzione nella cella B1 e poi copiala e incollala per il resto della colonna B, fino alla fine del codice. Dopo averlo fatto, puoi nascondere la colonna B.

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

Innanzitutto, questa funzione aggiunge un byte per l'opcode stesso, e poi cerca PUSH. Gli opcode di push sono speciali perché necessitano di byte aggiuntivi per il valore inserito. Se l'opcode è un PUSH, estraiamo il numero di byte e lo aggiungiamo.

In A1 inserisci il primo offset, zero. Quindi, in A2, inserisci questa funzione e copiala e incollala di nuovo per il resto della colonna A:

=dec2hex(hex2dec(A1)+B1)

Abbiamo bisogno che questa funzione ci dia il valore esadecimale perché i valori che vengono inseriti prima dei salti (JUMP e JUMPI) ci vengono forniti in esadecimale.

Il Punto di Ingresso (0x00)

I contratti sono sempre eseguiti dal primo byte. Questa è la parte iniziale del codice:

Questo codice fa due cose:

1. Scrive 0x80 come valore a 32 byte nelle posizioni di memoria 0x40-0x5F (0x80 è memorizzato in 0x5F e 0x40-0x5E sono tutti zeri).
2. Legge la dimensione dei dati di chiamata. Normalmente i dati di chiamata per un contratto Ethereum seguono l'ABI (application binary interface) (opens in a new tab), che richiede come minimo quattro byte per il selettore di funzione. Se la dimensione dei dati di chiamata è inferiore a quattro, salta a 0x5E.

Il Gestore a 0x5E (per dati di chiamata non ABI)

Questo frammento inizia con un JUMPDEST. I programmi della EVM (Ethereum Virtual Machine) generano un'eccezione se si salta a un opcode che non è JUMPDEST. Poi controlla la CALLDATASIZE e, se è "vera" (cioè non zero), salta a 0x7C. Ci arriveremo più avanti.

Quindi, quando non ci sono dati di chiamata, leggiamo il valore di Storage[6]. Non sappiamo ancora quale sia questo valore, ma possiamo cercare le transazioni che il contratto ha ricevuto senza dati di chiamata. Le transazioni che trasferiscono semplicemente ETH senza alcun dato di chiamata (e quindi senza alcun metodo) hanno in Etherscan il metodo Transfer. Infatti, la primissima transazione ricevuta dal contratto (opens in a new tab) è un trasferimento.

Se guardiamo in quella transazione e clicchiamo su Click to see More (Clicca per vedere di più), vediamo che i dati di chiamata, chiamati dati di input, sono effettivamente vuoti (0x). Notiamo anche che il valore è 1,559 ETH, il che sarà rilevante in seguito.

Successivamente, clicca sulla scheda State (Stato) ed espandi il contratto di cui stiamo facendo il reverse engineering (0x2510...). Puoi vedere che Storage[6] è effettivamente cambiato durante la transazione e, se cambi Hex in Number (Numero), vedi che è diventato 1.559.000.000.000.000.000, il valore trasferito in wei (ho aggiunto i punti per chiarezza), corrispondente al successivo valore del contratto.

Se guardiamo i cambiamenti di stato causati da altre transazioni Transfer dello stesso periodo (opens in a new tab), vediamo che Storage[6] ha tracciato il valore del contratto per un po'. Per ora lo chiameremo Value*. L'asterisco (*) ci ricorda che non sappiamo ancora cosa faccia questa variabile, ma non può servire solo a tracciare il valore del contratto perché non c'è bisogno di usare lo storage, che è molto costoso, quando puoi ottenere il saldo del tuo account usando ADDRESS BALANCE. Il primo opcode inserisce l'indirizzo stesso del contratto. Il secondo legge l'indirizzo in cima allo stack e lo sostituisce con il saldo di quell'indirizzo.

Continueremo a tracciare questo codice alla destinazione del salto.

Il NOT è bit a bit, quindi inverte il valore di ogni bit nel valore della chiamata.

Saltiamo se Value* è minore di 2^256-CALLVALUE-1 o uguale ad esso. Questa sembra una logica per prevenire l'overflow. E in effetti, vediamo che dopo alcune operazioni senza senso (la scrittura in memoria sta per essere eliminata, ad esempio) all'offset 0x01DE il contratto esegue un revert se viene rilevato l'overflow, il che è un comportamento normale.

Nota che un tale overflow è estremamente improbabile, perché richiederebbe che il valore della chiamata più Value* sia paragonabile a 2^256 wei, circa 10^59 ETH. L'offerta totale di ETH, al momento della stesura, è inferiore a duecento milioni (opens in a new tab).

Se siamo arrivati fin qui, otteniamo Value* + CALLVALUE e saltiamo all'offset 0x75.

Se arriviamo qui (il che richiede che i dati di chiamata siano vuoti) aggiungiamo a Value* il valore della chiamata. Questo è coerente con ciò che diciamo facciano le transazioni Transfer.

Infine, svuota lo stack (il che non è necessario) e segnala la fine con successo della transazione.

Per riassumere il tutto, ecco un diagramma di flusso per il codice iniziale.

L'handler a 0x7C

Di proposito non ho inserito nell'intestazione cosa fa questo handler. Il punto non è insegnarti come funziona questo specifico contratto, ma come fare ingegneria inversa sui contratti. Imparerai cosa fa nello stesso modo in cui l'ho fatto io, seguendo il codice.

Arriviamo qui da diversi punti:

• Se ci sono dati di chiamata di 1, 2 o 3 byte (dall'offset 0x63)
• Se la firma del metodo è sconosciuta (dagli offset 0x42 e 0x5D)

Questa è un'altra cella di archiviazione, una che non sono riuscito a trovare in nessuna transazione, quindi è più difficile sapere cosa significhi. Il codice sottostante lo renderà più chiaro.

Questi codici operativi (opcode) troncano il valore che leggiamo da Storage[3] a 160 bit, la lunghezza di un indirizzo Ethereum.

Questo salto è superfluo, poiché stiamo andando all'opcode successivo. Questo codice non è minimamente efficiente in termini di gas quanto potrebbe esserlo.

All'inizio del codice impostiamo Mem[0x40] a 0x80. Se cerchiamo 0x40 in seguito, vediamo che non lo modifichiamo, quindi possiamo presumere che sia 0x80.

Copia tutti i dati di chiamata in memoria, a partire da 0x80.

Ora le cose sono molto più chiare. Questo contratto può fungere da proxy (opens in a new tab), chiamando l'indirizzo in Storage[3] per svolgere il vero lavoro. DELEGATE_CALL chiama un contratto separato, ma rimane nello stesso storage. Ciò significa che il contratto delegato, quello per cui siamo un proxy, accede allo stesso spazio di archiviazione. I parametri per la chiamata sono:

• Gas: Tutto il gas rimanente
• Indirizzo chiamato: Storage[3]-come-indirizzo
• Dati di chiamata: I byte CALLDATASIZE a partire da 0x80, che è dove abbiamo inserito i dati di chiamata originali
• Dati di ritorno: Nessuno (0x00 - 0x00) Otterremo i dati di ritorno con altri mezzi (vedi sotto)

Qui copiamo tutti i dati di ritorno nel buffer di memoria a partire da 0x80.

Quindi, dopo la chiamata, copiamo i dati di ritorno nel buffer 0x80 - 0x80+RETURNDATASIZE e, se la chiamata ha esito positivo, eseguiamo un RETURN esattamente con quel buffer.

DELEGATECALL fallita

Se arriviamo qui, a 0xC0, significa che il contratto che abbiamo chiamato ha eseguito un revert. Poiché siamo solo un proxy per quel contratto, vogliamo restituire gli stessi dati ed eseguire a nostra volta un revert.

Quindi eseguiamo un REVERT con lo stesso buffer che abbiamo usato per RETURN in precedenza: 0x80 - 0x80+RETURNDATASIZE

Chiamate ABI

Se la dimensione dei dati di chiamata è di quattro byte o più, questa potrebbe essere una chiamata ABI valida.

Etherscan ci dice che 1C è un codice operativo (opcode) sconosciuto, perché è stato aggiunto dopo che Etherscan ha scritto questa funzionalità (opens in a new tab) e non l'hanno aggiornata. Una tabella degli opcode aggiornata (opens in a new tab) ci mostra che si tratta di uno scorrimento a destra (shift right)

Dividere in due i test di corrispondenza della firma del metodo in questo modo fa risparmiare in media la metà dei test. Il codice che segue immediatamente questo e il codice in 0x43 seguono lo stesso schema: DUP1 i primi 32 bit dei dati di chiamata, PUSH4 (((method signature>, esegue EQ per verificare l'uguaglianza, e poi JUMPI se la firma del metodo corrisponde. Ecco le firme dei metodi, i loro indirizzi e, se nota, la definizione del metodo corrispondente (opens in a new tab):

Se non viene trovata alcuna corrispondenza, il codice salta al gestore del proxy a 0x7C, nella speranza che il contratto di cui siamo un proxy abbia una corrispondenza.

splitter()

La prima cosa che fa questa funzione è controllare che la chiamata non abbia inviato alcun ETH. Questa funzione non è payable (opens in a new tab). Se qualcuno ci ha inviato degli ETH deve trattarsi di un errore e vogliamo eseguire un REVERT per evitare di avere quegli ETH dove non possono essere recuperati.

E 0x80 ora contiene l'indirizzo del proxy

Il codice E4

Questa è la prima volta che vediamo queste righe, ma sono condivise con altri metodi (vedi sotto). Quindi chiameremo X il valore nello stack, e ricorderemo semplicemente che in splitter() il valore di questa X è 0xA0.

Quindi questo codice riceve un puntatore di memoria nello stack (X) e fa in modo che il contratto esegua un RETURN con un buffer che è 0x80 - X.

Nel caso di splitter(), questo restituisce l'indirizzo per cui siamo un proxy. RETURN restituisce il buffer in 0x80-0x9F, che è dove abbiamo scritto questi dati (offset 0x130 sopra).

currentWindow()

Il codice negli offset 0x158-0x163 è identico a quello che abbiamo visto in 0x103-0x10E in splitter() (a parte la destinazione JUMPI), quindi sappiamo che anche currentWindow() non è payable.

Il codice DA

Questo codice è condiviso anche con altri metodi. Quindi chiameremo il valore nello stack Y, e ricorderemo semplicemente che in currentWindow() il valore di questa Y è Storage[1].

Scrive Y in 0x80-0x9F.

E il resto è già stato spiegato sopra. Quindi i salti a 0xDA scrivono la cima dello stack (Y) in 0x80-0x9F e restituiscono quel valore. Nel caso di currentWindow(), restituisce Storage[1].

merkleRoot()

Il codice negli offset 0xED-0xF8 è identico a quello che abbiamo visto in 0x103-0x10E in splitter() (a parte la destinazione JUMPI), quindi sappiamo che anche merkleRoot() non è payable.

Cosa succede dopo il salto lo abbiamo già capito. Quindi merkleRoot() restituisce Storage[0].

0x81e580d3

Il codice negli offset 0x138-0x143 è identico a quello che abbiamo visto in 0x103-0x10E in splitter() (a parte la destinazione JUMPI), quindi sappiamo che anche questa funzione non è payable.

Sembra che questa funzione accetti almeno 32 byte (una word) di dati di chiamata.

Se non riceve i dati di chiamata, la transazione va in revert senza alcun dato di ritorno.

Vediamo cosa succede se la funzione riceve effettivamente i dati di chiamata di cui ha bisogno.

calldataload(4) è la prima word dei dati di chiamata dopo la firma del metodo

Se la prima word non è minore di Storage[4], la funzione fallisce. Va in revert senza alcun valore restituito:

Se calldataload(4) è minore di Storage[4], otteniamo questo codice:

E le locazioni di memoria 0x00-0x1F ora contengono il dato 0x04 (0x00-0x1E sono tutti zeri, 0x1F è quattro)

Quindi c'è una tabella di ricerca nello storage, che inizia allo SHA3 di 0x000...0004 e ha una voce per ogni valore legittimo dei dati di chiamata (valore inferiore a Storage[4]).

Sappiamo già cosa fa il codice all'offset 0xDA: restituisce il valore in cima allo stack al chiamante. Quindi questa funzione restituisce al chiamante il valore dalla tabella di ricerca.

0x1f135823

Il codice negli offset 0xC4-0xCF è identico a quello che abbiamo visto in 0x103-0x10E in splitter() (a parte la destinazione JUMPI), quindi sappiamo che anche questa funzione non è payable.

Sappiamo già cosa fa il codice all'offset 0xDA, restituisce il valore in cima allo stack al chiamante. Quindi questa funzione restituisce Value*.

Riepilogo dei metodi

Senti di aver compreso il contratto a questo punto? Io no. Finora abbiamo questi metodi:

Ma sappiamo che qualsiasi altra funzionalità è fornita dal contratto in Storage[3]. Forse se sapessimo cos'è quel contratto ci darebbe un indizio. Per fortuna, questa è la blockchain e tutto è noto, almeno in teoria. Non abbiamo visto alcun metodo che imposti Storage[3], quindi deve essere stato impostato dal costruttore.

Il costruttore

Quando osserviamo un contratto (opens in a new tab) possiamo anche vedere la transazione che lo ha creato.

Se clicchiamo su quella transazione, e poi sulla scheda Stato, possiamo vedere i valori iniziali dei parametri. Nello specifico, possiamo vedere che Storage[3] contiene 0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761 (opens in a new tab). Quel contratto deve contenere la funzionalità mancante. Possiamo comprenderlo usando gli stessi strumenti che abbiamo usato per il contratto che stiamo analizzando.

Il contratto proxy

Usando le stesse tecniche che abbiamo usato per il contratto originale qui sopra, possiamo vedere che il contratto va in revert se:

• C'è qualche ETH allegato alla chiamata (0x05-0x0F)
• La dimensione dei dati di chiamata è inferiore a quattro (0x10-0x19 e 0xBE-0xC2)

E che i metodi che supporta sono:

Possiamo ignorare gli ultimi quattro metodi perché non ci arriveremo mai. Le loro firme sono tali che il nostro contratto originale se ne occupa da solo (puoi cliccare sulle firme per vedere i dettagli sopra), quindi devono essere metodi che vengono sovrascritti (opens in a new tab).

Uno dei metodi rimanenti è claim(<params>) e un altro è isClaimed(<params>), quindi sembra un contratto di airdrop. Invece di esaminare il resto codice operativo (opcode) per codice operativo (opcode), possiamo provare il decompilatore (opens in a new tab), che produce risultati utilizzabili per tre funzioni di questo contratto. Il reverse engineering delle altre è lasciato come esercizio per il lettore.

scaleAmountByPercentage

Questo è ciò che il decompilatore ci fornisce per questa funzione:

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)

Il primo require verifica che i dati di chiamata abbiano, oltre ai quattro byte della firma della funzione, almeno 64 byte, sufficienti per i due parametri. In caso contrario, c'è ovviamente qualcosa che non va.

L'istruzione if sembra controllare che _param1 non sia zero e che _param1 * _param2 non sia negativo. Probabilmente serve a prevenire casi di wrap around.

Infine, la funzione restituisce un valore scalato.

claim

Il codice creato dal decompilatore è complesso e non tutto è rilevante per noi. Ne salterò una parte per concentrarmi sulle righe che ritengo forniscano informazioni utili

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'

Qui vediamo due cose importanti:

• _param2, sebbene sia dichiarato come uint256, è in realtà un indirizzo
• _param1 è la finestra di cui si richiede il riscatto, che deve essere currentWindow o precedente.

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

Quindi ora sappiamo che Storage[5] è un array di finestre e indirizzi, e se l'indirizzo ha effettuato il riscatto della ricompensa per quella finestra.

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

Sappiamo che unknown2eb4a7ab è in realtà la funzione merkleRoot(), quindi questo codice sembra verificare una prova di Merkle (opens in a new tab). Ciò significa che _param4 è una prova di Merkle.

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

Questo è il modo in cui un contratto trasferisce i propri ETH a un altro indirizzo (contratto o di proprietà esterna). Lo chiama con un valore che è l'importo da trasferire. Quindi sembra che si tratti di un airdrop di 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

Le ultime due righe ci dicono che anche Storage[2] è un contratto che chiamiamo. Se guardiamo la transazione del costruttore (opens in a new tab) vediamo che questo contratto è 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 (opens in a new tab), un contratto di ether incapsulato (weth) il cui codice sorgente è stato caricato su Etherscan (opens in a new tab).

Quindi sembra che il contratto tenti di inviare ETH a _param2. Se ci riesce, ottimo. In caso contrario, tenta di inviare WETH (opens in a new tab). Se _param2 è un account di proprietà esterna (EOA), allora può sempre ricevere ETH, ma i contratti possono rifiutarsi di ricevere ETH. Tuttavia, WETH è un ERC-20 e i contratti non possono rifiutarsi di accettarlo.

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

Alla fine della funzione vediamo che viene generata una voce di log. Guarda le voci di log generate (opens in a new tab) e filtra per l'argomento che inizia con 0xdbd5.... Se clicchiamo su una delle transazioni che ha generato tale voce (opens in a new tab) vediamo che in effetti sembra un riscatto: l'account ha inviato un messaggio al contratto di cui stiamo facendo il reverse engineering e in cambio ha ottenuto ETH.

1e7df9d3

Questa funzione è molto simile a claim qui sopra. Anch'essa verifica una prova di Merkle, tenta di trasferire ETH al primo e produce lo stesso tipo di voce di log.

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 differenza principale è che il primo parametro, la finestra da prelevare, non c'è. Invece, c'è un ciclo su tutte le finestre di cui si potrebbe effettuare il riscatto.

  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

Quindi sembra una variante di claim che effettua il riscatto di tutte le finestre.

Conclusione

A questo punto dovreste sapere come comprendere i contratti il cui codice sorgente non è disponibile, utilizzando i codici operativi (opcode) o (quando funziona) il decompilatore. Come è evidente dalla lunghezza di questo articolo, il reverse engineering di un contratto non è banale, ma in un sistema in cui la sicurezza è essenziale è una competenza importante essere in grado di verificare che i contratti funzionino come promesso.

Vedi qui per altri miei lavori (opens in a new tab).