Unable to replicate short-address attack

Question

I was reading about the short address attack and decided to replicate and test the possible solutions.

What I know about short address attack is if you skip n characters of your address, you end up supplying 68-(n/2) bytes to your transfer function and the evm appends zeros to makes if 68 bytes. And the end result is your value changes by n<<8. This was just a high-level overview.

Now I trid to test the same with a test toke (with decimal places =2) . The transfer function of the contract goes by:

 function transfer(address _to, uint256 _value) {
        require (balanceOf[msg.sender] > _value) ;
        require (balanceOf[_to] + _value > balanceOf[_to]);
        balanceOf[msg.sender] -= _value;
        balanceOf[_to] += _value;
        Transfer(msg.sender, _to, _value);                                  
    }

I used remix connected to my private test-net to check for this attack.

I had an address 0x7ecd024742458287b9cd97015ff265d04a316f20. I called the transfer function of contract with arguments:

transfer("0x7ecd024742458287b9cd97015ff265d04a316f2", 1);

As per my understanding, I was expecting the supplied address will get 256 coins (if short address attack is replicated). But instead I got the error:

transact to browser/TestShortAddAttack.sol:MyToken.transfer errored: Gas required exceeds block gas limit: 6000000. An important gas estimation might also be the sign of a problem in the contract code. Please check loops and be sure you did not sent value to a non payable function (that's also the reason of strong gas estimation).

Why is the transaction consuming this much gas? Is this issue has been taken care by evm or we need to implement the check (Checking length of msg.data)?

Answer 1

I tried to replicate as well. I, however, did not get the error you did, but neither did I get a perfect replica of the attack. I have an implementation the safemath library, but elseway as yours.

function transfer(address _to, uint _amount) public returns (bool success){
    balances[msg.sender] = balances[msg.sender].sub(_amount);
    balances[_to] = balances[_to].add(_amount);
    Transfer(msg.sender,_to,_amount);
    return true;
}

I tried using the address:

0xe9f341c1b12912b1594afa3885c873c91ec66920

If I run the transfer as I normally would

transfer("0xe9f341c1b12912b1594afa3885c873c91ec66920",1);

I would get

0x40c10f19000000000000000000000000e9f341c1b12912b1594afa3885c873c91ec669200000000000000000000000000000000000000000000000000000000000000064

as the input of the signed transaction. If I instead used the shortened address

transfer("0xe9f341c1b12912b1594afa3885c873c91ec6692",1);

I would get

0x40c10f190000000000000000000000000e9f341c1b12912b1594afa3885c873c91ec66920000000000000000000000000000000000000000000000000000000000000064

Padding the input with a zero, but as the header of the address, and not behind as intended. This would simply transfer the funds to an address to which I do not have access.

Did you find a way to replicate the attack?