DYOR: Smart Contract Hash vs. Audit CheckSum w/ SHA256
DYOR: Smart Contract Hash vs. Audit CheckSum w/ SHA256
Loading saved threads...
Ryan · External communityPost link
External question — Ethereum Stack Exchange
Author: Ryan
Original post: https://ethereum.stackexchange.com/questions/165249
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
Stack Exchange,
First off I would like to say, as a grateful reader on many different stack forums, thank you all for the competent, articulate and drama-free solutions written on these pages. So many other discussion boards quickly turn into argumentative "king of the hill" style games. It's refreshing to be able to go to a stack forum and ALWAYS find something worth reading. Thank you all.
I have a problem that I can't seem to solve and I'm learning cryptocurrency with hopes to eventually run a node for various tokens... In an attempt to DYOR and hopefully profit on some ICOs I thought I would verify that these audit companies are actually doing a good job.
In an audit report that was done by a company cyber scope that specializes in audits, all of which are posted on their GitHub.
The ETF company in question advertises their smart contract address and I can see the source on EtherScan. It's got the green check mark and says that it's verified.
I'm not sure how this verification is done and I understand there could be some plausible ways that these values don't match up but The SHA 256 value of the two files that were verified for their smart contract do not match up to the SHA 256 values that I get if I can pile the source code individually.
Interestingly enough I have contacted both cybroscope and this ETF company by email and written communication and after a couple emails they understand exactly what I'm referring to they stop responding. Since then I've noticed that I'm no longer able to search by the company name on either scan to find these smart contracts I need the contract address, almost like after I mentioned it they are trying to hide this detail.
I'm concerned that the version of the smart contract that was audited was changed to be malicious in a sneaky way and I don't have enough knowledge about solidity to read it myself and if I can't verify the checksum what's the point of even having it?
We use checksums all the time to verify that it download is intact. I want to make sure that the smart contract code that's going to run at launch is actually the version that received the good audit. I made a very detailed post on Reddit in a subform specifically for this project and it was immediately flagged and removed. I inquired with the moderator as to why after reading their content policy and to refuse to give me anything more than extremely vague answer. Of course i was dissatisfied with this and politely explained that to him. It was at this point that i got permanently banned from the forum. Very frustrating.
I found a couple good articles that are similar or provide some background to discuss I have linked to those below.
Ultimately, I would like to know how I can carry out DYOR and verify that it's a trustworthy project etc etc.
Thanks!
What is a smart contract security audit?
Gas cost of a sha256 hash
Quote
Report
Lauri Peltonen · External communityPost link
External answer — Ethereum Stack Exchange
Author: Lauri Peltonen
Original post: https://ethereum.stackexchange.com/a/165250
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
Just to make sure: Etherscan verification is not related to any audits.
The verification means the source code has been published in Etherscan, and it's guaranteed to match the bytecode. There may be differences in comments and stuff like that, but the execution code should match the bytecode.
So, if you want to make sure that a project's code is secure, you can go through its source code in Etherscan yourself. If a project's source code isn't verified, it's typically a huge red flag and you shouldn't use it.
Quote
Report
Abraham P · External communityPost link
External answer — Ethereum Stack Exchange
Author: Abraham P
Original post: https://ethereum.stackexchange.com/a/172426
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
The existing answer is right that Etherscan's green check is not an audit. But the question you are actually asking,
"is the code at this address the code that was audited?"
, has a concrete answer, and a SHA-256 of the source files is the wrong tool for it.
Why your hashes don't match
A file hash changes if a single byte changes (line endings, comments, licence headers, import rewrites, file flattens, etc all trip this). Etherscan verification recompiles the submitted sources under the stated compiler version and settings, then checks the result against bytecode at the address. It
does not
compare source bytes at all. So two sources with different SHA-256 values can both verify, and a file hash printed in an audit report says nothing about what is deployed.
To actually understand whether the audit is representative, you need to go from "different" to "what changed".
1. Find exactly what was audited
A proper audit report should name its scope, pointing at a repository(or multiple) and a specific
commit hash
per repo. Sometimes they will even include a list of file hashes computed at that commit. Those commits are the only code the report speaks for. If the report gives file hashes but no repository or commit, nobody can reproduce what was hashed, which is a QA issue on the audit side worth considering in your analysis.
Also look for a fix review section. Findings are normally fixed after the report, in a later commit, so the code that should be deployed is the commit
after
the fixes. A finding marked "acknowledged" rather than "resolved" is still in the code either by choice, compromise, or simply through lack of care.
2. Diff the audited source against the verified source
Download the verified source from Etherscan (the Contract tab, or the API call
module=contract&action=getsourcecode
), check out the audited commit, and compare while ignoring whitespace:
git clone <repo> && cd <repo> && git checkout <audited-commit>
git diff --no-index -w src/Token.sol ../from-etherscan/Token.sol
If the Etherscan copy is flattened into one file, compare it contract by contract. Ignore the harmless differences (pragma, import lines, license header). Anything else is a change the audit did not see. You do not need to be a Solidity developer to read this: a new function, a changed
require
, a new
onlyOwner
path or a different fee number all stand out in a diff.
3. Or compare bytecode
If you can build the project, compile the audited commit with the exact compiler version, optimizer runs and EVM version shown on the Etherscan page, then compare with what is on-chain (Foundry shown here):
cast code <address> --rpc-url <rpc> # the deployed runtime bytecode
forge inspect Token deployedBytecode # what the audited commit compiles to
Expect exactly two legitimate differences: the metadata hash appended to the end of the bytecode, which changes with comments and file paths (see
contract metadata
in the Solidity docs), and
immutable
values that are filled in at deploy time. Everything else should be identical. Sourcify
full versus partial match
.
4. Check whether the code can change after you have checked it
If the contract is a proxy, the address stays the same while the code is replaced. Etherscan shows a "Read as Proxy" tab for these. For the standard pattern (
EIP-1967
) you can read the current implementation and admin straight from storage:
# current implementation
cast storage <address> 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc
# admin
cast storage <address> 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103
If the admin is a single ordinary wallet rather than a multisig or a timelock, the audited code can be swapped for anything at any time. The same applies, less dramatically, to owner-only functions that mint, change fees, blacklist or pause. An audit usually lists those as centralization risks.
What this means for your situation
An audit is a statement about one commit, under the assumptions that held on the day it was written. If deployed code differs from that commit, or someone with admin rights changes it, the audit is no longer representative. So the useful questions to put to a project are not "were you audited?" but: which commit was audited, is that what is deployed, and who can change it? If the project doesn't know or refuses to answer, that is, in and of itself, an answer (A bad one, to be clear)
Disclosure: I work at Fidesium, a smart contract security firm. The longer version of this, including which kinds of change mean an audit no longer covers the code and which do not, is here:
When does a smart contract audit actually expire?
Quote
Report
Post Reply
Quoted from Forex.com.bd-Editorial External answer — Ethereum Stack Exchange Author: Abraham P Source score (net votes, not local likes): 0 Original post: https://ethereum.stackexchange.com/a/172426 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. The existing answer is right that Etherscan's green check is not an audit. But the question you are actually asking, "is the code at this address the code that was audited?" , has a concrete answer, and a SHA-256 of the source files is the wrong tool for it. Why your hashes don't match A file hash changes if a single byte changes (line endings, comments, licence headers, import rewrites, file flattens, etc all trip this). Etherscan verification recompiles the submitted sources under the stated compiler version and settings, then checks the result against bytecode at the address. It does not compare source bytes at all. So two sources with different SHA-256 values can both verify, and a file hash printed in an audit report says nothing about what is deployed. To actually understand whether the audit is representative, you need to go from "different" to "what changed". 1. Find exactly what was audited A proper audit report should name its scope, pointing at a repository(or multiple) and a specific commit hash per repo. Sometimes they will even include a list of file hashes computed at that commit. Those commits are the only code the report speaks for. If the report gives file hashes but no repository or commit, nobody can reproduce what was hashed, which is a QA issue on the audit side worth considering in your analysis. Also look for a fix review section. Findings are normally fixed after the report, in a later commit, so the code that should be deployed is the commit after the fixes. A finding marked "acknowledged" rather than "resolved" is still in the code either by choice, compromise, or simply through lack of care. 2. Diff the audited source against the verified source Download the verified source from Etherscan (the Contract tab, or the API call module=contract&action=getsourcecode ), check out the audited commit, and compare while ignoring whitespace: git clone <repo> && cd <repo> && git checkout <audited-commit> git diff --no-index -w src/Token.sol ../from-etherscan/Token.sol If the Etherscan copy is flattened into one file, compare it contract by contract. Ignore the harmless differences (pragma, import lines, license header). Anything else is a change the audit did not see. You do not need to be a Solidity developer to read this: a new function, a changed require , a new onlyOwner path or a different fee number all stand out in a diff. 3. Or compare bytecode If you can build the project, compile the audited commit with the exact compiler version, optimizer runs and EVM version shown on the Etherscan page, then compare with what is on-chain (Foundry shown here): cast code <address> --rpc-url <rpc> # the deployed runtime bytecode forge inspect Token deployedBytecode # what the audited commit compiles to Expect exactly two legitimate differences: the metadata hash appended to the end of the bytecode, which changes with comments and file paths (see contract metadata in the Solidity docs), and immutable values that are filled in at deploy time. Everything else should be identical. Sourcify full versus partial match . 4. Check whether the code can change after you have checked it If the contract is a proxy, the address stays the same while the code is replaced. Etherscan shows a "Read as Proxy" tab for these. For the standard pattern ( EIP-1967 ) you can read the current implementation and admin straight from storage: # current implementation cast storage <address> 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc # admin cast storage <address> 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103 If the admin is a single ordinary wallet rather than a multisig or a timelock, the audited code can be swapped for anything at any time. The same applies, less dramatically, to owner-only functions that mint, change fees, blacklist or pause. An audit usually lists those as centralization risks. What this means for your situation An audit is a statement about one commit, under the assumptions that held on the day it was written. If deployed code differs from that commit, or someone with admin rights changes it, the audit is no longer representative. So the useful questions to put to a project are not "were you audited?" but: which commit was audited, is that what is deployed, and who can change it? If the project doesn't know or refuses to answer, that is, in and of itself, an answer (A bad one, to be clear) Disclosure: I work at Fidesium, a smart contract security firm. The longer version of this, including which kinds of change mean an audit no longer covers the code and which do not, is here: When does a smart contract audit actually expire?
Checking account access…