Avançar o Título Original’技术详解 | 链上打新局中局，大规模Rug Pull手法解密’

Recentemente, os especialistas em segurança da CertiK detetaram frequentemente múltiplas instâncias do mesmo método de esquema de saída, comumente conhecido como Puxar o tapete. Após uma investigação mais aprofundada, descobrimos que várias instâncias do mesmo método apontam para o mesmo grupo, ligado a mais de 200 esquemas de saída de Tokens. Isso sugere que podemos ter descoberto um grupo de hackers automatizado em larga escala que colhe ativos através de esquemas de saída. Nestes esquemas de saída, os atacantes criam um novo token ERC20 e usam tokens pré-minados juntamente com uma certa quantidade de WETH para criar uma pool de liquidez Uniswap V2. Após bots ou utilizadores na cadeia efetuarem um certo número de compras do novo token na pool de liquidez, o atacante esgotará todo o WETH na pool com tokens gerados do nada. Uma vez que os tokens obtidos pelo atacante do nada não são refletidos no fornecimento total e não acionam eventos de Transferência, não são visíveis no etherscan, tornando difícil para os externos detetar. Os atacantes não só consideram o encobrimento, mas também desenham um subterfúgio para enganar os utilizadores com habilidades técnicas básicas que verificam o etherscan, usando um problema menor para ocultar as suas verdadeiras intenções...

Mergulhe no golpe

Fraude em Profundidade

Usando um dos casos como exemplo, vamos aprofundar os detalhes deste esquema de saída. O que detetámos foi uma transação em que o atacante usou uma quantidade massiva de tokens (emitidos em silêncio) para esgotar a piscina de liquidez e lucrar. Nesta transação, a equipa do projeto trocou aproximadamente 416,483,104,164,831 (cerca de 416 quatrilhões) tokens MUMI por cerca de 9,736 WETH, esgotando a liquidez da piscina. No entanto, esta transação é apenas a parte final de todo o esquema. Para entender o esquema completo, precisamos continuar a rastrear.

Implantar tokens

Em 6 de março, às 7:52 AM (horário UTC, o mesmo para o seguinte), o endereço do atacante (0x8AF8) implantou um token ERC20 chamado MUMI (nome completo MultiMixer AI) no endereço 0x4894 e pré-minerou 420.690.000 (cerca de 420 milhões) tokens, todos alocados ao implementador do contrato.

O número de tokens pré-minados 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 atacante (0x8AF8) começou a adicionar liquidez. O endereço do atacante (0x8AF8) chama a função openTrading no contrato do token, cria uma piscina de liquidez MUMI-WETH através da fábrica uniswap v2, adiciona todos os tokens pré-minados e 3 ETH à piscina de liquidez, e finalmente obtém aproximadamente 1,036 token LP.

Pode ser visto nos 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 para o contrato do token (endereço 0x4894). Ao visualizar o código-fonte do contrato, foi encontrado que o contrato do token cobrará uma certa taxa de manipulação para cada transferência, e o endereço para receber a taxa de manipulação é o próprio contrato do token (implementado especificamente na função “_transfer”).

O que é estranho é que o endereço fiscal 0x7ffb (o endereço para recolher 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 é de 357.586.500 (aproximadamente 350 milhões) após impostos, não 420.690.000 (aproximadamente 430 milhões).

Trancar a liquidez

Às 8:01 (1 minuto após a criação da pool de liquidez), o endereço do atacante (0x8AF8) bloqueou todos os 1.036 tokens LP obtidos ao adicionar liquidez.

Depois de o LP estar bloqueado, teoricamente, todos os tokens MUMI detidos pelo endereço do atacante (0x8AF8) estão bloqueados na pool de liquidez (exceto a parte utilizada como taxas de gestão), portanto, o endereço do atacante (0x8AF8) não tem a capacidade de removê-lo através da capacidade de Liquidez para realizar um Puxar o tapete. Para permitir que os utilizadores 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á a dizer: "Não vou fugir, todos podem comprar com confiança!", mas será que isto é realmente o caso? Obviamente que não, este é o caso, continuemos a análise.

Puxar o tapete

Às 8:10, apareceu um novo endereço de atacante ② (0x9DF4), e ele implantou o endereço de imposto 0x7ffb declarado no contrato do token.

Existem três pontos que valem a pena mencionar aqui: 1. O endereço onde o endereço fiscal é implantado e o endereço onde os tokens são implantados não são os mesmos. 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 é de código aberto, o que significa que pode haver operações ocultas no endereço fiscal que não querem ser expostas. 3. O contrato fiscal é implantado posteriormente ao contrato de token e o endereço fiscal no contrato de token foi codificado, o que significa que o endereço do contrato fiscal pode ser previsto pela equipe do projeto com antecedência. Como a instrução CREATE determina o endereço do criador e o nonce, o endereço do contrato de implantação é determinado. Portanto, a equipe do projeto usou o endereço do criador para simular e calcular o endereço do contrato com antecedência. De fato, muitos golpes de saída são realizados por meio de endereços fiscais, e as características do modo de implantação de 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 atacante ② (0x9DF4) realizou um Puxar o tapete. Ao chamar o método "swapExactETHForTokens" do contrato fiscal (0x77fb), ele trocou 416.483.104.164.831 (aproximadamente 416 trilhões) tokens MUMI no endereço fiscal por aproximadamente 9,736 ETH e esgotou a liquidez no pool.

Uma vez que o contrato fiscal (0x77fb) não é de código aberto, decompilamos o seu bytecode e os resultados da decompilação são os seguintes:

https://app.dedaub.com/decompile?md5=01e2888c7691219bb7ea8c6b6befe11c

Após descompilar o método "swapExactETHForTokens" do contrato de arrecadação de impostos (0x77fb), descobrimos que a principal funcionalidade implementada por esta função é trocar a quantidade especificada "xt" (especificada pelo chamador) de tokens MUMI pertencentes ao contrato de arrecadação de impostos (0x77fb) em ETH usando o roteador UniswapV2 e depois enviá-lo para o endereço declarado como "_manualSwap" no endereço de impostos.

O endereço de armazenamento do endereço _manualSwap é 0x0. Depois de consultar com o comando getStorageAt do json-rpc, descobrimos que o endereço correspondente ao _manualSwap é exatamente o implementador do contrato fiscal (0x77fb): atacante ② (0x9DF4).

O parâmetro de entrada xt desta transação de Puxar o tapete é 420,690,000,000,000,000,000,000, correspondente a 420,690,000,000,000 (aproximadamente 420 trilhões) tokens MUMI (a casa decimal dos tokens MUMI é 9).

Em outras palavras, no final, o projeto usou 420.690.000.000.000 (aproximadamente 420 trilhões) de MUMI para drenar o WETH no pool de liquidez e concluir todo o esquema de saída. No entanto, há uma questão crucial aqui: de onde veio o contrato de coleta de impostos (0x77fb) tantos tokens MUMI? Do conteúdo anterior, aprendemos que o fornecimento total de tokens MUMI no momento da implementação era de 420.690.000 (aproximadamente 420 milhões). No entanto, após o fim do esquema de puxar o tapete, quando consultamos o fornecimento total de tokens no contrato de token MUMI, permaneceu em 420.690.000 (como mostrado na figura abaixo, exibido como 420.690.000.000.000, que precisa subtrair os zeros finais correspondentes ao decimal, onde o decimal é 9). Os tokens no contrato de coleta de impostos (0x77fb), muito além do fornecimento total (420.690.000.000.000, aproximadamente 420 trilhões), parecem ter surgido do nada. Vale ressaltar que, como mencionado anteriormente, o endereço 0x77fb, atuando como o endereço de imposto, nem sequer foi usado para receber taxas de transação geradas durante o processo de transferência de tokens MUMI; o imposto foi recebido pelo próprio contrato do token.

Revelar a Técnica

• De onde veio o contrato fiscal?

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

Os resultados revelaram que, de todos os 6 eventos de transferência envolvendo 0x77fb, apenas eventos foram observados em que os tokens foram transferidos para fora do contrato de arrecadação de impostos (0x7ffb), sem eventos de tokens MUMI sendo transferidos para dentro. À primeira vista, parece de fato que os tokens no contrato de arrecadação de impostos (0x7ffb) apareceram do nada. Portanto, a quantidade significativa de tokens MUMI que aparentemente apareceu do nada no contrato de arrecadação de impostos (0x7ffb) tem duas características: 1. Não afetou o totalSupply do contrato MUMI. 2. O aumento de tokens não acionou um evento de Transferência. Levando isso em consideração, torna-se evidente que deve haver uma porta dos fundos no contrato de token MUMI, modificando diretamente a variável de saldo sem alterações correspondentes no totalSupply ou acionando eventos de Transferência. Em outras palavras, esta é uma implementação não padrão ou maliciosa de um token ERC20, onde os usuários não podem perceber a criação furtiva de tokens pela equipe do projeto a partir de mudanças no fornecimento total ou eventos. O próximo passo é verificar essa ideia pesquisando diretamente a palavra-chave “saldo” no código-fonte do contrato de token MUMI.

Como resultado, descobrimos que existe uma função de 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 saldo MUMI do contrato de impostos (0x7ffb) para tokenAmount10*_decimais, que é 1.000.000.000 (aproximadamente 1 bilhão) vezes o tokenAmount, e depois converter a quantidade de tokenAmount de MUMI em ETH a partir da pool de liquidez e armazená-la no contrato do token (0x4894). Em seguida, pesquise a palavra-chave “swapTokenForEth”.

A função 'swapTokenForEth' é chamada dentro da função '_transfer'. Após uma inspeção mais detalhada das condições de chamada, observa-se que: 1. Quando o endereço do destinatário (endereço de destino) da transferência é o pool de liquidez MUMI-WETH. 2. A função 'swapTokenForEth' é chamada apenas quando a quantidade de tokens MUMI comprados por outros endereços no pool de liquidez excede '_preventSwapBefore' (5 vezes). 3. O parâmetro 'tokenAmount' passado para a função é o valor mínimo entre o saldo de tokens MUMI possuído pelo endereço do token e '_maxTaxSwap'.

Ou seja, quando o contrato deteta que o utilizador trocou WETH por tokens MUMI na pool mais de 5 vezes, secretamente criará uma grande quantidade de tokens para o endereço fiscal e converterá parte dos tokens em ETH, armazenando-os no contrato do token. Por um lado, a parte do projeto supostamente recolhe impostos e troca automaticamente por uma pequena quantidade de ETH regularmente, colocando-os no contrato do token. Isto é mostrado aos utilizadores e faz com que todos pensem que esta é a origem dos lucros da parte do projeto. Por outro lado, o que a equipa do projeto está realmente a fazer é modificar diretamente o saldo da conta e drenar toda a pool de liquidez depois do número de transações do utilizador 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 da coleta de impostos no endereço do token para o contrato de impostos (0x77fb).

O ETH no contrato fiscal (0x77fb) pode ser retirado pela função de "resgate" implementada no contrato.

Agora, olhe para o registo de resgate da última transação lucrativa no esquema de saída inteiro.

Um total de duas trocas foram feitas na transação lucrativa. A primeira vez foi de 4.164.831 (aproximadamente 4,16 milhões) de 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 é que alguns dos tokens são usados como imposto enviado para o contrato do token (0x4894), conforme mostrado na figura abaixo:

A primeira troca corresponde ao processo de troca da segunda troca. Quando o token é enviado do contrato fiscal (0x7ffb) para o contrato do roteador, a condição de acionamento da função de porta dos fundos no contrato do token é atendida, causando a ativação de "swapTokensForEth". A troca iniciada pela função não é uma operação crítica.

• Colheitadeira por trás do golpe

Como visto no conteúdo anterior, todo o ciclo do token MUMI, desde a implantação até a criação da pool de liquidez e, em seguida, o Puxar o tapete, levou apenas cerca de 3 horas. No entanto, conseguiu obter mais de 50% de lucro com um custo de menos de aproximadamente 6.5 ETH (3 ETH para adicionar liquidez, 3 ETH para trocar MUMI da pool de liquidez como isca e menos de 0.5 ETH para implantação do contrato e iniciar transações), resultando em 9.7 ETH. O atacante realizou cinco transações de troca de ETH por MUMI, que não foram mencionadas anteriormente. Os detalhes da transação são os seguintes:

• https://etherscan.io/tx/0x62a59ba219e9b2b6ac14a1c35cb99a5683538379235a68b3a607182d7c814817
• https://etherscan.io/tx/0x0c9af78f983aba6fef85bf2ecccd6cd68a5a5d4e5ef3a4b1e94fb10898fa597e
• https://etherscan.io/tx/0xc0a048e993409d0d68450db6ff3fdc1f13474314c49b734bac3f1b3e0ef39525
• https://etherscan.io/tx/0x9874c19cedafec351939a570ef392140c46a7f7da89b8d125cabc14dc54e7306
• https://etherscan.io/tx/0x9ee3928dc782e54eb99f907fcdddc9fe6232b969a080bc79caa53ca143736f75

Ao analisar os EOAs (contas de propriedade externa) que operam dentro da liquidez, descobriu-se que uma parte significativa dos endereços pertencia a operações "bot" na cadeia. Considerando a natureza rápida e volátil de todo o esquema, é razoável assumir que o alvo deste esquema eram os vários "bots" e scripts ativos na cadeia. Portanto, quer se trate do design de contrato aparentemente desnecessário, mas complexo, da implantação de contrato, do processo de bloqueio de liquidez, ou do comportamento suspeito dos atacantes trocando ativamente ETH por tokens MUMI a meio caminho, tudo isso pode ser entendido como tentativas dos atacantes de enganar os vários mecanismos anti-fraude dos bots em cadeia. Ao rastrear o fluxo de fundos, descobriu-se que todos os lucros obtidos com o ataque foram eventualmente enviados pelo endereço de ataque ② (0x9dF4) para o endereço 0xDF1a.

De facto, tanto as fontes de financiamento iniciais como os destinos finais de vários esquemas de saída recentes apontaram para este endereço. Portanto, foi realizada uma análise e estatísticas aproximadas das transações deste endereço. Verificou-se que o endereço se tornou ativo há aproximadamente 2 meses e iniciou mais de 7.000 transações até à data, interagindo com mais de 200 tokens. Entre aproximadamente 40 registos de transações de token analisados, verificou-se que quase todos os tokens, quando vistos nos respetivos pools de liquidez, teriam uma única transação de grande troca que esgota todo o ETH no pool de liquidez, e todo o ciclo de esquema de saída é curto. Aqui estão as transações de implantação de alguns tokens (por exemplo, cigarro chinês):

https://etherscan.io/tx/0x324d7c133f079a2318c892ee49a2bcf1cbe9b20a2f5a1f36948641a902a83e17

https://etherscan.io/tx/0x0ca861513dc68eaef3017e7118e7538d999f9b4a53e1b477f1f1ce07d982dc3f

Portanto, pode concluir-se que este endereço é, de facto, um grande coletor automatizado de golpes de saída, visando operações de bots on-chain. Este endereço ainda está ativo.

Em conclusão, se o processo de criação de tokens não corresponder à modificação do totalSupply ou à ativação de eventos de Transferência, é difícil para nós perceber se a equipe do projeto está secretamente criando tokens. Isso agrava a situação atual em que a segurança dos tokens depende inteiramente da consciência da equipe do projeto. Portanto, pode ser necessário considerar a melhoria dos mecanismos de token existentes ou a introdução de um esquema eficaz de monitoramento do fornecimento total de tokens para garantir transparência nas mudanças na quantidade de tokens. Depender apenas de eventos para capturar mudanças de estado do token não é suficiente. Além disso, precisamos estar cientes de que, embora a consciência da prevenção de fraudes das pessoas esteja aumentando, os métodos dos atacantes de contrafraude também estão avançando. Este é um jogo interminável, e precisamos continuar aprendendo e pensando para nos protegermos.

• Ferramentas usadas neste artigo

Ver informações básicas da transação: https://etherscan.io/

Descompilação de contrato: app.dedaub.com/decompilejson-rpc: https://www.quicknode.com/docs/ethereum/eth_getStorageAt

Aviso legal：

1. Este artigo é reimpresso de [ CertiK], Encaminhe o Título Original‘技术详解 | 链上打新局中局，大规模Rug Pull手法解密’.Todos os direitos autorais pertencem ao autor original [CertiK]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Aprenderequipa, e eles vão resolver rapidamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem aconselhamento de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipe Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.