You can find the code here.

Let’s begin.

Backdoor

This took me a long time to solve, the main reason being unfamiliarity with the GnosisSafe contracts. So don't take this explanation as a fact. It did involve a lot of trial and error, and maybe luck was a key factor.

First things first - the challenge consists of 4 users that upon creating a GnosisSafe wallet according to the WalletRegistry specifications will receive 10 DVT tokens. Our goal is to steal them all in one transaction. This is our first clue, we will need a smart contract to do the dirty work.

Since I did not know the GnosisSafe contracts, I started by checking the setup for this challenge. Unexpectedly, it is quite easy. There are four contracts: WalletRegistry, GnosisSafeProxyFactory aka walletFactory, GnosisSafe aka masterCopy, and the DamnValuableToken contract. We also know who the allowed users are.

Next, I decided to look through the contracts. GnosisSafeProxyFactory and GnosisSafe contracts do not contain code exploits as far as I can tell. WalletRegistry was the only contract left to check, and after spending more time than I care to admit looking for code exploits, I couldn't find one in this contract either.

Not sure what to do, I decided to list what I found out while looking through the contracts:

1. We know that WalletRegistry is the contract that has the tokens, so we'll have to execute the proxyCreated(...) function to get them;

2. The proxyCreated(...) function makes sure that the wallet was created using the GnosisSafe setup(...) function;

3. To execute the proxyCreated(...) function we have to create the wallet using GnosisSafeProxyFactory createProxyWithCallback(...) function;

I decided to take a deeper look at the createProxyWithCallback(...) function, which has to be executed first. According to the comments, createProxyWithCallback(...) allows us to create a new GnosisSafeProxy and call it after it is initialized. It also allows us to call a specified callback function afterward.

From that, I assumed two things: the callback must be the WalletRegistry proxyCreated(...) function and that this is how we reach the GnosisSafe setup(...) function.

After making the above assumptions, I decided to look at the setup(...) function. I noticed two more things: some parameters weren't important and it also allows us to perform a delegatecall to a specified address.

This looked promising. If I'm able to successfully pass the verifications on the WalletRegistry proxyCreated(...) function, I can then execute a callback defined by me on the proxy itself, which by now will have the 10 DVT according to the WalletRegistry proxyCreated(...) function.

All that was left was implementing the contract. Most of it was pretty easy, but I was having trouble making a correct call to the setup(...). The initializer variable passed to the createProxyWithCallback(...) must contain the setup(...) function selector and parameters. Most of it can be ignored, but I was also ignoring the threshold parameter - which was a mistake. The proxyCreated(...) callback verifies that, so don't make the same mistake as I did.

I realize that this isn't a very clear explanation. It might even contain errors. But it was most of my thought process until finally reaching a solution. I rather find a solution myself even if it involves luck and trial and error than simply copy someone else's. Besides, after solving this I looked online for explanations and couldn't find much better explanations. I did find contract improvements though, so there's that.

Climber

he goal of this challenge is clearly stated: steal 10 million DVT from the ClimberVault contract.

We are also given a couple of extra hints:

1. The ClimberVault is upgradeable, following the UUPS pattern;

2. ClimberVault has the role of Sweeper which can sweep all funds from the vault;

3. The owner of ClimberVault is the ClimberTimelock contract;

4. The ClimberTimelock contract can withdraw a limited amount of tokens from the vault every 15 days;

5. The ClimberTimelock contract allows accounts with the Proposer role to schedule actions that will be executed 1 hour later;

Since we are given so much information, I instantly assumed this would be a tough challenge.

First I used my very limited knowledge of the UUPS pattern to look for a pattern error in the ClimberVault contract. However, it does have an empty constructor and instead is initialized by a initialize function. This is not the way in.

I then tried to find a way to get the Sweeper role. I couldn't find any. If you can, let me know.

However, while looking through the ClimberTimelock contract, I did notice that it has the role of Admin of itself, meaning it can grant the roles defined. I also noticed that anyone can call execute() to execute a proposal, as long as it has been scheduled. This function contains an enormous error, it only checks that a given proposal was ready for execution after executing it!

This is the point at which I knew I was onto something. Theoretically, we could create a contract to execute a proposal that grants itself the Proposer role and transfers the ownership of the ClimberVault to an account controlled by us. After that, it would be a simple matter of creating a new ClimberVault that allows us to call the sweepFunds() function, and upgrading the proxy to use our new ClimberVault.

While implementing the proposal I forgot one thing: we know from the challenge description that the delay to execute a proposal is 1 hour. Fortunately, we can just set it to 0 without any issue.

Also, don't forget that even though the checks-effects-interaction pattern is violated, the ClimberTimelock does check that the proposal is ready to be executed, so we'll have to schedule it otherwise it will revert and the attack won't work. Plus, the proposal can't call the schedule() function itself because the parameters won't match. So, we need to set a task that calls a function in our attacker contract that schedules the task, which will work because we already have the Proposer role.

So, to recap:

1. Implement a ClimberVault version that allows us to call the sweepFunds() function;

2. Create a contract that executes a proposal with the following tasks:

   • Set the delay to 0;

   • Grant the contract the proposer role;

   • Transfer the ownership of the vault to our attacker account;

   • Schedule the proposal;

3. Execute the proposal;

4. Update the proxy to use our ClimberVault

5. Sweep the funds;

Safe Miners

This is not an explanation of the solution, this is an unfiltered account of how I reached a solution. This is because I don't really understand this challenge. Then again, even the challenge description says it will be modified for a future version of damnvulnerabledefi.

With that caveat, let me explain how I reached a solution.

From the description, I immediately assumed I had to deploy a contract using the attacker to the specified address, because it clearly says that the address that has the tokens is empty.

My first instinct was to use CREATE2, but then it occurred to me it probably would take eternities to find the correct salt to get that same address.

So I decided to try brute forcing it first using CREATE, since paying for gas is not a concern in this scenario.

My first attempt consisted of having the attacker deploy 100k contracts that just transferred the DVT tokens to the attacker. Not only did this take a long time, but it also didn't work.

Since I am not sure how hardhat deploys contracts, I decided to give it another shot using a SafeMinersAttackerFactory to deploy the SafeMinersAttacker before giving up.

At first, I tried having the factory deploy 1000 instances of the attacker until the attacker account had the tokens. This ran into an out-of-gas error because I, naively, forgot that there's a limit to the gas I can send to the contract.

So I decided to modify how this would work. The attacker account would deploy a SafeMinersAttackerFactory that would create 500 instances of the SafeMinersAttacker. Then, if the attacker had the tokens, I would stop, otherwise, I would have the attacker deploy another factory.

I was expecting this to run for a while, but since I had to leave my computer at the time it was cool. If it didn't work, I would know brute force was the wrong approach. To my surprise, it worked on the second batch of 500 SafeMinersAttacker deployments.

You can find the code here.

Let’s begin.

Selfie

As per usual, this challenge involves a pool providing flash loans of 1.5 million DVT tokens. Our goal is to take them all.

Fortunately, we can immediately see that the pool has a drainAllFunds(...) function, which sends all pool DVT tokens to the address passed as a parameter. Unfortunately for us, it can only be called by governance.

SelfiePool is the first flash loan provider that has a governance mechanism attached to it, which, as stated in the challenge description, will be our way in. Looking into it we see that the SimpleGovernance contract allows for actions to be queued, provided they have enough votes. _hasEnoughVotes() checks that the msg.sender DVT balance is higher than half of the pool token balance.

SelfiePool also allows for an action to be executed, provided it has never been executed before and two days have passed since being queued. During a given action execution, the action.receiver will be called using the action.data and action.weiAmount as the call function parameters.

While looking through the SimpleGovernance contract, you'll hopefully have noticed that there are practically no access control mechanisms in place. This means that, as long as we can bypass queueAction(...) and executeAction(...) verifications, we are able to queue an action that will call the SelfiePool drainAllFunds(...) function and send them to us. It will work because the call is coming from governance.

To bypass queueAction(...) we need to have more than 750k DVT tokens at the time of the last snapshot. This is new - the pool implements an ERC20Snapshot version of the DVT token. Fortunately for us, anyone can take a DVT snapshot.

However, we are only interested in taking a snapshot when we do have enough DVT tokens, which we can get by implementing a contract that gets a SelfiePool flash loan.

All that's left is finding a way to bypass executeAction(...), which is easily done by waiting two days!

So, one way to solve this challenge is to:

1. Implement a contract that is able to get a flash loan from the SelfiePool contract;

2. After receiving the flash loan, take a snapshot and queue an action with:

   • data to make a call to the drainAllFunds(...) with our address as a parameter;

   • receiver as the SelfiePool address;

   • weiAmount must be 0, unless you funded the attacker contract;

3. Pay the flash loan back;

4. Wait two days;

5. Execute the action.

Compromised

To me, the hardest challenge so far. I had to use some guessing to get this to work. I'll explain my rationale below.

The challenge setup is simple: We have an Exchange selling and buying DVNTF tokens at a median price obtained from averaging 4 TrustfulOracle price feeds. The goal is simple as well: Drain Exchange using only our 0.1 ETH.

Looking at the contracts, I did not notice any obvious exploit. The only possible way to drain the Exchange contract that I found consisted of manipulating the DVNFT price. To that effect, the challenge description came in handy. This is where the guessing started.

Since it is called "Compromised" I assumed the leaked information from the HTTP response would contain some private keys.

I looked at the leaked data and decided to convert it to a string. Unfortunately, that did not result in a private key. Eventually, it occurred to me that the string I obtained may very well be encoded, as it is an HTTP response. I used google and found out that often HTTP response data is base64 encoded. So I converted the leaked data string using base64. At last, something that resembles a private key. I created wallets using the decoded leaked data and was happy to see that they corresponded to two trusted oracle addresses.

After that, it was just a question of manipulating the price using the compromised oracles.

Here's every step:

1. Decode the leaked data and obtain two private keys;

2. Create 2 wallets using the private keys obtained;

3. Set the price to an affordable value. I used 0.005 ETH;

4. Buy one DVNFT using the attacker account;

5. Set the price to equal Exchange ETH balance;

6. Sell the attacker DVNFT;

7. Reset the price to the original value;

Puppet

This challenge is quite easy.

There is a PuppetPool that allows users to borrow DVT tokens, as long as the user deposits double that amount in ETH as collateral. The pool has a balance of 100000 DVT. Our goal is to get our hands on all of them.

The pool uses an Uniswap V1 DVT/ETH pair to calculate the collateral needed. This pair starts with 10 ETH / 10 DVT liquidity.

Lastly, our attacker starts with a balance of 25 ETH and 1000 DVT.

Since there are no flash loans, our best option is to somehow lower the collateral needed to borrow the 100000 DVT tokens from the PuppetPool.

Looking at how the price is calculated we see the following equation amount * _computeOraclePrice() * 2 / 10 ** 18;.

Looking at the _computeOraclePrice() we see that the equation used is uniswapPair.balance * (10 ** 18) / token.balanceOf(uniswapPair);. This is problematic, because if the Uniswap V1 exchange has a sufficiently larger balance of DVT tokens than ETH, the price to borrow tokens will decrease significantly.

Luckily for us, our attacker has 1000 DVT tokens, so if we deposit these to the Uniswap V1 exchange, our 25 ETH, plus whatever ETH we receive from depositing to the Uniswap V1 exchange, will be more than enough to borrow the PuppetPool 100000 DVT tokens.

The only detail we must not forget is that to pass the challenge the attacker DVT balance must be higher than the initial 100000 DVT PuppetPool balance. This means we cannot deposit all of the attackers 1000 DVT tokens to the Uniswap V1 exchange.

To recap:

1. As the attacker, deposit an amount of DVT tokens large enough to lower the borrowing price to acceptable levels but less than 1000;

2. Determine the amount of ETH needed as collateral to borrow the PuppetPool 100000 DVT tokens;

3. Borrow them.

It's this simple.

Puppet V2

The set up of this challenge is very similar to the previous one.

The major differences are:

1. The PuppetV2Pool now uses an Uniswap V2 exchange to calculate the price;

2. WETH is used instead of ETH;

3. We are now required to deposit triple the borrow amount in WETH as collateral;

Despite the challenge description mentioning that developers learned from the original Puppet implementation, and in fact this is a more secure implementation, the same problem remains.

The Uniswap V2 pair used to calculate the borrowing price still has low liquidity, meaning that users with sufficient amounts of either of the pair tokens can affect significant price swings.

Luckily for us, our attacker has a significant amount of DVT tokens, meaning we can swing the price in our favor once again.

So, the steps to solve this challenge are similar to the previous one:

1. Swap the attacker DVT tokens for ETH using the Uniswap V2 pair;

2. Convert the attacker ETH to WETH;

3. Borrow all PuppetV2Pool DVT tokens;

Free Rider

The set up of this challenge consists of a FreeRiderNFTMarketplace that is selling 6 NFTs for 15 ETH each. We also have a FreeRiderBuyer which told us that the marketplace is exploitable, and if we exploit it and send them the 6 NFTs, it will pay us 45 ETH. This is our goal.

The challenge description mentions that we start with 0.5 ETH - which is clearly not enough to buy the 6 NFTs. It also implies that there's a way to get some more ETH. If we look at the script that sets up the challenge, we can see that there's an Uniswap V2 WETH/DVT pair.

First things first, we need to find the exploit in the FreeRiderNFTMarketplace. Looking at the contract we can see that we can only call the buyMany(...) function to buy NFTs. This function calls the _buyOne(...), which is the function that actually handles the purchase. The exploit must be here.

Luckily for us, it is easy to find what's wrong with this function - it is the way that it checks the price we have to pay. Suppose we call the buyMany(...) function with the ids of the 6 NFTs, the require(msg.value >= priceToPay, "Amount paid is not enough") check is wrong because it is only checking the price of one NFT, not the sum of all 6. This means that for the price of one NFT, 15 ETH, we can buy all six!

As a bonus, there's also another bug. It sends the 15 ETH to token.ownerOf(tokenId), the owner of the NFT. However, before doing so it transfers the NFT to the buyer - meaning that not only is 15 ETH enough to buy all 6 NFTs, we actually get the 90 ETH we were supposed to pay, because we are the new owner.

All that's left is figuring out how to get the 15 ETH we need. For that, you'll need to look into the Uniswap V2 documentation. This is the difficult part of the challenge.

You'll hopefully find that we can take a flashswap from the WETH/DVT pair, which we will be able to payback easily due to our expected profit from the attack.

We will need to perform this attack using a contract, not only because we need to implement a uniswapV2Call(...) function to receive the flashswap, but also because we need an onERC721Received to receive the NFTs.

Here's the full attack:

1. Get a flashswap of 15 WETH;

2. Unwrap that WETH;

3. Buy the 6 NFTs;

4. Send them to the buyer;

5. Pay the flashswap back;

6. Send the all profits to the attacker account;

You can find the code here.

Let’s begin.

Unstoppable

If you're like me, your first instinct might be to drain the pool. However, as you read through the contracts, you'll hopefully realize that there's a much easier way to stop the pool from giving out flashloans.

Let's start with the ReceiverUnstoppable contract. It has two functions receiveTokens(...) which, as the comment says, will be called during the execution of the executeFlashLoan(...) function. Looking at the executeFlashLoan(...) function, we can see that it must be called by the owner and that it will in turn call the flashLoan(...) function of the UnstoppableLender contract, so let's go to that function. The flashLoan(...) function first checks that the loan amount is higher than 0 but not greater than the pool token balance. It then checks that the poolBalance value corresponds to the actual amount of tokens the pool has. Only after does it execute the flashloan and check that it has been repaid.

So, the flashLoan(...) function will revert in case the loan amount is invalid or the loan isn't repaid. These make sense. However, it will fail in one extra scenario - if the actual amount of tokens in the pool differs from the stateful poolBalance value, which raises the question: where is the poolBalance value updated? It's in the depositTokens(...) function of the pool, which was intended as the only way users would deposit tokens in the pool. But, considering our balance of 100 DVT tokens, what's stopping us from using transfer to deposit 1 DVT token in the pool?

Naive Receiver

Ok, so we're told exactly what to do: Drain FlashLoanReceiver funds. If you look at the contract it has three functions, but only receiveEther(...) actually does something - it receives the flashloan and pays it back. As the comment says, this function is called while the NaiveReceiverLenderPool contract flashLoan(...) function is executed. Let's take a look.

We can see that the flashLoan(...) function checks that there's enough ETH in the pool for the requested flashloan amount. Then, it checks that the borrower is a contract. Finally, it verifies if the flashloan plus the fixed fee of 1 ether has been paid back.

Do you see the issue? The borrower is passed as a parameter! This means that we can say that the borrower is the FlashLoanReceiver contract and request a flashloan of 0 ether, which will cost the FlashLoanReceiver 1 ether in fees. Do this enough times and the receiver is drained!

To do this in one transaction, we just need to deploy a contract that does the attack for us.

Truster

So far, this is the most to-the-point challenge. We have to drain 1000000 DVT from the TrusterLenderPool.

Looking at the flashloan(...) function we immediately see that it has two strange parameters: address target and bytes calldata data. Examining further we find that this is a classic flash loan function except that before checking that the loan is repaid, it unexpectedly calls the target address using the data parameters. Well, this is obviously our way in.

Since no checks are performed, we can simply say that we want to borrow 0 DVT tokens, the target is the DVT token contract and the data is a call to the approve(...) function, which allows us to approve a transfer from the pool to ourselves of any amount of the pool DVT tokens. So two transactions are needed: one to call flashloan(...) in order to sneak in that approve(...) transaction, and another to transferFrom() to send the DVT tokens to ourselves.

To do this in one transaction, we just need to deploy a contract that does the attack for us.

Side Entrance

Once again, we have a 1000 ether pool that provides free flashloans. Our job is to drain the pool.

Looking at the SideEntranceLenderPool contract we can see that it allows users to deposit and withdraw funds from the pool. Of course, it also allows us to use the flashloan(...) function to request a flash loan.

Aside from repaying the flash loan, this flashloan(...) function also requires that the borrower implement the IFlashLoanEtherReceiver interface, which has the function execute() responsible for handling the flash loan funds.

So one thing is for sure, we need to implement an attacker contract that asks for the flash loan and receives it in the execute() function. But what do we do with it? Remember the deposit(...) and withdraw(...) functions? We just deposit the funds back in the pool, which will make the flash loan successful and set the funds as the property of our attacker contract, which in turn means we can withdraw those funds from the pool. All that's left to do is send the withdrawn funds from our contract to our wallet.

Rewarder

The first challenge where things get more complex. However, there are several tips in the challenge description that will provide us with a path to find the exploit.

First, we find out that there's a pool offering rewards in 5-day increments to users that deposit DVT tokens. We also discover that we have no DVT tokens, but that there's a pool offering free flash loans.

Let's look at the FlashLoanPool flashloan(...) function. It requires that the borrower is a deployed contract with the receiveFlashLoan(uint256) function to handle the flash loan. We now have a way of getting the DVT tokens, but how do we use them in regard to TheRewarderPool?

Looking at the pool the first thing we notice is that it uses three tokens: LiquidityToken, AccountingToken and RewardToken. Again, from the challenge description, it becomes obvious that we need to get some RewardToken tokens.

It seems that the only way to mint RewardToken is inside the distributeRewards(...) function. To execute that code, the function checks that rewards > 0 && !_hasRetrievedReward(msg.sender). Let's find a way to pass this verification.

hasRetrievedReward(msg.sender) will return false if we have never received a reward, which is true in our case - easy. rewards will be greater than 0 if we have a positive balance of AccountingToken tokens considering the last snapshot taken. Ok, so how do we get a positive balance of AccountingToken and our snapshot taken?

Snapshots are taken earlier in the distributeRewards(...) function execution via a call to _recordSnapshot(). However, to execute this call we need to pass the verification isNewRewardsRound() which checks that at least 5 days have passed since the last snapshot. This means that we need to wait 5 days before calling distributeRewards(...).

That was easy, but we still need to figure out how to get a positive balance of AccountingToken. Looking at the pool we see that AccountingToken are minted in the deposit(...) function, in proportion to the deposited LiquidityToken which is the DVT token. We also see that AccountingToken tokens are burned in the withdraw(...) function which, in addition to sending us our RewardToken, sends the DVT tokens back to us - allowing us to pay the flash loan.

We now have a clear picture of how to get RewardToken, and since we already know how to get our hands on free DVT tokens, we have all the information we need.

Let's recap what we know:

1. We know we have to get some amount of RewardToken to pass the challenge;

2. The only place where RewardToken is minted is in the TheRewarderPool distributeRewards(...) function;

3. To be able to reach that place of the code, the function needs that the caller:

   1. Have a positive balance of AccountingToken since the last snapshot;

   2. Have never received a reward;

4. To clear the verifications in the previous step, we need to:

   1. Wait 5 days;

   2. Deposit DVT tokens in the pool;

5. We have no DVT tokens, but we know how to get them for free provided we pay them back - which we can since we can call the pool withdraw(...) function which will give us our DVT tokens back after we have successfully gotten our RewardToken rewards;

All that's left is implementing a RewardAttacker contract that does all the above for us.

You can find the code here.

Let’s begin.

Assume Ownership

This challenge might be the easiest.

Solidity now allows you to use the constructor keyword so constructors stand out. However, the challenge contract doesn't use that keyword. If you look at the code you'll notice a severe error: the function that's meant to be the constructor is misspelled as AssumeOwmershipChallenge, allowing anyone to call it and become the owner.

There's not much to this challenge, just:

1. Get the contract abi and address;

2. Get the private key of the ropsten account you are using to interact with Capture The Ether. Otherwise, you can't pass the challenge as CTE doesn't know who you are;

3. Get the contract and connect with it using your account;

4. Call AssumeOwmershipChallenge;

5. Call authenticate;

6. Win;

Token Bank

This challenge involves two contracts: TokenBankChallenge which acts as a bank, as the name suggests. It deploys the SimpleERC223Token and assigns half to the CTE challenge factory, given that it created the TokenBankChallenge contract, and half to the player, meaning us. Our goal is to withdraw all 1000000 tokens, not just our 500000.

It's important to know that one difference between the ERC20 and ERC223 token standards is that the ERC223 notifies the recipient of a transfer by calling the tokenFallback function in case it is a contract.

Now, as you've probably guessed, the TokenBankChallenge withdraw function must be used. If you look through the function, you'll see that it is vulnerable to reentrancy attacks, as it only updates the msg.sender balance after sending the funds.

So, even though this looks like a lot of code, the solution isn't all that complicated. We just need to create a contract that has a tokenFallback function that keeps withdrawing until the contract is empty. This tokenFallback function will be called by the SimpleERC223Token contract on each withdrawal, allowing us to check if there are tokens left and keep withdrawing until it is empty.

Even though it is obvious, you must not forget that you can only withdraw funds that you have, so before initiating our attack we'll need to send our tokens to the attack contract and deposit them in the bank again.

So, here are the steps needed:

1. Get the bank contract abi and address;

2. Get the token contract abi;

3. Deploy the TokenBankHelper contract;

4. Get the bank contract;

5. Get the token contract that the challenge bank is using;

6. Withdraw your 500000 tokens;

7. Send your 500000 tokens to the TokenBankHelper;

8. Deposit them in the bank;

9. Initiate the attack by withdrawing 500000;

10. Wait until the TokenBank contract is empty;

11. Win;

You can find the code here.

Let’s begin.

Fuzzy Identity

To solve this challenge we need successfully authenticate as "smarx". The challenge gives us the conditions we need to meet:

1. Have a contract that returns "smarx" when the function name is called;

2. That same contract must be deployed at an address that ends with badc0de.

Step 1 is pretty simple, we just need a function called name that returns bytes32("smarx"). As for step 2, the EVM now has an opcode called CREATE2 that allows us to deploy a contract to a pre-computed address, provided we give it the contract bytecode and an uint256 salt to use. This is probably not what the author had in mind, but we should take advantage of improvements to the EVM.

To achieve step 2, take a look at this repo. It allows you to deploy a factory contract that will use the CREATE2 opcode to deploy our FuzzyIdentityHelper contract to an address that ends with badc0de, provided we send the correct salt along with the FuzzyIdentityHelper bytecode. This will allow us to solve the challenge. The repository contains instructions on how it should be done.

Our FuzzyIdentityHelper contract will have our challenge contract address hardcoded, although it's entirely possible to deploy bytecode with constructor params. It's just that this way is easier and does not require you to change the factory repo code.

So, to recap, here are the steps needed:

1. Deploy the factory contract to the Ropsten network;

2. Get our FuzzyIdentityHelper contract bytecode;

3. Determine the salt to use to deploy it to an address ending with badc0de. When introducing the needed information in the findHash.js script, remember that the deployerAddress is the address of the factory contract you deployed on step 1, not your own;

4. Use the factory contract to deploy our FuzzyIdentityHelper to the address determined in step 3;

5. Get the FuzzyIdentityHelper contract we just deployed;

6. Call the FuzzyIndentityHelper authenticate function;

7. Win;

Public Key

This challenge isn't about hacking a smart contract. It's about understanding how signatures work. So, you should read the docs before solving this.

A couple of important things to know:

• Ethereum signatures use the ECDSA algorithm. They consist of two integers r,s and v which Ethereum uses as a recover identifier;

• What is actually signed is the serialized transaction hash, according to the current docs;

• recoverPublicKey come with a prefix, such as 0x04 which means that both r and s follow;

Now, we will actually need some help from etherscan to begin with. The challenge contract contains the owner address, but to get its public key, we need a transaction signed by said address. If you search ropsten etherscan for the address you'll find an outgoing transaction, just what we need.

So, here's what's needed to solve this challenge:

1. Get the challenge owner outgoing transaction hash from etherscan;

2. Get the transaction object;

3. Reconstruct both the transaction data and signature objects;

4. Serialize the transaction data object;

5. Hash it;

6. Recover the public key using both the transaction data hash and the signature object;

7. Format it;

8. Get the challenge contract;

9. Authenticate yourself.

Account Takeover

This challenge is actually harder than the scoring suggests. It implies having knowledge about how ECDSA works and how to exploit its vulnerabilities. The math behind this is beyond the scope of this explanation and, to be honest, I am not knowledgeable enough to explain it. Here's a stackoverflow discussion that should get you started.

As a basic overview, ECDSA signatures can be exploited with the goal of recovering private keys when the same nonce is used to sign two transactions. We've determined in the previous challenge that a signature object consists of r, s, and v values. If two transactions have the same r, it means the same nonce was used.

ECDSA signatures are determined using s = k⁻¹ (z + r * privateKey) (mod p), where: - k is the nonce; - z is the transaction hash; - r is the r value of the signature object. This is what must be common between two transactions for this exploit to work; - (mod p) is a congruence modulo where p is a constant.

First, we need to determine all the possible k values. Then, we determine the private key that matches those k's and find out which one matches our account to hack address. After that, it's a matter of connecting to it using our new wallet and authenticating ourselves.

Note that everybody solving this challenge uses the same account, so if you're authenticate transaction is failing, it may be because the account has no ETH. Check on ropsten on etherscan and send it some if needed.

So, here are the steps:

1. Find two transactions sent by the account to hack that have the same r for the signature. This is hard to find because there are so many, so I found out which one were by searching different solutions to this challenge and kept them in the accountTakeover.js script so you don't have to;

2. Calculate the s and z values needed to determine our possible k's;

3. Determine our possible k's and the matching private keys;

4. Determine which private key corresponds to the address we need;

5. Get the challenge contract and connect to it using the hacked account wallet;

6. Authenticate ourselves;

Again, I advise you to research how ECDSA allows for private key recovery if the same nonce is used twice before solving this. And if you understand the math, feel free to hit me up and explain it to me :)

You can find the code here.

Let’s begin.

Token Sale

Looking at the contract, it may seem like everything is correct. However, if you look closely, you'll see that this contract does not implement SafeMath.

Remember, SafeMath is implemented on the language level since solidity version 0.8. This challenge uses an older version, so there's the possibility of overflows. This is how we game the contract.

If you look at the buy function, require(msg.value == numTokens * PRICE_PER_TOKEN) has the potential to overflow. Overflowing here would allow us to get a gigantic amount of tokens for a low price. We then sell 1 token for 1 ether, making a profit on the way and leaving the contract with a balance < 1, which is the required condition for us to solve the challenge.

Once again, the code is explained. Still, here are the steps needed:

1. Get the contract abi and address;

2. Get the private key of the ropsten account you are using to interact with Capture The Ether. Otherwise, you can't pass the challenge as CTE doesn't know who you are;

3. Get the contract and connect with it using your account;

4. Determine the amount of tokens to send to cause an overflow;

5. Determine the amount of ether to send;

6. Buy our tokens and wait for them to arrive;

7. Sell 1 token;

8. Profit;

To keep this description short, steps 4 and 5 are detailed in the tokenSale.js script. Take a look.

Token Whale

Looking at this contract, you'll hopefully notice that, once again, it is subject to over and underflows. However, this is part of the solution. Not all of it.

If you look at the _transfer function, it spends msg.sender tokens instead of tokens from the from address passed to the transferFrom function. This means that, if we successfully call transferFrom from an account with 0 tokens, balanceOf[msg.sender] -= value will underflow, causing the said account to receive a gigantic amount of tokens - 2**256 - 1 to be exact.

After that, all we need is to send 1000000 tokens from the helper account to our account, and we'll have successfully solved the challenge.

You may be thinking "Why do I need a second account? Couldn't I do this just using my account?". You couldn't. You'd never pass the require(balanceOf[from] >= value) check, as you'd need value to be 1001 to cause an underflow.

Once again, the code is explained. Still, here are the steps needed:

1. Get the contract abi and address;

2. Get the private key of the ropsten account you are using to interact with Capture The Ether. Otherwise, you can't pass the challenge as CTE doesn't know who you are;

3. Get a second ropsten account;

4. Approve the second account to spend funds from your account. Sign this transaction using your main account;

5. Transfer 1 token from your main account, to that same account. Sign this transaction using the second account. This will cause the underflow and give the second account an enormous amount of tokens;

6. Send the required 1000000 tokens from the second account back to your main account. Sign this transaction using the second account.

7. Wait for them to arrive, and you'll have solved the challenge.

Retirement Fund

Looking at this contract, you'll hopefully notice that, once again, it is subject to over and underflows. However, this is part of the solution. Not all of it.

If you look at the contract, you'll see that withdraw checks that msg.sender == owner, since the owner is the CTE factory, this function is of no use to us. Meaning, that our solution can only make use of the collectPenalty function.

As we've established, the contract is subject to over and underflows, meaning that uint256 withdrawn = startBalance - address(this).balance; can be underflowed, allowing us to drain all the ETH the contract has.

To achieve this, address(this).balance has to be > 1, which in turn means that we'll have to find a way to add some ether to the contract.

The contract has no payable functions, so how can we send ether to the contract? If you look through the Ethereum documentation, you'll hopefully realize that the easiest way to do this is to self-destruct another contract that has some ether in it, and send that contract ETH to the CTE challenge contract.

Once again, the code is explained. Still, here are the steps needed:

1. Get the contract abi and address;

2. Get the private key of the ropsten account you are using to interact with Capture The Ether. Otherwise, you can't pass the challenge as CTE doesn't know who you are;

3. Get the contract and connect with it using your account;

4. Deploy our helper contract. Send 1 eth as the msg.value. Don't forget to add the challenge address to the contract kill function;

5. Destroy our helper contract;

6. Call the challenge contract collectPenalty function;

7. Wait for challenge contract to be drained and you'll have solved the challenge

Mapping

To solve this challenge, we need to somehow set isComplete to true, or 1.

First, you should read the Ethereum docs to understand how contract storage works. You'll hopefully reach the conclusion that isComplete is at slot 0. Then, slot 1 has the map[] length.

From the documentation, we can also gather that: keccak256(1) has the map[0] value, keccak256(1) + 1 has the map[1] value and so forth. This is because the contract array is a dynamic size array, so the EVM reserves one slot to store the array length.

From this, we can expect that if we set the map length to 2**256 - 1, the slot that contains the isComplete value will be occupied by the array, allowing us to modify it if we know the corresponding storage address.

Since we know that map[0] is at keccak256(1), we also know that map[isComplete] = 2**256 - keccack256(1).

Once again, the code is explained. Still, here are the steps needed:

1. Get the contract abi and address;

2. Get the private key of the ropsten account you are using to interact with Capture The Ether. Otherwise, you can't pass the challenge as CTE doesn't know who you are;

3. Get the contract and connect with it using your account;

4. Expand the array bounds to occupy the isComplete slot;

5. Determine the storage address of the isComplete value;

6. Change it to 1 (true);

Donation

Looking at the contract, you'll hopefully notice two things almost immediately: the donate function calculates scale wrong, as it results in 10**36 since 1 ether == 10**18 already, and that we'll need to somehow call withdraw to drain the contract.

Taking a deeper look, the withdraw function requires us to be the contract owner, so we know what our goal is: become the contract owner.

If you read the storage layout docs in the previous challenge you'll remember that struct and array data use their own slots. Since the contract struct is only initialized when the donate function is called, we can assume that slot 0 has the Donation[] size and that slot 1 has the owner address. So, we must write to slot 1 of the contract storage, but how?

This is where the donate function is wrong again. It declares Donation donation without using either the memory or storage keywords, which means that this is just an uninitialized pointer to the contract storage. Since the struct has to uint256 values, etherAmount will write to slot 1, where the owner address is stored! All we need to do is determine the uint256 value of our address and send that as the etherAmount, with the needed msg.value to pass the require check.

Once again, the code is explained. Still, here are the steps needed:

1. Get the contract abi and address;

2. Get the private key of the ropsten account you are using to interact with Capture The Ether. Otherwise, you can't pass the challenge as CTE doesn't know who you are;

3. Get the contract and connect with it using your account;

4. Determine the uint256 value of our address;

5. Calculate the needed msg.value;

6. Make the donation;

7. Withdraw the eth;

Fifty Years

This is the challenge that awards the most points for a reason. It requires an orderly combination of transactions, with the intent to exploit the contract using the techniques we've used in the previous challenges.

First, let's try to determine our goal. Looking at the withdraw function, particularly the second require check, we can see that we need to send an index for a contribution that has an unlockTimestamp in the past and corresponds to the last contribution made, so we drain all the contributions. This is our goal. Now, how do we do this?

It should be clear that the upsert function is key. If we look through its code, we can identify two potential issues: require(timestamp >= queue[queue.length - 1].unlockTimestamp + 1 days) is subject to overflows, and the else statement relies on a previous declaration of contribution, which makes it an uninitialized storage pointer, which allows us to access storage slots 0 (queue.length) and 1 (head) (remember this from the previous challenge?). Knowing this, we can determine two steps needed:

• Call upsert once with a new contribution designed to prepare an overflow of the timestamp when we make the second contribution, allowing the second contribution to have timestamp = 0. Since the contribution.unlockTimestamp = timestamp writes to the head storage slot, after this first contribution head will have a gigantic value.

• Make another upsert call that resets head to 0, while also having an unlockTimestamp == 0, which will work, because we've prepared the overflow in the first upsert call.

This will total, 3 contributions (adding to the one that is made when we begin the challenge on CTE). There are three things we need to pay attention to while executing the two contributions:

• Time units are parsed to seconds, so we need to prepare the overflow taking that into account;

• Ether units are handled in wei, so if we send ETH to the contract the actual queue.length will be x ETH * 10**18. So we need to send wei, not ether as the msg.value;

• queue.push increments the queue.length before actually inserting the contribution. We've determined that the queue.length will be manipulated by the line contribution.amount = msg.value. This means that if we want to keep an accurate queue.length value, we need to be wary of the msg.value we send with each upsert call. We know that before our first upsert call the queue.length is 1, because one contribution was made when we began the challenge. However, we need to send 1 wei in the first contribution because, even though the line contribution.amount = msg.value will maintain the queue.length at 1 (when it's actually 2 since this is the second contribution made), the line queue.push(contribution) will increment it by 1, which will give us the correct queue.length of 2. We follow the same logic for the second upsert call and send 2 wei, since 2 + 1 = 3, which by then will be the correct queue.length.

At first glance, we may assume that, after these steps, calling withdraw(2) would drain the contract. However, this transaction would fail. Since queue.push increments the queue.length before actually pushing the contribution, contribution.amount = msg.value will be incremented too. Visualize it this way:

- Contribution 0 (made by CTE): contribution.amount == msg.value == 1 ETH;
- Contribution 1 (us): contribution.amount == msg.value == 1 wei + `queue.push` == 2 wei;
- Contribution 2 (us): contribution.amount == msg.value == 2 wei + `queue.push` == 3 wei;
- Contract total == 1.00...03 ETH, Contributions total == 1.00...05 ETH.

Hence, the transaction will fail until we add 2 wei to the contract, because we're trying to withdraw more ETH than the contract has. This can be done by taking a page out of the Retirement Fund challenge. Just create a contract that receives 2 wei on deploy, and then self-destruct said contract, sending the 2 wei to our challenge contract. After that, call withdraw(2) and we win!

Once again, the code is explained. Still, here are the steps needed:

1. Get the contract abi and address;

2. Get the private key of the ropsten account you are using to interact with Capture The Ether. Otherwise, you can't pass the challenge as CTE doesn't know who you are;

3. Get the contract and connect with it using your account;

4. Deploy our FiftyYearsHelper contract and fund it with 2 wei;

5. Call upsert a first time to prepare the timestamp overflow;

6. Call upsert a second time to set head to 0;

7. Kill our FiftyYearsHelper contract;

8. Call withdraw(2);

You can find the code here.

Let’s begin.

Guess The Number

This is very similar to the warmup challenges. In the code, you will find the script guessTheNumber.js. The code has comments explaining what each line does. Still, here is what we need to do:

1. Looking at the constructor you will notice that you need to have 1 Ropsten ETH in your account before pressing the Begin Challenge button, otherwise the transaction will fail;

2. After deploying the contract we can now solve the challenge locally. Again, we need to get the contract abi and address. Then, we need to connect to it using our account.

3. As you must have already noticed, the answer is in the code. The number is 42. However, look at the guess() function. Where have you seen that require statement before? Exactly, you need to send 1 ETH to the function in order to solve it.

Guess The Secret Number

This is almost equal to the previous challenge. In the code, you will find the script guessTheSecretNumber.js. The code has comments explaining what each line does. Still, here is what we need to do:

1. Do steps 1 and 2 from the previous challenge;

2. This time we only have the hash of the number we need to send to the guess() function. We need to figure out the number by running a loop, hashing the current loop counter value, and then checking if the hash matches. You probably saw that the guess() function takes an uint8 as a parameter. This tells us that the number is less than 256 because the uint8 max value is 2⁸-1 = 255;

3. When we have the correct number, we just need to call the guess() function and send 1 ETH to it again.

Guess The Random Number

This challenge requires a bit more work. There are at least three ways to solve this:

1. Check the Etherscan contract creation transaction, and look for state changes. You will find the solution there. This is not the goal of this solution;

2. Get the value in position 0 of the contract storage;

3. Compute the solution using the same formula that the challenge uses.

These last two options allow us to interact with the contract. Option 2 is the easiest, but both can be found in the guessTheRandomNumber.js script. As always, the code has comments explaining what each line does. Still, here is what's needed for each solution:

For both possible solutions, we need to do steps 1 and 2 from the previous challenge, and then:

Solution 2:

2. Get the value from position 0 of the contract storage and convert it to uint8;

3. When we have the correct number, we just need to call the guess() function and send 1 ETH to it again.

Solution 3:

2. We need the hash of the contract creation transaction, which we can get from Etherscan.

3. Get the contract creation transaction itself using the hash;

4. Get the block in which the transaction was included;

5. Get the block parent hash and block timestamp. If you look at the code, you'll notice that block.blockhash(block.number - 1) - that's why we get the parent hash of the block the transaction was included in;

6. Compute the hash using the above values;

7. Get the last byte of the hash, because the solution is an uint8, and convert it to a number.

8. When we have the correct number, we just need to call the guess() function and send 1 ETH to it again.

Guess The New Number

This challenge gets a little bit trickier because the answer is calculated when we call the guess function.

One approach to solve this challenge is to create a contract that computes the answer and calls the challenge guess() function in the same block. This way, our answer is always correct.

You will find the contract in contracts/GuessTheNewNumberSolver.sol. Once again, the code is explained. Still, here are the steps needed:

1. Look at the contract and understand what it is doing. The contract has comments explaining everything.

2. We need to deploy the contract. User your account so you can get your ETH back later, after solving the challenge;

3. Call the guess() function of the contract you just deployed. As a parameter, we need to send it the challenge address;

4. Call the withdraw function to get your ETH back;

Predict The Future

This challenge gets even trickier because you have to lock in your guess before an answer is calculated.

Luckily for us, we know the answer is between 0 and 9 because we mod the calculated uint8 by 10. However, knowing this isn't enough.

The key to solving this challenge is settling in the correct block. So, one approach to solve this challenge is to create a contract that locks a guess between 0 and 9. Then, we repeatedly call the predict() function of our contract until it determines that settling on the current block will produce the result that matches our locked guess.

You will find the contract in contracts/PredictTheFutureSolver.sol. Once again, the code is explained. Still, here are the steps needed:

1. Look at the contract and understand what it is doing. The contract has comments explaining everything.

2. We need to deploy the contract. User your account so you can get your ETH back later, after solving the challenge;

3. Call the lockGuess() function of the contract you just deployed. As a parameter, we need to send our guess;

4. Call the predict function until it determines that settling will produce the result we guessed;

5. Call the withdraw function to get your ETH back;

Predict The Future Block Hash

At first, this challenge may seem like a more complicated version of the previous one. However, it is not.

Looking at the contract, you'll see that the solution is determined by calculating the blockhash of the block you locked your guess in + 1. It may seem that this will require a tremendous amount of luck to guess correctly. However, what you should do first is to go to the solidity documentation and read about the blockhash function. Do it.

You'll hopefully see that it returns the hash of the last 256 blocks. For earlier blocks it will return 0 - this is how we solve the challenge! We simply lock our guess that the hash will be 0, then we get the block number our transaction was included in, wait for 257 blocks, and settle. It will return 0 and we will solve the challenge.

Once again, the code is explained. Still, here are the steps needed:

1. Get the contract abi and address;

2. Get the private key of the ropsten account you are using to interact with Capture The Ether. Otherwise, you can't pass the challenge as CTE doesn't know who you are;

3. Get the contract and connect with it using your account;

4. Lock your guess. Remember, guess 0.

5. Wait for 257 blocks. This will take some time. Go rest a little bit :)

6. Settle and get your ETH back;

You can find the code here.

Let’s begin.

Call Me / Set Nickname

Call Me and Set Nickname are very similar, so there is code only for the more complex one - Set Nickname. In the code, you will find the script setNickname.js. The code has comments explaining what each line does. Still, here is what we need to do:

1. Get the contract abi and address;

2. Get the private key of the ropsten account you are using to interact with Capture The Ether. Otherwise, you can't pass the challenge as CTE doesn't know who you are;

3. Get the contract and connect with it using your account;

4. Call the setNickname(…) function sending the nickname you want as a parameter; For the Call Me challenge, it's even easier, as the function requires no parameters.