Your MediaTek WiFi Chip's Secrets: Bypassing Firmware Encryption

Your MediaTek WiFi Chip's Secrets: Bypassing Firmware Encryption

Speakers: Edoardo Mantovani (Independent Researcher, Independent)

Conference: Hardwear.io USA

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

Overview

In a revealing talk at Hardwear.io USA, independent researcher Edoardo Mantovani, in collaboration with Daniel Wegemer, unveiled a series of sophisticated techniques to completely bypass the firmware encryption mechanisms present in a wide range of MediaTek Wi-Fi chipsets. This research stems from a broader goal to develop a robust firmware patching framework for MediaTek Wi-Fi hardware, enabling deeper security analysis and exploration of these ubiquitous components found in everything from Android smartphones and laptops to modern Wi-Fi 7 routers. The implications of this work are significant, as it exposes critical vulnerabilities in how MediaTek protects its firmware, allowing researchers to uncover hidden secrets, execute custom code, and gain unprecedented control over the Wi-Fi stack.

The presentation meticulously details the journey through exotic instruction set architectures, intricate firmware loading protocols, and multiple layers of encryption, starting from simple XOR ciphers to more robust AES-128 implementations. Mantovani demonstrated how creative reverse engineering, leveraging obscure debugging interfaces, and exploiting undocumented hardware peripherals can lead to full compromise of firmware integrity and confidentiality. By shedding light on these often-overlooked hardware-software interactions, the research provides invaluable insights for both security defenders seeking to harden their systems and other researchers aiming to push the boundaries of embedded device security.

Background

▶ Watch: Motivation: Exotic ISA, firmware encryption challenges (0:45)

The motivation for this extensive research began in 2023 with Edoardo Mantovani and Daniel Wegemer's ambition to create a firmware patching framework for MediaTek Wi-Fi hardware. Their initial exploration of older Android smartphones quickly expanded to encompass more modern Wi-Fi 5, Wi-Fi 6, Wi-Fi 6E, and Wi-Fi 7 devices. This journey presented formidable challenges, including an exotic instruction set architecture (ISA), robust firmware encryption, and the presence of hidden firmware secrets embedded deep within the chips. The researchers' work builds upon a lineage of significant security research targeting MediaTek processors, such as the complete defeat of secure boot in many Android smartphones and extensive reverse engineering efforts on MediaTek baseband modems. Within the Wi-Fi ecosystem itself, numerous devices from vendors like Broadcom, Intel, and Espressif (ESP32) have seen their firmware exploited, underscoring the importance of this attack surface.

A Wi-Fi card functions as a miniature embedded computer running its own real-time operating system (RTOS). Communication between the host kernel and the Wi-Fi firmware occurs over a physical bus, predominantly PCI for MediaTek devices. The Wi-Fi chipset hardware comprises a ROM (Read-Only Memory), which is hardcoded, difficult to dump, and generally unmodifiable, and RAM firmware, which defines the operational logic for receiving and sending data, communicating with the kernel, and managing access points.

MediaTek employs two primary kernel driver families. The MT76 driver is widely used in Linux-based desktop and laptop environments. It features a minimal codebase and, crucially for this research, a debugging interface exposed under sysfs. In contrast, the MT Wi-Fi and gen4m drivers target embedded environments like OpenWRT routers and Android smartphones, offering more verbose code and supporting newer devices not yet integrated into MT76. The research primarily focused on the MT76 driver due to its widespread desktop adoption and accessible debugging features.

MediaTek Wi-Fi chips utilize two distinct firmwares. The ROM patch is the first firmware loaded, containing pre-initialization code, exception handling, and core dump functions. It's stored in the file system and loaded into the ROM memory. Its format includes a header with metadata describing regions—chunks of code or data—each defined by an offset, length, and flags indicating properties like encryption status. The main Wi-Fi firmware is loaded after the ROM patch and is responsible for the full initialization of the Wi-Fi hardware, including receive/transmit paths and kernel communication. Unlike the ROM patch, its metadata is located at the end of the file, and each region incorporates a CRC32 checksum for integrity verification, appended to the last four bytes of the region.

The firmware loading process follows a specific booting protocol. The kernel driver first uploads the ROM patch, then proceeds to load the main Wi-Fi firmware region by region. The Wi-Fi ROM code processes these regions, transferring data from the physical bus into the chipset's memory. Once loaded, the ROM jumps to the RAM firmware's entry point, initiating normal Wi-Fi operations. During runtime, a new protocol is established for kernel-firmware communication, allowing the kernel to send commands (e.g., to set monitor mode). These commands contain a seed or command ID (a 32-bit number) that references a specific callback function within the ROM firmware's internal table.

A key challenge was identifying the Wi-Fi chipset's ISA. It was discovered to be NDS32, a RISC-V inspired architecture developed by AndesTech, a Taiwanese company. NDS32 employs a mix of 16-bit and 32-bit instructions and features 32 general-purpose registers, with the Global Pointer (GP), Link Pointer, and Stack Pointer being particularly important. MediaTek Wi-Fi chips typically use the N9 and N10 series of NDS32 cores. Initial attempts to reverse engineer the firmware in Ghidra encountered issues: incorrect string offsets and "unimplemented" instructions. The string issue was traced to the Global Pointer register (R29), which facilitates efficient access to global and static data using a base address. Without the correct GP address, string references were broken. The "unimplemented" instructions were revealed to be part of AndesTech's custom NDS Inline Function Call extension, designed to reduce firmware size. This extension introduces ifcall and ifret instructions for jumping to shared code areas and an X9 instruction, a 16-bit opcode that references frequently used 32-bit instructions stored in a ROM array. While Ghidra eventually received a patch for this extension, the researchers initially relied on radare2, which, thanks to its founder Pancake, provided full NDS32 support, including these custom instructions.

For debugging, the MT76 driver offers several primitives. Firmware logs can be obtained by writing a value (1-3) to the firmware_debug sysfs file, causing the firmware to send logging data back to the kernel, visible in dmesg. The core dump feature, triggered by sending an assert command, provides diagnostic information including the last 32 executed functions, scheduler task status, and crucially, register values, which helped retrieve the elusive Global Pointer address. However, the most critical primitive for this research was reg_index and reg_val, which permit reading and writing four bytes of data directly into the Wi-Fi chipset's memory, forming the bedrock for code injection and memory dumping.

Key Findings

▶ Watch: Revealing MT7921 Wi-Fi 6 XOR encryption key (22:15)

The research yielded several groundbreaking findings that collectively enabled the complete bypass of MediaTek's Wi-Fi firmware encryption across multiple generations of chipsets:

1. ROM Dumping via reg_index/reg_val (MT7921 - Wi-Fi 6): For the MT7921 chipset, the researchers successfully leveraged the reg_index and reg_val primitives to iteratively dump the first 300 kilobytes of the Wi-Fi 6 ROM, which was previously inaccessible. This provided the foundational code necessary to understand the firmware loading and decryption process.

1. XOR Encryption Key Discovery (MT7921): By reverse engineering the dumped MT7921 ROM, specifically the firmware_download_config function, the researchers identified and extracted the simple XOR encryption key: 0x76632000. This allowed for the complete decryption of the MT7921 RAM firmware and ROM patch.

1. CRC32 Integrity Check Mechanism and Bypass (MT7921): The research uncovered the role of the Peripheral DMA (PDA) hardware component within the NDS32 processor, which is responsible for calculating the CRC32 checksum for each loaded firmware region. Two methods were developed to bypass this integrity check:

• Kernel-space Bypass: By reading the hardware-computed CRC value from the PDA_CRC_val register during boot (after supplying a zeroed CRC), and then re-patching the firmware with this retrieved value, arbitrary code execution was achieved.
• User-space Bypass (Firmware Layout Trick): A more elegant user-space bypass was devised by moving the entire Wi-Fi firmware (RAM regions) into the unchecked ROM patch file, effectively disabling the loading flags for the original Wi-Fi firmware. Since the ROM patch's CRC is never verified by the PDA, custom code could be loaded and executed without integrity checks.

1. AES-128 Encryption Challenge and Live Patching (MT7922 - Wi-Fi 6E): On the newer MT7922 chipset, reg_index/reg_val could no longer dump the ROM directly, as the firmware was protected by AES-128 encryption. The researchers overcame this by:

• MMIO Table Exploration: Brute-forcing the entire PCI MMIO address space via reg_index/reg_val to identify accessible memory regions. This revealed a 65KB executable region of the RAM firmware.
• Live Patching via set_SPR: Identifying the set_SPR command callback (an uncommon, Layer 1-related function) in the accessible RAM region. They then developed a live patching mechanism to inject a custom memcpy routine into this callback, which could read 1KB chunks of the ROM from address 0x8000 and copy them to a user-readable memory area. Repeated execution of this command allowed for a full 300KB ROM dump of the MT7922.

1. AES-128 Key Discovery (MT7922): With the MT7922 ROM dumped, the same firmware_download_config function (as seen in MT7921) was reverse engineered to identify the AES-128 key responsible for decrypting the Wi-Fi 6E firmware. A custom program was then developed to decrypt both the ROM patch and main Wi-Fi firmware for the MT7922, revealing that even today, these firmwares are distributed in an encrypted state in Linux repositories.

1. Re-enablement of reg_index/reg_val for Wi-Fi 7 (MT7990/7992/7996): Surprisingly, for the very latest Wi-Fi 7 chipsets (MT7990, MT7992, MT7996), the reg_index/reg_val primitive was found to be functional again. This allowed for direct dumping of the first 5MB of the entire ROM and RAM firmware address space, completely decrypting these cutting-edge firmwares.

1. Bluetooth Firmware Decryption: The research also confirmed that the Bluetooth firmware, often co-located on MediaTek Wi-Fi chipsets, uses the same AES key as its Wi-Fi counterpart. Consequently, the Bluetooth firmware for these devices is now also decryptable in plain text.

These findings collectively demonstrate a comprehensive strategy for overcoming MediaTek's firmware protection mechanisms, revealing a pattern of vulnerabilities across multiple hardware generations that can be exploited to gain deep access and control.

Technical Deep Dive

▶ Watch: User-space CRC32 bypass via firmware layout trick (27:00)

The technical journey began with the fundamental challenge of understanding the NDS32 ISA and its custom extensions. The Global Pointer (GP) register (R29), a cornerstone of NDS32's efficient global data access, initially hindered reverse engineering efforts in Ghidra due to incorrect base address assumptions. The core_dump feature of the MT76 driver proved invaluable here, providing a snapshot of register values during a firmware crash, from which the true GP address could be extracted. This allowed for correct string referencing and data interpretation.

Even more complex were the NDS Inline Function Call extensions: ifcall/ifret and X9. These instructions, designed for code size reduction, obfuscated the control flow for standard disassemblers. ifcall/ifret act like jump and link primitives, directing execution to shared code blocks and then returning. The X9 instruction is a 16-bit opcode that dynamically resolves to a full 32-bit instruction by indexing into a specific array within the ROM. Without proper decoding, these instructions appeared as "unimplemented." The breakthrough came with radare2, which, with support from its founder Pancake, integrated full NDS32 instruction set support, including the X9 table resolution, enabling accurate decompilation.

The backbone of many exploits was the MT76 driver's debugging primitives. While firmware_debug provided useful logs, and core_dump revealed critical register states, the reg_index and reg_val sysfs files were paramount. These allowed reading and writing 4-byte values directly to arbitrary memory addresses within the Wi-Fi chipset. This direct memory access was the initial key to unlocking the MT7921 (Wi-Fi 6) ROM. By iterating reg_index across the expected ROM address range and reading reg_val, the first 300KB of the ROM were successfully dumped, providing the essential binary for further analysis.

Reverse engineering the MT7921 ROM revealed a crucial function: firmware_download_config. This function was responsible for parsing incoming firmware regions, checking their flags, and, if indicated, calling a decryption routine. For the MT7921, this routine implemented a simple XOR cipher. Through careful analysis of the decryption logic within firmware_download_config, the specific 4-byte XOR key 0x76632000 was identified. Applying this key to the encrypted RAM firmware regions (XORing each 4-byte block with the key) completely decrypted the MT7921 firmware.

Next, the researchers tackled the CRC32 integrity check. Each region in the main Wi-Fi firmware has a CRC32 checksum appended, verified by the hardware during loading. The challenge was that the specific polynomial, initial value, and final XOR value for this CRC32 were unknown. Diving deeper into the ROM, the answer was found in the Peripheral DMA (PDA). This undocumented hardware peripheral within the NDS32 processor is specifically designed to calculate the CRC for each uploaded region. The PDA exposes two critical registers: PDA_CRC_val, which holds the computed CRC32 checksum, and PDA_download_state, indicating the success or failure of the CRC computation.

Two distinct CRC32 bypass methods were developed:

1. Kernel-Space Bypass: This method involved modifying the kernel driver. The first step was to load the custom firmware with the last four bytes of each region (where the CRC would normally reside) set to zeros. During this loading process, the hardware's PDA would still calculate the CRC for the region (including the zeroed bytes). By instrumenting the kernel driver to read the PDA_CRC_val register during boot time for each region, the hardware-computed CRC could be retrieved. The final step was to re-patch the custom firmware with these retrieved CRC values and reload it, successfully bypassing the integrity check and achieving code execution.

1. User-Space Bypass (Firmware Layout Trick): This more accessible method exploited the fact that the ROM patch firmware's CRC is never checked by the PDA. The trick involved altering the firmware layout: all code and data regions from the main Wi-Fi firmware were moved and appended to the ROM patch file. Concurrently, the metadata for the original Wi-Fi firmware was modified to disable its loading flags, effectively making it an empty, unexecuted file. As the ROM patch is loaded first and its integrity is not verified, the entire custom firmware, now residing within the ROM patch, could be loaded and executed without any CRC checks.

The MT7922 (Wi-Fi 6E) presented a new hurdle: AES-128 encryption and the disabling of reg_index/reg_val for direct ROM access. The researchers had to find a new entry point. They realized that the MT76 driver's source code contains an MMIO table for every PCI device, detailing address translations for reading offsets into the PCI Bar address space. By brute-forcing this entire MMIO table using reg_index/reg_val, they could dump various memory segments. Out of 43 dumped segments, only one, the last 65KB executable region of the RAM firmware, contained valid NDS32 instructions. This segment was crucial because it was both readable/writable and executable.

To dump the MT7922 ROM, a live patching mechanism was devised. The researchers identified an uncommon command, set_SPR, from the previous hardware's command table, which they inferred likely existed and was reachable in the MT7922's last RAM firmware region. This command's callback function became the target. A simple C memcpy routine was compiled for NDS32, designed to read 1KB chunks from the ROM's starting address (0x8000) and copy them to a writable, user-accessible memory area. The executable section of this compiled memcpy was then injected into the set_SPR callback using reg_index/reg_val. By repeatedly sending the set_SPR command from the kernel space, 1KB of ROM could be dumped per iteration, eventually yielding the full 300KB MT7922 ROM after an "entire night" of execution.

With the MT7922 ROM in hand, the firmware_download_config function was again the target, but this time, it handled AES-128 decryption. The researchers were able to extract the AES key, leading to a custom program that fully decrypts the MT7922 ROM patch and main Wi-Fi firmware. This revealed that even current Linux firmware repositories distribute this firmware in an encrypted state, a vulnerability exposed by this research.

Finally, the most recent Wi-Fi 7 chipsets (MT7990/7992/7996), despite using AES-128 and the newer Andes N45 (pure RISC-V) ISA, surprisingly had the reg_index/reg_val primitives re-enabled. This made the dumping process significantly easier, allowing for the full 5MB dumping of the ROM and RAM firmware address space, completing the decryption of these advanced firmwares. The research also confirmed that the Bluetooth firmware on these chipsets shared the same AES key, making it fully decryptable as well.

Demo / Proof of Concept

▶ Watch: Unexpected easy firmware dump on latest Wi-Fi 7 routers (36:15)

While the talk did not feature a live, real-time demonstration of the exploits, the methodologies described constitute clear proofs of concept for each stage of the attack. The ability to dump the first 300KB of the MT7921 (Wi-Fi 6) ROM using the reg_index/reg_val primitive is a foundational PoC. The subsequent identification and application of the XOR encryption key (0x76632000) to decrypt the MT7921 firmware serves as a direct validation of the reverse engineering process.

Crucially, the two methods for bypassing the CRC32 integrity check on the MT7921 are explicit proofs of concept for achieving arbitrary code execution. The kernel-space bypass, involving the dynamic retrieval of the hardware-computed CRC from PDA_CRC_val and subsequent patching, demonstrates precise control over the firmware loading process. The user-space "firmware layout trick," which involves relocating Wi-Fi firmware regions into the unchecked ROM patch, is a clever and effective PoC for bypassing integrity checks without kernel modifications.

For the MT7922 (Wi-Fi 6E), the entire live patching mechanism to dump the ROM is a highly technical PoC. This involved:

1. Identifying an accessible and executable region of RAM firmware.
2. Locating a reachable command callback (set_SPR).
3. Compiling and injecting a custom memcpy routine into this callback using reg_index/reg_val.
4. Repeatedly invoking the patched set_SPR command to incrementally dump the ROM.

This intricate process directly demonstrates code injection and data exfiltration capabilities on an AES-128 encrypted system where direct ROM access was initially blocked. The ultimate result, the full decryption of the MT7922 firmware, further validates the success of this complex attack chain. Finally, the successful dumping of the MT7990/7992/7996 (Wi-Fi 7) ROM and RAM firmware via the re-enabled reg_index/reg_val confirms the practical applicability of these techniques across the latest hardware.

Defensive Implications

▶ Watch: Final considerations for researchers and hardware vendors (38:00)

The findings from this research highlight several critical areas where MediaTek and other hardware vendors need to strengthen their security posture to prevent similar firmware decryption and code execution attacks.

Firstly, robust input/output command validation is paramount. The discovery that commands like set_SPR could be leveraged for arbitrary code injection on the MT7922, simply by patching their callbacks, indicates insufficient vetting of firmware-exposed interfaces. Vendors must conduct thorough security reviews of all commands offered by both ROM and RAM firmware, ensuring they cannot be abused to read or write sensitive memory regions or alter critical execution paths.

Secondly, stronger firmware integrity checks are essential. The reliance on undocumented CRC32 calculations by the PDA, which could be bypassed by either dynamically retrieving the correct CRC or exploiting the unchecked ROM patch loading, demonstrates a weakness. Future designs should employ cryptographic hashes (e.g., SHA256) instead of simple CRCs, with publicly documented algorithms and parameters, and secure boot mechanisms should extend comprehensive integrity verification to all loaded firmware components, including ROM patches.

Thirdly, restricted MMIO access is critical. The reg_index/reg_val primitives, which allow direct 4-byte read/write access to arbitrary memory addresses, proved to be the most powerful attack vector. Such low-level debugging or diagnostic interfaces should be strictly limited, ideally removed in production firmware, or protected by strong authentication mechanisms tied to a secure boot chain. Their re-enablement on Wi-Fi 7 chips (MT799x) is a significant security regression.

Fourthly, encryption key management needs significant improvement. Hardcoded XOR and AES-128 keys, discoverable through ROM dumping and reverse engineering, undermine the entire encryption scheme. Keys should be derived from unique hardware secrets, ideally provisioned per device, and protected by hardware security modules (HSMs) or trusted execution environments, making them much harder to extract. The fact that Bluetooth firmware shared the same easily discoverable AES key further compounds this issue.

Finally, supply chain security and information hygiene are vital. The researchers emphasized the utility of leaked SDKs and firmware on GitHub. Vendors should exercise extreme caution regarding the release of internal development materials, as they often contain invaluable insights into undocumented hardware behavior and implementation details that can facilitate reverse engineering and exploitation. Regular security audits of driver code (e.g., MT76 vs. MT Wi-Fi) are also necessary to identify unintended debug features or information leaks that could be exploited by attackers.

Key Takeaways

• MediaTek Wi-Fi firmware encryption, ranging from simple XOR to AES-128, can be completely bypassed. This was achieved by exploiting a combination of hardware design choices, undocumented features, and weaknesses in firmware loading and integrity verification processes.
• Low-level debugging primitives in kernel drivers are potent attack vectors. The reg_index and reg_val sysfs interfaces in the MT76 driver allowed direct memory read/write, proving instrumental for ROM dumping, code injection, and exfiltrating encryption keys across multiple chip generations.
• Firmware integrity checks (CRC32) can be circumvented through deep hardware understanding or clever loading tricks. By identifying the Peripheral DMA (PDA) hardware's role in CRC calculation, researchers could dynamically forge valid CRCs. Alternatively, moving firmware into unchecked regions (like the ROM patch) provided a user-space bypass.
• Reverse engineering exotic ISAs requires specialized tools and persistence. The NDS32 architecture with its custom NDS Inline Function Call extensions (ifcall/ifret, X9) presented significant initial hurdles, overcome by leveraging tools like radare2 and understanding the Global Pointer register's role.
• Cross-referencing different driver versions and leaked SDKs is crucial for vulnerability discovery. The MT Wi-Fi/gen4m drivers and MediaTek's OpenWRT SDKs provided vital context and register definitions not present in the primary MT76 driver, accelerating the reverse engineering process.
• Even on newer hardware with stronger encryption, creative side-channel attacks and live patching can lead to full compromise. For the MT7922 (Wi-Fi 6E), where direct ROM dumping was blocked, exploiting an accessible command callback (set_SPR) for live code injection allowed for incremental ROM exfiltration and subsequent AES key recovery.

About the Speaker(s)

Edoardo Mantovani is an independent researcher dedicated to exploring the security of low-level code and uncovering hidden secrets within embedded firmware. His work, including this presentation, is often done in collaboration with Daniel Wegemer. Mantovani's research interests lie particularly in hybrid IoT devices and the intricate interactions between hardware and software. He has a history of contributing to the understanding of MediaTek hardware, having previously presented at Nullcon 2025 on techniques to unlock low-level receive mode for MediaTek Wi-Fi chipsets. His talks emphasize getting "hands dirty" with code and hardware to solve complex reverse engineering challenges.