shazow / whatsabi

Extract the ABI (and resolve proxies, and get other metadata) from Ethereum bytecode, even without source code.
https://shazow.github.io/whatsabi/
MIT License
1.04k stars 71 forks source link

Yul support? #37

Closed o-az closed 1 year ago

o-az commented 1 year ago

Can this get ABIs from a contract written in Yul? I tried to decompile a deployed Yul contract but no luck.

Read me says:

https://github.com/shazow/whatsabi/blob/cab00d3b562d04ef37fca240a0eb781c6afe8903/README.md?plain=1#L20

Contract: https://etherscan.io/address/0x24623e2C87bdF420204e21a75A5B6921950872b8

shazow commented 1 year ago

What kind of ABI result are you expecting from this contract?

WhatsABI doesn't care what language the bytecode was compiled from, but not all hand-written bytecode conforms to selector/ABI standards.

o-az commented 1 year ago

What kind of ABI result are you expecting from this contract?

WhatsABI doesn't care what language the bytecode was compiled from, but not all hand-written bytecode conforms to selector/ABI standards.

I don't know the ABI, this is why I tried to retrieve it with this tool. The smart contract is from here: https://docs.axiom.xyz/transparency-and-security/on-chain-zk-verifiers (AxiomV1 Historica Verifier).

Maybe I'm misunderstanding the utility of the tool?

shazow commented 1 year ago

What I mean is that not all code has an ABI, it's possible to write bytecode that does not have any standard entry points (via selector dispatch), or even non-standard ones. In this case, there's simply nothing for WhtasABI to return in that context, right?

Thanks for linking to the source of that project! I haven't written much Yul myself, let's see if we can figure it out.

If I'm reading that example source correctly: https://github.com/axiom-crypto/axiom-v1-contracts/blob/main/snark-verifiers/mainnet_17_7.v1.yul

Using this as a reference: https://docs.soliditylang.org/en/latest/yul.html#complete-erc20-example

It has nothing that calls calldataload and switches on that result, so there is no selector dispatch. If you go through the "runtime" object, there's just one function reference (functions in yul are internal by default), and it gets called as a helper in the various flat runtime context.

That is to say, if I'm reading this code correctly, there is no functionality switching behaviour based on calldata, it's all just one flat code path that gets executed regardless of what you pass into it. In other words, there is no ABI. :)

Does that make sense?

o-az commented 1 year ago

Thank you for clarifying. Learned something new!

shazow commented 1 year ago

Yay you're welcome, glad to hear it. :)