Last stretch for EVM Chronicle in the @Giveth Ethereum Security QF Round.
If you want to help push better Ethereum state research infrastructure forward, now is the time to support it.
https://t.co/E3uT5aALwE
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.
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.
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.
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.
Security tools should minimize metadata leakage.
When people are analyzing exploits or authorization logic, even browsing patterns can reveal intent. Self-hosted analytics is the right default.
Serious bug bounty hunters do not stop at the ABI.
They inspect storage.
EVM Chronicle lets you see the contract state the way the EVM does.
https://t.co/0fVzAMWZxx
I strongly prefer that infrastructure should be open, free, and built for long-term usefulness. Not "open" in name only, and not shaped by monetization pressure. When that holds, the community often finds its own ways to give back and sustain it.
The harder part is sustainability: how do we keep critical infrastructure alive without turning it into an API business or a VC-backed product?
Hopefully @thedaofund can help bring back the values that made the ecosystem community-driven in the first place.
We finally have an EVM storage tool that is easy to use and reads storage slots from on-chain contracts.
Very useful for auditing and debugging, and eliminates all the manual work required (after https://t.co/sm9LpXkqIf was taken down).
Check it out
https://t.co/7Qv3Z2Z6dz
As of today, EVM Storage Chronicle is the only publicly available Ethereum storage explorer providing realtime, full-history reconstructed contract storage.
Still early — testing, feedback, and bug reports are very welcome.
👉 https://t.co/OkT4K6O7Il