Engenharia Reversa de um Contrato

Introdução

Não há segredos no blockchain, tudo o que acontece é consistente, verificável e está disponível publicamente. Idealmente, os contratos devem ter seu código-fonte publicado e verificado no Etherscan (opens in a new tab). No entanto, nem sempre é o caso (opens in a new tab). Neste artigo, você aprenderá como fazer engenharia reversa de contratos analisando um contrato sem código-fonte, 0x2510c039cc3b061d79e564b38836da87e31b342f (opens in a new tab).

Existem compiladores reversos, mas eles nem sempre produzem resultados utilizáveis (opens in a new tab). Neste artigo, você aprenderá a fazer engenharia reversa manualmente e a entender um contrato a partir dos códigos de operação (opens in a new tab), bem como a interpretar os resultados de um descompilador.

Para entender este artigo, você já deve saber o básico da EVM e estar pelo menos um pouco familiarizado com a linguagem de montagem da EVM. Você pode ler sobre esses tópicos aqui (opens in a new tab).

Preparar o código executável

Você pode obter os códigos de operação indo para o Etherscan para o contrato, clicando na guia Contrato e depois em Mudar para Visualização de Opcodes. Você obterá uma visualização de um código de operação por linha.

Para entender os saltos, no entanto, você precisa saber onde no código cada código de operação está localizado. Para fazer isso, uma maneira é abrir uma planilha do Google e colar os códigos de operação na coluna C. Você pode pular as etapas a seguir fazendo uma cópia desta planilha já preparada (opens in a new tab).

O próximo passo é obter os locais corretos do código para que possamos entender os saltos. Colocaremos o tamanho do código de operação na coluna B e o local (em hexadecimal) na coluna A. Digite esta função na célula B1 e depois copie e cole no resto da coluna B, até o final do código. Depois de fazer isso, você pode ocultar a coluna B.

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

Primeiro, esta função adiciona um byte para o próprio código de operação e, em seguida, procura por PUSH. Os códigos de operação de push são especiais porque precisam ter bytes adicionais para o valor que está sendo inserido. Se o código de operação for um PUSH, extraímos o número de bytes e o adicionamos.

Em A1, coloque o primeiro deslocamento, zero. Depois, em A2, insira esta função e copie e cole novamente para o resto da coluna A:

1=dec2hex(hex2dec(A1)+B1)

Precisamos desta função para nos dar o valor hexadecimal, porque os valores que são inseridos antes dos saltos (JUMP e JUMPI) são nos dados em hexadecimal.

O ponto de entrada (0x00)

Os contratos são sempre executados a partir do primeiro byte. Esta é a parte inicial do código:

Este código faz duas coisas:

1. Escreve 0x80 como um valor de 32 bytes para os locais de memória 0x40-0x5F (0x80 é armazenado em 0x5F e 0x40-0x5E são todos zeros).
2. Lê o tamanho dos dados de chamada. Normalmente, os dados de chamada para um contrato Ethereum seguem a ABI (interface binária de aplicativo) (opens in a new tab), que no mínimo requer quatro bytes para o seletor de função. Se o tamanho dos dados da chamada for menor que quatro, salta para 0x5E.

O manipulador em 0x5E (para dados de chamada não ABI)

Este trecho começa com um JUMPDEST. Programas EVM (máquina virtual Ethereum) lançam uma exceção se você saltar para um código de operação que não seja JUMPDEST. Em seguida, ele analisa o CALLDATASIZE e, se for "verdadeiro" (ou seja, diferente de zero), salta para 0x7C. Veremos isso abaixo.

Então, quando não há dados de chamada, lemos o valor de Storage[6]. Ainda não sabemos qual é esse valor, mas podemos procurar transações que o contrato recebeu sem dados de chamada. As transações que apenas transferem ETH sem quaisquer dados de chamada (e, portanto, sem método) têm no Etherscan o método Transfer. Na verdade, a primeira transação que o contrato recebeu (opens in a new tab) é uma transferência.

Se olharmos nessa transação e clicarmos em Clique para ver mais, vemos que os dados da chamada, chamados de dados de entrada, estão de fato vazios (0x). Observe também que o valor é 1,559 ETH, o que será relevante mais tarde.

Em seguida, clique na guia Estado e expanda o contrato do qual estamos fazendo engenharia reversa (0x2510...). Você pode ver que Storage[6] mudou durante a transação, e se você mudar de Hex para Número, verá que se tornou 1.559.000.000.000.000.000, o valor transferido em wei (adicionei os pontos para maior clareza), correspondendo ao próximo valor do contrato.

Se olharmos nas mudanças de estado causadas por outras transações de Transfer do mesmo período (opens in a new tab), vemos que Storage[6] rastreou o valor do contrato por um tempo. Por enquanto, vamos chamá-lo de Valor*. O asterisco (*) nos lembra que ainda não sabemos o que essa variável faz, mas não pode ser apenas para rastrear o valor do contrato porque não há necessidade de usar o armazenamento, que é muito caro, quando você pode obter o saldo de suas contas usando ADDRESS BALANCE. O primeiro código de operação insere o próprio endereço do contrato. O segundo lê o endereço no topo da pilha e o substitui pelo saldo desse endereço.

Continuaremos a rastrear este código no destino do salto.

O NOT é bit a bit, então ele inverte o valor de cada bit no valor da chamada.

Saltamos se Valor* for menor ou igual a 2^256-CALLVALUE-1. Isso parece uma lógica para evitar overflow. E, de fato, vemos que, após algumas operações sem sentido (escrever na memória que está prestes a ser excluída, por exemplo), no deslocamento 0x01DE, o contrato reverte se o overflow for detectado, o que é um comportamento normal.

Note que tal overflow é extremamente improvável, porque exigiria que o valor da chamada mais Valor* fosse comparável a 2^256 wei, cerca de 10^59 ETH. O fornecimento total de ETH, no momento da escrita, é inferior a duzentos milhões (opens in a new tab).

Se chegamos aqui, obtemos Valor* + CALLVALUE e saltamos para o deslocamento 0x75.

Se chegarmos aqui (o que exige que os dados da chamada estejam vazios), adicionamos o valor da chamada a Valor*. Isso é consistente com o que dizemos que as transações de Transfer fazem.

Finalmente, limpe a pilha (o que não é necessário) e sinalize o fim bem-sucedido da transação.

Para resumir tudo, aqui está um fluxograma para o código inicial.

O manipulador em 0x7C

Eu propositalmente não coloquei no título o que este manipulador faz. O objetivo não é ensinar como este contrato específico funciona, mas como fazer engenharia reversa de contratos. Você aprenderá o que ele faz da mesma maneira que eu, seguindo o código.

Chegamos aqui de vários lugares:

• Se houver dados de chamada de 1, 2 ou 3 bytes (do deslocamento 0x63)
• Se a assinatura do método for desconhecida (dos deslocamentos 0x42 e 0x5D)

Esta é outra célula de armazenamento, uma que não consegui encontrar em nenhuma transação, então é mais difícil saber o que significa. O código abaixo tornará isso mais claro.

Esses códigos de operação truncam o valor que lemos de Storage[3] para 160 bits, o comprimento de um endereço Ethereum.

Este salto é supérfluo, já que estamos indo para o próximo código de operação. Este código não é tão eficiente em termos de gás quanto poderia ser.

Bem no início do código, definimos Mem[0x40] como 0x80. Se procurarmos por 0x40 mais tarde, veremos que não o alteramos - então podemos assumir que é 0x80.

Copie todos os dados da chamada para a memória, começando em 0x80.

Agora as coisas estão muito mais claras. Este contrato pode atuar como um proxy (opens in a new tab), chamando o endereço em Storage[3] para fazer o trabalho real. DELEGATE_CALL chama um contrato separado, mas permanece no mesmo armazenamento. Isso significa que o contrato delegado, para o qual somos um proxy, acessa o mesmo espaço de armazenamento. Os parâmetros para a chamada são:

• Gás: todo o gás restante
• Endereço chamado: Storage[3]-como-endereço
• Dados de chamada: Os bytes CALLDATASIZE começando em 0x80, que é onde colocamos os dados de chamada originais
• Dados de retorno: Nenhum (0x00 - 0x00) Obteremos os dados de retorno por outros meios (veja abaixo)

Aqui copiamos todos os dados de retorno para o buffer de memória começando em 0x80.

Então, após a chamada, copiamos os dados de retorno para o buffer 0x80 - 0x80+RETURNDATASIZE e, se a chamada for bem-sucedida, fazemos um RETURN com exatamente esse buffer.

DELEGATECALL Falhou

Se chegarmos aqui, em 0xC0, significa que o contrato que chamamos reverteu. Como somos apenas um proxy para esse contrato, queremos retornar os mesmos dados e também reverter.

Portanto, fazemos REVERT com o mesmo buffer que usamos para RETURN anteriormente: 0x80 - 0x80+RETURNDATASIZE

Chamadas ABI

Se o tamanho dos dados da chamada for de quatro bytes ou mais, pode ser uma chamada ABI válida.

O Etherscan nos diz que 1C é um código de operação desconhecido, porque foi adicionado depois que o Etherscan escreveu este recurso (opens in a new tab) e eles não o atualizaram. Uma tabela de códigos de operação atualizada (opens in a new tab) nos mostra que isso é um deslocamento para a direita

Dividir os testes de correspondência da assinatura do método em dois, dessa forma, economiza metade dos testes, em média. O código que se segue imediatamente e o código em 0x43 seguem o mesmo padrão: DUP1 os primeiros 32 bits dos dados da chamada, PUSH4 (((assinatura do método, executa EQ para verificar a igualdade e, em seguida, JUMPI se a assinatura do método corresponder. Aqui estão as assinaturas do método, seus endereços e, se conhecida, a definição do método correspondente (opens in a new tab):

Se nenhuma correspondência for encontrada, o código salta para o manipulador de proxy em 0x7C, na esperança de que o contrato para o qual somos um proxy tenha uma correspondência.

splitter()

A primeira coisa que esta função faz é verificar se a chamada não enviou nenhum ETH. Esta função não é payable (opens in a new tab). Se alguém nos enviou ETH, deve ter sido um erro, e queremos fazer um REVERT para evitar que esse ETH fique onde eles não possam recuperá-lo.

E 0x80 agora contém o endereço do proxy

O Código E4

Essa é a primeira vez que vemos essas linhas, mas elas são compartilhadas com outros métodos (veja abaixo). Então, vamos chamar o valor na pilha de X e apenas lembrar que em splitter() o valor desse X é 0xA0.

Portanto, esse código recebe um ponteiro de memória na pilha (X) e faz com que o contrato retorne (RETURN) com um buffer que é 0x80 - X.

No caso do splitter(), isso retorna o endereço para o qual somos um proxy. RETURN retorna o buffer em 0x80-0x9F, que é onde escrevemos esses dados (deslocamento 0x130 acima).

currentWindow()

O código nos deslocamentos 0x158-0x163 é idêntico ao que vimos em 0x103-0x10E em splitter() (além do destino de JUMPI), então sabemos que currentWindow() também não é payable.

O código DA

Esse código também é compartilhado com outros métodos. Então, chamaremos o valor na pilha de Y e lembre-se de que em currentWindow() o valor desse Y é Storage[1].

Escreve Y em 0x80-0x9F.

E o resto já foi explicado acima. Portanto, saltos para 0xDA escrevem o valor do topo da pilha (Y) em 0x80-0x9F e retornam esse valor. No caso de currentWindow(), ele retorna Storage[1].

merkleRoot()

O código nos deslocamentos 0xED-0xF8 é idêntico ao que vimos em 0x103-0x10E em splitter() (além do destino de JUMPI), então sabemos que merkleRoot() também não é payable.

O que acontece após o salto já descobrimos. Portanto, merkleRoot() retorna Storage[0].

0x81e580d3

O código nos deslocamentos 0x138-0x143 é idêntico ao que vimos em 0x103-0x10E em splitter() (além do destino de JUMPI), então sabemos que esta função também não é payable.

Parece que esta função leva pelo menos 32 bytes (uma palavra) de dados de chamada.

Se não obtiver os dados da chamada, a transação é revertida sem nenhum dado de retorno.

Vamos ver o que acontece se a função receber os dados de chamada de que precisa.

calldataload(4) é a primeira palavra dos dados da chamada após a assinatura do método

Se a primeira palavra não for menor que Storage[4], a função falhará. Ela reverte sem nenhum valor retornado:

Se calldataload(4) for menor que Storage[4], obtemos este código:

E os locais de memória 0x00-0x1F agora contêm os dados 0x04 (0x00-0x1E são todos zeros, 0x1F é quatro)

Portanto, há uma tabela de pesquisa no armazenamento, que começa no SHA3 de 0x000...0004 e tem uma entrada para cada valor de dados de chamada legítimo (valor abaixo de Storage[4]).

Já sabemos o que o código no deslocamento 0xDA faz, ele retorna o valor do topo da pilha para o chamador. Logo, esta função retorna o valor da tabela de pesquisa para o chamador.

0x1f135823

O código nos deslocamentos 0xC4-0xCF é idêntico ao que vimos em 0x103-0x10E em splitter() (além do destino de JUMPI), então sabemos que esta função também não é payable.

Já sabemos o que o código no deslocamento 0xDA faz, ele retorna o valor do topo da pilha para o chamador. Portanto, esta função retorna Valor*.

Resumo do método

Você sente que entende o contrato até este ponto? Eu não. Até o momento, temos esses métodos:

Mas nós sabemos que qualquer outra funcionalidade é fornecida pelo contrato no Storage[3]. Talvez se soubéssemos qual o contrato, isso nos daria uma pista. Felizmente, isto é blockchain e tudo é conhecido, ao menos em teoria. Não vimos nenhum método que defina Storage[3], então deve ter sido definido pelo construtor.

O construtor

Quando olhamos para um contrato (opens in a new tab), também podemos ver a transação que o criou.

Se clicarmos nessa transação e depois na guia Estado, podemos ver os valores iniciais dos parâmetros. Especificamente, podemos ver que Storage[3] contém 0x2f81e57ff4f4d83b40a9f719fd892d8e806e0761 (opens in a new tab). Esse contrato deve conter a funcionalidade ausente. Podemos entendê-lo usando as mesmas ferramentas que utilizamos para o contrato que estamos investigando.

O contrato de proxy

Utilizando as mesmas técnicas que usamos para o contrato original acima, podemos ver que o contrato reverte se:

• Houver algum ETH anexado à chamada (0x05-0x0F)
• O tamanho dos dados da chamada for menor que quatro (0x10-0x19 e 0xBE-0xC2)

E que os métodos que ele suporta são:

Nós podemos ignorar os quatro métodos inferiores porque nunca chegaremos a eles. Suas assinaturas são tais que nosso contrato original cuida delas por si só (você pode clicar nas assinaturas para ver os detalhes acima), por isso devem ser métodos que são substituídos (opens in a new tab).

Um dos métodos restantes é claim(<params>), e outro é isClaimed(<params>), então parece um contrato de airdrop. Em vez de passar pelo restante código de operação por código de operação, podemos tentar o descompilador (opens in a new tab), que produz resultados úteis para três funções deste contrato. A engenharia reversa dos outros é deixada como um exercício para o leitor.

scaleAmountByPercentage

Isso é o que o descompilador nos fornece para essa função:

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)
Copiar

O primeiro require testa que os dados da chamada tenham, além dos quatro bytes da assinatura da função, pelo menos 64 bytes, suficientes para os dois parâmetros. Do contrário, obviamente, há algo errado.

A instrução if parece verificar se _param1 não é zero e se _param1 * _param2 não é negativo. Provavelmente, isso é para evitar casos de wrap around (retorno).

Finalmente, a função retorna um valor escalado.

claim

O código que o descompilador cria é complexo, e nem todo ele é relevante para nós. Vou pular algumas partes para focar nas linhas que acredito fornecerem informações úteis

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, 'não é possível reivindicar para uma janela futura'
Copiar

Vemos aqui duas coisas importantes:

• _param2, embora esteja declarado como um uint256, é na verdade um endereço
• _param1 é a janela que está sendo reivindicada, que tem que ser currentWindow ou anterior.

1  ...
2  if stor5[_claimWindow][addr(_claimFor)]:
3      revert with 0, 'A conta já reivindicou a janela fornecida'
Copiar

Então, agora sabemos que Storage[5] é uma matriz de janelas e endereços, e se o endereço reivindicou a recompensa por essa janela.

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 inválida'
Exibir tudo
Copiar

Sabemos que unknown2eb4a7ab é, na verdade, a função merkleRoot(), então este código parece estar verificando uma prova de Merkle (opens in a new tab). Isso significa que _param4 é uma prova de Merkle.

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

É assim que um contrato transfere seu próprio ETH para outro endereço (de contrato ou de propriedade externa). Ele o chama com um valor que é a quantidade a ser transferida. Logo, parece que isso é um airdrop de 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
Copiar

As duas linhas inferiores nos dizem que Storage[2] também é um contrato que chamamos. Se olharmos para a transação do construtor (opens in a new tab) vemos que este contrato é 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 (opens in a new tab), um contrato de Wrapped Ether cujo código-fonte foi carregado no Etherscan (opens in a new tab).

Assim, parece que os contratos tentam enviar ETH para _param2. Se puder fazer isso, ótimo. Caso contrário, ele tenta enviar WETH (opens in a new tab). Se _param2 for uma conta de propriedade externa (EOA), então ela sempre pode receber ETH, mas os contratos podem se recusar a receber ETH. No entanto, WETH é ERC-20 e os contratos não podem se recusar a aceitar isso.

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

No final da função, vemos uma entrada de log sendo gerada. Veja as entradas de log geradas (opens in a new tab) e filtre pelo tópico que começa com 0xdbd5.... Se clicarmos em uma das transações que gerou tal entrada (opens in a new tab), veremos que realmente parece uma reivindicação - a conta enviou uma mensagem para o contrato do qual estamos fazendo engenharia reversa e, em troca, recebeu ETH.

1e7df9d3

Esta função é muito semelhante a claim acima. Ela também verifica uma prova de Merkle, tenta transferir ETH para o primeiro e produz o mesmo tipo de entrada de log.

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 inválida'
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)
Exibir tudo
Copiar

A principal diferença é que o primeiro parâmetro, a janela para retirada, não está lá. Em vez disso, há um loop sobre todas as janelas que podem ser reivindicadas.

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
Exibir tudo
Copiar

Portanto, parece uma variante de claim que reivindica todas as janelas.

Conclusão

Até agora você já deve saber como entender contratos cujo código-fonte não está disponível, usando os códigos de operação ou (quando funciona) o descompilador. Como é evidente pela extensão deste artigo, a engenharia reversa de um contrato não é trivial, mas em um sistema onde a segurança é essencial, é uma habilidade importante ser capaz de verificar se os contratos funcionam como prometido.

Veja aqui mais do meu trabalho (opens in a new tab).

Última atualização da página: 22 de agosto de 2025

q (opens in a new tab)

b (opens in a new tab)

p (opens in a new tab)

+7

Ver colaboradores