DeFi hacks are more common than anyone would like. In 2024, $2.2 billion USD was stolen in smart contract hacks and exploits, a 17% increase from 2023 (source: TRM Labs). These incidents happen all too often, even from fairly basic vulnerabilities. While efforts continue to prevent these hacks, blockchain investigators must know how to analyze and understand these thefts when they occur.

Reviewing a DeFi hack requires skill and knowledge, but I’m convinced that with modern tooling, anyone with general knowledge of smart contract architectures and code can decipher an exploit. In other words, anyone can perform a post-exploit analysis: discovering what happened (event analysis), how it happened (call data mechanics), and why it was possible (code vulnerability).

Here I’ll share my experience learning this systematic, very learnable process of post-exploit analysis.

Phase 1: High-Level Overview

The first goal is understanding the big picture. Starting with the theft transaction hash, examine it in a block explorer like Etherscan. You want to identify:

• Financial impact: How much was stolen and what tokens were involved

• Fund flow patterns: Movement from victim to attacker addresses

• Attack infrastructure: What addresses are involved (attackers, victims, intermediaries)

• Attack complexity: Single transaction vs. multi-block, flash loans, cross-chain components

• Timeline indicators: When the attack occurred and its duration

This high-level view prevents you from getting lost in technical details before understanding the scope and nature of the incident. Think of it as surveying the crime scene before examining individual pieces of evidence.

Phase 2: Event Log Analysis

Once you understand the context, dive into the transaction’s event logs. Every block explorer has a “Logs” tab showing emitted events, which often tell a clearer story than raw transaction data.

Why event logs matter: Smart contracts emit events to record important state changes. Unlike call data (which shows function inputs), events show the results of those function calls — transfers, state updates, and protocol interactions.

Take the SuperRare staking contract exploit I analyzed LINK HERE. The event logs revealed this sequence:

• Log 0: NewClaimRootAdded — Evidence of merkle root manipulation

• Log 1: Transfer — 11.9M RARE tokens moved from victim to attacker

• Log 2: TokensClaimed — Successful claim using the manipulated root

• Log 3: Attack confirmation — Custom event from attacker’s contract

This immediately suggested the vulnerability involved merkle root manipulation in a claiming mechanism, before even looking at the code.

Pro tip: Events are often more reliable than call traces for understanding fund movements and state changes, especially in complex multi-contract interactions.

Phase 3: Call Data Analysis

Now examine how those events were triggered by analyzing the actual function calls. This is where you move beyond Etherscan to specialized tools like Tenderly, Phalcon, or samczsun’s transaction viewer.

Why call data analysis matters: While events show what happened, call data reveals the mechanical how: the specific functions called, parameters passed, and execution flow that enabled the exploit.

Call data vs. event logs:

• Event logs: Show what happened: the results and state changes

• Call data: Shows how it happened: the specific functions and parameters used

• Source code: Reveals why it was possible: the underlying vulnerability

These advanced tools excel at:

• Function signature decoding: Converting raw hex data into readable function calls

• Parameter analysis: Understanding what values were passed to exploit functions

• Execution flow mapping: Seeing the exact sequence of contract interactions

• Gas usage patterns: Identifying unusual or complex execution paths

For complex attacks involving multiple contracts, reentrancy, or flash loans, call data analysis becomes essential. The tools can trace through intricate execution paths that would be nearly impossible to follow manually.

Key insight: Modern attacks often use legitimate protocol features in unintended ways. Call data analysis helps you understand exactly which legitimate functions were chained together to create the exploit.

Phase 4: Source Code Deep Dive

With your attack theory from the previous phases, now examine the actual smart contract code to understand why the exploit was possible. This is where you validate your dynamic analysis with static code review to find the root cause vulnerability. You can also use the support of tools like Copilot and Claude to examine the exact functions you know were called. This works well since you already know what functions were called and where to put your focus.

Contract discovery strategy:

• Verified contracts: Direct analysis on Etherscan

• Unverified contracts: Use Dedaub for bytecode decompilation

• Proxy contracts: Navigate to implementation contracts for actual logic

Look for the specific vulnerable function identified in your call data analysis. In the SuperRare case, this led to discovering a critical logic error in the access control:

// Vulnerable code — incorrect boolean logic

require((msg.sender != owner() || msg.sender != authorizedAddress),

“Not authorized”);

//

The flaw: This should have used && instead of ||, making the function accessible to anyone except when the caller was simultaneously both owner AND authorized address — an impossible condition.

This example is pretty straightforward and most people could catch just manually reviewing. But if you follow the systematic process of finding what and how answers before doing the code review, you should be able to discover the code vulnerability with the help of tools like Copilot since you know what functions to focus on.

Phase 5: Attack Flow Reconstruction

Finally, piece together the complete attack sequence to ensure your analysis explains all observed behaviors:

1. Step-by-step validation: Does each phase of your analysis logically lead to the next?

2. Event correlation: Do all transaction events align with your technical explanation?

3. Fund flow verification: Does the money movement match your vulnerability analysis?

4. Edge case consideration: Are there any unexplained behaviors or inconsistencies?

This validation step separates thorough analysis from superficial investigation. Professional blockchain investigators always verify their theories against all available evidence.

You could also write a proof of concept on the contract bug that you found to prove the vulnerability.

Building Your Investigation Skills

Start with documented exploits: Practice on well-known hacks from Rekt.news or security researchers’ blogs where you can check your analysis against expert explanations.

Master your tools: Develop fluency with different platforms:

• Etherscan: High-level overview and verified contract analysis

• Tenderly: Step-by-step debugging and simulation

• samczsun’s tx viewer: Detailed call traces with storage changes

• Dedaub: Unverified contract decompilation

Recognize patterns: Common exploit types (flash loan attacks, price manipulation, access control failures) have recognizable signatures in both event logs and call data.

Conclusion

Post-exploit analysis is a systematic, learnable skill. By following this phase-based approach from high-level overview through detailed call analysis to source code confirmation, you can deconstruct even complex DeFi exploits.

The key is methodical progression: understand the big picture before diving into technical details, use event logs and call data as complementary investigation tools, focus the code review on known functions called, and always validate your theories against all available evidence.

As DeFi continues evolving, these investigation skills become increasingly valuable for security researchers, protocol developers, and anyone involved in blockchain security. The tools are available, the methodology is proven and now it’s time to practice.