A signature replay attack occurs when an attacker reuses the same digital signature to execute a transaction multiple times against a smart contract, potentially causing unintended repeated actions. This attack exploits the fact that signatures alone do not guarantee transaction uniqueness. Three scenarios enable replay attacks: (1) on the same contract, (2) on the same code deployed at different addresses, and (3) on contracts deployed with CREATE2 that have self-destruct functionality. Prevention requires including a unique nonce in the transaction hash and tracking executed transactions in a mapping within the contract, ensuring each signature can only be used once.
Signature Replay Attack in Solidity 0.6: Prevention Techniques
Added:in this video let's take a look at signature replay attack the basic idea of signature replay attack is that you can use the same signature to execute a transaction multiple times what does that mean let's say that we have eve and some contract and in order to execute a function inside this contract you'll need to submit a signature so eve can execute a transaction by submitting a signature and then using the same signature again she can execute the same function inside the contract so that's the basic idea of signature replay attack that you can use the same signature to execute a function multiple times now you might be asking questions like what's the point of submitting a signature to a contract and what kind of damage can be done when you can execute a transaction multiple times against the same signature so first let's go over how submitting a signature can be useful imagine that we have a multi-sig wallet owned by even alice with two eaters eve wants to withdraw one meter from the contract so what does she have to do well first she'll have to send a transaction approving herself to spend one ether likewise alice will also send the transaction to approve e to withdrawal one either and then eve can finally withdraw the one ether inside the multisig wallet so that's three transactions in total however using signatures we can reduce the number of transactions to just one transaction let's see how again let's say that eve wants to withdraw one ether first alice would sign a message that says eep can withdrawal one either next she will give the signature over to eve and then eat sends a transaction to withdrawal one ether sending her signature and alice's signature the contract will verify eve's signature and alice's signature and then send one ether to eb in total that's one transaction alice and e were able to reduce the number of transactions by exchanging signatures off-chain and then sending a transaction to a contract that can verify signatures now let's take a look at how eve can perform a signature replay attack on a multi-sig wallet that uses signatures so like before e can take the signature of alice and withdraw one eater now using the same signatures eat can withdraw another eater from the multi-sig wallet even though alice's intention was to allow eve to withdraw one ether so that was an example of signature replay attack on a multi-sig wallet you use the same signatures to execute a function multiple times in this case e was able to withdraw 2 liters now there are at least three situations where the signature replay attack can be performed the first situation is as we discussed we can perform a signature replay attack on the same contract another situation is on the same code different address so for example here we will have the same multi-sig wallet contract deployed at a different address and the third situation is on a contract that was deployed using create2 and inside the contract it has a self-destruct function create2 is a function that will deploy a contract always at the same address so with the combination of create2 and self-destruct you can deploy a contract at the address and then use self-destruct to delete the contract and then use create to again to recreate the same contract now let's examine how we can prevent a signature replay attack on these different situations in the first situation we can prevent the replay attack by having a unique signature for every transaction and keeping track of which transaction has been executed inside the contract and we can accomplish this by including the nouns inside the signature and then also keeping track of the nouns inside the contract so if eve tries to execute the same transaction twice the contract will already know that that announce was already used so the transaction will fail next how will we prevent a replay attack on the same code deployed at a different address well we can do that by including the address of the contract inside the signature and to prevent the attack from the first case here we'll also have to include announce in our contract lastly how about the case for a contract that's been deployed by create2 and inside the contract it has a self-destruct how do we prevent the replay attack on this contract well the bad news is that you cannot the reason is because you can reset the nouns and this is done by deleting the contract by calling self-destruct and then using create 2 to deploy a new contract at the same address and when the new contract is deployed the nouns is reset back to 0. the announce is used to keep track of which transaction has been executed but here by resetting the nouns e will be able to do a replay attack alright so that's three situations where a replay attack is possible let's now examine a multi-sig wallet contract that is vulnerable to replay attack we'll turn that contract into a contract that is guarded against replay attack and in the process you'll get a better understanding of how the nouns are used and how the contract knows which transaction has been executed here we have a multi-sig wallet contract that is vulnerable to replay attack let's first take a look at what each function does first of all we set donors when the contract is deployed anyone will be able to send ether into this contract by calling deposit and to transfer the either stored in this contract to anyone else then you'll have to call a transfer to call this function you'll have to send three inputs the address to send the ether to the amount and the signatures here you'll need to send two signatures corresponding to the two owners now let's take a look at how the transfer function works well first it recreates the hash that was signed from the parameters to and amount next it checks the two signatures against the hash and if the signatures are valid in other words if the two signatures were signed by the two owners then the ether will be sent to the to address the get tx hash is a simple function that hashes the two and the amount and check six is also a simple function from the transaction hash it recomputes the actual hash double sign by calling to leave sign messages next it runs a for loop and for each signature we recover the signer and then check that the signer is indeed equal to the owner if the signer and the owners are not equal then it will return false otherwise it will return true this contract is vulnerable to a replay attack because once eve has alice's signature she'll be able to call this transfer function as many times as she wants and the signatures will be valid so we need a way to create a unique signature for each transaction and then once that transaction is executed we need to mark it as executed so that he won't be able to do a replay attack and we can create a unique signature for each transaction by creating a unique transaction hash and we can do that by including a nouns inside the transaction hash so that is what we'll do so we'll pass a nouns into the get tx hash function which will also pass to the transfer function and then we'll hash the nouns over here now we are able to create a unique transaction hash by passing a unique nouns so next we'll need to invalidate this transaction hash when this transfer function is successful so we'll scroll up and create a mapping called called executed that will map from bytes32 to boolean and we'll we'll name it execute it and then we'll require that the transaction hash has not been executed yet if it is we'll throw an error saying tx executed so once we know that the tx hash has not been executed and we have a valid signature then we'll mark the tx hash as executed and then transfer the ether so by having announce and keeping track of which transaction hash has been executed this will prevent a replay attack on the same contract now you'll need to go one step further and protect this contract from replay attack for the same contract deployed at a different address and we can do that by including the address of this contract inside the get tx hash so here we'll say address this so now when alice and eve signs this tx hash they are signing a hash that is unique to this contract and this is because we are hashing the address of this contract all right so now we have a contract that is protected against replay attack and this was done by including announce and the address of this contract in the hash that we're going to sign and once the transaction corresponding to this hash is executed we mark it as executed so in summary we used signatures to reduce the number of transactions and we protect against the replay attack by signing txhash with nouns and the address of this contract thanks for watching and have a good night
Up Next

Wormhole Bridge Hack: Technical Analysis of Signature Verification Bypass
@Halborn
6K views•2022-02-08

Torrent File Format & Bencoding: A Technical Deep Dive
@AsliEngineering
12.5K views•2022-08-08

Arbitrage Algorithm for Uniswap V2 and V3 Pools
@smartcontractprogrammer
166 views•2026-02-18

Understanding Ethereum: A Comprehensive Beginner's Overview
@99Bitcoins
3.1M views•2018-06-26
Related Study Plans & Knowledge Roadmaps
Structured learning paths in Blockchain & Crypto












![Learn Solidity: The COMPLETE Beginner’s Guide [Full Course] | Solidity Tutorial](https://i.ytimg.com/vi/9BZ0zjqwCPs/maxresdefault.jpg)






















