theCyber — Facing the closed door of theCyberGatekeeper contract
A technical walkthrough
NOTICE: I am moving away from Medium. You can find the updated versions of my articles as well as new ones at https://www.chevdor.com
Introduction
In a previous article, we discovered this recent Ethereum puzzle/club called theCyber. So far, we did not discuss any solution yet and I have no plan on providing any kind of the solution in this new article. That does not mean we cannot have a look and think together.
In the previous article, the only tool that we used was an internet browser. If you seriously want to make your way in, you will likely need a bit more than this.
There are certainly many ways to get in and I will not cover them all but I will try giving you a feel based on the tools I used.
Find the door
Before we can unleash the power of our carefully crafted Ethereum transactions, we way need to figure where to send those! Where is the door of theCyber?
As we learn in the invitation, the entry to theCyber is guarded by theCyberGatekeeper contract and we can already a little activity:
This article has been written on the 27.03.2018 but how useful is a date anyway. It was around #5330846 and we can see that 3 Ethereum adventurers tried unsuccessfully knocking at a door. But wait a minute, is it really THE door?
I guess this is now time to look at some code. theCyberGatekeepr contains the following code:
By the way, this is nice, there are comments… Do you comment your solidity contracts?
We know this part already, in the previous article, we saw that 10/250 spots have been claimed.
A few days later, we are at 41/250. Don’t wait too long to secure your spot!
This is no real magic from etherscan, the code we saw above is providing the values. This is however giving us an interesting clue:
the number of tx does not match the number of entrants… there must be another door…
Let’s have a look at the next piece of code:
Sure we could try sending a transaction to give it a shot. We then would be as (un)successful as the person who tried already: https://etherscan.io/tx/0x1381e09e2b50beba774589f06bbaa97c1fd8524c4ec94ec059cc86a02f1c2895
We can stop almost right away: as you can read above, the assignAll() function requires to have 250 spots claimed. Since only 10 have been claimed so far, this function will revert and nothing will happen. We won’t get far this way.
It is interesting to see that 0age left the assignAll() function unprotected: anyone can call it, but that will only happen once the entrants queue is full. That totally makes sense since the smart contract will enforce the behavior, whoever calls it.
Let’s move on with a popular function: enter(). No need to be a seasoned hacker to know that it sounds good for anyone who wants to get in!
THAT’S IT! We found it. Simply send a transaction to the enter() function and you are in.
Or not… wait a minute, what just happened? If you read the previous article you know that shouting a password at the door does not do the trick. Let’s now try understanding why.
Something blocks the door…
Let’s have a second look at this function:
Ahhh those modifiers, can you see them all? They are all packed within a single line in the verified contract:
- gateOne
- gateTwo
- gateThree
- checkOne
- checkTwo
- checkThree
- checkFour
I left you in the previous article with the task to check out what modifiers are. It seems to be the time now to have a closer look. You can find the official documentation at http://solidity.readthedocs.io/en/v0.4.21/contracts.html#function-modifiers
Let´s have a look at one of those modifiers:
We can see the checkOne() modifier in use in this stripped out version of the enter() function:
In a nutshell, the enter() function will only execute if the _; statement of the modifier is reached. In other words, the condition entrants_.length <= MAXENTRANTS_ needs to evaluate to true which means that entrants_.length must be less or equal than 250.
It seems that those modifiers are still on the way and we will have to do some lock picking to get in.
The Checks
In the contract source, we can read that checkOne() is there to ensure that:
The number of entrant submissions cannot exceed the maximum.
checkTwo()´s purpose is to ensure that:
Each entrant’s interaction with the gatekeeper must be unique.
checkThree() is rich in information. It says:
The provided passcode must hash to one of the initialized hashes.
checkFour() ensures that:
The provided passcode may not be reused.
The gates
Now that we clarified what the check modifiers are doing, we need to have a look at another set of modifiers: the Gates.
GateOne
This modifier seems to set some conditions related to whom (msg.sender) is allowed to send the transactions.
GateTwo
This second modifier clearly sets conditions on the amount of gas that is provided.
GateThree
This last Gate seems to be raising lots of questions. It sets 3 conditions related to an argument called _gateKey.
Conclusion
By now you noticed that I am very unwilling to provide a baked solution and I hope those who succeeded in getting in with also not give any solution away.
What have we learned?
We know that the door may not be where it seemed to be at first. We learned that we need a pass-phrase that is both correct and was previously never used in order to get in. But there is more! We have seen also some conditions on the number of entrants, some requirements on the the amount of gas that is provided, and complex requirements related to a mysterious gate key.
Keep reading the next article.
Wilfried Kopp — @chevdor
GPG Fingerprint: 15AF C574 D3F9 F1C3 CCDD E31E 2DCE C4DC 506E 6475