Black Box Probing: a Security Analysis of Xiaomi's MJA1 Secure Chip - Quarkslab's blog

Table of contents

Discovery of MJA1 secure chip<br>Target identification<br>Hardware analysisMJA1 secure chip identification<br>Sniffing communications<br>Flash dumping

Firmware analysisReverse engineering miio_client<br>Command format

TestingTesting setup<br>Brute-forcing command IDs<br>Update command (0x06)

Conclusion & next steps<br>Acknowledgments

Posted<br>Thu 18 June 2026

Author<br>Mengsi Wu

Category

Reverse-Engineering

Tags<br>reverse-engineering,<br>hardware,<br>Xiaomi,<br>MJA1,<br>secure element,<br>2026

Xiaomi's MJA1 is a proprietary secure chip used in their recent cameras to protect sensitive data and device communications. With no public documentation available, we conducted a black-box security analysis covering hardware identification, I2C sniffing, flash dumping, and firmware reverse engineering. This post walks through how we mapped the chip's command protocol, brute-forced undocumented commands, and assessed its security properties.

Discovery of MJA1 secure chip

When navigating on Xiaomi's online store to find a new R&D target, we ended up on a description of the MJA1 secure chip, available on their recent cameras.

This chip claims to provide hardware-level protection for sensitive data and device communications. It is designed to be resistant to a variety of common attacks, including replay attacks, MITM attacks, brute force, ... And each chip has its own private key and certificate.

However, it is a proprietary chip: no documentation or datasheet is present on the Internet.<br>At the time of writing, no public research work has been done on it, only a picture from RoboCoffee1.

With no public information available, our goal for this project was to understand how the MJA1 secure chip works and evaluate its security properties through black-box analysis.

Target identification

The first step was to find a target satisfying the following criteria:

Integrating the MJA1 secure chip;

Reasonable price (Allowing firmware upgrades interception, via mobile app for example, in case we fail to dump the firmware.

We ended up purchasing two devices for the price of one:

Xiaomi Outdoor Camera BW300 (60&euro;)

Xiaomi Camera Base Station (30&euro;)

They both have a MJA1 secure chip integrated and can interact together. This way, we can compare two different devices, check for the easiest target, and cross-validate our findings.

Hardware analysis

MJA1 secure chip identification

After opening both devices and inspecting their PCBs, we located the MJA1 chip on each board.<br>Both devices use the same MJA1 C06CW model.

The following picture shows the MJA1 chip on the BW300 camera.

The chip comes in a DFN 2&times;3-8 package, which means:

Dual Flat No-lead (DFN);

Size: 2 &times; 3 mm 🤏;

8 pins.

To identify the communication interface, we had to actively probe the chip while the device was running.

Sniffing communications

To observe the communication between the main SoC and the MJA1 chip, we used a PCBite setup combined with a logic analyzer. The PCBite probes can easily fit onto the 0.5 mm pin pitch of the chip.

We then powered the camera base station and started capturing signals on the pins of the chip. The goal at this stage was simple: identify which pins carried data, and from there, figure out what protocol was used.

Looking at the eight pins, most of them stayed flat, which may indicate VCC/pull-ups (constant high) or GND (constant low). Only two showed active data exchange:

In the embedded world, most common interfaces have characteristic pin counts:

UART uses two pins (TX, RX), but both are active in different directions and in an asynchronous way;

SPI needs at least four pins (CLK, MOSI, MISO, CS), which does not correspond to our case;

I2C uses exactly two pins (SCL, SDA), shared bidirectionally between master and slave, synchronously.

Zooming in on the captures revealed the typical signature of an I2C bus, with a regular clock line and a data line:

By applying the built-in I2C decoder of the logic analyzer, we could read the transaction: Write [0x2A] to address the chip, then a sequence of data bytes: 0x05, 0x00, 0x03, 0x00, 0x02, 0x00, 0x08, 0x58, 0xEF, each acknowledged by the slave.

From there, we could conclude:

Communication with the secure chip uses the I2C protocol;

The clock (SCL) defines when data is read; the data line (SDA) carries the bits;

The address of the secure chip is 0x2A — I2C being a shared bus, each device on it is identified by such an ID.

As a side note, the exact byte sequence captured above (0x05 0x00 0x03 0x00 0x02 0x00 0x08 0x58 0xEF) is in fact a READ command, the very same one we will decode in detail later in this post.

Sniffing gave us the transport layer, but the actual command structure on top of I2C was still unknown. To understand it, we needed to extract and analyze the firmware of the host device that talks to the chip.

Flash dumping

We had two devices to work with, each with...