One common vulnerability with the ecrecover function in Solidity is malleability of signatures.
ecrecover is used to recover the address that signed a message from an elliptic curve signature. However, signatures in crypto systems like Ethereum are malleable.
This means it is possible to modify a signature in a way that remains valid for the same message and public key, but produces a different signature value.
A common attack involves an attacker modifying a valid signature before it is verified via ecrecover. This could allow:
Impersonating the signer by recovering their address from a maliciously modified signature.
Hiding the real signer by modifying their valid signature into one that recovers to a different address.
Tricking contracts rely on ecrecover for authentication or permissions.
To prevent this, signatures should be verified correctly against the original message and public key, rather than relying on ecrecover alone. Additionally, signature metadata like timestamp/nonce can be included in the digest to make them non-malleable. @EthSecurity1
ecrecover is used to recover the address that signed a message from an elliptic curve signature. However, signatures in crypto systems like Ethereum are malleable.
This means it is possible to modify a signature in a way that remains valid for the same message and public key, but produces a different signature value.
A common attack involves an attacker modifying a valid signature before it is verified via ecrecover. This could allow:
Impersonating the signer by recovering their address from a maliciously modified signature.
Hiding the real signer by modifying their valid signature into one that recovers to a different address.
Tricking contracts rely on ecrecover for authentication or permissions.
To prevent this, signatures should be verified correctly against the original message and public key, rather than relying on ecrecover alone. Additionally, signature metadata like timestamp/nonce can be included in the digest to make them non-malleable. @EthSecurity1
Blockchain Security Across The Development Lifecycle
Preventative Security Tactics de.fi
Aave v3 bug bounty Part 3
@EthSecurity1
Preventative Security Tactics de.fi
Aave v3 bug bounty Part 3
@EthSecurity1
X (formerly Twitter)
OpenZeppelin (@OpenZeppelin) on X
The industry got it wrong: relying solely on audits at the finish line has not been enough
True security demands integrating protection across all stages of a project’s lifecycle
It's time to ship faster and more securely🛡️💡
True security demands integrating protection across all stages of a project’s lifecycle
It's time to ship faster and more securely🛡️💡
❤3
What is the difference between an optimistic rollup and a zk-rollup?
The main differences between optimistic rollups and zk-rollups in Ethereum layer 2 scaling are:
• Optimistic rollups use fraud proofs to ensure validity - transactions are assumed valid and anyone can submit a fraud proof to show invalid state transitions. Zk-rollups use zero-knowledge proofs to ensure validity - each transaction batch comes with a cryptographic proof of validity.
• Optimistic rollups have longer withdrawal times (1-2 weeks) since you need to wait for the challenge period to elapse before withdrawing. Zk-rollups have faster withdrawal times (minutes to hours) since validity is already proven.
• Optimistic rollups can achieve higher transaction throughput as validity does not need to be proven for each transaction. The computation costs are lower. Zk-rollups have lower throughput since each transaction must be proven valid.
• Zk-rollups provide stronger security guarantees and fraud proof protection compared to optimistic rollups. However they require more computational overhead.
• In summary, optimistic rollups rely on fraud proofs for validity whereas zk-rollups use zero-knowledge proofs. Zk-rollups have faster withdrawals but lower throughput while optimistic rollups have higher throughput but slower withdrawals.
How does EIP1967 pick the storage slots, how many are there, and what do they represent?
P-1967 is an Ethereum Improvement Proposal that standardizes a pattern for deploying upgradeable smart contracts.
EIP-1967 uses a proxy contract that delegates calls to the implementation contract. It defines a specific storage layout to manage this:
• There are 2 storage slots used.
• Slot 0 stores the address of the implementation contract. This is the logic contract that contains the actual code.
• Slot 1 stores the admin address, which has permissions to upgrade the implementation contract address in slot 0.
So in summary:
• 2 total storage slots.
• Slot 0 stores implementation address.
• Slot 1 stores admin address with upgrade permissions.
This allows the proxy contract address to stay constant while the implementation can be switched out by the admin. Users only interact with the proxy, which delegates to the implementation, enabling upgradeability via EIP-1967.
@EthSecurity1
The main differences between optimistic rollups and zk-rollups in Ethereum layer 2 scaling are:
• Optimistic rollups use fraud proofs to ensure validity - transactions are assumed valid and anyone can submit a fraud proof to show invalid state transitions. Zk-rollups use zero-knowledge proofs to ensure validity - each transaction batch comes with a cryptographic proof of validity.
• Optimistic rollups have longer withdrawal times (1-2 weeks) since you need to wait for the challenge period to elapse before withdrawing. Zk-rollups have faster withdrawal times (minutes to hours) since validity is already proven.
• Optimistic rollups can achieve higher transaction throughput as validity does not need to be proven for each transaction. The computation costs are lower. Zk-rollups have lower throughput since each transaction must be proven valid.
• Zk-rollups provide stronger security guarantees and fraud proof protection compared to optimistic rollups. However they require more computational overhead.
• In summary, optimistic rollups rely on fraud proofs for validity whereas zk-rollups use zero-knowledge proofs. Zk-rollups have faster withdrawals but lower throughput while optimistic rollups have higher throughput but slower withdrawals.
How does EIP1967 pick the storage slots, how many are there, and what do they represent?
P-1967 is an Ethereum Improvement Proposal that standardizes a pattern for deploying upgradeable smart contracts.
EIP-1967 uses a proxy contract that delegates calls to the implementation contract. It defines a specific storage layout to manage this:
• There are 2 storage slots used.
• Slot 0 stores the address of the implementation contract. This is the logic contract that contains the actual code.
• Slot 1 stores the admin address, which has permissions to upgrade the implementation contract address in slot 0.
So in summary:
• 2 total storage slots.
• Slot 0 stores implementation address.
• Slot 1 stores admin address with upgrade permissions.
This allows the proxy contract address to stay constant while the implementation can be switched out by the admin. Users only interact with the proxy, which delegates to the implementation, enabling upgradeability via EIP-1967.
@EthSecurity1
Here are some other common uses of the delegatecall functionality besides just proxies:
Library calls - A contract can delegatecall a library to reuse shared code without duplication.
Upgrades - By delegatecalling a new implementation address, upgrading logic is possible without redeploying the entire contract.
Inheritance - Contracts can inherit behavior from parent contracts by delegatecalling base contracts from derived ones.
Sandboxing - Dangerous operations can be isolated using delegatecalls to avoid reentrancy exploits in the main contract.
Middleware - Common responsibilities like authorization, validation etc. can be externalized using delegatecalls.
Payment channels - State updates can occur off-chain via signed delegatecalls submitted simultaneously.
Oracles - Data feeds can be provided via delegatecalls to isolated oracle contracts without trusting them.
Multisig wallets - Approval proxies can require multisig authorization by delegatecalling the transaction sender.
DEX protocols - Trading pairs, pricing models etc. can flexibly be implemented via delegatecall integrations.
Under what circumstances would a smart contract that works on Etheruem not work on Polygon or Optimism? (Assume no dependencies on external contracts)
Opcode support - Layer 2s generally support the same EVM opcodes as Ethereum, but there may be some minor discrepancies in opcode behavior that could cause issues.
Chain properties - Things like block time, intrinsic gas costs, and incentive structures can differ across chains in potentially breaking ways.
Pricing models - Layer 2s often have different currency pegs, interest rates, and transaction/contract execution pricing that contracts rely on.
State storage - Polygon/Optimism have additional constraints on state storage gas costs and storage that a native Ethereum contract may violate.
Timestamps - Block times are faster on L2s, so contracts relying precisely on timestamps could malfunction.
Consensus models - Differences in consensus algorithms like finality could cause issues for contracts expecting immediate confirmation.
Chain ID - Each chain has a unique chain ID. Contracts using chain ID for randomness or permissions would fail cross-chain.
Requirements for ETH - Logic requiring ETH balances or transfers directly wouldn't work without wrapping ETH on those chains first.
Mainnet EIP changes - A contract deployed before an EIP like 1559 may not account for changes introduced and fail on current Ethereum.
Network upgrades - Hard forks, consensus changes over time could cause issues if a contract doesn't anticipate potential future upgrade incompatibilities. @EthSecurity1
Library calls - A contract can delegatecall a library to reuse shared code without duplication.
Upgrades - By delegatecalling a new implementation address, upgrading logic is possible without redeploying the entire contract.
Inheritance - Contracts can inherit behavior from parent contracts by delegatecalling base contracts from derived ones.
Sandboxing - Dangerous operations can be isolated using delegatecalls to avoid reentrancy exploits in the main contract.
Middleware - Common responsibilities like authorization, validation etc. can be externalized using delegatecalls.
Payment channels - State updates can occur off-chain via signed delegatecalls submitted simultaneously.
Oracles - Data feeds can be provided via delegatecalls to isolated oracle contracts without trusting them.
Multisig wallets - Approval proxies can require multisig authorization by delegatecalling the transaction sender.
DEX protocols - Trading pairs, pricing models etc. can flexibly be implemented via delegatecall integrations.
Under what circumstances would a smart contract that works on Etheruem not work on Polygon or Optimism? (Assume no dependencies on external contracts)
Opcode support - Layer 2s generally support the same EVM opcodes as Ethereum, but there may be some minor discrepancies in opcode behavior that could cause issues.
Chain properties - Things like block time, intrinsic gas costs, and incentive structures can differ across chains in potentially breaking ways.
Pricing models - Layer 2s often have different currency pegs, interest rates, and transaction/contract execution pricing that contracts rely on.
State storage - Polygon/Optimism have additional constraints on state storage gas costs and storage that a native Ethereum contract may violate.
Timestamps - Block times are faster on L2s, so contracts relying precisely on timestamps could malfunction.
Consensus models - Differences in consensus algorithms like finality could cause issues for contracts expecting immediate confirmation.
Chain ID - Each chain has a unique chain ID. Contracts using chain ID for randomness or permissions would fail cross-chain.
Requirements for ETH - Logic requiring ETH balances or transfers directly wouldn't work without wrapping ETH on those chains first.
Mainnet EIP changes - A contract deployed before an EIP like 1559 may not account for changes introduced and fail on current Ethereum.
Network upgrades - Hard forks, consensus changes over time could cause issues if a contract doesn't anticipate potential future upgrade incompatibilities. @EthSecurity1
👍6❤2
How can a smart contract change its bytecode without changing its address?
There are a few ways a smart contract could change its bytecode without changing its address:
Upgradeable proxies - The contract address stays the same while the implementation address it proxies to can be updated, allowing bytecode changes.
Library delegation - If a contract delegates functionality to upgradeable libraries, the libraries' bytecode can change without affecting the contract address.
State channels - Contract state could transition through different bytecode versions via signed state updates submitted off-chain without changing the on-chain address.
Eternal storage - Storing critical code/data in an immutable "storage" contract while non-critical code resides in an upgradable "proxy" contract.
Self-replacement - Contract includes logic to suicidally delete and redeploy itself at the same address with new bytecode, careful state migration required.
Data availability - Contract source and data is decoupled, allowing new implementations to reuse stored data under the same address.
How change bytecodes of deployed contract 👉https://t.me/EthSecurity1/184
@EthSecurity1
There are a few ways a smart contract could change its bytecode without changing its address:
Upgradeable proxies - The contract address stays the same while the implementation address it proxies to can be updated, allowing bytecode changes.
Library delegation - If a contract delegates functionality to upgradeable libraries, the libraries' bytecode can change without affecting the contract address.
State channels - Contract state could transition through different bytecode versions via signed state updates submitted off-chain without changing the on-chain address.
Eternal storage - Storing critical code/data in an immutable "storage" contract while non-critical code resides in an upgradable "proxy" contract.
Self-replacement - Contract includes logic to suicidally delete and redeploy itself at the same address with new bytecode, careful state migration required.
Data availability - Contract source and data is decoupled, allowing new implementations to reuse stored data under the same address.
How change bytecodes of deployed contract 👉https://t.me/EthSecurity1/184
@EthSecurity1
Telegram
EthSecurity
https://t.co/1HmqpFbSQF
👍3❤1
What is the relationship between variable scope and stack depth?
The relationship between variable scope and stack depth in Ethereum is:
Variables are allocated memory on the execution stack based on their scope.
Local variables declared inside a function have the smallest scope and deepest stack depth. They are allocated at the top of the stack and removed when the function ends.
outer or enclosing scopes have wider scope but shallower stack depth, as their variables are allocated lower down on the stack and persist even after inner scopes exit.
The contract's state variables declared at the top level have the widest scope across the entire contract but the shallowest/lowest stack depth, as they persist for the life of the contract.
The stack grows deeper as new scopes are entered via function calls or loops, and shrinks back as those scopes exit.
So deeper in the call stack means deeper stack depth and narrower variable scope that exists only within that run.
Shallower in the call stack equates to wider variable scope that persists outside the current run.
So in summary, narrower variable scope correlates with deeper stack allocation, while wider scope variables have more persistent but shallower storage on the stack. Scopes map directly to stack usage.
What is an access list transaction? access list transactions provide a way for senders to declaratively restrict contract storage access during tx execution for efficiency and privacy benefits. @EthSecurity1
The relationship between variable scope and stack depth in Ethereum is:
Variables are allocated memory on the execution stack based on their scope.
Local variables declared inside a function have the smallest scope and deepest stack depth. They are allocated at the top of the stack and removed when the function ends.
outer or enclosing scopes have wider scope but shallower stack depth, as their variables are allocated lower down on the stack and persist even after inner scopes exit.
The contract's state variables declared at the top level have the widest scope across the entire contract but the shallowest/lowest stack depth, as they persist for the life of the contract.
The stack grows deeper as new scopes are entered via function calls or loops, and shrinks back as those scopes exit.
So deeper in the call stack means deeper stack depth and narrower variable scope that exists only within that run.
Shallower in the call stack equates to wider variable scope that persists outside the current run.
So in summary, narrower variable scope correlates with deeper stack allocation, while wider scope variables have more persistent but shallower storage on the stack. Scopes map directly to stack usage.
What is an access list transaction? access list transactions provide a way for senders to declaratively restrict contract storage access during tx execution for efficiency and privacy benefits. @EthSecurity1
RWA is one of the fastest growing categories of DeFi https://www.galaxy.com/insights/research/overview-of-on-chain-rwas/ @EthSecurity1
Galaxy
Overview of On-Chain RWAs and the Forces Propelling their Growth
Explore the rise of on-chain real world assets (RWAs) and tokenized real-world assets! Galaxy unpacks growth driven by yield demand, Fed policy, and crypto trends.
❤3
UniswapX Audit
https://blog.openzeppelin.com/uniswapx-audit
Aave Unleashed
Evm course
https://learnevm.com/
@EthSecurity1
https://blog.openzeppelin.com/uniswapx-audit
Aave Unleashed
Evm course
https://learnevm.com/
@EthSecurity1
Openzeppelin
UniswapX Audit
The UniswapX Protocol operates as a non-custodial trading framework based on Dutch auctions. It seamlessly combines on-chain and off-chain liquidity, protects swappers from MEV by making them participants via price enhancement, and enables gas-less swaps.…
👍6❤3⚡2
1)If you deploy an empty Solidity contract, what bytecode will be present on the blockchain, if any?
If you deploy an empty Solidity contract with no functions or variables defined, the bytecode that will be deployed to the blockchain will be:
608060405234801561001057600080fd5b50610130806100206000396000f3fe6080604052600080fdfea264697066735822122082841ff4e4f1026f8824145257795b55a85b7b19d8689f3e455c52daa2c275e64736f6c634300060c0033
This is the default bytecode generated by the Solidity compiler for an empty contract with no code. It consists of:
608060405234801561001057600080fd5b50 - Standard EVM contract initialization code
610130806100206000396000f3fe - Empty contract creation code
6080604052600080fdfea26469706673582212... - Empty runtime bytecode 2)Rate manipulation in Balancer Boosted Pools https://medium.com/balancer-protocol/rate-manipulation-in-balancer-boosted-pools-technical-postmortem-53db4b642492
@EthSecurity1
If you deploy an empty Solidity contract with no functions or variables defined, the bytecode that will be deployed to the blockchain will be:
608060405234801561001057600080fd5b50610130806100206000396000f3fe6080604052600080fdfea264697066735822122082841ff4e4f1026f8824145257795b55a85b7b19d8689f3e455c52daa2c275e64736f6c634300060c0033
This is the default bytecode generated by the Solidity compiler for an empty contract with no code. It consists of:
608060405234801561001057600080fd5b50 - Standard EVM contract initialization code
610130806100206000396000f3fe - Empty contract creation code
6080604052600080fdfea26469706673582212... - Empty runtime bytecode 2)Rate manipulation in Balancer Boosted Pools https://medium.com/balancer-protocol/rate-manipulation-in-balancer-boosted-pools-technical-postmortem-53db4b642492
@EthSecurity1
👍7❤4🫡1
step by step SHA256 visualization https://sha256algorithm.com/ @EthSecurity1
Sha256Algorithm
Sha256 Algorithm Explained
Sha256 algorithm explained online step by step visually
❤10👍2
comprehensive TWAP manipulation attacks https://chaoslabs.xyz/resources/chaos_uniswap_v3_twap_oracle_manipulation.pdf https://medium.com/@chinmayf/so-you-want-to-use-twap-1f992f9d3819 @EthSecurity1
❤5👍3
EthSecurity
1)If you deploy an empty Solidity contract, what bytecode will be present on the blockchain, if any? If you deploy an empty Solidity contract with no functions or variables defined, the bytecode that will be deployed to the blockchain will be: 608060405…
when reviewed Balancer pools critical issues found out everything was free for traders. linear pools ratio was 1:1 + no fees ;( audit giants reviewed it before @EthSecurity1
👍3
new patrick collins github course for first runners https://github.com/Cyfrin/security-and-auditing-full-course-s23 @EthSecurity1
GitHub
GitHub - Cyfrin/security-and-auditing-full-course-s23: The ultimate, most advanced, security, DeFi, assembly, web3 auditor course…
The ultimate, most advanced, security, DeFi, assembly, web3 auditor course ever created. - GitHub - Cyfrin/security-and-auditing-full-course-s23: The ultimate, most advanced, security, DeFi, assem...
👍4❤2⚡1
❌ Error: uint160(uint160 a * uint56 b)
Intermediate result of a * b can overflow uint160
When performing arithmetic operations on uint data types in Solidity, the result takes on the smallest uint type that can hold the result without overflowing.
a is of type uint160
b is of type uint56
Multiplying two uint values performs unchecked arithmetic
So when we multiply a * b:
The result could potentially be up to 160 + 56 = 216 bits wide.
✅ Fix: uint160(uint256(uint160 a) * uint56 b)
Cast to uint256 first then multiply @EthSecurity1
Intermediate result of a * b can overflow uint160
When performing arithmetic operations on uint data types in Solidity, the result takes on the smallest uint type that can hold the result without overflowing.
a is of type uint160
b is of type uint56
Multiplying two uint values performs unchecked arithmetic
So when we multiply a * b:
The result could potentially be up to 160 + 56 = 216 bits wide.
✅ Fix: uint160(uint256(uint160 a) * uint56 b)
Cast to uint256 first then multiply @EthSecurity1
❤4
A Deep Dive into 1inch Fusion
x.com/officer_cia/status/1721201204573733305
Defi Dao gevernanc defi attacks
https://dacian.me/dao-governance-defi-attacks
layerzero vulnerability
https://medium.com/@Heuss/layerzeros-cross-chain-messaging-vulnerability-e5ef48c5ccec
Collected 26 unobvious tips for y’all fam. FYI
http://github.com/OffcierCia/tips-solidity-code-auditors
@Ethsecurity1
x.com/officer_cia/status/1721201204573733305
Defi Dao gevernanc defi attacks
https://dacian.me/dao-governance-defi-attacks
layerzero vulnerability
https://medium.com/@Heuss/layerzeros-cross-chain-messaging-vulnerability-e5ef48c5ccec
Collected 26 unobvious tips for y’all fam. FYI
http://github.com/OffcierCia/tips-solidity-code-auditors
@Ethsecurity1
in your storage
DAO Governance DeFi Attacks
On-chain DAO Governance protocols create a large attack surface for creative exploitation..
👍4❤2🔥1
TLDR: Attacker can break neutrality guarantees of Chainlink's VRF (verifiable random function). Chainlink confirmed CRITICAL severity and paid us $300K for the finding!🎇
From the Chainlink blog: "malicious VRF subscription
Link to blog: https://blog.chain.link/smart-contract-research-case-study/
…
@EthSecurity1
From the Chainlink blog: "malicious VRF subscription
Link to blog: https://blog.chain.link/smart-contract-research-case-study/
…
@EthSecurity1
Chainlink Blog
Supporting the Smart Contract Vulnerability Research Community | Chainlink Blog
Understand the importance of smart contract vulnerability research for a secure and sustainable Web3 economy.
🔥11
In this clip, ArthurB
points out that Optimism has not implemented fraud proofs at all https://twitter.com/Justin_Bons/status/1726395238749450722 @EthSecurity1
points out that Optimism has not implemented fraud proofs at all https://twitter.com/Justin_Bons/status/1726395238749450722 @EthSecurity1
Uniswap v4 Lethal Integration: Vulnerabilities in Hooks Due to Risky Interactions
https://phalcon.xyz/blog/lethal-integration-vulnerabilities-in-hooks-due-to-risky-interactions @EthSecurity1
https://phalcon.xyz/blog/lethal-integration-vulnerabilities-in-hooks-due-to-risky-interactions @EthSecurity1
BlockSec
A Platform to Monitor and Block Hacks - BlockSec Phalcon
Phalcon helps protocols, liquidity providers/traders, L1/L2 Chains, and exchanges detect attacks, get instant alerts, and take automatic actions.