Out-of-Box Exploitation: Breaking the Trust Chain of the Ethereum Phone

Out-of-Box Exploitation: Breaking the Trust Chain of the Ethereum Phone

Speakers: Guanxing Wen, Sr. Staff Security Researcher, CertiK

Conference: Hardwear.io USA

YouTube: https://www.youtube.com/watch?v=zBxfp7M5PDY

Overview

In an insightful presentation at Hardwear.io USA, Guanxing Wen, a Senior Staff Security Researcher at CertiK, meticulously dissected the security posture of the "Ethereum Phone" (Generation 1). His talk, "Out-of-Box Exploitation: Breaking the Trust Chain of the Ethereum Phone," used this device as a critical case study for the emerging category of "cryptophones." These devices aim to bridge the convenience of traditional smartphones with the enhanced security of hardware wallets, claiming to protect digital assets through secure enclaves. Wen's research specifically investigated whether the Ethereum Phone's purported "trust chain" could genuinely safeguard private keys and user funds from the moment it was unboxed.

The talk exposed a series of fundamental security flaws, demonstrating that the Ethereum Phone's security claims were largely unfounded in practice. From an easily bypassable bootloader to a software-only screen lock and unencrypted private key storage, the device failed to provide adequate protection for sensitive blockchain assets. Furthermore, a critical design flaw in its airdrop mechanism exposed users to potential theft even before they received their device. This research is particularly significant as it highlights the inherent risks in nascent cryptophone ecosystems and underscores the vital need for robust, independently verifiable hardware-backed security in devices designed to handle high-value digital assets.

Wen's expertise, spanning lower-level systems, embedded devices, and the intersection of blockchain and traditional security, positioned him uniquely to evaluate the cryptophone's security architecture. His findings serve as a stark warning to both developers and users in the rapidly evolving Web3 space: true security for digital assets requires more than just marketing claims; it demands rigorous, hardware-rooted implementations that withstand sophisticated attacks, even from an "out-of-box" perspective.

Background

▶ Watch: Introduction to Cryptophones and Ethereum Phone (0:00)

The advent of blockchain technology has led to a proliferation of digital assets and decentralized applications (DeFi). Interacting with these ecosystems necessitates a wallet, which acts as a custodian for private keys – the cryptographic secrets that authorize transactions. Traditional browser extension wallets, while convenient, are inherently vulnerable; if an attacker compromises the host system or browser environment, private keys are at risk. Hardware wallets address this by managing keys on a separate, isolated device, significantly improving security but often at the cost of convenience, requiring physical interaction for every transaction.

Cryptophones emerge as an attempt to resolve this trade-off. They aim to integrate hardware wallet-level security directly into a smartphone form factor, promising users the ability to interact with DeFi applications conveniently while claiming to keep private keys secure within a dedicated enclave or similar secure module. The Ethereum Phone, specifically the Generation 1 model running ETHOS (an Android-based operating system on a MediaTek chipset), explicitly states in its official documentation that private keys are managed by a Trusted Execution Environment (TEE).

However, a fundamental technical challenge exists: traditional Ethereum and many other blockchains utilize SECP256K1 for transaction signing, whereas Android and iOS hardware key systems typically only support SECP256R1 for hardware-backed curves. This incompatibility means that if a cryptophone truly wants to leverage hardware-backed key storage for Ethereum-compatible keys, it cannot use the default Android KeyStore system. Other platforms, like the Solana Phone or Samsung phones, address this by developing their own custom TEE Trusted Applications (TAs) to support blockchain operations. The central question for Wen's research was to ascertain how the Ethereum Phone handled this, and more broadly, whether its claims of TEE-based security held up under scrutiny.

Another crucial aspect of the cryptophone ecosystem is airdrops. Blockchain projects frequently reward early adopters and enthusiastic community members with free tokens. These users, often engaging in community campaigns, retweeting, bridging funds, or staking, become natural targets for token distribution. Users who pre-order a cryptophone and wait months for delivery demonstrate significant commitment to the ecosystem, making them prime candidates for substantial airdrops, sometimes exceeding the device's cost. This financial incentive adds another layer of criticality to the security of these devices, as compromising a phone could mean not only stealing existing assets but also intercepting future rewards. Wen's investigation began by reverse engineering the device's firmware, a process typically requiring root access, but in this case, leveraging the device's download mode for initial access.

Key Findings

▶ Watch: Initial Access via MediaTek Download Mode Bypass (5:15)

Guanxing Wen's "out-of-box" analysis of the Ethereum Phone revealed a series of critical vulnerabilities that collectively shattered its claims of a robust trust chain for digital assets. The core findings painted a picture of a device whose software-level implementations failed to deliver on the promise of hardware-backed security.

1. Unfused MediaTek Download Mode Vulnerability: The device's MediaTek chipset possessed an insecure download mode. Crucially, the SA (Signature Authentication) and DA (Download Agent authorization) fuses, which are designed to prevent unauthorized code execution during the boot process, were not blown. This critical misconfiguration allowed an attacker to upload any compatible, unsigned download agent, gaining very early and deep control over the device's boot chain without needing physical hardware modifications like shorting test pins.

1. Software-Backed Security, Not Hardware-Backed: Despite documentation claiming private keys were managed by a Trusted Execution Environment (TEE), the research found that both the screen lock mechanism and the private key storage were implemented primarily in software. The is_hardware_backed function in the gatekeeper service was hardcoded to return true, deceptively indicating hardware protection where none existed.

1. Offline Screen Lock Bypass: Due to the software-only implementation of the screen lock, the device was vulnerable to offline brute-force attacks. The parameters necessary for password derivation (using scrypt and sha256) were found unencrypted within a "password file" on the device. An attacker with initial access could extract this file and then computationally brute-force the screen lock PIN without any rate limiting or hardware involvement, rendering the lock functionally useless against a determined adversary.

1. Unencrypted Private Key Extraction: The device's private keys, despite being critical for managing digital assets, were stored in a software keystore and were not encrypted. They were serialized and saved directly into a database file located in the device's D storage. Critically, this D storage partition could be accessed and read without first unlocking the device's screen, making private key extraction trivial once initial bootloader access was achieved.

1. Airdrop Theft via Public Identifiers: The mechanism for verifying user identity for valuable airdrop distributions relied on the device's IMEI and serial number. Alarmingly, both of these unique identifiers were found printed directly on the phone's physical packaging label. This design flaw meant that anyone with access to the packaging (e.g., factory workers, delivery personnel, or even buyers of online listings showing package photos) could pre-emptively steal airdrop rewards intended for the legitimate device owner before the phone even reached their hands.

These findings collectively demonstrate a profound failure in the security architecture of the Ethereum Phone, undermining user trust and exposing digital assets to significant risk from multiple vectors, all stemming from vulnerabilities present "out of box."

Technical Deep Dive

▶ Watch: Bypassing Android Virtualization Framework (AVF) (13:20)

The technical depth of Wen's research showcased a sophisticated understanding of modern Android boot chains and MediaTek platform specifics. The exploitation began with the discovery of a critical misconfiguration in the MediaTek download mode. On many smartphone platforms (Qualcomm Sahara, Huawei Xloader, Samsung XO, Pixel Tensor), a boot ROM provides a failsafe mechanism, exposing a USB interface to upload a second-stage loader to recover the device. On the Ethereum Phone's MediaTek chipset, entering this download mode simply required a button combination. The crucial vulnerability lay in the fact that the SA (Signature Authentication) and DA (Download Agent authorization) fuses, which typically enforce the loading of vendor-authorized code, were not blown. This meant an attacker could upload any compatible download agent, effectively bypassing the first crucial security boundary.

Wen's objective was not merely static firmware extraction but to propagate this early access into the post-boot Android environment for dynamic debugging and patching, all without modifying the flash storage. Modifying flash storage could trigger later bootloader stages (like gatekeeper, keymaster, or security models) to detect an unexpected state, potentially leading to a factory reset and loss of user data. To achieve this, he devised an in-memory, multi-stage patching strategy dubbed "load off loader."

The "load off loader" strategy works by intercepting each stage of the boot process:

1. Boot ROM to Preloader: The boot ROM loads and verifies the preloader. Wen's initial download agent would patch the preloader in memory.
2. Preloader to BL2 & Genius Zone: The preloader initializes more components and loads BL2 and the Genius Zone (MediaTek's implementation of Google's Android Virtualization Framework - AVF). The patched preloader would then inject shellcode into BL2 and Genius Zone memory spaces.

• Genius Zone: This is a new module in modern Android boot chains, using E2 virtual machine technology for isolation, unlike ARM TrustZone. It is encrypted, but Wen discovered that the decryption key and IV were passed as parameters, allowing offline decryption of its firmware (unlike systems that only provide an oracle). By replacing a non-critical HVC (Hypervisor Call) handler with custom shellcode, a backdoor was established for E2 read/write/execute primitives from the Android side.

1. BL2 to ARM Trust Firmware (ATF): BL2 loads more images, including the ARM Trust Firmware. The patched BL2 would then inject shellcode into ATF.
2. ATF to Little Kernel (LK): ATF is a common component. Similar to Genius Zone, a backdoor was implemented by replacing an SMC (Secure Monitor Call) handler with shellcode.
3. Little Kernel (LK) to Android Kernel: The LK is the bootloader stage interacting with fastboot and loading the Android kernel. A significant challenge here was the absence of a fastboot boot command (which loads a kernel into memory without flashing). Wen's patch for LK was the most complex, involving:

• Replacing the original disk_read function. When the requested partition was "boot," the patched function would copy data from a download buffer instead of flash.
• Enabling a continue command and preventing the download buffer from being freed, ensuring the kernel image remained in memory.
• Forcing the bootloader into fastboot command mode by patching functions to return zero, bypassing unlock flag checks.
• A workaround was needed to halve a modem allocation size to prevent memory exhaustion due to the non-freed download buffer.

After this elaborate patching chain, the system would boot into Android, with SMC and HVC backdoors established in the kernel, allowing an attacker to gain root privileges.

With this deep access, Wen proceeded to analyze the security mechanisms:

Screen Lock Bypass:

The standard Android screen lock flow involves Java-level LockSettings, native Gatekeeper services, and finally a hardware-backed TEE or Strongbox. On the Ethereum Phone, however, the implementation was found to be a soft_gatekeeper shared library.

• The is_hardware_backed function was hardcoded to 1, falsely indicating hardware protection.
• The get_password_key function, which should return a hardware-bound key for cryptographic operations, did not; the key was not involved in calculating the signature.
• The password derivation algorithm involved scrypt, then sha256, then scrypt again. All necessary parameters for these algorithms were directly retrievable from the password file created alongside the PIN.

This combination meant the screen lock could be brute-forced offline using a simple Python script, with no hardware rate limiting or TEE involvement. A six-digit PIN could be cracked in minutes on a high-end server.

Private Key Extraction:

The device utilized smart accounts, which are smart contracts on the blockchain, to circumvent the SECP256K1/R1 incompatibility. Instead of relying on the hardware-backed KeyStore for SECP256K1, the smart account allowed storing a public key and custom verification logic, supporting SECP256R1. However, the private key itself was not securely stored.

• Keys were found to be stored in a software-based keystore, serialized, and unencrypted within a database.
• The relevant field was named p256_ethos.
• Crucially, this database was located in the device's D storage, which, unlike C storage, was accessible without requiring the screen to be unlocked.

Once extracted, the private key could be used to derive the public key, and its ownership could be verified by invoking the owner_public_key function on the associated on-chain smart contract (found to be on the Base chain), confirming full control over the system wallet.

This detailed technical analysis exposed a complete breakdown of the device's supposed security model, from the foundational bootloader to the application-level storage of critical cryptographic assets.

Demo / Proof of Concept

▶ Watch: Gaining Root and Screen Lock Bypass (21:30)

Guanxing Wen provided compelling demonstrations and proof-of-concept steps for each of the identified vulnerabilities, illustrating the practical feasibility of his "out-of-box" exploitation.

The initial demonstration focused on the bootloader bypass and gaining root access. The Ethereum Phone was powered on while pressing the specific button combination to enter the boot ROM download mode. Once in this mode, Wen uploaded his custom, patched preloader. The phone then continued its boot process, leveraging the in-memory patches. To confirm the success of the patching chain without touching flash storage, a fastboot command was used to "flash" a non-existent partition. This action, leveraging the patched Little Kernel's boot command implementation, allowed the system to proceed without actual writes to flash. The phone successfully booted into the Android system. To verify that the kernel backdoor was active and functional, a command was executed from the Android shell to gain root privilege. The successful execution of this command visually confirmed that the multi-stage in-memory patching had indeed propagated full control to the Android operating system.

Next, the screen lock bypass was demonstrated. After gaining root access, the critical "password file" containing the scrypt and sha256 parameters was extracted from the device. Wen then executed a Python script, which he had developed based on his reverse engineering of the soft_gatekeeper logic. This script performed an offline brute-force attack against the screen lock PIN. For demonstration purposes, a relatively simple six-digit PIN was used. Within seconds, the script successfully identified the correct PIN, which was then manually entered on the device, unlocking the screen. This visually confirmed that the screen lock was entirely software-based and vulnerable to offline attacks.

Finally, the private key extraction and verification was showcased. With root access (or even without screen unlock, given the D storage location), the database containing the private keys was retrieved from the device. Wen then parsed the p256_ethos blob within the database to extract the raw private key. From this private key, the corresponding public key (x and y coordinates) was derived. To provide irrefutable proof of control, these public key coordinates were then input into a chain explorer for the Base chain, specifically invoking the owner_public_key function of the on-chain smart contract associated with the device's system wallet. The smart contract returned true, unequivocally confirming that the extracted private key indeed controlled the Ethereum Phone's system wallet.

While the talk didn't feature a live "airdrop theft" demonstration, the implications were clear. With the ability to extract IMEI and serial numbers directly from product packaging, an attacker could register these identifiers with the vendor's backend server, obtain the necessary signature, and then invoke the on-chain airdrop contract to claim tokens before the legitimate owner even had a chance, effectively demonstrating a "minus one click" attack scenario.

Defensive Implications

▶ Watch: Airdrop Theft via Public IMEI/Serial Numbers (34:00)

The findings from the "Out-of-Box Exploitation" talk carry significant defensive implications for both cryptophone vendors and users of these emerging devices. The observed vulnerabilities highlight critical areas where security implementations fall short of user expectations and industry best practices.

For Cryptophone and Hardware Vendors:

1. Properly Fuse Bootloader Security: The most fundamental defense is to correctly configure and permanently fuse security features like Signature Authentication (SA) and Download Agent (DA) authorization. Unblown fuses are a critical manufacturing oversight that provides attackers with an immediate and unmitigated entry point into the device's trust chain. This is a non-negotiable requirement for any secure hardware.
2. Implement Hardware-Backed Key Storage and Gatekeepers: Claims of TEE-based security must be backed by genuine hardware implementations. Vendors must integrate and utilize Strongbox or a properly isolated Trusted Execution Environment (TEE) for storing and managing private keys and for all sensitive cryptographic operations, including screen lock verification. The is_hardware_backed function should accurately reflect the underlying security mechanism, not hardcoded to true if it's not.
3. Encrypt Sensitive Data with Hardware-Bound Keys: All critical user data, especially private keys, must be encrypted at rest using keys derived from or wrapped by hardware-backed roots of trust. Storing private keys unencrypted in accessible storage, even D storage, is a severe security lapse.
4. Avoid Public Identifiers for Critical Security Functions: Using easily discoverable identifiers like IMEI and serial numbers for authentication, especially when they are printed on external packaging, is a dangerous practice. If these identifiers are necessary, they must be treated as highly sensitive secrets and never exposed publicly. A robust identification system would involve cryptographic proofs derived from hardware-unique keys that are never exposed.
5. Undergo Independent Security Audits: Given the high-value assets cryptophones are designed to protect, rigorous, independent security audits by reputable third parties are essential. These audits should cover the entire stack, from hardware and bootloader to the operating system, TEE implementations, and application-level security.
6. Transparency and Accurate Documentation: Vendors should be transparent about their security architecture and accurately document what is truly hardware-backed versus software-implemented. Misleading documentation erodes trust and exposes users to unseen risks.

For Users of Cryptophones (and Digital Assets):

1. Skepticism Towards Security Claims: Be highly skeptical of devices claiming "hardware-backed security" without robust, verifiable evidence and independent audit reports. Research the specific implementations rather than relying solely on marketing.
2. Understand the Security Model: Before entrusting significant digital assets to a new device category like cryptophones, seek to understand its actual security model. Is the key generation, storage, and signing truly isolated in a secure element or TEE, or is it a software abstraction?
3. Protect Physical Packaging: If using a device where identifiers like IMEI or serial numbers are printed on the packaging, treat that packaging as sensitive. Do not share photos of it online, and dispose of it securely. This applies even if you don't believe the identifiers are used for security, as vendors' practices can change.
4. Consider Traditional Hardware Wallets for High Value Assets: Until cryptophone security models mature and are proven robust through widespread adoption and independent scrutiny, consider continuing to use established, audited hardware wallets for your most valuable digital assets.
5. Strong and Unique PINs/Passwords: If a device relies on a PIN or password for screen lock, always choose a strong, unique one. While the Ethereum Phone's software gatekeeper bypass makes even strong PINs vulnerable, this is still a good general practice.
6. Monitor for Updates and Vulnerability Disclosures: Stay informed about security updates and disclosures for your devices. A responsible vendor will address known vulnerabilities promptly.

Ultimately, the talk serves as a critical reminder that integrating complex blockchain functionality with traditional mobile hardware introduces new attack surfaces. True security for digital assets demands a comprehensive, layered approach that prioritizes hardware-rooted trust, rigorous implementation, and transparent validation.

Key Takeaways

• The Ethereum Phone (Generation 1) exhibited fundamental security flaws "out of box," failing to deliver on its claims of a robust trust chain for digital assets.
• The MediaTek bootloader was critically misconfigured, with SA and DA fuses unfused, allowing attackers to upload arbitrary unsigned code and gain deep control over the boot process.
• The device's screen lock was implemented via a software-only gatekeeper, making it vulnerable to offline brute-force attacks due to accessible password derivation parameters and a lack of hardware-based rate limiting.
• Private keys were stored unencrypted in a software keystore within the device's D storage, making them easily extractable without even unlocking the screen.
• The airdrop identification system was severely flawed, using IMEI and serial numbers printed on the physical packaging, enabling pre-theft of airdrop rewards before the legitimate owner received the device.
• The research highlights the critical importance of genuine hardware-backed security (e.g., properly fused bootloaders, TEE/Strongbox for key management) in cryptophones, rather than relying on software abstractions or misleading documentation.
• Users should exercise extreme caution and perform due diligence when considering cryptophones, prioritizing devices with transparent security architectures and independent audits.

About the Speaker(s)

Guanxing Wen is a Senior Staff Security Researcher at CertiK, a leading blockchain security company. His professional interests lie primarily in the lower-level systems of modern technology, encompassing smartphones, electric vehicles, and various embedded systems. More recently, his research focus has expanded to the critical intersection between blockchain technology and traditional security infrastructure. This includes delving into the security of hardware wallets, decentralized applications (dApps), and the underlying blockchain code itself. Given this specialized expertise, cryptophones, which combine the complexities of smartphone hardware with the unique security demands of blockchain interaction, naturally became a compelling target for his in-depth security analysis.