Try it Live
Run Bytecode examples in the interactive playground
- C
bytecode_to_abi(bytecode_t bytecode) const char*
TypeScript implementation only. ABI reverse engineering not available in C.How It Works
toAbi() analyzes bytecode to extract interface information by:
- Function Selector Detection - Identifies function dispatch jump tables
- Payability Analysis - Detects CALLVALUE checks for non-payable modifiers
- State Mutability - Infers view/pure based on SLOAD/SSTORE presence
- Event Extraction - Finds PUSH32 + LOG patterns for event signatures
- Proxy Detection - Identifies proxy patterns (EIP-1967, etc.)
Detection Patterns
Function Selectors
Solidity function dispatchers follow predictable patterns:Payability
Non-payable functions have guard checks:payable.
State Mutability
Inferred from opcode usage:| Opcodes | Mutability | Meaning |
|---|---|---|
| SSTORE present | nonpayable | Modifies state |
| Only SLOAD | view | Reads state |
| No SLOAD/SSTORE | pure (tentative) | No state access |
| Has CALLVALUE checks | payable | Accepts ETH |
State mutability inference has limitations with dynamic jumps. Functions may be incorrectly classified if control flow cannot be fully analyzed.
Events
Event signatures detected from LOG patterns:Return Type
Usage Patterns
Interact with Unverified Contracts
Verify Deployed Contract
Detect Proxy Contracts
ABI Recovery for Lost Source
Compare Contract Versions
Limitations
What Works Reliably
✅ Function selector extraction (standard Solidity) ✅ Payability detection (CALLVALUE patterns) ✅ Event topic hashes (PUSH32 + LOG patterns) ✅ Basic state mutability (view vs nonpayable) ✅ Proxy detection (EIP-1967, minimal proxies)Compiler Compatibility
Works best with standard compiler output:| Compiler | Version | Compatibility |
|---|---|---|
| Solidity | 0.4.x - 0.8.x | ✅ Excellent - Standard jump tables |
| Vyper | 0.2.x - 0.3.x | ⚠️ Good - Some non-standard patterns |
| Yul | Any | 🟡 Variable - Depends on optimization |
| Hand-written | N/A | ❌ Poor - No standard patterns |
Performance
ABI extraction performance:| Bytecode Size | Time | Functions Detected |
|---|---|---|
| Small (<5KB) | <10ms | ~10 functions |
| Medium (10-15KB) | ~20ms | ~20-30 functions |
| Large (20-24KB) | ~50ms | ~50+ functions |
Integration with Abi Module
Reconstructed ABIs are compatible with Abi module methods:Since reconstructed ABIs use generic
bytes types, encoding/decoding may require manual type casting or ABI augmentation with known signatures.Security Considerations
Verification
Never trust reconstructed ABIs for production without verification:- Compare with verified source when available
- Test function calls on testnets before mainnet
- Validate return data matches expected formats
- Check for proxy patterns that might delegate to different implementations
Bytecode Manipulation
Malicious contracts may:- Include fake function selectors in unused code paths
- Use dynamic dispatch to hide actual functions
- Manipulate jump tables to evade analysis
- Include misleading event signatures
Privacy
ABI extraction may reveal:- Internal function structure (even if not in public ABI)
- Proxy implementation details
- Factory patterns and CREATE2 addresses
- Compiler version and optimization settings
Advanced Usage
Augment Reconstructed ABI
Detect Compiler Version
Extract Initialization Code
See Also
- Abi - ABI encoding/decoding and formatting
- analyze - Complete bytecode analysis
- detectFusions - Pattern detection used internally
- EventLog - Working with decoded events
References
- WhatsABI - Underlying reverse engineering library
- Function Selector Database - Map selectors to signatures
- Ethereum Signature Database - Alternative selector lookup
- EIP-1967 - Proxy storage slots

