Aviso de segurança Web3丨Um novo jogo dentro da cadeia, descriptografia do método Rug Pull em grande escala

Recentemente, a equipe de especialistas em segurança da CertiK detectou frequentemente vários "golpes de saída" com as mesmas táticas, comumente conhecidas como Rug Pull.

Depois de realizarmos pesquisas aprofundadas, descobrimos que vários incidentes com as mesmas táticas apontavam para a mesma gangue e, em última análise, estavam ligados a mais de 200 golpes de retirada de tokens. Isso indica que podemos ter descoberto uma equipe de hackers automatizada em grande escala que coleta ativos por meio de “golpes de saída”.

Nesses golpes de saída, o invasor criará um novo token ERC20 e um pool de liquidez Uniswap V2 com o token pré-minerado no momento da criação mais uma certa quantidade de WETH.

Quando o novo robô na cadeia ou o usuário compra novos tokens no pool de liquidez por um determinado número de vezes, o invasor usará os tokens gerados do nada para esgotar todo o WETH no pool de liquidez.

Como os tokens obtidos do nada pelo invasor não são refletidos no fornecimento total (totalSupply) e não acionam o evento Transfer, eles não podem ser vistos no etherscan, dificultando a percepção do mundo exterior.

Os invasores não apenas consideraram a ocultação, mas também criaram um jogo dentro de um jogo para paralisar os usuários que possuem habilidades técnicas básicas e podem ler etherscan, e usar um pequeno problema para encobrir seu verdadeiro propósito...

Golpe mais profundo

Tomemos um dos casos como exemplo para explicar os detalhes desse golpe de saída.

O que detectamos foi na verdade uma transação em que o invasor usou uma enorme quantidade de tokens (cunhados secretamente) para drenar o pool de liquidez e obter lucro. Nesta transação, a parte do projeto usou um total de 416.483.104.164.831 (aproximadamente 416 trilhões) MUMI para exchange Cerca de 9.736 WETH foram liberados, esgotando a liquidez do pool.

No entanto, esta transação é apenas o último elo de todo o golpe. Para entender todo o golpe, precisamos continuar rastreando.

Implantar tokens

Às 7h52 do dia 6 de março (horário UTC, o mesmo abaixo), o endereço do invasor (0x8AF8) Rug Pull implantou um token ERC20 (endereço 0x4894) chamado MUMI (nome completo MultiMixer AI) e pré-minerou-o 420.690.000 (aproximadamente 420 milhões) de tokens foram alocados e todos foram alocados para implantadores contratados.

O número de tokens pré-minerados corresponde ao código-fonte do contrato.

Adicionar liquidez

Às 8 horas em ponto (8 minutos após a criação do token), o endereço do invasor (0x8AF8) começou a adicionar liquidez.

O endereço do invasor (0x8AF8) chama a função openTrading no contrato de token, cria um pool de liquidez MUMI-WETH por meio da fábrica uniswap v2, adiciona todos os tokens pré-minerados e 3 ETH ao pool de liquidez e, finalmente, obtém aproximadamente 1.036 token LP.

Pode-se observar pelos detalhes da transação que dos 420.690.000 (aproximadamente 420 milhões) tokens originalmente usados para adicionar liquidez, aproximadamente 63.103.500 (aproximadamente 63 milhões) tokens foram enviados de volta ao contrato de token (endereço 0x4894). descobriu que o contrato de token cobrará uma certa taxa de manuseio para cada transferência, e o endereço para coletar a taxa de manuseio é o próprio contrato de token (implementado especificamente na "função _transfer").

**O estranho é que o endereço fiscal 0x7ffb (endereço para cobrança das taxas de transferência) foi definido no contrato, mas a taxa final foi enviada para o próprio contrato do token. **

Portanto, o número final de tokens MUMI adicionados ao pool de liquidez é 357.586.500 (aproximadamente 350 milhões) após impostos, e não 420.690.000 (aproximadamente 430 milhões).

Bloqueio de liquidez

Às 8h01 (1 minuto após a criação do pool de liquidez), o endereço do invasor (0x8AF8) bloqueou todos os 1.036 tokens LP obtidos pela adição de liquidez.

Depois que o LP é bloqueado, teoricamente todos os tokens MUMI pertencentes ao endereço do invasor (0x8AF8) são bloqueados no pool de liquidez (exceto a parte usada como taxa de manuseio), portanto, o endereço do invasor (0x8AF8) não tem a capacidade de removê-lo através da capacidade de liquidez para realizar Rug Pull.

Para permitir que os usuários comprem tokens recém-lançados com confiança, muitas partes do projeto bloqueiam o LP, o que significa que a parte do projeto está dizendo: “Não vou fugir, todos podem comprar com confiança!”, mas será mesmo assim? ? Obviamente que não, é esse o caso, continuemos a análise.

Puxador de tapete

Às 8h10, um novo endereço do invasor ② (0x9DF4) apareceu e ele implantou o endereço fiscal 0x7ffb declarado no contrato do token.

Há três pontos que valem a pena mencionar aqui:

1. O endereço onde o endereço fiscal é implantado não é o mesmo que o endereço onde os tokens são implantados. Isso pode indicar que a parte do projeto está reduzindo intencionalmente a correlação entre cada operação e o endereço, tornando mais difícil rastrear o comportamento.

2. O contrato do endereço fiscal não é open source, o que significa que podem existir operações ocultas no endereço fiscal que não pretende expor.

3. O contrato fiscal é implantado depois do contrato simbólico, e o endereço fiscal no contrato simbólico foi codificado, o que significa que a parte do projeto pode prever o endereço do contrato fiscal. Uma vez que a instrução CREATE determina o endereço do criador e uma vez, ele é implantado. O endereço do contrato é determinado, então a equipe do projeto simulou o endereço do contrato antecipadamente usando o endereço do criador.

**Na verdade, muitos golpes de saída são conduzidos através de endereços fiscais, e as características do modo de implantação dos endereços fiscais estão em conformidade com os pontos 1 e 2 acima. **

Às 11h (3 horas após a criação do token), o endereço do invasor ② (0x9DF4) realizou um Rug Pull. Ao chamar o método "swapExactETHForTokens" do contrato fiscal (0x77fb), ele trocou 416.483.104.164.831 (aproximadamente 416 trilhões) de tokens MUMI no endereço fiscal por aproximadamente 9.736 ETH e esgotou a liquidez do pool.

Como o contrato fiscal (0x77fb) não é de código aberto, descompilamos seu bytecode e os resultados da descompilação são os seguintes:

Após verificar o código descompilado do método “swapExactETHForTokens” do contrato fiscal (0x77fb), descobrimos que a principal função desta função é transferir o contrato fiscal (0x77fb) com o número “xt” (especificado pelo chamador) através roteador uniswapV2.Os tokens MUMI são trocados por ETH e enviados para o endereço "_manualSwap" declarado no endereço fiscal.

O endereço de armazenamento do endereço _manualSwap é 0x0. Após consultar com o comando getStorageAt do json-rpc, verifica-se que o endereço correspondente a _manualSwap é o implantador do contrato fiscal (0x77fb): atacante ② (0x9DF4).

O parâmetro de entrada xt desta transação Rug Pull é 420.690.000.000.000.000.000.000, correspondendo a 420.690.000.000.000 (aproximadamente 420 trilhões) de tokens MUMI (o decimal dos tokens MUMI é 9).

Em outras palavras, no final, o projeto utilizou 420.690.000.000.000 (aproximadamente 420 trilhões) de MUMI para drenar o WETH do pool de liquidez e completar todo o esquema de saída.

No entanto, há uma questão crucial aqui: de onde veio o contrato fiscal (0x77fb) de tantos tokens MUMI?

A partir do conteúdo anterior, sabemos que o fornecimento total de tokens MUMI no momento da implantação do contrato de token era de 420.690.000 (aproximadamente 420 milhões) e, após o término do golpe de saída, o fornecimento total que consultamos no contrato de token MUMI. ainda é 420.690.000 (mostrado como 420.690.000.000.000.000 na figura abaixo, você precisa subtrair 0 do dígito decimal correspondente, que é 9).Os tokens no contrato fiscal (0x77fb) excedem em muito o fornecimento total (420.690.000.000.000, cerca de 420 trilhões) É como se tivesse surgido do nada. Você deve saber que, como mencionado acima, 0x77fb, como endereço fiscal, nem sequer foi utilizado para receber as taxas de manuseio geradas durante o processo de transferência do token MUMI. O imposto foi recebido pelo contrato de token.

Técnica revelada

• De onde veio o contrato fiscal

Para explorar a origem do token do contrato fiscal (0x7ffb), analisamos seu histórico de eventos de transferência ERC20.

Verificou-se que entre todos os 6 eventos de transferência relacionados a 0x77fb, houve apenas eventos de transferência do contrato tributário (0x7ffb), e não houve eventos em que os tokens MUMI foram transferidos. 0x7ffb) realmente apareceram do nada.

Portanto, os enormes tokens MUMI que surgiram do nada no endereço do contrato fiscal (0x7ffb) têm duas características:

1. Sem impacto no fornecimento total do contrato MUMI

2. O aumento de tokens não desencadeou o evento Transfer

Então a ideia é muito clara, ou seja, deve haver um backdoor no contrato do token MUMI, esse backdoor modifica diretamente a variável de saldo, e ao modificar o balabce, não modifica o totalSupply e não aciona o evento Transfer.

Em outras palavras, esta é uma implementação de token ERC20 não padrão ou maliciosa. Os usuários não conseguem detectar que o lado do projeto está cunhando tokens secretamente a partir de mudanças no fornecimento total e nos eventos. **

O próximo passo é verificar a ideia acima: procuramos diretamente a palavra-chave “saldo” no código-fonte do contrato do token MUMI.

Como resultado, descobrimos que existe uma função do tipo privado "swapTokensForEth" no contrato e o parâmetro de entrada é tokenAmount do tipo uint256. Na 5ª linha da função, a parte do projeto modifica diretamente _taxWallet, que é o MUMI saldo do contrato fiscal (0x7ffb). é tokenAmount * 10**_decimals, que é 1.000.000.000 (aproximadamente 1 bilhão) vezes o tokenAmount e, em seguida, converta o valor tokenAmount de MUMI em ETH do pool de liquidez e armazene-o no contrato de token (0x4894).

Em seguida, pesquise a palavra-chave “swapTokenForEth”.

A função "swapTokenForEth" é chamada na função "_transfer". Se você observar atentamente as condições de chamada, encontrará:

1. Quando o endereço de recebimento da transferência for o pool de liquidez MUMI-WETH.

2. A função "swapTokenForEth" só será chamada quando outros endereços comprarem tokens MUMI no pool de liquidez por mais de _preventSwapBefore (5 vezes)

3. O tokenAmount recebido é o valor menor entre o saldo do token MUMI pertencente ao endereço do token e _maxTaxSwap

Ou seja, quando o contrato detectar que o usuário trocou WETH por tokens MUMI no pool mais de 5 vezes, ele cunhará secretamente uma grande quantidade de tokens para o endereço fiscal e converterá parte dos tokens em ETH e armazenará eles no contrato de token.

**Por um lado, a parte do projeto aparentemente coleta impostos e os troca automaticamente por uma pequena quantidade de ETH regularmente e os coloca no contrato de token. Isso é para os usuários verem, fazendo com que todos pensem que esta é a fonte do projeto lucros do partido. **

**Por outro lado, o que a equipe do projeto realmente está fazendo é modificar diretamente o saldo da conta e drenar todo o pool de liquidez depois que o número de transações do usuário atingir 5 vezes. **

• Como obter lucro

Após executar a função "swapTokenForEth", a função "_transfer" também executará sendETHToFee para enviar o ETH obtido na arrecadação de impostos no endereço do token para o contrato fiscal (0x77fb).

O ETH do contrato tributário (0x77fb) pode ser retirado pela função “resgate” implementada em seu contrato.

Agora olhe novamente para o registro de resgate da última transação lucrativa em todo o esquema de saída.

Um total de duas trocas foram feitas na transação lucrativa: a primeira vez foi de 4.164.831 (aproximadamente 4,16 milhões) tokens MUMI por 0,349 ETH, e a segunda vez foi de 416.483.100.000.000 (aproximadamente 416 trilhões) de tokens MUMI por 9.368 ETH. A segunda troca é a troca iniciada dentro da função "swapExactETHForTokens" no contrato fiscal (0x7ffb).A razão pela qual o número não corresponde aos 420.690.000.000.000 (aproximadamente 420 trilhões) de tokens representados pelos parâmetros de entrada é porque alguns dos tokens são usados como imposto Enviado para o contrato de token (0x4894), conforme figura abaixo:

A primeira troca corresponde ao segundo processo de troca. Quando o token é enviado do contrato fiscal (0x7ffb) para o contrato do roteador, a condição de acionamento da função backdoor no contrato do token é atendida, fazendo com que "swapTokensForEth" seja acionado. A troca iniciada pela função não é uma operação crítica.

• A foice atrás

Como pode ser visto acima, todo o ciclo do esquema de saída, desde a implantação, até a criação do pool de liquidez, até o Rug Pull dos tokens MUMI, leva apenas cerca de 3 horas, mas a um custo inferior a cerca de 6,5 ETH (3 ETH são usados para Para adicionar liquidez, 3 ETH foram usados para trocar MUMI do pool de liquidez por incentivo, e menos de 0,5 ETH foram usados para implantar contratos e iniciar transações) e obtiveram 9,7 ETH, com lucro máximo de mais de 50%. **

Houve 5 transações em que o invasor trocou ETH por MUMI, que não foram mencionadas no artigo anterior. As informações da transação são as seguintes:

Ao analisar os endereços EOA que operam em liquidez, descobrimos que uma parte considerável dos endereços são "novos robôs" na cadeia. Combinado com as características de todo o golpe, que entra e sai rapidamente,** temos motivos para acreditar que todo esse golpe tem como alvo Os alvos são todos os tipos de novos robôs e novos scripts que são muito ativos na cadeia. **

Portanto, seja o design de contrato aparentemente desnecessário, mas complicado, a implantação do contrato e o processo de bloqueio de liquidez do token, ou o comportamento suspeito do endereço relacionado do invasor trocando ativamente ETH por tokens MUMI, pode-se entender que o invasor está tentando Um disfarce feito para tentar enganar os programas antifraude de vários novos bots da rede. **

Ao rastrear o fluxo de capital, descobrimos que todos os rendimentos do ataque foram finalmente enviados para o endereço de liquidação de fundos ** (0xDF1a)** pelo endereço de ataque ② (0x9dF4).

Na verdade, a fonte inicial de fundos e o destino final dos fundos para muitos golpes de saída que detectamos recentemente apontam para este endereço, por isso conduzimos uma análise aproximada e estatísticas sobre as transações neste endereço.

Foi finalmente descoberto que o endereço se tornou ativo há cerca de 2 meses e iniciou mais de 7.000 transações até hoje, e que o endereço interagiu com mais de 200 tokens.

Analisamos cerca de 40 registros de transações de tokens e descobrimos que nos pools de liquidez correspondentes a quase todos os tokens que analisamos, eventualmente haveria uma transação de troca com um valor de entrada muito maior que o fornecimento total do token. A entrada da ETH está esgotada e todo o período do golpe de saída é mais curto.

As transações de implantação de alguns dos tokens (Mingyan China) são as seguintes:

Portanto, podemos concluir que este endereço é na verdade uma colheitadeira automatizada de “exit scam” em grande escala, e o alvo da colheita é o novo robô da cadeia.

**Este endereço ainda está ativo. **

Escreva no final

Se um token não modificar o totalSupply durante a cunhagem e não acionar o evento Transfer, será difícil para nós detectar se o lado do projeto está cunhando tokens secretamente. Isso também agravará o problema de saber se o token é seguro ou não depende inteiramente do lado do projeto. Consciente ou não" status quo.

**Portanto, podemos precisar considerar a melhoria do mecanismo de token existente ou a introdução de uma solução eficaz de detecção de quantidade total de token para garantir a abertura e a transparência das alterações na quantidade de token. **Não é suficiente capturar alterações de status de token com eventos agora.

E o que precisamos estar atentos é que, embora a conscientização antifraude de todos esteja melhorando, os métodos antifraude dos invasores também estão melhorando. Este é um jogo sem fim. Precisamos continuar aprendendo e pensando para podermos fazer isso .Proteja-se no jogo.