Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Buffer overflow to C is Reentrancy to Solidity. Reentrancy attacks are when a user can reenter code in an unintended state in order to manipulate the system somehow. For instance, while withdrawing tokens, the money may be sent but the state variable is not updated. With the money sending call, we could reenter the contract to withdraw the funds again.

The solution to this problem is using reentrancy guards. On functions in Solidity, modifiers can be provided to ensure that the code cannot be reentered. Although this works well for a single contract, what about multiple? Doesn't work so well. Another smart contract may use a state variable (well, gathered via a function...) while it sits in an unintended state.

The author of this post described a system for cross contract reentrancy protection that they implemented in Volt: Global Reentrancy Lock. There are two components to it. First, a global smart contract that holds the state of the locking and unlocking. Second, a modifier for every state-changing function on the other contracts.

So, locked or not locked, right? The author took this a step further with multiple lock levels. For instance, there is a outer level, inner level and a second inner level. By doing this, it prevents functions being accessed while in weird state.

As an example, the authors mention an AMM that has deposits in several locations. While trading with the service, they would not be able to move assets from a different module. Additionally, they should not be able to trade with other AMMs while a trade is in progress. These both could be at a lock level!

The code is a good way forward for reentrancy security. It was tested heavily with Foundry invariant/unit testing, Echidna symbolic execution, and hevm execution. The implementation relies on the lock numbers being implemented properly by the developers and ensuring that the modifiers are properly added.

This seems like an interesting vector for denial of service as well. There may be unexpected code paths that revert because of a weird entry point. Additionally, it doesn't solve the problem of read-only reentrancy as well, assuming these are only put on modifying code snippets.