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

Recentemente, os especialistas em segurança da CertiK detectaram frequentemente múltiplas instâncias do mesmo método de golpe de saída, comumente conhecido como Puxada de tapete. Após uma investigação mais aprofundada, descobrimos que várias instâncias do mesmo método apontam para o mesmo grupo, eventualmente ligado a mais de 200 golpes de saída de Tokens. Isso sugere que talvez tenhamos descoberto um grupo de hackers automatizado em grande escala que colhe ativos através de golpes de saída. Nestes golpes de saída, os atacantes criam um novo token ERC20 e utilizam tokens pré-minados juntamente com uma certa quantidade de WETH para criar uma pool de liquidez Uniswap V2. Após bots ou usuários na cadeia realizarem 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. Como os tokens obtidos pelo atacante do nada não são refletidos no fornecimento total e não acionam eventos de transferência, eles não são visíveis no etherscan, tornando difícil para os outsiders detectá-los. Os atacantes não apenas consideram o sigilo, mas também planejam um subterfúgio para enganar os usuários com habilidades técnicas básicas que verificam o etherscan, usando um problema menor para ocultar suas verdadeiras intenções…

Mergulhe no golpe

Golpe detalhado

Usando um dos casos como exemplo, vamos aprofundar nos detalhes desse golpe de saída. O que detectamos foi uma transação em que o atacante usou uma quantidade massiva de tokens (gerados silenciosamente) para esgotar a reserva de liquidez e lucrar. Nesta transação, a equipe do projeto trocou aproximadamente 416.483.104.164.831 (cerca de 416 quatrilhões) de tokens MUMI por cerca de 9,736 WETH, esgotando a liquidez da reserva. No entanto, esta transação é apenas a parte final de todo o golpe. Para entender o golpe inteiro, precisamos continuar rastreando.

Implantar tokens

Em 6 de março às 7:52 (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) de 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 depois de o token ter sido criado), 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 um pool de liquidez MUMI-WETH através 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 ver 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, descobriu-se que o contrato do 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 do token (especificamente implementado na função "_transfer").

O que é estranho é que o endereço fiscal 0x7ffb (o endereço para coletar 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, e não de 420.690.000 (aproximadamente 430 milhões).

Travar a liquidez

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

Depois que o LP é bloqueado, teoricamente todos os tokens MUMI de propriedade do endereço do atacante (0x8AF8) estão bloqueados na pool de liquidez (exceto a parte usada como taxas de manuseio), então o endereço do atacante (0x8AF8) não tem a capacidade de removê-lo através da capacidade de Liquidez para realizar Puxada de tapete. 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 isso é realmente o caso? ? Obviamente não, este é o caso, vamos continuar a análise.

Puxada de tapete

Às 8:10, um novo endereço de atacante ② (0x9DF4) apareceu e ele implantou o endereço de imposto 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 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á intencionalmente reduzindo 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 desejam ser expostas. 3. O contrato fiscal é implantado posteriormente ao contrato do token, e o endereço fiscal no contrato do 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. Na verdade, muitos golpes de saída são realizados por meio 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 11 da manhã (3 horas após a criação do token), o endereço do atacante ② (0x9DF4) realizou uma Puxada de 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.

Como o contrato fiscal (0x77fb) não é de código aberto, decompilamos 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 coleta 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 coleta de impostos (0x77fb) por ETH usando o roteador UniswapV2 e em seguida enviá-lo para o endereço declarado como '_manualSwap' no endereço de imposto.

O endereço de armazenamento do endereço _manualSwap é 0x0. Após a consulta com o comando getStorageAt do json-rpc, descobrimos que o endereço correspondente ao _manualSwap é exatamente o implementador do contrato de imposto (0x77fb): atacante ② (0x9DF4).

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

Em outras palavras, no final, o projeto usou 420.690.000.000.000 (aproximadamente 420 trilhões) MUMI para drenar o WETH no pool de liquidez e completar todo o golpe de saída. No entanto, há uma questão crucial aqui: onde o contrato de cobrança de impostos (0x77fb) obteve tantos tokens MUMI? Pelo conteúdo anterior, aprendemos que o fornecimento total de tokens MUMI no momento da implantação era de 420.690.000 (aproximadamente 420 milhões). No entanto, após o fim do esquema de puxada do tapete, quando consultamos o fornecimento total de tokens no contrato de token MUMI, ele permaneceu em 420.690.000 (como mostrado na figura abaixo, exibida como 420.690.000.000.000.000, que precisa subtrair os zeros à direita correspondentes ao decimal, onde o decimal é 9). Os tokens no contrato de arrecadação de impostos (0x77fb), superando em muito a oferta total (420.690.000.000.000, aproximadamente 420 trilhões), parecem ter aparecido do nada. Vale ressaltar que, como mencionado anteriormente, o endereço 0x77fb, atuando como endereço fiscal, sequer foi utilizado para receber taxas de transação geradas durante o processo de transferência de tokens MUMI; o imposto foi recebido pelo próprio contrato simbólico.

Revelar a Técnica

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

Os resultados revelaram que, de todos os 6 eventos de transferência envolvendo 0x77fb, apenas eventos foram observados nos quais os tokens foram transferidos para fora do contrato de coleta de impostos (0x7ffb), sem eventos de tokens MUMI sendo transferidos para dentro. À primeira vista, de fato parece que os tokens no contrato de coleta de impostos (0x7ffb) apareceram do nada. Portanto, a quantidade significativa de tokens MUMI que aparentemente apareceram do nada no contrato de coleta de impostos (0x7ffb) tem duas características: 1. Não afetou o total de fornecimento do contrato MUMI. 2. O aumento de tokens não acionou um evento de Transferência. Com isso em mente, 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 total de fornecimento 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 geração furtiva da equipe do projeto de tokens a partir de alterações 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 há uma função privada do tipo '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 fiscal (0x7ffb) para tokenAmount10*_decimals, que é 1.000.000.000 (aproximadamente 1 bilhão) vezes o tokenAmount, e depois converter a quantidade de MUMI em ETH a partir da piscina de liquidez e armazená-la no contrato de token (0x4894). Em seguida, procure 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 (para o endereço) 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 detecta que o usuário trocou WETH por tokens MUMI na piscina mais de 5 vezes, ele secretamente cunhará uma grande quantidade de tokens para o endereço de impostos e converterá parte dos tokens em ETH e os armazenará no contrato de token. Por um lado, a equipe do projeto coleta ostensivamente impostos e os troca automaticamente por uma pequena quantidade de ETH regularmente e os coloca no contrato de token. Isso é mostrado aos usuários e faz com que todos pensem que esta é a fonte de lucro da equipe do projeto. Por outro lado, o que a equipe do projeto está realmente fazendo é modificar diretamente o saldo da conta e drenar toda a piscina de liquidez após o número de transações do usuário atingir 5 vezes.

• Como obter lucro

Após a execução da função 'swapTokenForEth', a função '_transfer' também executará sendETHToFee para enviar o ETH obtido da arrecadação 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 em seu contrato.

Agora olhe 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 4.164.831 (aproximadamente 4,16 milhões) tokens MUMI por 0,349 ETH, e a segunda vez foi 416.483.100.000.000 (aproximadamente 416 trilhões) tokens MUMI por 9,368 ETH. A segunda troca é a troca iniciada dentro da função “swapExactETHForTokens” no contrato de imposto (0x7ffb). A razão pela qual o número não corresponde aos 420.690.000.000.000 (aproximadamente 420 trilhões) tokens representados pelos parâmetros de entrada é que alguns dos tokens são usados como imposto enviado ao contrato de token (0x4894), como mostrado na figura abaixo:

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

• Colheitadeira por trás do golpe

Conforme visto no conteúdo anterior, o ciclo inteiro do token MUMI, desde a implantação até a criação da piscina de liquidez e, em seguida, a Puxada de 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 piscina de liquidez como isca e menos de 0,5 ETH para implantação de contrato e iniciando 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 das transações 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 as EOAs (contas de propriedade externa) operando dentro da liquidez, descobriu-se que uma parte significativa dos endereços pertencia a operações de “bot” on-chain. Considerando a natureza rápida de entrada e saída de todo o golpe, é razoável supor que o alvo desse golpe eram os vários “bots” e scripts ativos na cadeia. Portanto, seja o design de contrato aparentemente desnecessário, mas complexo, o processo de bloqueio de liquidez, ou o comportamento suspeito dos atacantes que trocavam ativamente ETH por tokens MUMI no meio do caminho, tudo pode ser entendido como tentativas dos atacantes de enganar os vários mecanismos anti-fraude dos bots on-chain. Ao rastrear o fluxo de fundos, descobriu-se que todos os lucros obtidos do ataque foram enviados eventualmente pelo endereço atacante ② (0x9dF4) para o endereço 0xDF1a.

Na verdade, tanto as fontes de financiamento iniciais quanto os destinos finais de vários golpes de saída recentes apontaram para este endereço. Portanto, uma análise e estatísticas aproximadas das transações deste endereço foram conduzidas. Descobriu-se que o endereço se tornou ativo aproximadamente 2 meses atrás e iniciou mais de 7.000 transações até o momento, interagindo com mais de 200 tokens. Entre aproximadamente 40 registros de transações de tokens analisados, descobriu-se que quase todos os tokens, quando vistos em seus respectivos pools de liquidez, teriam uma única grande transação de troca que esgota todo o ETH no pool de liquidez, e todo o ciclo do golpe 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-se concluir que este endereço é, de fato, um grande colheitador de scam de saída automatizado em grande escala, visando operações de bots on-chain. Este endereço ainda está ativo.

Em conclusão, se o processo de cunhagem de um token 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á cunhando tokens secretamente. Isso agrava a situação atual, onde 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 quantitativas de tokens. Contar exclusivamente com eventos para capturar as mudanças de estado do token não é suficiente. Além disso, precisamos estar cientes de que, embora a conscientização 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

Visualizar 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 é reproduzido a partir de [GateCertiK], Encaminhe o Título Original‘技术详解 | 链上打新局中局，大规模Rug Pull手法解密’.Todos os direitos autorais pertencem ao autor original [CertiK]. Se houver objeções a esta reimpressão, entre em contato com oGate Aprenderequipe, e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.