Mi batalla contra un bot "sweeper": os cuento como recuperé 1000 $ de un shur
ForoCoches: Miembro
04-jun-2022 19:52
#33
| Grande shur, además de buena persona, un tipo inteligente. |
*AutoBan Spam/Flood/Troll*
04-jun-2022 20:30
#34
|
Puto amo. 10/10. Gracias por hacer de este subforo algo mejor. |
Cuenta Premium ⭐⭐⭐⭐⭐
04-jun-2022 21:29
#39
|
Muy buenas shurs, me gustaría compartir con vosotros esta historia que terminó con final feliz y que tal vez os pueda servir de ayuda en caso de que os pase algo similar o simplemente para que conozcáis un poco más el funcionamiento de la blockchain.
Para mí toda esta batalla contra el bot me ha servido para aprender un poco más sobre este mundillo con la doble satisfacción de poder ayudar a alguien a recuperar sus fondos. Problema Hace unos días el shur @Iberia, abrió el siguiente hilo: Hackeo de METAMASK + Bot borrador En el hilo expone el siguiente problema: Cada vez que envío algo de BNB a mi wallet aparece justo después una transacción firmada por mi propia wallet que envía ese BNB al monedero del bot.  Esto ocurre porque en algún momento la clave privada del shur se vio comprometida (phishing, robo de información, etc.) y el "hacker" lo único que tuvo que hacer es conectar un bot para que automáticamente limpiara los fondos. Este bot es conocido en la comunidad con el nombre de bot "sweeper" (barrendero) y su funcionamiento se basa en vigilar la lista de transacciones pendientes (mempool) para detectar un envío de BNB hacia la wallet comprometida. Cuando lo detecta, envía en el menor tiempo posible una transacción de retiro de fondos para que al titular de la wallet no le dé tiempo a realizar ninguna acción. Sin BNB no es posible operar con la wallet porque no podemos pagar el gas, por lo que la cuenta queda inutilizada. El problema es que al quedar la wallet inutilizada el shur no podía sacar unos fondos que tenía en Staking desde hace meses y que ya se habían desbloqueado, estos fondos ascendían a algo más de 1000 $. Toma de contacto Tras leer su hilo y mas o menos entender la naturaleza del problema me pongo en contacto con él para ayudarle. Una vez me da la dirección de su Wallet puedo ver que efectivamente el problema ocurre tal cual lo cuenta:  En azul: La wallet limpia desde la que envía BNB para poder operar la wallet comprometida. En amarillo: Es la wallet comprometida desde donde se realizan operaciones sin su consentimiento. En rojo: La wallet del hacker, una de ellas, en realidad tenía bastantes más. En un primer momento, cuando veo esto, pienso que la solución es muy fácil porque en la imagen se puede apreciar que el envío de BNB y el robo ocurre en 2 bloques distintos (18318520 y 18318522) pensando erróneamente que el bot no estaba mirando la mempool y que podría colocar mi transacción en el mismo bloque que la del envío del BNB. Intento de solución 1  Monto una estrategia muy sencilla que es hacer un script que mire la mempool detecte el envío de BNB a la wallet comprometida y automáticamente lance una transacción de test para ver si mi transacción cae por delante de la del bot y puedo empezar a operar la wallet del shur. Pero... cuando voy a enviar la transacción ocurre esto: Código:
"error":{"code":-32000,"message":"insufficient funds for gas * price + value"}
¿tiene la wallet fondos suficientes como para pagar el coste de la transacción y el valor BNB que envías? La respuesta es que no, porque la transacción de envío de BNB aún está pendiente, por lo que la mía la descarta y ni siquiera entra a la mempool. Intento de solución 2  Como no sé cuando es el momento exacto para poder enviar la transacción y el bot sí, intento hacer frontrun al bot para invalidar su transacción con algo más de gas. Esto es muy sencillo de hacer, me pongo a mirar en la mempol una transacción que salga de la wallet comprometida, veo que nonce (el nonce es un índice que usan los nodos para saber cuál es la última transacción enviada) tiene, envío la mía con un poquito más de gas y el mismo nonce. Tras varios intentos puedo ver que en TODAS las ejecuciones la transacción minada siempre es la del bot y no la mía. Para ver porque narices no estaba entrando mi transacción primero decido "depurar" la mempool y ver que está ocurriendo cuando el bot envía su transacción. Me encuentro lo siguiente: Código:
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 642,
data: '0x',
}
{
from: '0x98442BDA3A28...'
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 638,
}
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
nonce: 641,
}
{
from: '0x98442BDA3A28...',
gasPrice: BigNumber { _hex: '0x0414d46655', _isBigNumber: true },
to: '0xA1fF30a24485...',
value: BigNumber { _hex: '0x026dc545c64176', _isBigNumber: true },
nonce: 639,
}
.
.
.otras 30 más
 sí, como lo veis, no envía una sola transacción envía más de 30 transacciones pendientes con distintos precios de gas, distintos nonces... Todo esto lo hace para despistar porque realmente la única transacción que va a entrar ahí es la que tiene el nonce correcto.En el ejemplo que os he puesto, en ese momento, la transacción correcta y la que entró fue la cuarta, la que tenía nonce 639. Tuve que modificar mi script para que no pillara la primera transacción que salía de la wallet hackeada. Tenía que tener en cuenta también el nonce correcto. Volví a probar y empecé a ver en los logs que seguía teniendo problemas con el gas. Guerra de gas A partir de este punto me doy cuenta de que tal vez el problema es que no estoy seleccionando correctamente el gas. Básicamente tenemos dos variables con las que podemos enviar una transacción:
Si, ¿adivináis quien estaba haciendo estas transacciones con un coste tan reducido? El bot:  Tiene lógica este comportamiento, gasta el menor gas posible para pagar menos "fees" y robar más cantidad de BNB para su cuenta. Esto además, ofrece una doble ventaja al bot, ya que para un usuario que quiera colocar una transacción por delante de él, siempre competirá en desventaja porque cualquier transacción que no sea envío de BNB cuesta más gas utilizado. La transacción que estaba probando yo, era aprobar un token cualquiera (el típico aprobado que hacéis en Metamask cuando queréis vender un token). El coste de gas mínimo que necesita tu transacción se puede estimar con la función "estimateGas", en concreto, aprobar la venta de un token me costaba un mínimo de 41000 de gas aproximadamente. En resumen, si el bot quería, reduciendo sus beneficios siempre podría colocar su transacción por delante de la mía porque la mía es más cara y él podría pagar siempre más "fees" que yo. Aquí pensé que era jaque mate. Intento de solución 3: adelantar mi transacción al bot A pesar de mi reflexión anterior, no me doy por vencido e intento colocar mi transacción antes que la del bot. En ese momento había descubierto como hacerlo con la función estimateGas. Cuando estimas gas y el nodo no puede estimarlo porque en la wallet no hay BNB da un error. Sin embargo, cuando ya puede estimarlo significa que ya hay BNB en su cuenta y eso me sirve como "marcador" para poder enviar mi transacción en primer lugar a la mempool.  Tras montar esta estrategia recibo todo el rato el siguiente error: Código:
"error":{"code":-32000,"message":"Replacement transaction underpriced"}
Solución 4: definitiva Con todos los intentos que estuve haciendo pude darme cuenta de que el bot modificaba su comportamiento en función de si yo enviaba una transacción a la misma vez que él o no. Si detectaba que en la transacción actual o en transacciones previas había habido competidores, el bot subía el precio del gas de su transacción para vencer a la mía. Sin embargo, si yo lo único que hacía era enviar pequeñas cantidades de BNB a la wallet hackeada y no competía con el bot, este se relajaba y empezaba a bajar su precio del gas. Este comportamiento es inteligente, porque en todo momento lo que busca el bot es maximizar los beneficios y no que se lo coman las comisiones. Los desarrolladores del bot se han movido en una dicotomía: ¿pago más por la transacción para estar seguro de que el que roba el BNB soy yo?, o ¿pago menos por la transacción para robar más BNB arriesgándome a que me coloquen una transacción por delante? Así es como di con la solución, explotando esa dicotomía. Además de aprovecharme de su comportamiento introduje otra variación que hizo que el bot se liara un poco más sobre que precio de gas poner a su transacción. Monté la siguiente estrategia:  1. Vuelvo al esquema donde mi transacción va a ir justo por detrás de la suya (para intentar colocarle una transacción con más gas y que sea la suya la descartada por el nodo) 2. Previamente a mi prueba, envío dos o tres transacciones con muy poco BNB sin competir con su transacción para que reduzca su agresividad. 3. Envío 3 o 4 transacciones con BNB a la vez para causar confusión al bot. 4. Detecto la primera transacción del bot que salga de la wallet hackeada con el nonce correcto y le meto la mía con +1 de gas. ¿Resultado? Tras varias horas de intentos y pagar más de 30 $ en total en pruebas desde mi wallet... Consigo colocar mi transacción de prueba por delante de la suya!. Engaño al bot, cuando envía esa transacción con el nonce correcto se piensa que es la única que va a haber y que no hay nadie compitiendo, además la envía con menos gas del que debería porque han entrado 3 transacciones a la vez con BNB y hay más BNB para llevarse por lo que debería de pagar más gas. Los siguientes pasos ya son más sencillos, realizo dos transacciones: - Una hace el withdraw de los tokens invocando el contrato donde tiene el shur los 1000 $. - Tras llegar los tokens a su wallet comprometida, hago seguido otra transacción para enviarlos a su wallet limpia.  En verde son las transacciones que coloco por delante del bot y la cantidad de tokens que entran y salen de la wallet hackeada. En azul, es la dirección del contrato donde estaban en staking los tokens, en naranja es la wallet hackeada y en morado es la cuenta del shur limpia. Había otras posibles formas de vencer al bot según se describe en la comunidad: 1. Crear un contrato y llamar a la función selfDestruct con la dirección de la wallet comprometida, esto genera una transacción interna con el BNB del contrato y no puede ser detectada en la mempool por el bot. (Esta solución no me gustaba del todo porque el bot vigilaba la wallet del shur llamando a la función balanceOf cada poco tiempo, aparte de vigilar la mempool) 2. Pagar a un minero el gas por otra vía y dejar que el minero ejecute tu transacción sin pagar gas por ella, esta creo que hubiera sido la solución más eficaz. Y por último me gustaría agradecer al shur @Iberia por haber confiado en mí sin conocerme de nada y por haberme devuelto 200 $ como agradecimiento por todo este trabajo. Siempre he pensado que en forocoches hay más gente dispuesta a ayudar que a estafar y de momento creo que no me equivoco. Gracias por leerme y espero que hayáis disfrutado con la historia. Dejo este tweet como recordatorio: |
ForoCoches: Usuario
04-jun-2022 22:34
#41
| Un de los pocos hilos desde que soy miembro de Forocoches que me recuerda por qué me uní a la comunidad |
ForoCoches: Usuario
04-jun-2022 22:52
#42
| Puto amo, que grande shur. Da gusto leer hilos así. 5 estrellas! |
ForoCoches: Usuario
04-jun-2022 23:44
#43
| Y aquí es donde veo algo que ya sabía: no tengo ni puta idea de criptos porque no entiendo nada de la jerga que has usado. |
Podium de los mayores egolatras/prepotentes reconocidos del Hilo :
ForoCoches: Usuario
05-jun-2022 10:24
#51
| El Hacker que programó el Bot es un crack porque está super currado. Pero ¿El Hacker que robó la clave privada y uso el Bot es retrasado porque no se dio cuenta que había pasta Stakeando? |
ForoCoches: Miembro
05-jun-2022 12:29
#53
|
ForoCoches: Usuario
05-jun-2022 13:09
#54
|
Enhorabuena shur, lo tuyo sí que se merece reconocimiento, no solo por conseguirlo, sino por ser una persona decente, con valores e implicada. Tienes mis dieses.
 Además que yo he tenido trato con Iberia en el pasado, y era un buen tipo, no sabía que le había pasado tremenda putada, me alegro por él que haya recuperado algo La idea de abrir este hilo y contar la historia era visiblizar un poco mas que en forocoches no solo hay hilos de shitcoins o de algunos intentando sacar provecho también hay gente que todos los días aporta su granito de arena y sin darse cuenta ayuda mucho a los demás, a mi el primero!. Jajaja sería de justicia hacerlo pero me temo que el ladrón tendrá muy bien custodiadas sus claves, como mucho podrías robar lo que el ladrón roba para dárselo a su legítimo propietario menos el gas que pagas claro... Estupendo shur, recuerdo haber leído el hilo.
Grande @calatras , nuestro experto blockchain forocochero. Te doy un 10 en el hilo.
Y bueno como friki informatico tambien me ha surgido una potencial idea de lo que has construido. Crees que por ejemplo aplicando una lista blanca de direcciones aceptadas y no, se podria utilizar tu script como una medida de seguridad para evitar que se limpien carteras? Algo en plan detectar cuando has sido hackeado asi con tu frase semilla y el script sea capaz de adelantarse a la transaccion maliciosa y volcar tus fondos en una cartera limpia. Ojo que podrias tener tiron por ahi… La mejor medida seguridad es lo que dice el tweet, manten tus claves en secreto y offline. Una vez tienes configurado todo eso ya puedes integrarte con la blockchain para por ejemplo firmar las transacciones que quieras, llamar a la mempool para ver las transacciones pendientes, invocar directamente funciones de los contratos publicados en la blockchain etc... Una cosa que me ocurrió y que me explotó un poco la cabeza cuando me di cuenta es que los tokens no están realmente en tu wallet (salvo BNB), donde están es en el contrato del token en un mapa que relaciona wallet propietaria con tokens que hay. Cuando hacéis una transferencia (que no sea de BNB) lo que ocurre es una llamada a la función transfer del contrato del token donde resta tokens de un propietario y se los suma a otro dentro de ese mapa... pero los tokens como tal nunca salen del contrato son solo apuntes contables en el mapa!. Imáginate entonces ponerte a trackear también si desde esas wallets comprometidas se invocó la función staking de otro contrato y cuando caducan... es muy complicado de saber. Asi que se olvidan y dicen.. ¿quiere el propietario hacer algo con su wallet? Pues envia bnb que ya te lo robo.. es la estrategia mas facil y diría la mas eficaz para el bot. |
ForoCoches: Usuario
05-jun-2022 13:41
#56
| Otro hilo con la explicación de la factura de la luz por favor |
ForoCoches: Usuario
05-jun-2022 13:57
#57
|
Una cosa que me ocurrió y que me explotó un poco la cabeza cuando me di cuenta es que los tokens no están realmente en tu wallet (salvo BNB), donde están es en el contrato del token en un mapa que relaciona wallet propietaria con tokens que hay.
Cuando hacéis una transferencia (que no sea de BNB) lo que ocurre es una llamada a la función transfer del contrato del token donde resta tokens de un propietario y se los suma a otro dentro de ese mapa... pero los tokens como tal nunca salen del contrato son solo apuntes contables en el mapa!. Imáginate entonces ponerte a trackear también si desde esas wallets comprometidas se invocó la función staking de otro contrato y cuando caducan... es muy complicado de saber. Asi que se olvidan y dicen.. ¿quiere el propietario hacer algo con su wallet? Pues envia bnb que ya te lo robo.. es la estrategia mas facil y diría la mas eficaz para el bot. |
