Bitmay

A lot of Solidity code still treats extcodesize as if it were a security feature. Checking extcodesize(addr) == 0 only tells you one thing: at that exact moment, the address has no deployed code. Usually developer use this feature cause they wants to block smart contracts and allow only regular wallets. The thinking is simple: "If the caller is not a contract, the function is safer." That is where the mistake begins. On the surface, it looks strict and intuitive: if the caller has no code, then it must be safe to treat it like a normal user. But that assumption breaks in one of the most important edge cases. The most well-known issue is constructor bypass. During contract construction, the contract's code is not yet stored on-chain. That means if a contract calls another contract from its constructor, extcodesize(address(this)) is still zero during that call. So code like this: require(msg.sender.code.length == 0, "no contracts"); can still be bypassed by a contract calling in from its constructor. That alone should be enough to kill the idea that this is a reliable security boundary. The check looks strict, but it can fail in one of the most important edge cases.

This commonly used batching pattern can easily lead to vulnerabilities Batching is a pattern many developers use to let users execute multiple actions in one transaction. On the surface, it looks simple and useful. But if it is added without fully understanding how it changes execution flow, it can quietly turn otherwise normal functions into vulnerable ones. The dangerous part is that the bug often does not come from batching alone, but from how it interacts with other contract logic. A simplified version of how batching works looks like this: function batch(bytes[] calldata calls, bool revertOnFail) external payable returns (bool[] memory successes, bytes[] memory results) { successes = new bool[](calls.length); results = new bytes[](calls.length); for (uint256 i = 0; i < calls.length; i++) { (bool success, bytes memory result) = address(this).delegatecall(calls[i]); require(success || !revertOnFail, "call failed"); successes[i] = success; results[i] = result; } } The important part is this line: address(this).delegatecall(calls[i]); Because it uses delegatecall, every batched call keeps the same msg.sender and msg.value. This is where it is commonly misused. For example, imagine the same contract also has: function deposit() external payable { require(msg.value == 1 ether, "need 1 ETH"); credits[msg.sender] += 100; } Used normally, this looks fine: - send 1 ETH - call deposit() - get 100 credits But once deposit() can be reached through batching, one 1 ETH transaction can batch deposit() multiple times. Because every batched call still sees the same msg.value, the contract may count the same 1 ETH again and again. So one payment can execute deposit() multiple times. That is the danger. Batching itself is not automatically broken, but if developers batch functions that rely on msg.value or assume each call is independent, it can easily lead to vulnerabilities.

@0x0x0xOxx just search any keyword or lines of solidity code

@Bitmay How can i use it?

Using dork to find vulnerable Solidity contracts One way to find vulnerable Solidity contracts is by using a dorking mindset. For example, before Solidity 0.8, integer overflow and underflow on uint was still possible because arithmetic did not automatically revert. So if we want to search for this vulnerability, we can search for an old Solidity version like: pragma solidity 0.7 And to make it more accurate, we can look for contracts that do not use SafeMath. We can make it more specific by adding arithmetic patterns like: += or -= So one way to search for this type of bug is to combine multiple clues in a dork. That gives us a search idea like this: site:etherscan*io "pragma solidity 0.7" "-=" or more specifically: site:etherscan*io "pragma solidity 0.7" "accounts[_from].balance -= _value;" But sometimes Google does not give accurate results for what we really want. Because Google mostly searches exact text. This is where EVM Chronicle has a dedicated feature for this kind of search. It does not just search the exact words we type. It can search for the pattern we actually want. So if you search: pragma solidity 0.7 accounts[_from].balance -= _value; it can return contract address results with similar logic, like: balance[address] -= wad; or other similar arithmetic patterns in old Solidity version 0.7.x. With EVM Chronicle, you do not have to stress out selecting the exact words to match the data you want. You can just place a line of code, and EVM Chronicle can extract the logic from there and search on its own dedicated database. If you want a clearer picture, watch the video to see exactly how I do it in practice.

Let's do it... Will create and post it on Monday

Sometimes I still use Google dorking methods to find Solidity patterns that often lead to vulnerabilities. If enough of you are interested, I can share the workflow.

Address Impersonation Simulation = run transactions as any address. Great for testing admin paths, whale interactions, and real protocol state during audits. Some bugs only appear when the right address calls the function.

Even for me, it's really fun to play with 🧑‍💻

Source Code Intelligence is now live in EVM Chronicle. Variables are now inline-clickable in source view, so you can inspect live storage instantly. Functions are now simulatable directly from code, with inputs and execution traces in one flow. From source → state → execution, without leaving the page.

Been away from X for two weeks. Heads down building. Coming back next week with something big for EVM Chronicle.

Something powerful is coming to EVM Chronicle next week. A new feature that changes how contract state is explored. Stay tuned.

@ProgrammerSmart awesome!!

Foundry live reload transcation graph and trace tx-graph-eight.vercel.app

In Solidity 0.8.x, unchecked blocks are usually intentional. Overflow alone is rarely the goal. Manual diffing is just a red flag to enter the math layer. From there, inspect everything related to the deviation. The real key is finding ways to compound it. Will share a thread soon on how to leverage this approach.

@Bitmay Have you ever hit a case where this trace + manual diff method revealed a sneaky overflow in unchecked arithmetic after SafeMath removal? What was the largest discrepancy you chased before finding the edge, please curious about real bounty-level examples if you're open to share!

First, the most important step is to read the code to understand how it works. And test some common patterns where we usually catch something. In this kind of pattern case, I go to Chronicle to find addresses that often interact with the target contract. Those repeated transactions give different sets of input amounts. Choose a few transactions with different set integer input amount. The fastest way is to look address balance History at Chronicle and pick different balance changes like 9, 13, 16, 19 digit change. Then trace each transaction and jump to the specific function that doing the math. I capture all variable values from SLOAD and compare the computation result in SSTORE with my manually calculated result. (see image) When a mismatch happens, we can explore a way to increase or decrease the difference. Simplest method we can start from the input set that produces the largest difference. Then tweak the first integer input segment, add or subtract depending what increases the difference, and increment step by step to find the edge. After that, move to the next integer input segment to go deeper on the edge. On some old contract overflow often occur with this method. For the underflow focus on decrease the difference and start from input set that produces lowest difference.

@bichistriver Array is enumerable because the key just incremented integer. EVM chronicle help show all key of mapping and array in contract automatically

I'm not comfortable with arrays in smart contract

@s_chiriac Onlyone EVMStorage Explorer @evmchronicle_io

Sell me your startup in 3 words! add link! 👇

@chiefofautism goodluck

someone built an entire AI RED TEAM - multiple agents that coordinate HACKING ATTACKS together, ZERO human input PentAGI, open source, one agent does recon, another scans, another exploits, another writes the report. they talk to each other and adapt based on what they find it ships as one docker container with nmap, metasploit, sqlmap, hydra preinstalled. the AI decides which tool to use and when. you point it at a target and walk away a red team engagement costs $30-50k and takes weeks. this is one docker command and API tokens

@cicada_HQ Nothing fancy, just integer abuse.

@Bitmay Old school overflow hunting with actual steps. Refreshing.

@0x_Scater source of claim?

Is it really possible to break 256-bit ECDSA using quantum computers today? I’m seeing claims about 126,000 qubits doing it in 9 hours. #Quantum #ecdsa #blockchain #securityconference