Down the rabbit hole. Storming Yandex Station debug console

The proposed method is suitable for:

• Yandex Station Mini2 (YNDX-00020/21);
• Yandex Station Lite (YNDX-00025);
• Yandex Station Max (YNDX-00053/0008); and 
• other devices based on Amlogic S905X2 (G12) and A113X (AXG).

In my research, I used two interesting plugins for IDA: using Diaphor, you can borrow information from a similar open-source project; while FindCrypt helps to find cryptographic constants.

U-Boot login

If you tried to connect to the UART interface of Yandex Stations, you probably saw such inscriptions as “RH challenge” and “RH response”. At that point, the station stops booting-up, and you have either to reboot it or enter a response. The request is always different, and it’s nothing more than authorization required when you attempt to log into the U-Boot console.

Login to the U-Boot console is initiated when you interrupt the autoboot using any key, for example Enter or Ctrl-C (classic variant). After that, authorization can be required (standard authorization types such as bootstopkeysha256 (by password hash)). An excellent description of these authorization methods can be found in the article I hack, U-Boot. Yandex went a little beyond the standard procedure and added its own authorization method: Rabbit Hole. Let’s see how it works.

First, you have to obtain the device firmware (i.e. read it using a programming device or any other technique). As an example, let’s examine Yandex Station Lite (YNDX-00025). To extract its firmware, I used the update utility developed by Amlogic to interact with its bootloaders via USB. It’s suitable for devices without a password. The bootloader consists of two parts, BL2 and TPL, which corresponds to the standard U-Boot structure.

If you build U-Boot for the A113X chip manually, you’ll get two files at the output: u-boot.bin.bl2 and u-boot.bin.tpl (both unencrypted). Unfortunately, Yandex smart stations use encrypted versions.

However, they can be decrypted thanks to a known vulnerability.

The bug makes it possible to decrypt boot files when you connect via USB without a password. By default, the Lite, Mini2, and Max stations don’t have a password — but over time, Yandex began installing it remotely. I was lucky: boards I am dealing with aren’t protected yet. Accordingly, I can use this vulnerability to decrypt the TPL file; while BL2 isn’t required for analysis.

Bootloader structure

To protect the boot process, Trusted Firmware is used with additional elements that are mainly related to hardware features added by the processor manufacturer. The first to start is BL1 (Boot ROM); it’s hardcoded in the processor at the factory and cannot be replaced. Other components start after it in the following sequence:

• BL2 prepares the system for startup;
• BL31 and BL32 constitute the protected part to ensure security; and 
• BL33 (U-Boot) is what I need.

For now, I am not interested in the fist-level bootloader BL2; what I need is TPL containing the remaining boot levels, including BL33 (U-Boot).

In Max systems equipped with the Amlogic S905X2 processor, the bootloader is represented by a single file, bootloader.bin, which includes all boot stages: from initialization to U-Boot. In models based on A113X chips (e.g. Lite and Mini2), the bootloader is divided into two separate files whose extensions are .bl2 and .tpl.

In the firmware, each boot stage is marked with the @AML signature followed by a header with service information. I examined several bootloader files and noticed that the last in order @AML signature corresponds to the BL33 component. Its distinctive feature is the presence of the LZ4C string, which indicates LZ4 compression. Another indirect signs of compression are ‘broken’ strings in the file body.

Additional confirmation of this assumption was found in an article by Frederic Basse who managed to compress U-Boot in accordance with the LZ4 algorithm using standard Amlogic tools.

Attempt to extract U-Boot BL33

Let’s try to extract the BL33 component. No ready-made solutions could be found on the Internet, so, I had to figure it out myself. As a first step, I tried the easiest way: using the dd utility, cut off the desired file section and then unpack it using the LZ4 archiver.

Too bad, the data didn’t fit, and the archiver complained about a damaged header. Attempts to unpack using other utilities or add the header manually were unsuccessful as well. Alas, this method doesn’t work. But in the process, I checked the LZ4 source code in the hope to find suitable compression techniques and apply them to my data.

I examined the header trying to determine its format and get data that could be useful for unpacking. The Doc section of the repository contains descriptions of two formats:

• LZ4 Block Format — data blocks; and 
• LZ4 Frame Format — data headers.

The found descriptions pertain mostly to the data structure before and after compression, but don’t provide information about the initial header. Still, something useful was discovered: LZ4 decompression can be applied not only to files, but also to buffers; to do so, you have to explicitly specify the buffer size before and after compression. Accordingly, these values must be stored somewhere.

I put on hold the research of the LZ4 source code and continued my searches. At some point, I came across a much-needed clue on one of the forums: a link to the amlogic-boot-fip project. Its repository, in turn, provides links to three other projects where reverse-engineered Amlogic utilities (exactly what I need!) can be found:

• meson-tools — GXBB, GXL, and GXM;
• gxlimg — GXBB, GXL, GXM, and AXG; and 
• meson64-tools — designed for G12B and can potentially work with G12A and SM1.

Ultimately, I settled on the meson64-tools repository. It contains the LZ4 library and the disassembled bl3sig.c signature utility that provides everything I need: a header in the form of a C structure and a reference to the compression algorithm used (LZ4HC). Importantly, when you apply this structure to the available data, the byte order must be taken into account; in this particular case, the processor uses little-endian, and multibyte values should be read in reverse order.

LZ4 summary

Overall, I was able to establish that the LZ4C signature denotes the beginning of a header 0x80 bytes long followed by a compressed data buffer. The LZ4HC compression algorithm is used, and all parameters required for unpacking, including buffer size before and after compression, are contained in this header.

Extraction

Now that you possess all information about the header and the algorithm, let’s try to unpack the bootloader. For this purpose, I wrote a utility in my favorite programming language, C#.

In addition to the standard libraries, it uses the K4os.Compression.LZ4 package. The main part is provided below; while the full code can be found on my GitHub.

The algorithm is simple: the program gets the data size before (original_size) and after (compressed_size) compression, reads the compressed data in one big chunk, and passes it for unpacking. After successful completion, the buffer containing the unpacked data is written to the file. Voila!

Moving on to the disassembler

As can be seen, the strings are no longer ‘broken’, and IDA/Ghydra can now analyze and ‘disassemble’ the extracted BL33.

Too bad, you cannot modify U-Boot and push it back (even if you have encryption keys). Yes, it can be packed into the firmware, but it won’t pass validation due to the changes you’ve made (that’s what Trusted Firmware is for). However, the performed exercises are still of benefit: now you can analyze nonstandard functions added by Yandex to its devices and finally find Rabbit Hole (and maybe even dive into it).

Researches and searches

To ensure that the disassembler processes the extracted firmware correctly, I select the ARM little-endian architecture. I take an easy way by accepting all default parameters. The entry point is at the very beginning of the firmware; I place the cursor to 0x00 and press C: IDA will automatically create a number of functions.

Not everything can be recognized automatically, and I go through the firmware manually to process undefined sections (mostly by pressing C). The next step is to place the image at the correct address (base address) to get the most correct cross references to functions and data. The station boot log helps to determine the correct address:

To make edits, I go to Edit → Segments → Rebase Program and specify the desired value. After that, you can see the changes. Some of the cross references were previously incorrectly interpreted, but now everything should correspond to the U-Boot location in the device memory.

Searching for the hole

The firmware is ready for analysis, and I finally start searching for Rabbit Hole. From the boot log I know the text of the message: “RH challenge”; so, let’s cling to it. I review the list of string in the hope that it contains a reference.

I am lucky, and the reference is there. I immediately name the function Rabbit Hole. The code looks simple (only 63 lines and 5 functions), but all functions have unknown names and must be distinguished somehow.

Functions can be identified in two ways:

1. Get inside each function, analyze its logic, and give it a meaningful name; or 
2. Build a similar version of the software with debug information and use the Diaphora (or similar) plugin to search for standard functions (e.g. printf or sha256).

Normally, I use the first method at the beginning of the study, but if it’s possible to use the second one, I definitely use it. Since I am dealing with U-Boot, most of the functions can probably be identified using the second method.

U-Boot compilation environment

So, I have to compare functions with their analogs compiled from the source code of the closest version. To do this, I have to determine which compiler and software were used.

When U-Boot is built, strings containing the U-Boot version and the compiler used are added to the data section. I search for the strings U-Boot and GCC (for the compiler) and find the following:

• aarch64-elf-gcc (Linaro GCC 4.9-2017.01) 4.9.4;
• ld (Linaro_Binutils-2017.01) 2.24.0.20141017 Linaro 2014_11-3-git; and 
• U-Boot 2015.01 (Sep 29 2023 - 19:21:39) — the same can be seen in the boot log.

Build environment

Information about the version and compiler has been found; I search for the source code and download the compiler. I am going to use Ubuntu. The official documentation suggests the following sequence of actions for cross-compilation:

But the compiler version in the documentation is different from the one I am dealing with; in addition, there are two of them. The version isn’t a problem (I just have to find the right one); while the presence of two compilers requires clarification:

• gcc-linaro-arm-none-eabi builds code running in 32-bit ARMv7 mode; and 
• gcc-linaro-aarch64-none-elf builds code running in 64-bit AArhc64 mode.

In version 4.9, the notations have changed a bit; according to the Help, they should be as follows:

• aarch64-none-elf — gcc-linaro-*x86_64_aarch64-elf.tar.xz (Linux 64-bit binaries for the AArch64 bare-metal cross-toolchain);
• arm-none-eabi — gcc-linaro-*x86_64_arm-eabi.tar.xz (Linux 64-bit binaries for the ARMv7 bare-metal cross-toolchain).

Why two architectures? Because the Amlogic A113X processor has two cores with different architectures: the main one is Cortex-A53 based on the 64-bit ARMv8-A (AArch64); while the auxiliary one is Cortex-M3 based on the 32-bit ARMv7-M. The first core is responsible for the main boot-up and OS execution; the second one is responsible for real-time tasks (e.g. power management or work with audio).

To simplify routine actions during build iterations, I wrote a short script. Commented out strings were left to be able to change the U-Boot version or use a different version of the arm-none-eabi compiler. As a basis, I used the repository of Khadas: this manufacturer of debug boards actively maintains the U-Boot branch under investigation and updates it on a regular basis.

The build results are stored in the build folder; I am interested in the u-boot file. I load it to IDA, and it automatically determines the ELF 64 bit type and performs full analysis. All functions have names, and information about segments is in place.

Starting Diaphora

Time to start the plugin that will identify signatures and strings and save all required information to its database (SQLite) to compare it with the U-Boot version used by Yandex.

This process can take a while: my 10-year-old MacBook Air spent some 30 minutes on each firmware (the compiled one and the one used by Yandex).

When indexing is finished, you have to get back to the Yandex firmware and start the plugin again. This time, in the comparison database string, you should specify the SQLite database created during indexing of the compiled U-Boot. Important: don’t start re-indexing! If you do, the plugin will perform the same task again, and you’ll waste another half hour.

After the scan, the plugin will display its results in several tabs:

• Best matches — most accurately matching functions;
• Partial matches — more or less matching functions with minor differences (matching degree is indicated by color: bright green (high) or dark purple (low));
• Problematic matches — poorly matching results; and 
• Unmatched — several tabs of completely unique functions.

First, I go to the tab with completely matching functions, select them, and import them into the project: after that, the IDA database will be updated. Then I open the Partial tab and import some more functions (only those highlighted in green). It’s highly recommended to review the contents prior to importing, so that you don’t import unnecessary stuff. The remaining tabs can be ignored: they are of no interest to me.

After the import, meaningful names of functions and variables appear in the U-Boot under investigation.

To get a more comprehensive result, you can retrieve and index other U-Boot versions: each of them can potentially help process new functions. No guarantee, but sometimes this approach makes it possible to significantly expand the database.

I limited myself to one pass and moved on to the next plugin: FindCrypt. It searches for cryptographic constants that can be used to identify encryption algorithms. When the plugin finds some constants, it automatically renames them in accordance with their purpose.

Analysis per se

In total, Rabbit Hole contains five functions:

• sub_EDC96CC;
• sub_EDC1BBC;
• sub_EDC1B74;
• sub_EDC1A14; and 
• sub_EDC9734.

Unfortunately, the U-Boot version I built and above-described manipulations didn’t give names to these functions. Perhaps, I used an unsuitable version of the source code, or Yandex engineers wrote some parts of the code themselves. As a result, I had to study each function manually: analyze its behavior, examine strings used in it, and assign names based on the collected information:

• sub_EDC96CC — challenge_gen;
• sub_EDC1BBC — print;
• sub_EDC1B74 — getconsole;
• sub_EDC1A14 — getc; and 
• sub_EDC9734 — challenge_chk.

Let’s go through the first one and the last one.

challenge_gen

Analysis of the first function and the call to sub_EE2218C() showed that a challenge is generated in the a1 register (and I immediately renamed it accordingly). Each request is unique since it’s created using a hardware random number generator. The contents of the sub_EE2218C() function confirm this: its only string is return MEMORY[0xFF634018];. According to the A113X documentation, this address indeed belongs to the RNG area.

I can be assumed that the challenge_gen function takes a pointer to a buffer where the request should be written as a string in a hexadecimal notation. As an output, the function returns the length of the generated string in bytes.

The satiation with challenge_chk is slightly easier: almost all functions in this area have already been assigned meaningful names. They clearly indicate that input data are hashed using SHA-256, and the generated hash is subsequently passed to sub_EE0EBA8. Let’s see what’s inside it.

Some transformations can be seen in the code of this function, but still no names. Let’s dive into each numbered function and try to find out what it does.

So, sub_EE0E8B0 ‘swaps’ bytes of the input array and places them to another array.

Let’s name it array_bswap32. If I come across it somewhere else, I won’t have to delve into it again.

The situation with the sub_EE0E8E4 function is more complicated: it has a branched structure, and many data operations can be seen. I reviewed its listing and noticed the subM function: its name appeared in Diaphora’s output. Let’s try to find this name in the U-Boot source code from the Khadas repository that I’ve compiled.

As can be seen, this function occurs only in the avb_rsa.с file, which is a lucky break!

I examined this file in detail and compared it with what I see in IDA. As a result, I came across a call to avb_rsa_verify. This function is very similar to the beginning of sub_EE0E8E4.

A very similar check at the beginning, but no test messages are output. Instead, only error codes are returned: everything that’s not equal to 0 is bad. I go further and find more similarities; accordingly, I go back a couple of levels up and give a name to the sub_EE0EBA8 function: rsa_yndx. Now the response check function looks as follows:

where:

• dword_EE370C0 contains the public part of the RSA key;
• a2 is the answer (that you enter);
• 0x100u is the size of the data being checked;
• 0xEE89720 is the memory cell containing SHA-256 from the challenge; and 
• unk_EE593E0 is probably padding.

Looking at the prototype of avb_rsa_verify, one can match the parameters of rsa_yndx: they don’t look identical, but analysis makes it possible to fully reconcile them.

The same file contains a function with a self-explanatory name: array_bswap32. It converts little-endians into big-endians using the so-called swapping algorithm: byte-by-byte permutation in 32-bit words. Let’s find out where it’s called and what its role in data processing is.

To summarize. When a user tries to log into the U-Boot console, Rabbit Hole generates a text request (challenge). The user must sign this request with their private part of the RSA key and enter the resulting signature back into the console. Then the rsa_yndx function is called; it verifies the signature by analogy with avb_rsa_verify using the RSA-2048 algorithm. In case of successful verification, the function returns 0.

Done with the basic Rabbit Hole mechanics. The rest of its parts are pretty simple; below is its listing with comments:

The complete authorization algorithm is as follows:

1. During system autoboot, the user presses Enter or Ctrl-C, which provokes a call to Rabbit Hole;
2. A random request is generated and displayed in the console;
3. The user must sign the request with the private part of the RSA key and convert it to Base64;
4. User’s response in Base64 is converted into binary format and checked by the challenge_chk function;
5. If the verification result matches, then the user gets access to the U-Boot interactive mode.

The screenshot below was taken using Yandex Station Max.

I managed to get access to this console; some of my friends were able to access it, too. However, if the password has already been set, accessing the console becomes significantly more difficult.

Conclusions

Yandex engineers used a very secure algorithm to protect the U-Boot console: asymmetric RSA-2048 with random input data; it prevents access even if you’ve managed to decrypt the firmware. Brute-force is useless, and there is only one login attempt: an incorrect response reboots the device, and a new request is generated. In other words, there’s no way to bypass Rabbit Hole head-on.

But along the way, I created a tool that extracts BL33 and found out how this firmware is protected. Hopefully, the presented information will be useful for you, too.

I am not a professional reverse engineer — just an enthusiastic amateur. This is my first experience in this area, and if I did some nonsense, don’t hesitate to tell me about it in the comments!