Is Dead Code Really Dead?
Introduction
The smart contracts are not immune to vulnerabilities and intricacies that may go unnoticed at first glance. One such enigma lies within the realm of “dead code” or “unused code” — sections of a smart contract that appear dormant and inactive.
In this article, we are going to question: Are the dead code truly lifeless, or do they have the potential to conceal a hidden purpose?
Disclaimer:
The smart contracts in this article are used to demonstrate vulnerability issues only. Some contracts are vulnerable, some are simplified for minimal, some contain malicious code. Hence, do not use the source code in this article in your production.
Nonetheless, feel free to contact Valix Consulting for your smart contract consulting and auditing services.🕵
Explore The Smart Contract 👀
The Vault contract allows users to deposit and withdraw funds and it includes the internal _withdrawAllfunction that appears to be unused as there are no external functions in this Vaultcontract calls to it.
Alright, let’s put on our detective hats and investigate this contract! 🕵️
It seems like the Vault contract has some sneaky stuff going on.
It seems that the _withdrawAll function is the dead code within this contract, as it is never executed on the Vault contract.
BUT, Is this dead code really dead? 🤔
The Vault contract is designed in a way that allows it to be upgradeable according to its implementation.
This feature allows the contract owner to improve the functionality by upgrading the implementation code and introducing new logic that can potentially call the internal _withdrawAll function.
Thus, it could be the FAKE dead code.
More about the upgradeable contract, check this out: https://ethereum.org/en/developers/docs/smart-contracts/upgrading/
Explore The Scenario 🧑🏻💻
The Scenario
Let us explore the following scenario: Suppose the Vault contract is designed to be upgradeable. Now, let’s imagine a moment in time when the owner decides to upgrade it to version 2.
The following contract is the VaultV2 contract that is version 2 of the Vault contract above, it introduces the new externalwithdrawAllfunction (lines 33–35) to call the _withdrawAll function.
Consequently, the new logic enables the contract owner to effectively deplete all the funds stored within the contract.
Proof It Together
In the snapshot below, the owner cannot execute the _withdrawAll function in the first version of the vault.
However, in version 2, they gain this capability, as demonstrated below.
After the owner upgrades the implementation to version 2, they gain the ability to deplete all the deposited funds of the users.
Challenge for the Curious:
Can you uncover the dead code in the VaultV2 contract? 😼
Summary
It is important to take a close look at the code in the contract, especially parts that don’t seem to be used. If it is sure that this code is never used, let us think about why it is still there.
Author Details
Parichaya Thanawuthikrai, Senior Blockchain Security Auditor and Consultant.
About Valix Consulting
Valix Consulting is a blockchain and smart contract security firm offering a wide range of cybersecurity consulting services. Our specialists, combined with technical expertise, industry knowledge, and support staff, strive to deliver consistently superior quality services.
For any business inquiries, please contact us via Twitter, Facebook, or info@valix.io.
