Vai al contenuto principale

Aiuta ad aggiornare questa pagina

🌏

C'è una nuova versione di questa pagina, ma al momento è solo in inglese. Aiutaci a tradurre l'ultima versione.

Traduci la pagina
Visualizza in inglese

Nessun bug qui!🐛

Questa pagina non è stata tradotta. Per il momento, è stata intenzionalmente lasciata in inglese.

Decompilare un contratto

evmopcodedecompilazionedecompilatore
Advanced
✍️Ori Pomerantz
📆30 dicembre 2021
⏱️31 minuti letti

Introduzione

Non ci sono segreti sulla blockchain: tutto ciò che si verifica è coerente, verificabile e disponibile pubblicamente. Idealmente, il codice sorgente dei contratti dovrebbe essere pubblicato e verificato su Etherscan. Però non sempre è così. In questo articolo imparerai come decompilare i contratti guardando un contratto privo del codice sorgente, 0x2510c039cc3b061d79e564b38836da87e31b342f.

Esistono dei decompilatori, ma non producono sempre risultati utilizzabili. In questo articolo imparerai come decompilare manualmente e comprendere un contratto dagli opcode, nonché come interpretare i risultati di un decompilatore.

Per poter comprendere questo articolo dovresti già conoscere le basi dell'EVM ed avere una certa familiarità con l'assembler dell'EVM. Puoi leggere informazioni su questi argomenti qui.

Preparare il codice eseguibile

Puoi ottenere gli opcode andando su Etherscan per il contratto, facendo clic sulla scheda Contract e poi Switch to Opcodes View. Ottieni una vista composta da un opcode per riga.

Vista dell'opcode da Etherscan

Per poter comprendere i salti, però, devi sapere dove si trova ogni opcode nel codice. Per farlo, un modo è aprire un Foglio di calcolo di Google e incollare gli opcode nella colonna C. Puoi saltare i passaggi successivi creando una copia di questo foglio di calcolo già pronto.

Il prossimo passaggio è ottenere le posizioni corrette del codice, così 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=1+IF(REGEXMATCH(C1,"PUSH"),REGEXEXTRACT(C1,"PUSH(\d+)"),0)
2

Questa funzione aggiunge prima un byte per l'opcode stesso e poi cerca PUSH. Gli opcode push sono speciali perché hanno bisogno di byte aggiuntivi affinché venga eseguito il push del valore. Se l'opcode è un PUSH, estraiamo il numero di byte e lo aggiungiamo.

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

1=dec2hex(hex2dec(A1)+B1)
2

Ci serve che questa funzione ci restituisca il valore esadecimale perché i valori su cui è stato eseguito il push prima dei salti (JUMP e JUMPI) ci vengono dati in esadecimali.

Il Punto d'accesso (0x00)

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

OffsetOpcodeStack (dopo l'opcode)
0PUSH1 0x800x80
2PUSH1 0x400x40, 0x80
4MSTOREVuoto
5PUSH1 0x040x04
7CALLDATASIZECALLDATASIZE 0x04
8LTCALLDATASIZE<4
9PUSH2 0x005e0x5E CALLDATASIZE<4
CJUMPIVuoto

Questo codice fa due cose:

  1. Scrive 0x80 come un 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 calldata. Normalmente i dati della chiamata per un contratto di Ethereum seguono l'ABI (Application Binary Interface, interfaccia binaria dell'applicazione), che richiede come minimo quattro byte per il selettore della funzione. Se la dimensione dei dati della chiamata è inferiore a quattro, salta a 0x5E.

Diagramma di flusso per questa parte

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

OffsetOpcode
5EJUMPDEST
5FCALLDATASIZE
60PUSH2 0x007c
63JUMPI

Questo frammento inizia con un JUMPDEST. I programmi dell'EVM (macchina virtuale di Ethereum) lanciano un'eccezione se salti a un opcode che non è JUMPDEST. Poi guarda la CALLDATASIZE e se è "true" (ovvero, non è zero) salta a 0x7C. Lo vedremo di seguito.

OffsetOpcodeStack (dopo l'opcode)
64CALLVALUEWei fornito dalla chiamata. Chiamato msg.value in Solidity
65PUSH1 0x066 CALLVALUE
67PUSH1 0x000 6 CALLVALUE
69DUP3CALLVALUE 0 6 CALLVALUE
6ADUP36 CALLVALUE 0 6 CALLVALUE
6BSLOADStorage[6] CALLVALUE 0 6 CALLVALUE

Quindi quando non ci sono dati della chiamata leggiamo il valore di Storage[6]. Non sappiamo ancora cosa sia questo valore, ma possiamo cercare delle transazioni ricevute dal contratto prive di dati della chiamata. Le transazioni che trasferiscono semplicemente ETH senza alcun dato della chiamata (e dunque senza metodo) contengono in Etherscan il metodo Transfer. Difatti, la prima vera transazione ricevuta dal contratto è un trasferimento.

Se guardiamo in quella transazione e facciamo clic su Click to see More, vediamo che i dati della chiamata, detti dati di input, sono vuoti (0x). Nota anche che il valore è 1,559 ETH, che sarà rilevante in seguito.

I dati della chiamata sono vuoti

A questo punto, fai clic sulla scheda State ed espandi il contratto che stiamo decompilando (0x2510...). Puoi vedere che Storage[6] è cambiato durante la transazione e, passando da Hex a Number, vedrai che è diventato 1.559.000.000.000.000.000, il valore trasferito in wei (ho aggiunto i punti per chiarezza), corrispondente al valore del contratto successivo.

Il cambiamento in Storage[6]

Se guardiamo i cambiamenti di stato causati da altre transazioni Transfer dallo stesso periodo, vediamo che Storage[6] ha monitorato il valore del contratto per un po'. Per ora lo chiameremo Value*. L'asterisco (*) ci ricorda che ancora non sappiamo cosa faccia questa variabile, ma non può servire solo a tracciare il valore del contratto, poiché non è necessario utilizzare l'archiviazione, essendo molto costosa, quando si può ottenere il saldo dei conti utilizzando ADDRESS BALANCE. Il primo opcode effettua il push dell'indirizzo del contratto. Il secondo legge l'indirizzo in cima allo stack e lo sostituisce con il saldo di quell'indirizzo.

OffsetOpcodeStack
6CPUSH2 0x00750x75 Value* CALLVALUE 0 6 CALLVALUE
6FSWAP2CALLVALUE Value* 0x75 0 6 CALLVALUE
70SWAP1Value* CALLVALUE 0x75 0 6 CALLVALUE
71PUSH2 0x01a70x01A7 Value* CALLVALUE 0x75 0 6 CALLVALUE
74JUMP

Continueremo a monitorare questo codice alla destinazione del salto.

OffsetOpcodeStack
1A7JUMPDESTValue* CALLVALUE 0x75 0 6 CALLVALUE
1A8PUSH1 0x000x00 Value* CALLVALUE 0x75 0 6 CALLVALUE
1AADUP3CALLVALUE 0x00 Value* CALLVALUE 0x75 0 6 CALLVALUE
1ABNOT2^256-CALLVALUE-1 0x00 Value* CALLVALUE 0x75 0 6 CALLVALUE

Il NOT opera su singoli bit, quindi annulla il valore di ogni bit nel valore della chiamata.

OffsetOpcodeStack
1ACDUP3Value* 2^256-CALLVALUE-1 0x00 Value* CALLVALUE 0x75 0 6 CALLVALUE
1ADGTValue*>2^256-CALLVALUE-1 0x00 Value* CALLVALUE 0x75 0 6 CALLVALUE
1AEISZEROValue*<=2^256-CALLVALUE-1 0x00 Value* CALLVALUE 0x75 0 6 CALLVALUE
1AFPUSH2 0x01df0x01DF Value*<=2^256-CALLVALUE-1 0x00 Value* CALLVALUE 0x75 0 6 CALLVALUE
1B2JUMPI

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

Nota che l'overflow è estremamente improbabile, perché richiederebbe che il valore della chiamata più Value* fosse comparabile a 2^256 wei, circa 10^59 ETH. La quantità totale di ETH, al momento della scrittura, è inferiore a duecento milioni.

OffsetOpcodeStack
1DFJUMPDEST0x00 Value* CALLVALUE 0x75 0 6 CALLVALUE
1E0POPValue* CALLVALUE 0x75 0 6 CALLVALUE
1E1ADDValue*+CALLVALUE 0x75 0 6 CALLVALUE
1E2SWAP10x75 Value*+CALLVALUE 0 6 CALLVALUE
1E3JUMP

Se siamo arrivati qui, ottieni Value* + CALLVALUE e salta all'offset 0x75.

OffsetOpcodeStack
75JUMPDESTValue*+CALLVALUE 0 6 CALLVALUE
76SWAP10 Value*+CALLVALUE 6 CALLVALUE
77SWAP26 Value*+CALLVALUE 0 CALLVALUE
78SSTORE0 CALLVALUE

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

OffsetOpcode
79POP
7APOP
7BSTOP

Infine, cancelliamo lo stack (che non è necessario) e segnaliamo che la transazione è andata a buon fine.

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

Diagramma di flusso dei punti d'accesso

Il Gestore a 0x7C

Volutamente ho omesso di inserire nell'intestazione cosa fa questo gestore. Il punto non è insegnarti come funziona questo contratto specifico, ma come decompilare i contratti. Imparerai cosa faccia come ho fatto io, seguendo il codice.

Arriviamo qui da diversi punti:

  • Se ci sono dati della chiamata di 1, 2 o 3 byte (dall'offset 0x63)
  • Se la firma del metodo non è nota (dagli offset 0x42 e 0x5D)
OffsetOpcodeStack
7CJUMPDEST
7DPUSH1 0x000x00
7FPUSH2 0x009d0x9D 0x00
82PUSH1 0x030x03 0x9D 0x00
84SLOADStorage[3] 0x9D 0x00

Questa è un'altra cella di memoria; non riuscivo a trovarla in nessuna transazione quindi è più difficile sapere cosa significhi. Il codice seguente lo chiarirà.

OffsetOpcodeStack
85PUSH20 0xffffffffffffffffffffffffffffffffffffffff0xff....ff Storage[3] 0x9D 0x00
9AANDStorage[3]-as-address 0x9D 0x00

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

OffsetOpcodeStack
9BSWAP10x9D Storage[3]-as-address 0x00
9CJUMPStorage[3]-as-address 0x00

Questo salto è superfluo, poiché stiamo andando all'opcode successivo. Questo codice non è tanto efficiente a livello di gas, rispetto a quanto potrebbe.

OffsetOpcodeStack
9DJUMPDESTStorage[3]-as-address 0x00
9ESWAP10x00 Storage[3]-as-address
9FPOPStorage[3]-as-address
A0PUSH1 0x400x40 Storage[3]-as-address
A2MLOADMem[0x40] Storage[3]-as-address

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

OffsetOpcodeStack
A3CALLDATASIZECALLDATASIZE 0x80 Storage[3]-as-address
A4PUSH1 0x000x00 CALLDATASIZE 0x80 Storage[3]-as-address
A6DUP30x80 0x00 CALLDATASIZE 0x80 Storage[3]-as-address
A7CALLDATACOPY0x80 Storage[3]-as-address

Copia tutti i dati della chiamata nella memoria, a partire da 0x80.

OffsetOpcodeStack
A8PUSH1 0x000x00 0x80 Storage[3]-as-address
AADUP10x00 0x00 0x80 Storage[3]-as-address
ABCALLDATASIZECALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address
ACDUP40x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address
ADDUP6Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address
AEGASGAS Storage[3]-as-address 0x80 CALLDATASIZE 0x00 0x00 0x80 Storage[3]-as-address
AFDELEGATE_CALL

Ora le cose sono molto più chiare. Questo contratto può fungere da proxy, chiamando l'indirizzo in Storage[3] per compiere il vero lavoro. DELEGATE_CALL chiama un contratto separato, ma resta nella stessa memoria. Questo significa che il contratto delegato, quello per cui siamo un proxy, accede allo stesso spazio d'archiviazione. I parametri per la chiamata sono:

  • Gas: Tutto il gas rimanente
  • Indirizzo chiamato: Storage[3]-as-address
  • dati della chiamata: i byte CALLDATASIZE che iniziano a 0x80, ovvero dove inseriamo i dati di chiamata originali
  • Dati restituiti: nessuno (0x00 - 0x00) Otterremo i dati restituiti con altri mezzi (vedi di seguito)
OffsetOpcodeStack
B0RETURNDATASIZERETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
B1DUP1RETURNDATASIZE RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
B2PUSH1 0x000x00 RETURNDATASIZE RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
B4DUP50x80 0x00 RETURNDATASIZE RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
B5RETURNDATACOPYRETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address

Qui copiamo tutti i dati restituiti al buffer di memoria partendo a 0x80.

OffsetOpcodeStack
B6DUP2(((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
B7DUP1(((call success/failure))) (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
B8ISZERO(((did the call fail))) (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
B9PUSH2 0x00c00xC0 (((did the call fail))) (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
BCJUMPI(((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
BDDUP2RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
BEDUP50x80 RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
BFRETURN

Quindi, dopo la chiamata, copiamo i dati restituiti al buffer 0x80 - 0x80+RETURNDATASIZE, e se la chiamata è andata a buon fine RETURN esattamente con quel buffer.

DELEGATECALL fallita

Se arriviamo qui, a 0xC0, significa che il contratto che abbiamo chiamato è annullato. Poiché siamo solo un proxy per quel contratto, vogliamo restituire gli stessi dati e annullare a nostra volta.

OffsetOpcodeStack
C0JUMPDEST(((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
C1DUP2RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
C2DUP50x80 RETURNDATASIZE (((call success/failure))) RETURNDATASIZE (((call success/failure))) 0x80 Storage[3]-as-address
C3REVERT

Quindi noi REVERT con lo stesso buffer usato prima per RETURN: 0x80 - 0x80+RETURNDATASIZE

Chiamata al diagramma di flusso del proxy

Chiamate ABI

Se la dimensione dei dati della chiamata è di quattro byte o superiore, potrebbe essere una chiamata ABI valida.

OffsetOpcodeStack
DPUSH1 0x000x00
FCALLDATALOAD(((Prima parola (256 bit) dei dati della chiamata)))
10PUSH1 0xe00xE0 (((Prima parola (256 bit) dei dati della chiamata)))
12SHR(((primi 32 bit (4 byte) dei dati della chiamata)))

Etherscan ci dice che 1C è un opcode sconosciuto, perché è stato aggiunto dopo che Etherscan aveva scritto questa funzionalità e non l'ha aggiornata. Una tabella degli opcode aggiornata ci indica che questo è lo spostamento a destra

OffsetOpcodeStack
13DUP1(((primi 32 bit (4 byte) dei dati della chiamata))) (((primi 32 bit (4 byte) dei dati della chiamata)))
14PUSH4 0x3cd8045e0x3CD8045E (((primi 32 bit (4 byte) dei dati della chiamata))) (((primi 32 bit (4 byte) dei dati della chiamata)))
19GT0x3CD8045E>first-32-bits-of-the-call-data (((primi 32 bit (4 byte) dei dati della chiamata)))
1APUSH2 0x00430x43 0x3CD8045E>first-32-bits-of-the-call-data (((primi 32 bit (4 byte) dei dati della chiamata)))
1DJUMPI(((primi 32 bit (4 byte) dei dati della chiamata)))

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

MetodoFirma del metodoOffset a cui saltare
splitter()0x3cd8045e0x0103
???0x81e580d30x0138
currentWindow()0xba0bafb40x0158
???0x1f1358230x00C4
merkleRoot()0x2eb4a7ab0x00ED

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

Diagramma di flusso delle chiamate ABI

splitter()

OffsetOpcodeStack
103JUMPDEST
104CALLVALUECALLVALUE
105DUP1CALLVALUE CALLVALUE
106ISZEROCALLVALUE==0 CALLVALUE
107PUSH2 0x010f0x010F CALLVALUE==0 CALLVALUE
10AJUMPICALLVALUE
10BPUSH1 0x000x00 CALLVALUE
10DDUP10x00 0x00 CALLVALUE
10EREVERT

La prima cosa che fa questa funzione è controllare che la chiamata non abbia inviato alcun ETH. Questa funzione non è pagabile. Se qualcuno ci ha inviato degli ETH, si tratterebbe di un errore e vogliamo REVERT per evitare di avere quegli ETH dove non possiamo restituirli.

OffsetOpcodeStack
10FJUMPDEST
110POP
111PUSH1 0x030x03
113SLOAD(((Storage[3] ovvero il contratto per cui siamo un proxy)))
114PUSH1 0x400x40 (((Storage[3] ovvero il contratto per cui siamo un proxy)))
116MLOAD0x80 (((Storage[3] ovvero il contratto per cui siamo un proxy)))
117PUSH20 0xffffffffffffffffffffffffffffffffffffffff0xFF...FF 0x80 (((Storage[3] ovvero il contratto per cui siamo un proxy)))
12CSWAP10x80 0xFF...FF (((Storage[3] ovvero il contratto per cui siamo un proxy)))
12DSWAP2(((Storage[3] ovvero il contratto per cui siamo un proxy))) 0xFF...FF 0x80
12EANDProxyAddr 0x80
12FDUP20x80 ProxyAddr 0x80
130MSTORE0x80

E ora 0x80 contiene l'indirizzo del proxy

OffsetOpcodeStack
131PUSH1 0x200x20 0x80
133ADD0xA0
134PUSH2 0x00e40xE4 0xA0
137JUMP0xA0

Il Codice E4

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

OffsetOpcodeStack
E4JUMPDESTX
E5PUSH1 0x400x40 X
E7MLOAD0x80 X
E8DUP10x80 0x80 X
E9SWAP2X 0x80 0x80
EASUBX-0x80 0x80
EBSWAP10x80 X-0x80
ECRETURN

Quindi questo codice riceve un puntatore di memoria nello stack (X) e fa sì che il contratto dia RETURN con un buffer che sia 0x80 - X.

Nel caso di splitter(), ciò restituisce l'indirizzo per cui siamo un proxy. RETURN restituisce il buffer in 0x80-0x9F, ovvero 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() (diverso dalla destinazione JUMPI), quindi sappiamo che neanche currentWindow() è pagabile.

OffsetOpcodeStack
164JUMPDEST
165POP
166PUSH2 0x00da0xDA
169PUSH1 0x010x01 0xDA
16BSLOADStorage[1] 0xDA
16CDUP20xDA Storage[1] 0xDA
16DJUMPStorage[1] 0xDA

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

OffsetOpcodeStack
DAJUMPDESTY 0xDA
DBPUSH1 0x400x40 Y 0xDA
DDMLOAD0x80 Y 0xDA
DESWAP1Y 0x80 0xDA
DFDUP20x80 Y 0x80 0xDA
E0MSTORE0x80 0xDA

Scrivi Y a 0x80-0x9F.

OffsetOpcodeStack
E1PUSH1 0x200x20 0x80 0xDA
E3ADD0xA0 0xDA

E il resto è già spiegato sopra. Quindi salta a 0xDA, scrive la cima dello stack (Y) a 0x80-0x9F e restituisce 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() (diverso dalla destinazione JUMPI), quindi sappiamo che neanche merkleRoot() è pagabile.

OffsetOpcodeStack
F9JUMPDEST
FAPOP
FBPUSH2 0x00da0xDA
FEPUSH1 0x000x00 0xDA
100SLOADStorage[0] 0xDA
101DUP20xDA Storage[0] 0xDA
102JUMPStorage[0] 0xDA

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() (diverso dalla destinazione JUMPI), quindi sappiamo che neanche questa funzione è pagabile.

OffsetOpcodeStack
144JUMPDEST
145POP
146PUSH2 0x00da0xDA
149PUSH2 0x01530x0153 0xDA
14CCALLDATASIZECALLDATASIZE 0x0153 0xDA
14DPUSH1 0x040x04 CALLDATASIZE 0x0153 0xDA
14FPUSH2 0x018f0x018F 0x04 CALLDATASIZE 0x0153 0xDA
152JUMP0x04 CALLDATASIZE 0x0153 0xDA
18FJUMPDEST0x04 CALLDATASIZE 0x0153 0xDA
190PUSH1 0x000x00 0x04 CALLDATASIZE 0x0153 0xDA
192PUSH1 0x200x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA
194DUP30x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA
195DUP5CALLDATASIZE 0x04 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA
196SUBCALLDATASIZE-4 0x20 0x00 0x04 CALLDATASIZE 0x0153 0xDA
197SLTCALLDATASIZE-4<32 0x00 0x04 CALLDATASIZE 0x0153 0xDA
198ISZEROCALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA
199PUSH2 0x01a00x01A0 CALLDATASIZE-4>=32 0x00 0x04 CALLDATASIZE 0x0153 0xDA
19CJUMPI0x00 0x04 CALLDATASIZE 0x0153 0xDA

Sembra che questa funzione richieda almeno 32 byte (una parola) di dati della chiamata.

OffsetOpcodeStack
19DDUP10x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA
19EDUP20x00 0x00 0x00 0x04 CALLDATASIZE 0x0153 0xDA
19FREVERT

Se non ottiene i dati della chiamata, la transazione è annullata senza alcun dato restituito.

Vediamo cosa succede se la funzione ottiene i dati della chiamata che necessita.

OffsetOpcodeStack
1A0JUMPDEST0x00 0x04 CALLDATASIZE 0x0153 0xDA
1A1POP0x04 CALLDATASIZE 0x0153 0xDA
1A2CALLDATALOADcalldataload(4) CALLDATASIZE 0x0153 0xDA

calldataload(4) è la prima parola della dei dati della chiamata dopo la firma del metodo

OffsetOpcodeStack
1A3SWAP20x0153 CALLDATASIZE calldataload(4) 0xDA
1A4SWAP1CALLDATASIZE 0x0153 calldataload(4) 0xDA
1A5POP0x0153 calldataload(4) 0xDA
1A6JUMPcalldataload(4) 0xDA
153JUMPDESTcalldataload(4) 0xDA
154PUSH2 0x016e0x016E calldataload(4) 0xDA
157JUMPcalldataload(4) 0xDA
16EJUMPDESTcalldataload(4) 0xDA
16FPUSH1 0x040x04 calldataload(4) 0xDA
171DUP2calldataload(4) 0x04 calldataload(4) 0xDA
172DUP20x04 calldataload(4) 0x04 calldataload(4) 0xDA
173SLOADStorage[4] calldataload(4) 0x04 calldataload(4) 0xDA
174DUP2calldataload(4) Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA
175LTcalldataload(4)<Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA
176PUSH2 0x017e0x017EC calldataload(4)<Storage[4] calldataload(4) 0x04 calldataload(4) 0xDA
179JUMPIcalldataload(4) 0x04 calldataload(4) 0xDA

Se la prima parola non è inferiore a Storage[4], la funzione fallisce. Si annulla senza alcun valore restituito:

OffsetOpcodeStack
17APUSH1 0x000x00 ...
17CDUP10x00 0x00 ...
17DREVERT

Se calldataload(4) è inferiore a Storage[4], otteniamo questo codice:

OffsetOpcodeStack
17EJUMPDESTcalldataload(4) 0x04 calldataload(4) 0xDA
17FPUSH1 0x000x00 calldataload(4) 0x04 calldataload(4) 0xDA
181SWAP20x04 calldataload(4) 0x00 calldataload(4) 0xDA
182DUP30x00 0x04 calldataload(4) 0x00 calldataload(4) 0xDA
183MSTOREcalldataload(4) 0x00 calldataload(4) 0xDA

E le posizioni di memoria 0x00-0x1F ora contengono i dati 0x04 (0x00-0x1E sono tutti zeri, ox1F è quattro)

OffsetOpcodeStack
184PUSH1 0x200x20 calldataload(4) 0x00 calldataload(4) 0xDA
186SWAP1calldataload(4) 0x20 0x00 calldataload(4) 0xDA
187SWAP20x00 0x20 calldataload(4) calldataload(4) 0xDA
188SHA3(((SHA3 of 0x00-0x1F))) calldataload(4) calldataload(4) 0xDA
189ADD(((SHA3 of 0x00-0x1F)))+calldataload(4) calldataload(4) 0xDA
18ASLOADStorage[(((SHA3 of 0x00-0x1F))) + calldataload(4)] calldataload(4) 0xDA

Quindi c'è una tabella di ricerca in memoria che inizia allo SHA3 di 0x000...0004 e ha una voce per ogni valore dei dati della chiamata legittimo (valore sotto Storage[4]).

OffsetOpcodeStack
18BSWAP1calldataload(4) Storage[(((SHA3 of 0x00-0x1F))) + calldataload(4)] 0xDA
18CPOPStorage[(((SHA3 of 0x00-0x1F))) + calldataload(4)] 0xDA
18DDUP20xDA Storage[(((SHA3 of 0x00-0x1F))) + calldataload(4)] 0xDA
18EJUMPStorage[(((SHA3 of 0x00-0x1F))) + calldataload(4)] 0xDA

Sappiamo già cosa faccia il codice all'offset 0xDA, restituisce il valore massimo dello stack al chiamante. Quindi questa funzione restituisce il valore dalla tabella di ricerca al chiamante.

0x1f135823

Il codice negli offset 0xC4-0xCF è identico a quello che abbiamo visto in 0x103-0x10E in splitter() (diverso dalla destinazione JUMPI), quindi sappiamo che neanche questa funzione è pagabile.

OffsetOpcodeStack
D0JUMPDEST
D1POP
D2PUSH2 0x00da0xDA
D5PUSH1 0x060x06 0xDA
D7SLOADValue* 0xDA
D8DUP20xDA Value* 0xDA
D9JUMPValue* 0xDA

Sappiamo già cosa faccia il codice all'offset 0xDA, restituisce il valore massimo dello stack al chiamante. Quindi questa funzione restituisce Value*.

Riepilogo del metodo

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

MetodoSignificato
TrasferimentoAccetta il valore fornito dalla chiamata e aumenta Value* di quell'importo
splitter()Restituisci Storage[3], l'indirizzo del proxy
currentWindow()Restituisci Storage[1]
merkleRoot()Restituisci Storage[0]
0x81e580d3Restituisce il valore da una tabella di ricerca, a condizione che il parametro sia inferiore a Storage[4]
0x1f135823Restituisce Storage[6], ovvero Value*

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

Il costruttore

Quando guardiamo un contratto possiamo anche vedere la transazione che lo ha creato.

Fai clic per creare la transazione

Facendo clic su quella transazione e poi sulla scheda State, possiamo visualizzare i valori iniziali dei parametri. Nello specifico, possiamo vedere che Storage[3] contiene 0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761. Quel contratto deve contenere la funzionalità mancante. Possiamo comprenderlo usando gli stessi strumenti usati per il contratto che stiamo esaminando.

Il contratto proxy

Usando le stesse tecniche usate per il suddetto contratto originale, possiamo vedere che il contratto si annulla se:

  • Sono presenti ETH allegati alla chiamata (0x05-0x0F)
  • Le dimensioni dei dati della chiamata sono inferiori a quattro (0x10-0x19 e 0xBE-0xC2)

E che i metodi che supporta sono:

MetodoFirma del metodoOffset a cui saltare
scaleAmountByPercentage(uint256,uint256)0x8ffb5c970x0135
isClaimed(uint256,address)0xd2ef07950x0151
claim(uint256,address,uint256,bytes32[])0x2e7ba6ef0x00F4
incrementWindow()0x338b1d310x0110
???0x3f26479e0x0118
???0x1e7df9d30x00C3
currentWindow()0xba0bafb40x0148
merkleRoot()0x2eb4a7ab0x0107
???0x81e580d30x0122
???0x1f1358230x00D8

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 fare clic sulle firme per vedere i suddetti dettagli), quindi devono essere metodi sovrascritti.

Uno dei metodi rimanenti è claim(<params>) e un altro è isClaimed(<params>), quindi sembra un contratto airdrop. Invece di analizzare il resto opcode per opcode, possiamo provare il decompilatore, che produce risultati utilizzabili per tre funzioni da questo contratto. La decompilazione degli altri viene lasciato come esercizio per il lettore.

scaleAmountByPercentage

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

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

Il primo require testa che i dati della chiamata abbiano, oltre ai quattro byte della firma della funzione, almeno 64 byte. abbastanza per i due parametri. Altrimenti c'è ovviamente qualcosa di sbagliato.

L'istruzione if sembra verificare che _param1 non sia zero e che _param1 * _param2 non sia negativo. Probabilmente serve a impedire casi di avvolgimento.

Infine, la funzione restituisce un valore in scala.

claim

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

1def unknown2e7ba6ef(uint256 _param1, uint256 _param2, uint256 _param3, array _param4) payable:
2 ...
3 require _param2 == addr(_param2)
4 ...
5 if currentWindow <= _param1:
6 revert with 0, 'impossibile rivendicare per una finestra futura'
7
📋 Copia

Qui vediamo due cose importanti:

  • _param2, sebbene sia dichiarato come uint256, è in realtà un indirizzo
  • _param1 è la finestra rivendicata, che dev'essere currentWindow o precedente.
1 ...
2 if stor5[_claimWindow][addr(_claimFor)]:
3 revert with 0, 'Il conto ha già rivendicato la finestra data'
4
📋 Copia

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

1 ...
2 idx = 0
3 s = 0
4 while idx < _param4.length:
5 ...
6 if s + sha3(mem[(32 * _param4.length) + 328 len mem[(32 * _param4.length) + 296]]) > mem[(32 * idx) + 296]:
7 mem[mem[64] + 32] = mem[(32 * idx) + 296]
8 ...
9 s = sha3(mem[_62 + 32 len mem[_62]])
10 continue
11 ...
12 s = sha3(mem[_66 + 32 len mem[_66]])
13 continue
14 if unknown2eb4a7ab != s:
15 revert with 0, 'Prova non valida'
16
Mostra tutto
📋 Copia

Sappiamo che unknown2eb4a7ab è in realtà la funzione merkleRoot(), quindi sembra che questo codice stia verificando una prova di Merkle. Ciò significa che _param4 è una prova di Merkle.

1 call addr(_param2) with:
2 value unknown81e580d3[_param1] * _param3 / 100 * 10^6 wei
3 gas 30000 wei
4
📋 Copia

Ecco come un contratto trasferisce i propri ETH a un altro indirizzo (contratto o posseduto esternamente). Lo chiama con un valore che è l'importo da trasferire. Quindi sembra che questo sia un airdrop di ETH.

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

Le ultime due righe ci dicono che anche Storage[2] è un contratto che chiamiamo. Se guardiamo la transazione del costruttore, vediamo che questo contratto è 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2, un contratto Wrapped Ether il cui codice sorgente è stato caricato in Etherscan.

Quindi sembra che i contratti tentino di inviare ETH a _param2. Se riescono a farlo, ottimo. Altrimenti, tentano di inviare WETH. Se _param2 è un conto posseduto esternamente (EOA), allora può sempre ricevere ETH, ma i contratti possono rifiutarsi di ricevere ETH. Tuttavia, WETH è ERC-20 e i contratti non possono rifiutarsi di accettarlo.

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

Alla fine della funzione vediamo che viene generata una voce del registro. Guarda le voci del registro generate e filtra l'argomento che inizia per 0xdbd5.... Se clicchiamo su una delle transazioni che hanno generato tale voce, vediamo che sembra indubbiamente una rivendicazione: il conto ha inviato un messaggio al contratto che stiamo decompilando e, in cambio, ha ricevuto degli ETH.

Una transazione di rivendicazione

1e7df9d3

Questa funzione è molto simile alla suddetta claim. Verifica anche una prova di Merkle, tenta di trasferire ETH al primo e produce lo stesso tipo di voce del registro.

1def unknown1e7df9d3(uint256 _param1, uint256 _param2, array _param3) payable:
2 ...
3 idx = 0
4 s = 0
5 while idx < _param3.length:
6 if idx >= mem[96]:
7 revert with 0, 50
8 _55 = mem[(32 * idx) + 128]
9 if s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]]) > mem[(32 * idx) + 128]:
10 ...
11 s = sha3(mem[_58 + 32 len mem[_58]])
12 continue
13 mem[mem[64] + 32] = s + sha3(mem[(32 * _param3.length) + 160 len mem[(32 * _param3.length) + 128]])
14 ...
15 if unknown2eb4a7ab != s:
16 revert with 0, 'Prova non valida'
17 ...
18 call addr(_param1) with:
19 value s wei
20 gas 30000 wei
21 if not return_data.size:
22 if not ext_call.success:
23 require ext_code.size(stor2)
24 call stor2.deposit() with:
25 value s wei
26 gas gas_remaining wei
27 ...
28 log 0xdbd5389f: addr(_param1), s, bool(ext_call.success)
29
Mostra tutto
📋 Copia

La differenza principale è che il primo parametro, la finestra per prelevare, non c'è. Invece, c'è un ciclo su tutte le finestre rivendicabili.

1 idx = 0
2 s = 0
3 while idx < currentWindow:
4 ...
5 if stor5[mem[0]]:
6 if idx == -1:
7 revert with 0, 17
8 idx = idx + 1
9 s = s
10 continue
11 ...
12 stor5[idx][addr(_param1)] = 1
13 if idx >= unknown81e580d3.length:
14 revert with 0, 50
15 mem[0] = 4
16 if unknown81e580d3[idx] and _param2 > -1 / unknown81e580d3[idx]:
17 revert with 0, 17
18 if s > !(unknown81e580d3[idx] * _param2 / 100 * 10^6):
19 revert with 0, 17
20 if idx == -1:
21 revert with 0, 17
22 idx = idx + 1
23 s = s + (unknown81e580d3[idx] * _param2 / 100 * 10^6)
24 continue
25
Mostra tutto
📋 Copia

Quindi, sembra una variante di claim che rivendica tutte le finestre.

Conclusione

A questo punto dovresti sapere come comprendere i contratti il cui codice sorgente non è disponibile usando gli opcode o (quando funziona) il decompilatore. Come è evidente dalla lunghezza di questo articolo, decompilare un contratto non è banale, ma in un sistema in cui la sicurezza è essenziale, poter verificare che i contratti operino come promesso è un'abilità importante.

Ultima modifica: , Invalid DateTime
Modifica la pagina

Questa pagina è stata utile?