# One more problem with ERC777

Recently, while working with one of our clients, we discovered an intriguing bug that could potentially serve as an attack vector for some DeFi projects. This bug is specifically associated with the well-known ERC777 token standard. Furthermore, it is not just simple reentrancy commonly observed in well-known hacks.


This article provides a comprehensive explanation of ERC777, covering all the necessary details. There is a scarcity of resources that delve into the specifics of ERC777 tokens, making this article a valuable and detailed guide for individuals interested in gaining in-depth knowledge about this token type.

In the final part of the article, we will explain our recent finding.

# The attack vector in short

This bug takes advantage of the ERC777 feature that enables setting a hook receiver. By exploiting the ability to make arbitrary calls in a target contract, a malicious caller can call the ERC777 registry contract and assign a specific hook address to the target contract. As a result, whenever the target contract receives ERC777 tokens in the future, the attacker's hook smart contract will be triggered. This hook can be utilized in various ways: either for reentrancy attacks to steal tokens or just to revert, thereby preventing the target contract from sending or receiving ERC777 tokens.

# ERC777 and its hooks

## What is ERC777

ERC777 is one of the token standards with hooks on transfers.
Described here:
https://eips.ethereum.org/EIPS/eip-777

The primary motivation behind implementing ERC777 tokens lies in their ability to mimic the behavior of native token transfers. By triggering smart contracts upon token reception, developers can execute specific logic to enhance functionality and create more dynamic token interactions.

However, these additional calls during transfers set ERC777 apart from ERC20 tokens. These hooks introduce a new attack vector that can potentially affect smart contracts that are not designed to handle additional calls during token transfers. This unexpected behavior can pose a security risk to such contracts.

Here is the list of some ERC777 tokens on the Ethereum mainnet with some liquidity:

VRA
https://etherscan.io/address/0xf411903cbc70a74d22900a5de66a2dda66507255
AMP
https://etherscan.io/address/0xff20817765cb7f73d4bde2e66e067e58d11095c2
LUKSO
https://etherscan.io/address/0xa8b919680258d369114910511cc87595aec0be6d
SKL
https://etherscan.io/address/0x00c83aecc790e8a4453e5dd3b0b4b3680501a7a7
imBTC
https://etherscan.io/address/0x3212b29e33587a00fb1c83346f5dbfa69a458923
CWEB
https://etherscan.io/address/0x505b5eda5e25a67e1c24a2bf1a527ed9eb88bf04
FLUX
https://etherscan.io/address/0x469eda64aed3a3ad6f868c44564291aa415cb1d9

## When hooks happen

ERC20 tokens just update balances during transfers.
But ERC777 tokens do this way:
1) Make a hook call to an address chosen by the token sender
2) Update balances
3) Make a hook call to an address chosen by the token receiver

It is well illustrated in the VRA token:
Source: https://etherscan.io/address/0xf411903cbc70a74d22900a5de66a2dda66507255

Now, let's examine the code responsible for these calls.

As you can see this function:
1) reads so-called `implementer` from `_ERC1820_REGISTRY`
2) if the function finds an implementer, such implementer is called

Let´s investigate this Registry and find out what implementers are.

## Registry and implementers

All ERC777 tokens are linked to the Registry contract:
https://etherscan.io/address/0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24

This address is used by ERC777 tokens to store preferred hook receivers. These preferred hook receivers are called "interface implementers".

It means that Alice can choose Bob as her interface implementer. Bob will receive hooks if Alice receives or send ERC777 tokens.

Alice can manage different hook types. So she can choose Bob as an interface implementer only when Alice sends tokens and choose Tom only when Alice receives tokens.
In the majority of cases, she can also choose different interface implementers for different tokens.

These preferrences are stored in the Registry in this mapping:
`_interfaceHash` is an identification of an event Alice chooses an interface implementer for.

And anyone can read Alice interface implementers using this function:

As you can see this is the function we met previously in the VRA code.
Variable `_TOKENS_SENDER_INTERFACE_HASH` is used as `_interfaceHash`, which can be any bytes. But VRA token uses these bytes to identify this type of hook:

## How to start receiving hooks

In order to choose a hook receiver, Alice just should call this function on the Registry and input Bob address as `_implementer` input.
She also has to specify an `_interfaceHash`. Let´s imagine she takes `_TOKENS_SENDER_INTERFACE_HASH` from VRA tokens.

One more important detail.

After setting the implementer for VRA above, Alice will realize that Bob receives calls even if other ERC777 tokens are transferred.
Like imBTC:
https://etherscan.io/address/0x3212b29e33587a00fb1c83346f5dbfa69a458923
imBTC has the same `_interfaceHash` on tokens sent.

This is because all ERC777 tokens share the same Registry address to store hook preferrences. But it is the deal for ERC777 tokens to specify names for their hooks. And sometimes they are similar, but not always.

## How to find ERC777 tokens

The Registry is something that is similar to all ERC777 tokens.
So we can try dune.com to receive all smart contracts that call the Registry.
We can use this SQL script. In fact, we should additionally filter that addresses are tokens but at least we have a perfect start that resulted in 78 addresses.

## Is this Registry the only one possible?

In theory, no one can guarantee that some token uses exactly this 0x1820 contract as a Registry.

But we can check it with dune.com

It returns these addresses

0x1820a4b7618bde71dce8cdc73aab6c95905fad24
0xc0ce3461c92d95b4e1d3abeb5c9d378b1e418030
0x820c4597fc3e4193282576750ea4fcfe34ddf0a7

We checked that 0x1820 is the only Registry with valuable ERC777 tokens. Other Registries have not-so-liquid tokens.

## The wider picture of hookable tokens

ERC777 is not only standard with hooks.

As the first step, you can read about ERC223, ERC995, or ERC667.
They are not so exotic. You must have heard of LINK token which implements ERC667.
https://etherscan.io/token/0x514910771af9ca656af840dff83e8264ecf986ca

# The attack vector with arbitrary calls

This is the attack vector we recently found for our client.

Researchers usually think that ERC777 tokens make calls to token senders and receivers. But we described above that this is the myth - senders and receivers can choose any "Bob" as hook receivers.

So, imagine a target smart contract that allows making arbitrary calls to any address with any data.

Such functions can exist in DEX aggregators (like 1inch), wallets, multicall contracts.

The attack:
1) Attacker finds a function in Target that allows arbitrary calls
2) Attacker makes Target call:
`registy1820.setInterfaceImplementer(Target, hookHash, Attacker)`
3) Now our Attacker is an implementer for Target
4) Attacker can call with every `hookHash` used in major ERC777 tokens
5) Every time Target receives an ERC777 token, Attacker receives a hook call
6) Following attack is different depending on the target code:
- Attacker can reenter when some user executes a function in the target contract
- Attacker can just revert, so that user transactions are just reverted

DEX aggregators may experience problems if they calculate that the optimal swap path lies through some DEX pair with some ERC777 token.

## Protection

After hours of discussion with our client, we found a solution that still does not break arbitrary calls.

Projects are better to restrict choosing Registry1820 as an address for arbitrary calls. As a result, no attacker is able to choose interface implementers.

# Takeaways

Projects and auditors must be aware of the described hook behavior in ERC777. These tokens make calls not only to receivers and senders but also to some other hook recipients.
In this sense projects allowing arbitrary calls must pay special attention and be aware of one more attack vector with ERC777.