Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/sripwoud/demo-failed-erc20-hack

Example of a (failed) scam ERC20
https://github.com/sripwoud/demo-failed-erc20-hack

erc20 ethereum hack hardhat scam solidity

Last synced: 21 days ago
JSON representation

Example of a (failed) scam ERC20

Awesome Lists containing this project

README

        

# 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](https://github.com/r1oga/demo-failed-erc20-hack/blob/df18ed55e0953f52c2be783e8d311a7d1d9bf3e8/test/scams.js#L44))

## 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`](https://github.com/r1oga/demo-failed-erc20-hack/blob/df18ed55e0953f52c2be783e8d311a7d1d9bf3e8/contracts/Scam2.sol#L11) and [`Scam3.sol`](https://github.com/r1oga/demo-failed-erc20-hack/blob/df18ed55e0953f52c2be783e8d311a7d1d9bf3e8/contracts/Scam3.sol#L12) 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.**

### Tests

```shell
yarn
yarn hardhat test
```