PARADIGM CTF 2022 Question Analysis 4 -MerkleDrop

The CTF was ended for a while, but the security vulnerabilities and knowledge in many of these topics attract us to study and learn it. Meanwhile it comes with difficulties and challenges also.

Numen Cyber Labs is paying attention to all aspects of security information related to blockchain and trying to share some solutions with you as well. This time, we will analyze MerkleDrop. If there are better methods and techniques, welcome to discuss with us.

MerkleDrop Introduction

Merkledrop is a popular airdrop token technology . Its rough logic is that crypto projects send free tokens to the community to encourage adoption. They are based on the use of Merkle trees. Because of the nature of these data structures (i.e., each non-leaf node is a binary tree of hashes of its children), they are particularly effective in space usage and validation. The leaves store information about user addresses and the number of tokens they are eligible to receive. Leaves are then grouped in pairs and hashed. Their hashes are grouped in pairs and hashed again, and so on until there is a root hash. Such a tree can be made public to anyone and there is still no risk of modifying its data, and consistency is guaranteed by hashing.

It's also easy to prove that you're eligible for airdrops, such as:

1. Requires a leaf with your address and amount.

2. Provides a path from leaf to root hash. Specifically, you need to prove the other hash values in each pair on each layer of the tree.

Question Analysis

1. MerkleDistributor.sol

Analysis：The main function that can be called in this contract is the claim function, which collects tokens under the contract. isClaimed is a query function to query the pick status of leaf nodes

2. Setup.sol：

Analysis：We can see that in the constructor, the merkleDistributor contract was created and transferred 75,000tokens into it.

Question：In the condition that not all leaf nodes are in the claimed status, do claim all the tokens under the contract.

Problem-Solving Analysis

To solve this problem, we can only call the claim function in the merkleDistributor contract to claim the tokens under the contract, and the leaf nodes must not claim them. At first, when I saw these two conditions, I thought it was very contradictory. This question provides the tree.json file, which contains the verification information of 64 leaf nodes, including the extraction address, index, amount and verification hash, which can be called normally. However, by directly using this information, the tokens under the contract can be extracted, but all leaf nodes have been extracted, and this problem cannot be solved.

By continuing to analyze the question, we can see that the amount in the claim function is uint96, and When getting :is, is, is, this produces 64 bytes, and 64 is a good number. If we look again:

node:
index uint256
account address
amount uint96
MerkleProof

It concatenates two hashes (each with a hash value of 32 bytes) and hashes them. So the input here is also 64 bytes long.

If one of the leaves is also hashed, then we package all the leaf information, as shown below:

Each of these sequences is hashed, i.e. the 32 bytes on the left are one hash and the 32 bytes on the right areanother hash. However, there are a lot of 0 in front that don’t look like real hashes. The 32 bytes on the right look more like a hash value. Note that each of them has multiple 00s in about the same position — this is due to the number of fills. Let’s look at the tree.json if there’s one piece of evidence with a similar padding?

We see a similar message in the 37th leaf, the number of uint96 in hexadecimal 00000f40f0c122ae08d2207b is72033437049132565012603.

1) At this time, we can organize the extraction parameters and call the claim function to collect them. We will make the first proof in the proof list for leaf 37 itself a leaf.

We can pass the proof with multiple 00s as the second half of the input to the claim function0xd48451c19959e2d9bd4e620fbe88aa5f6f7ea72a will be an account, 0x00000f40f0c122ae08d2207b will be a cap.

But we need index, which can’t be an arbitrary number because it’s hashed with addresses and amounts, while theresulting hash value is hashed along with other proofs. The proof is concatenated, and the index is also connected to the address and amount. And this index is the hash of leaf 37, the leaves are hashed, and then their hashes are grouped in pairs and hashed again. Thus, the hash value of leaf 37 is grouped with the first proof in its proof array.

A total of 75,000*1e18 tokens were transferred into the contract, 72033437049132565012603 had just beenwithdrawn, and there were 2966562950867434987397 remaining, and the hexadecimal was 0xa0d154c64a300ddf85,so we looked for no leaf nodes in tree.json. The answer is yes, with an index of 8 leaf nodes.

Then continue to call the claim function, pass the parameter information in to extract the remaining tokens.

Summary

We also took a lot of detours when solving this problem, we must make reasonable use of all the information and data given in the problem, otherwise it will be difficult to solve it. If you have any better methods or skills, welcome to contact us and discuss together. Numen Cyber Labs will continue to focus on blockchain security!