Forward the Original Title’技术详解 | 链上打新局中局，大规模Rug Pull手法解密’

Recientemente, los expertos en seguridad de CertiK han detectado con frecuencia múltiples instancias del mismo método de estafa de salida, comúnmente conocido como un Rug Pull. Tras una investigación más a fondo, descubrimos que varias instancias del mismo método apuntan al mismo grupo, vinculado en última instancia a más de 200 estafas de salida de tokens. Esto sugiere que podríamos haber descubierto un grupo de hackers automatizado a gran escala que cosecha activos a través de estafas de salida. En estas estafas de salida, los atacantes crean un nuevo token ERC20 y utilizan tokens preminados junto con una cierta cantidad de WETH para crear un pool de liquidez Uniswap V2. Después de que los bots o los usuarios en la cadena realicen un cierto número de compras del nuevo token en el pool de liquidez, el atacante agotará todo el WETH en el pool con tokens generados de la nada. Dado que los tokens obtenidos por el atacante de la nada no se reflejan en el suministro total y no activan eventos de transferencia, no son visibles en etherscan, lo que dificulta que los externos los detecten. Los atacantes no solo consideran el ocultamiento, sino que también diseñan un subterfugio para engañar a los usuarios con habilidades técnicas básicas que revisan etherscan, utilizando un problema menor para ocultar sus verdaderas intenciones...

Sumérgete en la estafa

Estafa en Profundidad

Usando uno de los casos como ejemplo, adentrémonos en los detalles de esta estafa de salida. Lo que detectamos fue una transacción en la que el atacante utilizó una cantidad masiva de tokens (acuñados en silencio) para agotar el fondo de liquidez y obtener beneficios. En esta transacción, el equipo del proyecto intercambió aproximadamente 416,483,104,164,831 (alrededor de 416 cuatrillones) tokens MUMI por alrededor de 9.736 WETH, agotando la liquidez del fondo. Sin embargo, esta transacción es solo la parte final de toda la estafa. Para entender toda la estafa, necesitamos seguir rastreando hacia atrás.

Desplegar tokens

El 6 de marzo a las 7:52 AM (hora UTC, igual para lo siguiente), la dirección del atacante (0x8AF8) desplegó un token ERC20 llamado MUMI (nombre completo MultiMixer AI) en la dirección 0x4894 y pre-minó 420.690.000 (aproximadamente 420 millones) tokens, todos asignados al desplegador del contrato.

El número de tokens pre-minados corresponde al código fuente del contrato.

Agregar liquidez

A las 8 en punto (8 minutos después de que se creara el token), la dirección del atacante (0x8AF8) comenzó a añadir liquidez. La dirección del atacante (0x8AF8) llama a la función openTrading en el contrato del token, crea un pool de liquidez MUMI-WETH a través de la fábrica uniswap v2, añade todos los tokens pre-minados y 3 ETH al pool de liquidez, y finalmente obtiene aproximadamente 1.036 tokens LP.

Se puede ver en los detalles de la transacción que de los 420,690,000 (aproximadamente 420 millones) tokens originalmente utilizados para añadir liquidez, aproximadamente 63,103,500 (aproximadamente 63 millones) tokens fueron devueltos al contrato del token (dirección 0x4894). Al ver el código fuente del contrato, se encontró que el contrato del token cobrará una cierta tarifa por cada transferencia, y la dirección para cobrar la tarifa es el propio contrato del token (implementado específicamente en la función "_transfer").

Lo extraño es que la dirección fiscal 0x7ffb (la dirección para cobrar las comisiones de transferencia) se ha establecido en el contrato, pero la tarifa final se envió al propio contrato del token.

Por lo tanto, el número final de tokens MUMI agregados al pool de liquidez es 357,586,500 (aproximadamente 350 millones) después de impuestos, no 420,690,000 (aproximadamente 430 millones).

Bloquear liquidez

A las 8:01 (1 minuto después de que se creara el pool de liquidez), la dirección del atacante (0x8AF8) bloqueó los 1.036 tokens LP obtenidos al añadir liquidez.

Después de que el LP está bloqueado, teóricamente todos los tokens MUMI poseídos por la dirección del atacante (0x8AF8) están bloqueados en la piscina de liquidez (excepto la parte utilizada como tarifas de gestión), por lo que la dirección del atacante (0x8AF8) no tiene la capacidad de retirarlo a través de la capacidad de liquidez para realizar un Rug Pull. Para permitir a los usuarios comprar tokens recién lanzados con confianza, muchas partes del proyecto bloquean LP, lo que significa que la parte del proyecto está diciendo: '¡No me escaparé, todos pueden comprar con confianza!', pero ¿es realmente así? Obviamente no, este es el caso, sigamos con el análisis.

Rug Pull

A las 8:10, apareció una nueva dirección de atacante ② (0x9DF4), y desplegó la dirección de impuestos 0x7ffb declarada en el contrato del token.

Hay tres puntos que vale la pena mencionar aquí: 1. La dirección donde se implementa la dirección fiscal y la dirección donde se implementan los tokens no son las mismas. Esto puede indicar que la parte del proyecto está reduciendo intencionadamente la correlación entre cada operación y la dirección, lo que dificulta el seguimiento del comportamiento. 2. El contrato del domicilio fiscal no es de código abierto, lo que significa que puede haber operaciones ocultas en el domicilio fiscal que no se quieren exponer. 3. El contrato fiscal se implementa más tarde que el contrato de token, y la dirección fiscal en el contrato de token se ha codificado de forma rígida, lo que significa que el equipo del proyecto puede predecir la dirección del contrato de impuestos con anticipación. Dado que la instrucción CREATE determina la dirección y el nonce del creador, se determina la dirección del contrato de implementación. Por lo tanto, el equipo del proyecto utilizó la dirección del creador para simular y calcular la dirección del contrato por adelantado. De hecho, muchas estafas de salida se llevan a cabo a través de direcciones fiscales, y las características del modo de implementación de las direcciones fiscales cumplen con los puntos 1 y 2 anteriores. A las 11 a.m. (3 horas después de que se creara el token), la dirección del atacante (2) (0x9DF4) realizó un Rug Pull. Al llamar al método "swapExactETHForTokens" del contrato fiscal (0x77fb), intercambió 416,483,104,164,831 (aproximadamente 416 billones) tokens MUMI en la dirección fiscal por aproximadamente 9.736 ETH y agotó la liquidez en el grupo.

Dado que el contrato fiscal (0x77fb) no es de código abierto, descompilamos su bytecode y los resultados de la descompilación son los siguientes:

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

Después de descompilar el método “swapExactETHForTokens” del contrato de recolección de impuestos (0x77fb), descubrimos que la funcionalidad principal implementada por esta función es intercambiar la cantidad especificada “xt” (especificada por el llamante) de tokens MUMI propiedad del contrato de recolección de impuestos (0x77fb) en ETH utilizando el enrutador UniswapV2 y luego enviarlo a la dirección declarada como “_manualSwap” en la dirección fiscal.

La dirección de almacenamiento de la dirección _manualSwap es 0x0. Después de consultar con el comando getStorageAt de json-rpc, encontramos que la dirección correspondiente a _manualSwap es exactamente el desplegador del contrato de impuestos (0x77fb): atacante ② (0x9DF4).

El parámetro de entrada xt de esta transacción Rug Pull es 420,690,000,000,000,000,000,000, correspondiente a 420,690,000,000,000 (aproximadamente 420 billones) tokens MUMI (la parte decimal de los tokens MUMI es 9).

En otras palabras, al final, el proyecto utilizó 420,690,000,000,000 (aproximadamente 420 billones) MUMI para drenar el WETH en el pool de liquidez y completar todo el esquema de estafa de salida. Sin embargo, aquí hay una pregunta crucial: ¿de dónde obtuvo el contrato de recaudación de impuestos (0x77fb) tantos tokens MUMI? A partir del contenido anterior, aprendimos que el suministro total de tokens de MUMI en el momento de implementación era de 420,690,000 (aproximadamente 420 millones). Sin embargo, después del final del esquema de rug pull, cuando consultamos el suministro total de tokens en el contrato de token MUMI, se mantuvo en 420,690,000 (como se muestra en la figura a continuación, mostrado como 420,690,000,000,000,000, lo que necesita restar los ceros finales correspondientes al decimal, donde el decimal es 9). Los tokens en el contrato de recaudación de impuestos (0x77fb), que superan con creces el suministro total (420,690,000,000,000, aproximadamente 420 billones), parecen haber aparecido de la nada. Cabe destacar que, como se mencionó anteriormente, la dirección 0x77fb, que actúa como la dirección de impuestos, ni siquiera se ha utilizado para recibir las tarifas de transacción generadas durante el proceso de transferencia de tokens MUMI; el impuesto fue recibido por el contrato de token en sí mismo.

Revele la Técnica

• ¿De dónde proviene el contrato fiscal?

Para explorar la fuente de tokens del contrato fiscal (0x7ffb), examinamos su historial de eventos de transferencia ERC20.

Los resultados revelaron que de los 6 eventos de transferencia que involucraron a 0x77fb, solo se observaron eventos en los que se transfirieron tokens desde el contrato de recolección de impuestos (0x7ffb), sin eventos de tokens MUMI transferidos. A primera vista, parece que los tokens en el contrato de recolección de impuestos (0x7ffb) aparecieron de la nada. Por lo tanto, la cantidad significativa de tokens MUMI que aparentemente aparecieron de la nada en el contrato de recolección de impuestos (0x7ffb) tiene dos características: 1. No afectó el total de suministro del contrato MUMI. 2. El aumento de tokens no desencadenó un evento de transferencia. Con esto en mente, se hace evidente que debe haber una puerta trasera en el contrato de tokens MUMI, modificando directamente la variable de saldo sin cambios correspondientes en el total de suministro o desencadenando eventos de transferencia. En otras palabras, esta es una implementación no estándar o maliciosa de un token ERC20, donde los usuarios no pueden percibir la acuñación sigilosa del equipo del proyecto a partir de cambios en el suministro total o eventos. El siguiente paso es verificar esta idea buscando directamente la palabra clave "balance" en el código fuente del contrato de tokens MUMI.

Como resultado, descubrimos que hay una función de tipo privado "swapTokensForEth" en el contrato, y el parámetro de entrada es tokenAmount de tipo uint256. En la quinta línea de la función, la parte del proyecto modifica directamente _taxWallet, que es el saldo de MUMI del contrato de impuestos (0x7ffb) para tokenAmount. 10*_decimales, que es 1,000,000,000 (aproximadamente mil millones) veces la cantidad de tokens, y luego convertir la cantidad de tokens de MUMI en ETH del pool de liquidez y almacenarla en el contrato de tokens (0x4894). Luego buscar la palabra clave “swapTokenForEth”.

La función "swapTokenForEth" se llama dentro de la función "_transfer". Tras una inspección más detallada de las condiciones de llamada, se observa que: 1. Cuando la dirección del destinatario (dirección de destino) de la transferencia es el pool de liquidez MUMI-WETH. 2. La función "swapTokenForEth" se llama solo cuando la cantidad de tokens MUMI comprados por otras direcciones en el pool de liquidez supera "_preventSwapBefore" (5 veces). 3. El parámetro "tokenAmount" pasado a la función es el valor mínimo entre el saldo de tokens MUMI propiedad de la dirección del token y "_maxTaxSwap".

Es decir, cuando el contrato detecta que el usuario ha intercambiado WETH por tokens MUMI en la pool más de 5 veces, secretamente acuñará una gran cantidad de tokens para la dirección de impuestos, y convertirá parte de los tokens en ETH y los almacenará en el contrato de tokens. Por un lado, el equipo del proyecto aparentemente recauda impuestos y los intercambia automáticamente por una pequeña cantidad de ETH regularmente y los coloca en el contrato de tokens. Esto se muestra a los usuarios y hace que todos piensen que esta es la fuente de los beneficios del equipo del proyecto. Por otro lado, lo que el equipo del proyecto realmente está haciendo es modificar directamente el saldo de la cuenta y drenar toda la pool de liquidez después de que el número de transacciones de usuarios alcance 5 veces.

• Cómo obtener beneficios

Después de ejecutar la función "swapTokenForEth", la función "_transfer" también ejecutará sendETHToFee para enviar el ETH obtenido de la recaudación de impuestos en la dirección del token al contrato de impuestos (0x77fb).

El ETH en el contrato fiscal (0x77fb) puede ser retirado mediante la función de "rescate" implementada en su contrato.

Ahora echa un vistazo al registro de redención de la última transacción rentable en toda la estafa de salida.

Un total de dos intercambios se realizaron en la transacción rentable. La primera vez fue de 4,164,831 (aproximadamente 4.16 millones) tokens MUMI por 0.349 ETH, y la segunda vez fue de 416,483,100,000,000 (aproximadamente 416 billones) tokens MUMI por 9.368 ETH. El segundo intercambio es el intercambio iniciado dentro de la función 'swapExactETHForTokens' en el contrato fiscal (0x7ffb). La razón por la que el número no coincide con los 420,690,000,000,000 (aproximadamente 420 billones) tokens representados por los parámetros de entrada es que algunos de los tokens se utilizan como impuesto enviado al contrato de tokens (0x4894), como se muestra en la figura siguiente:

El primer intercambio corresponde al proceso del segundo intercambio. Cuando el token se envía desde el contrato de impuestos (0x7ffb) al contrato del enrutador, se cumplen las condiciones del desencadenador de la función de puerta trasera en el contrato del token, lo que provoca que se active "swapTokensForEth". El intercambio iniciado por la función no es una operación crítica.

• Cosechadora Detrás de la Estafa

Como se ve en el contenido anterior, todo el ciclo del token MUMI, desde el despliegue hasta la creación del pool de liquidez, y luego el Rug Pull, tomó solo alrededor de 3 horas. Sin embargo, logró obtener más del 50% de beneficio con un costo de menos de aproximadamente 6.5 ETH (3 ETH para agregar liquidez, 3 ETH para intercambiar MUMI del pool de liquidez como cebo, y menos de 0.5 ETH para el despliegue del contrato y la iniciación de transacciones), lo que resultó en 9.7 ETH. El atacante realizó cinco transacciones de intercambio de ETH por MUMI, que no se mencionaron anteriormente. Los detalles de la transacción son los siguientes:

• 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

Al analizar las EOA (cuentas de propiedad externa) que operaban dentro de la liquidez, se descubrió que una parte significativa de las direcciones pertenecían a operaciones de "bots" en cadena. Teniendo en cuenta la rápida naturaleza de entrada y salida de toda la estafa, es razonable suponer que el objetivo de esta estafa eran los diversos "bots" y scripts activos en la cadena. Por lo tanto, ya sea que se trate del diseño del contrato aparentemente innecesario pero complejo, la implementación del contrato, el proceso de bloqueo de liquidez o el comportamiento sospechoso de los atacantes que intercambian activamente ETH por tokens MUMI a mitad de camino, todo puede entenderse como intentos de los atacantes de engañar a los mecanismos antifraude de varios bots en cadena. Al rastrear el flujo de fondos, se descubrió que todas las ganancias obtenidas del ataque fueron finalmente enviadas por la dirección atacante (2) (0x9dF4) a la dirección 0xDF1a.

De hecho, tanto las fuentes de financiamiento iniciales como los destinos finales de múltiples estafas de salida recientes han apuntado a esta dirección. Por lo tanto, se realizó un análisis y estadísticas aproximadas de las transacciones de esta dirección. Se descubrió que la dirección se volvió activa hace aproximadamente 2 meses y ha iniciado más de 7,000 transacciones hasta la fecha, interactuando con más de 200 tokens. Entre aproximadamente 40 registros de transacciones de tokens analizados, se descubrió que casi todos los tokens, al verse en sus correspondientes piscinas de liquidez, tendrían una sola transacción de intercambio grande que agota todo el ETH en la piscina de liquidez, y todo el ciclo de estafa de salida es corto. Aquí están las transacciones de implementación de algunos tokens (por ejemplo, cigarrillo chino):

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

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

Por lo tanto, se puede concluir que esta dirección es, de hecho, un recolector de "exit scam" automatizado a gran escala, dirigido a operaciones de bots on-chain. Esta dirección sigue activa.

En conclusión, si el proceso de creación de tokens de un token no corresponde a la modificación de totalSupply o la activación de eventos de Transferencia, nos resulta difícil percibir si el equipo del proyecto está creando tokens en secreto. Esto agudiza la situación actual en la que la seguridad de los tokens depende enteramente de la conciencia del equipo del proyecto. Por lo tanto, puede ser necesario considerar la mejora de los mecanismos de tokens existentes o la introducción de un esquema efectivo de monitoreo del suministro total de tokens para garantizar transparencia en los cambios de cantidad de tokens. Confiar únicamente en eventos para capturar cambios en el estado de los tokens no es suficiente. Además, debemos ser conscientes de que aunque la conciencia de la prevención del fraude de las personas está aumentando, los métodos de los atacantes para contraatacar el fraude también están avanzando. Este es un juego interminable y debemos seguir aprendiendo y pensando para protegernos a nosotros mismos.

• Herramientas utilizadas en este artículo

Ver información básica de transacción: https://etherscan.io/

Descompilación de contrato: app.dedaub.com/decompilejson-rpc: https://www.quicknode.com/docs/ethereum/eth_getStorageAt

Descargo de responsabilidad：

1. Este artículo fue reimpreso de [lCertiK], Reenviar el Título Original‘技术详解 | 链上打新局中局，大规模Rug Pull手法解密’.Todos los derechos de autor pertenecen al autor original [CertiK]. Si hay objeciones a esta reimpresión, por favor contacte al Gate Learnequipo, y lo resolverán rápidamente.
2. Descargo de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.