Skip to main content

Try it Live

Run Bytecode examples in the interactive playground

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:
  1. Function Selector Detection - Identifies function dispatch jump tables
  2. Payability Analysis - Detects CALLVALUE checks for non-payable modifiers
  3. State Mutability - Infers view/pure based on SLOAD/SSTORE presence
  4. Event Extraction - Finds PUSH32 + LOG patterns for event signatures
  5. Proxy Detection - Identifies proxy patterns (EIP-1967, etc.)

Detection Patterns

Function Selectors

Solidity function dispatchers follow predictable patterns:
The analyzer walks the jump table to extract all function selectors and their entry points.

Payability

Non-payable functions have guard checks:
Functions without this pattern are marked as payable.

State Mutability

Inferred from opcode usage:
OpcodesMutabilityMeaning
SSTORE presentnonpayableModifies state
Only SLOADviewReads state
No SLOAD/SSTOREpure (tentative)No state access
Has CALLVALUE checkspayableAccepts 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:
The PUSH32 value before a LOG instruction is extracted as an event topic hash.

Return Type

Reconstructed ABIs use generic bytes types since exact parameter structures cannot be determined from bytecode alone. Parameter names are always empty strings.

Usage Patterns

Interact with Unverified Contracts

Verify Deployed Contract

Detect Proxy Contracts

ABI Recovery for Lost Source

Compare Contract Versions

Limitations

ABI extraction from bytecode is heuristic-based and has fundamental limitations:

Cannot Determine

Exact parameter types - Only knows function takes inputs, not their structure ❌ Parameter names - No name information in bytecode ❌ Return types - Cannot distinguish between uint256, address, bytes32, etc. ❌ Function names - Only 4-byte selector hash available ❌ Event names - Only 32-byte topic hash available ❌ Struct layouts - Cannot reconstruct complex types ❌ Array dimensions - Cannot determine fixed vs dynamic arrays

May Miss

⚠️ Dynamic dispatch functions - Functions with computed jump targets ⚠️ Inline assembly routing - Custom dispatcher patterns ⚠️ Dead code - Unreachable functions may be detected anyway ⚠️ Optimized dispatchers - Non-standard jump table patterns

May Misclassify

🟡 State mutability - Limited by static analysis of reachable code 🟡 Payability - Edge cases with unconventional guard patterns 🟡 Proxy detection - May not detect custom proxy implementationsRecommendation: Use reconstructed ABIs for discovery and verification. For production interactions, always prefer verified source ABIs when available.

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:
CompilerVersionCompatibility
Solidity0.4.x - 0.8.x✅ Excellent - Standard jump tables
Vyper0.2.x - 0.3.x⚠️ Good - Some non-standard patterns
YulAny🟡 Variable - Depends on optimization
Hand-writtenN/A❌ Poor - No standard patterns
Solidity produces the most analyzable bytecode due to consistent function dispatcher patterns.

Performance

ABI extraction performance:
Bytecode SizeTimeFunctions Detected
Small (<5KB)<10ms~10 functions
Medium (10-15KB)~20ms~20-30 functions
Large (20-24KB)~50ms~50+ functions
Results are deterministic and can be cached. Re-running analysis on the same bytecode always produces identical results.

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:
  1. Compare with verified source when available
  2. Test function calls on testnets before mainnet
  3. Validate return data matches expected formats
  4. 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
Always verify contract source on Etherscan or similar before interacting based on reconstructed ABI.

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