sourcify

Decentralized Solidity contract source code verification service

MIT License

Downloads
2.2K
Stars
737
Committers
130
View Code on GitHub Visit Website
Ecosystems: Ethereum, Solidity

Bot releases are visible (Hide)

sourcify - Release v2.2.1

Published by kuzdogan over 1 year ago

What's Changed

  • Fix Matomo configs after migration
  • Fixes for chain verification tests
  • New chains:
    • Dogechain (2000)
    • Symplexia Smart Chain (1149)
  • Turned off support for chains:
    • POA Sokol (77)
    • Boba Rinkeby (28)
    • Candle (534)
    • Darwinia Pangolin (43)
    • Gather Devnet (486217935)
    • Crystaleum (103090)
    • POA Core (99)
    • Astar (592)
    • Gnosis Chiado (10200)
    • Flare (14)
    • Optimism Bedrock Alpha (28528)

Note that on the prev PR named Release v2.2.1, the commit tag was not generated and no release was actually done.

Pull requests

New Contributors

Full Changelog: https://github.com/ethereum/sourcify/compare/v2.2.0...v2.2.1

sourcify - Release 2.2.0

Published by marcocastignoli over 1 year ago

What's Changed

Features

  • Verification with Standard JSON Input
  • Added support for new chains (295, 7668, 7672, 888, 999, and 7701)
  • Implemented a complete Metadata type
  • Generate variations of the metadata file in partial match to reach a full match
  • Added "Lookup Another" button in Lookup result
  • Add server monitoring capabilities to Grafana
  • Added GitHub star button

Fixes

  • Etherscan metadata variations
  • Fix EventManager fails if listeners are not set
  • Update h5ai-nginx submodule to the latest version
  • Fix how the UI handles non-checksummed addresses
  • Reorder the metadata object before generating the variations
  • Add test for not alphabetically sorted metadata
  • Disable chainId 51 getCreatorTx test
  • Re-enable SourcifyEventManager's listeners
  • Add a repository link to the create2 verified contracts
  • Use checkSupportedChainId instead of checkChainId for contract verification
  • Update typescript and typedoc in lib-sourcify
  • Handle libraries with call protection
  • Add nginx exporter for Prometheus
  • Improve the function to sanitize path at storeSources
  • Display the create2 repo link only for create2 results
  • Fix abitype req. typescript v5+
  • Show error on bad Etherscan req
  • Change OPTIMISTIC_ETHERSCAN to OPTIMISMSCAN
  • Revert accidentally setting sed to gsed
  • Fix matchWithCreationTx by decoding the constructor arguments
  • Test for paths in metadata containing multiple ../
  • Fix linter errors and warnings

Fixed vulnerabilities

Thanks to @Hellobloc for reporting the following vulnerabilities.

Summary

When the file path is saved with ../ as prefix, the file is potentially saved in other locations in the repository.

Example

immagine

Solution

The solidity compiler collapses all the /../ components in the path, the same algorithm was implemented in Sourcify to fix the path traversal vulnerability.

Summary

The start_with vulnerability enables arbitrary source code verification.

When comparing Creation Code, bytecode comparison is performed using the start_with function. This is designed to facilitate source code validation when constructor arguments are present.

However, relying solely on start_with for source code validation without verifying constructor arguments can introduce risks.

In particular, it is possible to create contract source code without compilation results by utilizing abstract and interface contracts. Such source code can pass the start_with check for any contract bytecode.

Example

https://github.com/Hellobloc/verify/tree/test_start_with
https://repo.staging.sourcify.dev/contracts/partial_match/5/0x5ea1E75790b86C4c5Db5e7c7A1fa14d683D50Cfe/sources/contracts/

Solution

This problem is solved by decoding the rest of the bytecode after startsWith assuming it is the ABI encoded constructor arguments part. If the decoding fails, an error is thrown.

PRs

New Contributors

Full Changelog: https://github.com/ethereum/sourcify/compare/v2.1.1...v2.2.0

sourcify - Release 2.1.1

Published by marcocastignoli over 1 year ago

What's Changed

Removed verification through simulation because of the potential vulnerability to "hijack" a contract verification by embedding the deployed bytecode inside the constructor in assembly.

Thanks to @Hellobloc and @samczsun for reporting the following vulnerabilities.

Fixed vulnerability

Summary

Given a partial or unverified contract, it is possible to "fully verify" any contract by just returning the deployed (onchain) bytecode of the contract inside the constructor in assembly. The verified source file would then not contain the original source file but just a few lines of code with the raw deployed bytecode.

Example

  1. Given a partial match on Sourcify (you can use Import from Etherscan for 0x345a7c9325E7145CA7E8aafabf474361E6c674D5 on Goerli)
  2. Download this repo: https://github.com/Hellobloc/verify
  3. Edit the file final2.sol as follows
pragma solidity ^0.5.10;
contract Deployer {
    constructor() public {
        bytes memory bytecode = hex'6080604052348015600f57600080fd5b506004361060285760003560e01c8063d1524f7414602d575b600080fd5b60336075565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b6000809054906101000a900473ffffffffffffffffffffffffffffffffffffffff168156fea265627a7a72315820b59b9ccfbe01c3596a27c9bf3fc5728c39c25d61c263777e6e6a96dbb69a677a64736f6c63430005110032';
        assembly {
            return (add(bytecode, 0x20), mload(bytecode))
        }
    }
}
  1. Generate the keccak256 of that file and update the keccak256 field of final2.sol in the metadata.json
  2. Use Sourcify's API to verify the contract

Explanation

The function verifyDeployed tries to verify the contract with different methods, in order:

  1. matchWithDeployedBytecode: compare the deployed runtime bytecode with the recompiled runtime bytecode
  2. matchWithSimulation: execute the recompiled creation bytecode on an EVM (hence "simulation"), which will produce a runtime bytecode and compare it with the deployed one
  3. matchWithCreationTx

When using Sourcify's API to verify the ´Hellobloc/verify´ contract:

  • matchWithDeployedBytecode fails because recompiled runtime bytecode and the onchain runtime bytecode differ:

recompiled runtime bytecode:

0x6080604052600080fdfea265627a7a72315820ff612b856b9428c30f2fecfa6f13c7a7ee8d459a3c22f6c8a900e7a0459aba5f64736f6c63430005110032

onchain runtime bytecode:

0x6080604052348015600f57600080fd5b506004361060285760003560e01c8063d1524f7414602d575b600080fd5b60336075565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b6000809054906101000a900473ffffffffffffffffffffffffffffffffffffffff168156fea265627a7a72315820b59b9ccfbe01c3596a27c9bf3fc5728c39c25d61c263777e6e6a96dbb69a677a64736f6c63430005110032
  • matchWithSimulation succeed because it actually produces the same runtime bytecode as the deployed runtime bytecode

Solution

We've considered several solutions:

  1. If during matchWithDeployedBytecode we find that the length of the “trimmed” part of runtime bytecode differs then we are probably sure that the contract is neither a partial or a perfect match.
    • We don’t solve the issue because a malicious code could force the length to be the same.
  2. Checking the equivalence of the metadata hash after a perfect match.
  • This case makes use of this fact: the malicious file that generated a "perfect bytecode" needs a fake metadata (recall we modified the keccak256 above). Till now we assumed that if the compiler generated a "perfect runtime bytecode" then it was also true that the provided metadata was the correct one, but that's not the case. In this case, because assembly code is utilized, the "simulation" returns a "perfect runtime bytecode" but in fact the metadata hash of the metadata JSON, output from the recompilation is different than what's in the onchain CBOR encoded part.
  • However this method is not resolved for partial matches.
  1. **Remove matchWithSimulation**
    The vulnerability comes from this functionality. We were already considering removing this verification as with the recent addition of immutableRefences to verification, we wouldn't need alternative verifications for contracts with immutables.

We decided to comment out matchWithSimulation type verification and eventually remove it from the codebase.

Full Changelog: https://github.com/ethereum/sourcify/compare/v2.1.0...v2.1.1

sourcify - v2.1.0

Published by kuzdogan over 1 year ago

What's Changed

  • Added basic test coverage
  • Fix: Handling Etherscan contracts with multiple sources
  • Use the respective solc binary according to the platform, save binaries locally
  • Update Etherscan chains
    • Users can now import contracts from other Etherscan instances: Polygonscan, Snowtrace etc.
  • Make use of immutableReferences on verification
    • This lets us verify contracts with immutables very often without needing alternative methods such as looking at the creatorTxHash or "simulation"
  • Fix addLibraryAddresses potential vulnerability with regex.

Fixed vulnerability

Thanks to @Hellobloc and @samczsun for reporting the vulnerability.

Risk Description

Previously the following code was used to replace libraryAddresses.

export function addLibraryAddresses(
  template: string,
  real: string
): {
  replaced: string;
  libraryMap: StringMap;
} {
  const PLACEHOLDER_START = '__$';
  const PLACEHOLDER_LENGTH = 40;

  const libraryMap: StringMap = {};

  let index = template.indexOf(PLACEHOLDER_START);
  for (; index !== -1; index = template.indexOf(PLACEHOLDER_START)) {
    const placeholder = template.slice(index, index + PLACEHOLDER_LENGTH);
    const address = real.slice(index, index + PLACEHOLDER_LENGTH);
    libraryMap[placeholder] = address;
    const regexCompatiblePlaceholder = placeholder
      .replace('__$', '__\\\\$')
      .replace('$__', '\\\\$__');
    const regex = RegExp(regexCompatiblePlaceholder, 'g');
    template = template.replace(regex, address);
  }
  return {
    replaced: template,
    libraryMap,
  };
}

The code replaced the library placeholders in the bytecode by identifying __$ and constructed regular matching expressions from the placeholder.
But note that not all versions use the hash of the library name as a placeholder. For example, the 0.4 Solidity version uses __{Path:FileName}__ placeholder.

https://i.imgur.com/BTSFsmO.png

This allows a malicious user to manipulate regular expressions, which in turn allows other parts of the bytecode to be marked as a library address.

Example

As with the risks mentioned above, we can achieve arbitrary regular expression tampering by changing the file name of the library contract.
An example is the following:

pragma solidity ^0.4.0;
import "./$.{37}|2{40}|cantbematchedcharacters__";
contract A {
    address constant public a = address(0x2222222222222222222222222222222222222222);
    uint public b;
    function cc() public{
        b = L_.get4();
    }
}

In the above code, a regular expression is written in the filename and the expression appears in the generated bytecode and is adopted by the addLibraryAddresses function.

https://i.imgur.com/gpsm01V.png

This regular expression will first replace itself, and then look for 22...22 to do the same. Here 2{40} can also be modified to 5b.{...} to perform arbitrary replacements of executable bytecode.

A real attack case(0x4AD29c9716569f3c466BB123Efdd0B9B43207dE1 in goerli) was constructed.

https://i.imgur.com/vU5KhnD.png

https://i.imgur.com/gwNwRLR.png

The tampering of constants in the above case is possible. Of course executable bytecode tampering is also possible, simply by changing
2{40} to 5b.{...}, and writing L_ address to the bytecode we want.

DOS Attack

In addition to performing bytecode tampering, one can also perform a DOS attack on Sourcify. Specifically, once can design a regular expression that will not have any matches in bytecode, resulting in __$ not being replaced, which in turn makes addLibraryAddresses a dead loop.

Solution

We replaced the regex replacement of the pattern with a simple string match to __ in the bytecode, and replacing the placeholder with a fixed length (40 chars = 20 bytes).

PRs

New Contributors

Full Changelog: https://github.com/ethereum/sourcify/compare/v2.0.0...v2.1.0

sourcify - v2.0.0

Published by kuzdogan over 1 year ago

This is the release for the v2 of Sourcify. It is a MAJOR release because of the significant changes to the codebase. The server API does not have breaking changes but has additions.

  • Codebase refactoring with lib-sourcify library:
    • Removes the old npm packages @ethereum-sourcify/core -verification and -validation.
    • Maintain the main verification functionality in a reusable package @ethereum-sourcify/lib-sourcify, including types etc.
  • Fix Etherscan regex for the new Etherscan
  • Fix created contract address calculation with the nonce
  • Add monitoring support to Meter Network
  • Use local IPFS gateway in tests instead of ipfs.io/ipfs
  • Add creatorTxHash parameter to verification API
  • New Chains:
    • Bear Network Chain Mainnet #641230
    • Base Goerli Testnet #938

What's Changed

Full Changelog: https://github.com/ethereum/sourcify/compare/v1.2.2...v2.0.0

sourcify - v1.2.2

Published by kuzdogan over 1 year ago

What's Changed

Full Changelog: https://github.com/ethereum/sourcify/compare/v1.2.1...v1.2.2

sourcify - v1.2.1

Published by marcocastignoli over 1 year ago

New Contributors

Full Changelog: https://github.com/ethereum/sourcify/compare/v1.2.0...v1.2.1

sourcify - v1.2.0

Published by kuzdogan almost 2 years ago

New Contributors

Full Changelog: https://github.com/ethereum/sourcify/compare/v1.1.0...v1.2.0

sourcify - v1.1.0

Published by marcocastignoli almost 2 years ago

  • create2
  • import from contract
  • repository now rewrites url
  • added chains (8217, 10200, 336, 28428)
  • npm script to update chains
  • bytecode-utils
  • typescript strict null check
sourcify - v1.0.1

Published by marcocastignoli almost 2 years ago

The release includes:

  • add chain 592, 1001
  • ui fixes for mobile
  • remove kovan and ropsten support for both L1 and L2
sourcify - v1.0.0

Published by marcocastignoli about 2 years ago

Initial release for Sourcify.

Sourcify is a Solidity source code and metadata verification tool and repository and acts as a base layer allowing other tools build on top of it. We aim to keep as much as smart contract metadata and verified source code open and available via IPFS, and facilitate an improved smart contract UX with verified sources and decoded transactions.

The release includes:

  • Server
  • Monitor
  • UI
  • Repository
  • external services: IPFS, s3
  • packages
    • verification
    • validation
    • core

https://sourcify.dev

Package Rankings
Top 3.42% on Npmjs.org
Top 6.75% on Proxy.golang.org
Badges
Extracted from project README
codecov
Related Projects
dethcode

View source of deployed Ethereum contracts in VSCode

14 Dec 2021 1,359
TypeChain

🔌 TypeScript bindings for Ethereum smart contracts

02 Sep 2017 2,707
solgo

Solidity parser in Go, designed to transform Solidity code into a structured format for enhanced ...

28 Jun 2023 2
eth.rb

a straightforward library to build, sign, and broadcast ethereum transactions anywhere you can ru...

29 Nov 2021 201
full-blockchain-solidity-course-py

Ultimate Solidity, Blockchain, and Smart Contract - Beginner to Expert Full Course | Python Edition

27 Jul 2021 10,759
fe

Emerging smart contract language for the Ethereum blockchain.

10 Aug 2019 1,559
smart-contract-sanctuary

🐦🌴🌴🌴🦕 A home for ethereum smart contracts. 🏠

19 Jun 2018 1,467
chainify

Blockchain abstraction layer

20 Apr 2018 219
solidity

Solidity, the Smart Contract Programming Language

17 Aug 2015 22,570
whatsabi

Extract the ABI (and resolve proxies, and get other metadata) from Ethereum bytecode, even withou...

22 Sep 2022 1,047
chainlink

node of the decentralized oracle network, bridging on and off-chain computation

20 Nov 2017 6,974
q-diplomacy

A protocol for quadratic contributions

05 Aug 2021 3
token-erc-20

This is an example of implementation in solidity language of an ERC-20 standard Ethereum Token, m...

31 May 2020 44
chains

provides metadata for chains

20 Dec 2018 8,230
hardhat-js-starterkit

hardhat environment starterkit for testing and deployment of smart contracts

10 May 2021 17