1-💡Foundry tips

Have you ever tried deploying contracts with different solidity versions with Foundry? https://twitter.com/GiuseppeDeLaZa/status/1699394882941395416

2-Month long DeFi security alpha thread

3-Common Cross-Chain Bridge Vulnerabilities

@Ethsecurity1

TSS Vulnerability Thread by Hein Alberts. A more accessible explanation of the above vulnerability and how it affected THORChain

A summary from the perspective of Sigma Prime on the security GigaSpace: The Future of Web3 Security Reviews.

@EthSecurity1

Enso Transaction Simulator - Ethereum transaction simulator leveraging Foundry's codebase.

BrokenToken - a tool designed to automatically test smart contracts that interact with ERC20 tokens for unexpected behavior that may result in exploits.

mev-share-rs - ust utils for MEV-share.

Alloy - Fast, battle-tested and well-documented building blocks for Ethereum, in Rust.

Releasing Reth! by Georgios Konstantopoulos (Paradigm).

SmartBugs - A Framework for Analysing Ethereum Smart Contracts.

Titanoboa - A Vyper interpreter with pretty tracebacks, forking, debugging

@EthSecurity1

Haggling With Hackers: Surprising Lessons From 50 Negotiations With Ransomware Gangs.


Advanced Wizard Guide to Dune SQL and Ethereum Data Analytics


• LABRAT: Stealthy Cryptojacking and Proxyjacking Campaign Targeting GitLab 


Beware cool-looking beta crypto-apps. They may be money-stealing fakes.

@EthSecurity1

Breaking down the Top 50 DeFi hacks 2016-2022

Reports of fake crypto job posting used to spread wallet stealer malware.


Magnate Finance disappears with over $6 million in apparent 'rug pull'.

Sort of professionals creating a web3sec community.Check out the DeFiHackLabs Partnership Application:
forms.gle/M7WiCJiuGkdBxP…

DeFiHackLabs Discord: discord.gg/Akky65mbz9

@EthSecurity1

I want to do more in web3Security space
If you have a proposal or partnerships ideas you can Dm @EthDev1

Hello mates i decided share daily Ethereum developer Q&A in interviews beside ordinary secuirty Knowledge sharing.from zero to hero

1-What is the difference between private, internal, public, and external functions?

Here are the main differences between private, internal, public and external functions in Solidity:

Private: Can only be called within the currently executing contract, not externally or inherited. Not part of the ABI.

Internal: Can be called internally from current contract or inherited contracts/libraries. Not part of the ABI.

Public: Part of the ABI and contract interface. Can be called externally or internally.

External: Part of the ABI but cannot access contract state. Can only be called externally from other contracts.

In summary:

Private: callable only within current contract
Internal: callable internally or by inheriting contracts
Public: callable internally or externally via ABI
External: callable externally via ABI but not state-changing

The visibility degrees follow this order:

private < internal < public < external

With private being the most restrictive and external the most accessible from outside the contract and inheriting contracts. 2-Approximately, how large can a smart contract be?

There is no hard limit on the size of smart contracts in Ethereum, but there are some practical constraints:

Code size: Contract bytecode (compiled code) is typically limited to around 24KB due to EVM limitations. Larger code requires optimization.

Deployment cost: Deploying large contracts can be prohibitively expensive due to high upfront gas costs of several million gas or more.

Complexity: Very large contracts with many operations slow down node verification times and can impact decentralization.

Updating: Updating logic in deployed contracts is complex/costly for large codebases, favoring smaller focused updates.

Testing: Thoroughly testing contracts with many operations and edge cases becomes intractable at larger sizes.

In general, contracts larger than around 5KB start facing significant constraints. Most real-world contracts are below 1KB.

As a rough guideline:

Up to 5KB: Typical size for production contracts
5-20KB: Possible but requiring careful optimization
20-24KB: Theoretical limit, extremely large
Over 24KB: Not viable, would require optimization techniques like splitting across multiple contracts.

So in summary, while theoretically unbounded - practical constraints of deployment costs, complexity and maintainability favor targeting smaller contract sizes below 5KB whenever possible. @EthSecurity1

Minimal Proxy Compendium https://banteg.xyz/posts/minimal-proxies/

Cryogen - blockchain dataset management tool by banteg

Huff breakpoints for Foundry debugger

Reports of Google Adwords used to redirect users to crypto phishing sites which already cost one user $900k after visiting a malicious Celer Bridge Dapp

@EthSecurity1

Under what circumstances could abi.encodePacked create a vulnerability?

A few circumstances where abi.encodePacked could potentially create vulnerabilities:

Length padding attack: If an integer value is encoded that an attacker controls, they could append extra zeros to enforce type conversion to a larger type. This could allow reinterpreting the encoded data malevolently.

Overflow encoding: Encoding a series of values that together exceed the maximum type size (e.g. encoding multiple uint256 values that sum above 2**256) could cause unexpected behavior.(overflows transactions will revert in solidity 0.8.0)

Unexpected types: The packed format doesn't include type identifiers, so reinterpreting the encoded data unexpectedly as a different type than intended could lead to issues.

Semantic collisions: There is a small chance that semantically different contract types may encode to identical binary representations. Care needs to be taken to rely only on defined encoding properties.

Gas estimation: Since packed encoding delegates minimum gas amount based on input, very long or malicious inputs could potentially be crafted to exceed gas estimates.

Inheritance clashes: Ambiguous inheritance trees between encoded contract types could in theory lead to data interpretation conflicts on decoding. What is a storage collision in a proxy contract?
A storage collision in a proxy contract refers to a situation where the storage layout of the proxy contract and the logic contract conflicts, causing unexpected behavior.

To understand this, one must first understand how proxy contracts and logic contracts interact in an upgradeable contract system. An upgradeable contract system in Ethereum consists of two main parts:

Proxy Contract: This contract maintains a consistent address and holds the state variables (storage). It also contains a fallback function that delegates all calls to an address stored in the proxy, which points to the current logic contract.

Logic Contract(s): These contracts contain the business logic of the application. They can be replaced or upgraded, but they do not directly hold any state. They operate on the state stored in the proxy contract.

The way the EVM (Ethereum Virtual Machine) deals with storage layout is that each variable is assigned a slot in the storage space. If you have two contracts (the proxy and the logic contract) that are both using the same storage slots, then a storage collision can occur.

For example, if the logic contract has a variable x in slot 0, and the proxy contract also has a variable in slot 0, when the logic contract tries to access or modify x, it might be accessing or modifying the proxy's variable instead. This can lead to unexpected and potentially harmful behavior.

To avoid such collisions, developers need to be very careful about the storage layout when creating upgradeable contracts. Tools and libraries like OpenZeppelin's upgradeable contract tools can help manage this and prevent storage collisions. @EthSecurity1

Some rough impressions of Worldcoin

Solidity signature verification checklist
Check this too:
https://medium.com/coinmonks/ethereum-signatures-for-hackers-and-auditors-101-4da766cd6344
@EthSecurity1

Auditor life cycle @EthSecurity1

DeFi Hacks Analysis - Root Cause Analysis Part 2


Double and Nothing: Understanding and Detecting Cryptocurrency Giveaway Scams.

Smarter Contracts: Detecting Vulnerabilities in Smart Contracts with Deep Transfer Learning.
@EthSecurity1

Aave v3 bug bounty part 1 and part 2

Top 5 duplicated issues of competitive audits thread

@EthSecurity1

Cross-Chain Security with LayerZero Labs

A UI Flaw in Top Crypto Wallets We Need to Address
@EthSecurity1

What is the difference between UUPS and the Transparent Upgradeable Proxy pattern?

• Proxy Implementation:
• UUPS uses the minimal proxy contract that delegates all calls to the implementation contract.
• Transparent Proxy has more complex proxy logic to forward calls based on function signatures.
• Upgrade Mechanism:
• UUPS upgrades by calling the upgradeTo() function directly on the proxy.
• Transparent Proxy upgrades by calling the upgradeTo() function on the proxy admin which owns the proxy.
• Storage Layout:
• UUPS uses the same storage layout for the proxy and implementation. No translation is needed.
• Transparent Proxy uses different storage for proxy and implementation which requires storage layout translation.
• External Calls:
• UUPS proxy cannot make external calls except for the delegatecall to the implementation.
• Transparent Proxy can make arbitrary external calls as it has its own logic.
In summary, UUPS has a minimal proxy and direct upgrade mechanism while Transparent Proxy has more complex proxy logic and admin-based upgrade flow. UUPS is simpler while Transparent Proxy is more flexible.
ERC777 tokens introduce some new potential attack vectors that developers should be aware of compared to the more established ERC20 standard:
• Reentrancy - ERC777 has hooks that allow contracts to react to token transfers. This enables reentrancy if the hooked contracts are poorly coded. Proper reentrancy guards need to be implemented.
• Malicious contracts - Since ERC777 tokens can interact with arbitrary contracts via hooks, a malicious contract could try to exploit the token or steal funds when it receives tokens. Extra precaution needs to be taken.
• Denial of service - If not rate limited, malicious contracts could trap tokens forever by refusing to return them in the hooks. This could block token transfers.
• Brute force burn attacks - The burn functionality could potentially be abused to force holders to burn tokens by repeatedly calling it.
• Hook logic complexity - Complex logic in the token transfer hooks increases potential vulnerabilities and gas costs. Hooks should be as simple as possible.
• Infinite hook loops - Chained token contracts could call each other's transfer hooks infinitely unless a counter is implemented.
So in summary, ERC777 provides more flexibility which brings both power and vulnerabilities that developers need to mitigate. Carefully auditing and testing ERC777 behavior is recommended before deployment.
@EthSecurity1

Why shouldn’t upgradeable contracts use the constructor?

There are a few key reasons why upgradeable contracts should not use the constructor:
1-Constructors can only be called once: If the constructor is used during initial deployment, it cannot be called again when upgrading the contract. This means any initialization logic would only run on the initial deployment and not on future upgrades.
2-State changes cannot be reverted: Any mutable state changes made in the constructor are permanent and cannot be reverted if a future upgrade needs to rollback changes.
3-Constructors are not upgrade-safe: Since the constructor runs only once at initial deployment, it does not support the upgrade workflow where the code is replaced but the contract state is maintained.
4-Initialization logic should be separated: It's considered a best practice to separate initialization logic from perpetual/state-changing logic. Initialization only needs to run once, while other logic may need to rerun on upgrades.
Instead of using the constructor, upgradeable proxies recommend using an "initialize" function that can be called again after upgrades to re-initialize any needed storage variables, mappings, etc. This keeps state changes reconfigurable and avoids issues with only running constructor code once.
So in summary - constructors are not compatible with how upgradeable proxy contracts work and any logic meant to rerun on upgrades should live outside the constructor for safety and manageability of upgrades.

What is the difference between memory and calldata in a function argument?

The main differences between memory and calldata in Solidity function arguments are:
• Memory: Data is stored in memory which exists only for the duration of the function call. Memory is EXPENSIVE to use since it gets cleared after the function finishes.
• Calldata: Points to argument data provided to the function call and is read-only. Calldata contains the actual call data coming from the message call and is onlymodifiable by the called contract. It is CHEAPER than memory.
In summary:
• Memory is mutable and stores a copy of data, while calldata is immutable and direct pointer to external input data.
• Memory gets cleared after function finishes, while calldata remains unchanged and points to original call data even after function finishes.
• Using memory is more expensive than calldata due to allocation and freeing on the stack.
• Calldata should be used for large immutable data inputs to save on gas costs compared to memory which must allocate space.
• Memory is suitable when the data needs to be modified by the function since calldata is read-only.
So in general, use calldata for large immutable input data and memory for any data that needs modification within the function scope.
@EthSecurity1

Ethereum Apocrypha

Bonding curve explanation thread

@EthSecurity1

1. ZK Sync Audit reports : https://github.com/nullity00/zk-security-reviews/tree/main/ZKsync
2. Circuits : https://github.com/matter-labs/era-zkevm_circuits/tree/main/src
3. Boojum, the proving stack for circuits : https://github.com/matter-labs/era-boojum/tree/main
4. Verifier for circuits : https://github.com/matter-labs/era-boojum-validator-cli
5. Common ZK Bugs : https://github.com/0xPARC/zk-bug-tracker
6. Contracts : https://github.com/matter-labs/era-contracts

My 2 cents : Play on your strengths, try to breakdown the ZKEVM.

For any questions, reach out to
- Porter Adams, Security @ ZKSync (https://twitter.com/portport255)
- Vlad Bochok, Security @ ZKSync (https://twitter.com/vladbochok1)

Also, Brandon Ghomes has come forward to help https://twitter.com/brandonhgomes/status/1706837021702889603 (Brandon contributed to Plonky2 code, some of which is used by Boojum)

If you are unable to reach any of the above people, DM me.
Good luck bug hunting !

From DefiHackLabs’s Discord
@EthSecurity1