AuthorForum Account:FinchK
0x0 Introduction
As a pure beginner in reverse engineering, I have been involved in it for about two months.
I have a Xiaomi Mi Band 4 NFC version, which has the built-in Xiao Ai assistant that can engage in voice conversations to control smart home devices and perform operations such as setting alarms. Out of curiosity about its implementation principles and a desire to expand its functionality, I decided to reverse engineer it. There are only studies on Miband 3 available online, and I should be the first to explore the new features of Miband 4.
0x1 Preparation Before Reverse Engineering
First, to use the voice assistant in the Xiaomi Mi Band, the band must remain connected to the phone, and the Xiaomi Sports APP must run in the background. Clearly, the Xiaomi Mi Band does not have built-in voice recognition capabilities; it is presumed that it sends data from the sound sensor to the phone, which then performs voice recognition and natural language processing before sending it back to the band.
To achieve BLE (Bluetooth Low Energy) communication in Android, it is necessary to call
boolean android.bluetooth.BluetoothGatt.writeCharacteristic(BluetoothGattCharacteristic characteristic)For specific APIs, refer to Google’s documentation.
We will start from here.
0x2 Starting the Reverse Engineering
We used Jadx to open the Xiaomi Sports APP and examined its source code. We found that most of the code was heavily obfuscated, but this was not a problem.
We directly used the code search function to search for “writeCharacteristic” and found the results we were looking for.
The code search process is omitted here, but we eventually found the function that sends the byte stream.
We continued to look for references upwards, hoping to determine the packet structure through static analysis. The result…
Jadx failed to decompile… Emm… never mind, let’s just hook it.
We can hook the function that sends the data packets to see what it actually sends. Of course, we can also directly hook the Android API to prevent missing anything. Here, we chose the latter.
Success! The structures of these packets are quite clear; most are strings and some integers, and they are not encrypted. Through multiple comparisons and guesses, we can understand them, so I won’t go into detail. Next, we will focus on analyzing the communication protocol of Xiao Ai and the authentication algorithm of the Xiaomi Mi Band.
0x3 Communication Protocol of Xiao Ai
To capture the interaction packets of Xiao Ai, we also need to hook the function that reads the byte stream via Bluetooth. In Android, this process is implemented through a callback, so we need to hook that callback function. A quick search led us to:
com.xiaomi.hm.health.bt.O00000oO.O00000Oo.onCharacteristicChanged(BluetoothGatt bluetoothGatt, BluetoothGattCharacteristic bluetoothGattCharacteristic)
This way, we can also capture the packets sent from the band to the APP:
Since I have more experience in forward development, I could guess directly that the first few packets only involve some state exchanges, such as starting recording, switching UI, etc. The decryption of the subsequent voice data is the key.
I observed these voice data packets and found that the first byte represents the packet type, and the second byte represents the packet sequence number, which should be to prevent out-of-order delivery (I don’t know if BLE has out-of-order delivery). Next should be the voice data, initially guessed to be PCM, but it turned out not to be; there is another layer of encoding. Printing the call stack seems unfeasible, so I continued static analysis of the APP.
By searching for some keywords, I found some interesting ENUMs.
Note that tracing back the onCharacteristicChanged function is useless here because most apps pass parameters indirectly using Intents rather than directly calling the decryption function.
As long as we trace back the references of this enumeration, we can find the code that parses the voice data packets.
Hmm, it seems we are on the right track.
Here is the decryption function. It can be seen that it traverses an array, first writing the elements to a file, and then calling another function. Let’s follow that function.
Indeed, it calls a decode function, and from the string, we know that the final format should be PCM at 16k. Before decryption, it should be Opus.
I found that it calls a shared object, but the Opus decryption code is open source, so let’s write a demo using the open-source library.
Success! This way, we have completed the process from capturing voice data to decrypting it.
0x4 Xiaomi Mi Band Authentication Algorithm
Features like Xiao Ai cannot be used without authentication, so there is an authentication process.
There are also related articles online; a combination of static and dynamic analysis will suffice. However, I would like to point out that one of the parameters in the verification packet seems to have changed, which is different from what I found in online articles. The main issue is the data and key of the AES algorithm.
0x5 Insights and Conclusion
Analyzing this APP was quite simple; the entire process took an afternoon, and there were no complex encryption processes. The software itself had no protection, but I still learned a lot, such as:
-
Consider the APIs called by the software and trace back.
-
Keyword searching.
-
Combining dynamic and static analysis.
-
Mastering some software design patterns (the field of software engineering) and the forward development mindset of the APP can help make better guesses.
Actually, there is a simpler method: hook the function that prints logs. After some trial and error, I found that the logs from the Xiaomi Sports APP are very detailed (escape).
Here’s a picture of a friendly chat with a GitHub user; it seems that the Xiaomi Mi Band is heading towards internationalization.
––OfficialForumDiscussionPlatform
www.52pojie.cn
––RecommendtoFriends
PublicWeChatAccount:WeLoveBreakingNews
OrSearchWeChatAccount:pojie_52