When the vendor doesn’t protect you, we protect your Station, Capsule and A113X

Greetings!

In our imperfect world of “smart homes” and ubiquitous IoT, it has recently become fashionable to produce (and even buy home) another talkative electronic friend, namely: Yandex Stations, VK Capsules, SberBoom and similar devices.

Unfortunately for the developers (not to be confused with the vendors) of these devices, some of them contain vulnerabilities that allow users with the necessary skills to locally gain full control over the hardware, read data that the user should not be able to read, and in general be able to study the firmware , find vulnerabilities in it, and so on.

Of course, as you can understand from the name, we will talk about devices based on SoC from Amlogic – A113X. In this article I will talk about how you can protect your devices based on this chip from the things described above, why Amlogic could not offer this protection to developers, and other interesting details. Programmers of smart speakers, and those simply interested – welcome to cat.

Is A113X vulnerable?

Perhaps some developers of smart home devices who worked with Amlogic A113X were now very surprised to learn that the stone they chose for development is subject to some kind of vulnerability (besides, it was not introduced by them themselves).

So, back in 2020, in another chip from Amlogic – S905D3 a critical vulnerability was found at the Bootrom level, allowing the execution of any unsigned code, which obviously cannot be fixed. One of the commands of the Amlogic USB Download protocol used by the vendor's utility turned out to be vulnerable Aml Burning Tool v3 for flashing and updating devices. In addition, an exploit has been publicly published that allows you to take advantage of this vulnerability locally and execute the necessary commands. For example, you can subtract encryption keys from the protected area of ​​the chip (fuses) and decrypt the contents of some areas of the firmware, or simply dump the Bootrom itself and study it in more detail.

It would seem that this has nothing to do with it A113X? The fact is that the specified update protocol is used in the hero of this article, and contains the same vulnerability. Only there doesn’t seem to be a public exploit (in fact, the author wasn’t looking for it). In addition, attentive readers who have already read about the vulnerability via the link have noticed that it is possible to protect yourself from the vulnerability!

According to the material, you can use the “password protection” built into Bootrom, and that’s it – the vulnerability will be unexploitable. Having studied the bootrom code, I can say with confidence that password protection actually closes the bug found.

Password protection

Password protection involves writing a hash of the password you need into fuses and setting the corresponding bit there. The check will occur every time someone connects to the device via USB and tries to send commands, triggering before the execution of its main commands, such as the vulnerable one AM_REQ_WR_LARGE_MEM. And everything would be fine, but there is one BUT.

The developer tools (SDK) provided by Amlogic do contain a utility that allows you to set the required password when building the firmware and create a file that will include the fuses to be flashed into the device. This fuse file (which also includes firmware encryption keys) may have names in the style secureboot_set/secure_boot_set/amlogic_set and so on, and is used by the utility mentioned earlier – Aml Burning Tool.

Before mentioning that same BUT, it’s worth telling that Amlogic divides its chips into so-called “families”, and they have the following names:

For each family presented in the SDK there is its own version of the utility for creating a Secure Boot Set. This is done because all of them have their own Bootrom with its own structure for storing flags and keys in fuses.

So, BUT is that Not for all families in the list, the utility for creating a fuse file allows you to set this same password on USB. And in response to requests, the vendor claims that there is no way to set a password on such families in principle.

Faced with this, developers who wanted to somehow protect their device from unplanned use (sometimes without even knowing about the vulnerability) begin to resort to various tricks (or not to do so) just to prevent the researcher from tinkering with the firmware:

• They use USB pins, but do not bring them out, while hiding the pinout on the board

• Continue to use the USB port, protecting a higher level (RH, U-Boot bootdelay)

• Use a USB port (no protection)

Of course, all these protections only last so long as it takes the researcher to bypass them:

• you can call the pinout

• protections above Bootrom are meaningless if the chain of trust is broken

Is Amlogic telling the truth?

Let's find out whether the vendor is telling the truth when he claims that chips like A113X There is no password protection. To do this, we need to dump the Bootrom of the stone itself. For those who develop for this chip, doing this is as easy as shelling pears – the main thing is to write code that dumps the contents of memory at the address 0xFFFF0000 in UART.

Well, for those who have the ability to develop (or at least sign) code for A113X no (conditional device security researcher), there is only one option – to study the possibilities of running your code on the device. And this option actually contains the only solution:

I would not like to present the adapted exploit here for various reasons. Let me just say that after a detailed study of the dumped Bootrom from S905D3 the modification process becomes much easier. Well, the rest is stupid brute force of unknown addresses.

Be that as it may, having received the bootrom code A113Xmake sure that the USB protocol has a password checking function:

Adding password support for axg (A113X)

Great, we found out that the password is still checked, but the utility specially created for this does not even have the necessary flag so that this password is written to the fuse file. No problem, let's write the necessary bytes into it and it's done, right?

In fact, it's not that simple! If you take a closer look at the fuse file itself, you will notice some “mess” (let’s call it “high entropy”). This could mean using some kind of encryption or compression (or possibly both).

I’ll jump ahead and say that this is encryption. If you delve into the utility for creating a fuse file for other platforms (its name is aml_encrypt_xxxWhere xxx – platform name) in which password support is implemented, many interesting details can be found.

Firstly, you can find the password setting command itself mkpsd. Secondly, discover the encryption algorithm for the fuse file. A week of debugging – and now we can already decrypt secure_boot_set (including for the platform axg). All that remains is to figure out how to insert a flag into this file USB_PD_CHK_ENABLE and the USB password hash itself.

To do this, you will have to study the Bootrom code a little more. There, inside the function check_password you can find the following code:

We see that the hash we need is located at the offset 0x60. The hash also has a “salt” next to it:

Well, the necessary bit location for checking the password USB_PD_CHK_ENABLE managed to find out by the location of other flags in the same secure_boot_setand it turned out to be equal 0xB4. That is, the algorithm is as follows:

1. Deciphering secure_boot_set

2. Write down the USB password hash and salt at the offset 0x60

3. Set the bit number 15 per unit in yard by offset 0xB4

4. Encrypt the file back

5. Flash it via UBoot command efuse amlogic_sethaving previously written the contents of the fuse file with a password to the desired memory address (it is also possible to contain only password information, without AES encryption keys and the like)

6. Voila, the exploit no longer works!

Conclusion

Why couldn't the vendor include all the same things in the platform utilities? axg (A113X), what was done in this article, having all the source codes (is it all?), I don’t understand. Moreover, he was notified that the ability to set a password for axg There is.

It’s also funny that the vast majority of devices based on A113X do not contain enabled USB password checking and are susceptible to exploitation of a long-found vulnerability, which cannot be closed except by setting this password.

To confirm the stream of thoughts written in this material, I tortured devices from Yandex, VK and Sber based on this platform through an exploit, and only the latter had this protection turned on, preventing it from running its own code.

Therefore, in order to protect all listed smart speaker manufacturers from exploitation of the Bootrom vulnerability A113X and, accordingly, from running any code on them, searching in the vulnerability columns through firmware dumping from flash, I decided to share a script that will close the specified hole.

Scripts

Creation kit secure_boot_set with USB password: https://gist.github.com/lab313ru/08ca90aaacc41f662d39861ceda5510d

Examples of using:

python usb_password_a113x.py e usb_secureboot_set.bin -p password.bin

python usb_password_a113x.py d usb_secureboot_set_dec.bin -i usb_secureboot_set.bin