Entertainment at it's peak. The news is by your side.

There’s a Hole in Your SoC: Glitching the MediaTek BootROM


This study used to be performed by our intern Ilya Zhuravlev, who has returned to school but will seemingly be rejoining our crew after commencement, and used to be suggested by Jeremy Boone of NCC Community’s Hardware & Embedded Systems Practice.

With the appearance of affordable toolchains, such as ChipWhisperer, fault injection is rarely any longer an attack vector that is specific to effectively funded and highly skilled adversaries. On the identical time, popular devices embed more secrets and systems than ever, which have to be salvage. This can encompass every encrypted user data, or proprietary seller secrets and systems.

Voltage glitching is a effect of a fault injection attack where the supply voltage of a goal application is modified to induce unanticipated behavior. On the total, this involves momentarily shorting the processor’s core voltage rail to ground, which could pass the interior execution advise of the processor. While the facet-effects of glitching could per chance well additionally be sophisticated to predict accurately, by observing the system’s behavior and by tuning the glitch parameters fastidiously, it is possible to trigger the system to, to illustrate, skip the execution of particular instructions or to pass data salvage operations. On the total, these kinds of faults can enable an adversary to bypass excessive safety operations that are conducted by low level application, such as when a bootloader verifies the signature of a subsequent firmware image sooner than passing execution management to it.

In the previous, most fault injection study has centered on low vitality microcontrollers, such as basically the most popular attacks on the STM32 series MCUs, NXP LPC and ESP32. Given these kinds of microcontrollers are no longer incessantly seen in more mighty cell phones or IoT devices, NCC Community sought to repeat that such attacks would succeed when applied to a more complex processor.

This weblog put up describes NCC Community’s methodology for characterizing the boot direction of of the MediaTek MT8163V system-on-chip (64-bit ARM Cortex-A), as effectively because the invent of an apparatus that is able to reliably producing a fault injection attack in opposition to the SoC. In the slay, our outcomes worth that the MediaTek BootROM is at possibility of glitching, allowing an adversary to bypass signature verification of the preloader. This circumvents all salvage boot performance and permits the execution of unsigned preloader pictures, fully undermining the hardware root of trust.

Our work centered particularly on the MT8163V chipset, and we didn’t strive this exploit in opposition to more most popular variants of the SoC. On the replace hand, we’re conscious that many MediaTek SoCs portion the identical BootROM-to-preloader execution hotfoot along with the circulation. Our (as yet, untested) suspicion is that this vulnerability impacts other MediaTek SoC’s that are currently on the market. Given the occurrence of this platform, it could per chance well prepare that this vulnerability impacts a giant diversity of embedded devices that exercise MediaTek chips together with tablets, aesthetic phones, dwelling networking products, IoT devices, and more.

Because this vulnerability manifests in the mask ROM, the venture is unable to be patched for all in-field affected products. The severity of this venture then again, relies highly on the product possibility model. Voltage glitching attacks require bodily accumulate entry to to the goal application, so possibility is absolute top in possibility devices where bodily accumulate entry to is believed, such as with cell devices that are mechanically lost or stolen. Conversely, deployments that deny attackers bodily accumulate entry to could per chance well additionally be treated with a gleaming reduction in disaster.

Chosen Hardware Target

NCC Community selected a most popular tablet application which makes exercise of the MediaTek MT8163V system-on-a-chip. The goal used to be chosen in step with its build, huge availability, and the indisputable truth that the PCB has many exposed and labelled test aspects. This simplified the circuit board reverse engineering direction of and made it more straightforward to probe and glitch the board.

MediaTek Boot Direction of

Many MediaTek cell and tablet SoCs prepare a overall boot direction of, as confirmed by the next decide. Our fault injection attack is designed to goal the BootROM as it is loading and verifying the preloader executable.

MediaTek boot process

The BootROM is the immutable first stage in the boot direction of, and serves because the hardware root of trust for the SoC. As is conventional, these SoCs grasp an efuse bank that will per chance well additionally be configured one day of OEM application manufacturing in tell to enable salvage boot and to specify the hash of the preloader signing certificates. Right via startup, the BootROM will read these fuses to gain out the configured salvage boot protection. Subsequent, the BootROM will load the preloader from eMMC into RAM and can check its signature sooner than executing it.

MediaTek’s preloader is the 2d stage in the boot direction of and is the first mutable code. The preloader is kept on the BOOT0 eMMC partition. As described in allotment 7.2 of the eMMC specification the boot partitions are special hardware partitions, reduce loose the principle user data partition.

eMMC partitions

Boot Direction of Diagnosis

The MediaTek SoC stores two copies of the preloader in BOOT0. If the first image is pass (i.e. doesn’t hotfoot the signature verification test), then the BootROM will load the 2d image. If every copies are pass, then the BootROM will enter Download Mode, as indicated by the string “[DL] 00009C40 00000000 010701” being sent over the UART.

In tell to load the preloader from flash into RAM, the eMMC boot mode characteristic is prone. Rather than sending individual READ instructions, the BootROM resets the eMMC into this “replace boot mode”. Here is executed by sending two GO_IDLE_STATE (CMD0) instructions: first with argument of 0xF0F0F0F0 which puts the cardboard into the “pre-sluggish” advise, then with 0xFFFFFFFA which puts it into the boot advise.

GO_IDLE_STATE commands to initiate reading of BOOT0

After receiving the 2d tell, the eMMC begins transmitting the contents of the BOOT0 partition over the DAT0 line in 1-bit mode. It takes about 100ms to gain your total partition contents.

Transmission of BOOT0 partition contents

As soon as the BootROM has obtained the total lot of the first preloader image from the BOOT0 partition, the direction of is interrupted by sending a GO_IDLE_STATE reset tell.

GO_IDLE_STATE command to stop BOOT0 reading

If the first preloader image is legitimate, our observations worth that it takes about 2 seconds between when the closing bytes of the preloader are transmitted and when the first eMMC tell issued by the preloader is seen.

Logic analyzer capture demonstrating this 2s window (first preloader is valid)

On the replace hand, if the first preloader image is invalid (that is, it fails signature verification), then this direction of is repeated. On the replace hand, now the BootROM does no longer send a reset tell unless after the 2d replica of the preloader is obtained. On this case, it takes handiest about 700ms between the BootROM making an try to load the first and the 2d preloader pictures.

Logic analyzer capture demonstrating this 700ms window (first preloader is invalid)

As a consequence of this truth, we decide that one day of the first ~700ms, the BootROM is busy parsing the preloader image structure and performing signature validation, and that the next 1.2s of execution is basically the preloader initialization code. For that reason, NCC Community determined that the voltage glitch attack have to goal the first 700ms window after preloader is read from eMMC.

FPGA Device off Setup

In tell to inject a voltage glitch with valid timing, a custom trigger used to be conducted the utilization of an cheap FPGA (Sipeed Tang Nano). The FPGA is hooked as much as the eMMC CLK and DAT0 traces (while the CMD pin is additionally connected in the image, it used to be handiest prone for debugging with a great judgment analyzer).

FPGA connected to test points on the tablet

While the good judgment level of the FPGA is 3.3V by default, it is additionally able to work with 1.8V inputs with out any board modifications. The output of the FPGA is a 3.3V trigger signal and is hooked as much as the ChipWhisperer trigger enter pin.

The Verilog trigger code is extremely straightforward: the FPGA is clocked by the eMMC clock signal and the code implements a shift register the utilization of DAT0 to shield music of the closing 4 bytes transferred over the road. When the specified pattern is seen, a trigger output signal is generated for 512 eMMC clock cycles:

consistently @(posedge emmc_clk or negedge sys_rst_n) commence

take <= take;

counter <= counter;

trigger <= trigger;

if (!sys_rst_n) commence

trigger <= 1'b0;

counter <= 24'b1000000000;

take <= 32'b0;

end else if (counter > 0) commence

counter <= counter - 1;

take <= 32'b0;

pause else if (take == 32'h4ebbc04d) commence

trigger <= 1'b1;

counter <= 24'b1000000000;

pause else commence

trigger <= 1'b0;

take <= {capture[31:0], emmc_dat0};



The pattern being matched, 4e bb c0 4d, are the four bytes located around the end of the first copy of the preloader:

Hex dump of the preloader

The trigger output signal is then fed to the ChipWhisperer where a delay is inserted and a glitch of a specific width is generated.

Glitch Target

The ChipWhisperer platform is used to introduce voltage glitches when the FPGA trigger activates.

SMA connector on the tablet wired to test pad

An SMA connector was soldered to the side of the tablet circuit board and then connected through a wire to the target pad: VCCK_PMU. The glitch shorts VCCK_PMU to ground through ChipWhisperer’s low-power MOSFET. By dropping core voltage for a very short period of time, we expect to corrupt the internal state of the processor (such as values of the registers) without completely crashing the whole system. In order to access the VCCK_PMU pad, a portion of soldermask was scratched off the PCB with a knife. No other board modifications were performed (i.e. we did not find that it was necessary to remove decoupling capacitors as is sometimes necessary).

Overall Setup

The overall setup of the glitching apparatus and its connections are shown in the following diagram.

Glitching apparatus block diagram

The following hardware was used to perform the attack:

  • 1.8v UART: A UART adapter which uses 1.8v logic level. This is used so that we can see target output and determine when a glitch attempt has succeeded ($2 USD).
  • RaspberryPi: Used to programmatically reset the target device by disabling and re-enabling USB power with uhubctl ($50 CAD, CanaKit).
  • FPGA: Passively listens to eMMC traffic and outputs glitch trigger signal to ChipWhisperer ($10 CAD, Digikey).
  • ChipWhisperer: Inserts voltage glitches after the trigger signal is activated ($325 USD, NewAE Technology).

Determining The Initial Glitch Parameters

The following parameters were used to set up the ChipWhisperer glitch:

scope.glitch.clk_src = "" 

scope.glitch.output = "enable_only"

scope.glitch.trigger_src = ""

scope.clock.clkgen_freq = 16000000 = True = False

Next, it was necessary to determine the target glitch width. To accomplish this, glitches of different widths were manually injected while the device was executing in the BootROM and preloader. Glitch widths of around 80-100 clock cycles were observed to introduce various types of state corruption in the preloader. However, many of these state corruptions did not appear to be exploitable. For example the following output was observed during one of the iterations:

[2176] [PART] check_part_overlapped done

[2180] [PART] load "tee1" from 0x0000000000B00200 (dev) to 0x43001000 (mem) [SUCCESS]

[2181] [PART] load speed: 15000KB/s, 46080 bytes, 3ms

[2213] [platform] ERROR: div0.c:line 41 0

[2213] [platform] ERROR: PL fatal error...

[2214] [platform] PL delay for Long Press Reboot

Bruteforcing the Correct Glitch Parameters

As stated previously, we assumed that the signature check occurs within the 700ms window after the final GO_IDLE_STATE command. In order to cover the whole 700ms of timing, a gradual bruteforce approach was used.

First, an unmodified and properly signed preloader was loaded into the eMMC BOOT0 partition. Then, a coarse bruteforce was performed in the offset range [25400, 100000] with a step size of 200 cycles. The assumption was that a useful glitch offset would cause the device either to crash (no output seen on UART), or be put in DL mode (“[DL] 00009C40 00000000 010701” output string observed on the UART).

Through this experimentation process, we determined that most of the attempted offsets resulted in no apparent change in device behavior and the preloader was loaded and ran as normal. However, after several hours of running this first-stage bruteforce, multiple areas of interest were identified and a more granular bruteforce was applied to them. This fine grained approach used step values of 20 cycles instead of 200 cycles.

At this point, NCC Group tampered with the preloader image by modifying a debug string. The BootROM should refuse to load this tampered image due to a failed signature check. However, we will know if the glitch was successful if this tampered image is loaded and executed. NCC Group once again identified areas of interest, and continued bruteforcing the glitch parameters. After about 2 hours of bruteforce, several successful glitches were confirmed. However, these successes were unreliable, and more fine tuning was needed.

Next, the bruteforce was fine-tuned around these specific offsets and widths to discover the perfect glitch parameters. With the proper parameters, and several days worth of bruteforce, we were able to achieve a 15-20% success rate for bypassing the signature check. The following table summarizes the statistical output from these runs, demonstrating that multiple sets of parameters (width and offset) were able to achieve a successful glitch.

Width Offset Success Run Total Runs Success Rate
94 41428 122 802 15.21%
93 41430 154 802 19.20%
94 41431 156 803 19.43%
127 41431 176 803 21.92%
129 41431 167 803 20.80%
93 41432 182 803 22.67%
115 41432 168 803 20.92%
117 41432 188 802 23.44%
126 41432 161 802 20.07%
130 41432 181 803 22.54%
117 41433 180 803 22.42%
118 41433 178 802 22.19%
129 41433 158 802 19.70%
100 41434 147 803 18.31%
103 41434 162 803 20.17%
104 41434 163 803 20.30%
128 41434 180 803 22.42%
129 41434 169 802 21.07%
130 41434 176 803 21.92%
103 41435 157 803 19.55%
104 41435 187 803 23.29%
126 41435 167 803 20.80%
128 41435 161 803 20.05%
100 41436 160 803 19.93%
102 41436 169 802 21.07%
100 41437 160 803 19.93%
102 41438 158 803 19.68%
103 41438 157 803 19.55%
104 41438 147 802 18.33%

Notice that all successful glitches are clustered around a narrow range of widths (93-130) and offsets (41428-41438). These values can be used with the provided ChipWhisperer script, at this end of this blog post.

Payload Execution

Beyond simply tampering with a debug string, our goal is to execute arbitrary code. So next, a payload was injected into the preloader binary, replacing a portion of the string section. The preloader was also modified to jump to the payload around where it would normally perform GPT parsing. The specific place, located in the later stage of the preloader, was chosen because after the glitch has succeeded, the UART has to be reconfigured with different baud rate parameters, which takes some time and results in early output from the preloader being lost.

The injected payload will print a log message and then read out BootROM memory and EFUSE contents. A successful glitch attempt is shown in the UART output below:

Dry run 

Dry run done, go!

105 41431 b'x00[DL] 00009C40 00000000 010701nr'

105 41433 b'x00'

99 41432 b'x00nrF0: 102B 0000nrF3: 4000 0036nrF3: 0000 0000nrV0: 0000 0000 [0001]nr00: 0007 4000nr01: 0000 0000nrBP: 0000 0209 [0000]nrG0: 0190 0000nrT0: 0000 038B [000F]nrJump to BLnrnrxfdxf0'

Glitched after 10.936420202255249s, reopening serial!

[1167] [Dram_Buffer] dram_buf_t size: 0x1789C0

[1167] [Dram_Buffer] part_hdr_t size: 0x200

[1168] [Dram_Buffer] g_dram_buf start addr: 0x4BE00000

[1169] [Dram_Buffer] g_dram_buf->msdc_gpd_pool commence addr: 0x4BF787C0

[1169] [Dram_Buffer] g_dram_buf->msdc_bd_pool commence addr: 0x4BF788C0

[1187] [RAM_CONSOLE] sram(0x12C000) sig 0x0 mismatch

[1188] [RAM_CONSOLE] commence: 0x44400000, dimension: 0x10000

[1188] [RAM_CONSOLE] sig: 0x43074244

[1189] [RAM_CONSOLE] off_pl: 0x40

[1189] [RAM_CONSOLE] off_lpl: 0x80

[1189] [RAM_CONSOLE] sz_pl: 0x10

[1190] [RAM_CONSOLE] wdt space (0x0)=0x0


MediaTek MT8163V voltage glitch proof of concept NCC Community 2020



00000000: 08 00 00 EA FE FF FF EA FE FF FF EA FE FF FF EA


00000020: BB BB BB BB 38 00 20 10 00 00 A0 E3 00 10 A0 E3

00000030: 00 20 A0 E3 00 30 A0 E3 00 40 A0 E3 00 50 A0 E3

00000040: 00 60 A0 E3 00 70 A0 E3 00 80 A0 E3 00 90 A0 E3

00000050: ...


10206000: 11 00 0F 00 62 00 00 00 00 00 00 00 00 00 00 00

10206010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

10206020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

10206030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

10206040: 00 10 02 04 00 00 50 0C 00 00 00 00 00 00 00 00

10206050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

10206060: 46 08 00 00 00 00 00 00 07 00 00 00 00 00 00 00

10206070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

10206080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

10206090: 47 C8 DE F6 A6 A9 A1 8B 7A 8D 71 91 06 BC 18 86

102060A0: 9F 97 E1 CD A3 7C 4C E8 AB E8 7F 60 E8 A6 FD 77

102060B0: ...

At this point, now we obtain confirmed that our glitching methodology used to succeed and that the injected payload is able effect arbitrary code. Even supposing, no longer demonstrated, it could per chance well additionally be possible to effect any highly-privileged operations that the preloader is on the total accountable for, such as decrypting and loading a modified TrustZone image, loading a malicious LK/Android image, and so forth.


We obtain demonstrated that the MediaTek MT8163V SoC is at possibility of voltage glitching attacks. Moreover, we seen a excessive glitch success rate with out the need for evolved setup of the glitching apparatus (e.g. clock synchronization or taking away capacitors from the board). While every online page of glitch parameters has an approximate 20% success rate, an adversary can trivially effect a 100% total success rate by simply rebooting between glitch attempts.

Because this vulnerability impacts the BootROM, it could per chance well no longer be patched in the sphere, and as-such all in-field products will remain prone indefinitely. In our conversations with MediaTek main as much as this disclosure, MediaTek indicated plans to implement fault injection mitigations in the BootROM of an upcoming and unnamed SoC. We weren’t given the replace to put in thoughts the effectiveness of these mitigations, or whether or no longer they are hardware-primarily primarily based mostly or application-primarily primarily based mostly.

NCC Community serves as a strategic safety advisor to many semiconductor companies as effectively as companies that invent and accomplish embedded devices such as smartphones or IoT products. In give a shield to of holistic safety engineering, we tell our clients to put in thoughts mitigations to fault injection attacks. For voltage-glitching, hardware-primarily primarily based mostly mitigations such as fast-reacting in-silicon brown-out detection circuitry, are the ideal protection. Alternatively, application-primarily primarily based mostly mitigations could per chance well additionally additionally be employed, though they handiest elevate the bar for an adversary, and accomplish no longer fully mitigate the attack. Instance application-primarily primarily based mostly mitigations encompass:

  • Redundantly effect excessive tests, terminating execution if conflicting outcomes are produced. This mitigation forces the attacker to effect quite loads of successive system defects in tell to bypass a single excessive safety test.
  • Insert random-duration delays at a form of aspects one day of safety-excessive code. This mitigation forces the attacker to implement quite loads of lawful trigger cases.
  • Put in drive management hotfoot along with the circulation integrity interior the BootROM, in particular spherical safety excessive sections of code. This mitigation could per chance well additionally lend a hand detect when an injected fault causes the program to effect unexpected code paths, such as skipping department instructions.

For application OEMs, mitigations are more sophisticated. And they obtain restricted capacity to impress the glitch resistance properties conducted by their upstream silicon vendors. On this case, NCC Community recommends that application OEMs work closely with their suppliers to acquire the protection posture of the parts. Where gaps in working out exist, put in thoughts third-occasion assessments. This evaluation have to be executed early one day of the factor resolution allotment, so that important comparisons amongst possible seller parts can decide location. Simplest these parts that meet the protection dreams and possibility devices of the product have to be thought about to be used. Above the chipset level, further layers of bodily safety can also lend a hand sluggish an attack of this nature, together with careful PCB invent, a big series of anti-tamper measures, and the nice exercise of cryptography provide protection to wanted user data.

For users and patrons who’re even further eliminated from the implementation of the BootROM, it is excessive to lift devices from vendors who repeat a dedication to safety of their products. Here is in particular exact for cell devices which are with out problems lost or stolen, and due to this truth at possibility of the types of bodily attacks discussed right here. Lowest build too generally components the least consideration to the significance of safety. Survey sure safety traits, such as malicious program bounty packages, published safety whitepapers, product safety marks such as ioXt, strange firmware update cadence, and a overall history of positively responding to publicly known safety vulnerabilities.

Disclosure Timeline

  • 2020-06-16: Despatched disclosure via MediaTek’s internet-primarily primarily based mostly reporting effect.
  • 2020-07-03: Bought no response, so reached out to business contacts for assistance on contacting MediaTek PSIRT.
  • 2020-07-13: Emailed quite loads of MediaTek staff hoping one could per chance well redirect my inquiry to their PSIRT.
  • 2020-07-13: Bought response and directed to GPG encrypt the disclosure and send to MTK’s PSIRT electronic mail alias.
  • 2020-07-14: Despatched the disclosure.
  • 2020-07-15: MediaTek acknowledge receipt of disclosure.
  • 2020-07-16: MediaTek requested convention call to discuss.
  • 2020-07-23: Held convention call to discuss the vulnerability.
  • 2020-07-27: Answered further questions relating to the vulnerability.
  • 2020-09-30: MediaTek requests to gaze disclosure chronicle ahead of e-newsletter.
  • 2020-10-07: NCC Community equipped MTK with draft advisory weblog put up.
  • 2020-10-15: Disclosure e-newsletter

Appendix: Glitcher Provide Code

import chipwhisperer as cw 

import time

import serial

import subprocess

import sys

commence = time.time()

scope = cw.scope()

scope.glitch.clk_src = ""

scope.glitch.output = "enable_only"

scope.glitch.trigger_src = ""

scope.clock.clkgen_freq = 16000000 = Upright = Pretend

SERIAL = "/dev/ttyUSB0"

RPI = ""

def power_off():

subprocess.check_output(["ssh", "root@{}".format(RPI),

"/root/uhubctl/uhubctl -l 1-1 -p 2 -a 0"])

def power_on():

subprocess.check_output(["ssh", "root@{}".format(RPI),

"/root/uhubctl/uhubctl -l 1-1 -p 2 -a 1"])

ser = serial.Serial(SERIAL, 115200, timeout=0.1)

print("Dry lunge")


scope.glitch.repeat = 10

scope.glitch.ext_offset = 0

scope.arm() power_on()

for x in vary(10):

data =


print("Dry lunge executed, hotfoot!")

def glitch_attempt(offset, width):


scope.glitch.repeat = width

scope.glitch.ext_offset = offset



data = b""

for x in vary(30):

data +=

if b"[DL]" in data and b"nr" in data:


if b"Jump to BL" in data and b"nr" in data:


print(width, offset, data)

if b"Jump" in data:

print("Glitched after {}s, reopening serial!nn".structure(

time.time() - commence))


ser2 = serial.Serial(SERIAL, 921600, timeout=0.1)

while Upright:

data =




while Upright:

for width, offset in [

(105, 41431), (105, 41433), ( 99, 41432), (101, 41434),

(127, 41430), (104, 41432), (134, 41431), (135, 41434),


glitch_attempt(offset, width)

at closing:

print("Turn off")


print("Disable scope")



Read More

Leave A Reply

Your email address will not be published.