Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Benchmarking the decompile module of heimdall #285

Open
sifislag opened this issue Jan 10, 2024 · 1 comment
Open

Benchmarking the decompile module of heimdall #285

sifislag opened this issue Jan 10, 2024 · 1 comment
Labels
T-question Type: question

Comments

@sifislag
Copy link

Component

Other (please specify)

Question

Hi,
I'm working on the Gigahorse decompiler and I'm interested in evaluating it against heimdall.
In the past for black-box comparisons we've opted for high-level metrics, mainly:

  • Number of call signatures used in external calls
  • number of event signatures in emitted events

Wanted to create an issue to verify that I'm using heimdall correctly.

I'm invoking it using: heimdall decompile filename -vvv -d --include-sol --skip-resolving. Any other flags I should be aware of?

Code to identify external call sigs (recognize lines that are like *call*(abi.encode(selector_hex, ...):

    selectors = set()
    for call in [line  for line in text if "call" in line]:
        if "abi.encode" not in call:
            continue
        selectors.add(call.split("abi.encode(")[1][:10])

    selectors_filtered = set([sel for sel in selectors if sel.startswith("0x")])

Code to identify event sigs (recognize lines that are like emit Event_event_sig(...):

    event_sigs = set()
    for event in [line  for line in text if "emit Event_" in line]:
        event_sigs.add(event.split("emit Event_")[1][:8])

Do the above seem about right or can external calls and events appear in the decompiler output in a different way?
I'd also like to have some more low-level metrics (for example bytecode block reachable from contract's public function) but these would probably be harder to get.

Thanks,
Sifis

@sifislag sifislag added the T-question Type: question label Jan 10, 2024
@Jon-Becker
Copy link
Owner

Hey! Sorry for the late reply, been pretty busy lately.

That seems to be accurate so far, but it might be easier to parse the yul output: --include-yul over solidity.

as an aside, im drastically improving the decompilation output now :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-question Type: question
Projects
None yet
Development

No branches or pull requests

2 participants