search

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

proxies: Load additional candidates from recent transactions? #84

Open SonOfMosiah opened 8 months ago

SonOfMosiah commented 8 months ago

Failed to get function selector from proxy: 0x54e3f31b

SonOfMosiah commented 8 months ago

https://arbiscan.io/address/0xDEF171Fe48CF0115B1d80b88dc8eAB59176FEe57#writeProxyContract#F3

shazow commented 8 months ago

Nice, thank you! I'm going to be sprinting on these next week I think, but might get to it earlier.

shazow commented 7 months ago

Okay, had some time to investigate what's going on here: They have their own custom proxy, selectors are set in setImplementation but the selector gets stored in an internal mapping(bytes4 => address) internal selectorVsRouter and unlike DiamondProxy there is no array of registered selectors that we can enumerate.

Which is to say, aside from the ABI uploaded to Etherscan, there's no plain-RPC way to determine which selectors have been registered (unless we have an archival node then we could try to find all of the calls to setImplementation).

That is to say, I don't think whatsabi will be able to resolve these proxy selectors blind, but whatsabi should be capable of fetching the uploaded ABI.

Looks like the mistake is when whatsabi.autoload detects that there's a proxy, it goes into code-based detection rather than still checking if there's an ABI to fetch. (Are uploaded ABIs always include the proxy? I feel like they often don't? What's the correct behaviour here for autoload?)

shazow commented 7 months ago

Actually, the proxy selectors aren't in the ABI (since otherwise it would violate the verification).

So Etherscan must be grabbing selectors from recent transactions. I could add a helper for that, but not sure if it's a good idea for default behaviour?