# Walkthrough: Huff Challenge #5 **Published by:** [PraneshASP ⚡](https://paragraph.com/@praneshasp/) **Published on:** 2023-07-13 **URL:** https://paragraph.com/@praneshasp/walkthrough-huff-challenge-5 ## Content In this article, we’re going to have a look into the solution for Huff Challenge #5. If you wanna check-out the solutions for other challenges, look here.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 👋👋 ## Publication Information - [PraneshASP ⚡](https://paragraph.com/@praneshasp/): Publication homepage - [All Posts](https://paragraph.com/@praneshasp/): More posts from this publication - [RSS Feed](https://api.paragraph.com/blogs/rss/@praneshasp): Subscribe to updates