Replay Mirror Attacks

Replay Mirror Attacks
Photo by Tuva Mathilde Løland / Unsplash

DeFi is an ever-growing market, and apart from everybody wanting to have a piece of multi-billion dollar industry, there are chains and copycats of protocols found originally on Ethereum.

Some of those copycats grew into their respective applications, but also it meant, we have multiple chains we can deploy the same code. I'm talking about BSC and Polygon, which use EVM at their core. One protocol's success automatically means X copies of that application deployed onto various EVM-based chains with high hopes of gathering money.

The morality of this is none. Many of the original DeFi projects have put a lot of time into building an app today just to have some copycats fork the code and make some changes they don't understand or live it as it is. An issue arises if the original code had a logic flaw that was exploited. This exploit propagates automatically onto all forked projects.

We saw a high influx of attacks on multiple chains in recent weeks, and multiple protocols were hacked with copies of exploits from different hacks. A recent addition is PancakeBunny. I won't go into details. Please read this article by

Rekt - PancakeBunny - REKT 2
DeFi / Crypto - Two months ago PancakeBunny got rekt on BSC, now the same thing has happened on Polygon. $2.4 million lost. How earitating.

What is important in this case is the hack that happened two days before this one. ApeRocketFi was hacked, which is an exact fork of PancakeBunny. We don't know if the attackers were testing the exploit on a smaller project or somebody else noticed the same bug in the original codebase, but this raises an important point.

I've spoken many times about developers responsibilities of their code. It's important to audit your code, but it's more important to maintain it afterward. Audits are not silver bullets. They won't provide 100% of security and protect you from the mistakes you made or will make.

"If you decide to fork from a project that has a known vulnerability or it was disclosed or hacked after you forked, you have an obligation to patch the code. You have the responsibility to follow closely if any exploits happened to the code you forked. You should be monitoring the situation closely."

I think this ☝️ is more relevant now than ever. Especially if code can be forked and deployed onto many different chains, heck, even the same protocol can be deployed onto other chains and have the same issues. Just look at PancakeBunny.

No matter the size of the project or your TVL, security should be the number one focus. You're dealing with people's money and hearing about many hacks happening left and right nowadays. You should stay vigilant. Add constantly new test cases and test scenarios. Keep up to date with the latest hacks and check if your application is vulnerable to the same exploit.

Your work doesn't end when you deploy to the mainnet. It only begins.

Thanks for reading, and if you like my writing, you can subscribe to my blog to receive the daily newsletter as I'm currently in the middle of 100 days of blogging challenge. Subscription box below 👇

If the newsletter is not your thing, check out my Twitter @adrianhetman, where I post and share exciting news from the Blockchain world and security.

See you tomorrow!