Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

This is a classic horror story on MEV bots in Ethereum. Read at your own discretion (and craziness).

While on Discord, the author of this post received a question on Uniswap: "is it possible to recover the LP tokens that are sent to the pair contract itself?" Initially, they thought no but it's recoverable - by anyone!

When somebody calls the burn function on the Uniswap core contract, the contract measures its own LP balance and burns it. Then, the withdrawn tokens are outputted to the caller of the function. Within the contract was 12K worth of liquidity tokens just waiting for somebody to take it. This is a ticking time bomb, since anybody could burn their LP tokens and accidentally receive the funds.

There is a pros and a cons to the decentralized nature of blockchain. One of these cons is that if there is a contract that can be exploited for a profit, then it will be; this is a battlefield. However, this isn't even close to how bad the mempool is, where unconfirmed/pending transactions lay. If the chain is a battle ground, the mempool is the much worse dark forest.

The mempool is filled with bots that exploit the ordering of transactions currently in the mempool in order to turn a profit. This is why recovering the funds is a complicated task! If a bot sees what we're trying to do, they frontrun the swap and use their own address to receive the money instead.

The name of the game here is obfuscation. We need to make the call to the contract without the bots being able to detect the pattern. Their obfuscation plan was to use two separate calls: a getter and a setter contract that will make these calls instead of a call from an EOA. This way, a simple modification to the transaction wouldn't be possible to perform.

Their hope was to deploy these contracts in the same block but separate transactions. If an attacker only executed the get, then the contract would revert. The thought was that by the time the set and get had both been executed, the bot wouldn't know what hit them.

When trying the recovery, the get call was rejected by Infura even with manual gas overrides. Oh gosh... this means that the set had been done and the get was getting ready to go. The transaction slipped into the next block... they got a INSUFFICIENT_LIQUIDITY_BURNED error from Uniswap, meaning that somebody had performed the call and stolen the funds.

What can we take away from this?

• The monsters are real. Their are real generalized frontrunning bots out in the world who will steal funds.
• Don't get sloppy. Have a plan and execute it.
• Don't rely on normal infrastructure. The reason the getfailed was because it should have failed for the current blockchain state but not what they were updating it with. Or, know a private miner.

Overall, an extremely scary situation that's only going to get worse over time. The mempool is the reason for this unique bug class being possible. A product called VeeDo from Starkware has created a Verifiable Deploy Function to make Ethereum applications immune to these types of attacks.