Web3 Decoder

Web3 Decoder ist eine Burp-Suite-Erweiterung, die dabei hilft zu analysieren, was bei den Operationen mit Smart Contracts des Web3 vor sich geht. Dabei handelt es sich hauptsächlich um JSON-RPC-Aufrufe an Ethereum-Knoten und Knoten anderer kompatibler Netzwerke (wie Polygon, Arbitrum, BSC...)

Download und Installation

Lade die neueste Erweiterungs-JAR herunter – dieser Link liefert immer die neueste Version:

⬇ web3-decoder.jar (neueste)

Ältere Versionen findest du auf der Releases-Seite.

Lade sie dann in Burp Suite:

1. Gehe zu Extensions → Installed → Add.
2. Setze Extension type auf Java und wähle die heruntergeladene web3-decoder.jar.
3. Klicke auf Next – sobald es geladen ist, erscheinen der Web3-Tab und die Editor-Tabs Web3 Request/Web3 Response.

Erfordert eine Burp-Version, die mit JRE 21 gebündelt ist (aktuelle Burp-Suite-Versionen). Die JAR ist eigenständig – alle Abhängigkeiten (web3j usw.) sind enthalten.

Aus dem Quellcode erstellen

./gradlew jar

Die Erweiterungs-JAR wird unabhängig von der Version immer in einen festen Pfad geschrieben – web3-decoder/build/libs/web3-decoder.jar –, sodass du Burp einmal darauf zeigen lassen kannst und sie bei Neubauten automatisch neu geladen wird. Das Releasing ist in docs/RELEASING.md dokumentiert.

Screenshots

So sehen unsere verbesserten Web3-Editor-Tabs nach dem erfolgreichen Dekodieren deiner JSON-RPC-Anfragen und -Antworten aus:

Darunter der neu gestaltete Web3-Tab mit allen Einstellungen, erkannten ABIs und mehr! (Danke an Claude Design!)

Dokumentation

Ausführliche Dokumentation befindet sich im Ordner docs/:

• Architektur — Ebenen, Komponenten und die wichtigsten Dekodier-/Kodierabläufe (mit Diagrammen).
• Projektstruktur — Verzeichnisstruktur und Verantwortlichkeiten pro Paket.
• Tech-Stack — Abhängigkeiten, Build/Packaging, Laufzeit und CLI-Modus.
• Funktionen — vollständiger Funktionskatalog mit Implementierungshinweisen.

API-Schlüssel für Block-Explorer

Die meisten unterstützten Block-Explorer wie etherscan.io erfordern einen API-Schlüssel, um mehr als 1 Anfrage pro 5 Sekunden zu erlauben.

Die neue Oberfläche ermöglicht dir die Verwaltung der Chains, Block-Explorer und API-Schlüssel.

Manuelles Hinzufügen der ABI eines Vertrags

Die Erweiterung zwischenspeichert die heruntergeladenen ABIs von den Block-Explorern wie Etherscan. Du kannst sie auch direkt aus dem Web3-Tab hinzufügen, indem du sie automatisch vom Block-Explorer abrufst oder manuell hinzufügst.

Implementierte Funktionen

• Burp-Integration
  • Editor-Tab Web3 Request für JSON-RPC-Anfragen (bei Traffic ohne eth_call / eth_sendRawTransaction ausgeblendet).
  • Editor-Tab Web3 Response für passende JSON-RPC-Antworten.
  • Eigener Web3-Suite-Tab mit Chain-/ABI-/Calldata-Werkzeugen.
  • Proxy-Verlaufseinträge, die in ihrer Notiz mit der dekodierten Funktionssignatur annotiert werden (dekodiert außerhalb des Threads, im Live-Verlaufseintrag gespeichert).
• Editor-Erlebnis beim Dekodieren
  • Beide Editor-Tabs bieten standardmäßig eine strukturierte Baumansicht, mit einer JSON-Ansicht nur einen Umschalter entfernt – das JSON bleibt die maßgebliche Quelle für das erneute Kodieren.
  • Die JSON-Ansicht behält Syntax- und semantische Hervorhebung, Zeilennummern, Klammerpaar-Abgleich, Live-Gültigkeit und eine Suchleiste.
• JSON-RPC-Anfrage-Dekodierung
  • Dekodiert eth_call-Calldata in function + typisierte args.
  • Unterstützt Einzelanfragen und Batch-JSON-RPC-Payloads.
  • Bei Batch-Payloads wird jedes Element mit Status (decoded, skipped, ) und Grund gemeldet, wenn es übersprungen/fehlgeschlagen ist.

Bisher unterstützte Chains

Die vollständige, aktuelle Liste der gebündelten Chains befindet sich in web3-decoder/src/main/resources/chains.json — die Erweiterung enthält jetzt den Etherscan-v2-Multichain-Satz (Ethereum, Sepolia, BNB Smart Chain, Polygon, Base, Arbitrum, Linea, Blast, Optimism, Avalanche, Gnosis, Scroll, Taiko, Berachain und viele weitere, einschließlich ihrer Testnets). Die Oberfläche ermöglicht es dir außerdem, zur Laufzeit eigene Chains hinzuzufügen – jede Chain, deren Block-Explorer Etherscan-ähnliche APIs bereitstellt, funktioniert. Weitere Details zur Chain-Verwaltung (einschließlich Migration veralteter Chain-IDs) findest du in Funktionen.

So funktioniert es

Die Erweiterung sendet eine eth_chainId-JSON-RPC-Anfrage an den verwendeten Knoten, um zu erkennen, an welcher Chain wir arbeiten, und wählt je nach Chain eine Block-Explorer-API aus, indem sie in der Datei chains.json sucht.

Um Funktionsaufrufe zu dekodieren, benötigen wir die ABI (Application Binary Interface) des Vertrags, die alle Funktionen enthält, die im Vertrag aufgerufen werden können, sowie deren Ein- und Ausgaben. Die Erweiterung löst ABIs in dieser Reihenfolge auf:

1. Gecachte ABI für die Chain + Vertragsadresse (Burp-projektspezifische Persistenz).
2. Builtin-ABIs für bekannte Verträge (z. B. Multicall3).
3. Block-Explorer-Lookup (Etherscan-kompatible API) für verifizierte Verträge.
4. Erkannter ABI-Pool – ABIs, die der passive Scanner aus Dapp-Frontend-Bundles herausgelöst hat, indiziert nach 4-Byte-Funktionsselektor. Chain-agnostisch.
5. 4byte-Fallback – Selektor → Signatur-Lookup gegen api.4byte.sourcify.dev, mit einer synthetischen ABI, die aus passenden Kandidaten erstellt wird.

Wenn die Chain-ID nicht ermittelt werden kann (z. B. weil der Endpunkt nicht auf eth_chainId antwortet), werden die chain-bezogenen Schritte (1–3) übersprungen und der Dekodierer versucht trotzdem die chain-agnostischen Schritte (4 und 5).

Externe Dienste und Datenquellen

Um Traffic zu dekodieren, spricht die Erweiterung einige externe Quellen an. Diese sind optional und du kannst sie im Web3-Tab deaktivieren. Alle ausgehenden Anfragen werden über Burps eigenen HTTP-Stack (api.http().sendRequest) gesendet, sodass sie Burps Upstream-Proxy-/TLS-Einstellungen respektieren und im Burp-Traffic erscheinen.

Hinweis zum Datenschutz: ABI-Suchen senden die Vertragsadresse an den konfigurierten Block-Explorer, und der 4byte-Fallback sendet den Funktionsselektor an api.4byte.sourcify.dev. Heruntergeladene ABIs werden lokal zwischengespeichert, sodass wiederholte Dekodierungen nicht erneut abfragen. Die meisten Explorer (z. B. etherscan.io) benötigen für mehr als ~1 Anfrage / 5 Sekunden einen API-Schlüssel – Schlüssel lassen sich im Web3-Tab verwalten.

Der passive ABI-Detektor liest HTTP-Antwortkörper, die Burp bereits erfasst hat, und läuft vollständig lokal – durch die Erkennung selbst wird kein Traffic erzeugt.