MediaTek vulnerability: how to protect assets

Vulnerability in MediaTek Dimensity 7300 (MT6878)

A vulnerability in the MediaTek Dimensity 7300 (MT6878) chip, discovered by researchers at Ledger Donjon, allows for the disruption of the boot ROM and the execution of arbitrary code with maximum privileges via Electromagnetic Fault Injection (EMFI). Since this is a hardware vulnerability (in the silicon), it cannot be fixed with a standard firmware update—it requires a hardware revision, replacement, or hardware-level countermeasures at the device or infrastructure level.

A Brief Guide to EMFI — In Simple Terms

EMFI (electromagnetic fault injection) is a physical attack: short, targeted electromagnetic pulses disrupt the chip's logic—skipping checks, flipping bits, or altering execution order. To put it simply: at the exact moment the device verifies a signature or password, a pulse "hit" can force the system to ignore that verification. Unlike software vulnerabilities in applications, EMFI targets hardware structures (including the immutable boot ROM), making software patches powerless.

How the Attack Looks in Practice

• An attacker delivers a pulse at a precisely timed moment during code execution in the boot ROM; this can bypass integrity checks or access conditions.
• Once bypassed, the attacker can gain access to protected memory regions, prepare Return-Oriented Programming (ROP) chains, and execute code with kernel/boot privileges.
• Implementation requires physical access to the device and laboratory equipment; once set up, the attack can be reproduced in minutes.

Who Is at Risk and Real-World Consequences

• Owners of smartphones powered by the MT6878/Dimensity 7300, including "crypto-smartphones" (e.g., Solana Seeker), if these devices are used to store private keys or sign transactions.
• Companies and startups using consumer SoCs for key storage or critical signing operations.

Consequences: Theft of private keys, forgery or interception of signatures and transactions, and targeted compromises of accounts or network nodes.

Practical Steps — What to Do Now (By User Category)

Regular Users / Small to Mid-Balance Holders

1. Temporarily stop using the device for signing or storing large sums until confirmation is provided by the manufacturer or independent testers.
2. Move significant funds to cold storage: hardware wallets with a dedicated Secure Element or offline storage. For most, this is the simplest and most reliable step.
3. Keep only minimal amounts on the device for everyday operations.

Advanced Users / Active Self-Custody

1. Transfer keys to devices with independent, certified Secure Elements/HSMs (FIPS/Common Criteria or equivalent).
2. Organize a multi-signature (multisig) setup with independent keys; for example, 2-of-3 or 3-of-5 depending on risk and convenience—ensuring that the compromise of a single device does not grant full access.
3. Use offline signing and verify addresses/transactions on a separate, secure device.
4. Do not store master keys on the device until its secure status is confirmed.

Organizations and Companies

1. Immediately analyze which products in your infrastructure use the MT6878/Dimensity 7300; phase out these devices for critical signing and storage operations.
2. Move key management to certified HSMs/Secure Elements or a verified multi-signature scheme.
3. Include physical access risk assessments and restrict physical tampering possibilities (safes, containers, video surveillance, access control).
4. Demand that suppliers confirm the presence of hardware countermeasures against fault injection and provide independent test results.

Priority Protection Measures (Fast and Effective)

• For large sums: cold storage and HSMs.
• For signatures requiring mobility: multisig with keys split across independent devices/providers.
• Restrict physical access to devices and use security seals/safes for critical hardware.

Recommendations for Developers and Device Manufacturers (Concise)

• Do not store private keys inside unprepared consumer SoCs—use hardware modules with proven isolation (Secure Element, HSM).
• Plan for physical attack protection at an early stage: simple, proven measures include shielding, tamper/intrusion sensors, noise/interference detectors, and fail-safe states upon trigger.
• Include fault injection testing (including EMFI) in the product validation process and permit independent physical security audits.

Short Recommendations for Chip Manufacturers

• Document known hardware limitations of the boot ROM and publish threat modeling results.
• Implement built-in countermeasures against fault injection (sensors, filters, improved hardware signal resolution).
• Support processes for independent testing and certification.

Conclusion — What to Remember When Choosing a Device for Crypto Work

Hardware security is critical: software patches cannot save you from a silicon-level vulnerability. When choosing devices for storage and signing, prioritize those with a dedicated Secure Element/HSM, confirmed physical security audits, and a strong manufacturer reputation. For organizations, this means incorporating hardware resilience into product requirements and moving toward architectures that do not rely on a single consumer SoC for key storage.

Where to Find Details

The Ledger Donjon report contains a technical breakdown and demonstrations of the attack. For practical recommendations, refer to hardware wallet usage guides, Secure Element/HSM certification standards, and multisig organizational materials.

If you wish, I can:

• Prepare a brief checklist for auditing a specific device.
• Suggest a list of certified hardware wallets and HSM providers based on your requirements.