Infiltrating the EVM-III: Unravel the Impact Of Blockchain On Bug Fixing!

Table Of Content


This is the third part in the Infiltrating the EVM series.

Fixing a bug in traditional software development is often likened to solving a difficult puzzle, each presenting its own challenges. This task has always been complex and time-consuming. However, resolving bugs in a blockchain system is even more demanding due to its transparent & permissionless nature and the high stakes involved with users' funds. The intricacies of this task are significant and call for developers to think creatively and critically to come up with a solution. Let's examine these complexities in more detail.

In blockchain, transparency refers to the public availability of the smart contract's code. This unique characteristic enables anyone to review the code, scrutinize its logic, and identify potential bugs or vulnerabilities. The ability to access and examine the code fosters a collaborative environment where developers and security experts can come together to identify and address any issues they discover.

Blockchain systems are designed to be permissionless, meaning anyone can access and interact with the smart contract without requiring approval. This aspect can be both advantageous and challenging for bug fixing. On the one hand, it allows a wide range of white hat security experts to contribute to solving an identified bug while, in the meantime, opening up the possibility of black hat hackers exploiting it.

Bugs in smart contracts can put users' funds at risk. If a vulnerability is exploited, users can suffer financial losses. This factor adds urgency and pressure to fix the bug promptly and effectively to minimize user impact and safeguard the protocol’s reputation.

In this third part of our article series, we infiltrate the Ethereum Virtual Machine with our team of seasoned blockchain security sentinels. Till now, we dove deep into the internals of how a code is executed on the EVM’s world computer, going through the intense environment of a war room where responsible experts take up the duty to handle any and all critical conditions at hand, considering up to hundreds of millions of dollar value at stake.

Cracking The Code: Bug Fixing On Blockchain

Identify and Select a Patch

Once a bug is identified, the development team will work on a fix. The war room engineers at this point in time will;

  • analyze the code (localization/ detection) of the vulnerability,
  • understand the nature of the bug (categorize it in a pre-defined severity), and
  • create a patch or update (formulate a fix) to address the issue.

Let's delve into the various approaches taken to resolve these elusive issues while deploying a bug fix in a mission-critical financial instrument coded in the smart contract on the blockchain.

  1. To identify the bug, refer to the previous article where we discuss the multiple scenarios of how a bug can be identified and fire up a war room where a team of experts treats it as an operation theatre, performing diagnosis and surgery for the exploitable (or already exploited :skull: ) bug.
  2. Once the issue is confirmed, a list containing multiple possible fixes may be devised as a reflex action.
  3. When evaluating fixes from the list above, several factors impact the feasibility of selection, with the nature of the bug being the most critical. However, the bug's severity also plays a significant role in determining the appropriate fix.

At this point, the security partners of the protocol may be consulted to evaluate and finalize the fix as a patch.

  1. Once a bug fix is finalized, we move on to the next phase, executing it as a transaction within the dark forest of the Blockchain.

Implementing the Bug Fix as a Transaction on the Blockchain

The bug fix for the identified vulnerability will be executed as a transaction on the blockchain. This transaction includes relevant information such as the smart contract's address, the function signature to be called with the necessary parameters required for executing the fix, and the values supplied in the function arguments.

When the bug fix transaction is broadcasted on the blockchain, it enters the mempool, awaiting confirmation and validation from the network. At this stage, the transaction becomes visible to all participants on the network. However, the transparency and permissionlessness of blockchain acts as a double-edged sword.

All the while the transaction sits there, ready to be executed, and is visible to the public, the possibility of an attack increases by the passing second. Envision a zero-day at this point and multiply the intensity of damage to the protocol’s reputation by incorporating factors such as the users' funds, the permissionless ness to interact with the smart contract infrastructure, and the transparency, providing ease-of-access to an adversary to understand and grab the problem to turn it around for their own benefit.

Say hello to Front-running

Front-running is a technique where an attacker observes a transaction before it is processed and executes a similar transaction with a higher gas price to ensure it gets prioritized. If the bug fix is not carefully crafted, an attacker may still be able to exploit the identified bug despite the fix attempt by a privileged goodwill user.

A whitehat hacker named @trust__90 found a vulnerability in a protocol that brought risk to almost 100 ETH of users' funds. They tried to execute a white-hat rescue, only to get frontrun on the way and losing about 90% of the funds at risk by some MEV Bots.

Front-running at any cost?

When it comes to web3 security, front-running remains a persistent attack vector that continues to pose a significant threat despite being identified as a vulnerability. This leads us to many of the scenarios where not even bug-fix transitions are secured from it.

From a common person's perspective, front running might involve obstructing or delaying transactions that directly involve money or may have some financial gain in the future. However, there have been instances where even attempts to fix vulnerable code, such as with the SirenMarketV1 protocol, (the exploitable vulnerability could have allowed an attacker to get free leverage) have been front-run to an extent that a new attack vector named, Block-Stuffing Attack was discovered. The attacker provided a large number of high-gas transactions which in the rational environment of a blockchain’s mempool were (and are always) prioritized for the miner’s profit basically stopping the fix to be deployed for almost 30 blocks, hence the 0-day in this case extended by the will of an adversary.

Block stuffing is a technique where an attacker submits tons of transactions with a higher gas fee than an honest user. Miners will fill their blocks with just those transactions until the block gas limit is reached. Hence, an honest user gets completely ignored if they keep following a standard way of executing transactions on the blockchain* aka the public mempool.
(*Hint: Flashbots)

Front-running, is it something new?

Frontrunning refers to the unethical practice in financial markets where a trader or broker uses advanced knowledge about upcoming large buy or sell orders. This occurs when the frontrunner executes their own trades ahead of the client's order, utilizing the imminent price increase or decrease to gain a profit. By front-running, the frontrunner essentially jumps in front of the client's order and capitalizes on the anticipated price movement.

Context: In blockchain networks, transactions are typically held in a mempool, a pool of pending transactions, before being added to blocks through a consensus mechanism like proof-of-work or proof-of-stake. Miners or validators are responsible for selecting transactions from the mempool to include in the next block. Front running in blockchain occurs when a participant, often a watcher, miner, or validator, obtains information about a pending transaction and rapidly executes a competing transaction to capitalize on it. This is commonly done to exploit price fluctuations in DeFi platforms where the order of transactions on the blockchain determines transaction execution.

Unravel the Impact Of Blockchain On Bug Fixing - 02
Credits: Simple Explanation of Front Running by Wes Draper - Source Youtube

Already H4cked -> Negotiations

If an attacker successfully front-runs the bug-fix transaction and exploits the bug, it is crucial to negotiate with the attacker to mitigate the damage and protect users' funds. In such cases, working with experts in the field and involving law enforcement might be necessary to resolve the situation.

Trust Security lays out a standard for the lines of defense in such scenarios where negotiations are inevitable. The main pointers from their piece for the context focus on the fact that “a sophisticated negotiation plan needs to be put in place to prepare for all eventualities.” And that a good strategy must take into consideration the following:

  • “A strong monetary incentive to return the funds or to report the perpetrator.
  • Psychological manipulation of the attacker through carefully constructed clues and bluffs.
  • Setting up OpSec traps for the hacker to trip over.”

Source: Case for the defense

Circuit Breakers: Pause, Emergency, Exits, or actions that fall in the category are components that reduce the potential of overall loss and play n essential role in the line of defense. As stated in the linked article above, we find a relevant fact: “Limited-loss schemes are incredibly powerful because ideally, they are independent of the rest of the functionality.”

User Communications

If the attacker is not caught and the incident passes the initial response period, it is vital to handle the situation transparently. Users should be provided with detailed information about the attack, the bug, and the measures taken to resolve the issue. Additionally, steps should be communicated to prevent similar incidents in the future. Consideration should be given to compensating affected users to restore their trust in the smart contract and the development team.

In a war room, DevSecOps is a crucial part of the team. Their main responsibility is to manage patch transactions while being transparent with the affected community. Transparency is an essential blockchain component; trust cannot be effectively established in the wider blockchain landscape without it. Therefore, it's necessary to replace trustlessness with transparency to ensure confidence in the blockchain.

Disclosure and Post-Mortem Report

After successfully patching the code, it is important to disclose the issue professionally and safely to the user base. A comprehensive post-mortem report should be shared detailing the bug, its impact, the steps taken to address it, and the measures implemented to prevent similar incidents. The team may also consider hiring third-party auditors to conduct regular security audits to minimize the likelihood of future bugs. These steps aim to ensure transparency, accountability, and the protection of users' funds when addressing and fixing bugs in a blockchain system.


Fixing bugs in blockchain systems involves unique considerations due to transparency, permissionlessness, and users' funds at risk. Once a bug is identified, the development team analyzes the code and creates a fix implemented as a transaction on the blockchain. However, the transparent nature of blockchain introduces the risk of front-running, where an attacker exploits the bug fix. Negotiation and collaboration with experts may be necessary in case of exploitation. Transparent handling, user communication, and compensation may be required to restore trust. After patching, a detailed disclosure and post-mortem reports are essential. Regular security audits can help prevent future bugs.

More Audits

Rari Capital Hack Analysis & POC

Rari capital got hacked for around $79M through a classic re-entrancy attack. Rari is a fork of compound finance which had this bug fixed earlier. It is not the first time Rari has been a victim of a hack.

Sonar Bridge Initial Audit

BlockApex (Auditor) was contracted by Sonar(Client) for the purpose of conducting a Smart Contract Audit/Code Review of Sonar bridge modeule.  This document presents the findings of our analysis which took place on 8th September 2021. 

Sonar Bridge V2 Initial Audit

BlockApex (Auditor) was contracted by SONAR (Client) for the purpose of conducting a Smart Contract Audit/Code Review for Sonar Bridge V2. This document presents the findings of our analysis which took place on 28th September 2021.

Harvest Finance Hack Analysis & POC

Harvest finance got hacked for around $34M due to a flashloan attack which manipulated the price in the Curve pool to retrieve more USDT tokens than originally deposited USDT amount in fUSDT pool.

The Big Fuzz Theory: The Dark Fuzz Rises

Learn how Fuzz Driven Development (FDD) transforms software testing by assisting programmers and testers in overcoming prejudices for improved code quality, security, and performance.

The Big Fuzz Theory: Multiverse Of Fuzz Madness

This blog explores the fascinating world of fuzz testing methodologies and frameworks. We delve into stateless and stateful fuzzing. Bounded Model Checking (BMC) is introduced as a technique to verify systems against predefined specifications. Additionally, we discuss the essence of End-to-End (E2E) testing, combining structured scenarios with fuzz testing's unpredictability. Lastly, we compare renowned fuzzing tools, Echidna and Foundry, highlighting their unique features and differences.

Unipilot Final Audit Report

In our first iteration, we found 1 critical-risk issue, 4 high-risk issues, 1 medium-risk, 1 low-risk issue and 1 informatory issue. All these issues were refactored and fixes have been made. A detailed report on the first review can be found here.

BonqDAO - February 3, 2023

The BonqDAO security breach that occurred on February 2, 2023, had far-reaching consequences for the platform, its users, and the wider DeFi ecosystem. The attack exploited a vulnerability in the integration of the Tellor Oracle system, which BonqDAO relied on for obtaining token price information.

Infiltrating the EVM-I: Demystifying Smart Contracts & Auditing

Infiltrating the EVM-I: Demystifying Smart Contracts & Auditing comprises of information about compilation breakdown of solidity code, the vulnerable components of blockchain ecosystem and how Smart contract auditing is crucial.

1 2 3 11
Designed & Developed by: 
All rights reserved. Copyright 2023