Skip to content
This repository was archived by the owner on Jun 24, 2026. It is now read-only.
This repository was archived by the owner on Jun 24, 2026. It is now read-only.

Manticore removes only one metadata Swarm hash #909

Open

Description

@juli

The Solidity compiler automatically generates a JSON file, the contract metadata. The compiler appends a Swarm hash of the metadata file to the end of the bytecode. Some contracts have more than one metadata hash but Manticore only removes one.

Instead of a fixed length, an iteration should be added to the def _without_metadata method:

@staticmethod
def _without_metadata(bytecode):
end = None
if bytecode[-43: -34] == '\xa1\x65\x62\x7a\x7a\x72\x30\x58\x20' \
and bytecode[-2:] == '\x00\x29':
end = -9 - 32 - 2 # Size of metadata at the end of most contracts
return bytecode[:end]

Activity

  1. disconnect3d commented on Jan 15, 2019

    @disconnect3d
    Member

    @juli hey, I know it has been some time, but can you add some example of Some contracts have more than one metadata hash?

    The _without_metadata is used e.g. in calculate_coverage, so I believe it might introduce some bad bugs related to the coverage we report and so I added a high-priority here.

  2. juli commented on Jan 23, 2020

    @juli
    Author

    I found more instances of broken metadata and now I think it's a solc bug, but I didn't have time to investigate it further.

  3. chriseth commented on Jan 23, 2020

    @chriseth

    This is probably caused by a contract (X) creating another one (Y): Since Y's creation code is part of X's bytecode, also Y's metadata hash can be found there.

  4. juli commented on Jan 23, 2020

    @juli
    Author

    Thanks to @emiliorizzo I have a sample:
    End of bytecode metadata:

    a165627a7a723058207b86d41905245d0cddab03c40602fcba860db843231d0189039c19578fc091c30029526f6c65733a206163636f756e7420697320746865207a65726f2061646472657373
    Look at the end, it is ASCII:
    \x86\xd4\x19\x05$]\x0c\xdd\xab\x03\xc4\x06\x02\xfc\xba\x86\r\xb8C#\x1d\x01\x89\x03\x9c\x19W\x8f\xc0\x91\xc3\x00)Roles: account is the zero address

    Looks like an uninitialized memory issue to me.

  5. spalladino commented on Jan 23, 2020

    @spalladino

    @juli since a 5.x version, Solidity changed how string constants are stored in bytecode. If you have a string literal in the constructor, such as a revert reason, those are stored at the very end of the contract bytecode, even after the metadata hash. It seems like this is the case here.

  6. chriseth commented on Jan 23, 2020

    @chriseth

    This applies to all constants and goes back a long time (at least pre 0.3.1). It might be that it 0.5.x we changed how the costs are calculated for that optimizer method, so it was used more often.

  7. spalladino commented on Jan 23, 2020

    @spalladino

    Indeed, I think it was 0.5.2:

    Code Generator: Use codecopy for string constants more aggressively.

  8. montyly commented on Jan 24, 2020

    @montyly
    Contributor

    Thanks, @juli, @chriseth, and @spalladino for pointing this out and providing all these details.

    I was not aware of the string literal in the constructor corner case.

    It looks like we are not supporting also newer versions of the metadata. For the long run, I think we should move the metadata responsibility to crytic-compile.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions