ZKP vulnerabilities

Zcash hash collision

https://www.youtube.com/watch?v=W4zAbEnJQUw

Frozen heart

https://www.youtube.com/watch?v=ffPI0B2l2dY

@EthSecurity1

Time to shit on some proxy patterns.

- Beacon: it sucks in performance, antipattern that got psyoped into relevance.

- UUPS: devs need to pollute their implementations.

- Transparent: devs need to deploy 2 extra contracts and verify them everytime. Much captcha.@EthSecurity1

X users manipulated by ChatGPT bots to visit malicious crypto sites.

Dark days incoming

Lazarus Group exploits ManageEngine vulnerability to deploy QuiteRAT


DeFi Hacks Analysis - Root Cause Analysis Part 2 SunSec

@EthSecyrity1

Web2 Bug Repellant Instructions

Exploring Tornado Cash In-Depth to Reveal Malleability Attacks in ZKP Projects

@EthSecurity1

Essential Auditing Knowledge | What is the Difficult-to-Guard “Read-Only Reentrancy Attack”,

Audit Anomalies Archive

a unique Sandwich Attack against Curve Finance

@EthSecurity1

DeFi Risk Modelling Awesome

The Specter (and Spectra) of Miner Extractable Value.

@EthSecurity1

Typical vulnerabilities in AMM protocols

https://blog.decurity.io/typical-vulnerabilities-in-amm-protocols-9006f7986ba0

How Does Ethereum Manage Data?
https://blog.smlxl.io/how-does-ethereum-manage-data-3ee85263134b?

@EthSecurity1

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