by Shelven Zhou (x: @zhou49) and Hang Yin (x: @bgmshana) from Phala Network

What Happened in the Bybit Hack?

Imagine you’re sending a letter to your friend, but a sneaky thief swaps your friend’s address with theirs. You don’t notice because the envelope looks the same, so you seal it and mail it. That’s basically what happened in the Bybit hack—but with billions of dollars. Let’s break it down and see how TEE (Trusted Execution Environment) could have stopped it.

1. The Weak Link: A developer working on Safe{Wallet} got hacked. Attackers secretly added malicious code to the wallet service (JaveScript hosted in AWS).

2. The Trap: When Bybit used this compromised wallet to manage their cold storage, the malicious code altered transactions. Instead of sending money to the intended recipient, it rerouted funds to the attacker’s wallet.

3. Blind Signing: The hardware ledger used to approve transactions only showed a transaction hash—a jumble of letters and numbers that acts like a summary. Bybit’s team didn’t realize the details behind the hash were malicious, so they approved the transactions blindly.

Result: Attackers stole funds because no one double-checked the actual transaction details—like verifying the address on that envelope.

Problem Analysis: Why the Hack Succeeded

The Bybit attack exploited two systemic weaknesses in crypto infrastructure:

1. Code Supply Chain Vulnerability

The attacker didn’t need to hack the wallet’s frontend or hosting service. Instead, they compromised a trusted developer’s credentials to push malicious code directly into the official codebase. This made the attack invisible to users:

• Legitimacy by Design: The code update appeared "legitimate" to repositories and hosting platforms. Users unknowingly ran poisoned software, assuming it was safe.

• Decentralized Frontends Aren’t Enough: Even decentralized frontends (like IPFS) would fail here—the malicious code was signed and approved at the source.

Key Insight:

This attack highlights why code audits and on-chain governance are critical. Without cryptographic proof of code integrity (e.g., on-chain hashes), projects cannot distinguish "official" code from weaponized updates.

2. Blind Signing: A Fatal Flaw

Hardware wallets (like Ledger) are designed to secure private keys, but they fail at a critical task: transaction transparency.

• The Silent Swap: A compromised frontend can replace a valid transaction with a malicious one before sending it to the hardware wallet.

• Complex Transactions = Blind Spots:
• Simple transfers (e.g., “Send 1 ETH to Alice”) are readable on hardware wallet screens.
• Complex interactions (e.g., multisig approvals, smart contract calls) often display only raw hex data or nothing at all. Users are forced to sign blindly.

Key Insight:

Hardware wallets act as “dumb signers”—they cryptographically approve any data they receive. Without a way to verify the semantic meaning of transactions (e.g., “You’re granting unlimited USDC withdrawals”), users become easy targets.

Why Existing Protections Failed

• Code Signing ≠ Code Truth: Traditional code-signing certificates verify authorship, not intent. A malicious update from a hacked developer still appears “trusted.”

• Hardware Wallets Lack Context: They confirm mathematical validity (a valid signature) but not logical validity (is this transaction a drainer?).

This dual failure created the perfect storm: weaponized code and a signing process that hid the attack.

TL;DR on TEEs

• What they do:
• Run code in a locked-down, private environment.
• Generate proofs to verify what code ran.

• What they don’t do:
• Stop you from running bad code (audits still matter!).
• Replace blockchains—they complement them.

Bybit’s hack exploited unverified code and blind signing. TEEs fix both issues—if you use them wisely. 🛡️

How Could This Have Been Prevented?

1. For Project Owners: Lock Down Your Code

Project owners (like the Safe{Wallet} team) can avoid hacks by using three shields:

• Shield 1: Code Audits

Have experts check every line of code for sneaky changes.

• Shield 2: On-Chain Governance

Store a fingerprint (hash) of the correct code in a blockchain smart contract. If anyone tampers with the code, the fingerprint won’t match, and alarms go off.

• Shield 3: TEEs

A TEE is like a digital vault inside your computer. Code running inside a TEE is untouchable—even if hackers break into the system. By running wallet software in a TEE, you ensure only code with the correct fingerprint (matching the on-chain hash) can execute. No malicious code allowed!

2. For Signers: Eliminate Blind Signing with TEE-Verified Transactions

Why Transaction Simulation Fails Today

Simulating transactions—predicting outcomes by executing them in a sandbox—is the gold standard for detecting malicious intent. However, existing approaches fall short:

• Hardware Wallet Limitations:

On-device simulation is computationally infeasible. Hardware wallets prioritize minimalism for security, lacking the resources to run EVM-compatible simulations.

• Cloud-Based Services (e.g., Tenderly):

Outsourcing simulation to third parties introduces new risks. If a user’s machine is compromised, attackers can alter simulation results before they reach the hardware wallet.

The TEE-Powered Solution: Secure, Verifiable Simulation

To eliminate blind signing, we propose a TEE-based architecture that combines cryptographic proof, decentralized execution, and hardware-enforced trust:

1. Secure Simulation via TEE:
• A lightweight client (e.g., Helios) runs inside a Trusted Execution Environment (TEE).
• The TEE simulates the transaction, generating a cryptographically signed result (via remote attestation) that proves:
• The correct code was executed.
• The simulation was untampered.

2. Hardware Wallet Verification:
• The hardware wallet validates the TEE’s proof, ensuring the simulation is authentic.
• Results are displayed in plain language (e.g., “You’re approving a $10M USDC withdrawal to 0xABC…”).

3. Tamper-Proof Communication:
• End-to-end encryption (TLS) secures data between the TEE and hardware wallet.
• Even if the frontend, RPC, or user’s machine is compromised, attackers cannot alter the simulation or its results.

The TEE acts as a trusted intermediary. Green lines indicate cryptographically secured channels.

Beyond Security: Usability and Privacy

• AI-Driven Clarity:

Deploy an AI agent within the TEE to translate simulation results into natural language (e.g., “This transaction grants unlimited spending access to Protocol X”).

• Zero Privacy Leaks:

TLS encryption ensures simulation inputs/outputs remain confidential. The TEE processes data in isolation, exposing nothing to the host machine.

Why This Matters

The Bybit hack succeeded because blind signing allowed malicious transactions to masquerade as legitimate ones. By integrating TEE-verified simulations:

• Transactions become semantically transparent: Users see what they’re approving, not just raw data.

• Security is mathematically enforced: Tampering requires breaking both the TEE and the hardware wallet—a near-impossible feat.

Final Word

Blind signing is not a design flaw—it’s a systemic failure. TEEs bridge the gap between usability and security, transforming hardware wallets from passive signers into active guardians. By decentralizing trust to a verifiable, hardware-secured environment, we render supply chain attacks and frontend exploits obsolete.

This is not a theoretical improvement—it’s the new standard for institutional-grade security.

What’s a TEE? (A Detailed Version)

A Trusted Execution Environment (TEE) is like a black box inside your device—a tiny, ultra-secure computer within your computer. Here’s what it can (and can’t) do:

TEE’s Superpowers

1. Privacy Fortress:
• The TEE isolates code and data from the rest of the system. Even if your device is infected with malware, hackers can’t see or tamper with what’s happening inside the TEE. It’s like whispering secrets into a soundproof room.

2. Faithful Execution:
• The TEE always runs the program it’s given, exactly as written. If you deploy a program to a TEE, it will execute it honestly, without deviations—even if the outside system is compromised.

3. Verifiable Proofs:
• The TEE can generate proof that it ran a specific program. Think of it like a notarized document: anyone can verify the proof to confirm:
• “Yes, Program X ran inside a legitimate TEE, and here’s its output.”
• This makes TEEs perfect for blockchain ecosystems. They act as trusted off-chain helpers (like auditors or calculators) while staying accountable to on-chain rules.

TEE’s Limitations

1. It Can’t Judge Good vs. Bad Code:
• A TEE will faithfully run any program you give it—even malicious ones! If a hacker tricks you into deploying a bad program (like in the Bybit hack), the TEE will obediently execute it and generate valid proofs.
• Solution: Pair TEEs with code audits and on-chain governance. Store the “fingerprint” (hash) of approved code on-chain, and only let the TEE run programs that match this fingerprint.

2. It’s Only as Trustworthy as Its Setup:
• If someone compromises the TEE’s hardware (e.g., via physical tampering), its security breaks. Thankfully, modern TEEs (like Intel SGX or ARM TrustZone) are rigorously tested and widely trusted—but no system is 100% unhackable.

Why TEE + Blockchain = A Perfect Pair

• TEEs bridge the gap between off-chain computation and on-chain trust. For example:
• A blockchain can store a hash of “valid code” in a smart contract.
• A TEE proves it’s running that exact code (using cryptographic proofs).
• Users can trust the TEE’s output because they know it’s running the approved program.

This combo lets blockchains delegate complex tasks (like transaction validation) to TEEs without sacrificing security.

References

1. Safe{Wallet} Statement on Targeted Attack on Bybit

2. Root cause of the Bybit incident from @realScamSniffer

3. Attack transaction