As always, you can find the full source code for this challenge below on Github.

https://github.com/imam-abbudi/ethernaut-web3py-solutions/tree/main/coinflip

You’re going to want to download the challenge’s source code locally for this one, keep a folder that looks something like this:

coinflip/
|_ Coinflip.sol
|_ CoinflipExploit.sol
|_ coinflip.py

And yes, we are going to be writing the exploit in Solidity.

coinflip.sol

This file should include the source code, like this. Reading through the code, we can see that it reads the block hash of the previous block, divides it by FACTOR, and checks if the division is equals to 1. That’s how it picks the side of the coin.

It is important to note that we can’t just guess the same side ten times in a row in the same block. Because the contract will revert if it notices the same blockValue is generated twice.

coinflipExploit.sol

We can create an interface with the Ethernaut’s challenge by importing the source code, and entering the challenge instance’s address in the constructor when we deploy the contract.

The function flipGuess() has the exact same logic as the challenge, and since the two contracts are running on the same network, blockValue will be the same value for both contracts. Since we already know FACTOR, we can directly import it as it doesn’t change values.

If someone were to call flipGuess(), it would create all the variables, and call the challenge contract’s flip() function with the correct side. Now we just have to write a Python script to call our flipGuess() function 10 blocks in a row.

coinflip.py

As always we’ll import the necessary modules and variables.

We’ll also need to deploy our contract for this challenge. To do this, we’ll need to get both the ABI and bytecode from our exploit script.

A quick reminder:

ABI: An interface to interact with deployed Solidity contracts on the Ethereum network.

Bytecode: The compiled version of our Solidity program, designed for computers to read instructions rather than humans.

This function will read our exploit contract, and return a tuple of both the ABI and bytecode. We will use both of these variables when deploying our contract.

We’ll also use this function from previous challenges, it will sign the transaction we want and return the receipt.

Moving onto our main function, we will first save our ABI and bytecode from our exploit contract, build our transaction by supplying gas and its price, and deploy the contract.

In the constructor of our exploit contract, we will pass in the address of the Ethernaut challenge instance, which will let our exploit contract know which contract address to attack.

Using the receipt of the exploit contract deployment transaction, we can print the address of our contract if it was deployed successfully, or exit if the transaction failed.

If it was successfully deployed, we’ll use the contract address and the ABI we generated at the top of our main function to create an instance.

We will also keep track of there number of correct guesses in correct_guesses. In the while loop, we call our exploit function. If the transaction goes through, we assume the guess is correct and increment correct_guesses by one.

Once we reach 10 guesses, we print a completion message and exit the program. The challenge is now complete, and you can try submitting on Ethernaut.

Note: You could also call the number of correct guesses from the Ethernaut instance itself, but I found that the guesses are always right so it makes more sense to keep a local track of the correct guesses.

Clear conditions:

• Claim ownership of the contract

Take a read of the contract yourself, and see if anything stands out already.

The constructor is a function! Even though it is labelled as a constructor by the author’s comment.

This means that anyone can call Fal1out() and claim ownership of the contract.

Let’s first import modules we’ll need as well as read required environment variables.

We’ll also reuse the functions we made in the previous challenge. The first function returns a contract object to allow us to interact with the challenge instance, and the second signs a transaction and returns its receipt.

If you want to learn how these functions work in greater detail, you can read the Fallback writeup:

https://mirror.xyz/0x9C6D113a0Eafcfe3BcEbF25b0CD0F77778EeB851/TibBVMl7Bb7ZEf8UVyo_4HrjcE-t01fxxZRibzOTxX0

Now it’s as simple as creating the contract object, calling Fal1out(), and checking if the transaction succeeded or not.

Moral of the story: Don’t trust developer comments, the code may behave differently than the developer intends.

If you want to read the full Python code, you can find it here:

https://github.com/imam-abbudi/ethernaut-web3py-solutions/blob/main/fallout/fallout.py

Clear conditions:

• Become the owner of the contract.

• Empty all ether from the contract.

Let’s first run through the code…

First, notice the two variables:

contributions: A mapping keeping track of how much wei an address contributed.

owner: A single address that can withdraw funds from the contract.

The constructor then sets up the scenario for this challenge, the owner of the contract is now Ethernaut who has 1000 ether in contributions.

Looking at the rest of the code, two functions stand out in particular.

contribute()

This function will revert if we contribute an amount over 0.001 ether, and we can only become the owner of the contract if we donate 1000 ether through this function.

So let’s look for another way.

receive()

If you are unfamiliar with what receive() is, it is basically the fallback function of this contract. What this means is that if you send a transaction to this contract with empty calldata, the transaction will end up triggering the receive() function instead.

calldata: Raw hexadecimal bytes sent with a transaction that specifies which external contract function you want to call, along with what parameters.

With the basics out of the way, we notice that the receive function requires us to send some amount of money (obviously), and have some amount of a contribution.

If we fulfill both of these requirements, we can be assigned as the owner of the contract.

We can then use our ownership to empty the ether in the contract by calling withdraw().

The attack

Now we know we first need a contribution to become the owner of the contract, let’s write a Python3 script named "fallback.py” that will:

1. Contribute 1 wei.

2. Send a transaction with no calldata.

3. Call the withdraw() function, emptying the contract.

Imports

We will only need these four modules for this challenge. Make sure to load_dotenv() before doing anything else, because we will need to import some variables from env soon.

web3 to interact with the Sepolia network.

solcx to compile the Ethernaut contract and get the ABI needed to interact with the contract.

dotenv & os to read environment variables.

You can then load your private key, address, and provider like so.

Function -- read_contract_return_abi()

This function will read “fallback.sol“ that exists in the same directory as our python script. In the file, we can copy the Fallback contract’s source code from Ethernaut.

The function above first opens “fallback.sol“, installs solidity 0.8.0 and compiles the contract using the source code.

Then, we get the ABI, which will allow us to encode/decode function calls. Without it, we wouldn’t be able to interact with the contract.

Finally, we return the contract object, which gives us an easy interface to encode function calls when interacting with the contract on Sepolia.

Function -- sign_and_send_transaction()

This function will allow us to sign the transactions we’ll need to exploit the contract.

We sign the transaction we want to send using our private key and store it in signed_tx, then get the receipt using the transaction hash, which allows us to look at details of our transactions, like if the transaction failed or not.

Attack

We’ll now work on our main function, where we can now exploit the contract.

At the top of the main function is where we specify the gas and gas price we’ll use to send all of our transactions. web3.py does have modules to estimate how much gas a future transaction will use. But, I found that my transactions usually ran out of gas, so I’m using 50,000 gas at 5 gwei.

Then we contribute to the contract, and save the receipt to analyze our transaction.

Now we’ll check how much we contributed by calling contributions() with our address and save it in contribution. This is to make sure we actually contributed some amount to the contract.

If we contributed successfully, we send the transaction with no calldata, then attempt to withdraw. The script will print a success message if the withdrawal worked, and the program will exit. Then submit your instance on Ethernaut and you’re done!

If you want to see the full code for this challenge, you can find it here:

https://github.com/imam-abbudi/ethernaut-web3py-solutions/blob/main/fallback/fallback.py