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!

In Solidity smart contract, there are two ways opcodes that can deploy contracts: CREATE and CREATE2. CREATE uses the addresses incrementing nonce in order to determine the address. CREATE2 takes in a user controlled value in order to determine where to place the contract.

A network reorganization is when the blockchain ordering has changed somehow. This happens in a few cases:

• Network lag
• A fork of the chain
• Malicious actor messing with the system

The smart contract being tested had functionality that would deploy a smart contract called a Quest when called. This contract used the CREATE in order to send this transaction.

The author of this finding (solo medium severity finding) brings up a scenario with reordering and deterministic creation of a smart contract. A user may have a local script to create the quest that waits for the success to occur. After this succeeds, this would send funds to the contract.

What if a reorganization occurred at this moment? A malicious actor could create the quest first! Then, the quest they created would be at a different location and their reassurance of the address would be gone. This means that the user would send their funds to the wrong contract.

The author mentions that a user may try to predict the contract address and send the funds there. If this is true, then a simple frontrunning attack would work on them as well.

The solution to this issue is to use the CREATE2 opcode instead. Overall, a weird finding that I'm sure could be reported more.