Failed ERC20 hack Demo

Unknown ERC20 contracts can potentially perform any actions within function that match the standard ERC20 interface (ABI).

Scam 1

A common source of hack comes from the use of delegatecalls that allow a target contract (the one we "delegate" to), to execute in the caller's context and especially modifies its storage.

One could then think that it is possible for a contract to hide an approve within another by:

deploying a scam ERC20 that matches the standard ABI
overriding the approve function and delegatecall (to forward the right `msg.sender``) to a victim ERC20 contract to approve it

This doesn't work as the allowances in the caller contract (the scam contract) will be modified instead of the victim's. So the hack will have no effect. (See test case)

Scam 2 - Scam 3

Performing native ETH send/transfer within other functions calls. This doesn't work either. It is not possible to override nonpayable (defined in the parent contract without payable) functions with the payable modifier. The solidity contracts won't compile.

Try uncommenting the transfer function in Scam2.sol and Scam3.sol and run yarn hardhat compile. It will fail with errors like:

TypeError: Overriding function changes state mutability from "nonpayable" to "payable".

Scam 4 - forcing out of gas error

Possible. But is not benefiting anyone. Not even the person who deployed the scam contract...

Scam 5 - stealing ETH within a token transfer

Hide an ETH send in a token transfer. The function signature is still compliant to the standard: transfer(address to, uint256 amount), but the function is made payable. So it is possible to steal ETH provided there is ETH value sent when broadcasting the tx. Otherwise there is nothing to steal. Who builds the tx controls whether ETH is send or not.